1. Обзор безопасности в Windows Azure
Василий Ямалетдинов
Архитектор, Artezio

2. Содержание Проблемы безопасности в «облаке» Физическая безопасность
Сети и изоляция
Безопасность приложений
Управление идентификацией пользователей
Безопасность данных

3. Это действительно безопасно?
Вопросы, интересующие руководство:
Насколько это безопасно?
Будут ли мои данные в безопасности?
Могу ли я доверять «облачному» провайдеру?
Сертифицирован ли провайдер по безопасности?
Slide Objective
Explain security concerns customers must consider before deploying applications in the cloud.
Speaking Notes
Is it secure to put sensitive data in the cloud?
Can I trust the cloud provider to supply computing resources as promised?
What is necessary for a cloud application to pass security audits and receive security certifications from well-known security standard organizations?
What happens in case of a disaster?
There is no doubt that taking an application from the company’s data center and deploying it to the cloud raises security concerns.
The cloud is by definition abstract. You do not know exactly where your data is. You cannot “touch” your servers.
Data and computing power may be the company’s most valuable assets. Exporting them to the cloud is not an easy decision to make.

4. Безопасность многомерна
Для обеспечения безопасности должны быть учтены все аспекты :
Человеческий фактор
Как люди обращаются с секретными данными?
Данные
Защита БД, шифрование, разрешения
Приложение
Проектирование с использованием лучших практик
Хост
Защита ОС, регулярное обновление
Slide Objective
Explain how all aspects of security must be taken into consideration. Mitigations must be deployed in every aspect of the SW lifecycle.
Emphasize that security is much more than just a firewall. If any one aspect of security is forgotten, the application can be breached, and there will have been no value to all the other security measures that were taken. It is an all-or-nothing issue.
Speaking Notes
It is possible to divide the security arena into the following domains:
Physical: Who has physical access to the actual server? Who can deploy patches and tools on the server? If a bad guy can access the server and deploy tools on it – He owns the server -> Game over.
Networking: How protected is communication between the server and the application? If a bad guy can sniff the data, execute a man-in-the-middle attack or other networking attack (e.g., DDOS) – He owns the server -> Game over.
Host: How protected and up-to-date is the OS? Security patches provide mitigations for newly discovered security breaches. If the OS is not patched regularly it remains susceptible to these attacks. How isolated is the host? Can one host influence another? If a bad guy owns a neighboring host and can use it to influence your host – He owns the server -> Game over. Does the host contain unnecessary features and tools that can be used by the bad guy to mount an attack? The more tools and features that are installed on the host, the wider the potential attack surface.
Application: How does the application deal with security issues? Only the application knows its business and use cases, thus it is in charge and no one should be able to use its legitimate capabilities to mount an attack. For example: If a bad guy can use the application to access the database – He owns the server -> Game over.
Data: How well-protected is the data against unauthorized access? Is it encrypted? How isolated is the database? If a bad guy can gain access to the data – He owns the server -> Game over.
Human: People must use the application (otherwise it is of no use). Therefore, by design, they must have access to the data and be able to execute use cases. If a bad guy can manipulate people into accessing data or executing malicious use cases – He owns the server -> Game over.
Сеть
Брандмауэры, VLans, защищенные каналы и т.д.
Физический уровень
Контроль доступа к серверам

