Изменить

Меры безопасности для приложений IaaS с высоким уровнем конфиденциальности в Azure

Шифрование дисков Azure
Брандмауэр Azure
Azure Key Vault
Microsoft Defender для облака
Виртуальная сеть Azure

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

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

Виртуальные машины Azure

Вычислительная платформа Azure основана на виртуализации машин. Гипервизор выполняется на физическом оборудовании каждого узла Или конечной точки сети Azure и создает переменное число гостевых виртуальных машин Hyper-V на узле. Весь пользовательский код выполняется на виртуальных машинах. Основные инструкции по развертыванию виртуальных машин Azure см. в статье "Запуск виртуальной машины Linux в Azure " или запуск виртуальной машины Windows в Azure. Большинство процессов развертывания одинаковы для двух операционных систем (OS), но такие средства, как шифрование дисков, могут отличаться.

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

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

Архитектуры N-уровней

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

  • Высокий уровень доступности (HA). Приложения высокой доступности должны быть доступны более 99,9% времени. Размещение виртуальных машин на уровне в разных зонах доступности Azure обеспечивает высокий уровень доступности, так как AZ охватывает один или несколько центров обработки данных, обеспечивая устойчивость через сопротивление сбоям центра обработки данных. Регионы, которые не поддерживают AZ, могут использовать группы доступности (ASS), которые распределяют виртуальные машины между несколькими изолированными аппаратными узлами.
  • Балансировка нагрузки. Подсистемы балансировки нагрузки распределяют трафик между виртуальными машинами, балансируйте нагрузку и устойчивость при сбое виртуальной машины. Вам не нужны подсистемы балансировки нагрузки, если приложение управляет балансировкой нагрузки, а отдельные виртуальные машины известны вызывающим.
  • Виртуальные сети. Виртуальные сети и подсети сегментирует сеть, что упрощает управление безопасностью и расширенную маршрутизацию.
  • Система доменных имен (DNS). Azure DNS предоставляет высокодоступную и безопасную службу DNS. Частная зона в Azure DNS позволяет использовать пользовательские домены в виртуальных сетях.

Резервное копирование и восстановление

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

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

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

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

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

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

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

Минимальный размер изолированной виртуальной машины составляет 64 виртуальных ЦП и 256 ГиБ памяти. Эти виртуальные машины гораздо больше, чем требуется большинство приложений n-уровней, и могут создавать большие затраты. Чтобы сократить затраты, можно запустить несколько уровней приложений на одной виртуальной машине с вложенной виртуализацией или в разных процессах или контейнерах. Вам по-прежнему нужно развернуть разные виртуальные машины в AZ для обеспечения устойчивости и запустить демилитаризованные зоны (DMZ) (модуль) на отдельных виртуальных машинах. Объединение нескольких приложений в одной инфраструктуре по экономическим причинам может также конфликтуть с политиками разделения приложений организации.

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

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

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

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

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

Шифрование

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

Azure Key Vault

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

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

При размещении SQL Server на виртуальной машине можно использовать Соединитель SQL Server для Microsoft Azure Key Vault для получения ключей для прозрачного шифрования данных (TDE), шифрования на уровне столбцов (CLE) и шифрования резервных копий. Дополнительные сведения см. в статье "Настройка интеграции Azure Key Vault для SQL Server на виртуальных машинах Azure".

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

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

Для высокочувствительных рабочих нагрузок также следует использовать ключ шифрования ключей (KEK) для дополнительного уровня безопасности. При указании KEK Шифрование дисков Azure использует этот ключ для упаковки секретов шифрования перед записью в Key Vault. Вы можете создать KEK в Azure Key Vault, но более безопасный метод — создать ключ в локальной среде HSM и импортировать его в Azure Key Vault. Такой сценарий с использованием собственного ключа часто называется BYOK. Так как импортированные ключи не могут оставить границу HSM, создав ключ в HSM, обеспечивает полный контроль над ключами шифрования.

Шифрование, защищенное HSM

Дополнительные сведения о ключах, защищенных HSM, см. в статье "Создание и передача ключей, защищенных HSM" для Azure Key Vault.

