Microsoft Hybrid Cloud blogsite about Management

Tag Archives: Enterprise

Overview

The “Secure DevOps Kit for Azure” (will be referred to as ‘AzSDK’ henceforth) is a collection of scripts, tools, extensions, automations, etc. that caters to the end to end Azure subscription and resource security needs for dev ops teams using extensive automation and smoothly integrating security into native dev ops workflows helping accomplish secure dev ops with these 6 focus areas:1. Secure the subscription: A secure cloud subscription provides a core foundation upon which subsequent development and deployment activities can be conducted. An engineering team should have the capabilities to deploy and configure security in the subscription including elements such as alerts, ARM policies, RBAC, Security Center policies, JEA, Resource Locks, etc. Likewise, it should be possible to check that all settings are in conformance to a secure baseline.2. Enable secure development: During the coding and early development stages, developers should have the ability to write secure code and to test the secure configuration of their cloud applications. Just like build verification tests (BVTs), we introduce the concept of security verification tests (SVTs) which can check for security of various resource types in Azure.3. Integrate security into CICD: Test automation is a core tenet of devops. We emphasize this by providing the ability to run SVTs as part of the VSTS CICD pipeline. These SVTs can be used to ensure that the target subscription used to deploy a cloud application and the Azure resources the application is built upon are all setup in a secure manner.4. Continuous Assurance: In the constantly changing dev ops environment, it is important to move away from the mindset of security being a milestone. We have to treat security as a continuously varying state of a system. This is made possible through capabilities that enable continuous assurance using a combination of automation runbooks, schedules, etc.5. Alerting & Monitoring: Visibility of security status is important for individual application teams and also for central enterprise teams. We provide solutions that cater to the needs of both. Moreover, the solution spans across all stages of dev ops in effect bridging the gap between the dev team and the ops team from a security standpoint through the single, integrated views it generates.6. Cloud Risk Governance: Lastly, underlying all activities in the kit is a telemetry framework that generates events capturing usage, adoption, evaluation results, etc. This allows us to make measured improvements to security targeting areas of high risk and maximum usage before others.

Develop Security, Spot Check security via Scripts

Deploy securely from VSO Build/Release Pipeline

Security Verification Tests (SVTs) in VSTS pipeline

Security Verification Tests (SVTs) in Jenkins pipeline (Preview)

The AzSDK contains Security Verification Tests (SVTs) for multiple PaaS and IaaS services of the Azure platform. As we have seen so far, these SVTs can be manually run against one or more target resources held in resource groups or tagged via a {tagName, tagValue} pair. While it is invaluable to run these SVTs periodically from a PS console (to ensure that the subscription and the different resources that comprise your application are in a secure state), a key aspect of dev ops is to be able to automate such tests and integrate them as part of the dev ops workflows and release pipelines. In other words, while checking that SVTs pass in an ad hoc manner is a good practice, it is important to be able to also ensure that security control configuration remains intact in higher environments.
The CICD extensions feature of AzSDK makes automated security configuration enforcement possible by making SVTs available as a Visual Studio Extension in the Marketplace so that engineering teams can run them within build/release pipeline. Once the build/release task is configured, SVTs run against a target deployment in an Azure subscription. Upon completion, SVTs will report the pass/fail status for controls along with aggregate control results. Hereafter, all the different ‘out-of-box’ build/release workflow options from the CICD engine (e.g., VSTS) can be used as ‘next steps’ based on the outcomes of SVTs. (For instance, one can decide whether to fail the release outright or to continue despite failures while sending an email to the build/release owners or to hold progress until someone manually approves, etc. Furthermore, if all SVTs pass in the pre-prod environment, then a release can be ‘promoted’ to prod.)
Outcomes of the SVT execution can also be routed to an OMS workspace configured to receive various events generated by the AzSDK.

