Справочник

Рабочим нагрузкам GKE требуется доступ к API GCP без управления ключами учетных записей служб.

→Включите и настройте Workload Identity в кластере GKE. Сопоставьте Kubernetes Service Accounts (KSA) с Google Service Accounts (GSA).

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

Источник↗

Предоставить доступ к внутренним веб-приложениям из любой сети на основе идентификации пользователя и состояния устройства, без VPN.

→Используйте Identity-Aware Proxy (IAP) с Access Context Manager. Определите уровни доступа на основе IP-адреса, состояния устройства (через Endpoint Verification) и идентификации пользователя.

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

Источник↗

Конвейеру CI/CD (например, GitHub Actions, GitLab) требуется доступ к ресурсам GCP без долговременных учетных данных.

→Используйте Workload Identity Federation. Создайте пул поставщиков для внешнего IdP (например, GitHub OIDC) и настройте условия атрибутов для ограничения доступа к конкретным репозиториям или веткам.

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

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

→Используйте ограничения Organization Policy, такие как `iam.disableServiceAccountKeyCreation` и `iam.allowedPolicyMemberDomains`.

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

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

→Используйте Privileged Access Manager (PAM) для just-in-time (JIT) доступа. Пользователь запрашивает определенную роль на ограниченное время, что проходит через рабочий процесс утверждения.

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

Несколько команд используют один кластер GKE. Каждая команда должна управлять ресурсами только в своем собственном пространстве имен.

→Предоставьте роль IAM `roles/container.clusterViewer` на уровне проекта. Используйте Kubernetes RBAC `Role` и `RoleBinding` в каждом пространстве имен для предоставления конкретных разрешений (например, редактирование, просмотр).

Почему: Разделяет аутентификацию на уровне кластера (IAM) от авторизации на уровне пространства имен (Kubernetes RBAC), обеспечивая детальный, многопользовательский контроль.

Вызовы API должны использовать кратковременные учетные данные вместо статических ключей.

→Используйте имитацию учетной записи службы. Предоставьте субъекту роль `roles/iam.serviceAccountTokenCreator` в целевой учетной записи службы для генерации кратковременных токенов доступа OAuth 2.0.

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

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

→Предоставьте необходимую роль IAM с временным условием IAM, например, `request.time < timestamp("YYYY-MM-DDTHH:MM:SSZ")`.

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

Разрешать развертывание в производственные кластеры GKE только тех образов контейнеров, которые были подписаны конвейером CI/CD.

→Реализуйте Binary Authorization. Создайте аттестацию в конвейере CI для подписи образов. Настройте политику Binary Authorization в кластере GKE, чтобы требовать эту аттестацию.

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

Источник↗

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

→Используйте IAM Conditions с выражениями тегов ресурсов, такими как `resource.matchTag("123456789/env", "prod")`.

Почему: Обеспечивает масштабируемый, атрибутивно-ориентированный контроль доступа (ABAC). Разрешения динамичны и применяются автоматически по мере маркировки ресурсов.

Разрешить сервисному проекту развертывать виртуальные машины в хост-проекте Shared VPC без предоставления прав сетевого администратора.

→В хост-проекте предоставьте учетной записи службы сервисного проекта роль `roles/compute.networkUser` для конкретных подсетей, которые ей необходимо использовать.

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

Пользователь с `storage.admin` не может создать корзину. Вам нужно определить основную причину.

→Проверьте наличие политики IAM Deny на более высоком уровне (папка, организация), которая запрещает разрешение `storage.buckets.create`.

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

Включить SSO для пользователей локального Active Directory для доступа к консоли Google Cloud.

→Используйте Google Cloud Directory Sync (GCDS) для синхронизации идентификаторов с Cloud Identity. Настройте федерацию (SAML) между Cloud Identity и AD FS (или другим IdP).

Почему: Сохраняет AD как источник истины для идентификаторов, обеспечивая при этом бесшовный, федеративный SSO для пользователей.

Зашифровать данные в GCP, но ключи шифрования никогда не должны покидать локальный HSM.

→Используйте Cloud External Key Manager (EKM). Это позволяет сервисам GCP использовать ключи из внешней системы управления ключами для операций CMEK.

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

Источник↗

Автоматически находить и классифицировать конфиденциальные данные (PII, PHI) во всех активах Cloud Storage и BigQuery.

→Настройте сканирование Cloud Data Loss Prevention (DLP). Результаты могут автоматически заполнять Data Catalog тегами.

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

Команде аналитиков необходимо запрашивать данные, содержащие PII, но они не должны видеть необработанные конфиденциальные значения. Ссылочная целостность должна быть сохранена.

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

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

