1. Сетевая безопасность в «облаке»
Василий Ямалетдинов
Архитектор,Artezio

2. Содержание Сетевая архитектура Фильтрация пакетов
Встроенные брандмауэры
Azure Connect
SSL
Безопасность уровня WCF

3. Архитектура ЦОД … … … … ОсновнойVLAN Маршрутизаторы Узлы Узлы Узлы
Агрегирующие маршрутизаторы и балансировщики нагрузки
ОсновнойVLAN
Agg
Agg
Agg
Agg LB LB LB LB LB LB LB LB
Top of Rack
коммутаторы
Slide Objective
The data center is designed for scale and security.
Speaking Notes
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,
and it also cannot eavesdrop on traffic that is not to or from its VLANs.
There are three VLANs in each cluster:
• The main VLAN – interconnects untrusted customer nodes
• The FC VLAN – contains trusted FCs and supporting systems
• The device VLAN – contains trusted network and other infrastructure devices
Communication is permitted from the FC VLAN to the main VLAN, but cannot be initiated from
the main VLAN to the FC VLAN. Communication is also blocked from the main VLAN to the
device VLAN. This assures that even if a node running customer code is compromised, it cannot
attack nodes on either the FC or device VLANs.).
TOR
TOR
TOR
TOR
TOR
TOR
TOR
TOR
TOR
TOR
TOR
TOR … … … …
Стойки
Узлы
Узлы
Узлы
Узлы
Узлы
Узлы
Узлы
Узлы
Узлы
Узлы
Узлы
Узлы
PDU
PDU
PDU
PDU
PDU
PDU
PDU
PDU
PDU
PDU
PDU
PDU
Power Distribution Units

4. Изоляция сетей Сетевая инфраструктура Azure состоит трех VLAN:
VLAN FC  - содержит доверенные узлы FC и вспомогательных систем
VLAN устройств – доверенная сеть и другие устройства инфраструктуры

5. Коммуникации внутри ЦОД
Сетевая безопасность Azure была спроектирована не только для защиты инфраструктуры от атак извне, но также изнутри.
Брандмауэр корневой ВМ обеспечивает невозможность подмены IP-адреса внутри ЦОД.
Внутренние IP-адреса являются доверенными, так что нет необходимости использовать IPsec между узлами внутри ЦОД.
Гипервизор отвечает за разграничение сетевых ресурсов между ВМ и предотвращает DOS-атаки.
Slide Objective
The data center was designed to mitigate external attacks as well as internal attacks originating from legitimate roles.
Speaking Notes
The hypervisor and the root OS provide network packet filters that assure that the untrusted VMs cannot generate spoofed traffic, cannot receive traffic not addressed to them, cannot direct traffic to protected infrastructure endpoints, and cannot send or receive inappropriate broadcast traffic.
Storage nodes run only Windows Azure-provided code and configuration, and access control is thus narrowly tailored to permit legitimate customer, application, and administrative access only.
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; Microsoft plans to permit customers to enable these protocols as an explicit option in the future. Microsoft allows customers to specify whether any connections are accepted from the Internet and from role instances within the same application.
Connections between role instances of different applications are considered to be Internet connections. Connectivity rules are cumulative; for example, if role instances A and B belong to different applications, A can open a connection to B only if A can open connections to the Internet and B can accept connections from the Internet.
The fabric controller translates the list of roles into a list of role instances, and from that to a list of IP addresses. This list of IP addresses is used by the FA to program the packet filters to only allow intra-application communication to those IP addresses. Roles are allowed to initiate communication to Internet addresses. This enables them to communicate with the Internet and send traffic to any other role with visibility from the Internet via their VIPs

6. Гипервизор на основе Hyper-V
Фильтрация пакетов
Трафик проходит через брандмауэры гостевых ВМ и корневые брандмауэры.
Весь доступ к диску фильтруется «корневой» виртуальной машиной.
Сетевые подключения ограничиваются брандмауэром хоста.
Фильтрация пакетов всего трафика
Агент FC следит, чтобы ВМ имела доступ только к IP- адресам ВМ того же сервиса.
А также к адресам в Интернет
Guest VM
Guest VM
Guest VM
Guest VM
Guest VM
Guest VM
Guest VM
Root VM
Slide Objective
Outline packet filtering performed on all traffic to VMs
Speaking Notes
In the Azure Compute Services nodes the customer applications run inside virtual machines (VMs).
Each virtual machine 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 that has specific server OS software installed (IIS, .NET framework, etc.) depending on the VM role, and has a very limited number of device drivers.
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.
The hypervisor 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 run the host operating system on hypervisor controlled systems. Azure uses a stripped down version of Windows Server that includes only those components necessary to host VMs. This is done both to improve performance and to reduce attack surface.
All access to network and disk by the VMs is mediated by the root OS. [Click]
The Hypervisor’s virtual network switch filters all network traffic from and to 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.
Гипервизор на основе Hyper-V
Hypervisor
Network/Disk

