Рекомендации Azure по безопасной изоляции

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

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

Azure устраняет предполагаемый риск совместного использования ресурсов, предоставляя надежную основу для обеспечения мультитенантной, криптографически определенной, логически изолированной облачной службы с помощью общего набора принципов:

1. Элементы управления доступом пользователей с аутентификацией и разделением полномочий.
2. Изоляция вычислений для обработки
3. Сетевая изоляция, включая шифрование данных при передаче
4. Изоляция хранилища с шифрованием данных в состоянии покоя
5. Процессы обеспечения безопасности, внедренные в структуру службы, для правильной разработки логически изолированных служб

Многотенантность в общедоступном облаке повышает эффективность путем мультиплексирования ресурсов среди разрозненных клиентов с низкой стоимостью; однако этот подход представляет предполагаемый риск, связанный с общим доступом к ресурсам. Azure устраняет этот риск, предоставляя надежное основание для изолированных облачных служб с помощью многоуровневого подхода, показанного на рис. 1.

На рис. 1. Подходы к изоляции Azure

Краткое описание подходов к изоляции приведено ниже.

• Управление доступом пользователей с помощью проверки подлинности и разделения удостоверений — все данные в Azure независимо от типа или расположения хранилища связаны с подпиской. Облачный клиент можно просмотреть как выделенный экземпляр идентификатора Microsoft Entra, который ваша организация получает и владеет при регистрации в облачной службе Майкрософт. Стек удостоверений и доступа помогает обеспечить изоляцию между подписками, включая ограничение доступа к ресурсам в подписке только авторизованным пользователям.

• Изоляция вычислений — Azure предоставляет как логическую, так и физическую изоляцию вычислений для обработки. Логическая изоляция реализуется с помощью:

  • Изоляция гипервизора для служб, которые обеспечивают криптографически определенную изоляцию с помощью отдельных виртуальных машин и использования изоляции Гипервизора Azure.
  • Изоляция Drawbridge внутри виртуальной машины для служб, которые обеспечивают изоляцию, гарантированную криптографическим способом, для рабочих нагрузок, выполняющихся на той же виртуальной машине, с использованием изоляции, предоставляемой Drawbridge. Эти службы предоставляют небольшие единицы обработки с помощью клиентского кода.
  • Изоляция на основе контекста пользователей для служб, состоящих исключительно из управляемого корпорацией Майкрософт кода и клиентского кода, не разрешена.
    

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

• Сетевая изоляция — виртуальная сеть Azure помогает обеспечить логическую изоляцию частного сетевого трафика от трафика, относящегося к другим клиентам. Службы могут обмениваться данными с помощью общедоступных IP-адресов или частных IP-адресов. Обмен данными между виртуальными машинами остается частным в виртуальной сети. Вы можете подключать виртуальные сети через пиринг виртуальных сетей или VPN-шлюзы в зависимости от параметров подключения, включая пропускную способность, задержку и требования к шифрованию. Группы безопасности сети (NSG) можно использовать для обеспечения изоляции сети и защиты ресурсов Azure из Интернета при доступе к службам Azure с общедоступными конечными точками. Теги службы виртуальной сети можно использовать для определения элементов управления доступом к сети в группах безопасности сети или брандмауэре Azure. Тег службы представляет группу префиксов IP-адресов из данной службы Azure. Корпорация Майкрософт управляет префиксами адресов, охватываемым тегом службы, и автоматически обновляет тег службы по мере изменения адресов, тем самым уменьшая сложность частых обновлений правил безопасности сети. Кроме того, вы можете использовать приватный канал для доступа к службам Azure PaaS через частную конечную точку в виртуальной сети, обеспечивая передачу трафика между виртуальной сетью и службой через глобальную магистральную сеть Майкрософт, что устраняет необходимость предоставления службы общедоступному Интернету. Наконец, Azure предоставляет возможности для шифрования данных во время передачи, включая сквозное шифрование сетевого трафика с помощью TLS (Transport Layer Security) с завершением TLS, использующим сертификаты Key Vault, шифрование VPN с использованием IPsec и шифрование Azure ExpressRoute с поддержкой MACsec и управляемыми клиентом ключами (CMK).

• Изоляция хранилища . Чтобы обеспечить криптографическую уверенность в изоляции логических данных, служба хранилища Azure использует шифрование неактивных данных с помощью расширенных алгоритмов с несколькими шифрами. Этот процесс использует несколько ключей шифрования и служб, таких как Azure Key Vault и Идентификатор Microsoft Entra, чтобы обеспечить безопасный доступ к ключам и централизованное управление ключами. Шифрование службы хранилища Azure гарантирует, что данные автоматически шифруются перед сохранением в службе хранилища Azure и расшифровываются перед извлечением. Все данные, записанные в службу хранилища Azure, шифруются с помощью шифрования FIPS 140, проверенного 256-разрядного шифрования AES , и вы можете использовать Key Vault для ключей, управляемых клиентом (CMK). Шифрование в службе хранилища Azure шифрует страничные блобы, которые содержат диски виртуальных машин Azure. Кроме того, шифрование дисков Azure может использоваться при необходимости для шифрования дисков виртуальных машин IaaS под управлением Windows и Linux, чтобы повысить изоляцию хранилища и обеспечить криптографическую целостность данных, хранящихся в Azure. Это шифрование включает управляемые диски.

• Процессы и методики обеспечения безопасности — обеспечение изоляции Azure также применяется внутренней службой майкрософт по использованию жизненного цикла разработки безопасности (SDL) и других надежных процессов обеспечения безопасности для защиты поверхностей атак и устранения угроз. Корпорация Майкрософт создала ведущие в отрасли процессы и инструменты, обеспечивающие высокую уверенность в гарантии изоляции Azure.

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

В этой статье в выделенных блоках текста описываются важные аспекты или действия, которые считаются частью вашей ответственности. Например, вы можете использовать Azure Key Vault для хранения секретов, включая ключи шифрования, которые остаются под контролем.

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

Изоляция на основе удостоверений

Идентификатор Microsoft Entra — это репозиторий удостоверений и облачная служба, которая обеспечивает проверку подлинности, авторизацию и управление доступом для пользователей, групп и объектов. Идентификатор Microsoft Entra можно использовать в качестве автономного облачного каталога или в качестве интегрированного решения с существующим локальным Active Directory для включения ключевых корпоративных функций, таких как синхронизация каталогов и единый вход.

Каждая подписка Azure связана с клиентом Microsoft Entra. С помощью управления доступом на основе ролей Azure (Azure RBAC), пользователей, групп и приложений из этого каталога можно предоставить доступ к ресурсам в подписке Azure. Например, учетную запись хранения можно поместить в группу ресурсов для управления доступом к определенной учетной записи хранения с помощью идентификатора Microsoft Entra. Служба хранилища Azure определяет набор встроенных ролей Azure, охватывающих общие разрешения, используемые для доступа к данным BLOB-объектов или очередей. Запрос к службе хранилища Azure можно авторизовать с помощью учетной записи Microsoft Entra или ключа учетной записи хранения. Таким образом, доступ к данным в службе хранилища Azure предоставляется только определенным пользователям.

Архитектура нулевого доверия

Все данные в Azure независимо от типа или расположения хранилища связаны с подпиской. Облачный клиент можно просмотреть как выделенный экземпляр идентификатора Microsoft Entra, который ваша организация получает и владеет при регистрации в облачной службе Майкрософт. Проверка подлинности на портале Azure выполняется через Microsoft Entra ID с использованием удостоверения, созданного в Microsoft Entra ID или федеративно связанного с локальным Active Directory. Стек удостоверений и доступа помогает обеспечить изоляцию между подписками, включая ограничение доступа к ресурсам в подписке только авторизованным пользователям. Это ограничение доступа является всеобъемлющей целью модели нулевого доверия, которая предполагает, что сеть скомпрометирована и требует фундаментального перехода от модели безопасности периметра. При оценке запросов доступа все запрашивающие пользователи, устройства и приложения должны считаться ненадежными, пока их целостность не будет проверена в соответствии с принципами проектирования нулевого доверия. Microsoft Entra ID обеспечивает надежную адаптивную проверку подлинности на основе стандартов, необходимую для платформы "Никому не доверяй".

Майкрософт Ентра айди

Разделение учетных записей, используемых для администрирования облачных приложений, крайне важно для достижения логической изоляции. Изоляция учетных записей в Azure достигается с помощью идентификатора Microsoft Entra и ее возможностей для поддержки детального управления доступом на основе ролей Azure (Azure RBAC). Каждая учетная запись Azure связана с одним клиентом Microsoft Entra. Пользователи, группы и приложения из этого каталога могут управлять ресурсами в Azure. Вы можете назначить соответствующие права доступа с помощью портала Azure, средств командной строки Azure и API управления Azure. Каждый тентант Microsoft Entra отличается и отделен от других тенантов Azure AD. Экземпляр Microsoft Entra логически изолирован с помощью границ безопасности, чтобы предотвратить смешивание данных клиента и информации об идентификации, тем самым гарантируя, что пользователи и администраторы одного идентификатора Microsoft Entra не могут ни получить доступ к данным, ни повредить их в другом экземпляре Microsoft Entra, ни злонамеренно, ни случайно. Идентификатор Microsoft Entra выполняется физически изолированно на выделенных серверах, которые логически изолированы от выделенного сетевого сегмента и где фильтрация пакетов на уровне узла и службы брандмауэра Windows обеспечивают дополнительную защиту от ненадежного трафика.

Идентификатор Microsoft Entra реализует обширные функции защиты данных, включая изоляцию клиентов и управление доступом, шифрование данных при передаче, шифрование секретов и управление ими, шифрование на уровне диска, расширенные криптографические алгоритмы, используемые различными компонентами Microsoft Entra, операционными рекомендациями по работе с данными для предварительного доступа и многое другое. Подробные сведения см. в техническом документе о безопасности данных Microsoft Entra.

Изоляция клиента в идентификаторе Microsoft Entra включает два основных элемента:

• Предотвращение утечки данных и доступа между клиентами, что означает, что данные, принадлежащие клиенту A, не могут быть получены пользователями в клиенте B без явной авторизации клиентом A.
• Изоляция доступа к ресурсам между клиентами, что означает, что операции, выполняемые клиентом A, не могут влиять на доступ к ресурсам для клиента B.

Как показано на рис. 2, доступ через идентификатор Microsoft Entra требует проверки подлинности пользователя через службу маркеров безопасности (STS). Система авторизации использует сведения о существовании и состоянии пользователя через API служб каталогов и Azure RBAC, чтобы определить, разрешен ли запрошенный доступ к целевому экземпляру Microsoft Entra для пользователя в сеансе. Помимо проверки подлинности на основе маркеров, привязанной непосредственно к пользователю, идентификатор Microsoft Entra id дополнительно поддерживает логическую изоляцию в Azure через:

• Экземпляры Microsoft Entra являются дискретными контейнерами, и между ними нет связи.
• Данные Microsoft Entra хранятся в секциях, и каждый раздел имеет предопределенный набор реплик, которые считаются предпочтительными основными репликами. Использование реплик обеспечивает высокий уровень доступности служб Microsoft Entra для поддержки разделения удостоверений и логической изоляции.
• Доступ к экземплярам Microsoft Entra не разрешен, если администратор Microsoft Entra не предоставляет его через федерацию или предоставление учетных записей пользователей из других экземпляров.
• Физический доступ к серверам, составляющим службу Microsoft Entra, и прямой доступ к внутренним системам Microsoft Entra ID ограничен надлежащим образом авторизованными операционными ролями Майкрософт с помощью системы управления привилегированным доступом JIT-In-Time (JIT).
• Пользователи Microsoft Entra не имеют доступа к физическим ресурсам или расположениям, поэтому для них невозможно обойти логические проверки политики RBAC Azure.

2. Изоляция логического клиента Microsoft Entra

В итоге подход Azure к логической изоляции клиента использует удостоверение, управляемое с помощью идентификатора Microsoft Entra ID, в качестве первой границы логического управления для предоставления доступа на уровне клиента к ресурсам и авторизации через Azure RBAC.

Управление ключами шифрования данных

Azure имеет обширную поддержку для защиты данных с помощью шифрования данных, включая различные модели шифрования:

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

Шифрование данных обеспечивает гарантии изоляции, привязанные непосредственно к доступу к ключу шифрования (криптографический). Так как Azure использует надежные шифры для шифрования данных, доступ к данным может иметь только сущности с доступом к криптографическим ключам. Удаление или отмена криптографических ключей делает соответствующие данные недоступными. Дополнительные сведения о шифровании данных при передаче предоставляются в разделе " Изоляция сети ", а шифрование неактивных данных рассматривается в разделе изоляции хранилища .

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

Azure Key Vault

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

• Хранилище поддерживает секреты, ключи и сертификаты, защищенные с помощью программного обеспечения и аппаратных модулей безопасности (HSM).
• Управляемый HSM поддерживает только криптографические ключи, защищенные HSM.

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

Служба Key Vault предоставляет абстракцию над базовыми аппаратными модулями защиты (HSM). Он предоставляет REST API для включения использования служб из облачных приложений и проверки подлинности с помощью идентификатора Microsoft Entra, чтобы обеспечить централизацию и настройку проверки подлинности, аварийного восстановления, высокого уровня доступности и эластичности. Key Vault поддерживает криптографические ключи различных типов, размеров и кривых, включая ключи RSA и Elliptic Curve. При использовании управляемых модулей HSM также доступна поддержка симметричных ключей AES.

С помощью Key Vault можно импортировать или создать ключи шифрования в HSM, гарантируя, что ключи никогда не покидают границу защиты HSM для поддержки сценариев создания собственного ключа (BYOK), как показано на рис. 3.

рис. 3. Поддержка Azure Key Vault для получения собственного ключа (BYOK)

Ключи, созданные внутри HSM Key Vault, не экспортируются. Нет четкой текстовой версии ключа за пределами HSM. Эта привязка применяется базовым HSM. Функциональность BYOK доступна как в хранилищах ключей, так и в управляемых модулях HSM. Методы передачи ключей, защищённых модулями HSM, в "Key Vault" зависят от базового HSM, как описано в онлайн документации.

Key Vault предоставляет надежное решение для управления жизненным циклом ключей шифрования. После создания каждое хранилище ключей или управляемое устройство HSM автоматически связывается с клиентом Microsoft Entra, которому принадлежит подписка. Любой пользователь, пытающийся управлять или извлекать содержимое из хранилища ключей или управляемого устройства HSM, должен быть правильно проверен и авторизован:

• Аутентификация определяет личность вызывающего абонента (пользователя или приложения).
• Авторизация определяет, какие операции может выполнять вызывающий объект, на основе сочетания управления доступом на основе ролей Azure (Azure RBAC) и политики доступа к хранилищу ключей или управляемого локального RBAC HSM.

Идентификатор Microsoft Entra применяет изоляцию клиента и реализует надежные меры, чтобы предотвратить доступ неавторизованных сторон, как описано ранее в разделе идентификатора Microsoft Entra ID . Доступ к хранилищу ключей или управляемому HSM осуществляется через два интерфейса или плоскости — плоскость управления и плоскость данных — при помощи идентификатора Microsoft Entra для проверки подлинности.

• Плоскость управления позволяет управлять хранилищем ключей или управляемым HSM, например создавать и удалять хранилища ключей или управляемые HSM, извлекать хранилище ключей или управляемые свойства HSM, а также обновлять политики доступа. Для авторизации управляющая плоскость использует Azure RBAC как с хранилищами ключей, так и управляемыми HSM.
• Плоскость данных позволяет вам управлять данными, хранящимися в хранилищах ключей и управляемыми модулями безопасности (HSM), включая добавление, удаление и изменение данных. Для хранилищ сохраненные данные могут включать ключи, секреты и сертификаты. Для управляемых виртуальных машин HSM сохраненные данные ограничены только криптографическими ключами. Для авторизации канал данных использует политику доступа Key Vault и Azure RBAC для операций с хранилищами ключей или локальные RBAC для управляемых HSM.

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

