Published: 20

th
March 2011


Windows Azure Security Overview

Data Security in the Cloud














Module Manual
Authors: David Tesar


2
The information contained in this document represents the current view of Microsoft Corporation
on the issues discussed as of the date of publication. Because Microsoft must respond to
changing market conditions, it should not be interpreted to be a commitment on the part of
Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the
date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES,
EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the
rights under copyright, no part of this document may be reproduced, stored in or introduced into a
retrieval system, or transmitted in any form or by any means (electronic, mechanical,
photocopying, recording, or otherwise), or for any purpose, without the express written permission
of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.

2011 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, Hyper-V, SQL Azure, Visual Basic, Visual C++, Visual C#, Visual Studio,
Windows, Windows Azure, Windows Live and Windows Server are either registered trademarks or
trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.


3
Contents

Overview .................................................................................................................................... 4
Customer Concerns ................................................................................................................... 4
Azure Storage Architecture ....................................................................................................... 5
Data Protection ......................................................................................................................... 5
Protection Against Data Loss ................................................................................................. 6
Secure communication .......................................................................................................... 6
Isolation ................................................................................................................................. 6
Access Control ....................................................................................................................... 6
Privacy in Microsoft ................................................................................................................... 7
Windows Azure Access Control ................................................................................................. 8
Shared Access Signatures ...................................................................................................... 8
Container Policy ..................................................................................................................... 9
AppFabric Cache Access Control ............................................................................................. 10
SQL Azure Security Model ....................................................................................................... 10
Encryption ............................................................................................................................... 12
Hybrid Applications ................................................................................................................. 14
Conclusion ............................................................................................................................... 14


4
Overview
The security of ones data is one of the most important elements that decision
makers must take under consideration. Data is an extremely valuable asset, and
most customers feel insecure regarding the cloud environment because they do
not know the exact location of their data and exactly how it is protected. This is a
serious barrier for customers considering using the cloud; customers must be
sure that their data is safe and private before entrusting it to a shared storing
infrastructure.

Under the traditional information technology (IT) model, an organization is
accountable for all aspects of its data protection regime, from how it uses
sensitive personal information to how it stores and protects such data stored on
its own computers. Cloud computing changes the paradigm because information
is moved offsite to data centers owned and managed by cloud providers.
Responsibility for the physical hosting and protection of data is taken away from
the customers, yet even though the data physically resides in a cloud providers
data centers cloud customers still own their data and remain ultimately
responsible for controlling its use and protecting the legal rights of individuals
whose information they have gathered.

Microsoft understands its responsibilities concerning customer data. The challenge
of storing and protecting such data is not new to the company; Microsofts on-line
services such as Hotmail and Live Services have hosted customer data since the
launch of the MSN

network in 1994. Today Microsoft is a leader in addressing

the privacy and security issues associated with hosting customer data in the
cloud.

This document describes the privacy, policies, infrastructure, and security
mechanisms designed to protect customer data in Windows Azure.

Customer Concerns
Concerns over information security and privacy top on the list of issues that
customers evaluate before storing their data in the cloud. When speaking to
customers, the following issues will likely be raised:

Is it still my data?
Who gets to see my data?
Do I know if someone looked at my data?
How can I control access to my data?
Where, physically, is my data?
What laws and regulations apply?
Is the integrity of my data assured?
Is my data erased effectively when I delete it?
Where does my responsibility to protect my data end, and where does the
cloud service providers responsibility begin?

These concerns relate overwhelmingly to two subjects: privacy and security. The
subjects deal with different issues, yet they overlap in several areas.

Security issues such as access control and data integrity are handled using
security infrastructures and technologies, such as secure communication,
cryptography and identity management. Privacy issues such as data ownership
and transparency are handled through the enforcement of privacy policies and

5
regulations such as ISO/IEC 27001:2005, and management standards such as
SAS 70 Type II

For both security and privacy, international standards and regulations allow
providers and customers to monitor the level of compliance with and
implementation of the relevant policies. For instance, ISO/IEC 27001 is an
Information Security Management System (ISMS) standard published by the
International Organization for Standardization (ISO) and the International
Electrotechnical Commission (IEC). ISO/IEC 27001 formally outlines a
management system that brings information security under explicit management
control. SAS 70 Type II is an internationally recognized auditing standard that
provides guidance to service auditors when assessing the internal controls of a
service organization and issuing a service auditors report.