5. Модель безопасности Platform-as-a-Service
Большинство аспектов безопасности обеспечивается провайдером
Данные
Данные
Потребитель
Приложение
Приложение
Хост
Хост
Потребитель
Microsoft
Сеть
Сеть
Slide Objective
Explain the responsibilities exported to the cloud provider in a PaaS solution.
Explain that the provider takes care of security aspects in the domains under his responsibility (Physical, Network, Host)
The cloud provider also provides technologies that can help mitigate security threats in other security domains (Application, Data)
Speaking Notes
To leverage the benefits of a cloud-based services provider, organizations give up the level of control they have on-premises.
In traditional on-premises applications, organizations have full control over the entire application stack, from the physical environment in which the application is hosted up to how the application data is stored. This allows organizations to implement a defense-in-depth approach, with security controls in every layer of the stack, with no necessary dependencies on any external party.
When moving to a cloud-based platform such as Windows Azure, the organization gives up control over a significant part of the stack to the service provider, in this case Microsoft. Microsoft is now responsible for providing physical-, network-, and host-level security, following the standards implemented by Microsoft for all its customers. In order to be able to provide the gains of scale that are key to the business advantages of cloud-based services, Microsoft and other service providers have to provide their customers with a one-size-fits-all security policy that has little flexibility and no control delegated to them.
In platform-as-a-service (PaaS) services like Windows Azure, the services provider also makes available a standard application environment upon which to run customer applications. While the customer is able to implement its own set of controls in its applications, these will be constrained by the boundaries defined by the PaaS provider for its service.
For many customers, the biggest change when moving to the security model of cloud-based services in general and PaaS platforms in particular is that the service provider has administrative privileges (i.e. full control) over the applications and the data stored in the service. Customers have to ultimately trust the service provider for the overall security of their platform.
Notes
Физический уровень
Физический уровень
Корпоративный ЦОД
Платформа как сервис

6. Безопасность данных: уровни безопасности Windows Azure
TechReady11
9/18/2018
Безопасность данных: уровни безопасности Windows Azure
Подход эшелонированной обороны
Уровень
Защита
Данных
Ключи доступа к хранилищу
Поддержка SSL для обмена данными между участниками
.NET-код запускается с частичным доверием
Учетные записи Windows с минимальными полномочиями
Приложения
Хостинга
Облегченная версия Windows Server 2008 R2
Границы хоста управляются внешним гипервизором
Slide Objective
Explain Microsoft’s defense-in-depth approach to protecting the infrastructure under its control against security threats.
Speaking Notes
To provide a secure platform for its customers and protect against the most prevalent security threats, Microsoft implements the following security controls in the stack:
In the data layer, access to data stored in Windows Azure is controlled using strong storage access keys that are provisioned to the customer. All access to data can (and should) be done over SSL to protect the confidentiality and integrity of the data while in transit over the network.
In the application layer, Windows Azure developers can choose to run their front-end code under Partial Trust, a “sandbox” that blocks access to native (non-.NET) components and helps ensure the integrity of the platform. Customer code can also run under a low-privilege user account.
At the host level, Windows Azure virtual machines run the latest Windows Server 2008 R2 operating system from Microsoft, with the option of using pre-configured virtual machine roles (web and worker). The OS is constantly patched and updated by Microsoft. Virtual machine boundaries are enforced by a underlying hypervisor and do not depend on the security of the VM Windows operating system.
At the network level, all traffic to and from the virtual machines is filtered according to the policy defined by the customer, enforced by the firewall on the virtual machine as well as the firewall running on the host (root) system. Microsoft also deploys VLANs and packet filters to segregate network access between customers, management systems, and the Internet, and uses special devices to protect its infrastructure against distributed denial of service attacks (DDoS).
In the physical layer, Microsoft runs Windows Azure in its own data centers, which implement world-class security controls and information security management systems that have been certified under the international ISO/IEC 27001:2005 standard and the AICPA’s SAS 70 Type II standard.
Сетевой
Брандмауэр хоста ограничивает трафик к VM
VLAN’ы и фильтры пакетов в маршрутизаторах
Физический
Физическая безопасность мирового уровня
ISO и SAS 70 Type II сертификации для процессов ЦОД

