Google ACE: Безопасность, соответствие требованиям и защита данных — Руководство по подготовке

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Часть Google Associate Cloud Engineer — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Google, или пройдите тесты на время на ExamRoll.io.

Обзор

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

Основы идентификации и доступа

Разделение ответственности и принцип наименьших привилегий
- Организуйте проекты в рамках единой организации с папками, отражающими границы доверия. Применяйте ограничения через Organization Policy для принудительного использования безопасных настроек по умолчанию (например, запрет публичных IP-адресов, ограничение местоположений, запрет на создание ключей сервисных аккаунтов).
- Назначайте роли IAM группам Google Groups, а не пользователям, и отдавайте предпочтение предопределенным ролям, а не базовым. Регулярно проверяйте привязки ролей и удаляйте неиспользуемые права.
- Обеспечьте возможность аудита и атрибуции. Для административного доступа к ОС виртуальных машин используйте OS Login с SSH-ключами для каждого пользователя; предоставляйте группам роли roles/compute.osLogin или roles/compute.osAdminLogin. Пример:
  - gcloud compute project-info add-metadata –metadata enable-oslogin=TRUE
  - gcloud projects add-iam-policy-binding PROJECT_ID –member=‘group:ops@example.com’ –role=‘roles/compute.osAdminLogin’
- Типичные ошибки: предоставление пользователям ролей owner или editor, использование SSH-ключей на уровне проекта и создание долгоживущих ключей сервисных аккаунтов.
Защита доступа к приложениям с помощью BeyondCorp и Identity-Aware Proxy (IAP)
- IAP терминирует доступ с проверкой личности на границе сети Google для HTTPS-приложений и для перенаправления TCP (SSH/RDP), устраняя необходимость выставлять приложения или бастионы в интернет. Используйте в паре с политиками контекстно-зависимого доступа (Access Context Manager), чтобы требовать определенного состояния устройства, IP-диапазонов или членства в группах пользователей.
- Преимущества: централизованная аутентификация и авторизация (authN/Z), строгая атрибуция, уменьшенная поверхность атаки и упрощенная политика брандмауэра (запретить входящий трафик, кроме как от балансировщика нагрузки/IAP).
- Компромиссы: неверная конфигурация может заблокировать администраторов; держите наготове «аварийный» доступ (ограниченный владелец проекта, внеполосный доступ к консоли). Некоторые устаревшие протоколы или не-HTTP сервисы могут потребовать перенаправления TCP через IAP или альтернативных средств контроля.
Сервисные аккаунты и Workload Identity
- Предпочтительно привязывать сервисные аккаунты к Compute Engine, GKE с Workload Identity, Cloud Run и Cloud Functions, чтобы рабочие нагрузки автоматически получали краткосрочные токены. Избегайте встраивания ключей; отключите создание ключей сервисных аккаунтов с помощью политики организации. Ограничивайте область действия IAM для сервисных аккаунтов (принцип наименьших привилегий).
- Типичные ошибки: широкое предоставление роли roles/iam.serviceAccountUser, что позволяет олицетворять сервисный аккаунт; сервисные аккаунты с избыточными привилегиями, которые становятся целями для горизонтального перемещения.

Защита данных и управление ключами

Шифрование, Cloud KMS, CMEK и конвертное шифрование
- Google по умолчанию шифрует все данные при хранении и передаче. Для дополнительного контроля и разделения обязанностей используйте управляемые клиентом ключи шифрования (CMEK) в Cloud KMS. Многие сервисы (BigQuery, Cloud Storage, Pub/Sub, диски Compute Engine) поддерживают CMEK; сервисы используют конвертное шифрование, где ваш CMEK оборачивает ключи шифрования данных (DEK) для каждого объекта или блока.
- Планируйте иерархию ключей: связки ключей (key rings) для каждого региона, криптографические ключи для каждого домена данных и ротация каждые 90–365 дней в зависимости от риска. Пример ротации:
  - gcloud kms keys update KEY_NAME –keyring=KR –location=REGION –rotation-period=90d –next-rotation-time=YYYY-MM-DDT00:00:00Z
