Мониторинг операций базового кластера AKS для PCI-DSS 3.2.1 (часть 7 из 9)

В этой статье описываются рекомендации по кластеру Служба Azure Kubernetes (AKS), на котором выполняется рабочая нагрузка в соответствии со стандартом безопасности данных индустрии платной карты (PCI-DSS 3.2.1).

Этот материал входит в цикл статей. Ознакомьтесь с введением.

Регулярный мониторинг и тестирование сетей

Требование 10. Отслеживание и мониторинг доступа ко всем сетевым ресурсам и карта заполнителям

Поддержка функций AKS

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

AKS предоставляет журналы аудита на нескольких уровнях, которые могут быть полезны для защиты системы и данных заранее. Журналы действий предоставляют сведения об операциях, связанных с управлением учетными записями и секретами; управление параметрами диагностики; управление серверами; и другие операции доступа к ресурсам. Все журналы записываются с датой, временем, удостоверением и другими подробными сведениями. Вы также можете получить доступ ко всем хронологическим записям всех вызовов API, выполненных в кластере AKS. Журналы включают сведения о вызывающем объекте, время выполнения вызова, источник, где был инициирован вызов, и т. д. Дополнительные сведения см. в разделе "Включение и проверка журналов плоскости управления Kubernetes" в Служба Azure Kubernetes (AKS).

RBAC (управление доступом на основе ролей) можно использовать для управления политикой доступа к ресурсам в качестве стандартной практики в Azure.

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

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

Ваши обязанности

Требование	Обязанности
Требование 10.1	Реализуйте тропы аудита для связывания всех системных компонентов с каждым отдельным пользователем.
Требование 10.2	Реализуйте автоматические следы аудита для всех системных компонентов, чтобы восстановить следующие события:
Требование 10.3	Записывайте по крайней мере следующие записи журнала аудита для всех системных компонентов для каждого события:
Требование 10.4	Используя технологию синхронизации времени, синхронизируйте все критически важные системные часы и время и убедитесь, что для получения, распространения и хранения времени реализовано следующее.
Требование 10.5	Безопасные следы аудита, поэтому их нельзя изменить.
Требование 10.6	Просмотрите журналы и события безопасности для всех системных компонентов, чтобы определить аномалии или подозрительные действия.
Требование 10.7	Сохраняйте журнал следов аудита по крайней мере один год с минимальным количеством трех месяцев, которые немедленно доступны для анализа (например, в сети, архиве или восстановлении из резервной копии).
Требование 10.8	Дополнительное требование только для поставщиков услуг: своевременно реагировать на сбои любых критически важных элементов управления безопасностью. Процессы реагирования на ошибки в элементах управления безопасностью должны включать в себя
Требование 10.9	Убедитесь, что политики безопасности и операционные процедуры для мониторинга всех сетевых ресурсов и карта заполнителей документируются, используются и известны всем пострадавшим сторонам.

Требование 11. Регулярно тестировать системы безопасности и процессы

Поддержка функций AKS

AKS интегрирован с службами мониторинга Azure:

• Microsoft Defender для контейнеров предоставляет множество функций проверки безопасности. Например, Defender для контейнеров сканирует образы, извлекаемые, отправленные и импортированные в реестры контейнеров и предоставляет рекомендации. Дополнительные сведения см. в статье об оценке уязвимостей.

• Azure Monitor можно использовать для настройки оповещений на основе типа событий для защиты целостности системы и безопасности. Если на узлах AKS возникают ожидаемые сбои системы, AKS автоматически обрабатывает ресурс своевременно без прерывания обработки системы.

Кластеры AKS защищены Шлюз приложений Azure с помощью Брандмауэр веб-приложений (WAF) и могут быть настроены в режиме обнаружения оповещений и угроз. Более строгий режим — это профилактический режим, который активно блокирует обнаруженные вторжения и атаки. Дополнительные сведения см. в рекомендациях по сетевому подключению и безопасности в Служба Azure Kubernetes (AKS).

Ваши обязанности