Вы управляете разрешениями доступа и можете извлекать подробные журналы действий из службы Azure Key Vault. Azure Key Vault регистрирует следующие сведения:

• Все запросы REST API, прошедшие проверку подлинности, включая неудачные запросы
  • Операции с хранилищем ключей, такими как создание, удаление, настройка политик доступа и т. д.
  • Операции с ключами и секретами в хранилище ключей, включая а) создание, изменение или удаление ключей или секретов, а также подпись, проверка, шифрование ключей и т. д.
• Запросы, не прошедшие проверку подлинности, такие как запросы, у которых нет маркера носителя, имеют неправильный формат или истек срок действия или имеют недопустимый маркер.

Вы также можете использовать решение Azure Key Vault в Azure Monitor для просмотра журналов Key Vault. Чтобы использовать это решение, необходимо включить ведение журнала диагностики Key Vault и направить диагностику в рабочую область Log Analytics. В этом решении не требуется записывать журналы в хранилище BLOB-объектов Azure.

Хранилище

Хранилища предоставляют мультиарендное, дешёвое, простое в развертывании, устойчивое на уровне зоны (где доступно) и высокодоступное решение для управления ключами, подходящее для наиболее распространенных сценариев облачных приложений. Хранилища могут хранить и защищать секреты, ключи и сертификаты. Они могут быть защищены программно (стандартный уровень) или модулем HSM (уровень "Премиум"). Сравнение ценовой категории "Стандартный" и "Премиум" см. на странице цен Azure Key Vault. Защищенные программным обеспечением секреты, ключи и сертификаты защищены Azure, используя стандартные алгоритмы и длины ключей. Если вам требуется дополнительная гарантия, вы можете защитить свои секреты, ключи и сертификаты в хранилищах, которые защищены аппаратными средствами безопасности с многопользовательской архитектурой. Соответствующие HSM сертифицированы в соответствии со стандартом FIPS 140 и имеют общий рейтинг уровня безопасности 2, который включает требования к физическим доказательствам вскрытия и аутентификации на основе ролей.

Хранилища обеспечивают поддержку ключей, управляемых клиентом (CMK), где можно управлять собственными ключами в HSM и использовать их для шифрования неактивных данных для многих служб Azure. Как упоминалось ранее, вы можете импортировать или создать ключи шифрования в HSM, гарантируя, что ключи никогда не покидают границу HSM для поддержки сценариев использования собственного ключа (BYOK ).

Key Vault может обрабатывать запросы и продление сертификатов в хранилищах, включая сертификаты TLS, что позволяет регистрировать и автоматически обновлять сертификаты из поддерживаемых общедоступных центров сертификации. Поддержка сертификатов Key Vault обеспечивает управление сертификатами X.509, которые основаны на ключах и предоставляют функцию автоматического продления. Владелец сертификата может создать сертификат с помощью Azure Key Vault или импортировать существующий сертификат. Поддерживаются как самозаверяющие сертификаты, так и сертификаты, выданные центром сертификации. Кроме того, владелец сертификата Key Vault может реализовать безопасное хранилище и управление сертификатами X.509 без взаимодействия с закрытыми ключами.

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

Управляемый модуль HSM

Управляемый HSM предоставляет единый клиент, полностью управляемый, высокодоступный, устойчивый к зонам (где доступен) HSM в качестве службы для хранения криптографических ключей и управления ими. Этот модуль лучше всего подходит для приложений и сценариев использования с особо ценными ключами. Это также помогает соответствовать самым строгим требованиям к безопасности, соответствию и нормативным требованиям. Управляемый модуль HSM использует HSM, сертифицированные на соответствие стандарту FIPS 140 уровня 3 для защиты криптографических ключей. Каждый управляемый пул HSM является изолированным экземпляром с одним клиентом с собственным доменом безопасности , контролируемым вами и изолированным криптографически от экземпляров, принадлежащих другим клиентам. Криптографическая изоляция использует технологию Intel Software Guard Extensions (SGX), которая предоставляет зашифрованный код и данные, чтобы обеспечить контроль над криптографическими ключами.

При создании управляемого устройства HSM запрашивающий также предоставляет список администраторов на уровне данных. Только эти администраторы могут получить доступ к управляемой плоскости данных HSM для выполнения ключевых операций и управления назначениями ролей для плоскости данных (локальная RBAC управляемого HSM). Модель разрешений для уровней управления и данных использует тот же синтаксис, но разрешения обеспечиваются на разных уровнях, а для назначений ролей используются разные области. Управляющая плоскость Azure RBAC применяется через Azure Resource Manager, в то время как локальный RBAC для плоскости данных управляемого HSM применяется непосредственно управляемым HSM.

Как упоминалось ранее, управляемый HSM поддерживает импорт ключей, созданных в локальных устройствах HSM, гарантируя, что ключи никогда не покидают границу защиты HSM, также известной как сценарий создания собственного ключа (BYOK). Управляемый HSM поддерживает интеграцию со службами Azure, такими как служба хранилища Azure, База данных SQL Azure, Azure Information Protection и другие. Полный список служб Azure, работающих с управляемым HSM, см. в разделе "Модели шифрования данных".

Управляемый HSM позволяет использовать установленные интерфейсы API Azure Key Vault и интерфейсы управления. Вы можете использовать одинаковые шаблоны разработки и развертывания приложений для всех приложений независимо от решения управления ключами: мультитенантного хранилища или управляемого HSM с одним клиентом.

Изоляция вычислительных ресурсов

Платформа вычислений Microsoft Azure основана на виртуализации машин. Этот подход означает, что ваш код, выполняется ли он в роли рабочего процесса PaaS или на виртуальной машине IaaS, исполняется на виртуальной машине, размещенной гипервизором Windows Server Hyper-V. На каждом физическом сервере Azure, также называемом узлом, работает гипервизор типа 1, который выполняется непосредственно на оборудовании и делит узел на переменное количество гостевых виртуальных машин (VM), как показано на рис. 4. Каждый узел имеет одну специальную виртуальную машину Host VM, также известную как корневая виртуальная машина, которая запускает Host OS — настраиваемую и защищённую версию последней Windows Server, которая урезана, чтобы уменьшить поверхность атаки и включать только те компоненты, которые необходимы для управления узлом. Изоляция корневой виртуальной машины от гостевых виртуальных машин и гостевых виртуальных машин друг от друга — это ключевая концепция в архитектуре безопасности Azure, которая формирует основу изоляции вычислений Azure, как описано в документации Майкрософт по Сети.

рис. 4. Изоляция гипервизора, корневой виртуальной машины и гостевых виртуальных машин

Физические серверы, на которых размещаются виртуальные машины, группируются в кластеры, и они независимо управляются масштабируемым и избыточным программным компонентом платформы с именем контроллера Структуры (FC). Каждый ФК управляет жизненным циклом виртуальных машин, работающих в своем кластере, включая подготовку и мониторинг работоспособности оборудования под его контролем. Например, ФК отвечает за повторное создание экземпляров виртуальных машин на работоспособных серверах при определении сбоя сервера. Он также выделяет ресурсы инфраструктуры для рабочих нагрузок клиента и управляет однонаправленным обменом данными с узла на виртуальные машины. Разделение вычислительной инфраструктуры на кластеры, изолирует ошибки на уровне FC и предотвращает влияние определенных классов ошибок за пределами кластера, в котором они происходят.

ФК является центральным компонентом вычислительной платформы Azure, а агент узла выступает его прокси-сервером, интегрируя серверы в платформу, чтобы ФК мог развертывать, отслеживать и управлять виртуальными машинами, используемыми вами и облачными сервисами Azure. Связывание гипервизора и операционной системы узла использует десятилетия опыта Microsoft в обеспечении безопасности операционной системы, включая инвестиции, ориентированные на безопасность в Microsoft Hyper-V, чтобы обеспечить надежную изоляцию гостевых виртуальных машин. Изоляция гипервизора рассматривается далее в этом разделе, включая обеспечение формально определенных границ безопасности, применяемых гипервизором, меры защиты с глубокой проработкой от атак и надежные процессы гарантирования безопасности.

Изоляция сети управления

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

• Основная виртуальная сеть соединяет недоверенные узлы клиентов
• Сетевой сегмент контроллера Fabric (FC), содержащий доверенные FC и вспомогательные системы
• Виртуальная локальная сеть устройств, включающая доверенную сеть и другие инфраструктурные устройства.

Связь разрешена из FC VLAN к главной VLAN, но не может быть инициирована из главной VLAN к FC VLAN. Мост от FC VLAN к основной VLAN используется для снижения общей сложности и повышения надежности и устойчивости сети. Подключение защищено несколькими способами для обеспечения доверенности и успешной маршрутизации команд.

• Связь от FC к агенту Fabric (FA) является однонаправленной и требует взаимной аутентификации с помощью сертификатов. FA осуществляет защищённую TLS службу, которая отвечает только на запросы от FC. Он не может инициировать подключения к ФК или другим привилегированным внутренним узлам.
• ФК обрабатывает ответы от службы агента, как если бы они не были доверенными. Обмен данными с агентом также ограничен набором авторизованных IP-адресов с помощью правил брандмауэра на каждом физическом узле и правил маршрутизации на пограничных шлюзах.
• Ограничение пропускной способности используется для предотвращения того, чтобы клиентские виртуальные машины не могли насытить сеть и нарушить маршрутизацию команд управления.

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

Эти элементы управления гарантируют, что доступ консоли управления к гипервизору всегда действителен и доступен.

Рисунок 5. Изоляция ВЛАН

Гипервизор и ОС узла предоставляют фильтры сетевых пакетов, которые помогают гарантировать, что ненадежные виртуальные машины не могут генерировать спуфированный трафик, получать трафик, не адресованный им, направлять трафик к защищенным конечным точкам инфраструктуры или отправлять и получать недопустимый широковещательный трафик. По умолчанию трафик блокируется при создании виртуальной машины, а затем агент FC настраивает фильтр пакетов для добавления правил и исключений для разрешения авторизованного трафика. Дополнительные сведения об изоляции сетевого трафика и разделения трафика клиента приведены в разделе "Изоляция сети ".

Консоль управления и плоскость управления

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

• Консоль управления (MC) — MC в облаке Azure состоит из графического интерфейса портала Azure и уровней API Azure Resource Manager. Они используют учетные данные пользователя для проверки подлинности и авторизации всех операций.
• Плоскость управления (MP) — этот уровень выполняет фактические действия управления и состоит из поставщика вычислительных ресурсов (CRP), контроллера структуры (FC), агента Структуры (FA) и базового гипервизора, который имеет собственный агент гипервизора для обмена данными. Эти слои используют системные контексты, которые предоставляют минимальные разрешения, необходимые для выполнения своих операций.

Azure FC выделяет ресурсы инфраструктуры арендаторам и управляет однонаправленными коммуникациями от Host OS к гостевым виртуальным машинам. Алгоритм размещения виртуальных машин в Azure FC очень сложный и почти невозможно предсказать. FA находится в операционной системе хоста и управляет виртуальными машинами арендаторов. Коллекция гипервизора Azure, ОС узла и FA и клиентских виртуальных машин представляет собой вычислительный узел, как показано на рис. 4. FCs управляют FAs, хотя FCs расположены вне вычислительных узлов — существуют отдельные FCs для управления кластерами вычислений и хранения данных. Если вы обновляете файл конфигурации приложения во время работы в MC, MC взаимодействует через CRP с FC, а ФК взаимодействует с FA.

CRP — это интерфейсная служба для вычислений Azure, предоставляющая согласованные API вычислений с помощью Azure Resource Manager, что позволяет создавать ресурсы и расширения виртуальных машин и управлять ими с помощью простых шаблонов.

Обмен данными между различными компонентами (например, Azure Resource Manager с и в CRP, CRP с и в FC, FC с и в агентом гипервизора) осуществляется через разные каналы связи с различными идентификаторами и наборами разрешений. Эта архитектура следует общепринятым моделям наименьших привилегий, чтобы в случае компрометации одного слоя предотвратить выполнение дальнейших действий. Отдельные каналы связи гарантируют, что обмен данными не может обойти ни один слой в цепочке. На рисунке 6 показано, как MC и MP безопасно взаимодействуют в облаке Azure для связи с гипервизором, инициированной аутентификацией пользователя по OAuth 2.0 в Microsoft Entra ID.

рис. 6. Взаимодействие консоли управления и плоскости управления для безопасного потока управления

Все команды управления проходят проверку подлинности через подписанный сертификат RSA или веб-токен JSON (JWT). Каналы проверки подлинности и команд шифруются через TLS 1.2, как описано в разделе "Шифрование данных" в разделе транзита . Серверные сертификаты используются для обеспечения TLS-подключения к поставщикам аутентификации, где применяется отдельный механизм авторизации, например, Microsoft Entra ID или служба токенов безопасности дата-центра (dSTS). dSTS — это поставщик токенов, такой как Microsoft Entra ID, изолированный в центрах обработки данных Microsoft и используемый для обмена данными на уровне обслуживания.

На рисунке 6 показан поток управления, соответствующий команде пользователя, чтобы остановить виртуальную машину. Шаги, перечисленные в таблице 1, применяются к другим командам управления таким же образом и используют тот же поток шифрования и проверки подлинности.

Таблица 1. Управляющий поток с участием различных компонентов MC и MP

Команды, сформированные на всех этапах процесса, определенного в этом разделе, отправляются в системы FC и FA на каждом узле, записываются в локальный журнал аудита и распределяются по различным аналитическим системам для потоковой обработки, чтобы отслеживать состояние системы и выявлять события и закономерности в области безопасности. Отслеживание включает события, которые были обработаны успешно, и события, которые были недопустимыми. Недопустимые запросы обрабатываются системами обнаружения вторжений для обнаружения аномалий.

Варианты реализации логической изоляции

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

• Изоляция гипервизора для служб, которые обеспечивают криптографически определенную изоляцию с помощью отдельных виртуальных машин и использования изоляции Гипервизора Azure. Примеры: Служба приложений, экземпляры контейнеров Azure, Azure Databricks, Функции Azure, Служба Azure Kubernetes, Машинное обучение Azure, облачные службы, фабрика данных, Service Fabric, виртуальные машины, масштабируемые наборы виртуальных машин.
• Изоляция Drawbridge внутри виртуальной машины для служб, которые обеспечивают криптографически определенную изоляцию для рабочих нагрузок, работающих на одной виртуальной машине, с помощью изоляции, предоставляемой Drawbridge. Эти службы предоставляют небольшие единицы обработки с помощью клиентского кода. Чтобы обеспечить изоляцию безопасности, Drawbridge запускает пользовательский процесс вместе с облегчённой версией ядра Windows (библиотеки ОС) внутри пико-процесса. Пико-процесс — это защищенный процесс без прямого доступа к службам или ресурсам системы узла. Примеры: автоматизация, База данных Azure для MySQL, База данных Azure для PostgreSQL, База данных SQL Azure, Azure Stream Analytics.
• Изоляция на основе контекста пользователей для служб, состоящих исключительно из управляемого корпорацией Майкрософт кода и клиентского кода, не разрешена. Примеры : управление API, шлюз приложений, идентификатор Microsoft Entra, Azure Backup, Кэш Azure для Redis, Azure DNS, Azure Information Protection, Центр Интернета вещей Azure, Azure Key Vault, портал Azure, Azure Monitor (включая Log Analytics), Microsoft Defender для облака, Azure Site Recovery, реестр контейнеров, сеть доставки содержимого, сетка событий, центры событий, Подсистема балансировки нагрузки, служебная шина, хранилище, виртуальная сеть, VPN-шлюз, Диспетчер трафика.

