Сетевая безопасность

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

Ниже приведены три основных компонента домена безопасности сети.

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

Связанные элементы управления:

• NS-2. Защита облачных служб с помощью сетевых элементов управления
• NS-3. Развертывание брандмауэра на границе корпоративной сети
• NS-5. Развертывание защиты от атак DDOS
• NS-6. Развертывание брандмауэра веб-приложения
• NS-9: Подключить локальную или облачную сеть частным образом

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

Связанные элементы управления:

• NS-1. Установка границ сегментации сети

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

Связанные элементы управления:

• NS-4. Развертывание систем обнаружения и предотвращения вторжений (IDS/IPS)
• NS-8. Обнаружение и отключение небезопасных служб и протоколов
• NS-10. Обеспечение безопасности системы доменных имен (DNS)

NS-1. Установка границ сегментации сети

Политика Azure: См. встроенные определения политик Azure: NS-1.

Принцип безопасности

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

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

• Разделите Corpnet с помощью сетей приложений
• Отдельные сети приложений
• Отдельные сети рабочей и тестовой среды

Дополнительные сведения о ключевых стратегиях сегментации сети см. в Azure Well-Architected Framework:

• Стратегия сегментации Azure

Риск для смягчения

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

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

MITRE ATT&CK

• Первоначальный доступ (TA0001): несанкционированный доступ к сетям и открытым службам (например, T1190 — эксплуатация уязвимого приложения с открытым доступом).
• Боковое перемещение (TA0008): перемещение атаки с использованием виртуальных сетей и неограниченного трафика между подсетями (например, T1021 — удаленные службы).
• Эксфильтрация (TA0010): утечка данных по неограниченным исходящим трафиком для несанкционированного передачи данных на внешние серверы (например, T1041 — эксфильтрация по каналу C2).
• Команда и управление (TA0011): распространение вредоносных программ путем связи с вредоносными IP-адресами или доменами с помощью правил брандмауэра и аналитики угроз (например, T1071 — протокол уровня приложений).

NS-1.1. Создание сегментации с помощью виртуальной сети и подсетей

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

Реализуйте сегментацию виртуальной сети, создавая изолированные границы сети и подразделения:

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

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

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

NS-1.2. Ограничение сетевого трафика с помощью NSG

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

Реализуйте ограничение сетевого трафика с помощью правил NSG:

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

• Определите явные правила разрешения и запрета: Для хорошо определенных приложений (например, трехуровневых архитектур) используйте подход "запретить по умолчанию, разрешать по исключению" для создания правил NSG на основе портов, протокола, исходного IP-адреса и IP-адреса назначения, явно разрешая только необходимый трафик при запрете всех других подключений.

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

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

Пример реализации

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

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

Подход к решению:

• Сегментация виртуальной сети по среде: Создали отдельные виртуальные сети для рабочей среды (10.0.0.0/16), разработку (10.1.0.0.0/16) и тестирование сред (10.2.0.0/16), устанавливая границы сетевой изоляции, которые препятствуют доступу между средами и ограничивают радиус взрыва потенциальных нарушений.
• Сегментация подсети по уровням: В рабочей виртуальной сети создали отдельные не перекрывающиеся подсети для каждого уровня приложения — веб-уровень (10.0.1.0/24), уровень приложения (10.0.2.0/24) и уровень базы данных (10.0.3.0/24) — включение детализированного управления трафиком между уровнями.
• Правила NSG для управления движением на северо-юге: Настроенные правила NSG, чтобы запретить весь входящий трафик из Интернета (0.0.0.0/0) во внутренние подсети и ограничить исходящий доступ к Интернету только доверенным назначениям, с определенными правилами, разрешая только необходимые внешние подключения для веб-уровня, блокируя весь доступ к Интернету из уровня базы данных.
• Правила NSG для горизонтального управления трафиком: Реализованы политики запрета по умолчанию с явными правилами разрешения между уровнями — веб-уровню разрешён исходящий трафик на уровень приложений только на необходимых портах, уровню приложений разрешён исходящий трафик на уровень базы данных только через порт 1433 (SQL), а уровню базы данных отклоняется весь другой входящий трафик, кроме трафика из подсети уровня приложений.
• Удаленный доступ к управлению: Ограниченные порты удаленного управления (RDP 3389/TCP, SSH 22/TCP) для приема подключений только из доверенной подсети узла бастиона (10.0.0.0/26), устраняя прямой доступ к интернету к интерфейсам управления.

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

Уровень критическости

Должно быть.

Сопоставление элементов управления

• NIST SP 800-53 ред.5: SC-7, SC-32, AC-4, CM-7
• PCI-DSS версии 4: 1.2.1, 1.3.1, 1.4.1
• Элементы управления CIS версии 8.1: 12.1, 12.2, 12.6
• NIST CSF версии 2.0: PR. IR-01, PR. AC-05
• ISO 27001:2022: A.8.20, A.8.21
• SOC 2: CC6.1, CC6.6

NS-2. Защита облачных собственных служб с помощью сетевых элементов управления

Политика Azure: См. встроенные определения политик Azure: NS-2.

Принцип безопасности

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

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

Примечание. Помимо базового сетевого контроля доступа и фильтрации трафика, вы также должны использовать возможности обнаружения угроз для мониторинга таких служб, как DNS (NS-10) для обнаружения возможной кражи данных.

Риск для смягчения

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

• Утечка данных через общедоступные конечные точки: Злоумышленники эксплуатируют общедоступные учетные записи хранения, базы данных или API-интерфейсы для получения конфиденциальных данных путем установления несанкционированных подключений к открытым конечным точкам, обхода элементов управления сегментацией сети и включения кражи крупномасштабных данных.
• Атаки уровня приложений на общедоступные конечные точки: Распределенные атаки типа "отказ в обслуживании" (DDoS), внедрение SQL и другие эксплойты приложений предназначены для общедоступных веб-служб, API и баз данных, подавляющих ресурсов или уязвимостей, чтобы привести к нарушению работы службы или компрометации данных.
• Атаки "человек посередине": Злоумышленники перехватывают трафик, передаваемый через общественные сети к открытым службам, занимаясь записью учетных данных, маркеров сеансов или конфиденциальной информации, передаваемой без достаточного шифрования или частного подключения, что позволяет захват учетных записей или кражу данных.

MITRE ATT&CK

• Первоначальный доступ (TA0001): несанкционированный доступ из-за публичного воздействия облачных сервисов (например, сервисы облачного хранения, сервисы баз данных), использование уязвимостей, направленное на общедоступные конечные точки (например, T1190: эксплойт уязвимостей внешних приложений).
• Эксфильтрация (TA0010): утечка данных путем маршрутизации трафика через подключения частной виртуальной сети, что снижает риск утечки данных на внешние серверы (например, T1041 — эксфильтрация по каналу C2).
• Боковое перемещение (TA0008): перемещение злоумышленников между службами в виртуальных сетях, несанкционированный доступ через облачные ресурсы (например, удаленные службы (T1021)).

NS-2.1 используйте приватный канал для подключения к службе

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

Реализуйте частное подключение для облачных служб, выполнив следующие действия.

• Развертывание частных конечных точек для поддерживаемых служб: Создайте частные конечные точки в виртуальной сети для ресурсов Azure, поддерживающих приватный канал (например, службу хранилища Azure, базу данных SQL Azure, Azure Key Vault), устанавливая частные IP-адреса (например, 10.0.2.4), доступные только из виртуальной сети.

• Настройка частных зон DNS: Создайте частные зоны DNS Azure для переопределения общедоступного разрешения DNS, чтобы полностью квалифицированные доменные имена (FQDN), такие как mystorageaccount1.blob.core.windows.net, разрешались в частные IP-адреса внутри вашей виртуальной сети (VNet), а не в общедоступные конечные точки. Это обеспечивает беспрепятственное соединение для приложений, использующих доступ на основе FQDN.

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

Заметка: Некоторые службы Azure также могут разрешить частную связь через функцию конечной точки службы , хотя Для безопасного и частного доступа к службам, размещенным на платформе Azure, рекомендуется использовать приватный канал Azure. Для развертываний, таких как веб-службы, размещенные на виртуальных машинах Azure, избегайте назначения общедоступных IP-адресов непосредственно виртуальным машинам, если это не оправдано; Вместо этого используйте шлюз приложений Azure или Azure Load Balancer в качестве внешнего интерфейса для доступа к службам.

NS-2.2. Развертывание службы в VNet

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

Развертывайте службы с интеграцией виртуальной сети, если это поддерживается.

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

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

NS-2.3 Настройка собственного брандмауэра службы

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

Настройте брандмауэры служб для ограничения доступа:

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

• Определите правила на основе IP-адресов или виртуальных сетей: Настройте правила брандмауэра, чтобы разрешить доступ только из определенных диапазонов общедоступных IP-адресов (например, корпоративных сетей office) или определенных подсетей виртуальной сети Azure, реализуя доступ с минимальными привилегиями путем запрета всех других источников.

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

NS-2.4 используйте периметр безопасности сети для изоляции ресурсов PaaS

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