Требование	Обязанности
Требование 11.1	Реализуйте процессы для проверки наличия беспроводных точек доступа (802.11) и обнаружения всех авторизованных и несанкционированных беспроводных точек доступа на ежеквартально.
Требование 11.2	Запуск внутренних и внешних уязвимостей сети проверяет по крайней мере квартал и после каких-либо существенных изменений в сети (таких как новые установки системных компонентов, изменения в топологии сети, изменения правил брандмауэра, обновления продуктов).
Требование 11.3	Реализуйте методологию для тестирования на проникновение, включающую следующее:
Требование 11.4	Используйте методы обнаружения вторжений и (или) предотвращения вторжений для обнаружения и/или предотвращения вторжений в сеть.
Требование 11.5	Разверните механизм обнаружения изменений (например, средства мониторинга целостности файлов) для оповещения персонала о несанкционированном изменении (включая изменения, дополнения и удаления) критически важных системных файлов, файлов конфигурации или файлов содержимого; и настройте программное обеспечение для выполнения критически важных сравнений файлов по крайней мере еженедельно.
Требование 11.6	Убедитесь, что политики безопасности и операционные процедуры для мониторинга и тестирования безопасности документируются, используются и известны всем пострадавшим сторонам.

Требование 10.1

Реализуйте тропы аудита для связывания всех системных компонентов с каждым отдельным пользователем.

Ваши обязанности

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

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

  Данные хранятся в течение 90 дней. Для более длительных вариантов хранения рекомендуется отправлять записи журнала действий в журналы Azure Monitor и настраивать политику хранения и архивирования.

  

• Параметры диагностики Azure. Предоставляет диагностические и аудиты сведения о ресурсах Azure и платформе, к которой применяется параметр. Рекомендуется включить параметры диагностики для AKS и других компонентов в системе, например Хранилище BLOB-объектов Azure и Key Vault. В зависимости от типа ресурса можно выбрать тип журналов и данных метрик для отправки в место назначения. Назначение диагностика должно соответствовать необходимым периодам хранения.

  • Параметр диагностики для AKS. В указанных категориях AKS включите журналы аудита Kubernetes. Параметры диагностики включают kube-audit или kube-audit-admin, а также guard.

    Включите kube-audit-admin просмотр вызовов сервера API на основе журнала, которые могут изменить состояние кластера. Если требуется аудит всех взаимодействий с сервером API (включая события, не изменяющие такие запросы на чтение), включите kube-audit вместо этого. Эти события могут быть плодовитыми, создавать шумы и увеличивать затраты на потребление. Эти журналы содержат сведения о имени доступа и удостоверениях, которые используются для выполнения запроса.

    Включите guard журналы для отслеживания управляемых идентификаторов Microsoft Entra ID и аудита управления доступом на основе ролей Azure (RBAC).

  Помимо журналов на основе пользователей, рассмотрите журналы из плоскости управления Kubernetes, включая kube-apiserver и kube-controller-manager. Эти журналы обычно не связаны с пользователем, но могут помочь сопоставить системные изменения, внесенные пользователями.

  Дополнительные сведения см. в разделе "Просмотр журналов компонентов уровня управления".

  Эта эталонная реализация включает cluster-autoscaler, kube-controller-managerkube-audit-adminи журналы и guard пересылает данные в рабочую область Log Analytics. Срок хранения рабочей области — 90 дней.

  

• Служба Azure Kubernetes (AKS) диагностика помогает обнаруживать и устранять проблемы с кластером, например сбои узлов. Она также включает в себя диагностические данные, относящиеся к сети, которые не требуют дополнительных затрат. Обычно эти данные не связаны с пользователем, но могут помочь сопоставить системные изменения, внесенные пользователями. Дополнительные сведения см. в Служба Azure Kubernetes диагностика.

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

Требование 10.2

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

• 10.2.1. Все операции доступа отдельного пользователя к данным владельца карты.
• 10.2.2. Все действия, выполняемые пользователем с правами суперпользователя или администратора.
• 10.2.3. Доступ ко всем журналам аудита.
• 10.2.4. Недопустимые попытки логического доступа.
• 10.2.5. Использование и изменение механизмов идентификации и проверки подлинности, включая, но не ограничивается созданием новых учетных записей и повышением привилегий, а также всех изменений, добавлений или удалений учетных записей с правами корневого или административного администратора.
• 10.2.6. Инициализация, остановка или приостановка ведения журналов аудита.
• 10.2.7. Создание и удаление объектов на уровне системы.

Ваши обязанности

AKS предоставляет журналы аудита на нескольких уровнях, как описано в описании требования 10.1. Ниже приведены некоторые ключевые моменты.