Эти параметры логической изоляции рассматриваются в остальной части этого раздела.

Изоляция гипервизора

Изоляция гипервизора в Azure основана на технологии Microsoft Hyper-V, которая позволяет использовать преимущества гипервизора Azure за счет десятилетий опыта Microsoft в области безопасности операционных систем и инвестиций Microsoft в технологию Hyper-V для изоляции виртуальных машин. Вы можете ознакомиться с независимыми отчетами об оценке сторонних организаций о функциях безопасности Hyper-V, включая отчеты Национального партнерства в области обеспечения информации (NIAP) по Схеме оценки и проверки Общих критериев (CCEVS), такие как отчет, опубликованный в феврале 2021 года, который обсуждается здесь.

Цель оценки (TOE) состоит из Microsoft Windows Server, Microsoft Windows 10 версии 1909 (обновление ноября 2019 г.) и Microsoft Windows Server 2019 (версия 1809) Hyper-V («Windows»). TOE применяет следующие политики безопасности, как описано в отчете:

• Аудит безопасности — Windows имеет возможность собирать данные аудита, просматривать журналы аудита, защищать журналы аудита от переполнения и ограничивать доступ к журналам аудита. Сведения аудита, созданные системой, включают дату и время события, удостоверение пользователя, вызвавшее создание события, и другие данные, относящиеся к событиям. Авторизованные администраторы могут просматривать, выполнять поиск и сортировку записей аудита. Авторизованные администраторы также могут настроить систему аудита для включения или исключения потенциально проверяемых событий на основе многих характеристик. В контексте этой оценки требования к профилю защиты охватывают создание событий аудита, авторизованную проверку сохраненных записей аудита и обеспечение безопасного хранилища для записей событий аудита.
• Поддержка шифрования — Windows предоставляет проверенные криптографические функции, поддерживающие шифрование и расшифровку, криптографические подписи, криптографические хэширование и случайное создание чисел. Windows реализует эти функции в поддержке реализации протокола IPsec, TLS и HTTPS. Windows также гарантирует, что гостевые виртуальные машины имеют доступ к данным энтропии, чтобы виртуализированные операционные системы могли обеспечить реализацию строгой криптографии.
• Защита данных пользователей — Windows делает определенные вычислительные службы доступными для гостевых виртуальных машин, но реализует меры, чтобы обеспечить доступ к этим службам соответствующим образом, и что эти интерфейсы не приводят к несанкционированной утечке данных между гостевыми виртуальными машинами и Windows или несколькими гостевыми виртуальными машинами.
• Идентификация и проверка подлинности — Windows предлагает несколько методов проверки подлинности пользователей, включая сертификаты X.509, необходимые для доверенных протоколов. Windows реализует механизмы контроля надежности паролей и гарантирует, что чрезмерные неудачные попытки проверки подлинности, использующие методы, подвержены атакам методом перебора (пароль, ПИН-код), приводят к блокировке.
• Управление безопасностью — Windows включает несколько функций для управления политиками безопасности. Доступ к административным функциям обеспечивается через административные роли. Windows также имеет возможность поддерживать разделение управления и операционных сетей и запретить общий доступ к данным между гостевыми виртуальными машинами.
• Защита функций безопасности TOE (TSF) — Windows реализует различные механизмы самозащиты, чтобы гарантировать, что он не может использоваться в качестве платформы для несанкционированного доступа к данным, хранящимся на гостевой виртуальной машине, что целостность как TSF, так и гостевых виртуальных машин поддерживается, и что гостевые виртуальные машины обращаются исключительно через хорошо документированные интерфейсы.
• TOE Access — в контексте этой оценки Windows позволяет авторизованному администратору настроить систему для отображения баннера входа перед диалогом входа.
• Доверенный путь или каналы — Windows реализует доверенные каналы и пути IPsec, TLS и HTTPS для удаленного администрирования, передачи данных аудита в операционную среду, а также разделение управления и операционных сетей.

Дополнительные сведения см. в отчете о сертификации сторонних производителей.

Критическая изоляция гипервизора обеспечивается через:

• Строго определенные границы безопасности, применяемые гипервизором
• Глубокая защита смягчает эксплойты
• Надежные процессы обеспечения безопасности

Эти технологии описаны в остальной части этого раздела. Они позволяют Гипервизору Azure предоставлять надежные гарантии безопасности для разделения клиентов в мультитенантном облаке.

Строго определенные границы безопасности

Код выполняется на виртуальной машине с гипервизором и использует обеспечиваемые гипервизором границы безопасности, как показано на рисунке 7. Гипервизор Azure основан на технологии Microsoft Hyper-V . Он делит узел Azure на переменное количество гостевых виртуальных машин с отдельными адресными пространствами, где они могут загружать операционную систему (ОС) и приложения, работающие параллельно с ОС узла, которая выполняется в корневой секции узла.

рис. 7. Изоляция вычислений с помощью гипервизора Azure (см. глоссарий терминов в Интернете)

Гипервизор Azure действует как микро-ядро, передавая через интерфейс общей памяти под названием VMBus все запросы на доступ к оборудованию от гостевых виртуальных машин с помощью клиента службы виртуализации (VSC) в ОС узла для обработки. Хостовая ОС обрабатывает аппаратные запросы с помощью поставщика служб виртуализации (VSP), который запрещает пользователям получать прямой доступ к операциям чтения, записи и выполнения в системе, что снижает риск совместного использования системных ресурсов. Привилегированный корневой раздел, также известный как ОС узла, имеет прямой доступ к физическим устройствам и периферийным устройствам в системе, например контроллерам хранилища, gpuUs, сетевым адаптерам и т. д. Хостовая ОС позволяет гостевым разделам совместно использовать эти физические устройства, предоставляя каждой гостевой секции виртуальные устройства. Таким образом, операционная система, выполняемая в гостевой секции, имеет доступ к виртуализированным периферийным устройствам, предоставляемым VSPs, выполняемым в корневой секции. Эти представления виртуальных устройств могут принимать одну из трех форм:

• Эмулированные устройства — ОС узла может предоставлять виртуальное устройство с интерфейсом, идентичным тому, что будет предоставлено соответствующим физическим устройством. В этом случае операционная система в гостевой секции будет использовать те же драйверы устройств, что и при запуске в физической системе. Основная ОС эмулирует поведение физического устройства к гостевому разделу.
• Пара-виртуализированные устройства — ОС узла может предоставлять виртуальные устройства с интерфейсом для виртуализации с помощью интерфейса общей памяти VMBus между ОС узла и гостевым. В этой модели гостевой раздел использует драйверы устройств, специально разработанные для реализации виртуализированного интерфейса. Эти пара-виртуализированные устройства иногда называются искусственными.
• Устройства с аппаратным ускорением. Операционная система хоста может предоставлять физические периферийные устройства непосредственно в гостевой раздел. Эта модель обеспечивает высокую производительность ввода-вывода в гостевой секции, так как гостевая секция может напрямую обращаться к ресурсам аппаратного устройства без прохождения операционной системы узла. Ускоренная сеть Azure — это пример аппаратного ускорения устройства. Изоляция в этой модели достигается с помощью единиц управления памятью ввода-вывода (МММ ввода-вывода) для обеспечения адресного пространства и изоляции прерываний для каждой секции.

Расширения виртуализации в ЦП узла позволяют гипервизору Azure обеспечить изоляцию между секциями. Следующие основные возможности ЦП предоставляют аппаратные блоки для изоляции гипервизора:

• Преобразование адресов второго уровня — гипервизор управляет ресурсами памяти, к которым разрешен доступ секции с помощью таблиц страниц второго уровня, предоставляемых единицей управления памятью ЦП (MMU). MMU ЦП использует преобразование адресов второго уровня в элементе управления гипервизором для обеспечения защиты доступа к памяти, выполняемого следующими способами:
  • ЦП при выполнении в контексте раздела.
  • Устройства ввода-вывода, доступ к которым осуществляется непосредственно по гостевым секциям.
• Контекст ЦП — гипервизор использует расширения виртуализации в ЦП для ограничения привилегий и контекста ЦП, к которым можно получить доступ во время выполнения гостевой секции. Гипервизор также использует эти средства для сохранения и восстановления состояния при совместном использовании ЦП между несколькими секциями, чтобы обеспечить изоляцию состояния ЦП между секциями.

Гипервизор Azure использует эти процессорные средства для обеспечения изоляции между секциями. Появление спекулятивных атак через побочные каналы выявило потенциальные недостатки некоторых возможностей изоляции процессора. В многопользовательской архитектуре любая межвиртуальная атака между различными клиентами включает два этапа: помещения управляемой злоумышленником виртуальной машины на тот же хост, что и одна из виртуальных машин жертвы, а затем нарушение границы логической изоляции для выполнения атаки по сторонним каналам. Azure обеспечивает защиту от векторов угроз с помощью расширенного алгоритма размещения виртуальных машин, применяющего разделение памяти и процесса для логической изоляции, и безопасной маршрутизации сетевого трафика с криптографической уверенностью в гипервизоре. Как описано в разделе " Эксплуатация уязвимостей в технологиях виртуализации " далее в статье, гипервизор Azure был разработан для обеспечения надежной изоляции непосредственно в гипервизоре, которая помогает устранить множество сложных атак на стороне канала.

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

• Изоляция сетевого трафика между потенциально враждебными гостями — виртуальная сеть обеспечивает изоляцию сетевого трафика между клиентами в рамках его основной структуры, как описано далее в разделе "Разделение сетевого трафика клиента ". Виртуальная сеть формирует границу изоляции, в которой виртуальные машины в виртуальной сети могут взаимодействовать только друг с другом. Любой трафик, предназначенный для виртуальной машины из виртуальной сети или внешних отправителей без соответствующей политики, будет удален узлом и не доставлен на виртуальную машину.
• Изоляция ключей шифрования и криптографических материалов . Вы можете дополнительно расширить возможности изоляции с помощью аппаратных диспетчеров безопасности или специализированного хранилища ключей, например хранение ключей шифрования в FIPS 140 проверенных аппаратных модулей безопасности (HSM) через Azure Key Vault.
• Планирование системных ресурсов — проектирование Azure включает гарантированную доступность и сегментацию вычислительных ресурсов, памяти, хранилища и прямого и пара-виртуализированного доступа к устройству.

Гипервизор Azure соответствует целям безопасности, показанным в таблице 2.

Таблица 2. Цели безопасности гипервизора Azure

Смягчение атак по принципу защиты в глубину

Для дальнейшего снижения риска компрометации безопасности корпорация Майкрософт инвестировала в многочисленные средства устранения рисков на глубину защиты в программном обеспечении, оборудовании и встроенном ПО Azure, чтобы обеспечить надежные гарантии изоляции в реальном мире клиентам Azure. Как упоминалось ранее, изоляция гипервизора Azure основана на технологии Microsoft Hyper-V , которая позволяет Гипервизору Azure воспользоваться десятилетиями работы Майкрософт в области безопасности операционной системы и инвестиций в Hyper-V технологии изоляции виртуальных машин.

Ниже приведены некоторые основные принципы проектирования, принятые корпорацией Майкрософт для защиты Hyper-V:

• Запретить проблемам уровня разработки влиять на продукт
  • Каждое изменение, вносимое в Hyper-V, подлежит дизайнерскому обзору.
• Устранение распространенных классов уязвимостей с безопасным кодом
  • Некоторые компоненты, такие как VMSwitch, используют формально проверенный средство синтаксического анализа протокола.
  • Многие компоненты используются gsl::span вместо необработанных указателей, что устраняет возможность переполнения буфера и (или) доступа к памяти вне границ. Дополнительные сведения см. в документации по библиотеке поддержки рекомендаций (GSL ).
  • Многие компоненты используют умные указатели для устранения риска ошибок использование после удаления.
  • В большинстве случаев код ядра Hyper-V использует распределитель памяти, который обнуляет выделяемую память для устранения ошибок неинициализированной памяти.
• Устраните распространенные классы уязвимостей с помощью методов защиты компилятора
  • Весь код Hyper-V компилируется с помощью InitAll, что устраняет неинициализированные переменные стека. Этот подход был реализован, так как многие исторические уязвимости в Hyper-V были вызваны неинициализированными переменными стека.
  • Весь Hyper-V код компилируется с стековыми канарейками, чтобы значительно снизить риск уязвимостей переполнения стека.
• Поиск проблем, которые проникают в продукт
  • Весь код Windows охвачен набором правил статического анализа, применяемых к нему.
  • Весь код Hyper-V проверяется и проходит фаззинг-тестирование. Дополнительные сведения о нечеткости см. в разделе "Процессы и методики обеспечения безопасности " далее в этой статье.
• Сделать эксплуатацию оставшихся уязвимостей более сложной
  • Рабочий процесс виртуальной машины имеет следующие способы устранения рисков:
    • Защита от произвольного кода — динамически сгенерированный код нельзя загрузить в процесс рабочей виртуальной машины.
    • Code Integrity Guard — в рабочий процесс виртуальной машины можно загрузить только подписанный корпорацией Майкрософт код.
    • Control Flow Guard (CFG) — обеспечивает защиту потока управления курсом для непрямых вызовов и переходов.
    • NoChildProcess — рабочий процесс не может создавать дочерние процессы (полезно для обхода CFG).
    • NoLowImages / NoRemoteImages — рабочий процесс не может загружать библиотеки DLL через сеть или библиотеки DLL, записанные на диск изолированным процессом.
    • NoWin32k — рабочий процесс не может взаимодействовать с Win32k, что усложняет обход песочницы.
    • Случайность кучи — Windows поставляется с одной из самых безопасных реализаций кучи среди всех операционных систем.
    • Выборка макета адресного пространства (ASLR) — случайным образом определяет макет кучи, стеки, двоичные файлы и другие структуры данных в адресном пространстве, чтобы сделать эксплуатацию менее надежным.
    • Предотвращение выполнения данных (DEP/NX) — выполняются только страницы памяти, предназначенные для хранения кода.
  • Ядро имеет следующие меры по смягчению:
    • Случайное распределение кучи — Windows поставляется с одной из самых защищённых реализаций кучи среди всех операционных систем.
    • Рандомизация адресного пространства (ASLR) — рандомизирует макет куч, стеков, двоичных файлов и других структур данных в адресном пространстве, чтобы сделать эксплуатацию менее надежной.
    • Предотвращение выполнения данных (DEP/NX) — выполняются только страницы памяти, предназначенные для хранения кода.

Инвестиции Майкрософт в безопасность Hyper-V непосредственно приносят пользу Azure Hypervisor. Цель защитных мер в глубину состоит в том, чтобы сделать эксплуатацию уязвимости для злоумышленника как можно более дорогостоящей, ограничивая влияние уязвимостей и максимизируя время для обнаружения. Все меры по устранению рисков эксплойтов оцениваются для эффективности путем тщательного проверки безопасности области атак Гипервизора Azure с помощью методов, которые могут использовать злоумышленники. В таблице 3 описаны некоторые способы устранения рисков, предназначенных для защиты границ изоляции гипервизора и целостности оборудования.

Таблица 3. Глубокоэшелонированная защита гипервизора Azure

Кроме того, Azure использует стратегию безопасности "предполагаемого нарушения", реализованную с помощью методов Red Teaming. Этот подход основан на выделенной группе исследователей и инженеров по безопасности, которые проводят непрерывное тестирование систем и операций Azure, используя ту же тактику, методы и процедуры, что и настоящие противники в рабочей инфраструктуре, без ведома команд разработки и эксплуатации инфраструктуры и платформы Azure. Этот подход проверяет возможности обнаружения безопасности и реагирования и помогает выявлять уязвимости рабочей среды в гипервизоре Azure и других системах, включая ошибки конфигурации, недопустимые предположения или другие проблемы безопасности в управляемом режиме. Корпорация Майкрософт в значительной степени инвестирует в эти инновационные меры безопасности для непрерывного устранения угроз Azure.