7. Центры обработки данных – физическая безопасность
Online Airlift
9/18/2018
Центры обработки данных – физическая безопасность
Безопасность сервисов начинается с ЦОД
Сертифицированы по ISO 27001
Сертифицированы по SAS 70 Type II
Датчики движения
Защищенный доступ 24/7
Системы биометрического доступа
Видеонаблюдение
Системы оповещения
Slide Objective
Describe the physical security of the world-class, ISO/IEC certified data centers upon which Windows Azure runs.
Speaking Notes
Online service environments must meet numerous government-mandated and industry-specific security requirements in addition to their own business-driven specifications. Microsoft’s Operational Services Security and Compliance (OSSC) team works with the operation, product, and service delivery teams as well as with internal and external auditors to ensure compliance with the relevant security industry standards and regulatory obligations.
The physical security of all of Microsoft's data centers is an example of the operational security managed by the OSSC. Policies define the access controls applied to inner and outer perimeters, the levels of automated monitoring applied at the data centers, and the security incident notification procedures in force. Microsoft specifies the security requirements under which data center employees and contractors are reviewed. In addition to contractual stipulations with site staff, OSSC policies define a further layer of security within the data center for the personnel who operate the facility. Access is restricted by applying a least-privilege policy so that only essential personnel are authorized to manage users’ applications and services.
“What’s in it for me?” you might ask.
Physical security is all about who can access your servers, how movements around the servers are tracked, and what can be accomplished if someone does succeed in breaking through. In most companies, data centers are only partially covered by surveillance cameras, so if someone enters the data center you have to be lucky to adequately track his actions. In Windows Azure, data centers are constantly monitored under full video surveillance. Several rings of physical protections are deployed to prevent outsiders from breaking in (fences, motion sensors, and biometric-controlled access to the building). Such security measures are quite rare in the average company.
In the majority of companies, most employees can access servers in the data center (they might have to tell some story to the data center supervisor but eventually they will get in). In Windows Azure data centers this is impossible. Only a very small group of people can access the servers, and these people have had numerous background checks. The security system enforces this state of affairs using state-of-the-art biometrics. The result is that it is virtually impossible for someone unauthorized to gain physical access to the racks or to any physical part of the Windows Azure data center. This usually cannot be said about your average company’s data center.
In the unlikely event that someone did get through and gained physical access to the machines, the question is: What good will it do him?
In normal data centers it can be said that if an intruder gains physical access to the server the game is over. In Windows Azure it is different. The VMs are able to communicate only with other VMs belonging to the same service and with the Internet. This policy was established to prevent different VMs from influencing each other and prevent attacks implemented by legitimate roles deployed to the data center.
When a VM is provisioned, its IP is registered and distributed to all of the service’s VMs. This way the host VM firewall (described later) can filter out unauthorized traffic originating from within the VLAN. To make a long story short, if someone gains physical access to the racks and connects to the internal VLAN, he still cannot communicate with anyone.
These layers of physical security are designed to give you more confidence in Windows Azure data centers than you have in your own servers. This confidence is validated by the physical security certifications given to the Windows Azure data centers. These certifications ensure that the level of security expected from the data center is in fact in place. Microsoft’s cloud infrastructure has SAS 70 Type II certification (which incorporates all the Type I elements as well), as well as ISO/IEC 27001:2005 certification.
The ISO/IEC 27001:2005 certificate validates that Microsoft has implemented the internationally recognized information-security controls defined in this standard.
The SAS 70 certificate illustrates Microsoft’s willingness to open up its internal security programs to outside scrutiny. SAS 70 is an auditing standard designed by the American Institute of Certified Public Accountants (AICPS) to enable an independent auditor to evaluate and issue an opinion on a service provider’s controls. SAS 70 does not specify a pre-determined set of control objectives or control activities that service organizations must achieve; this is covered by ISO/IEC
Note: According to the PCAOB, the body created by the Sarbanes-Oxley Act to oversee the auditors of companies, the SAS 70 Type II report is an acceptable format to assess the operating effectiveness of controls at a service provider’s organization.