Структура соответствия (например, для финансовых услуг) требует, чтобы ключи шифрования были защищены HSM, сертифицированным по FIPS 140-2 Level 3.

→Используйте Cloud KMS с уровнем защиты HSM. Это создает ключи внутри управляемого аппаратного модуля безопасности.

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

Убедитесь, что новые ресурсы (например, корзины GCS, наборы данных BigQuery) всегда шифруются ключами, управляемыми клиентом (CMEK), а не ключами, управляемыми Google.

→Примените политику организации `constraints/gcp.restrictNonCmekServices`.

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

Данные должны храниться в неизменном состоянии (WORM - Write-Once-Read-Many) в течение определенного периода хранения по юридическим причинам или причинам соответствия.

→Настройте корзину Cloud Storage с политикой хранения и включите Bucket Lock.

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

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

→Используйте Secret Manager с настроенной автоматической ротацией. Ротация запускает Cloud Function, которая обновляет пароль в базе данных и создает новую версию секрета.

Почему: Управляемая, автоматизированная ротация снижает риск компрометации учетных данных. Приложения ссылаются на `latest` версию для беспрепятственного получения нового секрета.

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

→Используйте Confidential Computing, развернув рабочую нагрузку на Confidential VMs.

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

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

→Используйте BigQuery column-level security. Примените теги политики Data Catalog к конфиденциальным столбцам и предоставьте роль "Fine-Grained Reader" для этих тегов политики авторизованным пользователям/группам.

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

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

→Зашифруйте объекты с помощью управляемого клиентом ключа шифрования (CMEK) и строго контролируйте доступ к этому ключу в Cloud KMS.

Почему: Создает систему с двумя ключами. Злоумышленнику нужны разрешения как для объекта GCS, так и для ключа KMS для расшифровки данных, обеспечивая глубокую защиту.

Предотвратить случайное или злонамеренное немедленное удаление критически важных ключей Cloud KMS.

→При создании ключа настройте свойство `destroy_scheduled_duration` на значение, например, 30 дней.

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

Юридическое требование доказать, что файл в Cloud Storage не был изменен с момента его загрузки.

→При загрузке повторно вычислите хеш MD5 или CRC32C файла и сравните его с хешем, хранящимся в метаданных объекта Cloud Storage.

Почему: Обеспечивает криптографическое доказательство целостности объекта. Cloud Storage автоматически вычисляет и хранит эти хеши при загрузке.

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

→Поместите конфиденциальный проект в периметр VPC Service Controls. Это ограничивает перемещение данных в другие проекты за пределами периметра.

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

Источник↗

Защитить общедоступное веб-приложение от объемных DDoS-атак и распространенных веб-эксплойтов (например, SQLi, XSS).

→Разместите приложение за Global External HTTP(S) Load Balancer и подключите политику безопасности Cloud Armor с предварительно настроенными правилами WAF.

Почему: Балансировщик нагрузки поглощает DDoS-атаки на границе Google. Cloud Armor предоставляет управляемый брандмауэр веб-приложений для блокировки угроз OWASP Top 10.

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

→Настройте туннель HA VPN поверх подключений Cloud Interconnect VLAN.

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

Локальным системам необходимо вызывать Google API (например, BigQuery, GCS) без прохождения через публичный интернет.

→Настройте Private Google Access для локальных хостов. Используйте Cloud Interconnect или VPN и настройте DNS для разрешения `*.googleapis.com` в ограниченный диапазон VIP.

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

Принудительно применять взаимный TLS (mTLS) для всей межсервисной связи в кластере GKE.

→Разверните Anthos Service Mesh (или Istio) и включите строгую взаимную mTLS-аутентификацию для соответствующих пространств имен.

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

Потребительскому VPC требуется частный доступ к службе (например, внутреннему API), работающей в VPC производителя, без использования пиринга или публичных IP-адресов.

→Производитель публикует службу с помощью Private Service Connect. Потребитель создает конечную точку в своем VPC, которая приватно маршрутизируется к службе.

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

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

→Создайте частный кластер GKE. Включите Private Google Access в подсети для доступа узлов к API GCP. Настройте авторизованные сети мастера для ограничения доступа плоскости управления к определенным IP-адресам (например, корпоративной сети).

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

В кластере GKE поды для службы `frontend` должны иметь возможность общаться только с подами для службы `backend`, и ни с чем другим.

→Создайте ресурсы Kubernetes NetworkPolicy. Примените политику входящего трафика к подам `backend`, которая разрешает трафик только от подов `frontend` на основе меток подов.

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

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