- Контроль доступа: предоставляйте сервисным аккаунтам роль Cloud KMS CryptoKey Encrypter/Decrypter только для необходимых ключей. Отслеживайте использование с помощью журналов Cloud KMS.
- Типичные ошибки и компромиссы: отключение или удаление CMEK делает зависимые данные нечитаемыми; планируйте сценарии реагирования на инциденты, дважды проверяйте IAM перед ротацией и поддерживайте доступность ключей во всех развертываниях. Рассмотрите возможность использования External Key Manager, если вам нужно хранить ключи за пределами Google Cloud; учитывайте дополнительную задержку и риск внешней зависимости.
Secret Manager и избавление от жестко закодированных учетных данных
- Храните API-ключи, пароли баз данных и токены в Secret Manager с автоматическим версионированием и доступом на основе IAM. Интегрируйте ротацию через Cloud Scheduler → Pub/Sub → Cloud Functions/Run, которая обновляет вышестоящую систему и записывает новую версию секрета. Приложения получают секреты при запуске или по требованию и кэшируют их минимально.
- Лучшие практики: никогда не коммитьте секреты в код или образы; избегайте вывода секретов в логи; предоставляйте роль roles/secretmanager.secretAccessor удостоверениям рабочих нагрузок; используйте метки для обозначения уровня конфиденциальности.
- Типичные ошибки: встраивание секретов в переменные окружения, которые попадают в логи при сбоях; несвоевременное обновление нижестоящих приложений после ротации; широкие права IAM для доступа к секретам.
Классификация, хранение и конфиденциальность данных
- Классифицируйте данные (публичные, внутренние, конфиденциальные, регулируемые) и помечайте ресурсы метками. Используйте безопасность на уровне столбцов и политики доступа на уровне строк в BigQuery для гранулярного контроля. Для обнаружения и маскирования данных используйте Sensitive Data Protection (DLP).
- Реализуйте хранение: жизненный цикл объектов Cloud Storage (переходы между классами хранения и удаление по возрасту), политики хранения для бакетов с блокировками (holds) и TTL для таблиц или партиций BigQuery. Согласуйте сроки хранения с юридическими требованиями; более длительное хранение увеличивает риски и затраты.
- Конфиденциальность и местоположение данных: ограничивайте местоположение ресурсов с помощью политик организации; выбирайте между мультирегиональным и региональным хранилищем в зависимости от требований к суверенитету данных и задержке. Формируйте доказательную базу с помощью журналов аудита и дашбордов состояния безопасности в SCC.

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

Эшелонированная защита сетей
- Используйте правила брандмауэра VPC с политикой запрета по умолчанию; разрешайте только необходимые диапазоны источников и порты. Отдавайте предпочтение Private Google Access и Private Service Connect, чтобы трафик API не выходил в общедоступный интернет. Включите ведение журналов VPC Flow Logs и Firewall Rules Logging; регулярно анализируйте исходящий трафик.
- Для контроля исходящего трафика запретите весь исходящий трафик (egress), а затем явно разрешите необходимые назначения через прокси-сервер для исходящего трафика по FQDN или через NAT с прокси. Отслеживайте журналы Cloud NAT и настройте ведение журналов DNS.
VPC Service Controls (VPC SC), периметры сервисов и уровни доступа
- Изолируйте поддерживаемые Google API (например, BigQuery, Storage, Pub/Sub) с помощью периметров сервисов, чтобы снизить риски утечки данных даже в случае компрометации учетных данных. Используйте Access Context Manager для определения уровней доступа по группам пользователей, IP-адресам или состоянию устройства, что позволяет применять политики с учетом контекста.
- При необходимости настраивайте правила для исходящего трафика (egress rules) для легитимных межпериметральных интеграций и мостов между периметрами (perimeter bridges). Тестируйте в режиме пробного запуска (dry-run mode) VPC SC, чтобы выявить потенциальные сбои до применения политик.
- Возможные сбои: непреднамеренная блокировка заданий CI/CD или межпроектных заданий, отказ сторонних интеграций или обход защиты разработчиками с помощью неуправляемых устройств. Документируйте исключения и регулярно их пересматривайте.
Cloud Armor, защита от DDoS-атак и правила WAF
- Глобальная пограничная сеть Google обеспечивает постоянную защиту от DDoS-атак на уровнях L3/L4. Cloud Armor добавляет защиту на уровне L7 для внешних балансировщиков нагрузки HTTP(S), включая ограничение частоты запросов (rate limiting), доступ на основе геолокации/IP, пользовательские выражения и преднастроенные наборы правил WAF.
- Пример создания и подключения базового WAF:

undefined

- Примените политику к бэкенд-сервису вашего балансировщика нагрузки HTTPS.