8. Встроенные брандмауэры
Трафик Windows Azure проходит через несколько брандмауэров. Некоторые из них могут быть сконфигурированы владельцем сервиса, некоторые управляются фабрикой.
Брандмауэр гостевой VM
Брандмауэр хост-VM
Брандмауэр SQL Azure
Локальные Брандмауэры
Slide Objective
Outline the firewalls relevant to communication with Windows Azure roles
Present networking, the second domain of the security arena.
Describe the strong protection Windows Azure provides over the network infrastructure to the data and compute nodes.
Speaking Notes
The typical Windows Azure application generates traffic that traverses several firewalls:
The Guest VM Firewall. Configured using a service definition file, involves remote administration with Windows Azure Connect or startup tasks.
Host VM firewall. Executes packet filtering.
SQL Azure Firewall.
Local client firewalls.
Windows Azure uses a wide range of technologies to protect network infrastructure.
The compute nodes as well as the data storage nodes run inside a dedicated VLAN inside Windows Azure’s data centers. It is impossible to access a VM running inside the data center from a public internet address.
The fabric controller in charge of provisioning VMs and connecting them to the network is isolated from the compute nodes’ infrastructure. This prevents attacks on the network using the fabric controller.
There are several firewalls controlling the traffic to\from compute nodes.
VMs are deployed in groups of up to 8 VMs per hypervisor. One VM is called the root VM. All VM access to the network and the disk is mediated by the root OS. The Hypervisor’s virtual network switch filters all network traffic to and from the virtual machines, and also prevents sniffer-based attacks against other VMs on the same physical host. Additional filters are in place to block broadcast and multicast traffic, with the exception of what is needed to maintain DHCP leases.
Each role has endpoint definition in its role definition file. The endpoint definition describes which ports are open to the public network and which protocols to use. All other ports are closed.
Each VM has its Windows Server 2008 firewall configured to block almost all protocols (e.g. ping)
It is possible (and recommended) to expose the role using SSL channels.
SSL can be established between two roles and between roles and storage nodes.

9. Различные SSL-каналы Разработчик SSL SSL Клиент SSL SSL SSL Веб-роль
Slide Objective
Outline different SSL channels that can be used within Windows Azure
Speaking Notes
It is possible to establish different SSL channels in Windows Azure.
Clients <-> Web and worker roles
Clients <-> Storage endpoints
Web roles <-> web and worker roles over internal endpoints
Web and worker roles <-> Storage endpoints
The developer registers x.509 certificates in the portal.
Certificates deployed to roles are used to establish SSL channels with the client.
Certificates deployed to the subscription are used to authenticate tools that use the Windows Azure management API. The SSL channel used for management has mutual authentication. Both the customer and Windows Azure must authenticate each other using the other’s party certificate.
All communications between Windows Azure internal components are protected with SSL. In
most cases, the SSL certificates are self-signed. The exceptions are certificates for the
fabric controllers and certificates for connections that can be accessed from outside the
Windows Azure network (including the storage service).
Fabric controllers have certificates issued by a Microsoft CA that chains back to a trusted root
CA. This allows FC public keys to be rolled over easily. Additionally, FC public keys are used by
Microsoft developer tools so that when developers submit new application images they are
encrypted with a FC public key in order to protect any embedded secrets.
Прикладная роль
SSL

10. Гипервизор на основе Hyper-V
Хостинг
Изоляция
Каждая роль запускается на отдельной VM
Защита:
Регулярная установка обновлений безопасности
Облегченная, защищенная версия Windows Server 2008 или R2
Отсутствие постоянного хранилища на compute-узлах
Ограниченное число драйверов
Сетевые подключения ограничены брандмауэром хоста
Веб-роль
Прикл. роль
VM-роль
Slide Objective
Describe the level of security Windows Azure provides in the third domain, host protection. Indicate that hosts are isolated as well as patched.
Speaking Notes
Virtualization is one of the driving technologies behind the ability of cloud services to quickly scale up and down relative to need. Virtualization requires thoughtful management, as formerly “hard” security boundaries between systems become virtualized, and thus potentially subject to new attack vectors.
In the Windows Azure Compute service, a compute node can be configured to have one of the three roles (web, worker or VM), depending on its purpose. Each node runs inside its own virtual machine (VM), which has 1, 2, 4 or 8 virtual CPUs and is allocated up to 14 GB of memory. The VMs run a special version of Windows Server 2008 or Windows Server 2008 R2 that has a specific server OS software installed (IIS, .NET framework, etc.) depending on the role. The software has a very limited number of device drivers.
There is no long-lasting storage on individual compute nodes. Data written to the local disks are not guaranteed to persist across instatiation/de-instatiation of the virtual machines. Any data that requires durability must be stored in the Windows Azure storage services.
Windows Firewall is enabled on each VM. The only ports open and addressable (internally or externally) on a Windows Azure VM are those explicitly defined in the Service Definition file configured by the customer.
Windows Azure uses its own hypervisor, a virtualization layer developed by Microsoft that is built on top of the lessons learned by Hyper-V. It runs directly over the hardware and divides a node into a variable number of virtual machines (VMs). Each node also has a “root” virtual machine, which runs the host operating system on hypervisor-controlled systems. Windows Azure uses a stripped-down version of Windows Server that includes only those components necessary to host VMs, like the Fabric Controller agent. This is done both to improve performance and to reduce the potential attack surface.
A critical boundary is the isolation of the root VM from the guest VMs and the guest VMs from one another. This boundary is 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.
When a customer uses a PaaS environment, the cloud provider (i.e., Microsoft) is responsible for upgrading the VM with the latest security patches.
Гипервизор на основе Hyper-V
Изоляция VM (гипервизор)