→Настройте Cloud NAT для подсети, содержащей виртуальные машины.

Почему: Предоставляет управляемую трансляцию сетевых адресов для интернет-трафика из частных экземпляров с централизованным ведением журналов и распределением IP-адресов.

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

→Создайте иерархическую политику брандмауэра на уровне организации или папки с правилом запрета для порта 22 из `0.0.0.0/0` с высоким приоритетом.

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

Разрешать внутренние имена хостов в VPC без утечки запросов на публичные DNS-серверы.

→Настройте частную управляемую зону Cloud DNS для ваших внутренних доменов и свяжите ее с вашим VPC.

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

Когда Security Command Center обнаруживает угрозу (например, криптомайнинг), автоматически изолировать затронутую виртуальную машину.

→Настройте SCC для публикации результатов в тему Pub/Sub. Запустите Cloud Function, которая получает результат и изменяет сетевые теги виртуальной машины для применения предварительно настроенного правила брандмауэра "карантина".

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

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

→Создайте приемник журналов на уровне организации в корзину Cloud Storage. Настройте целевую корзину с политикой хранения на 7 лет и Bucket Lock.

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

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

→Остановите экземпляр виртуальной машины (чтобы остановить активность) и немедленно создайте снимок ее постоянного диска. Затем изолируйте ее с помощью правил брандмауэра.

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

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

→Включите уровень Security Command Center Premium, который включает Event Threat Detection. Эта служба анализирует журналы на предмет аномального поведения.

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

Центральная группа безопасности должна анализировать и коррелировать сигналы безопасности из GCP, AWS и локальных систем на одной платформе.

→Передайте все соответствующие журналы и телеметрию в Chronicle Security Operations (SIEM).

Почему: Chronicle — это облачная SIEM, предназначенная для анализа петабайтов данных, со встроенными парсерами и правилами обнаружения для мультиоблачных и гибридных сред.

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

→Настройте канал Cloud Asset Inventory для отправки уведомлений об изменениях активов в реальном времени в тему Pub/Sub. Затем служба может сравнить эти изменения с состоянием Terraform.

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

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

→Используйте Attack Path Simulation в SCC Premium. Определите ценные активы, и симуляция выявит и приоритизирует результаты, которые образуют прямой путь к этим активам.

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

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

→Включите Container Threat Detection в Security Command Center.

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

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

→Настройте Packet Mirroring для клонирования трафика с исходных виртуальных машин и отправки его на виртуальную машину-коллектор, работающую с инструментами инспекции, такими как Wireshark или Zeek.

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

Предотвратить развертывание небезопасных конфигураций Terraform (например, публичных корзин GCS).

→Интегрируйте инструмент статического анализа безопасности (SAST), такой как `tfsec` или Checkov, в конвейер CI/CD. Отклоняйте сборку, если обнаружены нарушения безопасности.

Почему: Реализует подход "shift-left" в безопасности, выявляя неправильные конфигурации до их развертывания, снижая потребность в реактивном исправлении.

Компания должна гарантировать, что по соображениям соответствия определенные данные и обработка могут происходить только в регионах ЕС.

→Примените ограничение `gcp.resourceLocations` Organization Policy, разрешающее только указанные регионы ЕС.

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

Финансовое учреждение требует, чтобы инженеры поддержки Google получали явное, ограниченное по времени разрешение перед доступом к их данным для случая поддержки.

→Включите Access Approval и настройте утверждающих. Все запросы на доступ от Google будут генерировать запрос, который должен быть одобрен.

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

Аудитор запрашивает отчет Google SOC 2 Type II и аттестацию соответствия PCI DSS.

→Используйте Compliance Reports Manager в консоли Google Cloud для доступа и загрузки отчетов об аудите и сертификаций.

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

Постоянно отслеживать среду GCP на предмет конфигураций, нарушающих определенный стандарт соответствия, такой как PCI DSS или HIPAA.

→Используйте Security Health Analytics в Security Command Center, с включенным соответствующим стандартом соответствия на панели мониторинга.

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

Аудитор запрашивает отчет Google SOC 2 Type II и аттестацию соответствия PCI DSS.

→Используйте Compliance Reports Manager в консоли Google Cloud для доступа и загрузки отчетов об аудите и сертификаций.

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

Агентству правительства США необходимо развернуть рабочую нагрузку, соответствующую требованиям FedRAMP High.

→Разверните приложение в среде Assured Workloads, настроенной для режима соответствия FedRAMP High.

Почему: Assured Workloads автоматически применяет необходимые элементы управления и средства защиты (например, местоположение данных, ограничения доступа персонала) для обеспечения соответствия конкретным стандартам.