Google PCNE: Политики брандмауэра, Cloud Armor и сетевая безопасность — Руководство по подготовке

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

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

Иерархические политики брандмауэра, сегментация и сервисные периметры

Иерархические политики брандмауэра применяют правила на уровне организации или папки до правил уровня VPC. Используйте их для обеспечения защитных барьеров (например, «запретить весь входящий трафик из интернета на ВМ без балансировщика нагрузки» или «запретить RDP/SSH с 0.0.0.0/0»). Правила VPC более низкого уровня не могут переопределить уже сработавшее правило запрета на уровне организации/папки.

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

• Сегментация входящего трафика (ingress):
  • Политика на уровне организации/папки: высокоприоритетные правила запрета для рискованных портов и запрет по умолчанию, за исключением разрешенных точек входа. Разрешите диапазоны IP-адресов для проверок состояния Google (health checks), где это необходимо.
  • Правила VPC: разрешающие правила для конкретных рабочих нагрузок, нацеленные по сервисному аккаунту или защищенному тегу (secure tag). Для внутренних сервисов используйте Private Service Connect или внутренний балансировщик нагрузки для доступа «восток-запад» (east-west) с ограниченными правилами.
• Сегментация исходящего трафика (egress):
  • Замените неявное правило «разрешить все» для исходящего трафика на высокоприоритетное правило «запретить все» на уровне организации/папки или VPC, а затем открывайте только необходимое:
    • Исходящий трафик в интернет через Cloud NAT или утвержденные брандмауэры для исходящего трафика.
    • Доступ к Google API через Private Google Access и эндпоинты private.googleapis.com или restricted.googleapis.com. Эндпоинт restricted.googleapis.com используется в паре с VPC Service Controls для предотвращения утечки данных в неавторизованные проекты или к неавторизованным идентификаторам.
    • Для архитектур, которые направляют трафик 0.0.0.0/0 через сторонний брандмауэр, но все еще требуют прямого доступа к Google API без «шпильки» (hairpinning), добавьте статические маршруты для VIP-блоков Google API к шлюзу интернета по умолчанию и включите Private Google Access в подсетях. Это сохраняет средства контроля безопасности, одновременно снижая задержку и зависимость от стороннего устройства для доступа к сервисам Google.

Взаимодействие с сервисными периметрами:

• VPC Service Controls определяют периметры вокруг проектов и поддерживаемых Google API для предотвращения утечки данных. Когда периметры включены:
  • Предпочитайте использовать restricted.googleapis.com, чтобы вызовы API оставались в контексте периметра.
  • Убедитесь, что DNS указывает соответствующие домены на restricted или private эндпоинты, и что маршруты не возвращают трафик на недоверенные устройства для исходящего трафика.
  • Сочетайте политику периметра со списками разрешений брандмауэра для исходящего трафика, чтобы избежать случайных утечек на эндпоинты вне периметра.

Компромиссы:

• Запреты на уровне организации упрощают управление рисками, но могут блокировать легитимные эксперименты при медленном процессе управления изменениями; делегируйте исключения с помощью защищенных тегов (secure tags) и документированных процедур запросов.
• Агрессивные запреты исходящего трафика уменьшают радиус поражения (blast radius), но требуют надежного обнаружения сервисов и управления изменениями для предотвращения сбоев.

Cloud Armor, WAF и защита на глобальном периметре

Cloud Armor привязывает политики безопасности к внешним балансировщикам нагрузки HTTP(S) и внешним TCP/SSL Proxy для защиты на периметре сети.

• Правила WAF:
  • Используйте преднастроенные правила для OWASP Top 10 и распространенных CVE, а также пользовательские правила на языке выражений для сопоставления по заголовкам, IP-адресам, странам, URI и многому другому.
  • Применяйте правила к каждому бэкенд-сервису и упорядочивайте их по приоритету. Действия включают разрешение, запрет с определенным ответом или перенаправление для HTTP(S).
• Ограничение частоты запросов (rate limiting):
  • Применяйте квоты для каждого ключа (например, по IP-адресу клиента, заголовку или cookie) со скользящими окнами и контролем всплесков трафика. Блокировки на основе частоты запросов автоматически добавляют временные правила запрета для источников вредоносной активности.
• Adaptive Protection:
  • Обнаружение аномалий на основе машинного обучения (ML) изучает нормальные паттерны запросов и выявляет L7 DDoS-атаки или злоупотребления. Система может предлагать или автоматически генерировать правила-кандидаты; сначала развертывайте их в режиме предварительного просмотра (preview).
• Режим предварительного просмотра (preview mode):
  • Оценивайте новые правила без влияния на трафик. Результаты предварительного просмотра логируются, что позволяет выполнять настройку с низким риском. После проверки переходите в режим принудительного применения (enforced mode).

Защита от DDoS и управление глобальным балансировщиком нагрузки:

• Глобальная anycast-сеть Google поглощает объемные L3/L4 атаки; проверка SYN/ACK, обработка некорректных пакетов и автомасштабирование периферийных мощностей встроены в платформу для внешних балансировщиков HTTP(S) и TCP/SSL Proxy.
• Используйте в сочетании с Cloud Armor для смягчения L7-флуда, атак с перебором учетных данных (credential stuffing) и злоупотреблений на уровне приложения.
• Применяйте политики TLS, современные шифры и, при необходимости, клиентский mTLS на уровне балансировщика нагрузки. Для поддержки IPv6 используйте глобальный внешний балансировщик нагрузки HTTP(S) или TCP/SSL Proxy с IPv6 VIP.
• Для добавления IP-адресов определенных клиентов в список разрешенных для приложения за балансировщиком:
  • При использовании HTTP(S) предпочитайте списки разрешений Cloud Armor по IP-адресу клиента и ограничивайте правила брандмауэра для бэкендов только источниками GFE и проверок состояния.
  • При использовании сетевого балансировщика нагрузки TCP/UDP бэкенды видят реальный IP-адрес клиента; применяйте списки разрешений брандмауэра VPC непосредственно к целевым инстансам (по защищенному тегу или сервисному аккаунту) и включайте в них IP-адреса проверок состояния Google.

Предостережения по эксплуатации:

• Правила оцениваются на периметре сети; неверные списки разрешений могут мгновенно вызвать глобальные сбои. Используйте режим предварительного просмотра и поэтапное развертывание, а также отслеживайте логи Cloud Armor и метрики балансировщика нагрузки.
• Требования к привязке сессий (session affinity) различаются: для смешанных протоколов (например, HTTP и TFTP от одного клиента к одному пулу бэкендов) привязка по IP-адресу клиента на балансировщике нагрузки сохраняет «липкость» (stickiness) сессии между портами.

← Архитектура VPC · Все домены · Гибридное подключение →

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

Просмотреть Google →