Надежные процессы обеспечения безопасности

Поверхность атаки в Hyper-V хорошо понятна. Это была тема продолжающихся исследований и тщательных проверок безопасности. Корпорация Майкрософт является прозрачной в отношении поверхности атак Hyper-V и базовой архитектуры безопасности, что было продемонстрировано во время публичной презентации на конференции Black Hat в 2018 году. Корпорация Майкрософт гарантирует надежность и качество изоляции Hyper-V с помощью программы вознаграждений с суммой до 250 000 долларов США для критически важных уязвимостей удаленного выполнения кода (RCE), раскрытия информации и уязвимостей типа "отказ в обслуживании" (DOS), сообщаемых в платформе виртуализации Hyper-V. Используя ту же технологию Hyper-V в Windows Server и облачной платформе Azure, общедоступная документация и программа поощрений за нахождение ошибок гарантируют, что улучшения безопасности будут приносить пользу всем пользователям продуктов и служб Майкрософт. В таблице 4 приведены ключевые точки атаки из презентации Black Hat.

Таблица 4. сведения о поверхности атаки Hyper-V

Для защиты этих поверхностей атак корпорация Майкрософт создала ведущие в отрасли процессы и средства, обеспечивающие высокую уверенность в гарантии изоляции Azure. Как описано в разделе "Процессы и методики обеспечения безопасности " далее в этой статье, подход включает в себя специально разработанный фаззинг, тестирование на проникновение, жизненный цикл безопасной разработки, обязательное обучение безопасности, проверки безопасности, обнаружение вторжений на основе индикаторов угроз типа Гость – Хост и автоматическое оповещение о изменениях в области атаки. Этот зрелый многомерный процесс обеспечения безопасности помогает расширить гарантии изоляции, предоставляемые гипервизором Azure, смягчив риск уязвимостей безопасности.

Изоляция мостика

Для служб, предоставляющих небольшие единицы обработки с помощью клиентского кода, запросы от нескольких клиентов выполняются на одной виртуальной машине и изолированы с помощью технологии Microsoft Drawbridge . Чтобы обеспечить изоляцию безопасности, Drawbridge запускает пользовательский процесс вместе с упрощенной версией ядра Windows (ОС библиотеки) внутри пико-процесса. Пико-процесс — это лёгкий, безопасный контейнер изоляции с минимальной поверхностью API ядра и без прямого доступа к службам или ресурсам хост-системы. Единственными внешними вызовами, которые может выполнять пико-процесс, являются вызовы к Монитору безопасности Drawbridge через двоичный интерфейс приложения Drawbridge (ABI), как показано на рис. 8.

Рисунок 8. Изоляция процесса с помощью Drawbridge

Монитор безопасности делится на системный драйвер устройства и компонент пользовательского режима. ABI — это интерфейс между ОС библиотеки и узлом. Весь пользовательский интерфейс состоит из закрытого набора меньше 50 функциональных вызовов без сохранения состояния.

• Вызовы от процесса pico-process к ОС узла поддерживают абстракции, такие как потоки, виртуальные память и потоки ввода-вывода.
• Вызовы в pico-процесс выполняют инициализацию, возвращают информацию об исключениях и запускаются в новом потоке.

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

ABI реализуется в двух компонентах:

• Уровень адаптации платформы (PAL) выполняется как часть пико-процесса.
• Реализация хоста выполняется как часть хоста.

Пико-процессы объединяются в единицы изоляции, называемые песочницами. Sandbox определяет приложения, файловую систему и внешние ресурсы, доступные для пико-процессов. Когда процесс, выполняющийся внутри пико-процесса, создает новый дочерний процесс, он запускается с собственной операционной системой библиотеки в отдельном пико-процессе внутри той же песочницы. Каждая песочница взаимодействует с монитором безопасности и не может взаимодействовать с другими песочницами, за исключением разрешенных каналов ввода-вывода (сокетов, именованных каналов и т. д.), которые должны быть явно разрешены конфигурацией, учитывая подход по умолчанию в зависимости от потребностей службы. Результатом является то, что код, выполняемый внутри пико-процесса, может получить доступ только к собственным ресурсам и не может напрямую атаковать хост-систему или какие-либо совместно размещенные песочницы. Он может влиять только на объекты внутри собственной песочницы.

Когда пико-процесс нуждается в системных ресурсах, он должен обратиться к хосту Drawbridge, чтобы запросить их. Обычный путь для процесса виртуального пользователя — вызвать Библиотечную ОС для запроса ресурсов, а затем Библиотечная ОС вызовет ABI. Если политика выделения ресурсов не настроена в самом драйвере, монитор безопасности будет обрабатывать запрос ABI, проверяя, разрешен ли запрос, а затем обслуживание запроса. Этот механизм используется для всех системных примитивов, поэтому гарантирует, что код, выполняемый в пико-процессе, не может злоупотреблять ресурсами хост-машины.

Помимо изоляции внутри песочниц, пико-процессы также существенно изолированы друг от друга. Каждый процесс pico находится в собственном адресном пространстве виртуальной памяти и запускает собственную копию ОС библиотеки с собственным ядром пользовательского режима. Каждый раз, когда процесс пользователя запускается в песочнице Drawbridge, загружается новый экземпляр библиотечной ОС. Хотя эта задача занимает больше времени по сравнению с запуском неизолированного процесса в Windows, это значительно быстрее, чем загрузка виртуальной машины при выполнении логической изоляции.

Обычный процесс Windows может вызывать более 1200 функций, которые обеспечивают доступ к ядру Windows; однако весь интерфейс для пико-процесса включает менее 50 вызовов к хосту. Большинство запросов приложений к службам операционной системы обрабатываются Library OS в адресном пространстве пико-процесса. Предоставляя значительно меньший интерфейс ядра, Drawbridge создает более безопасную и изолированную операционную среду, в которой приложения гораздо менее уязвимы для изменений в системе узла и несовместимости, представленных новыми выпусками ОС. Более важно, что пико-процесс Drawbridge является строго изолированным контейнером, в котором ненадежный код из даже самых вредоносных источников может выполняться без риска компрометации системы узла. Хост предполагает, что код, выполняемый в пико-процессе, не может считаться доверенным. Хост проверяет все запросы из пико-процесса после проверок безопасности.

Как и виртуальная машина, пико-процесс гораздо проще защитить, чем традиционный интерфейс ОС, так как он значительно меньше, без отслеживания состояния и имеет фиксированную и легко описанную семантику. Дополнительным преимуществом небольшого интерфейса ABI / системного вызова драйвера является возможность аудита и фаззинга кода драйвера. Например, фаззеры для системных вызовов могут искать слабые места в ABI, достигая высокого уровня покрытия за относительно короткое время.

Изоляция на основе контекста пользователя

В случаях, когда служба Azure состоит из управляемого корпорацией Майкрософт кода и клиентского кода не разрешено запускать, изоляция предоставляется контекстом пользователя. Эти службы принимают только входные данные конфигурации пользователя и данные для обработки. Произвольный код не допускается. Для этих служб предоставляется контекст пользователя, чтобы установить данные, к которым можно получить доступ, и какие операции управления доступом на основе ролей Azure (Azure RBAC) разрешены. Этот контекст устанавливается Microsoft Entra ID, как описано ранее в разделе изоляции на основе удостоверений личности. После того как пользователь был идентифицирован и авторизован, служба Azure создает контекст пользователя приложения, присоединенный к запросу по мере его перемещения, обеспечивая уверенность в том, что операции пользователей разделены и должным образом изолированы.

Физическая изоляция

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

Выделенный узел Azure

Выделенный узел Azure предоставляет физические серверы, где может размещаться одна или несколько виртуальных машин Azure. Эти серверы выделены для одной подписки Azure. Выделенные узлы можно настроить в регионе, зоне доступности и области отказа. Затем вы можете поместить Windows, Linux и SQL Server на виртуальные машины Azure непосредственно в подготовленные узлы с помощью любой конфигурации, подходящей для ваших потребностей. Выделенный узел обеспечивает изоляцию оборудования на физическом уровне сервера, что позволяет размещать виртуальные машины Azure на изолированном и выделенном физическом сервере, который выполняет только рабочие нагрузки вашей организации в соответствии с требованиями корпоративного соответствия.

Виртуальные машины Windows и Linux можно развернуть на выделенных узлах, выбрав сервер и тип ЦП, количество ядер и дополнительные функции. Выделенный узел позволяет контролировать события техобслуживания платформы, позволяя вам выбрать окно обслуживания, чтобы снизить потенциальное влияние на предоставляемые службы. Большинство событий обслуживания не влияют на виртуальные машины; однако, если вы находитесь в строго регулируемых отраслях или с конфиденциальной рабочей нагрузкой, вы можете иметь контроль над любым потенциальным воздействием на обслуживание.

Корпорация Майкрософт предоставляет подробные рекомендации по подготовке виртуальных машин Windows и Linux Azure с помощью портала Azure, Azure PowerShell и Azure CLI. В таблице 5 приведены доступные рекомендации по безопасности для виртуальных машин, подготовленных в Azure.

Таблица 5. Руководство по безопасности для виртуальных машин Azure

Изолированные виртуальные машины

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

Изоляция сети

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

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

Разделение сетевого трафика клиента

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

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

Azure обеспечивает сетевую изоляцию для каждого развертывания и применяет следующие правила:

• Трафик между виртуальными машинами всегда проходит через фильтры доверенных пакетов.
  • Такие протоколы, как протокол ARP, протокол конфигурации динамического узла (DHCP) и другой трафик OSI уровня 2 с виртуальной машины управляются с помощью ограничения скорости и защиты от спуфингов.
  • Виртуальные машины не могут захватывать трафик в сети, который не предназначен для них.
• Виртуальные машины не могут отправлять трафик в частные интерфейсы и службы инфраструктуры Azure или на виртуальные машины, принадлежащие другим клиентам. Виртуальные машины могут взаимодействовать только с другими виртуальными машинами, принадлежащими или управляемыми вами, и конечными точками службы инфраструктуры Azure, предназначенными для общедоступных коммуникаций.
• Когда вы помещаете виртуальную машину в виртуальную сеть, эта виртуальная машина получает собственное адресное пространство, которое является невидимым и поэтому недоступно из виртуальных машин за пределами развертывания или виртуальной сети (если не настроено отображаться через общедоступные IP-адреса). Среда открыта только через порты, указанные для общедоступного доступа; Если виртуальная машина определена для общедоступного IP-адреса, все порты открыты для общедоступного доступа.

Защита потока пакетов и сетевого пути

Сеть гипермасштабирования Azure предназначена для предоставления:

• Единая высокая емкость между серверами.
• Изоляция производительности между службами, включая клиентов.
• Семантика Ethernet уровня 2.

Azure использует несколько сетевых реализаций для достижения этих целей:

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

Эти реализации дают каждой службе иллюзию, что все серверы, назначенные ей, и только эти серверы, подключены одним неинтерферным коммутатором Ethernet — виртуальным уровнем 2 (VL2) и поддерживают эту иллюзию, даже если размер каждой службы зависит от одного сервера до сотен тысяч. Эта реализация VL2 обеспечивает изоляцию производительности трафика, гарантируя, что трафик одной службы не может влиять на трафик любой другой службы, как если бы каждая служба была подключена отдельным физическим коммутатором.

В этом разделе объясняется, как пакеты передаются через сеть Azure, а также как топология, проектирование маршрутизации и система каталогов объединяются для виртуализации базовой сетевой структуры, создавая иллюзию, что серверы подключены к большому неинтерферируемом коммутатору центра обработки данных на уровне 2.

Сеть Azure использует два разных семейства IP-адресов:

• Адрес клиента (АД) — это определенный/выбранный клиентом IP-адрес виртуальной сети, который также называется виртуальным IP-адресом (VIP). Сетевая инфраструктура работает с использованием центров сертификации (ЦС), которые могут быть маршрутизированы извне. Все коммутаторы и интерфейсы назначаются ЦС, а коммутаторы выполняют протокол маршрутизации состояния связи на основе IP-адресов (уровень 3), распространяющий только эти ЦС. Этот дизайн позволяет коммутаторам получать полную топологию уровня коммутатора и пересылать пакеты, инкапсулированные с CAs, по кратчайшим путям.
• Адрес поставщика (PA) — это назначенный внутренним адресом структуры Azure, который не отображается пользователям и также называется динамическим IP-адресом (DIP). Трафик не передается непосредственно из Интернета на сервер; Весь трафик из Интернета должен проходить через подсистему балансировки нагрузки программного обеспечения (SLB) и инкапсулировать для защиты внутреннего адресного пространства Azure путем маршрутизации пакетов только в допустимые внутренние IP-адреса и порты Azure. Преобразование сетевых адресов (NAT) отделяет внутренний сетевой трафик от внешнего трафика. Внутренний трафик использует адресное пространство RFC 1918 или частное адресное пространство — адреса поставщика (PAs), которые не могут быть маршрутизируемыми внешним образом. Перевод выполняется на SLBs. Адреса клиентов, которые могут маршрутизироваться извне, преобразуются во внутренние адреса поставщиков, которые могут маршрутизироваться только внутри Azure. Эти адреса остаются неизменными независимо от того, как их расположения серверов изменяются из-за миграции виртуальных машин или переподготовки.

Каждый PA ассоциирован с CA, который служит идентификатором коммутатора Top of Rack (ToR), к которому подключен сервер. VL2 использует масштабируемую, надежную систему каталогов для хранения и поддержания сопоставления PAs с CAs, и это сопоставление создается, когда серверы развертываются для обслуживания и которым назначаются PA-адреса. Агент, работающий в сетевом стеке на каждом сервере, который называется агентом VL2, вызывает службу разрешения системы каталогов, чтобы узнать фактическое расположение назначения, а затем туннелирует исходный пакет там.

Azure назначает IP-адреса серверов, которые действуют только как имена, без топологической значимости. Схема адресации Azure VL2 отделяет эти имена серверов (PAs) от их местоположений (CAs). Суть предложения семантики уровня 2 заключается в том, чтобы серверы считали, что они совместно используют одну большую подсеть IP-адресов, то есть всё пространство PA, с другими серверами в той же службе, устраняя узкие места масштабирования протоколов ARP и DHCP, которые часто мешают крупным развертываниям Ethernet.

На рисунке 9 показан пример потока пакетов, в котором отправитель S отправляет пакеты в назначение D с помощью случайно выбранного промежуточного коммутатора с помощью IP-in-IP инкапсуляции. PAs начинаются с 20/8, а CAs с 10/8. H(ft) обозначает хэш 5-элементного кортежа, состоящего из исходного IP-адреса, исходного порта, целевого IP-адреса, порта назначения и типа протокола. ToR преобразует PA в CA, отправляет в промежуточный коммутатор, который пересылает на коммутатор назначения ToR CA, который преобразует в целевой PA.

рис. 9. Пример потока пакетов

Сервер не может отправлять пакеты в PA, если служба каталогов отказывается предоставить ему ЦС, с помощью которого он может направлять свои пакеты, что означает, что служба каталогов применяет политики управления доступом. Кроме того, поскольку система каталогов знает, какой сервер выполняет запрос при обработке поиска, она может применять детализированные политики изоляции. Например, она может обеспечивать соблюдение политики, согласно которой общение разрешено только между серверами, принадлежащими одной и той же службе.

Шаблоны потока трафика