• По умолчанию журналы действий предоставляют сведения о критически важных операциях ресурсов Azure. Все журналы включают состояние, время и удостоверение, которое запустило операцию.
• Включите параметры диагностики для доступа ко всем записям всех вызовов API, выполненных в кластере AKS. В журналах содержатся сведения о запросе, метках времени, источнике запроса и содержимом запроса. Сохраните журналы в рабочей области Log Analytics с соответствующим периодом хранения. Включите ведение журнала рабочей области Log Analytics, чтобы убедиться, что даже доступ к следу аудита регистрируется.
• Включите сбор системных журналов с помощью контейнера Аналитика для записи журналов событий операционной системы на уровне узла AKS в рабочей области Log Analytics. Эти журналы также должны приниматься в SIEM.
• Включите ведение журнала аудита ос и использования для других вычислений, таких как агенты сборки и флажки перехода. Отключите доступ к системам непосредственно в качестве корневого каталога. Убедитесь, что все действия выполняются под определенным удостоверением.
• Журнал неудачных попыток доступа. Сюда входят запросы на доступ к компонентам, таким как служба хранилища Azure, Azure Key Vault, сервер API AKS и доступ к RDP/SSH в других системах.
• Воспользуйтесь преимуществами функций, предлагаемых сторонними агентами безопасности, чтобы помочь анализировать шаблоны пользователей в кластере AKS. Эти функции могут быть полезны для данных аудита доступа пользователей.

Требование 10.3

Записывайте по крайней мере следующие записи журнала аудита для всех системных компонентов для каждого события:

• 10.3.1. Идентификация пользователей.
• 10.3.2. Тип события.
• 10.3.3. Дата и время.
• 10.3.4. Указание успешного или неудачного выполнения.
• 10.3.5. Происхождение события.
• 10.3.6 Удостоверение или имя затронутых данных, системного компонента или ресурса.

Ваши обязанности

Как описано в описании требования 10.2, вы можете получить журналы аудита из кластера, включив параметр диагностики для AKS. Журналы содержат подробные сведения о получении, списке, создании, обновлении, удалении, исправлении и публикации событий. Журналы содержат сведения в списке в разделе "Требования". Сохраните журналы в учетной записи хранения, чтобы можно было запросить сведения.

Например, необходимо просмотреть предыдущий набор сведений для событий kube-audit-admin, выполнив этот запрос:

AzureDiagnostics
| where Category == 'kube-audit-admin'
| project TimeGenerated, ResourceId, log_s,  pod_s
| top 200 by TimeGenerated desc

Результирующий набор отображает сведения в рамках поля log_s.

Необходимые сведения	Схема
Идентификация пользователей	Исходные ip-адреса
тип события;	Команда
Дата и время	requestReceivedTimestamp
Указание успешности или сбоя	responseStatus
Происхождение события	Пользователь
Удостоверение или имя затронутых данных, системного компонента или ресурса	objectRef

Сведения о главном журнале см. в разделе "Просмотр журналов компонентов уровня управления".

Требование 10.4

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

• 10.4.1. Критически важные системы имеют правильное и согласованное время.
• 10.4.2. Данные о времени защищены.
• 10.4.3. Параметры времени получены из принятых отраслью источников времени.

Примечание. Одним из примеров технологии синхронизации времени является протокол NTP.

Ваши обязанности

AKS использует NTP из базовых узлов Azure и не требует каких-либо исходящих разрешений сетевого трафика для поддержки NTP. Другие виртуальные машины, которые вы добавляете в CDE, могут использовать внешние NTP-серверы, такие как ntp.ubuntu.org (и его пул) в качестве источника синхронизации времени. Дополнительные вычислительные ресурсы, которые вы вносите в CDE, должны явно использовать источник NTP и должен быть задокументирован.

Требование 10.5

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

• 10.5.1 Ограничение просмотра следов аудита людям с необходимостью, связанной с работой.
• 10.5.2. Защита файлов журнала аудита от неавторизованного изменения.
• 10.5.3. Быстрое создание резервной копии файлов журнала аудита на централизованном сервере журналов или носителе, который трудно изменить.
• 10.5.4. Запись журналов для внешних технологий на безопасном централизованном внутреннем сервере журналов или устройстве мультимедиа.
• 10.5.5. Применение мониторинга целостности файлов или программного обеспечения обнаружения изменений в журналах для гарантирования того, что имеющиеся данные журнала не могут быть изменены без создания оповещений (хотя добавление новых данных не должно вызывать оповещение).