Реализуйте периметр безопасности сети для защиты ресурсов PaaS:

• Создание и связывание ресурсов: Установите периметр безопасности сети и добавьте поддерживаемые ресурсы PaaS (хранилище Azure, база данных SQL, Key Vault, Центры событий, Cosmos DB) с помощью связей ресурсов, что позволяет взаимодействовать между связанными ресурсами внутри периметра.

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

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

Пример реализации

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

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

Подход к решению:

• Конечные точки Private Link для служб PaaS: развернуты частные конечные точки для базы данных Azure SQL (назначенный частный IP-адрес 10.0.2.4) и аккаунта хранения Azure (назначенный частный IP-адрес 10.0.2.5) в подсети выделенной частной конечной точки (10.0.2.0/24), устанавливая частное подключение, направляющее трафик через магистральную сеть Azure без выхода в Интернет.
• Частные DNS зоны для разрешения имен: Созданы частные DNS зоны Azure для переопределения общедоступного разрешения DNS, обеспечивая, чтобы полные доменные имена (например, mysqldb.database.windows.net, mystorageaccount.blob.core.windows.net) разрешались в частные IP-адреса внутри виртуальной сети, а не в общедоступные конечные точки, поддерживая непрерывное подключение для приложений с использованием доступа на основе FQDN.
• Интеграция виртуальной сети для служб приложений: Настройка интеграции виртуальной сети для службы приложений Azure, развертывание приложения в подсети приложения (10.0.1.0/24) для прямого взаимодействия с частными конечными точками без необходимости использовать общедоступные IP-адреса или маршрутизацию в Интернет.
• Собственные брандмауэры службы:Включенные брандмауэры уровня обслуживания в службе хранилища Azure, чтобы ограничить доступ к определенным подсетям виртуальной сети (подсеть приложения 10.0.1.0/24) и доверенным службам Майкрософт, полностью отключая доступ к общедоступной сети на уровне обслуживания для базы данных SQL Azure, чтобы обеспечить подключение только к частному.
• Правила NSG для глубокой защиты: Применяли правила NSG к подсети приложения, разрешая исходящий трафик только к подсети частной конечной точки (10.0.2.0/24) на необходимых портах (443 для хранилища, 1433 для SQL), реализуя управление доступом с минимальными привилегиями, которое дополняет защиту уровня обслуживания.

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

Уровень критическости

Должно быть.

Сопоставление элементов управления

• NIST SP 800-53 ред.5: SC-7(4), SC-7(5), AC-4(21)
• PCI-DSS версии 4: 1.3.1, 1.3.2, 1.4.2
• Элементы управления CIS версии 8.1: 12.4 , 12.7
• NIST CSF версии 2.0: PR. AC-05, PR. DS-05
• ISO 27001:2022: A.8.20, A.8.22
• SOC 2: CC6.1, CC6.6

NS-3: развертывание брандмауэра на границе корпоративной сети

Политика Azure: См. встроенные определения политик Azure: NS-3.

Принцип безопасности

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

Как минимум, политика брандмауэра должна включать:

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

Риск для смягчения

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

• Несанкционированный доступ через открытые протоколы: Общедоступные протоколы, такие как RDP (TCP 3389) или SMB (TCP 445), позволяют злоумышленникам получать несанкционированный доступ, компрометируя целостность системы с помощью эксплойтов, таких как атаки грубой силы или нацеленные на уязвимости CVE.
• Вредоносные программы и фишинг через вредоносные домены или IP-адреса: Вредоносные домены и IP-адреса упрощают доставку вредоносных программ или фишинговые кампании, угрожая конечным точкам и конфиденциальным данным с помощью команд и управления или атак социальной инженерии.
• Утечка данных через неограниченный исходящий доступ: Неконтролируемый исходящий трафик в неутвержденные места назначения позволяет злоумышленникам выводить конфиденциальные данные, рискуя нарушениями и нарушениями требований через скрытые каналы, такие как HTTPS POST.
• Боковое движение из-за плохой сегментации: Недостаточная сегментация сети позволяет злоумышленникам перемещаться внутри сети, эксплуатируя межсегментный трафик (например, SMB, Kerberos) для распространения из скомпрометированных систем.
• Уязвимости из ненадежных приложений и URL-адресов: Доступ к рискованным или ненадежным URL-адресам и приложениям увеличивает вероятность эксплойтов, повышение рисков инцидентов и несоответствие нормативным стандартам.

MITRE ATT&CK

• Первоначальный доступ (TA0001): несанкционированный доступ к протоколам высокого риска (например, RDP/TCP 3389, SSH/TCP 22) или вредоносным доменам (например, T1190 — эксплойт Public-Facing приложения).
• Команда и управление (TA0011): вредоносные программы, подключающиеся к вредоносным IP-адресам или доменам (например, T1071 — протокол уровня приложений).
• Эксфильтрация (TA0010): неавторизованные передачи данных через исходящий трафик в неутвержденные назначения (например, T1041 — эксфильтрация по каналу C2).
• Боковое перемещение (TA0008): препятствует внутреннему перемещению через нефильтрованный трафик между сегментами (например, SMB/TCP 445, Kerberos/TCP 88) (например, T1021 — удаленные службы).

NS-3.1 Подготовка к развертыванию брандмауэра Azure

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

Подготовка сетевой инфраструктуры для развертывания брандмауэра Azure:

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

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

• Настройка определяемых пользователем маршрутов (UDR): Создайте таблицы маршрутов , направляющие сетевой трафик из периферийных виртуальных сетей через брандмауэр Azure в центральной сети, включая маршруты для исходящего трафика в Интернет (0.0.0.0.0/0) и при необходимости межсайтовый трафик, если для связи между периферийными устройствами требуется проверка.

NS-3.2 Развертывание брандмауэра Azure с соответствующими политиками

Брандмауэр Azure предоставляет фильтрацию трафика уровня приложений с отслеживанием состояния с помощью централизованного управления политиками в сегментах корпоративной сети. Объединяя сетевые правила, правила приложения и аналитику угроз, брандмауэры проверяют потоки трафика на нескольких уровнях при фильтрации URL-адресов и проверке TLS обеспечивают детализированный контроль над обменом данными HTTP/HTTPS. Правильное проектирование политики балансирует требования к безопасности с операционными потребностями с помощью структурированных иерархий правил и фильтрации на основе категорий.

Развертывание и настройка брандмауэра Azure с помощью комплексных политик:

• Развертывание брандмауэра Azure в виртуальной сети концентратора: Разверните брандмауэр Azure (уровень "Стандартный" или "Премиум" на основе необходимых функций) в виртуальной сети концентратора, назначая общедоступные IP-адреса для трафика, привязанного к Интернету, и частные IP-адреса для внутренней маршрутизации из периферийных виртуальных сетей.

• Создайте политики брандмауэра с правилами фильтрации: Определите политики брандмауэра Azure , содержащие сетевые правила (фильтрация на основе IP/портов), правила приложений (фильтрация на основе FQDN) и правила аналитики угроз, упорядочение правил в коллекции на основе требований безопасности (например, разрешить критически важные для бизнеса службы, блокировать вредоносные IP-адреса, запрещать рискованные категории).

• Настройте фильтрацию URL-адресов для трафика HTTP/HTTPS: Реализуйте правила приложений на основе FQDN , чтобы разрешить или запретить определенные домены (например, разрешить *.microsoft.com, запретить *.torrent) и настроить фильтрацию на основе категорий на основе категорий , чтобы блокировать целые категории веб-сайтов (например, хакинг, социальные медиа), разрешая категории, связанные с работой.

• Включите проверку TLS для расширенной фильтрации: Для развертываний уровня "Премиум" включите проверку TLS путем отправки сертификатов в Azure Key Vault, позволяя брандмауэру расшифровывать, проверять и повторно шифровать трафик HTTPS для более глубокого фильтрации URL-адресов и обнаружения угроз за пределами проверки на основе SNI.

Пример реализации

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

Проблема: У организации были рабочие нагрузки, развернутые в отдельных периферийных виртуальных сетях с прямым доступом к Интернету, что приводит к созданию несогласованных политик безопасности и неспособности централизованно проверять трафик. Каждый представитель имел собственные правила NSG, что привело к смещениям политики и пробелам в безопасности. Не было видимости исходящих подключений к потенциально вредоносным доменам, нет возможности блокировать рискованные категории веб-сайтов (социальные сети, общий доступ к файлам) и не проверять содержимое трафика HTTPS. Межсайтовый трафик свободно передается без проверки, что обеспечивает потенциальное боковое движение после компрометации.

Подход к решению:

