Category: Azure Security

Organizational Identity/Microsoft Accounts and Azure Active Directory – Part 2

In Part 1 of this blog we defined some key terms to help us now move into a deeper discussion of how to best integrate Azure Active Directory (AAD), Organizational Identities (OrgIDs), and Microsoft IDs.  We defined Azure subscriptions and AAD tenants, then discussed the different types of administrative access for each entity.  The goal of integrating all of these entities is to manage your Azure subscription(s) using only organizational accounts (as opposed to Microsoft accounts).

Within Part 2 of this blog we focus on specific use cases to accomplish this integration.  We will look at different use cases related to existing Azure and AAD subscriptions to accomplish this.  Each use case describes how to leverage the use of organizational accounts. To bring your Azure subscription under management of ONLY OrgIDs (no Microsoft accounts) follow the tasks outlined in the “Use Cases” section and then perform the following:

  1. Ensure that an organizational account identity which has co-administrator privileges within Azure can log in to the Azure Portal to manage his organization’s users in the environment.
  2. Remove the Microsoft accounts users from the being co-administrators. This may require a support call to move the Azure Service Subscription to a different co-administrator if the Azure Service administrator is a Microsoft account.  In some cases you can also accomplish this from your subscription management UI.


Scope of Use Cases

The goal of these use cases are to bring your Azure subscription under management of ONLY organizational accounts (no Microsoft accounts).  Items such as synchronization of on premise Active Directory to Azure Active Directory or the use of Active Directory Federation Services (ADFS) for single sign-on (SSO) between your on premise environment and your Azure Portal is outside the scope of this document.

Use Cases

  • Case 1 – No existing AAD or Azure subscriptions
  • Case 2 – Existing AAD tenant / no Azure subscription
  • Case 3 – Existing Azure subscription / no AAD tenant
  • Case 4 – Existing Azure subscription and existing AAD tenant


Case 1 – No Azure or AAD Subscriptions

In this situation there are no existing AAD or Azure subscription so we are starting from the beginning with respect to both of these. Here are two options to get started. Once you accomplish either or one of these you can go to one of the other three use cases.

Case 2 – Existing AAD Tenant / No Azure subscription

Your organization has an AAD tenant (that may be associated with an O365 subscription) but does not yet have an Azure subscription. You would like to sign-up for an Azure subscription and allow a select group of users in the AAD tenant to log on to the Azure Portal using their organizational accounts. Once subscribed to Azure your existing AAD tenant will automatically be accessible in the Azure Portal to a specified set of administrators.

An organization can use their OrgID credentials to login to Azure today and sign-up for their Azure trial subscription.

1. Subscribe to Azure by going to

AAD and ID part 2 pic 1

2. Log on using OrgID credentials by selecting the link circled in the above image and then entering your OrgID user id and password.

3. Select the link that is circled below to sign up for Windows Azure

AAD and ID part 2 pic 2

4. Proceed through the sign-up process for your trial Azure subscription.

Key Point – Your AAD tenant will now be accessible automatically within the Azure Portal.

5. Additionally, you can add the OrgIDs (and Microsoft accounts) of the users you want to be co-administrators of your Azure subscription(s).

AAD and ID part 2 pic 3

6. You may want to use the Azure Portal to register applications and/or add organizational accounts to the AAD tenant.  The account(s) used to perform these tasks will need to have Global Administrator privileges for the AAD tenant.

AAD and ID part 2 pic 4

Note: A co-administrator of the Azure Portal is not by themselves a Global Administrator of the AAD tenant.  To administer the AAD tenant the user needs to be assigned the “Global Administrator” organizational role.

Case 3 – Existing Azure Subscription/ No AAD tenant

Your organization used a Microsoft account to set up their Azure subscription and does not have an AAD tenant. You would like to better manage the identities that administer the Azure subscription(s) via the Azure Portal by instantiating an AAD tenant. Since your organization started their Azure subscription(s) using Microsoft accounts, you can log into Azure Portal using the Microsoft account and get an AAD tenant.

Azure allows one AAD tenant per subscription.  So when you create an AAD here you will enter all the OrgIDs you want to be a part of that AAD.  Once an OrgID is part of an AAD, you can then make it a co-administrator in the Azure portal. You can then use that OrgID (instead of the Microsoft account used to originally create the Azure subscription) to log in to Azure and manage the AAD.  If you want to delete the Microsoft account totally you can change this either by calling Azure support or doing it in account settings.

