Обзор безопасности платформы Azure – кратко об основных моментах
Безопасность является одной из самых важных тем при обсуждении размещения приложений в «облаке». Растущая популярность облачных вычислений привлекает пристальное внимание к вопросам безопасности, особенно в свете наличия разделения ресурсов и мультитенантности. Аспекты мультитенантности и виртуализации облачных платформ вызывают необходимость в некоторых уникальных методах обеспечения безопасности, особенно учитывая такие типы атак, как side-channel attack (тип атак, базирующийся на получении некоторой информации о физической реализации).
Microsoft предоставляет безопасную среду выполнения, обеспечивает безопасность на уровне операционной системы и инфраструктуры. Некоторые аспекты безопасности, реализованные на уровне поставщика облачной платформы, фактически лучше тех, которые доступны в локальной инфраструктуре. Например, физическая безопасность датацентров, где располагается Microsoft Azure, существенно надежнее, чем у подавляющего большинства предприятий и организаций. Сетевая защита Microsoft Azure, изоляция среды выполнения и подходы к обеспечению защищенности операционной системы существенно выше, чем при традиционном хостинге. Таким образом, размещение приложений в «облаке» позволяет улучшить безопасность ваших приложений. С самого создания платформы Microsoft предпринимает множество мер по сертификации самыми современными и сложными стандартами. Общее представление об имеющихся сервисах и их расположении относительно разворачиваемой инфраструктуры можно получить из скриншота ниже.
В целом, любая облачная платформа должна обеспечивать три основных аспекта безопасности клиентских данных: конфиденциальность, целостность и доступность, и облачная платформа Microsoft не является исключением.
Конфиденциальность
Обеспечение конфиденциальности позволяет клиенту быть уверенным, что его данные будут доступны только тем объектам, у которых есть соответствующее на то право. На платформе Microsoft Azure конфиденциальность обеспечивается с помощью следующих средств и методов:
· Управление личностью – определение того, является ли аутентифицировавшийся принципал объектом, имеющим доступ к чему-либо.
· Изолированность – обеспечение изолированности данных с использованием «контейнеров» как физического, так и логического уровня.
· Шифрование – дополнительная защита данных с помощью механизмов шифрования. Шифрование используется на платформе Microsoft Azure для защиты каналов коммуникаций и применяется для обеспечения более совершенной защиты данных клиентов.
Управление личностью
Доступ к подписке осуществляется с помощью системы Microsoft Account (раньше Live Id), которая является одной из самых старых и проверенных систем аутентификации в Интернет. Доступ к уже развернутым сервисам контролируется подпиской. Пользователь должен ввести пару логин-пароль для доступа к своей подписке, кроме этого, если пользователь принадлежит организации, могут быть использованы организационный аккаунт вместе с мультифакторной аутентификацией, что позволяет внедрить еще один слой безопасности доступа к подписке. Пользователь может обеспечить дополнительную безопасность для входа в подписку с помощью многофакторной аутентификации и Microsoft Azure Active Directory – пользователь, который попытается зайти с помощью пары логин-пароль, будет проверен еще с помощью СМС либо телефонного звонка.
Развертывание приложений в Microsoft Azure осуществляется двумя способами – с портала Microsoft Azure и с помощью Service Management API (SMAPI). Service Management API (SMAPI) предоставляет веб-сервисы с помощью протокола Representational State Transfer (REST) и предназначен для разработчиков. Протокол работает поверх SSL. Также возможно использование Powershell и System Center.
Аутентификация SMAPI основана на создании пользователем пары публичного и приватного ключей и самоподписанного сертификата, который регистрируется на портале Microsoft Azure. Таким образом, все критичные действия по управлению приложениями защищены собственными сертификатами клиента, при этом сертификат не привязан к trusted root certificate authority (CA).
Хранилище Microsoft Azure использует собственный механизм аутентификации на основе двух ключей Storage Account Key (SAK), которые ассоциированы с каждым аккаунтом и могут быть сброшены пользователем.
Таким образом, в Microsoft Azure реализована комплексная защита и аутентификация, общие данные о которой приведены в таблице.
Субъекты |
Объекты защиты |
Механизм аутентификации |
Клиенты |
Подписка |
Microsoft Account |
Разработчики |
Портал Microsoft Azure/SMAPI |
Microsoft Account (портал), самоподписанный сертификат (SMAPI) |
Экземпляры ролей |
Хранилище |
Ключ |
Внешние приложения |
Хранилище |
Ключ |
Внешние приложения |
Приложения |
Определяется пользователем |
В случае с сервисами хранилища для определения прав пользователя можно использовать (для всех сервисов хранилища – с версии 1.7, ранее – только для блобов) Shared Access Signatures. Shared Access Signatures ранее были доступны только для блобов, что позволяло хозяинам аккаунтов хранилища выдавать определенным образом подписанные URL для обеспечения доступа к блобам. На данный момент Shared Access Signature доступны и для таблиц и очередей в добавление к блобам и контейнерам. До момента внедрения этой функции для того, чтобы совершить что-то из CRUD с таблицей или очередью, необходимо было быть хозяином аккаунта. Теперь же можно предоставить другому человеку ссылку, подписанную Shared Access Signature, и предоставить права. Функциональность Shared Access Signature заключается в детальном контроле доступа к ресурсам, определении, какие операции может совершить пользователь над ресурсом, имея Shared Access Signature. К списку доступных для определения Shared Access Signature операций относятся:
· Чтение и запись контента – в случае блобов ещё свойства и метаданные, а также блок-списки.
· Удаление, лизинг, создание снапшотов блобов.
· Получение списков элементов контента.
· Добавление, удаление, обновление сообщений в очередях.
· Получение метаданных очередей, включая количество сообщений в очереди.
· Чтение, добавление, обновление и вставка сущностей в таблицу.
Параметры Shared Access Signature включают в себя всю информацию, необходимую для выдачи доступа к ресурсам хранилища – параметры запроса в URL определяют временной промежуток, через который Shared Access Signature "протухнет", разрешения, предоставляемые данной Shared Access Signature, ресурсы, к которым предоставляется доступ и, собственно, сигнатуру, с помощью которой происходит аутентификация. В Shared Access Signature URL также можно включить ссылку на хранимую политику доступа.
Shared Access Signature должны распространяться с использованием HTTPS и разрешать доступ на максимально короткий временной промежуток.
Типичным примером для использования Shared Access Signature является сервис адресной книги, одним условием для разработки которого является то, чтобы он мог масштабироваться для большого количества пользователей. Сервис предоставляет пользователю возможность хранить собственную адресную книгу в облаке и получать к ней доступ с любого устройства или приложения. Пользователь подписывается на услуги сервиса и получает адресную книгу. Можно реализовать этот сценарий с помощью ролевой модели Microsoft Azure, и тогда сервис будет работать как прослойка между клиентским приложением и сервисами хранилища облачной платформы. После аутентификации клиентского приложения оно будет получать доступ к адресной книге через веб-интерфейс сервиса, который будет посылать запросы, инициированные клиентом, в сервис хранилища таблиц облачной платформы. Однако конкретно в этом сценарии отлично смотрится использование Shared Access Signature для сервиса таблиц, и реализуется он довольно просто. SAS для сервиса таблиц можно использовать для предоставления прямого доступа к адресной книге приложению. Подобный подход позволяет увеличить степень масштабируемости системы и уменьшить стоимость решения, удалив прослойку, обрабатывающую запросы, в виде сервиса. Роль сервиса в данном случае будет сведена к обработке подписки клиентов и генерации токенов Shared Access Signature для клиентского приложения.
Подробнее про Shared Access Signatures можно почитать в специально посвящённой этой теме статье - https://hpcru.wordpress.com/2012/06/21/sas/
Дополнительной мерой обеспечения безопасности является принцип наименьших привилегий. Согласно этому принципу, клиентам запрещен административный доступ к их виртуальным машинам (напомню, что все сервисы в Microsoft Azure работают на основе виртуализации), а программное обеспечение, запущенное ими, работает под специальным ограниченным аккаунтом. Таким образом тот, кто каким-либо образом хочет получить доступ к системе, должен провести процедуру повышения.
Всё, что передается по сети до Microsoft Azure и внутри платформы, защищено с помощью SSL, причем в большинстве случаев SSL-сертификаты являются самоподписанными. Исключение – передача данных вне внутренней сети Microsoft Azure, например, для сервисов хранилищ или fabric controller, которые используют сертификаты, выданные центром Microsoft. К процессу передачи этих данных пользователь не имеет отношения и не может получить доступ, так как траффик является служебным.
Изолированность
В зависимости от количества экземпляров роли, определенного клиентом, Windows Azure создает равное этому числу количество виртуальных машин, которые называются экземплярами роли, после чего запускает развернутое приложение на этих виртуальных машинах. Виртуальные машины запускаются в гипервизоре Hyper-V со специальными настройками и ограничениями.
Для реализации механизма безопасности необходимо изолировать друг от друга экземпляры сервисов, обслуживающих отдельных клиентов, и данные, которые будут храниться в сервисах хранилища.
Учитывая виртуализацию как краеугольный камень облаков, критичным является обеспечение изоляции Root VM (защищённой системы, где Fabric Controller размещает собственных Fabric Agent, которые управляют Guest Agent, размещаемыми на клиентских виртуальных машинах) от гостевых виртуальных машин и гостевых виртуальных машин друг от друга.
Виртуализация в облаке привела к появлению новых типов угроз, например:
• Повышение привилегий за счет атаки из виртуальной машины на физический хост либо на другую виртуальную машин
• Выход за пределы виртуальных машин и выполнение кода в контексте ОС физического хоста с захватом управления ОС (Jailbreaking, Hyperjacking)
Microsoft Azure использует гипервизор Hyper-V, адаптированный для облака. Он разделяет каждый узел на определенное количество виртуальных машин. Каждый узел имеет Root VM, на которой запущена хостовая операционная система. Microsoft Azure использует в качестве этой операционной системы обрезанную версию Windows Server, на которой установлены только необходимые сервисы для обслуживания хостовых виртуальных машин, что сделано как для увеличения производительности, так и уменьшения «поверхности» атаки.
Операции доступа к сети и дисковые операции управляются операционной системой на Root VM. Фильтры на виртуальной сети гипервизора управляют трафиком в и из виртуальных машин, предотвращая также различные атаки на основе снифинга. Кроме этого установлены другие фильтры, блокирующие броадкасты и мультикасты (кроме DHCP lease). Правила подключения кумулятивны – например, если экземпляры ролей А и Б принадлежат разным приложениям, то А может инициировать открытие подключения к Б только в том случае, если А может открывать подключения в Интернет, а Б может принимать подключения из Интернет.
Контроллер транслирует список ролей в список экземпляров этих ролей, после чего транслирует полученный список в список IP-адресов, который далее используется агентом для настройки фильтров пакетов, разрешающим intra-application подключения к этим IP-адресам.
Сам Fabric Controller максимально защищён от потенциально взломанных Fabric Agent-ов на хостах. Канал связи между контроллером и агентами двунаправленный, при этом агент реализует сервис, защищенный SSL, который используется контроллером и может отвечать только на запросу, но не может инициировать создание подключения к контроллеру. Если существует контроллер или устройство, которое не умеет SSL, оно располагается в отдельном VLAN-е.
VLAN-ы активно используются в Microsoft Azure. Они используются для обеспечения изолированности контроллеров и других устройств. VLAN-ы делят сеть таким образом, что между двумя VLAN-ами не может возникнуть канала коммуникаций иначе кроме как через маршрутизатор, что предотвращает вредоносную работу скомпрометированного узла – например, подмену трафика или его просмотр. На каждом кластере есть три VLAN-а:
1) Основной VLAN соединяет недоверенные клиентские узлы.
2) VLAN контроллера – доверенные контроллеры и поддерживаемые системы.
3) VLAN устройств – доверенные устройства инфраструктуры (например, сетевые).
Коммуникации между VLAN-ом контроллера и основным VLAN-ом возможны, но инициировать подключение может только контроллер к основному, но никак не наоборот. Коммуникации от основного VLAN-а к VLAN-у устройств заблокированы.
Шифрование
Как неоднократно писалось выше, практически все коммуникации защищаются SSL. Клиент может использовать Microsoft Azure SDK, расширяющий базовые .NET библиотеки возможностями интеграции .NET Cryptographic Service Providers (CSP) в Microsoft Azure, например:
1) Полный набор функциональности, связанной с криптографией, например, MD5 и SHA-2.
2) RNGCryptoServiceProvider – класс для генерации случайных чисел, достаточных для реализации достаточного для криптографии энтропии.
3) Алгоритмы шифрования (например, AES), проверенные годами реального использования.
4) И т.д.
Все управляющие сообщения, передающиеся по каналам связи внутри платформы, защищаются протоколом TLS с криптографическими ключами длиной минимум 128 бит.
Все вызовы операций к Microsoft Azure делаются с использованием стандартных протоколов SOAP, XML, REST-based. Канал коммуникации может быть зашифрован либо не зашифрован в зависимости от настроек.
На уровне сервисов хранилища данные клиента по умолчанию не шифруются – то есть как положены они в хранилище блобов или таблиц, в таком виде они и хранятся. В том случае, если необходимо шифровать данные, это нужно делать на стороне клиента. Для корпоративных нужд существует предложение StorSimple.
Для критичных данных рекомендуется использовать гибридное решение, когда важные данные хранятся локально, некритичные же в хранилище Microsoft Azure либо SQL Databases.
Целостность
Когда клиент использует данные в электронном виде, он ожидает, что эти данные будут защищены от изменения как намеренного, так и случайного. На Microsoft Azure обеспечение целостности гарантируется, во-первых, тем, что клиенты не имеют административных привилегий на виртуальные машины на вычислительных узлах, во-вторых - код выполняется под Windows-аккаунтом с минимальными привилегиями. Каждая ВМ соединена с двумя локальными дисками:
* Диск D: содержит временные данные.
* Диск C: содержит конфигурационную информацию, файлы подкачки и прочие служебные данные.
Временный диск D является локальным для конкретного оборудования, на котором расположена ВМ. Это является причиной, по которой при выключении или другой операции, приводящей к переразвертыванию ВМ, происходит очищение диска D. Диск C является устойчивым к этим операциям, так как не является локальным для физического оборудования.
Доступность
Клиенту, выкладывающему сервис в облако, критически важна максимально возможная его доступность как для потребителей, так, собственно, и для клиента. Microsoft Azure предоставляет слой функциональности, реализующей избыточность и, тем самым, максимально возможную доступность данных клиента.
Самым важным понятием, раскрывающим основной механизм обеспечения доступности на Microsoft Azure, является репликация. Рассмотрим репликацию подробнее.
Locally Redundant Storage (LRS) предоставляет хранилище с высокой степенью долговечности и доступности внутри одной географической локации (региона). Платформа хранит три реплики каждого элемента данных в одной главной географической локации, что гарантирует, что эти данные можно будет восстановить после сбоя общего характера (например, выхода из строя диска, узла, корзины и так далее) без простоя аккаунта хранилища и, соответственно, не влияя на доступность и долговечность хранилища. Все операции записи в хранилище выполняются синхронно в три реплики в трех различных доменах ошибок (fault domain), и только после успешного завершения всех трех операций возвращается код об успешном завершении транзакции. В случае использования локального избыточного хранилища, если датацентр, в котором размещены реплики данных, будет по какой-либо причине выведен из строя полностью, Microsoft свяжется с клиентом и сообщит о возможной потере информации и данных, используя контакты, приведенные в подписке клиента.
Geo Redundant Storage (GRS) предоставляет гораздо более высокую степень долговечности и безопасности, размещая реплики данных не только в главной географической локации, но и в какой-либо дополнительной в том же регионе, но за сотни километров. Все данные в сервисах хранилища блобов и таблиц географически реплицируются. С географически избыточным хранилищем платформа сохраняет опять же три реплики, но в двух локациях. Таким образом, если датацентр перестанет работать, данные будут доступны из второй локации. Как и в случае первой опции избыточности, операции записи данных в главной географической локации должны быть подтверждены перед тем, как система вернет код успешного завершения операции. По подтверждению операции в асинхронном режиме происходит репликация в другую географическую локацию. Рассмотрим, как происходит географическая репликация.
Когда вы совершаете операции создания, удаления, обновления и так далее в хранилище данных, транзакция полностью реплицируется в три совершенно разных узла хранилища в трех разных доменах ошибок и обновлений в главной географической локации, после чего клиенту возвращается код успешного завершения операции и в асинхронном режиме подтвержденная транзакция реплицируется во вторую локацию, где полностью реплицируется в три совершенно различных узла хранилища в разных доменах ошибок и обновлений. Общая производительность при этом не падает, так как всё совершается асинхронно.
Что касается географической отказоустойчивости и того, как все восстанавливается в случае серьезных сбоев. Если серьезный сбой возник в главной географической локации, естественно что корпорация пытается по максимуму сгладить последствия. Однако, если данные потеряны, может возникнуть необходимость в применении правил географической отказоустойчивости – клиент оповещается о возникшей катастрофе в главной локации, после чего соответствующие DNS-записи перезаписываются с главной локации на вторую (account.service.core.windows.net). В процессе перевода DNS-записей вряд ли что-то будет работать, но по его завершению существующие блобы и таблицы становятся доступными по их URL. После завершения процесса перевода вторая географическая локация повышается в статусе до главной (до тех пор, пока не случится очередной выход из строя датацентра). Также сразу по завершению процесса повышения статуса датацентра инициируется процесс создания новой второй географической локации в этом же регионе и дальнейшей репликации данных.
Всё это контролируется Fabric Controller. В том случае, если установленные на виртуальные машины гостевые агенты (GA) перестают отвечать, контроллер переносит всё на другой узел и перепрограммирует сетевую конфигурацию для обеспечения полной доступности.
Также на платформе Microsoft Azure есть такие механизмы, как домены обновлений и домены ошибок, с помощью которых также гарантируется постоянная доступность развернутого сервиса даже во время обновления операционной системы либо аппаратных ошибок.
Домены ошибок - это физический юнит, контейнер развертывания, и обычно он ограничивается реком (rack). Если домены расположить в разных реках, то получится, что экземпляры будут расположены так, что не будет достаточной вероятности их общего выхода из строя. Кроме этого, ошибка в одном домене ошибок не должна приводить к возникновению ошибок в других доменах. На данный момент контролировать количество доменов ошибок нельзя - этим занимается Fabric Controller.
Домены обновлений представляют из себя сущность более контролируемую. Над доменами обновлений есть определенный уровень контроля, и пользователь может совершать инкрементальные или rolling-обновления группы экземпляров своего сервиса в один момент времени. Отличаются домены обновлений от доменов ошибок еще и тем, что являются логической сущностью, тогда как домены ошибок - физической. Так как домен обновлений логически группирует роли, одно приложение может быть расположено в нескольких доменах обновлений и в то же время только в двух доменах ошибок. В этом случае обновления могут быть осуществлены сначала в домене обновлений №1, затем в домене обновлений №2 и так далее.
Каждый центр обработки данных имеет как минимум два источника электроэнергии, в том числе автономный источник электропитания. Элементы управления средой автономны и будут функционировать до тех пор, пока системы подключены к сети Интернет.
Сертификация
В обзоре безопасности любой платформы, которой активно пользуются, нельзя обойти стороной вопрос сертификации платформы различными организациями. Microsoft Azure имеет набор сертификатов от ведущих лидеров индустрии в области сертификации.
Постоянно обновляющуюся информацию о сертификации платформы можно изучить на портале Trust Center - https://www.windowsazure.com/ru-ru/support/trust-center/compliance/
Fault Tolerance & Redundancy
Платформа Microsoft Azure разработана для обеспечения отказоустойчивости и избыточности, она также позволяет клиентам создавать и развертывать отказоустойчивые приложения. Множество аспектов платформы обеспечивают отказоустойчивость и избыточность, от развертывания в географически распределенных центрах обработки данных до реплицированных экземпляров ролей и хранилищ.
Каждый уровень инфраструктуры платформы Microsoft Azure разработан для обеспечения непрерывности работы в случае сбоя. На каждом уровне есть резервные сетевые устройства, а каждый центр обработки данных использует двух поставщиков услуг Интернета. Отказоустойчивость в большинстве случаев обеспечивается автоматически (без вмешательства людей), а сеть отслеживается центром сетевых операций круглосуточно для обнаружения аномалий и потенциальных проблем.
SLA
Соглашение об уровнях предоставления услуги (ServiceLevelAgreement ( SLA) — это формальный договор между заказчиком услуги и её поставщиком, содержащий описание услуги, права и обязанности сторон и согласованный уровень качества предоставления данной услуги. Подробнее про SLA можно почитать в Trust Center https://www.windowsazure.com/ru-ru/support/legal/sla/
Физическая безопасность
Услуги Microsoft Azure предоставляются пользователям через глобальную сеть датацентров, разработанных с учетом необходимости работать круглосуточно, на каждом из которых используются различные средства для защиты системы от сбоев питания, физического вторжения и обрывов сетевого подключения. Эти географические распределенные центры обработки данных соответствуют индустриальным стандартам обеспечения физической безопасности и надежности. Корпорация Microsoft не делегирует задачи по обслуживанию собственных датацентров другим компаниям, и сотрудники Microsoft полностью осуществляют управление, мониторинг и администрирование датацентрами корпорации.
Microsoft использует механизмы доступа с высокой степенью безопасности, доступные только ограниченному числу сотрудников. Доступ к датацентрам и полномочия контролируются директором по работе сети в соответствии с локальными рекомендациями по обеспечению безопасности датацентра.
Полезные ресурсы