Google PCNE: Автоматизация сети, управление и контроль затрат — Руководство по подготовке

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

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

Обзор

Автоматизация сети, управление и контроль затрат в Google Cloud — это неразделимые дисциплины, которые определяют, насколько надежно, безопасно и экономично работают ваши сети в большом масштабе. Эффективный подход сочетает в себе хорошо структурированную иерархию ресурсов и IAM с принципом минимальных привилегий, инфраструктуру как код (IaC) и рабочие процессы, управляемые событиями. Все это подкрепляется четкими бюджетами, квотами и возможностью аудита. Конечным результатом является предсказуемое развертывание, минимум ручных изменений, убедительные доказательства соответствия требованиям и прозрачная юнит-экономика для сетевых ресурсов.

Управление и контроль доступа

Иерархия ресурсов
- Структура «Организация → Папки → Проекты» является плоскостью управления для наследования разрешений и применения ограничивающих политик. Размещайте производственные (production) и непроизводственные (non-production) среды в разных папках, чтобы изолировать политики и квоты. Используйте метки (labels) для VPC, подсетей, маршрутизаторов, правил пересылки и экземпляров для распределения затрат и таргетинга ресурсов.
- Shared VPC позволяет консолидировать маршрутизацию и сетевое взаимодействие в хост-проекте, делегируя при этом вычислительные ресурсы сервисным проектам. Предоставляйте доступ только к тем подсетям, которые необходимы каждому сервисному проекту, чтобы следовать принципу явного предоставления сетей и уменьшить непреднамеренное раскрытие маршрутов.
IAM и принцип минимальных привилегий
- Разделяйте администрирование сети и администрирование безопасности. Роль Compute Network Admin предоставляет полный контроль над сетевыми конструкциями и доступ только для чтения к правилам брандмауэра, в то время как Security Admin управляет правилами брандмауэра и SSL-сертификатами. Такое разделение позволяет избежать появления операторов с избыточными правами и соответствует процессам управления изменениями.
- Предоставляйте целевые роли:
  - Для изменения правил брандмауэра используйте роль Security Admin в Shared VPC.
  - Для управления VLAN attachments и другими ключевыми сетевыми ресурсами подходит роль Compute Network Admin.
  - Для автоматизации, работающей с конкретными ресурсами, по возможности предоставляйте разрешения на уровне ресурса, а не роли на уровне проекта, или создайте кастомную роль, ограниченную только необходимыми разрешениями.
- Предпочитайте олицетворение сервисного аккаунта (impersonation) и краткосрочные токены постоянным ключам. По возможности запрещайте создание ключей сервисных аккаунтов с помощью политики организации. Используйте Workload Identity Federation, чтобы полностью отказаться от ключей при автоматизации в локальной (on-prem) или мультиоблачной среде.
- Следуйте принципу минимальных привилегий для задач на уровне данных. Например, заданию, которое читает данные из Cloud Storage, нужна только роль storage object viewer для целевого бакета, а не широкая роль editor на уровне проекта.
Политики организации
- Принудительно устанавливайте политику «без внешнего IP» для ВМ по умолчанию; используйте Private Google Access и Cloud NAT для доступа к Google API без публичных адресов.
- Ограничивайте пиринг и внешний доступ только утвержденными шаблонами (например, ограничьте конфигурации VPC-пиринга, чтобы избежать их бесконтрольного роста).
- Ограничивайте создание и использование ключей сервисных аккаунтов, чтобы сократить их распространение.
- Сценарии сбоев и компромиссы:
  - Слишком широкие роли, унаследованные на уровне папки, могут незаметно предоставить права на запись во множество проектов. Проверяйте привязки ролей с помощью анализа действующих разрешений.
  - Блокировка внешних IP-адресов для ВМ без предварительного планирования Private Google Access и NAT приводит к сбоям при обращении к сервисам Google.
  - Преобразование VPC из автоматического режима (auto mode) в пользовательский (custom mode) без рефакторинга шаблонов, которые полагались на автоматические подсети, нарушает развертывания; после этого необходимо явно указывать пользовательские подсети.

Автоматизация, IaC и операции, управляемые событиями