The Alerting & Monitoring features of AzSDK empower dev ops teams with the following capabilities:
a single pane of glass view of cloud security across dev ops stages
visibility to control status for their Azure subscription and critical enterprise/application resources
pre-configured search queries for creating alerts to facilitate action on security drift
Out of the box, these capabilities can be leveraged via the Operations Management Suite (OMS) solution in AzSDK.
However, a dev ops team can equally easily leverage a different system for log analytics (e.g., Splunk) and view the AzSDK control evaluation events in the alternate system. This can be accomplished by using via connectors for Event Hubs or Webhooks in the AzSDK.

Make Data-driven Improvements to Security

Overview Security Telemetry

Control Telemetry

Organization Level Setup

Local Control Telemetry

Understanding Data in App Insights

App Insights Visualization

Usage Telemetry

Enable/Disable Usage Telemetry

FAQs

The Secure DevOps Kit generates telemetry events from all stages of dev ops. That is, events are generated when an engineer runs a scan ad hoc or when SVTs are run in CICD or subscriptions are scanned via Continuous Assurance (CA). The telemetry can be collected and aggregated across an organization. When combined with other organization metadata (e.g., a mapping of subscriptions to applications or service lines or business groups), this can yield a powerful platform for supporting a data-driven approach cloud risk governance and allow organizations to drive measured and targeted security improvement initiatives in a continuous and incremental fashion (just like the rest of dev ops). The telemetry data from AzSDK can be leveraged in two key ways:
Application Insights based – called Control Telemetry (will be renamed to Org Telemetry soon). There are two ways possible. One, configure it centrally, two, configure it specifically in end-user’s machine
API based – this is a custom solution using WebAPI and SQL to collect events and enrich it with organizational metadata. This lets an organization track and drive adoption and usage of the AzSDK and provides a window into the org’s DevSecOps Maturity. API based telemetry will be release in coming months when we release documents for how organization can customize AzSDK for their needs

Overview Azure Virtual Datacenter is an approach to making the most of the Azure cloud platform’s capabilities while respecting your existing security and networking policies. When deploying enterprise workloads to the cloud, IT organizations and business units must balance governance with developer agility. Azure Virtual Datacenter provides models to achieve this balance with an emphasis on governance. Deploying workloads to the cloud introduces the need to develop and maintain trust in the cloud to the same degree you trust your existing datacenters. The first model of Azure Virtual Datacenter guidance is designed to bridge that need through a locked-down approach to virtual infrastructures. This approach isn’t for everyone. It’s specifically designed to guide enterprise IT groups in extending their on-premises infrastructure to the Azure public cloud. We call this approach the trusted datacenter extension model. Over time, several other models will be offered, including those that allow secure Internet access directly from a virtual datacenter.

In the Azure Virtual Datacenter model, you can apply isolation policies, make the cloud more like the physical datacenters you know, and achieve the levels of security and trust you need. Four components any enterprise IT team would recognize make it possible: software-defined networking, encryption, identity management, and the Azure platform’s underlying compliance standards and certifications. These four are key to making a virtual datacenter a trusted extension of your existing infrastructure investment. Central to this model is the idea that your cloud infrastructure has isolation boundaries that can be thought of as your corporate namespace. Think of it as your isolated cloud within Azure. Within this virtual boundary, security controls, network policies, and compliance come together, providing you with an IT infrastructure on Azure capable of securely integrating cloud resources with your existing on-premises datacenter. You can deploy new virtual workspaces in the virtual datacenter much as you would deploy additional capacity to your physical datacenter. These virtual workspaces are self-contained

Environments where workloads can run independently, and workload teams can get workspace specific access. Workspaces enable teams to build solutions and manage workloads with great freedom while adhering to the overall access and security policies defined in the central IT infrastructure. This guide is intended for enterprise IT architects and executives. Using the lens of the physical datacenter, the guide discusses an approach to designing secure, trusted virtual datacenters on the Azure platform. Azure Virtual Datacenter is not a specific product or service but rather a way to think about cloud infrastructures. It offers proven practices and guidance to help smooth your migration to the cloud. At the end of this guide, you can learn about the upcoming Virtual Datacenter Automation guidance. This guidance includes a collection of scripts and Azure Resource Manager templates that will help you build an Azure Virtual Datacenter using the trusted extension model.