• Топология концентраторов и периферийных серверов с централизованным брандмауэром: Развернутый брандмауэр Azure Premium в центральной виртуальной сети (10.0.0.0/16) с выделенной сетью AzureFirewallSubnet (10.0.1.0/26, частный IP-адрес брандмауэра 10.0.1.4), устанавливающий единую точку принудительного применения для всех проверок сетевого трафика и управления политиками.
• Соединение VNet для подключения спицевой сети: Используется соединение виртуальной сети для подключения спицевой виртуальной сети приложения (10.1.0.0/16) и спицевой виртуальной сети базы данных (10.2.0.0/16) к центральной виртуальной сети, обеспечивая централизованную маршрутизацию трафика через брандмауэр.
• Определяемые пользователем маршруты для управления трафиком: Созданные таблицы маршрутов в каждой вспомогательной VNet перенаправляют весь интернет-трафик (0.0.0.0/0) и трафик между вспомогательными сетями на частный IP-адрес брандмауэра Azure (10.0.1.4), направляя весь исходящий трафик через центральную точку проверки.
• Политики брандмауэра с многоуровневой фильтрацией: Определены комплексные политики Azure Firewall, включая сетевые правила (разрешают DNS UDP/53 к Azure DNS, по умолчанию запрещают все другие протоколы), правила приложений (разрешают бизнес-критичные FQDN, такие как *.microsoft.com, запрещают домены для обмена файлами, такие как *.torrent), и правила на основе угроз (блокируют известные вредоносные IP-адреса из потоков угроз Microsoft Defender).
• Фильтрация URL-адресов и блокировка на основе категорий: Реализованы правила приложений на основе полного доменного имени для точного управления доменами и фильтрации на основе категорий , чтобы блокировать все категории веб-сайтов (хакинг, социальные медиа, азартные игры), позволяя работать связанные с работой категории (бизнес/экономика, технология или Интернет), применяя допустимые политики использования на пограничной сети.
• Проверка TLS для трафика HTTPS: Включена проверка TLS с сертификатами, хранящимися в Azure Key Vault, что позволяет брандмауэру расшифровывать, проверять и повторно шифровать трафик HTTPS для более глубокого фильтрации и обнаружения угроз за пределами проверки на основе SNI, исключая конфиденциальные банковские домены из расшифровки на соответствие требованиям.

Результат: Организация установила централизованную видимость и контроль над всем направленным в интернет и межзвёздочным трафиком, устраняя отклонение политики и слепые зоны безопасности. Проверка TLS позволила обнаруживать угрозы, скрытые в зашифрованном трафике HTTPS, а фильтрация на основе категорий значительно уменьшила подверженность рискованному веб-контенту. Архитектура концентратора и периферийных устройств обеспечивает масштабируемую, согласованную безопасность во всех рабочих нагрузках с унифицированным управлением политиками и комплексной защитой от угроз.

Уровень критическости

Должно быть.

Сопоставление элементов управления

• NIST SP 800-53 ред.5: SC-7, SC-7(5), AC-4, SI-4(4)
• PCI-DSS версии 4: 1.2.1, 1.3.1, 1.4.1, 1.4.2
• Элементы управления CIS версии 8.1: 9.2, 9.3, 13.1
• NIST CSF версии 2.0: PR. AC-05, PR. PT-04, DE. CM-01
• ISO 27001:2022: A.8.20, A.8.22
• SOC 2: CC6.1, CC6.6, CC7.2

NS-4: развертывание систем обнаружения и предотвращения вторжений (IDS/IPS)

Принцип безопасности

Используйте системы обнаружения и предотвращения вторжений (IDS/IPS) для проверки сетевого и полезного трафика, входящего и исходящего из вашей рабочей нагрузки или виртуальных сетей. Убедитесь, что идентификаторы и IPS всегда настроены для предоставления высококачественных оповещений в решении SIEM.

Примечание. Для более углубленного обнаружения угроз и предотвращения на уровне хоста используйте хостовые IDS/IPS или решение для обнаружения и реагирования на конечных точках (EDR) в сочетании с сетевыми IDS/IPS.

Риск для смягчения

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

• Эксплойты протокола: Уязвимости в таких протоколах, как RDP (TCP 3389) или HTTP/HTTPS (TCP 80/443), обеспечивают несанкционированный доступ или компрометацию системы через эксплойты, такие как атаки, ориентированные на CVE.
• Обмен данными между командами и управлением (C2): Вредоносные серверы устанавливают контроль над скомпрометированных устройств с помощью запросов DNS или обратных вызовов на основе IP-адресов, что способствует постоянной эксплуатации или распространению вредоносных программ.
• Эксплойты приложений: Атаки, такие как внедрение SQL, межсайтовое скриптирование (XSS) или переполнение буфера, нацелены на уязвимости приложений для кражи данных или выполнения произвольного кода.
• Боковое движение: Аномальный внутренний трафик, такой как исследование SMB (TCP 445) или злоупотребление билетами Kerberos (TCP 88), указывает на перемещение злоумышленника внутри сети.
• Утечка данных: Неавторизованные передачи данных происходят через зашифрованные каналы (например, HTTPS POSTs) или исходящие исходящие данные с высоким объемом, используя маскировку для уклонения от обнаружения.

MITRE ATT&CK

• Первоначальный доступ (TA0001): несанкционированные вторжения с помощью эксплойтов, нацеленных на уязвимости сети (например, T1190 — эксплойт приложения, доступного из сети).
• Выполнение (TA0002): исполнение вредоносного кода путем эксплуатации уязвимостей или загрузок C2 (например, T1059 — Командный и Сценарный Интерпретатор).
• Command and Control (TA0011): коммуникации с серверами C2 вредоносного ПО с использованием DNS-запросов или обратных вызовов на основе IP-адресов (например, T1071 — протокол прикладного уровня).
• Боковое перемещение (TA0008): аномальный внутренний трафик (например, перечисление SMB) свидетельствует о переходе (например, T1021 — удаленные услуги).
• Эксфильтрация (TA0010): неавторизованные передачи данных через зашифрованные или скрытые каналы (например, T1041 — эксфильтрация по каналу C2).

NS-4.1 Развертывание Azure Firewall Premium для системы обнаружения и предотвращения вторжений

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

Развертывание и настройка систем обнаружения и предотвращения вторжений (IDPS) через Azure Firewall Premium.

• Развертывание брандмауэра Azure Premium: Разверните брандмауэр Azure Premium с помощью политики Premium в виртуальной сети концентратора, чтобы включить возможности IDPS вместе с другими расширенными функциями, такими как проверка TLS и фильтрация URL-адресов.

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

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

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

Пример реализации

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

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

Solution:

• Брандмауэр Azure Premium с системой обнаружения и предотвращения вторжений (IDPS):Развернут брандмауэр Azure Premium в концентраторной виртуальной сети, включающий возможности IDPS наряду с проверкой TLS и фильтрацией URL-адресов, обеспечивая централизованное обнаружение угроз на основе сигнатур для всего трафика периферийных виртуальных сетей.

• Выбор правила сигнатуры: Выбраны высокосерьезные IDPS-сигнатуры из критически важных категорий, включая вредоносное ПО (Cobalt Strike, Metasploit, шифровальщики C2), эксплойты (PaperCut CVE-2023-27350, Log4Shell, ProxyShell), фишинг (сбор учетных данных) и паттерны управления и контроля.

• Режим оповещения и настройка: Настроенная система обнаружения и предотвращения вторжений (IDPS) в режиме оповещений для первоначального тестирования с целью отслеживания совпадений подписей без блокировки трафика, анализа оповещений для выявления ложных срабатываний от допустимых средств DevOps и вызовов API партнеров, а затем создание исключений для известных хороших сценариев, оставаясь при этом активными с подписями CVE с высоким приоритетом.

• Переход в режим предотвращения: Переключили систему обнаружения и предотвращения вторжений (IDPS) в режим оповещения и запрета для производственной среды после валидации, активно блокируя обнаруженные угрозы, включая попытки эксплуатации PaperCut, атаки Log4Shell и коммуникации C2.

• Интеграция Sentinel: настроили диагностические журналы в Log Analytics, создали правила аналитики Sentinel, сопоставляющие обнаружения IDPS с событиями аутентификации, и установили автоматическое создание инцидентов для оповещений высокой критичности.

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

Уровень критическости

Должно быть.

Сопоставление элементов управления

• NIST SP 800-53 ред.5: SI-4, SI-4(4), SI-4(5), SC-7(5)
• PCI-DSS версии 4: 11.4.1, 11.4.2, 1.4.1
• Элементы управления CIS версии 8.1: 13.2 , 13.6, 13.7
• NIST CSF версии 2.0: ДЕ. CM-01, DE. CM-04, DE. CM-07
• ISO 27001:2022: A.8.16, A.8.22, A.5.24
• SOC 2: CC6.1, CC7.2

NS-5: развертывание защиты от атак DDoS

Политика Azure: См. встроенные определения политик Azure: NS-5.

Принцип безопасности

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

Риск для смягчения

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