Для маршрутизации трафика между серверами, использующими PA-адреса, в базовой сети, которая знает маршруты для CA-адресов, агент VL2 на каждом сервере перехватывает пакеты из узла и инкапсулирует их с CA-адресом переключателя ToR назначения. После прибытия пакета к целевому коммутатору ToR, коммутатор ToR декапсулирует пакет и доставляет его к назначенному PA, находящемуся во внутреннем заголовке. Пакет сначала доставляется на один из промежуточных коммутаторов, где он декапсулируется коммутатором, затем доставляется к CA коммутатора уровня здания (ToR), декапсулируется снова, и, наконец, отправляется в место назначения. Этот подход показан на рис. 10 с помощью двух возможных шаблонов трафика: 1) внешний трафик (оранжевый канал), проходящий через Azure ExpressRoute или Интернет в виртуальную сеть, и 2) внутренний трафик (синяя линия) между двумя виртуальными сетями. Оба потока трафика соответствуют аналогичному шаблону для изоляции и защиты сетевого трафика.

рис. 10. Разделение сетевого трафика клиента с помощью виртуальных сетей

Внешний трафик (оранжевая линия) — для внешнего трафика Azure предоставляет несколько уровней гарантии для обеспечения изоляции в зависимости от шаблонов трафика. При размещении общедоступного IP-адреса в шлюзе виртуальной сети трафик из общедоступного Интернета или локальной сети, предназначенной для этого IP-адреса, будет перенаправлен на маршрутизатор Internet Edge. Кроме того, при установке частного пиринга через подключение ExpressRoute он подключается к виртуальной сети Azure через шлюз виртуальной сети. Эта настройка настраивает подключение физической цепи и делает частное IP-адресное пространство из локального расположения адресуемым. Затем Azure использует протокол BGP для обмена сведениями о маршрутизации с локальной сетью для установления сквозного подключения. Когда связь начинается с ресурса в виртуальной сети, сетевой трафик проходит как обычный, пока он не достигнет маршрутизатора Microsoft ExpressRoute Edge (MSEE). В обоих случаях виртуальные сети обеспечивают возможность виртуальным машинам Azure действовать как часть вашей локальной сети. Криптографически защищенный туннель IPsec/IKE устанавливается между Azure и внутренней сетью (например, через VPN-шлюз Azure или частный пиринг Azure ExpressRoute), что позволяет виртуальной машине безопасно подключаться к локальным ресурсам, как будто это было непосредственно в этой сети.

На маршрутизаторе Internet Edge или маршрутизаторе MSEE пакет инкапсулируется с помощью универсальной инкапсуляции маршрутизации (GRE). В этой инкапсуляции используется уникальный идентификатор, характерный для назначения виртуальной сети и адреса назначения, который используется для надлежащего маршрутизации трафика в определяемую виртуальную сеть. При достижении шлюза виртуальной сети, который является специальной виртуальной сетью, используемой только для приема трафика извне виртуальной сети Azure, инкапсуляция проверяется сетевой структурой Azure, чтобы убедиться, что конечная точка, получающая пакет, соответствует уникальному идентификатору виртуальной сети, используемому для маршрутизации данных, и b) запрошенный адрес назначения существует в этой виртуальной сети. После проверки пакет направляется как внутренний трафик из шлюза виртуальной сети в окончательный запрошенный целевой адрес в виртуальной сети. Этот подход гарантирует, что трафик из внешних сетей перемещается только в виртуальную сеть Azure, для которой он предназначается, обеспечивая принудительную изоляцию.

Внутренний трафик (синяя линия) — внутренний трафик также использует инкапсуляцию или туннелирование GRE. Когда две ресурсы в виртуальной сети Azure пытаются установить связь между собой, сетевая структура Azure обращается к службе каталогов маршрутизации виртуальной сети Azure, которая входит в сетевую структуру Azure. Службы каталогов используют адрес клиента (ЦС) и запрошенный целевой адрес для определения адреса поставщика (PA). Эти сведения, включая идентификатор виртуальной сети, ЦС и PA, затем используются для инкапсуляции трафика с помощью GRE. Сеть Azure использует эти сведения для правильной маршрутизации инкапсулированных данных на соответствующий узел Azure с помощью PA. Инкапсуляция проверяется сетевой структурой Azure, чтобы подтвердить:

1. Pa — это совпадение,
2. ЦС расположен по этому адресу, и
3. Идентификатор VNet соответствует.

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

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

• Предотвращение спуфинга IP-адресов – всегда, когда инкапсулированный трафик передается виртуальной сетью, служба повторно проверяет информацию на принимающей стороне передачи. Трафик просматривается и инкапсулируется независимо в начале передачи и возвращается на принимающей конечной точке, чтобы обеспечить надлежащее выполнение передачи. Эта проверка выполняется с помощью внутренней функции виртуальной сети с именем SpoofGuard, которая проверяет, что источник и назначение действительны и им разрешено взаимодействовать, тем самым предотвращая несоответствия в ожидаемых шаблонах инкапсуляции, которые иначе могут разрешить спуфинг. Процессы инкапсуляции GRE препятствуют спуфингу, так как любая инкапсуляция GRE и шифрование, не выполняемая сетевой структурой Azure, рассматривается как удаленный трафик.
• Обеспечение сегментации сети между клиентами с перекрывающимися сетевыми пространствами. Реализация виртуальной сети Azure зависит от установленных стандартов туннелирования, таких как GRE, что, в свою очередь, позволяет использовать уникальные идентификаторы конкретных клиентов (идентификаторы виртуальных сетей) в облаке. Идентификаторы виртуальной сети используются в качестве идентификаторов области. Этот подход гарантирует, что вы всегда работаете в уникальном адресном пространстве, перекрывая адресные пространства между клиентами и сетевой структурой Azure. Все, что не было инкапсулировано с допустимым идентификатором виртуальной сети, блокируется в сетевой структуре Azure. В примере, описанном ранее, любой инкапсулированный трафик, не выполняемый сетевой структурой Azure, удаляется.
• Запрет трафика между виртуальными сетями— предотвращение пересечения трафика между виртуальными сетями осуществляется с помощью одного и того же механизма, обрабатывающего перекрытие адресов и предотвращение спуфингов. Трафик между виртуальными сетями становится невозможным благодаря уникальным идентификаторам виртуальных сетей, установленным для каждого арендатора, в сочетании с проверкой всего трафика на исходной и конечной точках. У пользователей нет доступа к базовым механизмам передачи, которые используют эти идентификаторы для выполнения инкапсуляции. Поэтому любая попытка инкапсулировать и имитировать эти механизмы приведет к падению трафика.

Помимо этих защиты ключей, по умолчанию удаляется весь непредвиденный трафик, исходящий из Интернета. Любой пакет, входящий в сеть Azure, сначала столкнется с маршрутизатором Edge. Пограничные маршрутизаторы намеренно разрешают весь входящий трафик в сеть Azure, кроме поддельного трафика. Эта базовая фильтрация трафика защищает сеть Azure от известного вредоносного трафика. Azure также реализует защиту от атак DDoS на сетевом уровне, сбор журналов для регулирования или блокировки трафика на основе анализа данных в режиме реального времени и анализа исторических данных, а также устраняет атаки по требованию.

Кроме того, сетевая структура Azure блокирует трафик от любых спуфированных IP-адресов, происходящих из пространства самой сетевой структуры Azure. Сетевая структура Azure использует GRE и виртуальную расширяемую локальную сеть (VXLAN) для проверки того, что весь разрешенный трафик управляется Azure, а весь трафик, отличный от Azure GRE, заблокирован. Используя туннели GRE и VXLAN для сегментирования трафика с помощью уникальных ключей клиента, Azure соответствует RFC 3809 и RFC 4110. При использовании VPN-шлюза Azure в сочетании с ExpressRoute Azure соответствует RFC 4111 и RFC 4364. Благодаря комплексному подходу к изоляции, охватывающему внешний и внутренний сетевой трафик, виртуальные сети Azure предоставляют гарантию, что Azure успешно направляет трафик между виртуальными сетями, обеспечивает правильную сегментацию сети для клиентов с перекрывающимися адресными пространствами и предотвращает подделку IP-адресов.

Вы также можете использовать службы Azure для дальнейшего изоляции и защиты ресурсов. С помощью групп безопасности сети (NSG) — функции виртуальной сети Azure, можно фильтровать трафик по исходному и целевому IP-адресу, порту и протоколу с помощью нескольких правил безопасности для входящего и исходящего трафика— по сути, выступая в качестве распределенного виртуального брандмауэра и списка управления доступом на основе IP-адресов (ACL). NSG можно применить к каждому сетевому интерфейсу в виртуальной машине, к подсети, к которой подключен сетевой адаптер или другой ресурс Azure, и непосредственно к набору виртуальных машин с автоматическим масштабированием, что позволяет более тщательно контролировать инфраструктуру.

На уровне инфраструктуры Azure реализует брандмауэр гипервизора для защиты всех клиентов, работающих в виртуальных машинах на вершине гипервизора от несанкционированного доступа. Этот брандмауэр гипервизора распространяется в рамках правил NSG, развернутых на узле, реализованных в гипервизоре и настроенных агентом контроллера Структуры, как показано на рис. 4. Экземпляры ОС узла пользуются встроенным брандмауэром Windows для реализации тонких списков управления доступом на более детализированном уровне, чем списки управления доступом маршрутизатора, и они поддерживаются тем же программным обеспечением, которое подготавливает арендаторов, поэтому они никогда не устаревают. К брандмауэру Windows применяются детализированные списки управления доступом с помощью файла Machine Configuration File (MCF).

В верхней части стека операционной системы находится гостевая ОС, которая используется в качестве операционной системы. По умолчанию этот уровень не разрешает входящий обмен данными с облачной службой или виртуальной сетью, что, по сути, делает его частью частной сети. Для ролей PaaS Web и Worker удаленный доступ не разрешен по умолчанию. Вы можете включить доступ к протоколу удаленного рабочего стола (RDP) в качестве явного параметра. Для виртуальных машин IaaS, созданных с помощью портала Azure, порты RDP и удаленного PowerShell открыты по умолчанию; однако номера портов назначаются случайным образом. Для виртуальных машин IaaS, созданных с помощью PowerShell, порты RDP и удаленного PowerShell должны быть открыты явно. Если администратор решит сохранить RDP и удаленные порты PowerShell открытыми в Интернете, учетная запись, разрешенная для создания подключений RDP и PowerShell, должна быть защищена с помощью надежного пароля. Даже если порты открыты, при необходимости можно определить списки управления доступом на общедоступных IP-адресах для дополнительной защиты.

Теги сервиса

Теги службы виртуальной сети можно использовать для обеспечения сетевой изоляции и защиты ресурсов Azure из Интернета при доступе к службам Azure с общедоступными конечными точками. С помощью тегов службы можно определить элементы управления доступом к сети в группах безопасности сети или брандмауэре Azure. Тег службы представляет группу префиксов IP-адресов из данной службы Azure. Корпорация Майкрософт управляет префиксами адресов, охватываемым тегом службы, и автоматически обновляет тег службы по мере изменения адресов, тем самым уменьшая сложность частых обновлений правил безопасности сети.

Приватный канал Azure

Вы можете использовать приватный канал для доступа к службам Azure PaaS и службам, размещенным в Azure, через частную конечную точку в виртуальной сети, обеспечивая передачу трафика между виртуальной сетью и службой через глобальную магистральную сеть Майкрософт. Этот подход устраняет необходимость предоставления службы общедоступному Интернету. Вы также можете создать свою службу приватной ссылки в виртуальной сети и предоставить её клиентам.

Частная конечная точка Azure — это сетевой интерфейс, который подключает вас частным и безопасным способом к службе, посредством Private Link. Частная конечная точка использует частный IP-адрес из виртуальной сети, фактически перемещая службу в виртуальную сеть.

Из точки зрения сетевой изоляции ключевые преимущества приватного канала включают:

• Вы можете подключить виртуальную сеть к службам в Azure без общедоступного IP-адреса в источнике или назначении. Приватный канал обрабатывает подключение между службой и его потребителями через глобальную магистральную сеть Майкрософт.
• Вы можете получить доступ к службам, работающим в Azure, из локальной среды через частный пиринг Azure ExpressRoute, VPN-туннели и пиринговые виртуальные сети с помощью частных конечных точек. Private Link устраняет необходимость настройки пиринга с Microsoft или использования Интернета для обращения к службе.
• Вы можете подключиться к службам, работающим в других регионах Azure.

Шифрование данных при передаче

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

• Конечные пользователи и служба Azure
• Локальный центр обработки данных и регион Azure
• Центры обработки данных Майкрософт в рамках ожидаемой операции службы Azure

Подключение конечного пользователя к службе Azure

Tls — Azure использует протокол TLS для защиты данных при перемещении между конечными пользователями и службами Azure. Большинство конечных пользователей будут подключаться к Azure через Интернет, и точное маршрутизация сетевого трафика будет зависеть от многих сетевых поставщиков, которые вносят вклад в инфраструктуру Интернета. Как указано в Дополнении о защите данных к продуктам и услугам Microsoft (DPA), корпорация Microsoft не контролирует и не ограничивает регионы, из которых вы или ваши конечные пользователи можете получить доступ к данным клиента или перемещать их.

В службах Azure трафик к службе и из нее защищен TLS 1.2 с помощью RSA-2048 для обмена ключами и AES-256 для шифрования данных. Соответствующие модули шифрования прошли проверку FIPS 140 в рамках программы валидации FIPS Microsoft Windows.

Протокол TLS обеспечивает строгую проверку подлинности, конфиденциальность сообщений и целостность данных. Идеальная секретность пересылки (PFS) защищает подключения между клиентскими системами и облачными службами Майкрософт путем создания уникального ключа сеанса для каждого инициируемого сеанса. PFS обеспечивает защиту прошлых сеансов от возможных взломов ключа в будущем. Благодаря такому сочетанию усложняется перехват данных и доступ к ним во время передачи.

Шифрование между виртуальными машинами — удаленные сеансы с виртуальными машинами Windows и Linux, развернутыми в Azure, можно проводить по протоколам, обеспечивающим шифрование данных при передаче. Например, протокол удаленного рабочего стола (RDP), инициированный с клиентского компьютера на виртуальные машины Windows и Linux, обеспечивает защиту TLS для передаваемых данных. Вы также можете использовать Secure Shell (SSH) для подключения к виртуальным машинам Linux, работающим в Azure. SSH — это зашифрованный протокол подключения, доступный по умолчанию для удаленного управления виртуальными машинами Linux, размещенными в Azure.

Транзакции службы хранилища Azure . При взаимодействии с службой хранилища Azure через портал Azure все транзакции происходят по протоколу HTTPS. Кроме того, вы можете настроить учетные записи хранения для приема запросов только из безопасных подключений, задав для учетной записи хранения свойство secure transfer required. Параметр "Требуется безопасная передача" включен по умолчанию при создании учетной записи хранения на портале Azure.

Служба файлов Azure предоставляет полностью управляемые общие файловые ресурсы в облаке, доступ к которым можно получить с помощью стандартного отраслевого протокола SMB. По умолчанию все учетные записи хранения Azure имеют шифрование при передаче. Поэтому при подключении общей папки через SMB или доступе к ней через портал Azure (или Azure PowerShell, Azure CLI и пакеты SDK Azure) Azure Files разрешает подключение только в том случае, если используется SMB 3.0+ с шифрованием или протокол HTTPS.

Подключение центра обработки данных к региону Azure

VPN-шифрование — виртуальная сеть (виртуальная сеть) предоставляет средства для виртуальных машин Azure, которые будут выступать в качестве части внутренней (локальной) сети. При использовании виртуальной сети вы выбираете диапазоны адресов, не относящихся к глобальному маршрутизируемому IP-адресам, которые будут назначены виртуальным машинам, чтобы они не столкнулись с адресами, которые вы используете в другом месте. Вы можете безопасно подключиться к виртуальной сети из локальной инфраструктуры или удаленных расположений.