Ваши обязанности

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

По возможности интегрируйте журналы. Преимуществом является возможность эффективного просмотра, анализа и запроса данных. Azure предоставляет несколько вариантов технологии. Аналитика контейнеров Azure Monitor позволяет записывать журналы в рабочую область Log Analytics. Другим вариантом является интеграция данных в решения по управлению безопасностью и событиями (SIEM), например Microsoft Sentinel. Другие популярные сторонние варианты: Splunk, QRadar и ArcSight. Microsoft Defender для облака и Azure Monitor поддерживают все эти решения. Эти решения являются приемниками данных только для добавления, чтобы убедиться, что путь не может быть изменен.

Defender для облака может экспортировать результаты с настроенными интервалами. Дополнительные сведения см. в разделе Непрерывный экспорт.

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

Log Analytics и Microsoft Sentinel поддерживают различные элементы управления доступом на основе ролей для управления доступом к следу аудита. Убедитесь, что роли сопоставляются с ролями и обязанностями организации.

Убедитесь, что рабочая область Log Analytics поддерживает как операции, так и требования соответствия. Рассмотрим выделенную рабочую область для кластеров в область, которая пересылается в решение SIEM.

Большинство журналов в AKS будут поступать из stdout/stderr и будут собираться аналитикой контейнеров Azure Monitor. Если у вас есть другие созданные вручную журналы, рассмотрите возможность создания данных таким образом, который отправляется в доверенный поток пересылки и не подлежит незаконному копированию.

Требование 10.6

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

• 10.6.1 Просмотрите следующие по крайней мере ежедневно:
  • все события безопасности;
  • журналы всех системных компонентов, которые хранят, обрабатывают или передают данные владельца карты и (или) SAD;
  • журналы всех критически важных системных компонентов;
  • Журналы всех серверов и системных компонентов, выполняющих функции безопасности (например, брандмауэры, системы обнаружения вторжений и системы предотвращения вторжений (IDS/IPS), серверы проверки подлинности, серверы перенаправления электронной коммерции и т. д.).
• 10.6.2 Периодически просматривает журналы всех остальных системных компонентов на основе политик организации и стратегии управления рисками, как определено ежегодной оценкой рисков организации.
• 10.6.3. Детальное рассмотрение исключений и аномалий, выявленных во время процесса проверки.

Ваши обязанности

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

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

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

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

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

Требование 10.7

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

Ваши обязанности

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

Требование 10.8

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

• восстановление функций безопасности;

• определение и документирование времени, на протяжении которого функция безопасности не работала (дата и время начала и окончания);

• определение и документирование причин сбоя, включая первопричину, а также действий по исправлению, необходимых, чтобы устранить первопричину;

• определение и устранение любой проблемы безопасности, возникшей во время сбоя;

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

• Реализация элементов управления, чтобы предотвратить повторную отработку отказа — возобновление мониторинга элементов управления безопасностью"

Ваши обязанности

Когда это практически, есть оповещения, указывающие на существование критически важных элементов управления безопасностью. В противном случае убедитесь, что процесс аудита может своевременно обнаружить отсутствие ожидаемого элемента управления безопасностью. Рассмотрите такие элементы управления, как агенты безопасности, работающие в кластере AKS, и элементы управления доступом (IAM и сеть) в ресурсах Azure. Включите параметры для проверка, если кластер AKS является частным кластером, для точек воздействия сети через правила группы безопасности сети (NSG) или проверка для непредвиденных общедоступных IP-адресов. Также включают непредвиденные изменения в DNS, маршрутизацию сети, брандмауэр и идентификатор Microsoft Entra.

Требование 10.9

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

Ваши обязанности

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

Требование 11.1

Реализуйте процессы для проверки наличия беспроводных точек доступа (802.11) и обнаружения всех авторизованных и несанкционированных беспроводных точек доступа на ежеквартально.

Внешние сети не область для этой документации и должны оцениваться отдельно.

Ваши обязанности

Эта архитектура и ее реализация не предназначены для поддержки локальных или корпоративных сетевых транзакций в облако через беспроводные подключения. Рекомендации см. в официальном стандарте PCI-DSS 3.2.1.