• Объемные атаки (наводнение сети): Злоумышленники заполняют сетевые интерфейсы большим объемом трафика (например, миллионы пакетов в секунду) для исчерпания пропускной способности, емкости обработки маршрутизатора или ресурсов подсистемы балансировки нагрузки, что приводит к недоступности службы. Примерами являются наводнения UDP, наводнения ICMP или амплифицированные атаки на отражение DNS, используя такие протоколы, как NTP или SSDP.
• Атаки на протоколы (исчерпание состояния): Злоумышленники используют уязвимости протоколов уровня 3/4 для истощения ресурсов, отслеживающих состояние, таких как таблицы подключений TCP или состояния сеансов брандмауэра. Распространенные методы включают атаки TCP SYN, которые перегружают серверы полуоткрытыми соединениями, или атаки ACK, нацеленные на устройства с отслеживанием состояния.
• Атаки уровня ресурсов (перегрузка приложения): Атаки, ограниченные уровнем 7, такие как атаки типа HTTP GET/POST flood, нацеленные на ресурсы приложений (например, ЦПУ, память или подключения к базе данных), чтобы перегружать веб-серверы или API. Эти атаки направлены на исчерпание вычислительных ресурсов, что приводит к всплескам задержки или сбоям.
• Атаки усиления: Злоумышленники используют неправильно настроенные серверы (например, DNS, NTP или Plex Media на UDP 32414), чтобы усилить трафик, отправляя небольшие запросы, которые создают большие ответы, направленные на цель, и это подавляет емкость сети. Примеры включают усилительные атаки DNS или отражательные атаки SSDP.

MITRE ATT&CK

• Влияние (TA0040): нарушает доступность служб с помощью объемных атак (например, UDP/ICMP) или перегрузок ресурсов (например, атак HTTP), чтобы запретить доступ (например, T1498 — отказ в обслуживании сети).
• Разработка ресурсов (TA0042): использует скомпрометированные системы для усиленных атак (например, отражения DNS/NTP) для увеличения влияния атак (например, T1584 - компрометация инфраструктуры).

NS-5.1 Реализуйте защиту от атак DDOS на соответствующем сетевом уровне

Разверните защиту от атак DDoS как на сетевом уровне, так и на уровне приложений, чтобы защититься от объемных и специфичных для приложений атак. Azure предоставляет несколько уровней защиты: защита сети от атак DDoS для комплексного покрытия виртуальных сетей с поддержкой быстрого реагирования, защита IP-адресов DDoS для экономичной защиты отдельных IP-адресов и защиты уровня приложений через WAF. Настройте мониторинг и оповещения для проверки эффективности защиты и обеспечения устойчивости приложений во время атак:

• Разверните защиту от атак DDoS сетевого уровня: Выберите между DDoS Network Protection для развертываний рабочих нагрузок, требующих комплексного покрытия виртуальных сетей и поддержки быстрого реагирования для исследования атак и анализа после атаки, или защиты IP-адресов DDoS для экономичной защиты ограниченного количества IP-адресов без поддержки быстрого реагирования.

• Развертывание защиты от атак DDoS уровня приложений: Включите защиту от атак DDoS в брандмауэре веб-приложений Azure (WAF), шлюзе приложений или Azure Front Door для защиты от атак уровня приложений (уровень 7).

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

Замечание

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

Пример реализации

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

Вызов: Организация управляла глобальной платформой электронной коммерции с общедоступными веб-приложениями, API-интерфейсами и инфраструктурой доставки содержимого, предоставляемыми в Интернете. Во время пиковых событий платформа испытала несколько атак DDoS, включая UDP-флуды, TCP SYN-флуды, исчерпывающие таблицы подключений балансировщика нагрузки, HTTP-флуды, нацеленные на интерфейсы API для оформления заказа, и атаки типа DNS amplification. Без выделенной защиты от атак DDoS эти атаки вызвали сбои служб, что привело к потере доходов и неудовлетворенности клиентов.

Solution:

• Защита сети от атак DDoS: Включена защита сети от атак DDoS Azure в рабочих виртуальных сетях, где размещаются клиентские приложения, обеспечивая комплексную защиту на уровне виртуальной сети с адаптивной настройкой, автоматическое обнаружение атак на уровнях 3 и 4 и устранение рисков в режиме реального времени.

• Защита уровня приложений: Развернут шлюз приложений Azure с WAF для региональных приложений и Azure Front Door с WAF для глобальной пограничной доставки, что обеспечивает защиту от атак DDoS уровня 7 с ограничением скорости, обнаружением наводнений HTTP и правилами защиты ботов.

• Конфигурация политики защиты: Создан план защиты от атак DDoS, связывающий все рабочие виртуальные сети, настроена система обучения адаптивной настройки по базовым шаблонам трафика, включён постоянный мониторинг трафика и определены политики защиты от флуда UDP, флуда TCP SYN, флуда ICMP и протокольных атак.

• Мониторинг и оповещения: Настроены журналы диагностики DDoS, отправляющие данные телеметрии атак в рабочую область Log Analytics; созданы оповещения Azure Monitor, которые немедленно уведомляют при обнаружении атак; создана книга Sentinel, коррелирующая атаки DDoS с метриками производительности приложений; настроен мониторинг состояния приложений в Application Insights для контроля работоспособности во время мероприятий по смягчению атак.

• Быстрое реагирование: Активирован быстрый ответ DDoS , предоставляющий прямой доступ к экспертам по защите от атак DDoS во время активных атак для анализа атак в режиме реального времени, разработки пользовательской стратегии устранения рисков и судебной экспертизы после атак.

Результат: Атаки DDoS во время пиковых покупок были успешно устранены с нулевыми сбоями в обслуживании. Объемные наводнения, наводнения SYN и наводнения HTTP были автоматически заблокированы, сохраняя доступность платформы. Rapid Response предоставил экспертный анализ сложных атак. Критически важные периоды покупок поддерживали высокий уровень доступности без задержки транзакций клиента во время устранения неполадок.

Уровень критическости

Должно быть.

Сопоставление элементов управления

• NIST SP 800-53 ред.5: SC-5, SC-5(1), SC-5(2), SI-4(4)
• PCI-DSS версии 4: 6.4.2, 11.4.7
• Элементы управления CIS версии 8.1: 13.3
• NIST CSF версии 2.0: PR. PT-05, DE. CM-01
• ISO 27001:2022: A.8.13, A.8.24
• SOC 2: CC6.1, CC7.2

NS-6: развертывание брандмауэра веб-приложения

Политика Azure: См. встроенные определения политик Azure: NS-6.

Принцип безопасности

Разверните брандмауэр веб-приложения (WAF) и настройте правила для защиты веб-приложений и API от атак, относящихся к приложениям, путем проверки, обнаружения и фильтрации вредоносного трафика HTTP/HTTPS.

Риск для смягчения

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