Windows Azure utilizes a number of mechanisms in the securing of customer
data, uses Microsofts Global Foundation Services (GFS) group to formulate data
center security and privacy policies. These policies and procedures are enforced
by the Online Services Security and Compliance (OSSC) Information Security
Management System (ISMS).

Microsoft Global Foundation Services (GFS) runs Microsoft's data centers for
Microsoft Online services such as Hotmail and Dynamic CRM. The OSSC team
within GFS is responsible for compliance with ISMS regulations and standards.

For more information about the services GFS provides, visit
http://www.globalfoundationservices.com

For more information about the Microsoft Online Privacy Statement and how it
relates to customer concerns mentioned here, visit:
http://privacy.microsoft.com/en-us/default.mspx

Azure Storage Architecture
Traditional on-premises applications are designed to run on a single server. Data
is stored in memory or persisted to the file system. In the cloud, this architecture
no longer applies. The cloud is made up of a grid of compute nodes load-balanced
by the cloud fabric; consequently, information must be saved in a shared location
that all compute nodes are able to access.

The solution is an independent storage mechanism that provides Storage as a
Service (SaaS) to both cloud applications and on-premises applications. Storage
in Windows Azure is deployed on separate hardware from the compute nodes. To
handle massive data, storage must be scalable and reliable, so multiple layers of
architecture are used. The top layer validates, authenticates, and authorizes
requests, routing them to the partition layer and data layer that actually store the
bits. Security validation is done as soon as possible to prevent malicious resource
consumption.

Data Protection
In Windows Azure there are three major types of data storage: Windows Azure
Storage, SQL Azure, and Azure AppFabric Cache. Each storage type has its own
properties: its own pros and cons and its own typical usage scenario. Yet all three
storage types are designed to protect the data they store. This data protection is
implemented in several domains:

6
Protection Against Data Loss

All data in Azure data stores is replicated three times across multiple physical
computers in the data center. This architecture provides automatic failover and
load balancing.

One node is considered primary, and the others are marked as secondary nodes.
In the case of hardware failure of the primary node, one of the secondary nodes
will take its place and be marked as the primary. Another replication will be
instantly performed to preserve three living replicas at all times.

Customer data is spread across multiple physical servers within the geolocation
specified for the data store. In this way, the data store achieves high availability
and stability for all applications, from the smallest to the largest, without
requiring intensive administrative effort.

If a customer wishes to mitigate major catastrophic events that might disable an
entire data center, it is possible to create different stores in different data centers
and use Microsoft's sync services, such as SQL Data Sync, to synchronize data
between geographic locations.

Secure communication
Communication between roles and storage is secure by default. If desired, it is
possible to require SSL for all communication with all types of storage in the
Windows Azure Platform. Secure communication is however essential when
communicating sensitive information from storage to applications running on-
premises. Storage is independent, so it cannot distinguish between traffic coming
from Windows Azure nodes and traffic originating from the Internet. Channels
inside Windows Azure data centers are considered secure, but channels
originating from the public Internet are untrusted. SSL ensures that all traffic
runs on a secure channel, so configuring storage to accept requests running on
SSL channels provides an important layer of security.

Isolation
Windows Azure prevents interaction between data containers by creating logical
and physical separations. Storage is implemented by a shared infrastructure that
isolates data containers through a number of mechanisms. Each of the different
storage infrastructures provided by the Windows Azure platform contains a
mechanism (implemented as a layer in the multi-layer architecture) responsible
for isolating data containers.

For example, networks are physically and logically isolated. (For more
information, see the networking white paper.) Data containers are provisioned
among customers such that internal data routing ensure logical isolation.

Access Control
All communication with all types of storage must be authenticated and
authorized. The only exception is in the use of public blobs, described later in this
document.


7
Each type of storage has its own access control mechanism. Windows Azure
Storage and Azure AppFabric Cache follow the same principle. The owner of the
store is provided with a secret key. This access key provides full access to the
data; thus it must be protected and handled with care.