1. Log into Azure portal with Microsoft ID and click on Active Directory.

AAD and ID part 2 pic 5

2. Add new users to the new AAD tenant. Use the OrgIDs of those users you would like to be co-administrators on your Azure subscription(s) and who are maintained in this new AAD tenant.

Note: You could also add Microsoft accounts to administer the AAD tenant. But the goal of this blog post is to get away from Microsoft account and use solely OrgIDs in the AAD tenant and login process.

3. When adding an Azure co-administrator assure that the correct subscription box is selected and the correct email address is entered.

AAD and ID part 2 pic 8

If you would like integrate this Azure subscription with an AAD tenant created using an organizational account (perhaps in conjunction with O365) see the next case (Case 4).


Case 4 – Existing Azure Subscription / Existing AAD tenant

Your organization has an existing AAD tenant that was perhaps obtained via subscription to O365, Intune, CRM, etc.   Your organization also has an existing Azure subscription, but it was created using a Microsoft account.

You would like a select group of users to use their OrgIDs to access the Azure Portal of the Azure subscription created using a Microsoft account. You also want the users to use their organizational accounts for registering applications and services in AAD.

1. Add the Azure account administrator’s Microsoft account to your AAD tenant.

Key PointBy adding an Azure account administrator to your AAD tenant this enables the Azure subscription to query the AAD tenant.

Hopefully the Azure account administrator is the same person as the Service Administrator. How do you tell if this is the case? You can use the Microsoft account in question and log in here with that account.   If you see the target Azure subscriptions listed you have the proper Microsoft account. If you do not see the target subscription or if you see the image below you do not have the proper account.

AAD and ID part 2 pic 9

2. Log into the Azure portal at using an OrgID from your AAD tenant that has Global Administrator rights.

AAD and ID part 2 pic 10

3. Log in using OrgID credentials by selecting the link circled in the above image and then entering your OrgID user id and password. If the AAD Global administrator does not have an Azure subscription, sign up for a free trial Azure subscription.

Note: This step is required so the AAD Global Administrator can access the AAD management interface. This step will be eliminated in the future.

4. Add the Azure account administrator’s Microsoft account (Live ID) to the AAD tenant. Make sure the user name field matches their Microsoft account.

5. If the Azure account administrator and the Azure Service Administrator are not the same then add the Azure Service administrator’s Microsoft Account to the AAD tenant as well.

6. Once the Azure account/Service administrator of the Azure subscription is in the AAD tenant that account can be used within Azure to add an organizational account from the AAD tenant to be a co-administrator on the Azure subscription.


In Part 2 of this blog we looked at four different combinations of how to use OrgIDs within both AAD and Azure subscriptions.   There are various combinations you may have of existing Azure and AAD subscriptions that need to be handled slightly differently.

User User Experience in Azure Portal
Organizational account, Global   Administrator Sees AAD and can manage it
Organizational account, not Global   Administrator Does not see AAD in Azure portal
Microsoft account, Global Administrator Sees AAD  and   can manage it
Microsoft account, not a member of a   directory Sees UX to create a directory

The key to all this is the Account Administrator (AA) for your Azure subscription.  That is the user that needs to be added to the AAD tenant so that tenant can be queried and is visible in the Azure AAD portal. Once the Account Administrator is part of the AAD tenant the Service Administrator (SA) can add other OrgIDs as Co-Administrators (CAs) to the Azure portal.  The SA and CAs can then add OrgIDs to the AAD tenant in the Azure portal.

Best practices would suggest that the eventual owner of an Azure subscription should be the entity that is assigned/owns the Azure Account/Service Administrator role. For example, if an Azure development or test subscription is created for an organization it is highly recommended that the Azure Service Administrator role be assigned to an organizational account and not a Microsoft account. This will make the management of Co-Administrators within the subscription much easier during the life-cycle of the Azure subscription.  You can also allow administrators from your AAD tenant to administer and manage your organizations users within Azure.

Here are some key links you can use to help you manage all this.

The preferred flow of this process is to obtain an Azure subscription, an AAD tenant, and an organizational account at  The end result of all this is that you can now use your organization’s AAD OrgIDs to log in and manage your Azure subscription and no longer need to use Microsoft IDs.

This is part 1 of a 2 part series on the synergy between O365 Organizational IDs, Microsoft Accounts, and Azure Active Directory. In this first post we lay the groundwork with terms and key points. In the second part we show how to use and leverage these concepts in unison with each other.