11. Приложение
Приложения, работающие в «облаке», должны быть реализованы с применением лучших практик безопасности
Проверка ввода
Аутентификация
Авторизация
Управление конфигурацией
Секретные данные
Управление сессиями
Криптография
Управление параметрами
Управление исключениями
Аудит и журналирование
Slide Objective
Describe the fourth domain of the security arena, application security. Indicate that the application is outside of the cloud provider’s realm of responsibility. The customer is in charge of the application’s security design and implementation.
Speaking Notes
What is application security?
Application security deals with several subjects.
Input validation: Validate all input that crosses trust boundaries. Good validation can mitigate a high percentage of present and future attacks. This validation is usually simple and cheap yet very effective. There are two main strategies used to execute validation: the "White List" and the "Black List". White list validation defines a pattern of valid inputs: all inputs that follow the pattern are allowed, while other inputs are rejected. When such patterns cannot be defined, a black list of bad inputs can be created instead. If such inputs are discovered they are rejected.
Authentication: Identify the user. Almost all web applications need to know who originated the request.
Authorization: Verify the permissions granted to the user and verify that operations can be executed only by those with relevant permissions. If an operation is requested and the user does not have the permissions required, it will be denied.
Configuration Management: Protect sensitive information that may appear in the application’s configuration, such as connection strings or business rules. Application change management (i.e., new versions) is a high-risk process that must be handled with care.
Sensitive data: Identify and map sensitive data to security policies.
Session management: Protect state. (i.e. information saved throughout a session of a business process execution)
Cryptography: Use reliable cryptographic algorithms. Handle encryption keys.
Parameter manipulation: Protect parameter exchange between different modules of the application (e.g., http parameters exchanged between web pages)
Exception management: Sanitize and log all exceptions. Exceptions contain intimate information about the application. Such information is critical to anyone trying to mount an attack, while the end user usually does not want to be exposed to such information.
Auditing and logging: Identify abnormal situations by comparing them to normal application states. If a problem arises, it is important to track it, and without auditing and logging this is impossible. Administrators need to know ASAP if something is going wrong and if the application may be under some sort of attack. For this to occur, abnormal situations must be immediately identifiable. Auditing and logging provides the base information for application state assessment.

12. SDL – Security Development Life Cycle
Продукты Microsoft разработаны в соответствии c процессом SDL
Нормативный и практичный подход
Проактивный – не только поиск уязвимостей
Устранение проблем безопасности на ранних этапах
Предсказуемый результат
Разрабатывайте ваши
приложения с SDL и
защищайте ваших клиентов
Снижайте количество уязвимостей
Снижайте влияние уязвимостей
Conception
Implementation
Secure
Robust
Design
Best Practices and Learning
Product Development
Internal Testing
Beta Testing
Incident Response
Microsoft Security Response Center
Security Review
Final
Verification
Release
Slide Objective
Explain what the SDL is, why Microsoft uses it to secure its products, and why your application should be developed using the SDL.
Speaking Notes
Microsoft uses for Windows Azure the same proven, industry-leading process for developing secure software used successfully in products like Windows 7 and SQL Server.
The Microsoft Security Development Lifecycle (SDL) is a set of processes and tools designed to minimize the number and severity of vulnerabilities in software products. It encompasses education of development personnel, secure development processes, and accountability of individuals and product teams, all for the building of more consistently secure software.
Microsoft’s internal development groups use the SDL to systematically address security threats that may be inherent in their software products. The SDL applies equally to Microsoft online services. Microsoft requires that the SDL be followed for any Microsoft-developed software deployed on Windows Azure. The SDL addresses security threats throughout the development process: through threat modeling during the design process; following development best practices and code security standards during coding; and requiring the use of various tools for testing and verification before deployment. These proactive checks during development make software less vulnerable to potential threats after release, and the SDL provides a structured and consistent methodology through which to apply them. These methodologies, which are supported by an executive commitment to security, have helped Microsoft develop more secure software.