Рекомендации: запускайте правила в режиме предварительного просмотра (preview), чтобы уменьшить количество ложных срабатываний, добавляйте разрешающие правила для известного доверенного трафика и, если возможно, включите адаптивную защиту. Компромиссы: Cloud Armor применяется к балансировщикам нагрузки HTTP(S) и прокси-балансировщикам; для сетевых и внутренних балансировщиков нагрузки требуются другие средства контроля.

Операции по обеспечению безопасности и соответствия требованиям

Security Command Center (SCC) и управление состоянием безопасности
- Используйте SCC как единую панель управления для отслеживания рисков. Уровень Standard объединяет данные о неверных конфигурациях и уязвимостях; уровень Premium добавляет обнаружение угроз (например, Event Threat Detection, VM and Container Threat Detection) и анализ путей атак.
- Сортируйте результаты по степени серьезности, назначайте ответственных и отслеживайте до полного устранения. Экспортируйте результаты в BigQuery или Pub/Sub для интеграции с SIEM и сбора доказательств. Постоянно оценивайте состояние безопасности на соответствие политикам организации и настраивайте оповещения о регрессиях.
Shielded VM, безопасная загрузка, vTPM, мониторинг целостности и усиление защиты ОС
- Включите функции Shielded VM для блокировки руткитов и несанкционированного изменения процесса загрузки: Secure Boot, vTPM и Integrity Monitoring для обнаружения изменений в загрузчиках и ядре. Некоторые кастомные ядра или неподписанные модули могут не пройти проверку Secure Boot; проверяйте образы перед включением этой функции.
- Усиливайте защиту ОС с помощью OS Config для своевременной установки исправлений, использования базовых конфигураций, соответствующих стандартам CIS, минимизации пакетов, отключения входа по паролю для SSH и логирования событий sudo и auth. Предпочитайте использовать IAP TCP forwarding для SSH и ограничьте входящий трафик к 0.0.0.0/0.
Сбор логов для расследований, классификация инцидентов, их локализация и устранение последствий
- Логирование для проведения расследований: журналы аудита Admin Activity и Data Access, VPC Flow Logs, Firewall Rules Logging, логи Cloud DNS, логи балансировщиков нагрузки, а также логи доступа к Cloud KMS и Secret Manager. Экспортируйте их в централизованный проект для логов и в BigQuery с соответствующими настройками хранения и контроля доступа.
- План действий по классификации и локализации инцидентов:
  - Проверьте индикаторы с помощью данных из SCC и сопоставленных логов.
  - Локализуйте угрозу, отозвав подозрительные токены, отключив скомпрометированные сервисные аккаунты, добавив запрещающие правила брандмауэра или временно изолировав инстансы с помощью тегов.
  - Сохраните доказательства: сделайте снимки дисков, экспортируйте логи, при необходимости сделайте дамп памяти с помощью утвержденных инструментов и задокументируйте цепочку ответственных (chain-of-custody).
  - Устраните последствия: выполните ротацию секретов и ключей, установите исправления для уязвимостей, пересоздайте системы из заведомо исправных образов, добавьте средства обнаружения для предотвращения повторения инцидента и проведите анализ после инцидента для усиления мер контроля.

Практический сценарий

Компания Nimbus Finance использует веб-сервисы и API за внешними балансировщиками нагрузки HTTP(S), обрабатывает регулируемые данные в BigQuery и Cloud Storage и предоставляет инженерам удаленный административный доступ. Недавние учения с участием «красной команды» (red-team) выявили риски эксфильтрации данных через скомпрометированные учетные данные и горизонтального перемещения по сети. Команде эксплуатации необходимо усилить контроль доступа, защитить данные и улучшить обнаружение угроз, не нарушая работу сервисов.

Внедрить OS Login с атрибуцией действий администраторов

Шаги: Включить OS Login на уровне проекта; добавить группе инженеров роль compute.osAdminLogin; удалить SSH-ключи уровня проекта.
Обоснование: SSH-ключи для каждого пользователя и роли на основе IAM обеспечивают четкую атрибуцию и простой отзыв доступа. Отказ от общих ключей снижает риск горизонтального перемещения.

Ограничить удаленный доступ с помощью IAP и контекстно-зависимого доступа