This package contains a set of symbols/icons to visually represent features of and systems that use Microsoft Cloud and Enterprise technologies, including Windows Server, Microsoft Azure and related technologies. Email CnESymbols@microsoft.com to provide feedback and suggestions.

Data disk drive configuration: All data drives must be of the same type (SAS or SATA) and capacity. If SAS disk drives are used, the disk drives must be attached via a single path (no MPIO, multi-path support is provided)

* RAID controllers without pass-through capability can’t recognize the media type. Such controllers will mark both HDD and SSD as Unspecified. In that case, the SSD will be used as persistent storage instead of caching devices. Therefore, you can deploy the Microsoft Azure Stack POC on those SSDs.

Deploy Azure Stack POC

Before you deploy, prepare the Azure Stack POC machine and make sure it meets the minimum requirements.

Reboot the machine. It will automatically run Windows Setup as the VHD system is prepared.

Configure the BIOS to use Local Time instead of UTC.

Verify that four drives for Azure Stack POC data:

Are visible in disk management

Are not in use

Show as Online, RAW

Verify that the host is not joined to a domain.

Log in using a local account with administrator permissions.

Verify network connectivity to Azure.com.

Important: Only one NIC is allowed during the deployment process. If you want to use a specific NIC, you must disable all the others.

Run the PowerShell deployment script

Open PowerShell as an administrator.

In PowerShell, go to the Azure Stack folder location (\Microsoft Azure Stack POC\ if you used the default).

Run the deploy command:

I’m running the script with Proxy settings.

Deployment starts and the Azure Stack POC domain name is hardcoded as azurestack.local.

At the Enter the password for the built-in administrator prompt, enter a password and then confirm it. This is the password to all the virtual machines. Be sure to record this Service Admin password.

At the Please login to your Azure account in the pop-up Azure authentication page, hit any key to open the Microsoft Azure sign-in dialog box.

Enter the credentials for your Azure Active Directory Account. This user must be the Global Admin in the directory tenant

Back in PowerShell, at the account selection confirmation prompt, enter y. This creates two users and three applications for Azure stack in that directory tenant: an admin user for Azure Stack, a tenant user for the TiP tests, and one application each for the Portal, API, and Monitoring resource providers. In addition to this, the installer adds consents for the Azure PowerShell, XPlat CLI, and Visual Studio to that Directory Tenant.

The deployment process will take a few hours, during which several automated system reboots will occur. Signing in during deployment will automatically launch a PowerShell window that will display deployment progress. The PowerShell window closes after deployment completes.

On the Azure Stack POC machine, sign in as an AzureStack/administrator, open Server Manager, and turn off IE Enhanced Security Configuration for both admins and users.

Double-click the AzureStack.local.rdp desktop icon to open a Remote Desktop Connection to the client virtual machine. This automatically uses the AzureStack\AzureStackUser account that was created by the deployment script. Use the admin password you gave in step 5 of the script process at the Enter the password for the built-in administrator prompt.

Tenants provision, monitor, and manage services that they subscribe to, like Web Apps, storage, and virtual machines. A service administrator can log in as a tenant to test the plans, offers, and subscriptions that their tenants might use. If you don’t already have one, Create a tenant account before you log in.

Log in to the Azure Stack physical machine.

Double-click the AzureStack.local.rdp desktop icon to open a Remote Desktop Connection to the client virtual machine. This automatically uses the AzureStack\AzureStackUser account that was created by the deployment script. Use the admin password you gave in step 5 of the script process at the Enter the password for the built-in administrator prompt.