A Microsoft account is the new name for what was previously called a “Windows Live ID.” Your Microsoft account is the combination of an email address and a password that you use to sign in to services like Hotmail, Messenger, SkyDrive, Windows Phone, Xbox LIVE, or If you use an email address and password to sign in to these or other Microsoft services, you already have a Microsoft account. Examples of a Microsoft account may be or and can be managed here: Once you log in you can manage your personal account information including security, billing, notifications, etc.


An Organizational Identity (aka OrgID) is a user’s identity stored in Azure Active Directory (AAD). O365 users automatically have an OrgID as AAD is the underlying directory service for O365. An example of an organizational account might be

Why Two Different Identities?

A person’s Microsoft account is used by services generally considered consumer oriented. The user of a Microsoft account is responsible of the management (i.e. password resets) of the account.

A person’s Organizational Identity is managed by their organization in that organization’s AAD tenant. The identities in the AAD tenant be synchronized with the identities maintained in the organization’s on-premise identity store (i.e. on-premise Active Directory).  If an organization subscribes to Office 365, CRM Online, or Intune, user organizational accounts for these services are maintained in AAD.

AAD and ID Pyramids

Tenants and Subscriptions

AAD tenants are cloud-based directory service instances and are only indirectly related to Azure subscriptions through identities. That is identities can belong to an AAD tenant and identities can be co-administrator(s) of Azure subscription. There is no direct relationship between the Azure subscription and the AAD tenant except the fact that they might share user identities. An example of an AAD tenant may be An identity in this AAD tenant the same as a user’s OrgID.

Azure subscriptions are different than AAD tenants. Azure subscriptions have co-administrator(s) whose permissions are not related to permissions in an AAD tenant. An Azure subscription can include a number of Azure services and are managed using the Azure Portal. An AAD tenant can be one of those services managed using the Azure Portal.

Many Types of Administrators

Once you understand the types of accounts, tenants, and subscriptions, it makes sense to discuss the many types of administrators within AAD and Azure.

Admins in AAD

An AAD Global Administrator is an administrator role for an AAD tenant.

  • If integration of duties across Azure and AAD is desired an AAD Global Administrator will require assignment as a co-administrator to an Azure subscription to manage. This allows that Global Admin to manage their Azure subscription as well as the AAD tenant.
  • If the desire is separation of duties those that manage the organization’s production Azure subscription are separate from those that manage the AAD tenant.   Create a new Azure subscription and only add AAD Global Administrators as Azure co-administrators. This will provide an AAD management portal while separating the two different administration functions – Azure production versus AAD production. In the near future the Azure Portal will provide more granular management capabilities eliminating the need for an additional Azure subscription for separation of duties.

Admins in Azure

Depending upon the subscription model there are many types of Admins in Azure.

Azure co-administrator is an administrator role for an Azure subscription(s). An Azure co-administrator will require Global Administrator privileges (granted in their AAD’s organizational account) to manage the AAD tenant as well as the Azure subscription.

Azure Service administrator is a special administrator role for an Azure subscription(s) who is assigned the subscription. This user cannot be removed as an Azure administrator until they are unassigned from the Azure subscription.

Azure account administrator/owner monitors usage and manages billings through the Windows Azure Account Center. A Windows Azure subscription has two aspects:

  1. The Windows Azure account, through which resource usage is reported and services are billed. Each account is identified by a Windows Live ID or corporate email account, and is associated with at least one subscription.
  2. The subscription itself, which governs access to and use of Windows Azure subscribed service. The subscription holder uses the Management Portal to manage services.

The account and the subscription can be managed by the same individual or by different individuals or groups. In a corporate enrollment, an account owner might create multiple subscriptions to give members of the technical staff access to services. Because resource usage within an account billing is reported for each subscription, an organization can use subscriptions to track expenses for projects, departments, regional offices, and so forth. In this scenario, the account owner uses the Windows Live ID associated with the account to log into the Windows Azure Account Center, but does not have access to the Management Portal unless they create a subscription for themselves.

Further information about Azure administrator roles can be found here:

In Part 2 of this post (upcoming) we will examine the different use cases for AAD and Azure with respect to administrative access and the ability to authenticate and provide permissions to your directory and Cloud resources.

