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

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

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

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

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

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

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

Azure аренды

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

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

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

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

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

• Физический доступ к серверам, составляющим службу 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 дней после окончания периода хранения данных. (Раздел "Условия обработки данных" Условия онлайн-сервисов определяет подпадающие под действие службы.)

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

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

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

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

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

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

Кроме того, поскольку виртуальные машины изолированного размера являются большими, клиенты могут разделить ресурсы этих виртуальных машин с помощью поддержки 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_M832ids_16_v3
• Standard_M832is_16_v3
• Standard_M896ixds_24_v3
• Standard_M896ixds_32_v3
• Standard_M1792ixds_32_v3

Объявление об устаревании размеров изолированных виртуальных машин

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Программируйте две категории правил:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шифрование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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