Изоляция в общедоступном облаке Azure

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

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

Уровень изоляции клиентов

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

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

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

Аренда Azure

Клиент или выставление счетов Azure (подписка Azure) относится к отношениям "клиент или выставление счетов" и уникальному клиенту в идентификаторе Microsoft Entra. Изоляция на уровне клиента в Microsoft Azure достигается с помощью идентификатора Microsoft Entra и управления доступом на основе ролей Azure, предлагаемым им. Каждая подписка Azure связана с одним каталогом Microsoft Entra.

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

• Для доступа к данным в идентификаторе Microsoft Entra id требуется проверка подлинности пользователей через службу маркеров безопасности (STS). Система авторизации определяет, имеет ли этот пользователь в этом сеансе право на доступ требуемого типа к целевому клиенту. Решение принимается на основе информации о существовании, состоянии активности и роли пользователя.

• Клиенты являются дискретными контейнерами, и между ними нет связи.

• У клиентов нет доступа друг к другу, если только администратор клиентов не предоставит его, использовав федерацию или подготовив учетные записи пользователей из других клиентов.

• Физический доступ к серверам, составляющим службу Microsoft Entra, и прямой доступ к внутренним системам Идентификатора Microsoft Entra ограничен.

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

Для диагностики и обслуживания требуется и используется рабочая модель, которая использует JIT-систему повышения привилегий. Microsoft Entra управление привилегированными пользователями (PIM) представляет концепцию соответствующего администратора. Допустимые администраторы должны быть пользователями, которым нужен привилегированный доступ сейчас, но не каждый день. Эта роль будет неактивной, пока пользователю не потребуется доступ. При необходимости пользователь выполнит активацию и станет активным администратором на заранее определенный период времени.

Идентификатор Microsoft Entra id размещает каждый клиент в собственном защищенном контейнере с политиками и разрешениями для и в контейнере, принадлежащих и управляемым клиентом.

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

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

Управление доступом на основе ролей в Azure (Azure RBAC)

Управление доступом на основе ролей в Azure (Azure RBAC) позволяет совместно использовать различные компоненты, доступные в подписке Azure, обеспечивая детализированное управление доступом в Azure. Azure RBAC позволяет разделять обязанности в организации и предоставлять доступ в зависимости от того, что нужно пользователям для работы. Вместо того, чтобы предоставить всем неограниченные разрешения для подписки Azure или ресурсов, можно разрешить только определенные действия.

Механизм RBAC Azure (управление доступом на основе ролей) включает в себя три основные роли, которые применяются ко всем типам ресурсов.

• Владелец имеет полный доступ ко всем ресурсам, включая право делегировать доступ другим.

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

• Читатель может просматривать существующие ресурсы Azure.

Остальные роли в Azure дают возможность управлять определенными ресурсами Azure. Например, роль Участник виртуальных машин позволяет пользователю создавать виртуальные машины и управлять ими. Он не предоставляет им доступ к Azure виртуальная сеть или подсети, к которым подключается виртуальная машина.

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

Некоторые другие возможности для идентификатора Microsoft Entra:

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

• Доступ к данным в службе хранилища Azure регулируется механизмом проверки подлинности. Для каждой учетной записи хранения предусмотрен первичный ключ (ключ учетной записи хранения, или SAK) и вторичный секретный ключ (подписанный URL-адрес, или SAS).

• Идентификатор Microsoft Entra предоставляет удостоверение как службу через федерацию с помощью службы федерации Active Directory (AD FS), синхронизации и реплика tion с локальными каталогами.

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

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

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

Изоляция от администраторов корпорации Майкрософт и удаление данных

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

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

Бизнес-службы, использующие сертификаты аудита, например ISO/IEC 27001, регулярно проверяются корпорацией Майкрософт и аккредитованными аудиторскими компаниями, которые проводят выборочный аудит для подтверждения этого доступа, исключительно для законных коммерческих целей. Вы всегда можете получить доступ к своим данным клиента, в любое время и по любой причине.

Если вы удалите данные, Microsoft Azure удалит их, включая все сохраненные в кэше или резервные копии. В соответствующих службах удаление произойдет в течение 90 дней после окончания периода хранения. (Соответствующие службы указаны в разделе "Условия обработки данных" наших условий использования веб-служб.)

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

Изоляция вычислений

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

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

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

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

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

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

• Standard_E80ids_v4
• Standard_E80is_v4
• Standard_E104i_v5
• Standard_E104is_v5
• Standard_E104id_v5
• Standard_E104ids_v5
• Standard_M192is_v2
• Standard_M192ims_v2
• Standard_M192ids_v2
• Standard_M192idms_v2
• Standard_F72s_v2
• Standard_M128ms

