• Статья
Windows Azure. Безопасность

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

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

Платформа 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 (https://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, см. https://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 каждая роль выполняется внутри собственной виртуальной машины. Каждая виртуальная машина имеет 1, 2, 4 или 8 виртуальных процессоров и до 14 Гбайт памяти. В виртуальных машинах работает специальная версия Windows Server 2008 или Windows Server 2008 R2, на которой установлены необходимые программные компоненты - IIS, .NET Framework – их состав зависит от типа роли. В виртуальной машине также находится ограниченный набор драйверов устройств. Подробнее об этом см. «Внутри виртуальной машины Windows Azure».

На уровне отдельных узлов не поддерживается «долгосрочное» хранение данных. Данные, записанные на локальные диски, не сохраняются при установке/удалении виртуальных машин. Данные, которые должны быть сохранены, должны храниться с использованием сервисов Azure Storage.

В Windows Azure используется собственный гипервизор – слой виртуализации, разработанный Microsoft на основе технологий, используемых в Hyper-V. Этот гипервизор взаимодействует непосредственно с аппаратной инфраструктурой и разделяет узлы на определенно число виртуальных машин. Каждый узел имеет «корневую» виртуальную машину, на которой выполняется операционная система, представляющая собой существенно обрезанную версию Windows Server, включающая только компоненты, требуемые для хостинга виртуальных машин, агент Fabric Controller и т.п. Это сделано для того, чтобы улучшить производительность и минимизировать область потенциальных атак.

Критической границей является изоляция корневой виртуальной машины от гостевых виртуальных машин и гостевых машин друг от друга. Эта граница реализуется гипервизором и корневой операционной системой. Инфраструктура Windows Azure регулярно устанавливает обновления операционной системы на образы виртуальных дисков (Virtual Hard Drive, VHD), содержащие гостевую операционную систему. У потребителей имеется возможность указать на необходимость использования определенной версии операционной системы – в этом случае дальнейшие обновления устанавливаться не будут.

Дизайн самой виртуальной машины с гостевой операционной системой обеспечивает защиту от неавторизованных изменений. Каждая виртуальная машина соединена с тремя локальными дисками:

  • Диск D содержит одну из нескольких версий гостевой операционной системы, выбираемой потребителем. Версия операционной системы поддерживается в актуальном состоянии за счет автоматической установки обновлений
  • Диск E содержит образ приложения, создаваемый Fabric Controller на основе пакета развертывания, предоставляемого потребителем. Более подробно про развертывание приложений см. «Windows Azure. Быстрый старт. Развертывание приложений»
  • Диск C содержит конфигурационную информацию и данные, собираемые в процессе работы приложения

Такой дизайн позволяет обеспечить целостность гостевой операционной системы и выполняющихся под ее управлением приложений и сервисов.

Безопасность приложений

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

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

  • Проверка вводимой информации
    • Необходимо выполнять проверку всех вводимых данных, которые пересекают т.н. «границу доверия» (trust boundary). Правильно реализованная проверка позволяет «отсечь» достаточно высокое число существующих и будущих атак. Такая проверка обычно является достаточно простой и очень эффективной. При выполнении проверки можно использовать две стратегии – «белый список» и «черный список». Проверка на основании «белого списка» задает шаблон для проверки корректного ввода – все данные, соответствующие этому шаблону попадают в систему, остальные – отсекаются. Если такой шаблон задать невозможно, создается «черный список», содержащий описание некорректного ввода – при вводе такие данные отсекаются
  • Аутентификация
    • Необходимо идентифицировать пользователей. Практически все веб-приложения должны знать источники запросов к ним
  • Авторизация
    • Проверяйте полномочия, доступные пользователям и то, что выполняемые операции доступны только пользователям с соответствующими привилегиями
  • Управление конфигурациями
    • Защищайте информацию, которая размещается в конфигурационных файлах приложения – например, строки соединения. Управление изменениями приложениями – развертыванием новых версий – это процесс, который требует особого внимания с точки зрения безопасности
  • Управление сессиями
    • Защищайте состояние приложения – информацию, которая сохраняется в рамках сессии и между сессиями
  • Криптография
    • Используйте надежные криптографические алгоритмы и храните ключи в защищенном месте
  • Защита параметров
    • Защищайте параметры, передаваемые между различными модулями приложения – например, http-параметры, передаваемые между веб-страницами
  • Управление исключениями
    • Следите за обработкой исключений и протоколируйте их. Исключения могут содержать конфиденциальную информацию о приложении, которая может использоваться для организации атаки. Обычно, пользователям приложения не нужна детальная техническая информация о произошедшем сбое
  • Аудит и журналирование
    • Определите нештатные ситуации, сравнивая их с обычным поведением приложения При возникновении проблемы важно отследить причину ее появления – без аудита и журналирования сделать это невозможно. Администраторы должны получать уведомления о возникновении нештатных ситуаций и иметь исчерпывающую информацию о причинах ее возникновения

 

Уровни доверия кода

Один из основных принципов написания безопасного кода является выполнение кода с минимально необходимыми привилегиями. Другими словами, код приложения не должен иметь больше привилегий, чем требуется для его нормального выполнения. В Windows Azure есть два уровня Code Access Security (CAS), под которыми выполняется код роли – полное доверие (full trust) и ограниченное доверие (partial trust)

При использовании уровня ограниченного доверия накладываются следующие ограничения:

  • Запрещено использование неуправляемого кода (native code)
  • Отсутствует доступ к библиотекам и ресурсам на неуправляемом коде
  • Отсутствует доступ к Windows Azure Diagnostics через библиотеку Windows Azure Managed Library
  • Доступ к файловой системе на чтение разрешен для каталога приложения и ряда локальных хранилищ. Доступ к файловой системе на запись и добавление разрешен только для ряда локальных хранилищ
  • Запрещен доступ к реестру
  • Разрешен доступ только к переменным среды TEMP и TMP
  • Запрещен доступ к журналу событий (Event log)

Уровень полного доверия требуется в следующих сценариях:

  • При использовании FastCGI или PHP
  • При миграции «традиционных» веб-сервисов в «облако»
  • При вызове кода роли или создании дочернего процесса (на неуправляемом или управляемом коде)
  • При вызовах библиотек на неуправляемом коде через P/Invoke

Если перечисленные выше сценарии не используются, рекомендуется использовать уровень ограниченного доверия – эта опция минимизирует область атаки для кода роли.

Идентификация

Как было отмечено выше, аутентификация и авторизация – это два базовых механизма, которые должны использоваться во всех приложениях. Существует два типа управления идентификацией – на основе ролей (role-based identity) и на основе утверждений (claims-based identity).

При использовании идентификации на основе ролей, пользователь предоставляет идентификационные данные (credentials), которые используются приложением для аутентификации пользователя. После этого, пользователь «отображается» на соответствующую группу и получает права, в соответствии с членством в той или иной группе. Идентификация на основе ролей является традиционным способом для аутентификации и авторизации пользователей. К наиболее популярным технологиям авторизации на основе ролей относятся Windows Identity (Domain Join, Kerberos), провайдеры членства (membership providers) ASP.NET и SQL.

При использовании идентификации на основе утверждений аутентификация выполняется вне «границ» приложения. Приложения устанавливают доверительные отношения с сервисами Security Token Services (STSs). Пользователи аутентифицируют себя, используя эти сервисы и получают маркер (token), содержащий коллекцию утверждений – информацию о пользователе. Такой маркер обычно подписан и зашифрован с помощью публичного ключа приложения. Когда приложение получает маркер, пользователь уже аутентифицирован – все, что требуется, это открыть маркер и обработать содержащуюся в нем информацию. Использование идентификации на основе утверждений позволяет реализовать сценарии федерации и делегации аутентификации.

Доверительный уровень может быть установлен даже между различными STS-сервисами – клиент может аутентифицироваться с помощью локального сервиса и послать маркер сервису, которому «доверяет» приложение. Этот сервис использует полученный маркер для создания нового маркера, который уже будет передан приложению. К наиболее популярным технологиям авторизации на основе утверждений относятся Active Directory Federation Services (ADFS) 2.0, Windows Identity Foundation (WIF) и Azure AppFabric Access Control Service (ACS).

В Windows Azure поддерживается как авторизация на основе ролей, так и авторизация на основе запросов.

Авторизация на основе ролей обычно используется в следующих сценариях:

  • При миграции в «облако» приложений, которые используют ролевую авторизацию
  • В простых сценариях, когда не требуется федерация и делегация аутентификации
  • В сценариях, когда идентификация может быть реализована на уровне приложения

Идентификация на уровне утверждений является более простой в реализации и может быть вынесена «вне» приложения. Обычно, при использовании такой идентификации уменьшается число учетных записей, которыми необходимо управлять, а централизация аутентификации упрощает переход на более защищенные методы аутентификации по мере их появления. В состав Windows Azure AppFabric входит масштабируемый, надежный и простой STS-сервис, который может быть использован как в «облачных», так и в традиционных приложениях.

Безопасность данных

В состав Windows Azure входит инфраструктура хранения данных, доступная в виде следующих сервисов - Windows Azure Storage, SQL Azure и Azure AppFabric Cache. Потребители и пользователи будут хранить данные в «облаке» только в том случае, если они будут уверены, что сервисы хранения безопасны и надежны. Поэтому все технологии хранения данных, реализованные в Windows Azure, содержат механизмы для обеспечения контроля доступа и реализуют GFS-политики защищенности пользовательских данных.

Контроль доступа

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

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

В тех сценариях, где необходимо ограничить доступ к содержимому бинарных объектов, эти объекты могут быть доступны либо ограниченное время, либо требовать для доступа к ним специального набора привилегий, опять же, без необходимости в использовании «секретного» ключа. В этих случаях предоставляется возможность создания Shared Access Signature (SAS) – специального варианта URL для доступа к бинарному объекту, который содержит информацию о способах доступа – времени доступности объекта или требуемых привилегиях. Такие URL подписываются с помощью ключа учетной записи хранилища и распространяются только среди пользователей, которым предназначено содержимое бинарных объектов. В доступ к бинарному объекту через «обычный» URL будет отказано, но с использованием SAS его содержимое будет доступно в течение заданного периода. При необходимости усиления уровня защиты следует создать ссылку из Shared Access Signature (SAS) на политику доступа к контейнеру - Container-Level Access Policy. Эта политика может быть модифицирована или отключена, что позволяет более гибко контролировать выданные разрешения на доступ к бинарным объектам.

Целостность данных, доступность и надежность

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

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

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

Криптография

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

В настоящий момент на уровне платформы шифрование для Windows Azure Storage или SQL Azure не реализовано. Данные, располагаемые в Windows Azure Storage, хранятся в «открытом» виде и не существует опции для их встроенного шифрования – только путем написания дополнительного кода, выполняющего эту операцию. В состав .NET Framework входит набор программных интерфейсов, позволяющих использовать различные алгоритмы шифрования для данных, хранимых в Windows Azure Storage. В настоящий момент SQL Azure не поддерживает механизм Transparent Data Encryption (TDE), доступный в Microsoft SQL Server.

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

Таким образом, до тех пор, пока сервис использует необходимый уровень защиты транспорта (например., SSL), единственным способом получения доступа к данным для злоумышленников является получение информации об учетной записи Windows Live ID, используемой в рамках подписки или сертификате управления, используемого для администрирования сервисов.

Шифрование ценно в тех сценариях, если вы обращаетесь к данным, расположенным в хранилище Windows Azure, из приложений, работающих вне инфраструктуры Azure. В этом случае может потребоваться использование частных AES-ключей, известных только конкретному пользователю. Такие ключи могут быть сгенерированы на компьютере пользователя или где-то в рамках локальной инфраструктуры. Зашифрованные данные загружаются в хранилище Windows Azure. Расшифровка данных доступна только пользователям, у которых есть необходимый ключ – это ключ можно хранить в пользовательском профиле используя программные интерфейсы DPAPI. Клиентское приложение, обращающееся к хранилищу Windows Azure напрямую, не предоставляя соответствующие ключи, не сможет расшифровать хранящиеся данные.

Заключение

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

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