SQL Azure implements the traditional SQL Access control model. Initial access is
established using a connection string that contains a user name and a password.
Access to each of the database objects is controlled by the login and Role
mechanisms.

The Windows Azure Storage Access Control mechanisms will be described in
detail later in this document.

Privacy in Microsoft
Since the launch of the Microsoft Network (MSN) in 1995, Microsoft has built and
hosted a wide variety of services:
Familiar consumer-oriented services such as the Windows Live Hotmail
web-based email service and the Bing search engine
Enterprise-oriented services such as the Microsoft Dynamics CRM Online
business software and the Microsoft Business Productivity Online Standard
Suite from Microsoft Online Services
Many behind-the-scenes services that handle online billing and advertising
functions for Microsoft customers.

Microsofts Global Foundation Services (GFS) provides the cloud infrastructure for
these services, with a focus on adherence to numerous regulatory, statutory, and
industry standards. The OSSC team within GFS works with partners and other
teams throughout the company to manage security risks to global online services
at Microsoft in order to fulfill its mission to provide trustworthy, available online
businesses that create a competitive advantage for Microsoft.

All Microsoft data centers are managed according to the following privacy
principles:

Accountability in handling personal information within Microsoft and with
external vendors and partners
Notice to individuals about how we collect, use, retain, and disclose their
personal information
Collection of personal information from individuals only for the purposes
identified in the privacy notice have provided
Choice and consent for individuals regarding how we collect, use, and disclose
their personal information
Use and retention of personal information in accordance with the privacy notice
provide to individuals and the consent that the individuals have provided in return
Disclosure or onward transfer of personal information to vendors and partners
only for purposes that are identified in the privacy notice, and in a secure fashion
Quality assurance steps to ensure that personal information in our records is
accurate for and relevant to the purposes for which it was collected
Access for individuals who want to inquire about and, when appropriate, review
and update personal information they have in our possession
Enhanced security of personal information to help protect against unauthorized
access and use
Monitoring and enforcement of compliance with our privacy policies, both
internally and with our vendors and partners, along with established processes to
address inquiries, complaints, and disputes

8

Microsofts software development teams apply the PD3+C principles, defined in
the Security Development Lifecycle (SDL), throughout the companys
development and operational practices:
Privacy by Design Microsoft uses this principle in multiple ways during the
development, release, and maintenance of applications to ensure that data
collected from customers has a specific purpose and that the customer is
given appropriate notice in order to enable informed decision-making. When
data to be collected is classified as highly sensitive, additional security
measures such as encrypting while in transit, at rest, or both may be taken.
Privacy by Default Microsofts offerings ask customers for permission
before collecting or transferring sensitive data. Once authorized, such data is
protected by means such as access control lists (ACLs) in combination with
identity authentication mechanisms.
Privacy in Deployment Microsoft discloses privacy mechanisms to
organizational customers as appropriate to allow them to establish
appropriate privacy and security policies for their users.
Communications Microsoft actively engages the public through publication
of privacy policies, white papers, and other documentation pertaining to
privacy.

Windows Azure storage is no exception to the policies governing other online
services hosted by Microsoft. The software running Windows Azure was developed
with privacy in mind under the PD3+C principles defined in the SDL.

Windows Azure Access Control
Windows Azure Storage has a simple access-control model. Each Windows Azure
subscription can create one or more storage accounts, and each storage account
has a single secret key, called the Storage Account Key (SAK), that is used to
control access to all data in that storage account. This supports the typical
scenario, under which storage is associated with applications, and these
applications have full Windows Azure Security control over their associated data.
Any application that wants to have access to data in a storage account needs to
have the appropriate SAK.

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.

Storage account keys can be reset using the subscription credentials via the
Windows Azure Portal or SMAPI. To support periodically changing SAKs without
any breaks in service, a Storage Account can have two secret keys associated
with it at one time, where either key grants full access to all of the data. There is
then a three-step sequence for changing the secret key: adding the new one as
authorized to the storage service; change the key used by all applications
accessing the service; and removing the old key so that it will no longer be
authorized.

Shared Access Signatures

The owner of the storage access keys (SAKs) has full control over blobs, tables,
and queues.

9

