Windows Azure. Безопасность. Часть 1

Облачная платформа – это высоко-масштабируемая, отказоустойчивая и надежная среда для размещения приложений и предоставления их в виде сервисов. Пользователи ожидают, что облачная платформа также обеспечивает должные уровни безопасности, как для приложений, так и для данных. Вопросы, связанные с безопасностью, приватностью, надежностью, контролем над средой и т.п. являются одними из самых популярных практически во всех обсуждениях, связанных с использованием облачной платформы.

Само понятие безопасности включает множество различных аспектов – к ним можно отнести такие области, как физическая безопасность, сетевая безопасность, безопасность среды выполнения сервисов, безопасность на уровне приложений и безопасность данных. Для того, чтобы облачная платформа могла отвечать ожиданиям пользователей, все эти аспекты должны быть учтены и должны быть реализованы соответствующие механизмы обеспечения безопасности.

Платформа Windows Azure – высоко-масштабируемая, отказоустойчивая облачная платформа Microsoft для создания и размещения приложений и данных и предоставления их в виде сервисов. Ниже мы узнаем, как Windows Azure реализует различные механизмы для обеспечения максимальной безопасности для приложений и данных.

Что такое безопасность?

Безопасность – это состояние системы, при котором действие внешних и внутренних факторов не приводит к ухудшению ее характеристик или невозможности ее функционирования. Нужно понимать, что абсолютной безопасности не существует, но учет всех возможных аспектов поможет сделать систему максимально надежной и безопасной. В случае «облачной» платформы безопасность можно разделить на следующие категории:

• Физическая безопасность – кто имеет доступ к серверам, кто отвечает за развертывание операционных систем и их обновлений
• Сетевая безопасность – насколько защищены коммуникации между сервером и приложением
• Безопасность среды выполнения – насколько защищена операционная система и как часто она обновляется, насколько изолирована среда выполнения одного приложения от другого, есть ли влияние одной среды на другую
• Безопасность на уровне приложений – насколько безопасны сами приложения и механизмы доступа к сервисам
• Безопасность данных – насколько защищены данные, поддерживается ли шифрование, насколько изолированы базы данных
• Организационная безопасность – как реализован доступ к приложениям и данным

 

Модели предоставления сервисов

Как известно, облачные платформы можно разделить на три основных категории (или модели предоставления сервисов):

• Инфраструктуракаксервис (Infrastructure as a Service, IaaS)
  • Поставщик сервисов предоставляет виртуальные машины, в которых пользователи устанавливают и выполняют приложения практически так же, как и в собственной локальной инфраструктуре
• Платформакаксервис (Platform as a Service, PaaS)
  • Поставщик сервисов предоставляет среду для создания и размещения приложений и данных и предоставления их в виде сервисов
• Приложениякаксервис (Software as a Service, SaaS)
  • Поставщик сервисов предоставляет приложения, выполняемые в его инфраструктуре и используемые для выполнения пользовательских задач

При традиционном расположении приложений в локальной инфраструктуре вся ответственность за их доступность, надежность и безопасность ложится на плечи владельца приложений. В модели IaaS поставщик сервисов отвечает за физическую инфраструктуру, но начиная с операционной системы и «выше» ответственность переносится на владельца программного обеспечения. В модели PaaS владелец программного обеспечения отвечает только за него, а в модели SaaS, пользователь только потребляет предоставляемые ему приложения – за все отвечает поставщик сервисов. Разница в границах ответственности при использовании каждой из перечисленных выше моделей использования программного обеспечения показана ниже.

Платформа Windows Azure является классическим примером модели «Платформа как сервис». В данной модели Microsoft отвечает за все аспекты безопасности за исключением безопасности самих приложений, предоставляя в распоряжение пользователей и разработчиков безопасную среду выполнения, безопасности на уровне операционной системы и инфраструктуры. Ниже мы рассмотрим эти вопросы более подробно.

Устройство Windows Azure

Прежде чем перейти к деталям реализации различных уровней безопасности, используемых в Windows Azure, давайте кратко напомним о том, как устроена сама платформа – с точки зрения потребителей и с точки зрения ряда внутренних компонентов.

Windows Azure с точки зрения потребителей

Windows Azure обеспечивает абстракцию практически всей инфраструктуры, требуемой для выполнения приложений – серверов, операционной системы, и т.п. позволяя разработчикам сосредоточиться на создании приложений. Ниже мы рассмотрим, как Windows Azure выглядит с точки зрения потребителей (т.е. физических или юридических лиц, оплативших использование ресурсов Windows Azure).

Рис. Ключевые компоненты Windows Azure

Как показано на иллюстрации, Windows Azure обеспечивает две основные функции – вычислительные сервисы и сервисы хранения. На базе этих сервисов потребители создают приложения, которые управляются через конфигурации. Управление вычислительными сервисами и сервисами хранения происходит через подписки. Подписка – это данные новой или существующей учетной записи и данные о кредитной карте, занесенные на портал управления подписками. Последующее использование подписки происходит через Windows LiveID (https://login.live.com).

Подписка может содержать сервисы и учетные записи хранилища. Сервис содержит одно или более приложений, развертывание может содержать одну или более ролей, а роль может быть представлена одним или более экземплярами. Учетные записи хранилища содержат бинарные объекты, таблицы и очереди, а также специальный тип бинарного объекта – Windows Azure Drive. Контроль доступа к сервисам и учетным записям хранилища управляется на уровне подписки. Аутентификация через LiveID, ассоциированным с подпиской представляет полный доступ к сервисам и учетным записям хранилища в рамках данной подписки.

Потребители загружают разработанные приложения и управляют сервисами и учетными записями хранилища через портал Windows Azure (http://windows.azure.com, подробнее про портал см. «Знакомимся с порталом Windows Azure») или через программные интерфейсы Service Management API (подробнее см. «Создание приложения, использующего Windows Azure Management API»). Доступ к порталу осуществляется через браузер, а программное управление – либо через специальные утилиты, входящие в состав Windows Azure SDK, либо из Visual Studio.

Аутентификация на уровне программных интерфейсов Service Management API осуществляется через пару public key /private key и сертификат, зарегистрированный через портал Windows Azure. Сертификат служит для аутентификации последующего доступа через Service Management API. Service Management API создает запросы к Windows Azure Fabric – компоненту Windows Azure, который отвечает за выделение ресурсов, инициализацию и управление приложениями. Потребители могут управлять приложениями и следить за ними либо через портал, либо через Service Management API, используя те же самые механизмы аутентификации.

Доступ к хранилищу Windows Azure осуществляется на основе ключа учетной записи хранилища (Storage Account Key, SAK), который ассоциирован с каждой учетной записью хранилища. Ключи создаются и обновляются на портале Windows Azure или через Service Management API.

Завершая эту вводную часть, перечислим основные механизмы аутентификации, используемые в Windows Azure.

Windows Azure с точки внутренних компонентов

Выше мы рассмотрели основные компоненты Windows Azure, «видимые» на уровне потребителей. На следующей иллюстрации показан ряд внутренних компонентов Windows Azure, назначение которых мы обсудим ниже.

Как мы уже отметили, потребители могут управлять рядом характеристик компонента Fabric, но основная задача Windows Azure – абстрагировать управление виртуальной инфраструктурой таким образом, чтобы она представала перед потребителями в виде набора масштабируемых ресурсов. Другими словами, Microsoft управляет виртуальной инфраструктурой, а задача разработчиков – использовать предоставляемые сервисы для создания приложений, выполняемых в этой инфраструктуре.

Рис. Компоненты Windows Azure и их взаимодействие

В зависимости от числа экземпляров ролей, указанных потребителями, Windows Azure создает виртуальные машины для каждого экземпляра роли, затем запускает код роли в этих машинах. Эти виртуальные машины работают под управлением гипервизора (Windows Azure Hypervisor), специально разработанного для облачной платформы. Одна из виртуальных машин имеет специальное назначение – в ней выполняется т.н. «корневая» операционная система, в которой работает Fabric Agent – специальный компонент, управляющий гостевыми агентами (Guest Agents), которые работают в гостевых операционных системах, расположенных в виртуальных машинах. Fabric Agent также управляет узлами хранилища. Набор, состоящий из Windows Azure Hypervisor, корневой операционной системы, Fabric Agent, потребительских виртуальных машин и гостевых агентов называется вычислительным узлом.

Агенты Fabric Agent управляются Fabric Controller, который работает вне вычислительных узлов и узлов хранилища. Если потребитель обновляет конфигурационный файл приложения во время его работы Fabric Controller коммуницирует с Fabric Agent, который, в свою очередь, передает запрос гостевым агентам, которые уведомляют приложения об изменениях конфигурации. В случае аппаратного сбоя, Fabric Controller автоматически ищет доступную инфраструктуру и перезапускает на ней виртуальную машину.

После того как мы познакомились с устройством платформы Windows Azure, можно перейти к обсуждению деталей реализации различных уровней безопасности, используемых в ней. Начнем с физической безопасности.

Физическая безопасность

Физическая безопасность является фундаментальной основой всей безопасности «облака». Если сервер, на котором выполняются приложения, не защищен физически, обеспечение других уровней безопасности вряд ли имеет смысл.

Windows Azure располагается в географически распределенных центрах обработки данных (по два центра в Северной Америке, западной Европе и Юго-восточной Азии), где также располагаются сервисы семейства Microsoft Online Services. Центры обработки данных Microsoft защищены в режиме 24х7 и обеспечиваются все необходимые меры по защите их работы от сбоев в электропитании, сбоев в работе сети и физического проникновения. Эти центры обработки данных отвечают требованиям различных индустриальных стандартов по обеспечению физической безопасности и надежности и управляются сотрудниками Microsoft.

Компания Microsoft использует индустриальные механизмы контроля доступа для защиты физической инфраструктуры Windows Azure и самих центров обработки данных. Доступ в помещения представляется ограниченному числу сотрудников, которые идентифицируются с помощью систем контроля доступа с использованием биометрических данных. С появлением таких глобальных стандартов, как ISO/IEC 27001:2005, Safe Harbor и ряда других существенно выросли требования к обеспечению физической безопасности. Сертификация центров обработки данных, проводимая компетентными организациями, позволяет убедиться в конфиденциальности данных пользователей без необходимости в предоставлении независимым аудиторам (например, при сертификации под SAS 70 Type II) непосредственного доступа к самой платформе, работающим на ней приложениям и хранимым данным.

Windows Azure располагается в инфраструктуре Microsoft Global Foundation Services (GFS), часть которой сертифицирована по стандарту ISO/IEC 27001:2005 (http://www.27001-online.com/). Данный международный стандарт является одним из основных стандартов, описывающих управление информационной безопасностью. В дополнение к этому, Microsoft поддерживает все требования в рамках Safe Harbor Framework (http://export.gov/safeharbor/). В то время, как ответственность за соблюдение законов, правил и индустриальных требований ложится на потребителей Windows Azure, Microsoft готова помогать им в соблюдении всех других требуемых стандартов. Более подробно о безопасности, предоставляемой инфраструктурой Microsoft Global Foundation Services, см. http://www.globalfoundationservices.com.

Сетевая безопасность

Второй уровень безопасности, за которой отвечает поставщик «облачных» сервисов – это сетевая безопасность. Сетевая инфраструктура Windows Azure реализована таким образом, чтобы ограничить атаки, исходящие как извне (Internet), так и изнутри – от вредоносного кода, выполняющегося в рамках обычной роли. Каждая роль развертывается в отдельную виртуальную машину («гостевую» VM), изолированную от Internet и других частей инфраструктуры Windows Azure через виртуальные локальные сети (VLAN). Использование виртуальных сетей обеспечивает контроль над коммуникациями – коммуникации между сетями обязательно проходят через роутеры, что предотвращает возможность захвата трафика и нанесение ущерба работе приложений. Помимо этого, использование виртуальных сетей предотвращает прослушивание трафика, не относящегося к данной сети. В Windows Azure используется три независимые виртуальные локальные сети:

• Экземпляры роли используют основную виртуальную локальную сеть
• Узлы Fabric Controller, которые отвечают за развертывание новых экземпляров и мониторинг работающих экземпляров используют отдельную виртуальную локальную сеть
• Отдельная виртуальная локальная сеть предназначена для сетевых и других инфраструктурных устройств

В инфраструктуре Windows Azure разрешены коммуникации, исходящие из виртуальной локальной сети, используемой Fabric Controller и направленные в основную виртуальную локальную сеть, но они должны быть инициированы виртуальной локальной сетью, используемой Fabric Controller, и не могут быть инициированы основной виртуальной локальной сетью. Коммуникации от основной виртуальной локальной сети к виртуальной локальной сети, используемой устройствами, блокируются – это гарантирует невозможность проведения атак, направленных на виртуальные локальные сети, используемые Fabric Controller или устройствами. Коммуникации с гостевыми виртуальными машинами защищены еще тремя уровнями – фильтрацией пакетов, брандмауэром и безопасными коммуникациями.

Фильтрация пакетов

В Windows Azure гипервизор напрямую взаимодействует с аппаратной инфраструктурой и делит один узел на переменное число виртуальных машин. Каждый узел также содержит «корневую» виртуальную машину, в которой работает хост-операционная система (или «корневая» операционная система). Гипервизор и корневая операционная система обеспечиваю фильтрацию сетевых пакетов – это гарантирует корректную работу гостевых операционных систем, отсутствие прослушивания трафика, получение трафика, не предназначенного той или иной гостевой машине и т.п. Пользовательский доступ к виртуальным машинам ограничен фильтрацией пакетов на уровне механизмов балансировки нагрузки и корневой операционной системы.

Брандмауэры

Как известно, на уровне конфигурации сервиса имеется возможность указания «точек входа» (endpoints) для роли Windows Azure. Описание точки входа включает протокол и используемый порт и служит правилом для брандмауэра (межсетевого экрана) в рамках гостевой виртуальной машины. Точки входа могут быть сконфигурированы таким образом, чтобы получать соединения из Internet или от других ролей, входящих в состав приложения. Соединения с ролями, относящимися к другим приложениям, считаются внешними соединениями.

Во время развертывания приложения Fabric Controller создает виртуальные машины для экземпляров ролей и, таким образом, «знает» какие IP-адреса принадлежат тем или иным экземплярам. Для реализации правил брандмауэра, позволяющих внутренние коммуникации, только Fabric Controller может сконфигурировать агента Fabric Agent, предоставив ему список IP-адресов роли. Этот список используется при фильтрации пакетов и на его основе обеспечиваются коммуникации внутри приложения, использующие только разрешенные IP-адреса.

Безопасные коммуникации

Безопасность на уровне коммуникаций может быть реализована одним из следующих способов:

• Коммуникации между клиентом и экземпляром роли
  • Роли поддерживают протокол SSL с использованием сертификата, создаваемого пользователем. Этот сертификат загружается в конфигурации роли через портал
• Управление через Service Management API
  • Управление ролью через Service Management API осуществляется по протоколу REST и использует механизм SSL аутентификации на основе сертификата, загружаемого в конфигурацию подписки через портал
• Внутренние коммуникации
  • Все коммуникации между внутренними компонентами Windows Azure защищены протоколом SSL. В большинстве случаев используются т.н. «Self-signed» SSL-сертификаты. Исключением являются сертификаты для Fabric Controller и сертификаты для соединения, которые доступны вне сети Windows Azure – например, для сервисов хранилища
• Коммуникации между экземпляром роли и SQL Azure
  • SQL Azure может использовать SSL для всех клиентских соединений. В этом случае при конфигурации соединения с SQL Azure следует использовать параметры Encrypt = True и TrustServerCertificate.

Продолжение следует

Во второй части мы продолжим знакомство с деталями реализации различных уровней безопасности, используемых в Windows Azure.

/АФ

Comments

• Anonymous
  October 20, 2011
  Ай, спасибо. Больше Azure, больше!