Инфраструктура как код (IaC) с помощью Terraform
- Используйте модульный дизайн: один модуль на каждый примитив (VPC, подсеть, брандмауэр, Cloud Router, Cloud NAT, Interconnect attachment), а затем составляйте из них стеки окружений. Управляйте версиями модулей и закрепляйте их в использующих стеках для контроля над выкаткой изменений.
- Храните состояние (state) удаленно с блокировкой (например, в Cloud Storage с блокировкой в стиле DynamoDB через шаблон бэкенда), чтобы предотвратить одновременные изменения. Шифруйте и создавайте резервные копии состояния; относитесь к нему как к конфиденциальным данным.
- Управление расхождениями (drift):
  - Внедряйте изменения через pull-запросы и выполнение terraform plan в CI, чтобы выявить разницу между ожидаемой и реальной конфигурацией. Запускайте по расписанию обнаружение расхождений (plan -detailed-exitcode) и отправляйте оповещения при их появлении.
  - Избегайте нерегламентированных изменений через gcloud в производственной среде; если экстренные исправления необходимы, зафиксируйте их и немедленно синхронизируйте с кодом.
- Идемпотентность и защитные механизмы: Всегда выполняйте шаги plan, review и apply. Используйте целевые apply для минимизации радиуса поражения. Применяйте валидацию переменных и «политику как код» (policy-as-code, например, с помощью Sentinel или OPA), чтобы блокировать антипаттерны, такие как пересекающиеся CIDR-блоки или открытые для всех брандмауэры.
gcloud, API и рабочие процессы
- Используйте gcloud и REST для операционных задач, требующих низкой задержки, но оборачивайте их в воспроизводимые скрипты. Учитывайте конечную согласованность (eventual consistency) и ограничения скорости API, реализуя повторные попытки с экспоненциальной выдержкой.
- Операции, управляемые событиями:
  - Используйте связку Cloud Scheduler + Pub/Sub + Cloud Run/Cloud Functions для автоматизации рутинных задач, таких как проверка квот, аудит утилизации Cloud NAT или выборочный сбор логов брандмауэра.
  - Направляйте потоки логов Admin Activity и Data Access в Pub/Sub для запуска защитных рабочих процессов (например, для автоматического отката неавторизованного изменения правила брандмауэра).
- Примеры фрагментов кода
  - Предоставление роли:

undefined

- Создание маршрута для Google API в обход маршрута по умолчанию к NGFW:
  -

undefined

Эксплуатационные риски
- Состояния гонки (race conditions), когда несколько конвейеров (pipelines) управляют общими ресурсами (например, правилами брандмауэра в общем VPC), вызывают флаппинг (постоянное изменение состояния). Используйте соглашения о владении и конвейеры, привязанные к папкам.
- Нестабильность API при высоком параллелизме вызывает ошибки квот; регулируйте и пакетируйте операции по регионам и типам ресурсов.

Управление затратами, квотами и мощностями

Квоты и лимиты API
- Отслеживайте квоты для каждого проекта и региона (адреса, правила пересылки, правила брандмауэра, подключения interconnect, маршрутизаторы). Автоматизируйте мониторинг квот и запрашивайте их увеличение до развертывания новых сред. Встройте предварительные проверки квот в CI для быстрого обнаружения ошибок.
- Обеспечивайте ресурсы в большом масштабе с помощью:
  - Регионального шардинга (создавайте ресурсы в каждом регионе, чтобы избежать конкуренции за региональные квоты).
  - Предварительного выделения (резервируйте адреса и настраивайте маршрутизаторы до пиковых событий).
  - Поэтапного развертывания (создание, проверка, а затем подключение бэкендов).
Экономика исходящего трафика и топологии
- Трафик между регионами в пределах одного VPC влечет за собой расходы на исходящий трафик между регионами. Размещайте взаимодействующие рабочие нагрузки в одном регионе или реплицируйте данные по регионам, когда задержка и стоимость имеют значение.
- Для пользователей, находящихся рядом с us-east1 и europe-west1, единый VPC с региональными подсетями обеспечивает частную связь по RFC1918, минимизируя накладные расходы на NAT и пиринг и позволяя использовать простые политики и маршрутизацию.
- Используйте VPC Network Peering для подключения между проектами или отделами с низкими накладными расходами, без NAT и транзитивной маршрутизации; поддерживайте непересекающиеся диапазоны CIDR. Используйте отдельные VPC для изоляции отделов, которые не должны взаимодействовать.
- Cloud CDN сокращает исходящий трафик и улучшает задержку для трафика HTTP(S); глобальный балансировщик нагрузки HTTP(S) является плоскостью управления для CDN. Сетевой балансировщик нагрузки не улучшит глобальную задержку для веб-приложений, поскольку у него нет пограничного распределения и кэширования.
- Выбирайте interconnect с умом: Dedicated Interconnect с подключениями VLAN в хост-проекте централизует администрирование и снижает затраты на каждый проект при большом общем подключении к локальной сети. Cloud VPN с Cloud Router подходит для быстрого зашифрованного подключения между организациями с возможностью последующего перехода на interconnect.
Распределение затрат, бюджеты и прогнозирование
- Помечайте все сетевые ресурсы метками для отдела, среды и центра затрат. Экспортируйте данные биллинга в BigQuery и рассчитывайте удельные затраты (например, $/ГБ исходящего трафика на сервис).
- Создавайте бюджеты на уровне проекта, папки или метки. Отправляйте оповещения в Pub/Sub и подключайте их к ChatOps или обработчикам на Cloud Run. Автоматизируйте действия при превышении бюджета (например, уменьшение выборки логов или масштабирование некритичных тестовых сред).
- Оптимизируйте исходящий трафик:
  - Предпочитайте Private Google Access и Cloud NAT вместо внешних IP-адресов для контроля путей исходящего трафика и централизации биллинга.
  - Для топологий с принудительным туннелированием добавьте пользовательские маршруты для Google API к шлюзу интернета по умолчанию или настройте Private Google Access для локальной сети, чтобы избежать «шпилечного» трафика (hairpinning) через сторонние брандмауэры.
  - Прогнозируйте мощность, анализируя VPC Flow Logs и логи балансировщика нагрузки; сопоставляйте с сезонностью. Заранее подбирайте правильный размер шлюзов NAT и пропускную способность interconnect перед пиковыми нагрузками.