With the General Availability (GA) release of Windows Azure Infrastructure as a Service (IaaS) a very powerful Identity Access Management (IAM) architecture is now available.   It brings a simplification to the authentication process for users of Office 365 whose companies utilize an Active Directory deployment for their organizational IAM process.

By leveraging the total cost of ownership advantages of Windows Azure Virtual Machines, or “VMs” (as part of Azure’s IaaS offering) companies can now host their Active Directory deployment in the Cloud in an inexpensive, scalable, and highly-available manner.   This includes their Active Directory Domain Controller (ADDC), and one or more IaaS VM servers running Active Directory Federation Services (ADFS) and ADFS Proxy Services (ADPS).  With the exception of the ADDC, the ADFS and ADPS servers can all be placed into a server farm.  Windows Azure provides “free of cost and hassle” dynamic round-robin load balanced functionality for its VMs.  Additionally through the concept of Azure IaaS availability sets, automatic failover is provided for VMs sharing a common endpoint. This provides not only a scalable architecture but a highly-available one as well.

For unified integration of AD domain accounts with Office 365 the AD deployment utilizes the Directory Synchronization (DirSync) tool.  This is run on a regularly scheduled basis to synchronize your email-enabled user objects from within your ADDC with managed accounts in Office 365. This maps licensed functionality for users to application capabilities within Office 365.

Through seamless integration with Office 365, the Active Directory deployment can subsequently federate identity management for Office 365 users.  Via the power of identity federation users within your organization log into Office 365 using their organizations credentials. They don’t have to create and maintain as separate set of credentials unique to their Office 365 account.   This offers a very powerful single sign on (SSO) experience for your users using a sole consistent identity principal.

In the following diagram you can see how at a high level the identity flows through the federation process.


  1. User goes to Office 365 and enters their email address which contains a domain.  Since you have already configured Office 365 to federate identity for that domain Office 365 redirects the user to the ADPS login screen for that domain.
  2. ADPS accepts the users login ID and password.
  3. ADPS lives within a DMZ and communicates with ADFS through a secure HTTPS channel. ADFS communicates with ADDC to authenticate the user.
  4. The claims-based SAML authentication token is sent back to Office 365 and the user is authenticated.

At that point Office 365 looks at its internal account for that user’s managed account to see what applications that user is licensed to use> Based upon that Office 365 makes application access permissions decisions. The user is allowed to use only those Office 365 applications to which they are licensed.

Alternative architectures are possible to take into account an existing ADDC on-premise.   By configuring an Azure IaaS Virtual Network (VNET) and connecting it through a VPN device to an on-premise network, an existing ADDC can remain on-premise while all the other parts of the AD deployment (ADFS, ADPS, and DirSync) can run in Azure IaaS VMs.

The power of identity federation exists through Office 365 and Active Directory integration.  It is now available in a scalable, inexpensive, and highly-available manner through Windows Azure IaaS.

Learned something interesting today about how Azure handles federation for an Azure Web Role. I thought Web.config was no longer applicable for Azure Web applications now that  ServiceConfig.cscfg exists. I was wrong.

In the Azure Portal I configured an Access Control Service (ACS) namespace along with Identity Providers, Rules,  and Relying Party for my Azure Web application.  In Visual Studio for my Azure ASP.NET Web role I chose “Add STS Reference” to invoke the Federation Utility Wizard. Went through all the dialogs to successfully link my app to the ACS Namespace I had created.  Opened up the ServiceConfiguration.cscfg file to view the changes made by the wizard —  and there was none. Snooping around I opened up Web.config and found a number of entries written by the Federation Utility Wizard.  I thought the ServiceConfiguration.cscfg file was to replace Web.config for Azure-only applications. So how would these become visible to the ServiceConfiguration.cscfg  file? How would my Azure application make use of these settings in the Web.config file?

Here’s how it works.  Federation support in ServiceConfiguration.cscfg  file is not implemented as of yet. For now, Azure will use the entries in Web.config to manage federation of an application using ACS.  If you need to change values in Web.config relating to federation after the Azure Web app has been deployed without having to repackage and redeploy, here is a tip on how to do that.