7. Встроенные брандмауэры
Трафик Windows Azure проходит через несколько брандмауэров. Некоторые из них могут быть сконфигурированы владельцем сервиса, некоторые управляются фабрикой.
Брандмауэр гостевой ВМ
Брандмауэр ВМ хоста
Брандмауэр 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.

8. Конфигурирование брандмауэров
Файл описания сервиса содержит описание входных портов, которые «слушает» роль
Slide Objective
Describe how to limit access by configuring endpoints for Web and worker roles
Speaking Notes
Windows Firewall is enabled on each VM in addition to enhanced VM switch packet filtering, which blocks unauthorized traffic.
The only ports open and addressable (internally or externally) for incoming network traffic on a Windows Azure VM are endpoints explicitly defined in the Service Definition file.
The Azure Service Definition File defines both external and internal endpoints:
An external endpoint can receive incoming traffic from the Internet.
A Web role may have no more than one HTTP endpoint and one HTTPS endpoint. A worker role may have any number of HTTP, HTTPS, or TCP (non-HTTP) endpoints.
An internal endpoint is available only to other role instances running within the service; it is not available to clients outside the service.
A Web role may have a single HTTP internal endpoint. A worker role may have any number of HTTP or TCP internal endpoints.

9. Конфигурирование брандмауэров
Свойства роли в Visual Studio
Файл описания сервиса (csdef)
Slide Objective
Describe how to configure the VM Firewall using Visual Studio
Speaking Notes
This slide demonstrates how to configure an Input Endpoint (exposed to the internet) that will listen on tcp port 1234 (as drawn in the previous slide)
The result is an endpoint definition in the service definition file (csdef)
It is possible to define Internal endpoints which are only visible to the roles of the same service within the data center.
The public port is the port number exposed to the outside world.
The private port is the port that will be used inside the data center after the load balancer.

10. Брандмауэр SQL Azure Разграничение доступа по IP-адресам
Возможность включать/отключать доступ из приложений, находящихся в Windows Azure
Internet
Slide Objective
Describe SQL Azure Firewall
Speaking Notes
Outgoing TCP port 1433 must be allowed by on-premises firewall
Source IP address needs to be authorized in SQL Azure firewall
The SQL Azure service is only available through TCP port To access a SQL Azure database from the customer premises, ensure that the customer firewall allows outgoing TCP communication on TCP port SQl Azure also has an integrated firewall that allows the customer to control which IP addresses are allowed to have access to the service, and the customer should configure it before connecting to the SQL Azure server for the first time. You will need to create a firewall setting that enables connection attempts from your computer or Windows Azure.
Rather than using a REST API like the other Azure storage services, SQL Azure is accessed via Tabular Data Stream (TDS), the same protocol used by Microsoft SQL Server (operating over port TCP/1433). To help protect the data, the SQL Azure firewall prevents all access to your SQL Azure server until you specify which computers have permission. The firewall grants access based on the originating IP address of each request.
Initially, all access to your SQL Azure server is blocked by the SQL Azure firewall; connection attempts originating from the Internet or Windows Azure will not be able to reach your SQL Azure server. In order to begin using your SQL Azure server, you must go to the SQL Azure Portal and specify one or more firewall settings that enable access to your SQL Azure server. Use the firewall settings to specify which IP address ranges from the Internet are allowed, and whether or not Windows Azure applications can attempt to connect to your SQL Azure server.

11. Azure Connect
Безопасное сетевое подключение между локальной сетью и «облаком»
Поддерживает стандартные IP-протоколы
Использует IPsec для безопасности соединений
Обеспечивает доступ гибридных приложений к локальным серверам
Обеспечивает удаленное администрирование приложений Windows Azure
Windows Azure
Slide Objective
Azure connect establish a secure channel between Azure roles and on-premise nodes.
Speaking Notes
Windows Azure is introducing Windows Azure Connect, a standards-based service to enable end-to-end secure communications between Windows Azure Compute nodes and on-premise systems.
Windows Azure Connect is a new Windows Azure service currently in CTP that allows secure network for Windows Azure roles. Windows Azure Connect, you can use a simple user interface to configure IPsec protected connections between computers or virtual machines (VMs) in your organization’s network, and roles running in Windows Azure. After you configure these connections, role instances in Windows Azure use IP addressing like that of your other networked resources, rather than having to use some form of external virtual IP addressing.

12. Защищенные каналы Azure Connect
Для защиты трафика используется транспортный режим IPsec
Аутентификация по умолчанию с использованием сертификатов
Шифрование и целостность канального уровня
Трафик прозрачен для сервиса Connect Relay
IPv6 с транспортным режимом IPsec
IPv6 с транспортным режимом IPsec
SSTP (HTTPS Encapsulation)
Интернет
Slide Objective
Azure Connect channels are secure.
Speaking Notes
Windows Azure Connect uses IPsec to protect the traffic between local endpoints and Windows Azure roles. Connect uses IPsec transport mode to create an end-to-end secure channel between the hosts, performing mutual authentication using certificates, authorizing incoming connections according to the defined network policy, and then signing and encrypting all traffic on the wire. By signing and encrypting traffic, IPsec ensures that the traffic is opaque to the Relay service and is not subject to man-in-the-middle (MITM) attacks.
Локальный сервер
Windows Azure Connect Relay
Роли Windows Azure