• Атаки на внедрение (например, внедрение SQL, внедрение команд): Злоумышленники используют уязвимости проверки входных данных для внедрения вредоносного кода в запросы или команды веб-приложения, что обеспечивает несанкционированный доступ к базе данных, кражу данных или компрометацию системы. Внедрение SQL (SQLi) управляет запросами к базе данных (например, добавление ' OR '1'='1' в форму входа), а внедрение команд выполняет произвольные команды ОС (например, ; rm -rf / через поле формы).
• Нарушения протокола HTTP и неправильные запросы: Злоумышленники отправляют неправильные HTTP-запросы (например, недопустимые заголовки, перегруженные полезные данные или не стандартные методы, такие как TRACE), чтобы использовать уязвимости в веб-серверах или приложениях, что может привести к сбоям или несанкционированным доступом. Эти атаки нацелены на неправильно настроенные серверы или неподключенные платформы.
• Атаки на основе ботов (например, заполнение учетных данных, скребение): автоматизированные боты запускают атаки на заполнение учетных данных (например, конечные точки входа с украденными учетными данными) или слом конфиденциального содержимого (например, ценовые данные), перегрузки серверов или компрометации учетных записей пользователей. Эти атаки используют слабую проверку подлинности или незащищенные API.
• Эксплойты для конкретных приложений (например, включение удаленных файлов, включение локальных файлов): Злоумышленники используют уязвимости для включения вредоносных файлов (например, "http://evil.com/shell.php") или доступа к локальным файлам сервера (например, .. /.. /etc/passwd) с помощью параметров URL-адреса или входных данных формы, включая выполнение кода или воздействие данных.

MITRE ATT&CK

• Первоначальный доступ (TA0001): Эксплуатация SQL-инъекций, XSS или удаленного включения файлов для получения доступа (например, T1190 — эксплойт общественно доступного приложения).
• Выполнение (TA0002): Выполняет вредоносный код с помощью внедрения команд, RFI или XSS (например, T1059 — интерпретатор команд и скриптов).
• Доступ к учетным данным (TA0006): Кража учетных данных с помощью XSS или подбора учетных данных (например, T1539 — кража файлов cookie веб-сеанса, T1110 — атака грубой силы).
• Коллекция (TA0009): Собирает данные с помощью инъекции SQL или сбора информации (например, T1213 — данные из информационных хранилищ).

NS-6.1 Настройка Azure WAF с соответствующими правилами

Включите возможности брандмауэра веб-приложений (WAF) в шлюзе приложений Azure, Azure Front Door или сети доставки содержимого Azure (CDN) для защиты приложений и API от веб-атак. Выберите соответствующую службу на основе требований приложения, настройте политики WAF со встроенными и настраиваемыми правилами, задайте режим политики на основе состояния безопасности и свяжите политику с конечной точкой службы:

• Выберите соответствующую службу WAF: Выберите шлюз приложений Azure для приложений, размещенных в виртуальной сети, Azure Front Door для глобальной пограничной доставки или Azure CDN для рабочих нагрузок с большим объемом содержимого на основе требований и архитектуры приложений.

• Настройте политики WAF со встроенными и настраиваемыми правилами: Начните с распространенных встроенных наборов правил, таких как набор правил OWASP (CRS 3.2) и правила защиты ботов (Microsoft Bot Manager). Добавьте настраиваемые правила (например, ограничение скорости для >100 запросов/мин) и исключения, чтобы уменьшить ложные срабатывания на основе ландшафта угроз и профиля безопасности приложений.

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

• Свяжите политику WAF с конечной точкой службы: Свяжите политику WAF с конечной точкой Шлюза приложений, Front Door или CDN, чтобы убедиться, что весь трафик HTTP/HTTPS направляется через WAF для проверки.

Пример реализации

Организация нуждалась в защите клиентских веб-приложений и API от SQL-инъекций, XSS-атак и атак с использованием ботами учетных данных, сохраняя производительность для легитимных пользователей.

Вызов: В организации были веб-приложения, развернутые глобально без защиты от уязвимостей OWASP Top 10, что привело к нескольким попыткам SQL-инъекций, атакам ботов, которые перегружают точки входа, и отсутствует видимость вредоносных шаблонов трафика. Приложения не имели контроля с ограничением скорости запросов, что позволяло злоупотреблять API и проводить атаки методом перебора учётных данных, а также не существовало механизма для различения легитимных пользователей и вредоносных ботов.

Подход к решению:

• Выбор службы WAF: Развернут шлюз приложений Azure с WAF для приложений, размещенных в виртуальной сети, и Azure Front Door с WAF для глобально распределенных приложений, требующих защиты границ и доступа с низкой задержкой.
• Встроенные наборы правил защиты: Включен набор правил OWASP Core (CRS) 3.2 для защиты от внедрения SQL, межсайтовых сценариев (XSS), удаленного включения файлов и других распространенных веб-уязвимостей, а также активированы правила Microsoft Bot Manager для выявления и блокировки вредоносных ботов, позволяя законным обходчикам поисковых систем и службам мониторинга.
• Пользовательские правила для определенных угроз: Реализованы правила ограничения скорости, блокирующие клиенты, превышающие 100 запросов в минуту, чтобы предотвратить злоупотребление API и вложения учетных данных, правила геофильтрации блокируют трафик из регионов с высоким риском, где службы недоступны, а правила на основе репутации IP-адресов блокируют запросы от известных диапазонов вредоносных IP-адресов, определенных через каналы аналитики угроз.
• Управление исключениями: Созданы целевые исключения для допустимых бизнес-сценариев, таких как /checkout конечные точки со сложными входными данными формы, которые приводят к ложным срабатываниям в правилах OWASP, /upload конечные точки, обрабатывающие большие отправки файлов, и /api конечные точки с необычными, но допустимыми шаблонами заголовков из мобильных приложений.
• Переход от обнаружения к предотвращению: WAF запускался в режиме обнаружения в течение двух недель для выявления ложных срабатываний, уточнения правил и создания исключений на основе законных шаблонов трафика, а затем была произведена настройка на режим предотвращения для рабочих приложений, чтобы активно блокировать угрозы и при этом поддерживать непрерывность бизнес-процессов.

Результат: Организация исключила попытки внедрения SQL и эксплуатации XSS, значительно сократила атаки на основе ботов с помощью правил диспетчера ботов и установила исчерпывающую видимость угроз веб-приложения. Средства управления ограничением скорости предотвращают злоупотребление API и добавление учетных данных, а поэтапное переход от обнаружения к режиму предотвращения гарантирует, что законные пользователи не столкнулись с нарушением работы службы.

Уровень критическости

Должно быть.

Сопоставление элементов управления

• NIST SP 800-53 ред.5: SC-7, SC-7(5), SI-10, SI-10(1), SI-11
• PCI-DSS версии 4: 6.4.1, 6.4.2, 11.4.7
• Элементы управления CIS версии 8.1: 13.2, 13.9
• NIST CSF версии 2.0: PR. AC-05, PR. PT-05, DE. CM-04
• ISO 27001:2022: A.8.20, A.8.22, A.8.25
• SOC 2: CC6.1, CC6.6, CC7.2

NS-7. Централизованное и эффективное управление безопасностью сети

Принцип безопасности

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

Риск для смягчения

Отсутствие централизованного контроля приводит к пропущенным или устаревшим параметрам безопасности, что повышает риск эксплуатации.

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

MITRE ATT&CK

• Первоначальный доступ (ТА0001): Эксплуатация неправильных настроек или устаревших параметров безопасности для получения несанкционированного доступа (например, T1190 — Exploit Public-Facing Application, T1133 — Службы внешнего удаленного доступа).
• Уклонение от защиты (TA0005): Использование фрагментированных наборов правил и отсутствия централизованного мониторинга с целью избежать обнаружения (например, T1562 — Подрыв обороны).
• Боковое движение (TA0008): Перемещение через сеть путем использования пробелов в политике или устаревших сегментации (например, T1021 — удаленные службы).
• Команда и управление (TA0011): Использование немонитоированных или неправильно настроенных сетевых путей для установления и обслуживания каналов C2 (например, T1071 — протокол уровня приложений).

NS-7.1 Централизованное и эффективное управление безопасностью сети

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

• Реализуйте централизованное применение политик: Используйте Диспетчер виртуальных сетей Azure (AVNM) для определения правил администратора безопасности, которые применяются последовательно между подписками и регионами. Сохранить группы безопасности сети для микросегментации на уровне рабочей нагрузки. Примените политики с помощью сетевых групп (например, по окружению: prod, non-prod).

• Стандартизация управления брандмауэром и маршрутизацией: Управление правилами брандмауэра Azure с помощью диспетчера брандмауэра с помощью объектов политики брандмауэра. Стандартизируйте группы IP-адресов и теги служб вместо необработанных IP-адресов. Используйте Azure Firewall Premium, где требуется проверка TLS, IDPS и фильтрация URL-адресов. Предпочитайте безопасные концентраторы виртуальной глобальной сети или общую топологию концентраторов и периферийных узлов, чтобы обеспечить согласованное назначение маршрутизации.

• Включите комплексный мониторинг и аналитику: Используйте журналы потоков виртуальной сети версии 2 (для замены журналов потоков NSG). Включите журналы диагностики брандмауэра Azure и интегрируйте их с Аналитикой трафика, Log Analytics и Microsoft Sentinel. Используйте аналитику политики брандмауэра и количество срабатываний правил для устранения неиспользуемых или повторяющихся правил.

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

Пример реализации

Вариант использования: Платформа оплаты с несколькими регионами объединяет сетевую безопасность в масштабе

Контекст: Обработчик платежей среднего размера, работающий в восточной части США и Западной Европы с 4 подписками (Prod, Non-Prod, Shared Services, SecOps) в рамках одного клиента, нуждается в сегментации PCI-DSS, меньше инцидентов от смещения правил и централизованного мониторинга.

Централизованное применение политик с помощью Azure Virtual Network Manager:

• Проектирование: Создайте AVNM на уровне группы управления. Определите две сетевые группы: ng-prod и ng-nonprod с динамическим членством по тегу subscriptionId. Создайте правила администратора безопасности (SAR), чтобы принудительно применять организационные защитные механизмы, которые оцениваются до NSG: Deny-Inbound-Internet-to-Spokes (блокирует непрошенный входящий трафик из Интернета во все вторичные подсети), Allow-Hub-Infra (разрешает службы хаба — Брандмауэр/Бастион — во вторичные), Allow-Platform-DNS (разрешает DNS от резольверов хаба в вторичные подсети).
• Границы команды приложений: Рабочие нагрузки сохраняют сетевые группы безопасности (NSG) для микросегментации (например, веб-интерфейс к API :443, API к базе данных :1433) в пределах каждой периферии. Изменениями NSG управляют команды приложений; SAR находятся в ведении группы безопасности платформы.
• Результат: Ограничения согласованы в обоих регионах; команды разработчиков приложений не могут непреднамеренно создать прямой доступ к Интернету, даже если сетевые группы безопасности (NSG) неправильно настроены.

Управление брандмауэром и маршрутизацией с помощью диспетчера брандмауэра и виртуальной глобальной сети:

• Проектировать: Развертывание безопасных центров виртуальной глобальной сети в каждом регионе (восточная часть США, Западная Европа). Подключите спицы к ближайшему концентратору и настройте маршрутизацию, чтобы все исходящие подключения к Интернету проверялись. Используйте менеджер межсетевых экранов с глобальной политикой (уровень "Премиум") и двумя дочерними политиками (Prod/Non-Prod) для переопределения параметров среды.
• Структура политики: Базовая (глобальная) политика включает Threat Intelligence с настройками для оповещения и запрета, включенную проверку TLS для исходящего HTTPS-трафика, IDPS в сбалансированном режиме, а также правила для исходящего трафика с использованием тегов служб (Storage, KeyVault, AzureMonitor) и IP-групп для конечных точек партнеров. У дочерней политики prod более строгий фильтр URL-адресов (блокировка без категории) и список разрешений для шлюзов платежей через IP-группы. У дочерней политики, отличной от Prod, более широкий доступ к инструментам разработки с помощью тегов служб (AzureDevOps, AzureContainerRegistry).
• Результат: Единая панель для управления правилами, изменения которой распространяются на оба концентратора. Маршрутизация согласована, и все исходящие данные проверяются с помощью расшифровки TLS, где разрешено.

Мониторинг и аналитика с помощью журналов потоков версии 2 и Sentinel:

• Настройка телеметрии: Включите журналы потоков виртуальной сети версии 2 во всех виртуальных сетях и отправьте их в центральную рабочую область Log Analytics в подписке SecOps. Настройте журналы диагностики брандмауэра Azure (приложения, сети, DNS, ThreatIntel, IDPS) в той же рабочей области. Включите аналитику трафика для рабочей области.
• Цикл оптимизации: Включите аналитику политики межсетевого экрана и ежемесячно просматривайте количество срабатываний правил. Создайте книгу Sentinel, которая сопоставляет журналы потоков (северо-юг и восток-запад), разрешение и запрет попаданий брандмауэра и сигнатуры IDPS, активируемые. Автоматизируйте запрос на изменение, если правило не имеет попаданий в течение 45 дней (кандидат на удаление) или если правило блокировки активируется рабочей подсетью (возможная ошибка маршрутизации).
• Результат: После двух циклов проверки 18% правил брандмауэра и 22 устаревших правил NSG удаляются, уменьшая задержку оценки правил и риск изменения.

Согласованность ресурсов и управление с помощью CAF и Defender для облака:

• Стандарты: Применение именования CAF (например, vnet-prd-eus-01, nsg-prd-eus-web-01, azfw-policy-global-01) и обязательных тегов: env, owner, dataClass, costCenter.
• Принуждение: Используйте инициативы политики Azure, чтобы требовать NSG в каждой подсети, требовать параметры диагностики в виртуальных сетях и брандмауэре в центральной рабочей области LA и запретить создание без обязательных тегов. Включение Защитника для облака — адаптивная защита сети на всех периферийных узлах с еженедельными элементами действий, рассмотренными в CAB SecOps.
• Результат: Смещение платформы быстро обнаруживается; избыточные правила ужесточаются с помощью рекомендаций Defender на основе данных.

Последовательности развертывания и критерии принятия:

• Подстановка безопасных концентраторов vWAN, присоединение периферийных устройств, включение намерения маршрутизации (только пилотные периферийные устройства). Критерии принятия: пилотные периферийные устройства исходят через брандмауэр; общедоступные IP-адреса недоступны напрямую.
• Разверните SAR AVNM в ng-nonprod, проверьте отсутствие разрывов, а затем в ng-prod. Критерии принятия: искусственные пробы подтверждают, что службы хаба (DNS/Бастион) всё ещё достигают спиц; Входящий Интернет всё ещё блокирован.
• Включите журналы потоков виртуальных сетей версии 2 и все диагностические средства брандмауэра; интегрируйте книгу Sentinel. Критерии принятия: панели мониторинга показывают сетевые потоки, отказы, срабатывания IDPS по регионам.
• Применяйте инициативы политики; исправьте несоответствующие элементы; включите адаптивное усиление защиты. Критерии принятия: соответствие достигает 95%, создан список задач для усиления NSG/брандмауэра.
• Первая проверка аналитики политик; удалите неиспользуемые правила с помощью окна изменений. Критерии принятия: число правил сокращено на 15% без воздействия на клиента.

Примеры операционных модулей Runbook:

• Диспетчер виртуальных сетей Azure SAR: Запретить входящий интернет на спицы (приоритет 100), разрешить сети хаба к спицам (приоритет 200: src 10.0.0.0/16 диапазоны хаба)
• Структура политики брандмауэра: azfw-policy-global-01 (Premium) с коллекциями правил Allow-Azure-Platform-ST (теги службы) и Allow-Partners-IPs (IP-группы: ipg-payment-gws), а также дочерние политики azfw-policy-prd-01 и azfw-policy-npd-01
• Диагностика: Назначение: law-secops-01, категории: AZFWApplicationRule, AZFWNetworkRule, AZFWIDPS, AZFWThreatIntel, AZFWDnsProxy, FlowLogV2

Уровень критическости

Должно быть.

Сопоставление элементов управления

• NIST SP 800-53 ред.5: CM-2, CM-3, CM-6, CA-7, SI-4
• PCI-DSS версии 4: 1.4.5, 11.5.1, 12.4.1
• Элементы управления CIS версии 8.1: 4.1 , 4.2, 12.4, 13.6
• NIST CSF версии 2.0: PR. IP-01, DE. CM-01, DE. CM-07
• ISO 27001:2022: A.8.9, A.8.32, A.5.37
• SOC 2: CC6.6, CC7.2, CC8.1

NS-8. Обнаружение и отключение небезопасных служб и протоколов

Политика Azure: См. встроенные определения политик Azure: NS-8.

Принцип безопасности

Обнаружение и отключение небезопасных служб и протоколов на уровне ОС, приложения или пакета программного обеспечения. Развертывание компенсирующих элементов управления, если отключение небезопасных служб и протоколов невозможно.

Риск для смягчения

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

• Эксплуатация криптографических уязвимостей: SSL/TLSv1 и слабые шифры (например, RC4, DES) уязвимы для атак MITM (например, POODLE, BEAST), что позволяет злоумышленникам расшифровывать конфиденциальные данные, такие как маркеры сеансов, с помощью атак типа padding oracle или атак выбранного шифротекста.
• Несанкционированный доступ с помощью эксплойтов протокола: Уязвимости SSHv1 и SMBv1 (например, CVE-2001-1473, CVE-2017-0144/EternalBlue) позволяют удаленному выполнению кода или неаутентифицированному доступу, обеспечивая начальные точки доступа.
• Кража учетных данных: LM/NTLMv1 и wDigest хранят слабые хэши или пароли в открытом виде, уязвимы для атаки pass-the-hash или считывания памяти (например, извлечение данных LSASS с помощью Mimikatz).
• Боковое движение: Незашифрованные сеансы и эксплойты SMBv1 (например, EternalBlue) позволяют распространять вредоносные программы или перехватывать учетные данные в сетях.

MITRE ATT&CK

• Первоначальный доступ (TA0001): Эксплуатация небезопасных протоколов, таких как SSL/TLSv1 или SSHv1, которые уязвимы для атак с понижением уровня протокола или известных эксплойтов, блокируя несанкционированный доступ (например, T1190 — эксплойт публично доступного приложения).
• Доступ к учетным данным (TA0006): Кража учетных данных путем использования LM/NTLMv1 и wDigest, которые хранят учетные данные в обратимых форматах или слабых хэшах, предотвращение атак pass-the-hash или сбор информации из памяти (например, T1003 — дамп учетных данных ОС).
• Боковое передвижение (TA0008): Ограничивает возможность злоумышленника использовать SMBv1, которая уязвима для эксплойтов, таких как EternalBlue, предотвращая его распространение по сетям (например, T1021 — удаленные службы).

NS-8.1. Обнаружение и отключение небезопасных служб и протоколов

Используйте встроенную книгу протокола Microsoft Sentinel для обнаружения и устранения небезопасных служб и протоколов в среде Azure. Эта книга определяет использование протоколов и служб, которые не соответствуют соответствующим стандартам безопасности, таким как SSL/TLSv1, SSHv1, SMBv1, LM/NTLMv1, wDigest, слабые шифры в Kerberos и неподписанные привязки LDAP. После идентификации отключите эти небезопасные протоколы и службы. Если отключение невозможно, реализуйте компенсирующие элементы управления, чтобы уменьшить область атаки.

Обнаружение небезопасных протоколов: Используйте книгу небезопасного протокола Microsoft Sentinel для выявления использования шифров SSL/TLSv1, SSHv1, SMBv1, LM/NTLMv1, wDigest, слабых шифров Kerberos и неподписанных привязок LDAP в вашей среде.

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

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

Пример реализации

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

Вызов: Организация управляла гибридной инфраструктурой с устаревшими приложениями, требующими подключения к размещенным в Azure ресурсам. Оценка безопасности показала широкое использование небезопасных протоколов, включая SSL/TLSv1.0 на веб-серверах, обслуживающих порталы пациентов, SMBv1 включено на файловых серверах для устаревшего программного обеспечения для медицинской визуализации, проверки подлинности LM/NTLMv1 на контроллерах домена и серверах приложений, wDigest проверка подлинности, в котором хранятся учетные данные в обратимом формате, неназначенные привязки LDAP к контроллерам Active Directory и слабому шифрованию Kerberos на учетных записях служб. Организация не пользовалась сведениями об использовании протокола и столкнулась с потенциальными нарушениями соответствия HIPAA.

Solution:

• Развертывание рабочей книги небезопасного протокола Sentinel: Развернут Microsoft Sentinel и установлена рабочая книга небезопасного протокола из концентратора контента. Подключенные источники данных включают журналы событий безопасности Windows, журналы Azure Monitor, журналы Active Directory и журналы сетевого потока, что позволяет установить всеобъемлющую базовую линию использования небезопасных протоколов в гибридной среде.

• Обнаружение протокола: Использовалась рабочая книга "Несекурный протокол" для выявления использования SSL/TLSv1.0 на веб-серверах, трафика SMBv1 от устаревших рабочих станций медицинской визуализации, шаблонов аутентификации LM/NTLMv1, использования wDigest на серверах Windows, неподписанных привязок LDAP из устаревших приложений и слабого шифрования RC4 для Kerberos на учетных записях служб.

• Систематическое отключение протоколов: Разработан поэтапный план исправления, утвержденный советом по изменению, отключен TLSv1.0/1.1 на веб-серверах после подтверждения, что пользователи портала пациентов используют современные браузеры, поддерживающие TLS 1.2+; отключен SMBv1 после координации обновлений программного обеспечения с поставщиком медицинских изображений; переход контроллеров домена с аутентификации NTLMv1 на NTLMv2; отключен wDigest через групповую политику; принудительное включение подписывания LDAP на контроллерах домена; и обновление шифрования учетных записей служб Kerberos до AES256.

• Компенсирующие элементы управления для исключений: Реализованы сетевые компенсирующие элементы управления для систем, требующих временной небезопасной поддержки протокола, включая изолированную ВЛС для устаревших медицинских рабочих станций, требующих SMBv1, правила NSG, ограничивающие трафик SMBv1 исключительно для изолированной ВЛС, брандмауэр Azure запрещает исходящий SMBv1 из производственных подсетей, выделенный узел перехода для устаревших HR-приложений и расширенный мониторинг с помощью Defender для конечной точки, отмечая использование протоколов за пределами одобренных подсетей исключений.

• Непрерывный мониторинг: Установлено поддержание постоянной чистоты протоколов с помощью правил аналитики Microsoft Sentinel, запускающих оповещения о новых небезопасных подключениях протоколов за пределами утвержденных исключений, отказ политики Azure в развертывании без минимального требования TLS 1.2, а также еженедельные проверки для отслеживания хода исправления небезопасных протоколов.

Результат: Слабые подключения TLS были устранены с порталов пациентов. SMBv1 был отключен после обновления медицинской визуализации, устранения уязвимости EternalBlue и достижения соответствия HIPAA. NTLMv1 переключился на NTLMv2, предотвращая сквозные хэш-атаки. WDigest отключил кражу учетных данных. Подписывание LDAP блокирует неподписанные запросы. Kerberos обновлен до AES256, что снижает риск атак типа "Kerberoasting". Компенсирующие меры контроля содержали устаревшие системы без бокового перемещения. Достигнуто полное соответствие HIPAA.

Уровень критическости

Должно быть.

Сопоставление элементов управления

• NIST SP 800-53 ред.5: SC-8, SC-8(1), SC-13, IA-5(1)
• PCI-DSS версии 4: 2.2.4, 4.2.1, 6.2.4
• Элементы управления CIS версии 8.1: 4.8, 9.3, 13.4
• NIST CSF версии 2.0: PR. DS-02, PR. IP-01, DE. CM-04
• ISO 27001:2022: A.8.24, A.8.26, A.5.14
• SOC 2: CC6.1, CC6.7, CC7.1

NS-9: подключение к локальной или облачной сети в частном режиме

Принцип безопасности

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

Риск для смягчения

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

• Перехват данных: Когда данные перемещаются по общедоступным сетям, таким как Интернет, он проходит через несколько маршрутизаторов, коммутаторов и поставщиков услуг, любые из которых могут быть скомпрометированы или отслеживаются вредоносными субъектами. Злоумышленники могут развертывать средства для перехвата пакетов (например, Wireshark) для захвата пакетов данных. Если данные незашифрованы или слабо зашифрованы, конфиденциальная информация , например учетные данные для входа, финансовые сведения или частные бизнес-данные, могут быть предоставлены.
• Атаки "Человек в середине" (MitM): В атаке MitM злоумышленник тайно перехватывает и потенциально изменяет связь между двумя сторонами, которые считают, что они напрямую взаимодействуют друг с другом. Это представляет серьезную угрозу для конфиденциальных операций, таких как финансовые транзакции или процессы проверки подлинности.
• Несанкционированный доступ: Общедоступные или недостаточно защищенные сети повышают вероятность несанкционированного доступа или вмешательства пользователей к частным системам или ресурсам. Злоумышленники могут использовать слабые сети для достижения внутренней инфраструктуры, которая должна оставаться недоступной извне.

MITRE ATT&CK

• Первоначальный доступ (TA0001): Эксплуатация незашифрованных или слабо зашифрованных протоколов (например, HTTP или устаревших версий TLS), уязвимых для перехвата пакетов или атак типа MitM, что позволяет неавторизованный доступ в системы (например, уязвимость T1190 – Public-Facing Application).
• Доступ к учетным данным (TA0006): Кража учетных данных через перехваченный сетевой трафик, использование протоколов открытого текста (например, Telnet или FTP) или слабое шифрование, уязвимое для расшифровки, что облегчает несанкционированный доступ (например, T1040 — анализ сети).
• Боковое движение (TA0008): Распространение в сетях путем эксплуатации неправильно настроенных или незакрытых служб (например, непатчированные RDP или SMB), что позволяет злоумышленникам перемещаться, используя украденные учетные данные или уязвимости (например, T1021 — удаленные службы).

NS-9.1 Используйте виртуальную частную сеть Azure (VPN) для упрощенного подключения типа "сеть — сеть" или "точка — сеть"

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

• Развертывание VPN типа "сеть — сеть": Используйте VPN типа "сеть — сеть" для безопасного подключения локальной сети к виртуальной сети Azure, обеспечивая простое взаимодействие между локальными ресурсами и рабочими нагрузками Azure.

• Развертывание VPN типа "точка — сеть": Используйте VPN типа "точка — сеть", чтобы включить отдельные устройства конечных пользователей (ноутбуки, рабочие станции) для безопасного подключения к виртуальной сети Azure из удаленных расположений.

NS-9.2 используйте Azure ExpressRoute (или виртуальную глобальную сеть) для высокопроизводительных подключений корпоративного уровня.

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

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

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

NS-9.3 используйте пиринг виртуальных сетей или подсетей для присоединения к виртуальным сетям

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

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

Пример реализации

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

Вызов: Организация управляла несколькими локальными центрами обработки данных с филиалами глобально, требуя подключения к размещенным в Azure приложениям, обрабатывающим финансовые транзакции и данные клиентов. Начальная архитектура использует VPN типа "сеть — сеть" через Интернет, испытывая непредсказуемую задержку, ограничения пропускной способности во время пиковых торговых часов, проблемы безопасности в отношении финансовых данных, пересекающих общедоступный Интернет, несмотря на шифрование и требования к соответствию требованиям к частному подключению для PCI-DSS и GDPR. Удаленные сотрудники, подключающиеся через VPN типа "точка-сайт", столкнулись с нестабильной производительностью и проблемами с проверкой подлинности. Приложения в разных регионах Azure требуют низкой задержки обмена данными между регионами без маршрутизации через локальные центры.

Solution:

• ExpressRoute для подключения к основному центру обработки данных: Развернутые каналы Azure ExpressRoute в основных центрах обработки данных через совместное размещение с поставщиками подключений ExpressRoute, устанавливая подключение частного уровня 3 к магистральной сети Azure с постоянной низкой задержкой, настроив ExpressRoute с пирингом Microsoft для служб Azure PaaS и частного пиринга для ресурсов, размещенных в виртуальной сети, реализована настройка маршрутизации BGP с активно-активной конфигурацией для обеспечения высокой доступности и автоматического переключения при отказе.

• VPN "сеть — сеть" для подключения филиала: Развернут VPN "сеть — сеть" для филиалов, не имеющих доступа к совместному расположению, создание VPN-шлюза в виртуальной сети концентратора с активно-активной конфигурацией для высокой доступности, настроены туннели IPsec/IKE с использованием сильной криптографии, соответствующей стандартам безопасности финансового сектора, реализована маршрутизация BGP для динамического выбора пути, что позволяет филиалам подключаться к ближайшему региональному концентратору, настраивая избыточные туннели, которые обеспечивают подключение во время обслуживания.

• VPN типа "точка-сеть" для удаленных сотрудников: Настроен VPN типа "точка-сеть" с проверкой подлинности Azure Active Directory для удаленных сотрудников, которым требуется безопасный доступ к приложениям, размещенным в Azure. Включена проверка подлинности на основе сертификатов как резервная мера для сценариев без доступа к Azure AD. Назначение клиентских IP-адресов из выделенного пула осуществляется через определяемые пользователем маршруты, направляющиеся к ресурсам виртуальной сети Azure. Реализованы протоколы OpenVPN для клиентов macOS/Linux и IKEv2/SSTP для клиентов Windows, что обеспечивает широкую совместимость с устройствами. Настроено разделение туннелирования, позволяющее прямой доступ к интернету для некорпоративного трафика, при этом трафик, направленный к Azure, проходит через VPN-туннель, что оптимизирует пропускную способность.

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

• Пиринг VNet для подключения между регионами Azure: Реализован пиринг виртуальных сетей, соединяющий периферийные виртуальные сети с виртуальными сетями концентратора Virtual WAN в каждом регионе, включена глобальная взаимосвязь VNet для подключения приложений между регионами, обеспечивающая низкую задержку через магистраль Azure. Настроена транзитная передача шлюзов, позволяющая периферийным сетям использовать VPN и шлюзы ExpressRoute хаба Virtual WAN без развертывания дополнительных шлюзов, что снижает затраты и сложность. Реализованы группы безопасности сети на периферийных подсетях для управления потоком трафика между подключенными виртуальными сетями с минимально необходимым уровнем доступа.

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

Результат: Частное подключение было обеспечено для всех финансовых транзакций, соответствующих требованиям PCI-DSS. ExpressRoute обеспечивает согласованную низкую задержку для торговли в режиме реального времени. Задержка между филиалами и центром обработки данных значительно сократилась благодаря Virtual WAN. Удаленные сотрудники успешно подключены через VPN типа "точка — сеть" с улучшенной проверкой подлинности. Глобальный пиринг виртуальных сетей позволил эффективное кросс-региональное аварийное восстановление. Оптимизация затрат достигается путем консолидации виртуальной глобальной сети.

Уровень критическости

Должно быть.

Сопоставление элементов управления

• NIST SP 800-53 ред.5: SC-7, SC-7(4), SC-8
• PCI-DSS версии 4: 1.2.1, 2.2.7, 4.2.1
• Элементы управления CIS версии 8.1: 12.8, 13.8
• NIST CSF версии 2.0: PR. AC-05, PR. DS-02
• ISO 27001:2022: A.8.21, A.8.22, A.5.14
• SOC 2: CC6.6, CC6.7

NS-10. Обеспечение безопасности системы доменных имен (DNS)

Принцип безопасности

Убедитесь, что конфигурация безопасности системы доменных имен (DNS) защищает от известных рисков:

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

Риск для смягчения

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

• DNS спуфинг/отравление: Злоумышленники подделывают ответы DNS или повреждают кэши резолверов (например, атака Камински), чтобы перенаправить клиентов на вредоносные серверы, что позволяет осуществлять фишинг и перехват данных.
• Атаки с увеличением DNS: Злоумышленники используют неправильно настроенные DNS-серверы для усиления трафика DDoS (например, 60-байтового запроса, предоставляющего 4000-байтовый ответ), подавляющих целевые сети.
• Эксплуатация незавершенных записей DNS: Незавершенные записи (например, устаревшие CNAME-записи) позволяют злоумышленникам захватывать вышедшие из эксплуатации ресурсы, перенаправляя трафик на вредоносные адреса для фишинга или распространения вредоносных программ.
• Утечка данных с помощью туннелирования DNS: Вредоносные субъекты кодируют данные в запросах DNS (например, data.exfil.evil.com) для скрытого извлечения конфиденциальной информации, обходя брандмауэры.
• Фишинг и доставка вредоносных программ: Скомпрометированные сопоставители перенаправляют законные домены на ip-адреса, контролируемые злоумышленниками, предоставляя фишинговые страницы или вредоносные программы неуказанным клиентам.

MITRE ATT&CK

• Командование и контроль (TA0011): Используйте туннелирование DNS для кодирования команд C2 в запросах (например, data.exfil.evil.com) или спуфинг разрешений для подключения к вредоносным серверам (например, T1071.004 — Протокол уровня приложений: DNS).
• Сбор (TA0009): Сбор данных путем спуфинга DNS для перенаправления пользователей на фишинговые сайты или эксфильтрации данных с помощью туннелирования (например, T1040 — сетевой перехват).
• Влияние (TA0040): Атаки амплификации DNS, отправка небольших запросов для генерации больших ответов, что нарушает доступность услуги (например, T1498.002 — отказ в обслуживании сети: отражение и амплификация).
• Первоначальный доступ (TA0001): Эксплуатация устаревших записей DNS или поддельных разрешений с целью доставки вредоносных программ или фишинга для получения доступа к системам (например, T1190 — уязвимость в публично доступном приложении).

NS-10.1 Использование доверенной службы DNS

Используйте доверенные службы DNS, чтобы клиенты получали правильные результаты разрешения и защищали от атак на основе DNS. Azure предоставляет рекурсивную службу DNS на уровне 168.63.129.16 (обычно назначается через DHCP или предварительно настроено) для разрешения DNS рабочей нагрузки на уровне операционной системы или приложения. Кроме того, используйте доверенные внешние DNS-серверы. Для организаций, которые размещают собственные домены, Azure DNS обеспечивает надежное авторитетное размещение DNS. Организации, создающиеся пользовательские DNS-серверы, должны соответствовать рекомендациям по безопасному развертыванию NIST SP 800-81 ред. 3.

• Используйте рекурсивную DNS-службу Azure или доверенный внешний DNS: Настройте рабочие нагрузки для использования рекурсивных DNS Azure (168.63.129.16) или доверенных внешних DNS-серверов в операционных системах виртуальной машины или параметров DNS приложения, чтобы обеспечить надежное разрешение имен.

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

• Хостинг доменов в Azure DNS: Используйте Azure DNS для размещения разрешения имен доменов для авторитарных нужд DNS, предоставляя надежный и масштабируемый хостинг DNS (примечание: Azure DNS не предоставляет услугу регистрации доменов).

• Следуйте рекомендациям по безопасному развертыванию DNS: Если вы создаете пользовательские DNS-серверы, выполните инструкции по развертыванию NIST SP 800-81 ред. 3. Руководство по развертыванию безопасной системы доменных имен (DNS) для реализации рекомендаций по обеспечению безопасности.

NS-10.2 используйте частный DNS в виртуальной сети

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

• Развертывание частного DNS Azure для частного разрешения: Используйте Azure Private DNS для создания частных зон DNS, которые сохраняют разрешение DNS в виртуальной сети, обеспечивая, что запросы никогда не покидают границы вашей сети.

• Настройте частный DNS для частных конечных точек: Настройте частные зоны DNS для частных конечных точек, чтобы заменить общедоступное разрешение DNS и обеспечить разрешение клиентами полных доменных имен частных конечных точек на частные IP-адреса в виртуальной сети.

• Реализуйте пользовательский DNS для ограниченного разрешения: Используйте пользовательские DNS-серверы, чтобы ограничить разрешение DNS только доверенными источниками разрешения для клиентов, обеспечивая дополнительный контроль над безопасностью разрешения имен.

NS-10.3 используйте Defender для DNS для расширенной защиты

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

• Включите защиту Defender для DNS: Используйте Microsoft Defender для DNS (включен в план Defender для серверов) для мониторинга и оповещения о подозрительных действиях DNS, включая утечку данных через туннелирование DNS, управляющие команды и взаимодействие с вредоносными доменами.

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

• Обнаружение висячих записей DNS: Используйте Microsoft Defender для App Service, чтобы определить висячие записи DNS при удалении веб-сайтов App Service, предотвращая атаки захвата поддомена и гарантируя удаление пользовательских доменов из регистраторов доменных имен.

Пример реализации

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

Подход к решению:

• Развернут рекурсивный DNS Azure (168.63.129.16) для всех рабочих нагрузок виртуальных машин Azure с правилами NSG, разрешающими трафик DNS.
• Размещенные авторитетные зоны в Azure DNS для разрешения общедоступных доменов с геораспределением
• Реализованы закрытые зоны DNS Azure для разрешения частных конечных точек (privatelink.database.windows.net, privatelink.blob.core.windows.net), связанных с производственными виртуальными сетями.
• Выполнена настройка интеграции частной DNS, обеспечивающая разрешение FQDN частных конечных точек на частные IP-адреса (например, sqlserver.database.windows.net → 10.0.2.4)
• Включение Microsoft Defender для DNS через План Defender для серверов чтобы отслеживать туннелирование DNS, обмен данными C2 и взаимодействия с вредоносными доменами
• Развернут Defender для службы приложений с целью обнаружения неактуальных DNS-записей во время вывода из эксплуатации веб-сайта

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

Уровень критическости

Должно быть.

Сопоставление элементов управления

• NIST SP 800-53 ред.5: SC-7, SI-4, SI-4(4), SI-4(5)
• PCI-DSS версии 4: 11.5.1, 12.10.1
• Элементы управления CIS версии 8.1: 8.5 , 13.6, 13.8
• NIST CSF версии 2.0: ДЕ. CM-01, DE. CM-04, DE. AE-02
• ISO 27001:2022: A.8.16, A.8.22, A.5.24
• SOC 2: CC6.1, CC7.2, CC7.3