Duplicate the settings found in Web.config in ServiceConfiguration.cscfg. (Note you also have to duplicate those in the ServiceDefinition.csdef for them to be able to be valid in the cscfg file).  In the OnStart method when your Azure Web role first loads have code to read the federation elements from the ServiceConfiguration.cscfg.  That code can then in turn write those values out to their matching elements in the Web.config file.  The Web.config file handles the actual federation not the  ServiceConfig.cscfg file. The role of the ServiceConfig.cscfg relating to Web.config in this case is to act as a conduit in case federation values need to be changed in the Web.config file of a deployed Azure Web application. This can be done by uploading an updated ServiceConfig.cscfg file in the Azure portal without redeploying the entire application.

While putting a slide deck together for some customers I pulled info for a number of sources, added some of my own info, and created a good flow. I decided to then take the deck and the supporting notes pages I had used and put it into a blog post. Rather long, and it duplicates info found in other documents (see links at the end).  I like the way the deck blended it all together so thought you might  want to see it in text form and simplfied down to key points.  Enjoy!


One of the common fears I hear from companies who are hesitant to move to the Cloud is the terror of their data not being 100% under their control living within the walls of their own private data center servers.   I can understand those feelings.   And a few of these fears may be well-founded in some situations due to regulatory requirements. If legally you are required to keep your data on premise, stored in a certain format, keep it from being transferred through certain geographic areas, or stored away from certain other data (for instance, can’t store data for different companies in the same database) then storing your data in the Cloud is probably not for you.

However, that does not mean the Cloud as a whole is not for you.  With the advent of Virtual Networks with the new IaaS feature of Windows Azure, and the technology of Azure Connect, you may be able to run your application in the Cloud keeping your data on-premise. Or you can move your non-critical data to the Cloud and leave the important data on-premise.

Microsoft has invested a significant amount of planning and technologies into securing a customer’s data and access within Azure. Here I will try my best to answer some common discussions and concerns that customers often ask about Azure, such as:

  • How can I ensure my data remains private?
  • Can Azure prevent non-authorized calls into my code?
  • Do I need to encrypt my data for Azure?
  • What about multi-tenant operations and protecting shared data?
  • Are calls between Azure and customer, and internal to Azure, secure?
  • How is my data backed up?
  • When data is deleted logically can I ensure it is also done physically?
  • What about regulatory data requirements?

Access Security

Access control for Hosted Services and Storage Accounts is governed by the subscription. The ability to authenticate with the Live ID associated with the subscription grants full control to all of the Hosted Services and Storage Accounts within that subscription.  Administrators can create Co-Administrators who then have access to all the services in that subscription.

Customers upload developed applications and manage their Hosted Services and Storage Accounts through the Windows Azure Portal web site or programmatically through the Service Management API (SMAPI). Customers access the Windows Azure Portal through a web browser or access SMAPI through standalone command line tools, either programmatically or using Visual Studio.

SMAPI authentication is based on a user-generated public/private key pair and self-signed certificate registered through the Windows Azure Portal. The certificate is then used to authenticate subsequent access to SMAPI. SMAPI queues requests to the Windows Azure Fabric which then provisions, initializes, and manages the required application. Customers can monitor and manage their applications via the Portal or programmatically through SMAPI using the same authentication mechanism.

Access to Windows Azure storage is governed by a storage account key (SAK) that is associated with each Storage Account. A more sophisticated access control model can be achieved by creating a custom application “front end” to the storage, giving the application the storage key, and letting the application authenticate remote users and even authorize individual storage requests.

Window Azure VM Protection

Windows Azure creates a virtual machine (VM) for each role instance, then runs the role in one of 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 guest agents (GA) within guest operating systems on customer VMs. FAs also manage storage nodes. The collection of Windows Azure hypervisor, root OS/FA, and customer VMs/GAs comprises a compute node.

After a compute node is booted, it starts the fabric agent (FA) and awaits connections and commands from the fabric controller (FC). The FC connects to the newly booted node using SSL, authenticating bi-directionally via SSL as described previously. FC communication with FAs is via one-way push, making it difficult to attack those higher in the chain of command because they cannot make direct requests to those components. Combined with the many mechanisms described above, these features help maintain the Fabric in a safe and clean state for customers.

All of these layers of VM management and the fact it is hardened makes it much very tough for anyone to gain unauthorized access.

Confidentiality of Windows Azure Customer Data