Аудит и операционное совершенство

Ведение журналов и сбор свидетельств
- Cloud Audit Logs:
  - Журналы Admin Activity фиксируют изменения на уровне управления (control plane) в VPC, маршрутах, брандмауэрах, маршрутизаторах и балансировщиках нагрузки; они включены всегда. Храните их централизованно и при необходимости направляйте в проект безопасности с использованием CMEK.
  - Журналы Data Access для сетевых API могут быть очень объемными; включайте их выборочно и применяйте семплирование или приемники (sinks).
- VPC Flow Logs и Firewall Rules Logging предоставляют свидетельства на уровне данных (data-plane) для реагирования на инциденты и обеспечения соответствия требованиям. Храните их в течение требуемого срока и индексируйте с помощью BigQuery для расследований.
- Записи об изменениях: Требуйте, чтобы каждое сетевое изменение исходило из IaC с неизменяемым артефактом плана и ссылкой на заявку (тикет). Для исключительных изменений, вносимых вручную, фиксируйте команду gcloud, оператора, временную метку и обоснование в центральном реестре.
Безопасные учетные данные и контроль рисков автоматизации
- Исключите использование долгоживущих ключей сервисных аккаунтов. Используйте IAM Conditions для ограничения области действия автоматизации по ресурсу, времени или IP-адресу. Защищайте высокорискованные разрешения (например, compute.firewalls.update, compute.routers.updateBgpPeer) с помощью процессов утверждения.
- Применяйте принцип наименьших привилегий к CI/CD, используйте отдельные сервисные аккаунты для каждой среды и часто ротируйте токены. Используйте VPC Service Controls для защиты периметра сервисов там, где существуют риски эксфильтрации данных.
Регламенты (runbooks), жизненный цикл и постоянное улучшение
- Поддерживайте регламенты для рутинных операций: подключение проекта к Shared VPC, создание VPC-пиринга, установка Cloud VPN с IKEv2, продвижение правил Cloud Armor из режима предварительного просмотра в режим принудительного применения.
- Определите политики жизненного цикла:
  - Продвижение по средам «Песочница» → «Тестовая» → «Рабочая» (Sandbox → Staging → Production) с использованием идентичных модулей Terraform и переменных для конкретного региона.
  - Используйте сценарии вывода из эксплуатации (playbooks) для безопасного удаления пиринговых соединений, NAT и маршрутов.
- Постоянное улучшение:
  - Результаты разборов после инцидентов должны использоваться для улучшения модулей (например, добавление правила deny по умолчанию для исходящего трафика с явными списками разрешений или включение логирования NAT по умолчанию).
  - Регулярно проверяйте политики организации, метки и бюджеты на предмет отклонений от целевого состояния.

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

Компания Contoso Retail работает в Северной Америке и Европе. Пользователи и сервисы в основном работают в регионах us-east1 и europe-west1. Служба безопасности требует, чтобы маршрут по умолчанию вел на сторонний NGFW, у ВМ не было внешних IP-адресов, а подключение к локальной инфраструктуре было централизованным. Компании также требуется четкое распределение затрат по отделам и автоматизированные защитные механизмы (guardrails).

Настроить управление и топологию