Примечание.

Размеры изолированных виртуальных машин имеют ограниченный срок существования из-за нехватки оборудования.

Устаревшие размеры изолированных виртуальных машин

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

Размер	Дата прекращения поддержки функции "Изоляция"
Standard_DS15_v2	15 мая 2021 г.
Standard_D15_v2	15 мая 2021 г.
Standard_G5	15 февраля 2022 г.
Standard_GS5	15 февраля 2022 г.
Standard_E64i_v3	15 февраля 2022 г.
Standard_E64is_v3	15 февраля 2022 г.
Standard_M192is_v2	31 марта 2027 г.
Standard_M192ims_v2	31 марта 2027 г.
Standard_M192ids_v2	31 марта 2027 г.
Standard_M192idms_v2	31 марта 2027 г.

Вопросы и ответы

Вопрос. Прекращается полная поддержка указанного размера или только функции "Изоляция"?

Ответ. Любой размер, опубликованный как изолированный, но не имеет "i" в имени, функция изоляции размеров виртуальных машин удаляется, если не сообщается по-другому. Размеры с "i" в имени будут устаревшими.

Вопрос. Есть ли простой, когда моя виртуальная машина приземляется на неисполнированном оборудовании?

Ответ. Для размеров виртуальных машин, где не рекомендуется использовать только изоляцию, но не размер, никаких действий не требуется, и простоя не будет. Напротив, если изоляция требуется, объявление включает рекомендуемый размер замены. Выбор размера замены требует от клиентов изменить размер виртуальных машин.

Вопрос. Существует ли разностная стоимость перехода на неоконтратированную виртуальную машину?

Ответ. Нет.

Вопрос. Когда будут сняты с поддержки другие изолированные размеры?

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

Вопрос. Я использую платформу Azure Service Fabric на уровне устойчивости "Серебряный" или "Золотой". Повлияет ли это изменение на мою работу?

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

Вопрос. Каковы даты прекращения поддержки изоляции для D15_v2 и DS15_v2?

Ответ.

Дата	Действие
15 мая, 2020 г.1	Объявление о прекращении поддержки изоляции в D/DS15_v2
15 мая 2021 г.	Прекращение гарантии изоляции в D/DS15_v2

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

Вопрос. Каковы даты прекращения поддержки изоляции для G5, Gs5, E64i_v3 и E64is_v3?

Ответ.

Дата	Действие
15 февраля 2021 г.1	Объявление о прекращении поддержки изоляции в G5/GS5/E64i_v3/E64is_v3
28 февраля 2022 г.	Прекращение гарантии изоляции в G5/GS5/E64i_v3/E64is_v3

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

Следующие шаги

Клиенты также могут разделить ресурсы этих изолированных виртуальных машин благодаря поддержке вложенных виртуальных машин в Azure.

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

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

Hyper-V и корневая ОС: изоляция корневой виртуальной машины и гостевых виртуальных машин

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

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

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

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

Расширенный алгоритм размещения виртуальных машин и защита от атак по сторонним каналам

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

Контроллер структуры Azure

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

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

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

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

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

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

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

Дополнительные правила, настраиваемые агентом контроллера структуры для изоляции виртуальных машин

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

Запрограммированы две категории правил.

• Конфигурация компьютера или правила инфраструктуры. По умолчанию весь обмен данными блокируется. Но есть исключения, которые разрешают виртуальной машине отправлять и получать трафик DHCP и DNS. Виртуальные машины могут также отправлять трафик как в общедоступный сегмент Интернета, так и другим виртуальным машинам в той же виртуальной сети Azure и на сервере активации ОС. Список разрешенных исходящих назначений виртуальных машин не включает подсети маршрутизатора Azure, управление Azure и другие свойства Майкрософт.
• Файл конфигурации ролей. Он определяет входящие списки управления доступом на основе клиентской модели службы.

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

В каждом кластере существуют три виртуальные локальные сети.

• Основная виртуальная локальная сеть соединяет ненадежные узлы клиента между собой.
• Виртуальная локальная сеть контроллера структуры содержит доверенные контроллеры структуры и вспомогательные системы.
• Виртуальная локальная сеть устройств содержит доверенные сетевые и другие устройства инфраструктуры.

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

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

Логическая изоляция вычислений и хранилища

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

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

Изоляция с помощью управления доступом к хранилищу

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

Доступом к данным службы хранилища Azure (включая таблицы) можно управлять с помощью маркера SAS (подписанный URL-адрес), который предоставляет доступ с заданной областью. SAS создается с помощью шаблона запроса (URL-адреса), подписанного с помощью SAK (ключа учетной записи хранения). Этот подписанный URL-адрес можно предоставить другому процессу (то есть делегировать), который затем может заполнить данные запроса и выполнить запрос службы хранилища. С помощью SAS можно предоставить клиентам доступ с ограниченным сроком действия, не предоставляя секретный ключ учетной записи хранения.

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