Confidentiality ensures that a customer’s data is only accessible by authorized entities. Windows Azure provides confidentiality via the following mechanisms. I will discuss each of them in subsequent sections.

  1. Identity and Access Management – Ensures that only properly authenticated entities are allowed access.
  2. Isolation – Minimizes interaction with data by keeping appropriate containers logically or physically separate.
  3. Encryption – Used internally within Windows Azure for protecting control channels and is provided optionally for customers who need rigorous data protection capabilities.
  4. Deletion of extraneous customer data – Removed and cleaned up when no longer needed
  5. Integrity of customer data – Fabric VM and tightly controlled access to virtual hard drive where the only way to the data is through Fabric
  6. Service Operations –  Data center personnel and processes along with enhanced network Security


1.    Azure Identity Access Management

Credential and key management are critical components of the security design and implementation of Windows Azure. Azure uses them to ensure only authenticated users get access to Azure resources.

Running applications with “least privilege” is widely regarded as an information security best practice. To align with the principle of least privilege, customers are not granted 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). This reduces the potential impact and increases the necessary sophistication of any attack, requiring privilege elevation in addition to other exploits. It also protects the customer’s service from attack by its own end users.

All communications between Windows Azure internal components are protected with SSL. In most cases, the SSL certificates are self-signed.

2.    Isolation of Key Components

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. The hypervisor/root OS pairing leverages Microsoft’s decades of operating system security experience, as well as more recent learning from Microsoft’s Hyper-V, to provide strong isolation of guest VMs.

As the central orchestrator of much of the Windows Azure Fabric, significant controls are in place to mitigate threats to fabric controllers, especially from potentially compromised FAs within customer applications. Communication from FC to FA is unidirectional – the FA implements an SSL-protected service that is accessed from the FC and replies to requests only. It cannot initiate connections to the FC or other privileged internal nodes. The FC strongly parses all responses as though they were untrusted communications. In addition, the FCs and devices incapable of implementing SSL are on separate VLANs. This limits exposure of their authentication interfaces to a compromised node that hosts VMs.

The hypervisor and the root OS provide network packet filters to ensure 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. Customer access to VMs is limited by packet filtering at edge load balancers and at the root OS. In particular, remote debugging, remote Terminal Services, or remote access to VM file shares is not permitted by default.

VLANs are used to isolate the FCs and other devices. VLANs partition a network such that no communication is possible between VLANs without passing through a router, which prevents a compromised node from faking traffic from outside its VLAN except to other nodes on its VLAN. It also cannot eavesdrop on traffic that is not to or from its VLANs.

3.    Encryption of Data and Communications

Encryption of data in storage and in transit can be used by customers within Windows Azure to align with best practices for ensuring confidentiality and integrity of data. As noted previously, critical internal communications are protected using SSL encryption. At the customer’s option, the Windows Azure SDK extends the core .NET libraries to allow developers to integrate the .NET Cryptographic Service Providers (CSPs) within Windows Azure. Developers familiar with .NET CSPs can easily implement encryption, hashing, and key management functionality for stored or transmitted data.

4.    Deletion of Customer 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. All storage operations including delete are designed to be instantly consistent. Successful execution of a delete operation removes all references to the associated data item and it cannot be accessed via the storage APIs. All copies of the deleted data item are then garbage collected. The physical bits are overwritten when the associated storage block is reused for storing other data, as is typical with standard computer hard drives.

5.    Integrity of Customer Data

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 with most current patches.

• The E: drive contains an image constructed by the FC based on the package provided by customer.

• The C: drive contains configuration information, paging files, and other storage.

The D: and E: virtual drives are effectively read-only because their ACLs are set to disallow write access from customer processes. Since the operating system may need to update those read-only volumes, they are implemented as VHDs with delta files. The initial VHDs for all role instances in an application generally start out identical. The delta drive for the D: drive is discarded any time Windows Azure patches the VHD containing the OS. The delta drive for the E: drive is discarded any time the VHD is updated with a new application image. This design strictly preserves the integrity of the underlying operating system and customer applications.

The configuration file is stored on the read/write C: drive specifying the connectivity requirements of all roles in the application. The FC takes the subset of that configuration file appropriate for each role and places it in the C: drive for each role instance. If the customer updates the configuration file while the role instances are running, the fabric controller (FC) – through the fabric agent (FA) – contacts the guest agent (GA) running in the VM’s guest OS and instruct it to update the configuration file on the C: drive. It can then signal the customer’s application to re-read the configuration file. Only authorized customers accessing their Hosted Services via the Widows Azure Portal or SMAPI (as described earlier) can change the configuration file. So, by the inherent design of Windows Azure, the integrity of the customer configuration is protected, maintained, and persisted constantly during an application’s lifetime. As for Windows Azure Storage, integrity is dictated by applications using the simple access control model described earlier. 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.