Шифрование сетевого трафика

Сетевые протоколы, такие как HTTPS, шифруют данные при передаче с помощью сертификатов. Трафик клиента к приложению обычно использует сертификат из доверенного центра сертификации (ЦС). Внутренние приложения могут использовать сертификат из внутреннего ЦС или общедоступного ЦС, например DigiCert или GlobalSign. Обмен данными между уровнями обычно использует сертификат, выданный внутренним ЦС или самозаверяющий сертификат. Azure Key Vault может разместить любой из этих типов сертификатов. Дополнительные сведения о создании различных типов сертификатов см. в разделе "Методы создания сертификата".

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

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

Безопасность сети

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

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

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

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

Вы можете использовать сетевые сети, такие как Брандмауэр Azure, чтобы разрешить, блокировать и проверять сетевой трафик. Брандмауэр Azure — это управляемая, высокодоступная служба брандмауэра платформы. Вы также можете развернуть сторонние NVAs из Azure Marketplace. Сведения о том, как сделать эти виртуальные виртуальные (модуль) сети высокодоступными, см. в статье "Развертывание высокодоступных виртуальных (модуль) сети".

Группы безопасности приложений

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

Группы безопасности приложений

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

Гибридные сети

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

  • Общедоступная конечная точка через Интернет. Вы можете полагаться на удостоверение, безопасность на уровне транспорта (HTTPS) и шлюз приложений для защиты приложения, потенциально в сочетании с брандмауэром. Однако для высокочувствительных рабочих нагрузок не рекомендуется предоставлять общедоступную конечную точку через Интернет.
  • VPN-шлюз Azure или стороннего VPN-шлюза. Вы можете подключить локальную сеть к Azure с помощью VPN-шлюза Azure. Трафик по-прежнему перемещается через Интернет, но через зашифрованный туннель, использующий TLS. Вы также можете запустить сторонний шлюз на виртуальной машине, если у вас есть определенные требования, не поддерживаемые VPN-шлюзом Azure.
  • ExpressRoute. В подключениях ExpressRoute используются частные выделенные подключения через сети сторонних поставщиков услуг подключения. Частное подключение расширяет локальную сеть в Azure и обеспечивает масштабируемость и надежное соглашение об уровне обслуживания (SLA).
    • ExpressRoute с отработкой отказа VPN. Этот параметр использует ExpressRoute в обычных условиях, но выполняет отработку отказа в VPN-подключение, если в канале ExpressRoute возникает потеря подключения, обеспечивая более высокую доступность.
    • VPN через ExpressRoute. Этот вариант лучше всего подходит для высокочувствительных рабочих нагрузок. ExpressRoute предоставляет частный канал с масштабируемостью и надежностью, а VPN обеспечивает дополнительный уровень защиты, который завершает зашифрованное подключение в определенной виртуальной сети Azure.

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

Развертывание dmZ

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

Архитектура, такая как сеть dmZ между Azure и локальным центром обработки данных, развертывает все службы dmZ и приложений в одной виртуальной сети с правилами NSG и определяемыми пользователем маршрутами для изоляции dmZ и подсетей приложений. Эта архитектура может сделать подсеть управления доступной через общедоступный Интернет, чтобы управлять приложениями, даже если локальный шлюз недоступен. Однако для высокочувствительных рабочих нагрузок следует разрешить обход шлюза в сценарии с разрывом. Лучшее решение — использовать Бастион Azure, который обеспечивает доступ непосредственно из портал Azure при ограничении воздействия общедоступных IP-адресов.

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

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

Развертывание в нескольких регионах

Для обеспечения непрерывности бизнес-процессов и аварийного восстановления может потребоваться развертывание приложения в нескольких регионах Azure, что может повлиять на расположение данных и безопасность. Эталонная архитектура для развертываний с несколькими регионами см. в статье "Запуск N-уровня приложения в нескольких регионах Azure для обеспечения высокой доступности".

Пары регионов

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