13. Безопасность доступа из кода в Windows Azure
Выполнение неуправляемого кода
Переменные среды
P/Invoke
Доступ к реестру
Доступ к файловой системе
Выполнение без административного доступа
Запрещено
Ограничено
Частичное доверие
Полное доверие
Slide Objective
Describe the full trust level of code access security, and how Windows Azure’s partial trust differs.
Speaking Notes
Full trust:
Default trust model for web, worker, and VM roles
Supports execution of native code
Allows access to environment variables, file system and registry
The Windows Azure partial trust policy is similar to the standard medium trust policy for ASP.NET [Click], but even stricter in some terms. Here are some of the restrictions imposed under the Windows Azure Partial Trust CAS Policy: [Click]
No calls to native code.
No access to native libraries and resources
No access to Windows Azure Diagnostics via the Windows Azure Managed Library.
Read file system access is granted for the application directory and for named local stores. Write and Append access is only granted for named local stores.
No registry access permission.
Access only to the TEMP and TMP environment variables.
No Event log access permission.
Full Trust is required in the following scenarios:
Use of FastCGI or PHP
Migration of traditional web services to the cloud
Role invocation and spawning Windows sub-processes (native code or managed)
Calls into native libraries via P/Invoke
If none of the above is required then use the Windows Azure Partial Trust level. This option minimizes the attack footprint of the role in question.
Notes
Hosting Web and Worker Roles Under Full Trust -
Windows Azure Partial Trust Policy Reference -
Ограничено
Запрещено
Запрещено

14. Аутентификация и авторизация
Windows Azure поддерживает доступ на базе ролей и доступ на базе утверждений
Аутентификация
Технология
Windows
Включение в домен (Azure Connect)
Логин\пароль
Аутентификация на основе форм Asp.Net
Claims-based
Azure AppFabric ACS
Slide Objective
Windows Azure supports several technologies for identity management.
Speaking Notes
There are two main patterns for handling identities: role-based and claims-based.
In role-based identity, the client supplies credentials (e.g., a username and password). The client is authenticated and then mapped to a certain group. Permissions are provided according to group membership.
In claims-based identity, the client supplies credentials to a special service (STS) and is provided with a token containing a collection of claims (pieces of information). The application opens the token, extracts the claims, and uses the information to provide permissions or execute the business process.
Windows Azure supports both role-based and claims-based identities.
Role-based:
Using Windows Azure Connect, it is possible to domain-join roles running on the cloud.
ASP.NET Form Authorization is supported (e.g., membership provider)
Claims-based:
Windows Azure AppFabric Azure Access Control Service (ACS) provides all of the infrastructure required for implementing claims-based authorization and integration with common identity providers.

