In Windows Azure Security Best Practices — Part 1: The Challenges, Defense in Depth, I described the threat landscape and introduces the plan for your application to employ defense in depth.
In this part, I explain that security with Windows Azure is a shared responsibility, and Windows Azure provides your application with security features than you may have employed in your on premises application. But then, it also exposes other vulnerabilities that you should consider. And in the end, you should be proactive in your application development to secure your application.
This section is meant to provide an overview of what Windows Azure provides. For more in depth information, see Global Foundation Services Online Security. The Global Foundation Services team delivers trustworthy, available online services that create a competitive advantage for you and for Microsoft’s Windows Azure.
The intent of this series is to provide a context for you to learn more and empower you to write great applications for the public cloud.
How Does Windows Azure Help Secure the Host?
You may well be saying, “Not so fast Bruce. How does Windows Azure help secure the host?”
Windows Azure Security Overview provides a comprehensive look at the security available with Windows Azure. Written by Charlie Kaufman and Ramanathan Venkatapathy. The paper examines the security functionality available from the perspectives of the customer and Microsoft operations, discusses the people and processes that help make Windows Azure more secure, and provides a brief discussion about compliance. I’ll summarize the features, and recommend you read and understand the Overview for an in-depth understanding.
Windows Azure is designed to abstract much of the infrastructure that typically underlies applications (servers, operating systems, web & database software, and so on) so you can focus on building applications.
From the outside looking in, you see cloud-based compute and storage, for you to build and manage applications and their associated configurations. Each of the ways into Windows Azure can require some level of authorization that you are in control of.
And I’ll describe some best practices that you should do for the authentication mechanisms in a later post.
Windows Azure must provide confidentiality, integrity, and availability of customer data, just like any other application hosting platform. It must also provide transparent accountability to allow you and their agents to track administration of applications and infrastructure, by yourself, and by Microsoft.
Based on the number of role instances specified by customers, Windows Azure creates a virtual machine (VM) for each role instance, then runs the role in those VMs. These VMs in turn run on a hypervisor that’s specifically designed for use in the cloud (the Windows Azure Hypervisor).
One VM is special: it runs a hardened operating system called the root OS that hosts a fabric agent (FA). FAs are used in turn to manage your application and storage nodes. FAs are managed by a fabric controller (FC), which exists outside of compute and storage nodes (compute and storage clusters are managed by separate FCs).
Ten Things to Know About Azure Security
Windows Azure must provide confidentiality, integrity, and availability of customer data, just like any other application hosting platform. It must also provide transparent accountability to allow customers and their agents to track administration of applications and infrastructure, by themselves and by Microsoft.
The blog post 10 Things to know about Azure Security provides a good summary of many of these features:
- SSL Mutual Authentication for Internal Control Traffic. All communications between Windows Azure internal components are protected with SSL.
- Certificate and Private Key Management. To lower the risk of exposing certificates and private keys to developers and administrators, they are installed via a separate mechanism than the code that uses them.
- Least Privilege Customer Software. You and other customers do not have administrative access to their VMs, and customer software in Windows Azure is restricted to running under a low-privilege account by default (in future versions, customers may select different privilege models at their option).
- Access Control in Windows Azure Storage. Each Storage Account has a single secret key that is used to control access to all data in that Storage Account. This supports the typical scenario where storage is associated with applications and those applications have full control over their associated data.
- Isolation of Hypervisor, Root OS, and Guest VMs. A critical boundary is the isolation of the root VM from the guest VMs and the guest VMs from one another, managed by the hypervisor and the root OS.
- Isolation of Fabric Controllers. As the central orchestrator of much the Windows Azure Fabric, significant controls are in place to mitigate threats to fabric controllers, especially from potentially compromised FAs within customer applications.
- Packet Filtering. The hypervisor and the root OS provide network packet filters that assure that the untrusted VMs cannot generate spoofed traffic, cannot receive traffic not addressed to them, cannot direct traffic to protected infrastructure endpoints, and cannot send or receive inappropriate broadcast traffic.
- VLAN Isolation. VLANs are used to isolate the FCs and other devices.
- Isolation of Customer Access. The systems managing access to customer environments (the Windows Azure Portal, SMAPI, and so on) are isolated within a Windows Azure application operated by Microsoft.
- Deletion of Data. Where appropriate, confidentiality should persist beyond the useful lifecycle of data. Windows Azure’s Storage subsystem makes customer data unavailable once delete operations are called.
IMPORTANT: The strongest security controls available are no protection against an attacker who gains unauthorized access to credentials or keys. Thus, credential and key management are critical components of the security design and implementation of Windows Azure.
Customers seeking to outsource their data compute and storage workloads to Windows Azure obviously expect it to be protected from unauthorized changes. The details are explained in the Windows Azure Security Overview. But I wanted to highlight some of the key points here.
The primary mechanism of integrity protection for customer data lies within the Fabric VM design itself. Each VM is connected to three local Virtual Hard Drives (VHDs).
• The D: drive contains one of several versions of the Guest OS, kept up-to-date with relevant patches, selectable by the customer.
• The E: drive contains an image constructed by the FC based on the package provided by the customer.
• The C: drive contains configuration information, paging files, and other storage.
OS and Application Integrity. The D: and E: virtual drives are effectively read-only because their ACLs are set to disallow write
access from customer processes. This design strictly preserves the integrity of the underlying operating system and customer applications.
Configuration Integrity. Only authorized customers accessing their Hosted Services via the Windows Azure Portal or SMAPI can change the configuration file. Internal processes explained in the Security Overview integrity of the customer configuration is protected, maintained, and persisted constantly during an application’s lifetime.
Storage. Each Storage Account has two storage account keys that are used to control access to all data in that Storage Account, and thus access to the storage keys provide full control over the associated data.
Fabric. The integrity of the Fabric itself is carefully managed from bootstrap through operation.
One of the main advantages provided by cloud platforms is robust availability based on extensive redundancy achieved with virtualization technology.
Replicated data. Data is replicated within Windows Azure to three separate nodes within the Fabric to minimize the impact of hardware failures.
Geographically distributed data. Customers can leverage the geographically distributed nature of the Windows Azure infrastructure by creating a second Storage Account to provide hot-failover capability. You can replicate and synchronize data between Microsoft facilities. Customers may also write customized roles to extract data from storage for offsite private backups.
The guest agents (GAs) on every VM monitor the health of the VM.
Because cloud computing platforms are effectively an outsourced computing environment, they have to be able to demonstrate safe operation to customers and their designated agents on a regular basis. Windows Azure implements multiple levels of monitoring, logging, and reporting to provide this visibility to customers. Primarily, the monitoring agent (MA) gathers monitoring and diagnostic log information from many places including the FC and the root OS and writes it to log files. It eventually pushes a digested subset of the information into a pre-configured Windows Azure Storage Account. In addition, the Monitoring Data analysis Service (MDS) is a
freestanding service that reads various monitoring and diagnostic log data and summarizes/digests the information, writing it to an integrated log.
Service Operations. Windows Azure developers and administrators have, by design, been given sufficient privileges to carry out their assigned duties to operate and evolve the service. As noted throughout this document, Microsoft deploys combinations of preventive, detective and reactive controls including the following mechanisms to help protect against unauthorized developer and/or
- Tight access control to sensitive data
- Combinations of controls that greatly enhance independent detection of malicious
- Multiple levels of monitoring, logging, and reporting
Security Response. Microsoft security vulnerabilities can be reported to the Microsoft Security Response Center or via email to email@example.com. Microsoft follows a consistent process to assess and respond to vulnerabilities and incidents reported via the standard facilities.
Network. Windows Azure internal network is isolated by strong filtering of traffic to and from other networks. This provides a “backplane” for internal network traffic that is high speed and at low risk from malicious activity generally.
Physical Security. A system cannot be more secure than the physical platform on which it runs. Windows Azure runs in geographically distributed Microsoft facilities, sharing space and utilities with other Microsoft Online Services. Each facility is designed to run 24 x 7 and employs various measures to help protect operations from power failure, physical intrusion, and network outages. These data centers comply with industry standards for physical security and reliability and they are managed, monitored, and administered by Microsoft operations personnel. They are designed for “lights out” operation.
Trusted third-party certification provides a well-established way to demonstrate how we protect customer data without giving excessive access to teams of independent auditors that may threaten the integrity of the overall platform.
The Online Services Security and Compliance (OSSC) Information Security Management System (ISMS) uses the ISO/IEC 27001:2005 Information technology — Security techniques — Information security management systems — Requirements (ISO/IEC 27001:2005) as its basis because it provided a well-established framework for integrating risk evaluation into the daily operations of running a cloud infrastructure. (For a copy of this standard, see http://www.iso.org.)
Windows Azure has obtained ISO 27001 certification for its core services following a successful audit by the British Standards Institute (BSI). You can view details of the ISO certificate here, which lists the scope as:
The Information Security Management System for Microsoft Windows Azure including development, operations and support for the compute, storage (XStore), virtual network and virtual machine services, in accordance with Windows Azure ISMS statement of applicability dated September 28, 2011. The ISMS meets the criteria of ISO/IEC 27001:2005 ISMS requirements Standard.
The ISO certification covers the following Windows Azure features:
- Compute (includes Web and Worker roles)
- Storage (includes Blobs, Queues, and Tables)
- Virtual Machine (includes the VM role)
- Virtual Network (includes Traffic Manager and Connect)
Included in the above are Windows Azure service management features and the Windows Azure Management Portal, as well as the information management systems used to monitor, operate, and update these services.
Microsoft’s Global Foundation Services division has a separate ISO 27001 certification for the data centers in which Windows Azure is hosted.
The Microsoft Compliance Framework for Online Services (Compliance Framework) was developed by OSSC to address this need. The Compliance Framework includes a standard methodology for defining compliance domains, determining which objectives apply to a given team or asset, and capturing how domain control objectives are addressed in sufficient detail as they apply to a given set of regulations or requirements.
Microsoft’s is committed to Microsoft’s Compliance Framework for Online Services. The link explains the Compliance Framework in more detail, and provides examples of how to develop compliance domains and to apply control objectives to them in the context of specific industry standards or regulatory requirements. The OSSC team within the GFS division builds on the same security principles and processes Microsoft has developed through years of experience managing security risks.
Microsoft Corporation is a signatory to Safe Harbor and is committed to fulfill all of its obligations under the Safe Harbor
You choose where their data is stored. You can segment customer data and processing across multiple systems, geographies, and regulatory jurisdictions.
Data in Microsoft datacenters around the world based on the geo-location properties that you specify when you create the storage in Azure Portal. You minimize compliance risk by actively selecting the geographic locations in which regulated data will reside.
- Windows Azure Achieves IS0 27001 Certification from the British Standards Institute
- Information Security Management System for Microsoft Cloud Infrastructure
- Windows Azure™ Security Overview
- Security Best Practices for Developing Windows Azure Applications.
- Microsoft’s Compliance Framework for Online Services.
- Webcast: Online Services Security and Compliance: Microsoft’s Compliance Framework for Online Services.
- Whiteboard Session: Online Services Security and Compliance: Microsoft’s Compliance Framework for Online Services.
Windows Azure Security Best Practices – Part 3: Identifying Your Security Frame. This post explores how you can examine your application and identify attack surfaces. The idea of a Security Frame is a way to look at your application to determine treats and your responses, before you even begin coding. I point you to checklists that you can use when you are architecting your application.
Here are links to the articles in this series:
- Windows Azure Security Best Practices — Part 1: The Challenges, Defense in Depth.
- Windows Azure Security Best Practices – Part 3: Identifying Your Security Frame.
- Windows Azure Security Best Practices – Part 4: What Else You Need to Do.
- Windows Azure Security Best Practices – Part 5: Claims-Based Identity, Single Sign On.
- Windows Azure Security Best Practices – Part 6: How Azure Services Extends Your App Security.
- Windows Azure Security Best Practices – Part 7: Tips, Tools, Coding Best Practices.
Bruce D. Kyle
ISV Architect Evangelist | Microsoft Corporation
Special thanks to Charlie Kaufman and Ramanathan Venkatapathy.