Customers may want some blobs to be made public. One common scenario is
static data (such as pictures) that needs to be accessible directly from a browser.
To achieve this, the blob container can be marked as public.

Sometimes, however, you want to be able to access your blobs from a browser
without making them publicly accessible to everyone. In this case, a Shared
Access Signature is needed. With the key, you can create a special URL that will
enable access to the blobs even without the storage access keys. This special URL
should be distributed only to customers to whom you want to give access.

The URL for a Shared Access Signature includes additional components that
specify the container or blob to make accessible, the interval over which the
Shared Access Signature is valid, the permissions associated with the signature,
any signed identifiers associated with the request, and the signature itself.

Shared Access Signatures can only be created by the SAK owner because the key
is required to create an HMAC signature. Figure 1 describes the structure of the
Shared Access Signatures URL.











Figure 1

Container Policy

A container-level access policy provides an additional level of control over Shared
Access Signatures on the server side. Establishing a container-level access policy
serves to group Shared Access Signatures and to provide additional restrictions
for signatures that are bound by the policy. You can use a container-level access
policy to change the start time, expiry time, or permissions for a signature, or to
revoke it, even after it has been issued.

A container-level access policy provides greater flexibility in issuing Shared
Access Signatures. Instead of specifying the signature's lifetime and permissions
on the URL, it is possible to specify these parameters within the access policy,
stored as metadata on the container in which the signed resource (container or
blob) resides. For example, to change the lifetime of one or more signatures, one
can simply modify the container-level access policy rather than have to reissue
the signatures. Similarly, Shared Access Signatures cannot be canceled after
being issued, but if a container policy is used it is possible to quickly revoke a
signature by modifying the container-level access policy.

A container-level access policy includes a signed identifier, a value that may be
up to 64 characters long and must be unique within the container. The value of
this signed identifier is specified in the signedidentifier field in the URL of the

10
Shared Access Signature. These policies are created using the Blob Service REST
API, and a maximum of five policies can be associated with a container.

AppFabric Cache Access Control
The Azure AppFabric Cache Security model is simple. The owner of the cache is
provided with a security token (ACS Token) in the cache portal. All cache access
requests must be authenticated.

To create a cache object, a CacheFactory must be created. The CacheFactory is
provided with the key, either in code or by writing it to the configuration file.

All communication with the cache runs over a secure channel established by WCF
message security. The channel is protected by implementing WS-* security
standards.

Figure 2 shows the cache's security token as presented by the management
portal. The portal provides a basic configuration snippet, which contains the key
that has to be inserted into the application's configuration file before using the
cache.


Figure 2

SQL Azure Security Model

SQL Azure is a database in the cloud. It was designed to look as similar as
possible to traditional on-premises SQL databases. The developer and the IT pro
can continue to use their existing knowledge and tools to manage and work with
SQL Azure.

SQL Azure uses the TDS protocol (i.e., port 1433) in exactly the same way as on-
premises databases, so data access technologies like ADO.NET and Entity
Framework can use it transparently. For network administrators, this means that
their environment must be configured to allow outbound TCP connections over
port TCP/1433 to enable applications and tools to connect to SQL Azure.


11
SQL Azure contains a built-in firewall to filter incoming traffic. This firewall is
configured using firewall rules that can be written to the master database or
directly in the management portal, as shown in Figure 3 and Figure 4.

It is also possible to enable or disable connections from Windows Azure by
clicking "Allow other Windows Azure services to access this server" in the firewall
rules configuration, as shown in Figure 3.


Figure 3


Figure 4
SQL Azure provides the same set of security principles that are available in SQL
Server with SQL Server Authentication. You can use these to authorize access
and secure your data:
SQL Server Logins: Authenticate access to SQL Azure at the server level.
Database Users: Grant access to SQL Azure at the database level.
Database Roles: Group users and grant access at the database level.
SQL Azure only supports the standard SQL authentication mechanism, where the
database stores and manages the credentials database for user logins.
Connection to the database is established by presenting a connection string that
contains the credentials of the user trying to connect. Connection strings that
contain clear-text credentials obviously contain sensitive information and must be
protected and handled with care.

SQL Azure does not currently support Windows Integrated authentication.

12