• Vpn-туннель типа "сеть — сеть" (IPsec/IKE VPN-туннель) — криптографически защищенный туннель устанавливается между Azure и внутренней сетью, позволяя виртуальной машине Azure подключаться к внутренним ресурсам, как будто это было непосредственно в этой сети. Для этого типа подключения требуется VPN-устройство , расположенное локально, которое имеет внешний общедоступный IP-адрес, назначенный ему. Vpn-шлюз Azure можно использовать для отправки зашифрованного трафика между виртуальной сетью и локальной инфраструктурой через общедоступный Интернет, например VPN типа "сеть — сеть" использует IPsec для шифрования транспорта. VPN-шлюз поддерживает множество алгоритмов шифрования, проверенных FIPS 140. Кроме того, vpn-шлюз можно настроить для использования настраиваемой политики IPsec/IKE с определенными алгоритмами шифрования и преимуществами ключей вместо использования политик Azure по умолчанию. IPsec шифрует данные на уровне IP-адреса (сетевой уровень 3).
• Точка — сеть (VPN через SSTP, OpenVPN и IPsec) — безопасное подключение устанавливается с отдельного клиентского компьютера к виртуальной сети с помощью протокола SSTP, OpenVPN или IPsec. В рамках конфигурации VPN типа "точка — сеть " необходимо установить сертификат и пакет конфигурации VPN-клиента, который позволяет клиентскому компьютеру подключаться к любой виртуальной машине в виртуальной сети. VPN-подключения типа "точка — сеть " не требуют VPN-устройства или общедоступного IP-адреса.

В дополнение к управлению типом алгоритма, поддерживаемого для VPN-подключений, Azure дает возможность принудительного направления всего трафика, покидающего виртуальную сеть, исключительно через шлюз виртуальной сети (например, Azure VPN Gateway). Это правило позволяет убедиться, что трафик не может покинуть VNet без шифрования. VPN-шлюз можно использовать для подключений между виртуальными сетями , а также для безопасного туннеля с помощью IPsec/IKE. VPN Azure использует проверку подлинности предварительно общего ключа (PSK), при которой корпорация Майкрософт создает PSK при создании VPN-туннеля. Вы можете изменить автоматически созданный PSK на собственный.

Шифрование Azure ExpressRoute — Azure ExpressRoute позволяет создавать частные подключения между центрами обработки данных Майкрософт и локальной инфраструктурой или объектом совместного размещения. Подключения ExpressRoute не проходят через общедоступный Интернет и обеспечивают более низкую задержку и более высокую надежность, чем защищенные VPN-подключения IPsec. Расположения ExpressRoute — это точки входа в глобальную сеть Майкрософт, и они могут или не совпадать с расположением регионов Azure. Когда сетевой трафик входит в магистраль Майкрософт, он гарантированно проходит по этой инфраструктуре частной сети вместо общедоступного Интернета. ExpressRoute можно использовать с несколькими параметрами шифрования данных, включая MACsec , которые позволяют хранить ключи шифрования MACsec в Azure Key Vault. Стандарт MACsec шифрует данные на уровне управления доступом к среде передачи (MAC), то есть канальный уровень данных (сетевой уровень 2). Блочные шифры AES-128 и AES-256 поддерживаются для шифрования. С помощью MACsec можно шифровать физические связи между сетевыми устройствами и сетевыми устройствами Майкрософт при подключении к Microsoft через ExpressRoute Direct. ExpressRoute Direct позволяет напрямую подключаться посредством оптоволокна от вашей сети к пограничным маршрутизаторам Microsoft Enterprise на узлах пиринга.

Кроме MACsec можно включить протокол IPsec на портах ExpressRoute Direct, как показано на рис. 11. С помощью VPN-шлюза можно настроить туннель IPsec через пиринг Майкрософт канала ExpressRoute между локальной сетью и виртуальной сетью Azure. MACsec защищает физическое подключение между локальной сетью и Корпорацией Майкрософт. IPsec защищает сквозное подключение между локальной сетью и виртуальными сетями в Azure. MACsec и IPsec можно включить независимо.

Рисунок 11. Шифрование VPN и ExpressRoute для передаваемых данных

Трафик по глобальной сети Майкрософт

Службы Azure, такие как хранилище и база данных SQL, можно настроить для георепликации, чтобы обеспечить устойчивость и высокий уровень доступности, особенно для сценариев аварийного восстановления. Azure использует парные регионы для доставки геоизбыточного хранилища (GRS), и парные регионы также рекомендуется использовать при настройке активной георепликации для Azure SQL Database. Парные регионы находятся в одном географическом регионе, однако сетевой трафик не гарантируется всегда следовать одному пути из одного региона Azure в другой. Для обеспечения оптимальной надежности, необходимой для облака Azure, корпорация Майкрософт предлагает множество физических сетевых путей с автоматической маршрутизацией при сбоях.

Кроме того, весь трафик Azure, путешествующий в пределах региона или между регионами, шифруется корпорацией Майкрософт с помощью MACsec, которая использует шифр блоков AES-128 для шифрования. Этот трафик полностью находится в глобальной сети Майкрософт и никогда не входит в общедоступный Интернет. Магистральная сеть является одной из крупнейших в мире с более чем 250 000 км задействованных оптических волокон и подводных кабелей.

Сторонние сетевые виртуальные устройства

Azure предоставляет множество функций, которые помогут вам достичь целей безопасности и изоляции, включая Microsoft Defender для облака, Azure Monitor, брандмауэр Azure, VPN-шлюз, группы безопасности сети, шлюз приложений, защиту от атак DDoS Azure, наблюдатель за сетями, Microsoft Sentinel и политику Azure. Помимо встроенных возможностей, которые предоставляет Azure, вы можете использовать сторонние сетевые виртуальные устройства для удовлетворения конкретных требований к сетевой изоляции, а также применения существующих навыков внутри компании. Azure поддерживает множество устройств, включая предложения из F5, Palo Alto Networks, Cisco, Check Point, Barracuda, Citrix, Fortinet и многие другие. Сетевые устройства поддерживают сетевые функции и службы в виде виртуальных машин в виртуальных сетях и развертываниях.

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

Изоляция хранилища

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

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

• Общие симметричные ключи . При создании учетной записи хранения Azure создает два 512-разрядных ключа учетной записи хранения, которые управляют доступом к учетной записи хранения. Вы можете сменить и обновить эти ключи в любое время без согласования с вашими приложениями.
• Проверка подлинности на основе идентификаторов Microsoft Entra — доступ к службе хранилища Azure можно контролировать с помощью идентификации Microsoft Entra, которая обеспечивает изоляцию клиента и реализует надежные меры для предотвращения доступа неавторизованных сторон, включая сотрудников Microsoft. Дополнительные сведения об изоляции клиента Microsoft Entra доступны в техническом документе о безопасности данных Microsoft Entra.
• Подписи общего доступа (SAS) — передписанные URL-адреса или URL-адреса общего доступа можно создавать из общих симметричных ключей. Эти URL-адреса могут быть значительно ограничены в охвате, чтобы уменьшить потенциальную поверхность атаки, но в то же время позволять приложениям предоставлять доступ к хранилищу другому пользователю, службе или устройству.
• SAS делегирования пользователей — делегированная проверка подлинности аналогична SAS, но основана на маркерах Microsoft Entra, а не на общих симметричных ключах. Этот подход позволяет службе, которая выполняет проверку подлинности с помощью идентификатора Microsoft Entra, создать предварительно подписанный URL-адрес с ограниченной областью и предоставить временный доступ другому пользователю, службе или устройству.
• Анонимный общедоступный доступ на чтение . Вы можете разрешить небольшой части хранилища быть общедоступным без проверки подлинности или авторизации. Эта возможность может быть отключена на уровне подписки, если требуется более строгий контроль.

Служба хранилища Azure предоставляет хранилище для различных рабочих нагрузок, в том числе:

• Виртуальные машины Azure (хранилище дисков)
• Аналитика больших данных (HDFS для HDInsight, Azure Data Lake Storage)
• Хранение состояния приложения, пользовательских данных (BLOB, очередь, хранилище таблиц)
• Долгосрочное хранилище данных (архивное хранилище Azure)
• Сетевые файловые ресурсы в облаке (хранилище файлов)
• Обслуживание веб-страниц в Интернете (статические веб-сайты)

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

Репликация данных

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

• Локально избыточное хранилище (LRS) реплицирует три копии (или стирание закодированного эквивалента, как описано далее) данных в одном центре обработки данных. Запрос на запись в учетную запись хранения LRS успешно возвращается только после записи данных во все три реплики. Каждая реплика находится в разных доменах сбоев и обновлений в единице масштабирования (набор стоек хранения в центре обработки данных).
• Зонально-избыточное хранилище (ZRS) синхронно реплицирует ваши данные в трех кластерах для хранения данных в одном регионе. Каждый кластер хранилища физически отделен от других и находится в собственной зоне доступности (AZ). Запрос на запись в учетную запись хранения LRS возвращается только после записи данных во все реплики в трех кластерах.
• Геоизбыточное хранилище (GRS) реплицирует данные в дополнительный (парный) регион , который находится в сотнях километров от основного региона. Учетные записи хранения GRS устойчивы даже во время полного регионального сбоя или аварии, в которой основной регион не может восстановиться. Для учетной записи хранения с поддержкой GRS или RA-GRS все данные сначала реплицируются с помощью LRS. Обновление сначала фиксируется в основном расположении и реплицируется с помощью LRS. Затем обновление реплицируется асинхронно во вторичный регион с помощью GRS. При записи данных во вторичное расположение они также реплицируются в этом расположении с использованием LRS.
• Геоизбыточное хранилище с доступом только для чтения (RA-GRS) основано на GRS. Он предоставляет доступ только для чтения к данным во вторичном расположении, в дополнение к георепликации в двух регионах. С помощью RA-GRS можно читать из вторичного региона независимо от того, инициирует ли Microsoft переключение при отказе из основного в вторичный регион.
• Геоизбыточное хранилище (GZRS) объединяет высокий уровень доступности ZRS с защитой от региональных сбоев, предоставляемых GRS. Данные в хранилище данных GZRS реплицируются в пределах трех зон доступности в основном регионе, а также копируются в дополнительный географический регион для защиты в случае региональных катастроф. Каждый регион Azure образует пару с другим регионом в той же географической области, вместе образуя региональную пару.
• Геоизбыточное хранилище с доступом только для чтения (RA-GZRS) основано на GZRS. При необходимости можно включить доступ на чтение к данным в дополнительном регионе с RA-GZRS, если приложения должны иметь возможность считывать данные после аварии в основном регионе.

Высокоуровневая архитектура службы хранилища Azure

Производственные системы службы хранилища Azure состоят из меток хранилища и службы расположения (LS), как показано на рис. 12. Хранилищный штамп — это кластер стоек узлов хранения, где каждая стойка создается как отдельный домен сбоя с избыточной сетью и питанием. LS управляет всеми метками хранилища и пространством имен учетной записи во всех метках. Он выделяет учетные записи для меток хранения и управляет ими в метках хранилища для балансировки нагрузки и аварийного восстановления. Сам LS распределяется между двумя географическими расположениями для собственного аварийного восстановления (Calder, et al., 2011).

рис. 12. Высокоуровневая архитектура службы хранилища Azure (источник: Calder, et al., 2011)

В структуре хранилища существуют три уровня: внешняя часть, раздел и поток. Эти слои описаны в остальной части этого раздела.

Интерфейсный слой

Внешний уровень (FE) состоит из набора серверов без отслеживания состояния, которые принимают входящие запросы, выполняют их проверку подлинности и авторизацию, а затем направляют их на сервер секционирования в секционном уровне. Уровень FE знает, какой сервер секционирования перенаправит каждый запрос, так как каждый внешний сервер кэширует карту секционирования. Карта секций отслеживает секции для доступа к службе и какой сервер секционирования управляет доступом к каждой секции в системе. Серверы FE также передают большие объекты непосредственно из слоя потока.

Передача больших объемов данных через Интернет по сути является ненадежной. С помощью службы блочных BLOB-объектов Azure можно эффективно отправлять и хранить большие файлы, разбивая большие файлы на небольшие блоки данных. Таким образом, блочные блобы позволяют секционировать данные в отдельные блоки для надежности больших загрузок, как показано на рис. 13. Каждый блок может быть размером до 100 МБ, а BLOB-объект типа блоков может содержать до 50 000 блоков. Если блок не удалось корректно передать, необходимо повторно отправить только этот конкретный блок, а не весь файл. Кроме того, с блочными BLOB-объектами несколько блоков можно отправлять параллельно, чтобы уменьшить время загрузки.

рис. 13. Секционирование больших двоичных объектов в отдельные блоки

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

Уровень секционирования

Уровень разделов отвечает за следующее:

• Управление абстракциями данных более высокого уровня (BLOB, Таблица, Очередь)
• Предоставление масштабируемого пространства имен объекта,
• Обеспечение упорядочения транзакций и строгой согласованности для объектов
• Хранение данных объектов на вершине слоя потока и
• Кэширование данных объектов для уменьшения операций ввода-вывода диска.

Этот уровень также обеспечивает асинхронную георепликацию данных и ориентирован на репликацию данных по меткам. Репликация между штампами выполняется в фоновом режиме, чтобы сохранить копию данных в двух местах для целей аварийного восстановления.

После того, как двоичный объект обрабатывается слоем FE, слой секционирования отвечает за отслеживание и хранение информации о размещении данных в слое потока. Каждый клиент хранилища может иметь примерно 200 – 300 отдельных узлов уровня секционирования, и каждый узел отвечает за отслеживание и обслуживание секции данных, хранящихся в этом клиенте хранилища. Функция высокопроизводительных блок-объектов (HTBB) позволяет сегментировать данные внутри одного блок-объекта, что позволяет распределить рабочую нагрузку больших объектов между несколькими серверами уровня секционирования (рис. 14). Распределение нагрузки между несколькими серверами уровня секционирования значительно повышает доступность, пропускную способность и устойчивость.

рис. 14. Большие двоичные объекты с высокой пропускной способностью распределяют трафик и данные между несколькими серверами секций и потоками

Слой потока

Уровень потоков хранит биты на диске и отвечает за распределение и репликацию данных на многих серверах, чтобы обеспечить устойчивость данных в метках хранилища. Он выступает в качестве распределенного слоя файловой системы в штампе. Он обрабатывает файлы, называемые потоками, которые являются упорядоченными списками блоков данных, называемых экстентами, которые аналогичны экстентам на физических жестких дисках. Большие двоичные объекты могут храниться в нескольких экстентах, потенциально на нескольких физических узлах экстентов (EN). Данные хранятся на уровне потока, но они доступны из слоя секционирования. Серверы секционирования и серверы потоковой передачи находятся на каждом узле хранилища в кластере.

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

Кодирование стирания — служба хранилища Azure использует метод с именем Erasure Coding, который позволяет перестроить данные, даже если некоторые данные отсутствуют из-за сбоя диска. Такой подход аналогичен концепции чередования RAID для отдельных дисков, в которых данные распределяются по нескольким дискам, чтобы при потере диска отсутствующие данные можно восстановить с помощью битов четности данных на других дисках. Кодирование с устранением разбивает дисковый объем на равные фрагменты данных и четности, которые хранятся на отдельных EN, как показано на рисунке 15.

рис. 15. Кодирование уничтожением дополнительно разбивает данные элементов экстентов между серверами EN для защиты от сбоя