Дополнительные сведения см. в разделе "Непрерывность бизнес-процессов" и аварийное восстановление (BCDR): парные регионы Azure. В техническом документе реализованы соответствующие требования к месту размещения и безопасности данных в Azure , а также о том, что делать для удовлетворения требований к месту размещения данных.

Репликация между регионами

В архитектурах IaaS реплика данные между регионами являются ответственностью за приложение. Наиболее распространенный сценарий реплика tion использует технологии реплика создания базы данных, встроенные в продукт сервера базы данных, такие как группы доступности SQL Server AlwaysOn, Oracle Data Guard или репликация MySQL.

Настройка реплика между серверами баз данных IaaS не является простой задачей, и необходимо учитывать требования к непрерывности бизнес-процессов. Службы баз данных Azure, такие как База данных SQL Azure, База данных Azure для MySQL и Azure Cosmos DB, упрощают реплика между регионами, но могут не соответствовать требованиям безопасности для высокочувствительных рабочих нагрузок.

Дополнительные сведения и рекомендации по развертыванию SQL Server в нескольких регионах и Oracle см. в следующем разделе:

Пиринг между регионами

Вы можете включить безопасное взаимодействие между виртуальными сетями в разных регионах с помощью пиринга глобальной виртуальной сети. Глобальный пиринг работает так же, как пиринг внутри региона. Трафик между регионами проходит через магистраль Майкрософт, не проходит через Интернет и изолирован от другого трафика. Для обеспечения большей безопасности можно развернуть виртуальные сети VPN в обоих регионах и использовать определяемые пользователем маршруты для принудительного трафика между регионами через NVAs, аналогично развертыванию dmZ.

Маршрутизация трафика отработки отказа

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

Управление

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

Для развертывания рабочих нагрузок в Azure требуется одна или несколько учетных записей управления. Защита учетных записей управления крайне важна для защиты рабочих нагрузок. Дополнительные сведения см. в разделе "Безопасный привилегированный доступ" для гибридных и облачных развертываний в идентификаторе Microsoft Entra ID.

Используйте ресурсы в подсети управления, чтобы предоставить доступ на уровне приложений только пользователям, которым требуется управлять этим уровнем. Например, можно использовать Microsoft Identity Manager с идентификатором Microsoft Entra. Однако для облачных сценариев microsoft Entra управление привилегированными пользователями (PIM) предпочтительнее.

Существует несколько других способов управления ролями и политиками Azure.

  • Управление доступом на основе ролей Azure (Azure RBAC) для ресурсов Azure позволяет назначать встроенные или пользовательские роли пользователям, поэтому у них есть только необходимые привилегии. Вы можете объединить Azure RBAC с PIM для реализации проверенного рабочего процесса утверждения, который повышает привилегии в течение ограниченного периода времени.
  • Политики применяют корпоративные правила, стандарты и соглашения об уровне обслуживания. Политика Azure — это служба Azure, которая создает, назначает и управляет политиками и оценивает ресурсы для соответствия политик.
  • Azure Blueprints объединяет назначения ролей, назначения политик и шаблоны развертывания, чтобы определить набор реплика ближенных ресурсов Azure, которые реализуют и следуют стандартам, шаблонам и требованиям организации. Схемы — это декларативный способ оркестрации развертывания шаблонов ресурсов и других артефактов. Вы можете самостоятельно создавать схемы или использовать существующие схемы. Например, схема общих служб ISO 27001 развертывает общий центр служб, который можно изменить и расширить до требований вашей организации.

Наблюдение

Microsoft Defender для облака предоставляет мониторинг и оповещения, которые помогают обеспечить безопасность вашей среды. Бесплатная служба автоматически проверка уязвимостей, таких как отсутствие исправлений ОС, неправильное настройку безопасности и базовую сетевую безопасность. Платная версия уровня "Стандартный" предоставляет дополнительные функции, такие как аналитика поведения, адаптивная защита сети и доступ к виртуальной машине JIT. Полный список функций см. в статье Обзор функций для компьютеров. Defender для облака также обеспечивает защиту от угроз для других ресурсов, таких как Azure Key Vault.

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