Изоляция хранилища на уровне IP-адреса

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

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

Шифрование

Azure предлагает следующие типы шифрования для защиты данных.

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

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

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

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

Шифрование при хранении

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

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

Дополнительные сведения см. в разделе Общие сведения о параметрах шифрования управляемых дисков.

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

Служба "Шифрование дисков Azure" для виртуальных машин Linux и Windows помогает соблюдать требования (включая корпоративные требования к безопасности). Она выполняет шифрование дисков виртуальных машин (загрузочных дисков и дисков данных) с использованием ключей и политик, которыми вы управляете в Azure Key Vault.

Шифрование дисков для Windows основано на шифровании дисков Microsoft BitLocker, а аналогичное решение для Linux использует шифрование dm-crypt.

В решениях, которые появляются в Microsoft Azure, реализована поддержка следующих сценариев для виртуальных машин IaaS:

• интеграция с хранилищем ключей Azure;
• виртуальные машины IaaS серий A, D, DS, G, GS и т. д. уровня "Стандартный";
• включение шифрования для виртуальных машин IaaS под управлением Windows и Linux;
• отключение шифрования дисков данных и дисков операционной системы виртуальных машин IaaS под управлением Windows;
• отключение шифрования дисков данных виртуальных машин IaaS под управлением Linux;
• включение шифрования для виртуальных машин IaaS под управлением клиентской ОС Windows;
• включение шифрования томов с путями подключения;
• включение шифрования для виртуальных машин Linux с чередованием дисков (RAID) с помощью программы mdadm;
• включение шифрования для виртуальных машин Linux с использованием диспетчера логических томов (LVM) для дисков данных;
• включение шифрования для виртуальных машин Windows, использующих дисковые пространства.
• поддерживаются все общедоступные регионы Azure.

Решение не поддерживает следующие сценарии, функции и технологии в выпуске:

• виртуальные машины уровня "Базовый";
• отключение шифрования диска ОС виртуальных машин IaaS под управлением Linux;
• виртуальные машины IaaS, созданные с помощью классической модели развертывания;
• интеграция с локальной службой управления ключами;
• служба файлов Azure (общая файловая система), NFS, динамические тома, виртуальные машины Windows с программными системами RAID.

Изоляция Базы данных SQL

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

Модель приложения Базы данных SQL

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

С точки зрения приложения База данных SQL предоставляет следующую иерархию: каждый уровень содержит приведенные ниже вложенные уровни по схеме "один ко многим".

Учетная запись и подписка — это понятия, используемые в платформе Microsoft Azure, чтобы связать выставления счетов и управление.

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

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

Логические базы данных master содержат:

• имена для входа SQL, используемые для подключения к серверу;
• Правила брандмауэра

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

С точки зрения клиента сервер создается в географическом регионе, тогда как на самом деле сервер создается в одном из кластеров региона.

Изоляции с помощью топологии сети

При создании сервера и регистрации его DNS-имени, оно указывает на так называемый "виртуальный IP-адрес шлюза" в конкретном центре обработки данных, в котором размещен этот сервер.

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

• Использование прокси-сервера TDS-подключений. Это включает в себя поиск базы данных пользователя во внутреннем кластере, реализацию последовательности входа в систему и пересылку пакетов TDS в серверную часть и обратно.
• Управление базами данных. Это включает в себя реализацию коллекции рабочих процессов для выполнения операций CREATE, ALTER или DROP с базами данных. Операции базы данных могут быть вызваны посредством сканирования пакетов TDS или явного использования интерфейсов API OData.
• Операции пользователя CREATE, ALTER или DROP.
• Операции управления сервером с помощью API OData

Уровень за шлюзом называется "внутренним". На нем хранятся все данные в режиме высокой доступности. Каждый фрагмент данных принадлежит "секции" или "единице отработки отказа", у каждой из которых есть по крайней мере три реплики. Реплики сохраняются и реплицируются ядром SQL Server, а управляет ими система отработки отказа, которую часто называют "структурой".

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

Изоляция с помощью функций и доступа компьютеров

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

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

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

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

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

Next Steps

• Дополнительные сведения см. в статье Варианты сетевой изоляции для компьютеров в виртуальных сетях Microsoft Azure. Здесь показан классический сценарий с внешней и внутренней сетями, в котором компьютеры, размещенные в определенной внутренней сети или подсети, разрешают подключаться к определенной конечной точке только определенным клиентам или компьютерам в соответствии со списком разрешенных IP-адресов.

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