Все блоки данных, хранящиеся в узлах потоковых экстентов, имеют 64-битную циклическую проверку избыточности (CRC) и заголовок, защищенный с помощью хэш-сигнатуры, для обеспечения целостности данных узла (EN). CRC и подпись проверяются перед каждой записью на диск, чтением с диска и получением данных из сети. Кроме того, процессы скруббера считывают все данные через регулярные интервалы, проверяя CRC и ищет битовую гниль. Если найден плохой экстент, создается новая копия этого экстента для замены.

Данные в хранилище Azure основываются на шифровании в состоянии покоя, чтобы обеспечить криптографическую защищенность логической изоляции данных. Вы можете выбрать ключи шифрования, управляемые корпорацией Майкрософт (также называемые ключами шифрования, управляемыми платформой) или ключами шифрования, управляемыми клиентом (CMK). Обработка шифрования и расшифровки данных является прозрачной для клиентов, как описано в следующем разделе.

Шифрование данных в состоянии покоя

Azure предоставляет широкие возможности шифрования неактивных данных , чтобы обеспечить защиту данных и обеспечить соответствие требованиям при использовании ключей шифрования, управляемых корпорацией Майкрософт, и ключей шифрования, управляемых клиентом. Дополнительные сведения см. в статье Модели шифрования данных. Этот процесс использует несколько ключей шифрования и служб, таких как Azure Key Vault и Идентификатор Microsoft Entra, чтобы обеспечить безопасный доступ к ключам и централизованное управление ключами.

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

• Ключ шифрования данных (DEK) — это симметричный ключ AES-256, используемый для массового шифрования и расшифровки секции или блока данных. Криптографические модули проверены FIPS 140 в рамках программы проверки Windows FIPS. Доступ к ключам шифрования данных (DEK) требуется поставщиком ресурсов или экземпляром приложения, ответственным за шифрование и расшифровку конкретного блока данных. Один ресурс может содержать множество разделов и много ключей DEK. Когда DEK заменяется новым ключом, повторного шифрования этим ключом требуют только данные в его связанном блоке. DEK всегда хранится в зашифрованном виде с использованием ключа шифрования ключей (KEK).
• Ключ шифрования ключей (KEK) — это асимметричный ключ RSA, который при необходимости предоставляется вами. Этот ключ шифрования ключей используется для шифрования ключа шифрования данных (DEK) с помощью Azure Key Vault или управляемого HSM. Как упоминалось ранее в разделе управления ключами шифрования данных , Azure Key Vault может использовать проверенные аппаратные модули безопасности FIPS 140 (HSM) для защиты ключей шифрования; Управляемый модуль HSM всегда использует проверенные аппаратные модули безопасности FIPS 140. Эти ключи не экспортируются и не может быть чистотекстовой версии KEK за пределами HSM— привязка применяется базовым HSM. KEK никогда не предоставляется напрямую поставщику ресурсов или другим службам. Доступ к KEK контролируется разрешениями в Azure Key Vault, и доступ к Azure Key Vault должен проходить аутентификацию с помощью Microsoft Entra ID. Эти разрешения можно отозвать, чтобы заблокировать доступ к этому ключу, а также к данным, зашифрованным с помощью этого ключа, который является корнем цепочки ключей.

рис. 16. Ключи шифрования данных шифруются с помощью ключа, хранящегося в Azure Key Vault

Таким образом, иерархия ключей шифрования включает как DEK, так и KEK. DEK шифруется с помощью KEK и хранится отдельно для эффективного доступа поставщиков ресурсов в операциях массового шифрования и расшифровки. Однако только сущность с доступом к KEK может расшифровать DEK. Сущность, у которой есть доступ к KEK, может быть отличной от сущности, требующей DEK. Поскольку KEK необходим для расшифровки DEK, KEK фактически является единой точкой, через удаление которой можно удалить DEK.

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

Шифрование службы хранилища

Шифрование службы хранилища Azure для неактивных данных гарантирует, что данные автоматически шифруются перед сохранением в службе хранилища Azure и расшифровываются перед извлечением. Все данные, записанные в службу хранилища Azure, шифруются с помощью fiPS 140, проверенного 256-разрядного шифрования AES, а обработка шифрования, расшифровки и управления ключами в шифровании службы хранилища является прозрачной для клиентов. По умолчанию корпорация Майкрософт управляет ключами шифрования и отвечает за смену ключей, использование и доступ. Хранилище ключей Майкрософт обеспечивает надежное хранение ключей и их защиту. Этот параметр обеспечивает максимальное удобство, учитывая, что поддерживаются все службы хранилища Azure.

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

• Ключ, управляемый клиентом, для управления шифрованием службы хранилища Azure, при котором ключ хранится в Azure Key Vault. Этот параметр обеспечивает большую гибкость для создания, смены, отключения и отмены доступа к ключам, управляемым клиентом. Необходимо использовать Azure Key Vault для хранения ключей, управляемых клиентом. Поддерживаются как хранилища ключей, так и управляемые HSM, как описано ранее в разделе Azure Key Vault .
• Предоставленный клиентом ключ используется для шифрования и расшифровки объектов Blob, при этом ключ может храниться в Azure Key Vault или в другом хранилище ключей в локальной среде, чтобы соответствовать требованиям соответствия. Предоставленные клиентом ключи позволяют передавать ключ шифрования службе хранилища с помощью API BLOB-объектов в рамках операций чтения или записи.

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

• Ключ шифрования данных (DEK) — это симметричный ключ AES-256, используемый для массового шифрования, и это уникально для каждой учетной записи хранения в службе хранилища Azure. Она создается службой хранилища Azure в рамках создания учетной записи хранения и используется для получения уникального ключа для каждого блока данных. Служба хранилища всегда шифрует DEK с помощью ключа метки или ключа шифрования, если клиент настроил шифрование с управляемыми клиентом ключами.
• Ключ шифрования ключей (KEK) — это асимметричный ключ RSA (2048 или более поздней версии), управляемый клиентом, и используется для шифрования ключа шифрования данных (DEK) с помощью Azure Key Vault или управляемого HSM. Он никогда не подвергается прямому взаимодействию со службой Azure Storage или другими службами.
• Ключ метки (SK) — это симметричный ключ AES-256, управляемый службой хранилища Azure. Этот ключ используется для защиты DEK, когда не используется ключ, управляемый клиентом.

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

Рис. 17. Поток шифрования для шифрования службы хранилища

Учетные записи службы хранилища всегда шифруются, независимо от уровня производительности ("Стандартный" или "Премиум") и модели развертывания (Azure Resource Manager или классическая модель). Все параметры избыточности службы хранилища Azure поддерживают шифрование, а все копии учетной записи хранения шифруются. Шифруются все ресурсы службы хранилища Azure, включая большие двоичные объекты, диски, файлы, очереди и таблицы. Также шифруются все метаданные объектов.

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

Шифрование дисков Azure

Шифрование в службе хранилища Azure шифрует страничные блобы, которые содержат диски виртуальных машин Azure. Кроме того, вы можете при необходимости использовать шифрование дисков Azure для шифрования дисков Виртуальных машин IaaS на Windows и Linux, чтобы повысить изоляцию хранилища и обеспечить криптографическую надежность ваших данных, хранящихся в Azure. Это шифрование включает управляемые диски, как описано далее в этом разделе. Шифрование дисков Azure использует стандартную функцию BitLocker Windows и функцию DM-Crypt Linux для обеспечения шифрования томов на уровне операционной системы, интегрированных с Azure Key Vault.

Шифрование диска с помощью BitLocker и DM-Crypt — это функция защиты данных, которая интегрируется с операционной системой и защищает от угроз кражи или раскрытия данных с потерянных, украденных или неправильно выведенных из эксплуатации компьютеров. BitLocker и DM-Crypt обеспечивают большую защиту при использовании с доверенным платформенным модулем (TPM) версии 1.2 или более поздней. TPM — это микроконтроллер, предназначенный для защиты оборудования с помощью интегрированных криптографических ключей. Обычно он предварительно установлен на более новых компьютерах. BitLocker и DM-Crypt могут использовать эту технологию для защиты ключей, используемых для шифрования томов дисков и обеспечения целостности процесса загрузки компьютера.

Для управляемых дисков шифрование дисков Azure позволяет шифровать диски ОС и данных, используемые виртуальной машиной IaaS; Однако данные не могут быть зашифрованы без первого шифрования тома ОС. Решение полагается на Azure Key Vault, чтобы контролировать и управлять ключами шифрования дисков в хранилищах ключей. Вы можете предоставить собственные ключи шифрования, которые защищены в Azure Key Vault для поддержки сценариев создания собственного ключа (BYOK), как описано ранее в разделе управления ключами шифрования данных .

Шифрование дисков Azure не поддерживает управляемый HSM или локальную службу управления ключами. Только хранилища ключей, управляемые службой Azure Key Vault, можно использовать для защиты ключей шифрования, управляемых клиентом, для шифрования дисков Azure. Ознакомьтесь с шифрованием на узле для других параметров, связанных с управляемым устройством HSM.

Шифрование дисков Azure использует два ключа шифрования для реализации, как описано ранее:

• Ключ шифрования данных (DEK) — это симметричный ключ AES-256, используемый для шифрования томов ОС и данных с помощью BitLocker или DM-Crypt. Сам DEK шифруется и хранится во внутреннем расположении, близком к данным.
• Ключ шифрования ключей (KEK) — это асимметричный ключ RSA-2048, используемый для шифрования ключей шифрования данных. KEK хранится в Azure Key Vault под вашим контролем, включая предоставление разрешений доступа с помощью идентификатора Microsoft Entra.

DEK, зашифрованный с помощью KEK, хранится отдельно, и только сущность с доступом к KEK может расшифровать DEK. Доступ к KEK охраняется Azure Key Vault, где можно сохранить ключи в проверенных аппаратных модулях безопасности FIPS 140.

Для виртуальных машин Windows шифрование дисков Azure выбирает метод шифрования в BitLocker на основе версии Windows, например XTS-AES 256-разрядной версии Windows Server 2012 или более поздней версии. Эти модули шифрования проверены FIPS 140 в рамках программы проверки MICROSOFT Windows FIPS. Для виртуальных машин Linux шифрование Azure Disk использует алгоритм по умолчанию aes-xts-plain64 с 256-разрядным главным ключом тома, который проверен на соответствие FIPS 140 в рамках проверки DM-Crypt, полученной от поставщиков образов виртуальных машин IaaS Linux в Microsoft Azure Marketplace.

Шифрование на стороне сервера для управляемых дисков

Управляемые диски Azure — это тома хранилища на уровне блоков, управляемые Azure и используемые с виртуальными машинами Windows и Linux. Они упрощают управление дисками для виртуальных машин IaaS Azure, прозрачно обрабатывая управление учетными записями хранения. Управляемые диски Azure автоматически шифруют данные по умолчанию с помощью 256-разрядного шифрования AES , проверенного FIPS 140. Для управления ключами шифрования у вас есть следующие варианты:

• Ключи, управляемые платформой, — это выбор по умолчанию, обеспечивающий прозрачное шифрование данных на управляемых дисках на этапе покоя, причем ключи управляются корпорацией Майкрософт.
• Управляемые клиентом ключи позволяют контролировать собственные ключи, которые можно импортировать в Azure Key Vault или управляемый HSM. Этот подход основан на двух наборах ключей, как описано ранее: DEK и KEK. DEK шифрует данные с помощью шифрования на основе AES-256, который, в свою очередь, шифруется с помощью RSA KEK, хранящегося в Хранилище ключей Azure или в Управляемой HSM.

Управляемые клиентом ключи (CMK) позволяют полностью контролировать ключи шифрования. Вы можете предоставить доступ к управляемым дискам в Azure Key Vault, чтобы ключи можно было использовать для шифрования и расшифровки DEK. Вы также можете отключить ключи или отозвать доступ к управляемым дискам в любое время. Наконец, вы можете полностью контролировать использование ключей с помощью мониторинга Azure Key Vault, чтобы обеспечить доступ только к управляемым дискам или другим авторизованным ресурсам.

Шифрование на узле

Шифрование на узле работает с шифрованием на стороне сервера, чтобы гарантировать, что данные, хранящиеся на узле виртуальной машины, зашифрованы в состоянии покоя и передаются в зашифрованном виде в службу хранилища. Сервер, на котором размещена виртуальная машина, шифрует данные без влияния на производительность или требования к коду, работающему на гостевой виртуальной машине, и что зашифрованные данные передаются в службу хранилища Azure с помощью ключей, настроенных для шифрования на стороне сервера. Дополнительные сведения см. в разделе "Шифрование на узле— сквозное шифрование для данных виртуальной машины". Шифрование на узле с помощью CMK может использовать ключи, хранящиеся в управляемом HSM или Key Vault, как и шифрование на стороне сервера для управляемых дисков.

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

Удаление данных

Хранилище выделяется разреженно, что означает, что при создании виртуального диска дисковое пространство не выделяется для всей емкости. Вместо этого создается таблица, сопоставляющая адреса на виртуальном диске с областями на физическом диске, и эта таблица изначально пуста. При первом написании данных на виртуальном диске выделяется место на физическом диске, а указатель на него помещается в таблицу. Дополнительные сведения см. в статье "Безопасность данных Azure" — очистка и утечка данных.

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

В службе хранилища Azure все операции записи дисков являются последовательными. Этот подход сводит к минимуму количество обращений к диску (seek), но требует обновления указателей на объекты каждый раз, когда они записываются — новые версии указателей также записываются последовательно. Побочным эффектом этого дизайна является то, что невозможно убедиться, что секрет на диске исчез, перезаписав его с другими данными. Исходные данные останутся на диске, и новое значение будет записано последовательно. Указатели будут обновлены таким образом, чтобы больше не было способа найти удаленное значение. Однако после полного завершения диска система должна записывать новые журналы в дисковое пространство, которое было освобождено путем удаления старых данных. Вместо выделения файлов журналов непосредственно из секторов дисков файлы журналов создаются в файловой системе под управлением NTFS. Фоновый поток, работающий на узлах службы хранилища Azure, освобождает место, просматривая самый старый файл журнала, копируя блоки, на которые по-прежнему ссылается старый файл журнала в текущий файл журнала, и обновляя все указатели по мере его использования. Затем он удаляет старый файл журнала. Таким образом, на диске есть две категории свободного места: (1) пространство, которое NTFS считает свободным, из которого выделяются новые файлы журналов; и (2) пространство в этих файлах журналов, которое служба хранилища Azure считает свободным, так как в ней нет текущих указателей.

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

• Клиент не может считывать удаленные данные другого клиента.
• Если кто-либо пытается считывать регион на виртуальном диске, на который они еще не записаны, физическое пространство не будет выделено для этого региона и поэтому будет возвращено только нули.

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

Концептуально это обоснование применяется независимо от программного обеспечения, которое отслеживает операции чтения и записи. Для Azure SQL Database программное обеспечение базы данных SQL осуществляет принудительное соблюдение. Для службы хранилища Azure это программное обеспечение службы хранилища Azure. Для недолговечных дисков ВМ отвечает код обработки VHD операционной системы хоста. Сопоставление между виртуальным и физическим адресом происходит за пределами виртуальной машины клиента.

Наконец, как описано в разделе шифрования неактивных данных и приведенном на рис. 16, иерархия ключей шифрования зависит от ключа шифрования ключей (KEK), который может храниться в Azure Key Vault под вашим контролем (т. е. ключ, управляемый клиентом — CMK) и используемый для шифрования ключа шифрования данных (DEK), который в свою время шифрует неактивных данных с помощью симметричного шифрования AES-256. Данные в службе хранилища Azure шифруются по умолчанию, и вы можете выбрать ключи шифрования под собственным контролем. Таким образом, вы также можете запретить доступ к данным, хранящимся в Azure. Кроме того, так как KEK требуется для расшифровки ключей, KEK фактически является одной точкой, с помощью которой можно удалить DEK путем удаления KEK.