As for Windows Azure Storage, integrity is dictated by applications using the simple access control model described earlier. 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.

6.    Secure Service Operations

Microsoft deploys combinations of preventive, detective and reactive controls including the following mechanisms to help protect against unauthorized developer and/or administrative activity. They keep  tight access controls on sensitive data, and combinations of controls that greatly enhance independent detection of malicious activity.  Additionally, Microsoft conducts background verification checks of certain operations personnel, and limits access to applications, systems, and network infrastructure in proportion to the level of background verification.

Each datacenter facility has a minimum of two sources of electrical power, including a power generation capability for extended off-grid operation.

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

The 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. The configuration and administration of network devices such as switches, routers, and load balancers is performed only by authorized Microsoft operations personnel, and generally only at major changes (such as when the data center itself is reconfigured). The virtualization provided by the Windows Azure Fabric makes such changes practically invisible to customers. Furthermore, any hardware that does not implement adequate communications security features (such as SSL) is administered over a separate LAN that is isolated from nodes that are exposed to the Internet, or customer access.

Business and Regulatory Requirements

The importance of business and regulatory compliance has increased dramatically with the proliferation of global standards including ISO 27001, Safe Harbor and many others. In many cases, failure to comply with these standards can have a dramatic impact on organizations, up to and including catastrophic financial penalties and damage to reputation. Any of the previously discussed threats can have an impact on compliance, but there are also threats that are directly related to failure to adhere to recognized practices, provide representation of compliance to independent auditors, support e-discovery, and otherwise facilitate reasonable efforts by customers to verify alignment with regulatory, legal, and Windows Azure Security Overview Microsoft 19 contractual requirements. Microsoft provides customers with the information they need to decide whether it is possible to comply with the laws and regulations to which they are subject within the context of Windows Azure and the tools to demonstrate that compliance when it is possible. Some of the ways Windows Azure assists customers with compliance are discussed below.

ISO 27001 Certification

Trusted third-party certification provides a well-established mechanism for demonstrating protection of customer data without giving excessive access to teams of independent auditors that may threaten the integrity of the overall platform. Windows Azure operates in the Microsoft Global Foundation Services (GFS) infrastructure, portions of which are ISO27001-certified. ISO27001 is recognized worldwide as one of the premiere international information security management standards. Windows Azure is in the process of evaluating further industry certifications. In addition to the internationally recognized ISO27001 standard, Microsoft Corporation is a signatory to Safe Harbor and is committed to fulfill all of its obligations under the Safe Harbor Framework. While responsibility for compliance with laws, regulations, and industry requirements remains with Windows Azure customers, Microsoft remains committed to helping customers achieve compliance through the features described above.

One of the key challenges inherent to Windows Azure is balancing compliance requirements against one of the key economic drivers behind cloud services: segmenting customer data and processing across multiple systems, geographies, and regulatory jurisdictions. Windows Azure addresses this challenge in a very simple way: customers choose where their data is stored. Data in Windows Azure is stored in Microsoft datacenters around the world based on the geo-location properties specified by the customer using the Windows Azure Portal. This provides a convenient way to minimize compliance risk by actively selecting the geographic locations in which regulated data will reside.


Windows Azure provides many mechanisms for protecting customer access and data.  Subscriptions manage access to Azure resources. Azure storage uses keys to protect access to the data stored in those entities.  Windows Azure VMs provide special hardened instances with the Windows Azure Hypervisor with many virtual layers to protect access much better than a physical server VMs are protected from each other by the Hypervisor. Confidentiality of Azure customer data is accomplished through Identity Access Management protection and runs applications with the least amount of privilege to prevent damage from occurring. Encryption of key communication is protected via SSL encryption.  Deletion management of customer data prevents it from being accessible after it has been removed. The read-only structure of the D and E virtual drives protect their contents from intrusion.  Tight controls and regulatory compliance on their personnel and data center off a level of physical protection not found in most companies.  Data stored in Window Azure are in most cases safer and more secure than it is within the walls of an on-premise system or database.



Helpful Links

  • Microsoft’s Global Foundation Services Security – Responsible for delivering the trustworthy, available operations environment that underlies Windows Azure

  • Windows Azure Trust Center – For concerns/questions on Azure security

  • Security Best Practices For Developing Windows Azure Applications