Требование 11.2

Запуск внутренних и внешних уязвимостей сети проверяет по крайней мере квартал и после каких-либо существенных изменений сети, таких как:

• Новые установки компонентов системы
• Изменения в топологии сети
• Изменения правил брандмауэра
• Обновления продуктов

Дополнительные сведения см. в разделе " Стандартный стандарт безопасности данных PCI", утвержденных поставщиков сканирования.

Ваши обязанности

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

Если в сети есть изменения, процесс должен оценить, требуется ли сканирование. Например, кластер теперь предоставляется общедоступному Интернету? Являются ли новые правила брандмауэра слишком разрешительными? В кластере существуют ли пробелы в безопасности потока между модулями pod?

Четкое и согласованное определение существенных изменений в отношении инфраструктуры. Некоторые примеры.

• Настройка правил NSG или Брандмауэр Azure
• Пиринги виртуальных сетей.
• Параметры DNS
• конфигурации Приватный канал Azure
• Другие сетевые компоненты

ПРИМЕНИМО К ВЕРСИИ 11.2.1

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

Эта проверка также должна включать в себя сети в кластере (pod-to-pod).

ПРИМЕНЯЕТСЯ К версии 11.2.2 Выбор утвержденного поставщика сканирования (ASV), который имеет широкий опыт работы с сетями Azure и Kubernetes. Это обеспечивает глубину и специфику предлагаемых исправлений.

Требование 11.3

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

• основан на общепринятых отраслевых подходах теста на проникновение (например, NIST SP800-115);
• охватывает весь периметр CDE и критические системы;
• включает тестирование как изнутри, так и вне сети;
• включает тестирование для проверки любой сегментации и инструментов сокращения области;
• определяет тесты на проникновение на уровне приложений для включения, как минимум, уязвимостей, перечисленных в требовании 6.5;
• Определяет тесты на проникновение сетевого слоя для включения компонентов, поддерживающих сетевые функции и операционные системы.
• включает проверку и анализ угроз и уязвимостей, возникших за последние 12 месяцев;
• Указывает хранение результатов тестирования на проникновение и результатов действий по исправлению.

Ваши обязанности

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

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

Тесты должны охватывать уровни приложений и данных, выполняемые в CDE.

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

Требование 11.4

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

Ваши обязанности

Защита кластера AKS путем проверки входящего трафика с помощью брандмауэра веб-приложения (WAF). В этой архитектуре Шлюз приложений Azure с интегрированным WAF предотвращает вторжение. Используйте режим предотвращения для активного блокирования обнаруженных вторжений и атак. Не просто используйте режим обнаружения . Дополнительные сведения см. в рекомендациях по сетевому подключению и безопасности в Служба Azure Kubernetes (AKS).

Альтернативным вариантом является использование возможностей обнаружения вторжений и (или) предотвращения вторжений в Брандмауэр Azure Premium. Дополнительные сведения см. в разделе IDPS.

Другим вариантом является включение Аналитика сети Azure Monitor, которая предоставляет доступ к возможностям мониторинга сети, таким как Монитор подключений, ведение журнала потоков для групп безопасности сети (NSG) и Аналитика трафика.

Включите планы Microsoft Defender в соответствии с различными компонентами CDE. Например, если SQL Azure используется для хранения chD, Microsoft Defender для SQL убедитесь, что обнаружены вторжения на уровень данных.

Кроме того, обнаружение аномалий в шаблонах трафика путем подключения журналов потоков NSG к централизованному решению SIEM, например Microsoft Sentinel. В этой эталонной реализации журналы находятся в режиме только для добавления, что сводит к минимуму отслеживание изменений в журналах аудита. Однако все журналы, отправляемые во внешние приемники для долгосрочного хранилища, не должны быть изменены. Они должны следовать подходу записи один раз/чтение-многие. Убедитесь, что решение для мониторинга целостности файлов (FIM) охватывает эти внешние сущности для обнаружения изменений.

Требование 11.5

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

Ваши обязанности

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

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

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

Любой другой вычислительный ресурс в CDE должен включать отслеживание изменений.

Требование 11.6

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

Ваши обязанности

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

Это важно для людей, которые являются частью процесса утверждения с точки зрения политики.

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

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