Хранение данных

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

Если срок действия подписки истекает или завершается, корпорация Майкрософт сохранит данные клиента в течение 90-дневного периода хранения, чтобы позволить вам извлекать данные или обновлять подписки. После этого периода хранения корпорация Майкрософт будет удалять все данные клиента в течение еще 90 дней, то есть данные клиента будут окончательно удалены через 180 дней после истечения срока действия или прекращения. Учитывая процедуру хранения данных, вы можете управлять временем хранения данных при завершении службы с корпорацией Майкрософт. Рекомендуется не завершать работу службы, пока вы не извлекли все данные, чтобы начальный 90-дневный период хранения может выступать в качестве буфера безопасности, если позже вы поняли, что пропустили что-то.

Если вы удалили всю учетную запись хранения по ошибке, обратитесь в службу поддержки Azure , чтобы получить помощь по восстановлению. Вы можете создавать запросы на поддержку и управлять ими на портале Azure. Учетная запись хранения, удаленная в подписке, сохраняется в течение двух недель, чтобы разрешить восстановление от случайного удаления, после которого она окончательно удаляется. Однако при удалении объекта хранилища (например, BLOB-объекта, файла, очереди, таблицы) операция удаления является немедленной и необратимой. Если вы не сделали резервную копию, удаленные объекты хранилища не могут быть восстановлены. Для хранилища BLOB-объектов можно реализовать дополнительную защиту от случайных или ошибочных изменений и удалений, включив мягкое удаление. Если для учетной записи хранения включено мягкое удаление, большие двоичные объекты, версии BLOB-объектов и моментальные снимки в этой учетной записи могут быть восстановлены после их удаления в течение указанного вами периода хранения. Чтобы избежать хранения данных после удаления учетной записи хранения или подписки, можно удалить объекты хранилища отдельно перед удалением учетной записи хранения или подписки.

Для случайного удаления, связанного с базой данных SQL Azure, необходимо проверить резервные копии, которые служба выполняет автоматически и использовать восстановление на определенный момент времени. Например, полное резервное копирование базы данных выполняется еженедельно, а разностные резервные копии баз данных выполняются почасово. Кроме того, отдельные службы (например, Azure DevOps) могут иметь собственные политики для случайного удаления данных.

Уничтожение данных

Если диск, используемый для хранения, страдает от сбоя оборудования, он безопасно удаляется или уничтожается перед выводом из эксплуатации. Данные на диске удаляются, чтобы гарантировать, что данные не могут быть восстановлены никакими средствами. При выводе таких устройств Microsoft следует процессу утилизации по стандарту NIST SP 800-88 R1, где классификация данных соответствует FIPS 199 Moderate. Магнитные, электронные или оптические носители очищаются или уничтожаются в соответствии с требованиями, установленными в NIST SP 800-88 R1, где термины определены следующим образом:

• Очистка — "процесс очистки средств массовой информации, который защищает конфиденциальность информации от лабораторной атаки", которая включает в себя "ресурсы и знания для использования нестандартных систем для проведения попыток восстановления данных на носителях за пределами их нормальной операционной среды" с помощью "сигнального оборудования и специально обученного персонала". Примечание. Для жестких дисков (включая ATA, SCSI, SATA, SAS и т. д.) допустима команда безопасного удаления встроенного ПО (однопроходная) или трехпроходная перезапись и проверка на уровне программного обеспечения (например, ноль, случайный) всего физического носителя, включая области восстановления, если таковые есть. Для твердотельных накопителей (SSD) необходима команда безопасного удаления на уровне встроенного ПО.
• Уничтожить - "различные методы, в том числе дезинтеграция, сжигание, пульсирование, измельчение и расплавление", после чего средства массовой информации "не могут быть повторно использованы как первоначально предназначенные".

Операции очистки и уничтожения должны выполняться с помощью средств и процессов, утвержденных корпорацией Майкрософт Security. Записи должны вестись о стирании и уничтожении активов. Устройства, которые не завершают очистку, должны быть удалены (только для магнитных носителей) или уничтожены.

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

Процессы и методики обеспечения безопасности

Гарантии изоляции Azure также применяются внутренней службой майкрософт по использованию жизненного цикла разработки безопасности (SDL) и другими строгими процессами обеспечения безопасности для защиты поверхностей атак и устранения угроз. Корпорация Майкрософт создала ведущие в отрасли процессы и инструменты, обеспечивающие высокую уверенность в гарантии изоляции Azure.

• Жизненный цикл разработки безопасности (SDL) — Microsoft SDL представляет рекомендации по безопасности и конфиденциальности на всех этапах процесса разработки, помогая разработчикам создавать высокозащищенное программное обеспечение, устранять требования к соответствию безопасности и сокращать затраты на разработку. Рекомендации, лучшие практики, инструменты и процессы в Microsoft SDL используются внутри компании для разработки всех служб Azure и создания более защищённых продуктов и служб. Этот процесс также публично задокументирован для совместного использования обучения Майкрософт с более широкой отраслью и включения отраслевых отзывов для создания более сильного процесса разработки безопасности.
• Средства и процессы . Весь код Azure подвержен обширному набору статических и динамических средств анализа, которые определяют потенциальные уязвимости, неэффективные шаблоны безопасности, повреждение памяти, проблемы с привилегиями пользователей и другие критически важные проблемы безопасности.
  • Целенаправленное фаззинг-тестирование — метод тестирования, используемый для поиска уязвимостей безопасности в программных продуктах и услугах. Он состоит из многократного введения измененных или фаззированных данных во входы программ для активации зависаний, исключений и сбоев, которые злоумышленник может использовать для вывода из строя или захвата контроля над приложениями и службами. Microsoft SDL рекомендует фаззинг всех поверхностей атак программного продукта, особенно тех, которые подвергают синтаксический анализатор ненадежным данным.
  • Тестирование на проникновение в реальном времени — корпорация Майкрософт проводит текущее тестирование на проникновение в реальном времени для улучшения управления безопасностью и процессов облачной безопасности в рамках программы Red Teaming, описанной далее в этом разделе. Тестирование на проникновение — это анализ безопасности программной системы, выполняемой квалифицированными специалистами по безопасности, имитацией действий хакера. Цель теста на проникновение заключается в выявлении потенциальных уязвимостей, вызванных ошибками кодирования, сбоями конфигурации системы или другими недостатками операционного развертывания. Тесты выполняются в отношении инфраструктуры и платформ Azure, а также собственных клиентов, приложений и данных Майкрософт. Арендаторы, приложения и данные, размещенные в Azure, не являются целью; однако вы можете провести собственное тестирование на проникновение приложений, развернутых в Azure.
  • Моделирование угроз — основной элемент Microsoft SDL. Это инженерный метод, используемый для выявления угроз, атак, уязвимостей и контрмер, которые могут повлиять на приложения и службы. Моделирование угроз является частью жизненного цикла разработки в Azure.
  • Автоматическое создание оповещений об изменениях в области поверхности атаки— это средство безопасности с открытым исходным кодом, разработанное корпорацией Майкрософт, которое анализирует область атаки целевой системы и сообщает о потенциальных уязвимостях безопасности, введенных во время установки программного обеспечения или неправильной настройки системы. Основная функция Attack Surface Analyzer — это возможность проводить сравнительный анализ конфигурации безопасности операционной системы до и после установки программного компонента. Эта функция важна, так как большинство процессов установки требуют повышенных привилегий, и после предоставления они могут привести к непреднамеренные изменения конфигурации системы.
• Обязательное обучение безопасности . Программа обучения безопасности и осведомленности Microsoft Azure требует, чтобы все сотрудники, ответственные за разработку и операции Azure, осуществляли необходимую подготовку и дополнительные учебные курсы на основе отдельных требований к заданию. Эти процедуры обеспечивают стандартный подход, инструменты и методы, используемые для реализации и поддержания программы осведомленности. Корпорация Майкрософт реализовала программу повышения осведомленности по безопасности под названием STRIKE, которая предоставляет ежемесячную электронную рассылку всем инженерам Azure на тему безопасности и позволяет сотрудникам регистрироваться для обучения по вопросам безопасности в очной или онлайн форме. STRIKE предлагает ряд мероприятий по обучению безопасности в течение года плюс STRIKE Central, который является централизованным онлайн-ресурсом для осведомленности, обучения, документации и участия сообщества.
• Программа Bug Bounty — Корпорация Майкрософт решительно считает, что тесное партнерство с академическими и отраслевыми исследователями гарантирует более высокий уровень безопасности для вас и ваших данных. Исследователи по безопасности играют важную роль в экосистеме Azure, обнаружив уязвимости, пропущенные в процессе разработки программного обеспечения. Программа вознаграждений за уязвимости Microsoft предназначена для дополнения и поощрения исследований в соответствующих технологиях (например, шифрование, спуфинг, изоляция гипервизора, повышение привилегий и т. д.) для более эффективной защиты инфраструктуры Azure и ваших данных. Например, для каждой критической уязвимости, определенной в гипервизоре Azure, корпорация Майкрософт компенсирует исследователей безопасности до $250 000 — значительную сумму для стимулирования участия и раскрытия уязвимостей. Диапазон bounty для отчетов об уязвимостях в службах Azure составляет до 60 000 долларов.
• Действия Red Team — Корпорация Майкрософт использует Red Teaming, форму динамического тестирования на проникновение сайтов с использованием управляемой корпорацией Майкрософт инфраструктуры, служб и приложений. Корпорация Майкрософт имитирует реальные нарушения, постоянно отслеживает безопасность и практикует реагирование на инциденты безопасности для тестирования и улучшения безопасности Azure. Основой Red Teaming является стратегия безопасности «Предположение о взломе», реализуемая двумя основными группами: Red Team (злоумышленники) и Blue Team (защитники). Этот подход предназначен для тестирования систем и операций Azure, используя ту же тактику, методы и процедуры, что и реальные злоумышленники, в производственной инфраструктуре, без предварительного уведомления команд инженеров или операторов инфраструктуры и платформы. Этот подход проверяет возможности обнаружения безопасности и реагирования, а также помогает выявлять уязвимости в рабочей среде, ошибки конфигурации, недопустимые предположения или другие проблемы безопасности в управляемом режиме. За каждым нарушением Red Team следует полное раскрытие информации между красной командой и синей командой для выявления пробелов, устранения результатов и значительно улучшения реагирования на нарушения.

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

Аспекты логической изоляции

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

Рекомендации по физической и логической безопасности

Таблица 6 содержит сводку ключевых аспектов безопасности для физически изолированных локальных развертываний (без операционной системы) и логически изолированных облачных развертываний (Azure). Перед изучением рисков, определенных для общих облачных сред, рекомендуется ознакомиться с этими рекомендациями.

Таблица 6. Основные аспекты безопасности для физической и логической изоляции

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

Эксплуатация уязвимостей в технологиях виртуализации

По сравнению с традиционными локальными размещенными системами Azure обеспечивает значительно уменьшенную область атаки с помощью заблокированного ядра Windows Server для ОС узла, наложенного на гипервизор. Кроме того, по умолчанию гостевые виртуальные машины PaaS не имеют учетных записей пользователей для приема входящих удаленных подключений, а учетная запись администратора Windows по умолчанию отключена. Программное обеспечение на виртуальных машинах PaaS по умолчанию ограничено выполнением под учетной записью с низким уровнем привилегий, которая помогает защитить службу от атак собственными конечными пользователями. Эти разрешения можно изменить, и вы также можете настроить виртуальные машины, чтобы разрешить удаленный административный доступ.

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

Атаки по побочным каналам

Корпорация Майкрософт была на переднем крае устранения спекулятивных атак на стороне канала выполнения , которые используют аппаратные уязвимости в современных процессорах, использующих гиперпотоки. Во многих отношениях эти проблемы похожи на атаку по боковому каналу Spectre (вариант 2), которая была раскрыта в 2018 году. В 2022 году обеими компаниями Intel и AMD были раскрыты несколько новых уязвимостей в каналах стороннего доступа при спекулятивном выполнении. Для решения этих уязвимостей корпорация Майкрософт разработала и оптимизировала Hyper-V HyperClear, комплексную и высокопроизводительную архитектуру устранения уязвимостей бокового канала. HyperClear использует три основных компонента, чтобы обеспечить надежную изоляцию между виртуальными машинами:

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

Эти средства защиты были развернуты в Azure и доступны в windows Server 2016 и более поздних версиях.

Когда виртуальные машины, принадлежащие разным клиентам, работают на одном физическом сервере, это задание гипервизора, чтобы убедиться, что они не могут узнать ничего важного о том, что делают другие виртуальные машины клиента. Azure помогает блокировать несанкционированное прямое взаимодействие по своему замыслу; однако существуют незаметные эффекты, при которых один клиент может быть в состоянии охарактеризовать работу, выполняемую другим клиентом. Наиболее важными из этих эффектов являются эффекты времени, когда разные виртуальные машины конкурируют за одни и те же ресурсы. Тщательно сравнивая количество операций на ЦП с временем выполнения, виртуальная машина может узнать что-то о других виртуальных машинах на том же сервере. Эти эксплойты получили много внимания в академической прессе, где исследователи стремились узнать более конкретную информацию о том, что происходит в одноранговой виртуальной машине.

В частности, необходимо изучить криптографические ключи одноранговой виртуальной машины , измеряя время доступа к определенной памяти и выводив, какие строки кэша виртуальной машины жертвы считывают и обновляются. В контролируемых условиях с виртуальными машинами с использованием гиперпотоков успешно продемонстрировались атаки на коммерчески доступные реализации криптографических алгоритмов. В дополнение к ранее упомянутой архитектуре смягчения последствий HyperClear Hyper-V, используемой в Azure, существуют несколько дополнительных мер в Azure, которые снижают риск такой атаки:

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

В целом PaaS или любая рабочая нагрузка, которая автоматически создается виртуальными машинами, способствует увеличению объема операций размещения виртуальных машин, что приводит к случайному выделению виртуальных машин. Случайное размещение виртуальных машин значительно затрудняет доступ злоумышленников к одному узлу. Кроме того, доступ к хосту затверден с значительно уменьшенной областью атаки, что делает эти типы эксплойтов трудными для поддержания.

Сводка

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

Azure устраняет предполагаемый риск совместного использования ресурсов, предоставляя надежную основу для обеспечения мультитенантной, криптографически определенной, логически изолированной облачной службы с помощью общего набора принципов:

• Элементы управления доступом пользователей с аутентификацией и разделением идентификаций, использующие Microsoft Entra ID и управление доступом на основе ролей Azure (Azure RBAC).
• Изоляция вычислений для обработки, включая логическую и физическую изоляцию вычислений.
• Сетевая изоляция, включая разделение сетевого трафика и шифрования данных при передаче.
• Изоляция хранилища с шифрованием данных в состоянии покоя с использованием расширенных алгоритмов, нескольких шифров и ключей шифрования, а также поддержка ключей, управляемых клиентом (CMK), под вашим контролем в Azure Key Vault.
• Процессы обеспечения безопасности, внедренные в структуру службы, для правильной разработки логически изолированных служб, включая жизненный цикл разработки безопасности (SDL) и другие надежные процессы обеспечения безопасности для защиты поверхностей атак и снижения рисков.

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

Дальнейшие шаги

Дополнительные сведения:

• Документация по основам безопасности Azure
• Безопасность инфраструктуры Azure
• Целостность и безопасность платформы Azure
• Обзор Azure для государственных организаций
• Безопасность Azure для государственных учреждений
• Соответствие требованиям Azure для государственных организаций
• Предложения по соответствию требованиям Azure и других службы Майкрософт