13. Настройки брандмауэра
В Windows Azure Connect вы полностью управляете настройками брандмауэра ВМ
Настраивайте исключения для программ или портов необходимые вашим приложениям или инструментам
Используйте удаленный доступ к рабочему столу или стартовые задачи
Пример: Ping (ICMP)
Slide Objective
Describe manual firewall configuration settings
Speaking Notes
After Azure connect connection is established you might want to ping the role VM, open a share and load files and tools etc.
By default the local VM firewall will block such attempts.
For example: To enable ping you will have to configure the VM’s firewall manually using the command provided here.
netsh advfirewall firewall add rule name="ICMPv6" dir=in action=allow enable=yes protocol=icmpv6

14. Различные 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

15. Зачем используется SSL
Причины
Тип канала
Бизнес-активности могут содержать секретные данные. Предотвращает атаки «Man In The Middle»
Клиент – Роль
Windows Azure и разработчик выполняют взаимную аутентификацию. Обеспечивает администрирование вне портала.
Администрирование
SAS предоставляет доступ пользователям у которых есть url. SSL предотвращает просмотр данных посторонними лицами.
Клиент – бинарный объект
Защищает передаваемую информацию (TDS по SSL).
База данных обычно содержит секретную информацию
Клиент - SQL Azure
Не дает особых преимуществ, поскольку канал доверенный.
Роль - Хранилище
Slide Objective
Summarize: When to use SSL.
Speaking Notes
Client to role: Like any web application it is recommended to use SSL.
Administration: It is required to use SSL with mutual authentication.
Client to blobs: It is recommended to protect data accessed using Shared access signatures. Other blobs accessible from the client (e.g. browser) are probably public so SSL might not be required.
Client to SQL Azure: Connection is established on TDS port over SSL. Data protection is recommended.
Roles to storage. It is possible to require SSL but the channel is protected by infrastructure so there is no much benifite.

16. Каналы SSL : Клиент<-> Роль
Рекомендуется использовать SSL для всех коммуникаций с ролью в Windows Azure.
SSL использует сертификаты X.509, загруженные в хранилище сертификатов роли.
SSL определяется в файле описания сервиса (csdef)
<Endpoints>
  <InputEndpoint name="ServiceEndPoint" protocol="https" port="443" certificate="localhost" />
</Endpoints>
<Certificates>
  <Certificate name=“certSubject“ storeLocation="LocalMachine" storeName="My" />
</Certificates>

17. Установка каналов SSL с хранилищем
<ConfigurationSettings>
  <Setting name="StorageConnectionString“ value="DefaultEndpointsProtocol=https; AccountName=MyAccount;AccountKey=MyKey"/>   
</ConfigurationSettings>
Настраивайте строку подключения к SQL Azure с требованием использовать SSL
Use of SSL is specified in the Services Configuration File (.cscfg, covered in the next module of the workshop) in the DataConnectionString setting:
DefaultEndpointsProtocol can be set to https to use SSL when connecting to the Azure Storage account.
SQL Azure forces SSL encryption with all client connections and hence data is secured over the wire. When defining the connection string to SQL Azure, developers should use the following parameters:
Encrypt=True specifies that SSL must be used in the connection.
TrustServerCertificate specifies whether encryption occurs if there is no verifiable server certificate. Setting the value to False forces the client to verify the validity of the certificate presented by SQL Azure.
<connectionStrings>
    <add name="MySqlAzureDB"
         connectionString="Server=tcp:ServerName.database.windows.net;
         Database=Pubs;User
         Encrypt=True;TrustServerCertificate=False"/>
</connectionStrings>

18. SSL-канал управления
Для выполнения задач управления с использованием Management API или инструментов (Visual Studio) должны использоваться каналы SSL.
Клиент должен загрузить сертификат с открытым ключом на портал, чтобы оба участника обмена могли аутентифицировать друг друга.

19. Безопасность WCF WCF – это инфраструктура электронного взаимодействия.
Модель безопасности WCF поддерживается в Windows Azure.
Транспортная безопасность: каналы SSL
Безопасность уровня сообщений: WS-*
Аутентификация на базе логин/пароль, сертификатов X.509 или WS-Federation (STS)
Безопасность на уровне сообщений WCF обеспечивает защищенный канал.
Защищенный канал

20. Итоги
Узлы Azure защищены сетевой инфраструктурой ЦОД и несколькими уровнями брандмауэров.
Узлы Azure могут устанавливать соединение внутри ЦОД только с узлами того же серсиса.
Каналы SSL могут использоваться для управления ролями и подключения к сервисам Azure.
Коммуникации с хранилищем также могут быть защищены SSL.
Azure Connect VLAN защищен IPsec.
Модель безопасности WCF полностью поддерживается.

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.