Создайте хост-проект Shared VPC с одной сетью VPC и двумя региональными подсетями в us-east1 и europe-west1. Обоснование: Одна VPC с региональными подсетями обеспечивает прямую связь по RFC1918 между регионами с простой маршрутизацией и политиками, минимизируя накладные расходы на каждый проект.
Предоставьте доступ только к необходимым подсетям трем сервисным проектам (Marketing, Supply, Finance). Обоснование: Предоставление доступа на уровне подсетей ограничивает видимость маршрутов и правил брандмауэра, сохраняя при этом централизованный контроль.
Создайте отдельную VPC для устаревшей системы отдела финансов, которую необходимо изолировать; настройте пиринг только с проектами маркетинга и снабжения, где это необходимо. Обоснование: VPC-пиринг обеспечивает приватное подключение с низкой задержкой для двух отделов, сохраняя при этом изоляцию от системы финансов.

Настроить безопасный доступ к сервисам Google без публичных IP-адресов

Включите Private Google Access для всех общих подсетей. Обоснование: Экземпляры без внешних IP-адресов могут получать доступ к Google API в частном порядке.
Поскольку маршрут по умолчанию ведет на NGFW, добавьте кастомный статический маршрут для 199.36.153.8/30 к интернет-шлюзу по умолчанию. Обоснование: Это гарантирует, что вызовы к Google API не будут проходить через брандмауэр (hairpinning), что снижает задержку и позволяет избежать единой точки отказа.

Централизовать подключение к локальной инфраструктуре

Разверните Dedicated Interconnect и VLAN attachments в хост-проекте Shared VPC, подключив их к Cloud Router в каждом регионе. Обоснование: Централизованное подключение снижает затраты и дублирование операционных задач; Cloud Router обеспечивает динамическую маршрутизацию для будущего роста.
Предоставьте роль Compute Network Admin сетевым операторам, а Security Admin — команде безопасности. Обоснование: Это обеспечивает принцип наименьших привилегий и разделение обязанностей; сетевые администраторы не могут изменять правила брандмауэра без одобрения службы безопасности.

Автоматизировать развертывание и защитные механизмы

Реализуйте модули Terraform для VPC, подсетей, маршрутизаторов, NAT, пиринга и политик брандмауэра. Храните состояние (state) удаленно с блокировкой; требуйте ревью pull-запросов с выводом terraform plan в CI. Обоснование: Повторяемые, версионируемые изменения с контролем отклонений (drift control) минимизируют сбои.
Добавьте политику OPA для блокировки пересекающихся CIDR-диапазонов и открытого входящего трафика с 0.0.0.0/0 на внутренние подсети. Обоснование: Предотвращает распространенные ошибки конфигурации на этапе ревью.
Используйте Cloud Scheduler для ежедневной публикации проверок квот в Pub/Sub; сервис Cloud Run вызывает Service Usage API для проверки запаса по адресам, правилам пересылки и подключениям interconnect. Обоснование: Позволяет избежать сбоев развертывания из-за исчерпания квот.

Оптимизировать затраты и точно их распределять

Применяйте метки env, dept и service ко всем сетевым ресурсам через Terraform. Экспортируйте данные биллинга в BigQuery и определите бюджеты для каждого отдела с оповещениями в Pub/Sub. Обоснование: Прозрачное распределение затрат и ранние предупреждения о всплесках позволяют принимать упреждающие меры.
Разместите публичные веб-ресурсы за глобальным балансировщиком нагрузки HTTP(S) и включите Cloud CDN. Обоснование: Улучшает задержку для пользователей по всему миру и сокращает исходящий трафик за счет отдачи кэшированного контента с пограничных узлов сети (edge).

Усилить возможности аудита и реагирования на инциденты

Направьте журналы Admin Activity и Firewall Rules Logging в центральный проект для логов с использованием CMEK. Обоснование: Защищенные от несанкционированного доступа записи об изменениях и свидетельства на уровне данных обеспечивают соответствие требованиям.
При подозрении на вредоносную активность клиентов разверните правило Cloud Armor в режиме предварительного просмотра (preview) на балансировщике нагрузки HTTP(S) и проанализируйте журналы перед его применением. Обоснование: Минимизирует неудобства для пользователей во время проверки эффективности мер по смягчению последствий.

Документировать и итерировать

Опубликуйте регламенты (runbooks) для подключения проекта к Shared VPC, создания VPC-пиринга между проектами маркетинга и снабжения, а также для настройки policy-based Cloud VPN для партнеров, у которых нет поддержки BGP. Обоснование: Стандартизированное выполнение сокращает среднее время восстановления (MTTR) и вариативность.
После каждого окна для внесения изменений собирайте метрики (время развертывания, ошибки, стоимость исходящего трафика $/ГБ, коэффициент попадания в кэш) и используйте их для улучшения модулей и политик. Обоснование: Постоянное улучшение встраивает надежность и контроль затрат в повседневные операции.

← Наблюдаемость сети · Все домены

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