15. Управление доступом пользователей
Управление доступом пользователей
AppFabric Access Control Services (ACS): единый вход с популярными провайдерами аутентификации
Интеграция с другими системами на основе стандартов WS-* и SAML 2.0
Slide Objective
Describe how claims-based identity makes it possible to work with multiple identity providers.
Speaking Notes
Applications using claims-based identity can be hosted on-premises or in the cloud without changes. Cloud applications are able to use credentials from on-premises AD directory services, other compatible enterprise directories, and even popular Internet identity providers, by leveraging the Windows Azure AppFabric Access Control Service 2.0.
Today, developers face a common challenge: To provide authorized users, clients, and systems with access to the data they require at any time, from any technology, from any location, while meeting basic security requirements for confidentiality, availability and integrity. At first glance, cloud computing technology might seem inappropriate or poorly suited to meet such rigorous standards: Developers seek to restrict access to data that exists in a comparatively uncontrolled environment (the cloud), and that data may be co-mingled with resources that are owned by someone else. These legitimate concerns can be effectively addressed by using claims-based identity.
Claims-based identity, an approach to authentication and access management based on open protocols, is an access-control strategy that is consistently applied across the full range of Microsoft products and services. One of the key properties of claims-based identity is that it reduces infrastructure dependencies because applications protected with claims-based identity can be hosted on-premises or in the cloud without changes. Applications targeting Windows Azure can take advantage of the same developer tools and identity management features and services that are available to their on-premises counterparts.
By supporting industry standards such as WS-Federation and SAML 2.0, applications using Windows Azure AppFabric Access Control Service (ACS) 2.0 can accept identities and claims from major enterprise identity providers such as Active Directory, as well as from popular web identity providers such as Windows Live ID, Google, Yahoo, and Facebook. On the application side, Windows Azure integrates with Windows Identity Foundation (WIF) and tooling so developers can build applications that can be hosted on premises or on the cloud without changes.
With claims-based identity, identity providers (IdPs) trusted by the Windows Azure AppFabric ACS issue signed tokens containing the identity of their authenticated users, as well as “claims” (assertions) about those users. The application, which trusts ACS, then relies on ACS to validate the token and the authenticated state of the user, as well as to map incoming claims from the IdPs to claims useful to the application. This model completely abstracts the workings of the identity provider, allowing applications to be agnostic in terms of which identity provider is used and how it authenticates. It also allows a variety of incoming claims from the various IdPs to be transformed and normalized by ACS into a single set of claims that the application requires. Because the application trusts ACS, and ACS trusts the IdP, the resulting security tokens that arrive at the application (which can use Windows Identity Foundation to make it very easy to deal with these incoming tokens) can be proven cryptographically to contain reliable access control information, which the application then uses as part of its internal logic. This powerful abstraction allows an application to continue to run unchanged even when the surrounding security environment is changing rapidly.
Использование учетных записей Active Directory с использованием федерации
WS-* и SAML
Доступ к корпоративным системам, привязанным к AD
Active Directory
Другие провайдеры
Корпоративный ЦОД

16. Безопасность данных
Данные клиентов хранятся на отдельном оборудовании объединенные в учетные записи хранения
Доступ к данным в учетной записи разрешен только тому, у кого есть секретный ключ данной учетной записи
Политика разграничения доступа может быть назначена бинарным объектам (BLOB), используя Shared Access Signature (SAS)
Slide Objective
Describe how in the fifth domain of the security arena, data protection, Windows Azure provides the necessary technology to protect data persistently through all types of storage (such as Windows Azure Storage, SQL Azure, and AppFabric Cache)
Speaking Notes
Windows Azure Storage services uses strong Storage Access Keys to control access to storage accounts
Windows Azure Storage has a simple access-control model. Each Windows Azure subscription can create one or more storage accounts. Each storage account has a storage account key (SAK) that is used to control access to all data in that storage account. This supports the typical scenario, in which storage is associated with applications and those applications have full control over their associated data. A more sophisticated access-control model can be achieved by creating a custom application front-end for the storage, giving the application the storage Windows Azure Security Overview key, and letting the application authenticate remote users and authorize individual storage requests.
To support periodically changing SAKs without any breaks in service, a storage account can have two secret keys associated with it at the same time (where either key grants full access to all of the data). The sequence for changing the key is of three steps: the new key is first authorized to the storage service, the key used by all applications accessing the service is changed, and the old key is removed from authorization. Changing the set of authorized storage keys associated with an account is done by the customer via the Windows Azure Portal or the Service Management API (SMAPI).
It is recommended that HTTPS appear in the request URL so that storage keys cannot be snooped on the wire.