During the provisioning process, SQL Azure creates a login for the customer that
is the server-level principal similar to SA login in SQL Server. This login will have
administrative capabilities in the virtual SQL Server that will be provisioned for
the customer. This account will then be used to create additional user logins for
authentication, as well as database users and roles for authorization.

When connecting to the SQL Azure service, the user will need to provide
credentials required for login. These credentials will be protected using SSL while
in transit (all communication between the SQL Azure database and your
application requires SSL encryption at all times). Connections will be re-
authenticated every 60 minutes, with the user client software resending the
credentials. At this point, any password reset will be enforced for that connection.
For performance reasons, when a password is reset in SQL Azure, the connection
will not be re-authenticated immediately, even if the connection is reset due to
connection pooling. This is different from the behavior of an on-premises SQL
Server.

Encryption

Currently there is no support for native encryption in either Windows Azure
Storage or SQL Azure. Data in Windows Azure Storage is stored as clear text, and
there is no option to encrypt the data other than by developing your own
encryption code. SQL Azure does not currently support the Transparent Data
Encryption (TDE) feature available in Microsoft SQL Server.

For data accessed only by services hosted by Windows Azure, this is not a major
concern. Encrypting data in a hosted service requires that all instances of the
service have access to the encryption keys, and if a service chooses to encrypt
data these keys should be stored in certificates held in the Windows Azure
certificate store. However, the security policies implemented by Microsofts data
centers help ensure that attackers cannot gain physical access to the machines
running Azure services or to the disks that implement Azure storage.
Consequently, the data destruction policies eliminate the possibility of data
becoming inadvertently accessible to other Azure subscribers.

Therefore, as long as a service implements an appropriate level of transport
security (e.g., SSL), the only feasible way in which an attacker could gain access
to the data would be to obtain or steal the details of either the Windows Live ID
used by the Azure subscription or the Management Certificate used to administer
the hosted services. Such an attacker would in any case have access to the
certificate store and therefore the means to decrypt the data, so performing
encryption in this scenario would be of little benefit.

Encryption is valuable if you are accessing data located in Azure storage from
applications running on computers outside of the Azure environment rather than
from services hosted on Azure. In this scenario, different users running these
applications might need to maintain confidentiality from each other. You can
encrypt data within a client application by for instance using a private AES key,
known only to the user, that is generated on a client machine or elsewhere within
the enterprise. The encrypted payload is then uploaded to Azure storage. The
data can be decrypted only by the user providing this key (which can be stored in
the users profile using DPAPI). Other users can generate their own private keys,
and these keys should not be disclosed. A client application, such as a Web

13
browser, that attempts to read the encrypted data directly from Azure storage
without providing the appropriate key will not be able to decrypt the data.




14
Hybrid Applications

There are scenarios under which sensitive data should not be deployed to the
cloud. The most common reasons are laws and regulations prohibiting the use of
data storage in the cloud. The nature of regulation changes slowly, so currently
there are many cases in which local laws are not up-to-date with rapidly evolving
cloud technologies. There are of course other cases, in which custom data
protection infrastructures prevent data from being written to the cloud.

In these cases, Windows Azure Connect allows for a direct and safe connection
between the local data center and the cloud. This enables scenarios in which data
continues to live on-premises but computation is done in the cloud. The main
caveats are of course scalability and performance; local data storage is usually
not designed to work on the same scale as storage in the cloud. Similarly, the
long communication channel between the data store and the computation nodes
will affect performance.


Conclusion
Taking data out of the companys private data center and storing it in the cloud is
never an easy step for decision makers and IT pros to make. Microsoft
understands the importance of information security and privacy and implements
all the steps necessary to ensure that anything stored in its data centers is safe
and private. All storage infrastructures provided by Windows Azure implement
data-protection mechanisms such as access control, secure communication, and
isolation.

Information stored in Microsoft's data center is managed under strict privacy
policies and regulations. Microsoft is committed to keeping your privacy and
protecting your data. Microsoft also keeps close watch on all of the evolving
security standards and regulations in order to continually maintain compliance.

It is not surprising, therefore, that Microsofts cloud infrastructure has obtained
the Federal Information Security Management Act of 2002 (FISMA)s
Authorization to Operate (ATO), which authorizes US government organizations
to store their data in Windows Azure.