Шаги: Разместить административный интерфейс за балансировщиком нагрузки HTTPS, защищенным IAP; требовать членства в группе эксплуатации и соответствия корпоративным требованиям к IP-адресу/устройству через Access Context Manager.
Обоснование: Доступ по принципу «нулевого доверия» (zero-trust) устраняет публичную доступность и централизованно применяет условия для идентификации и устройств, снижая риск фишинга и атак с перебором учетных данных (credential-stuffing).

Внедрить Cloud Armor WAF с поэтапным применением правил

Шаги: Создать политику Cloud Armor; включить преднастроенные правила WAF для защиты от SQLi/XSS в режиме предварительного просмотра (preview); добавить правило ограничения частоты запросов для /login; отслеживать логи; затем применить правила в принудительном режиме.
Обоснование: Режим предварительного просмотра снижает количество ложных срабатываний; точечные ограничения частоты запросов противодействуют атакам credential stuffing и ботам, не затрагивая легитимный трафик.

Изолировать сервисы данных с помощью VPC Service Controls

Шаги: Создать периметр безопасности для проектов с BigQuery и Cloud Storage; определить правила исходящего трафика (egress) для разрешенных заданий CI/CD и аналитики; требовать уровни доступа на основе группы и сети.
Обоснование: Периметры безопасности предотвращают эксфильтрацию данных с использованием действительных учетных данных, ограничивая, откуда и как можно получить доступ к защищенным данным.

Применить CMEK с помощью Cloud KMS и настроить ротацию ключей

Шаги: Создать региональные связки ключей (key rings) и криптографические ключи для BigQuery и Storage; предоставить роль roles/cloudkms.cryptoKeyEncrypterDecrypter только сервисным аккаунтам; установить график ротации на 180 дней; отслеживать логи использования ключей.
Обоснование: CMEK обеспечивает разделение обязанностей и контролируемые криптографические границы; ротация ключей ограничивает радиус поражения в случае компрометации ключа.

Централизовать секреты с помощью Secret Manager и автоматизировать их ротацию

Шаги: Переместить токены баз данных и сторонних сервисов в Secret Manager; предоставить рабочим нагрузкам доступ с минимальными привилегиями; реализовать задание Cloud Scheduler → Pub/Sub → Cloud Run для ротации секретов и создания новых версий.
Обоснование: Исключает жестко закодированные учетные данные; версионирование и автоматизация обеспечивают предсказуемую, проверяемую ротацию с минимальным временем простоя.

Усилить безопасность хостов с помощью Shielded VM и защиты ОС

Шаги: Включить Secure Boot, vTPM и Integrity Monitoring на всех инстансах Compute Engine; принудительно отключить вход по паролю для SSH; использовать OS Config для еженедельной установки исправлений и применения базовых конфигураций CIS.
Обоснование: Предотвращает несанкционированное вмешательство на уровне загрузки, обнаруживает отклонения от конфигурации и уменьшает поверхность атаки на вычислительных узлах.

Повысить наблюдаемость и улучшить управление состоянием безопасности с помощью SCC

Шаги: Включить SCC Premium для всей организации; настроить уведомления в реальном времени в Pub/Sub; экспортировать результаты и логи в BigQuery; создать дашборды для ключевых KPI (количество открытых проблем высокой важности, среднее время на устранение).
Обоснование: Единая панель мониторинга сокращает время от обнаружения до реагирования и предоставляет доказательства соответствия требованиям.

Подготовить и протестировать план реагирования на инциденты

Шаги: Задокументировать этапы классификации, привилегированные учетные записи для экстренного доступа (break-glass), и действия по локализации (отключение IAM, изоляция с помощью брандмауэра, отзыв токенов); проводить учения ежеквартально; обеспечить хранение логов и блокировку объектов (object holds) в проекте для сбора доказательств.
Обоснование: Отработанные сценарии уменьшают количество ошибок в стрессовых ситуациях и сохраняют целостность данных для криминалистического анализа первопричин и отчетности перед регуляторами.

Проверить изменения и минимизировать сбои в работе

Шаги: Использовать режим «пробного запуска» (dry run) VPC SC и режим предварительного просмотра Cloud Armor для выявления потенциальных проблем; развертывать изменения по средам с использованием канареечных релизов; иметь план отката и окна для внесения изменений.
Обоснование: Контролируемое развертывание снижает риски для доступности, связанные с ужесточением безопасности, и в то же время позволяет достичь целевого снижения рисков эксфильтрации и несанкционированного доступа.

← Мониторинг · Все домены · Надежность →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →