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

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

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

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

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

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

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

Azure аренды

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

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

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

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

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

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

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

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

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

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

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

Контроль доступа Azure на основе ролей (Azure RBAC)

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

Azure RBAC имеет три основные роли, которые применяются ко всем типам ресурсов:

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

• Contributor может создавать и управлять всеми типами ресурсов Azure, но не может предоставлять access другим пользователям.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В настоящее время доступны следующие типы изолированных виртуальных машин:

• Standard_E192is_v6
• Standard_E192ids_v6
• Standard_E104i_v5
• Standard_E104id_v5
• Standard_E104is_v5
• Standard_E104ids_v5
• Standard_E112ias_v5
• Standard_E112iads_v5
• Standard_E80is_v4
• Standard_E80ids_v4
• Standard_E96ias_v4
• Standard_E112ibs_v5
• Standard_E112ibds_v5
• Standard_EC96ias_v5
• Standard_EC96iads_v5
• Standard_HB120rs_v3
• Standard_HB176rs_v4
• Standard_HB368rs_v5
• Standard_HX176rs
• Standard_M832is_16_v3
• Standard_M832ids_16_v3
• Standard_M192is_v2
• Standard_M192ids_v2
• Standard_M192ims_v2
• Standard_M192idms_v2
• Standard_NC64as_T4_v3
• Standard_NC96ads_A100_v4
• Standard_NC80adis_H100_v5
• Standard_ND128isr_NDR_GB200_v6
• Standard_ND128isr_NDR_GB300_v6
• Standard_ND96isr_H100_v5
• Standard_ND96isr_H200_v5
• Standard_ND96isr_MI300X_v5
• Standard_NG32ads_V620_v1
• Standard_NG32adms_V620_v1
• Standard_NV72ads_A10_v5

Вывод из эксплуатации изолированных типоразмеров виртуальных машин

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

Для дальнейшего разделения ресурсов этих изолированных виртуальных машин см. раздел поддержка Azure for nested virtual machines.

Выделенные хосты

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

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

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

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

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

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

Продвинутый алгоритм размещения виртуальных машин и защита от атак на боковых каналах

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

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

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

В Azure корневая виртуальная машина запускает закаленную операционную систему, называемую корневой ОС, в которой размещен агент структуры (FA). FAs управляют гостевыми агентами (GA) в гостевых операционных системах на виртуальных машинах клиентов, а также управляют узлами хранения.

Совокупность гипервизора Azure, корневой ОС/FA и клиентских виртуальных машин/GAs составляет вычислительный узел. Контроллер подключения (FC) управляет функциональными агентами (FA). ФК существует за пределами вычислительных и хранилищ узлов. Отдельные FC управляют вычислительными и хранилищными кластерами. Если заказчик обновляет файл конфигурации приложения во время работы приложения, FC взаимодействует с FA. FA обращается к GA, которые уведомляют приложение о внесении изменения в конфигурацию. В случае сбоя оборудования fc автоматически находит доступное оборудование и перезапускает виртуальную машину там.

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

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

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

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

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

Агент контроллера ткани программирует две категории правил:

• Правила конфигурации машины или инфраструктуры: По умолчанию Azure блокирует всю коммуникацию. Добавьте исключения, позволяющие виртуальной машине отправлять и получать ТРАФИК DHCP и DNS. Виртуальные машины также могут отправлять трафик в "публичный" Интернет, отправлять трафик другим виртуальным машинам в той же виртуальной сети Azure и на сервер активации ОС. Список разрешённых исходящих адресов для виртуальных машин не включает подсети маршрутизатора Azure, управление Azure и другие свойства Microsoft.
• Role configuration file: Этот файл определяет входящие списки контроль доступа (списки управления доступом) на основе модели службы клиента.

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

Каждый кластер содержит три VLAN (виртуальных локальных сетевых областей):

• Основная VLAN: Соединяет недоверенные клиентские узлы.
• FC VLAN: содержит доверенные FC и поддерживающие системы.
• VLAN устройства: содержит доверенные сетевые и другие инфраструктурные устройства.

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

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

Логическая изоляция между вычислениями и хранением

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

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

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

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

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

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

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

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

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

Шифрование

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

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

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

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

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

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

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

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

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

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

Шифрование на узле обеспечивает шифрование на стороне сервера на уровне узла виртуальной машины с помощью шифрования AES 256, совместимого с FIPS 140-2. Это шифрование происходит без использования ресурсов ЦП виртуальной машины и обеспечивает сквозное шифрование:

• Временные диски
• Кэши дисков операционной системы и данных
• Потоки данных в служба хранилища Azure

Основные преимущества шифрования на узле:

• Нет влияния на производительность: шифрование происходит на уровне хоста без использования ресурсов процессора виртуальной машины.
• Широкая поддержка виртуальных машин: поддерживается на большинстве серий и размеров виртуальных машин.
• Ключи, управляемые клиентом: Необязательная интеграция с Azure Key Vault или Managed HSM для управления ключами.
• Ключи, управляемые платформой, по умолчанию: для шифрования не требуется дополнительная конфигурация.

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

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

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

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

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

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

Логические SQL-серверы и базы данных — это концепции, специфичные для SQL Database. Вы управляете ими с помощью интерфейсов OData и T-SQL, предоставленных SQL Database, либо через портал Azure.

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

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

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

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

С вашей точки зрения, вы создаёте сервер в географическом регионе, а Azure создаёт сервер в одном из кластеров этого региона.

Изоляция через топологию сети

Когда вы создаёте сервер и регистрируете его DNS-имя, оно указывает на VIP-адрес Gateway в конкретном дата-центре, где вы размещаете сервер.

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

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

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

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

Изоляция по функциям машины и доступу

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

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

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

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

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

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

• Узнайте о группах безопасности сети. Группы безопасности сети фильтруют сетевой трафик между ресурсами Azure в virtual network. Трафик можно ограничить подсетями или virtual machines на основе источника, назначения, порта и протокола с помощью правил безопасности.

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