17. Как управлять доступом к данным?
Модель безопасности бинарных объектов
Ключ учетной записи
Подписывает
Политика доступа к контейнеру
Ссылается на
Shared Access
Signature
Полный доступ
Чтение, Запись, Удаление, Список
Чтение, Запись, Удаление, Список
ACL контейнера
Slide Objective
Summarize blob access control
Speaking Notes
If you have the storage account keys (SAK) you have full control over any information saved in Windows Azure Storage (i.e., blobs, tables, and queues).
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 do this, mark the blob container as public.
Sometimes 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.
Finally, as the owner of the data you want to have the ability to block access to blobs even after Shared Access Signatures have been distributed. If the Shared Access Signatures are associated with Container-Level policy, an additional measure of control is provided, including the ability to revoke the signature if needed.
Публичный? Да/Нет
Бинарные объекты и контейнеры хранилища Windows Azure

18. Безопасность данных: надежность хранилища Windows Azure
Избыточность и хранилище в корпоративном ЦОД
Данные в Windows Azure реплицируются на трех отдельных физических узлах для повышения доступности
Для обеспечения физической безопасности данные реплицируются в различные ЦОДы одного географического расположения.
Приложение
Приложение X
Корпоративный ЦОД клиента
Slide Objective
Describe the benefits granted by data replication, such as reliability and protection against disaster scenarios.
Present the replication policies and synchronization technologies associated with Windows Azure storage solutions.
Speaking Notes
Data stored in Windows Azure storage services is replicated in three physically separate nodes for high availability and to minimize the impact of hardware failures. In case of physical failure affecting one or even two nodes, data is still available from the third one. Customers of Windows Azure can also write customized applications running on Windows Azure compute nodes to extract data from Windows Azure Storage for offsite backups. 
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 can no longer be accessed via the storage APIs. All copies of the deleted data item are then garbage collected. The physical bits will be overwritten when the associated storage block is reused for storing other data.
Физическое хранилище Windows Azure
Клиенты могут создавать собственные приложения для выгрузки данных в свой ЦОД для резервного копирования

19. Шифрование данных в Windows Azure
Шифрование данных возможно только в вашем коде
Приложения должны предоставлять соответствующий ключ для дешифрации данных
В основном применимо для приложений, работающих вне Azure
Windows Azure Storage ?
Шифрованные данные
Шифрованные данные
Slide Objective
Explain the options for data encryption in Windows Azure
Speaking Notes
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 through the development of 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 Microsoft’s data centers help to ensure that attackers cannot gain physical access to the machines running Windows Azure services or to the disks that implement Azure storage. The data destruction policies eliminate the possibility of data becoming inadvertently accessible to other Windows Azure subscribers. Consequently, as long as a service implements an appropriate level of transport security (via SSL), the only feasible way in which an attacker could gain access to the data would be to obtain or steal the details of the Windows Live ID used by the Windows 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 Windows Azure storage from applications running on computers outside of the Windows Azure environment. In this scenario, different users running these applications may need to maintain confidentiality from one 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 Windows Azure storage. The data can be decrypted only by the user providing this key (which can be stored in the user’s 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 browser that attempts to read the encrypted data directly from Windows Azure storage without providing the appropriate key will not be able to decrypt the data.
Notes
Клиентское приложение
- Ключи хранятся локально
Веб-браузер
Нет ключей
Невозможно
расшифровать
данные

20. Итоги
Windows Azure предоставляет широкий спектр решений и технологий безопасности на всех уровнях.
Физическом
Сетевом
Хоста
Приложений и авторизации
Данных
Обычно физическая, сетевая и безопасность хостинга выше именно в «облаке».
Slide Objective
Summarize the security technologies relevant to all security domains provided by Windows Azure.
Speaking Notes
Some aspects of the security solutions provided by the cloud provider are better than those obtainable in an on-premises environment. For example, the physical security of the Windows Azure data centers is likely better than your own. Windows Azure network protection, Host Isolation, and OS hardening are all more secure than that found in traditional hosting. Therefore, hosting your application in the cloud likely improves its security.

21. © 2010 Microsoft Corporation. All rights reserved
© 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows Azure, SQL Azure and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. 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 provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.