Google PCNE: Приватное подключение к Google и управляемым сервисам — Руководство по подготовке

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

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

Обзор

Частное подключение к сервисам Google и управляемым сервисам охватывает шаблоны, которые позволяют рабочим нагрузкам взаимодействовать с API Google, управляемыми сетями Google и сервисами сторонних поставщиков без использования публичных IP-адресов. Цели — снизить риск утечки данных, упростить соблюдение нормативных требований и повысить предсказуемость, сохраняя трафик в частных сетях. Основные строительные блоки включают Private Google Access (и ограниченные конечные точки), Private Services Access (для предоставления частных IP-адресов управляемым сервисам Google), Private Service Connect (для публикации и использования частных сервисов по модели «производитель-потребитель», включая API Google), VPC Service Controls (создание периметра безопасности данных), Cloud NAT (частный исходящий трафик в публичный интернет) и настройку DNS для детерминированного выбора конечной точки.

Успех проектирования зависит от трех решений:

Какой механизм частного доступа соответствует модели сервиса и безопасности (PGA или PSC для API Google, PSA или PSC для управляемых или партнерских сервисов).
Как DNS должен разрешать имена сервисов в частные целевые адреса, не нарушая работу неподдерживаемых сервисов.
Как взаимодействуют маршрутизация и политики периметра, чтобы трафик оставался частным на всем пути при сбоях или изменениях.

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

Private Google Access, ограниченные конечные точки и выбор конечных точек

Private Google Access (PGA) позволяет ВМ и узлам GKE без внешних IP-адресов обращаться к API и сервисам Google, используя anycast VIP-адреса Google через шлюз интернета по умолчанию для VPC, а не через Cloud NAT. Он включается для каждой подсети.

Конечные точки:
- private.googleapis.com (199.36.153.8/30): полный набор API Google.
- restricted.googleapis.com (199.36.153.4/30): подмножество API, совместимых с VPC Service Controls. Используйте этот вариант, когда вы применяете периметры безопасности сервисов.
Подходы к настройке DNS:
- Сохранить публичные имена по умолчанию и разрешить клиентам доступ к публичному DNS. Это работает, если вы разрешаете исходящий трафик через Cloud NAT, но ослабляет контроль за утечкой данных.
- Переопределить конкретные имена хостов API в частной зоне Cloud DNS для googleapis.com с помощью записей CNAME, указывающих на restricted.googleapis.com (или private.googleapis.com), чтобы принудительно использовать частное разрешение имен для каждого сервиса. Пример: создайте частную зону googleapis.com и добавьте запись

undefined

CNAME restricted.googleapis.com.

Вопросы маршрутизации:
- PGA требует наличия маршрута к шлюзу интернета по умолчанию. Если вы отправляете трафик 0.0.0.0/0 на сторонний NGFW, добавьте явные хост-маршруты, чтобы VIP-адреса API Google использовали шлюз интернета по умолчанию:

undefined

Сценарий сбоя: если эти хост-маршруты отсутствуют, инстансы без внешних IP-адресов не смогут получить доступ к API, когда в качестве next-hop для 0.0.0.0/0 указан инстанс брандмауэра.
Конфигурация подсети:

undefined

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

restricted.googleapis.com снижает риск утечки данных, но некоторые API недоступны.
Трафик PGA обходит Cloud NAT, поэтому он не будет отображаться в логах NAT. Используйте VPC Flow Logs для подсети.

Для локальных клиентов вы можете предоставить частный доступ к API Google, анонсируя диапазоны 199.36.153.4/30 и/или 199.36.153.8/30 в локальную сеть через Cloud VPN/Interconnect с указанием шлюза интернета по умолчанию в VPC в качестве next hop, либо предоставляя доступ к конечным точкам PSC (см. ниже) и настраивая локальный DNS для их использования.

Private Services Access и Private Service Connect

Private Services Access (PSA) обеспечивает приватное IP-подключение к управляемым Google сетям производителей, в которых размещаются такие сервисы, как Cloud SQL (с приватным IP) и Memorystore. Вы выделяете диапазон RFC1918 в своей VPC для использования Google и устанавливаете пиринговое соединение с сетью производителя сервисов.

Схема настройки:
- Зарезервируйте диапазон адресов для VPC-пиринга:

undefined

Установите приватное соединение:

undefined

Выделите управляемый сервис с приватным IP.
Примечания по эксплуатации:
- Диапазон должен быть достаточно большим для всех инстансов и не должен пересекаться с существующими диапазонами.
- Пиринг не является транзитивным; трафик должен исходить из VPC, с которым установлен пиринг (локальная сеть может получить доступ через VPC, если это разрешено маршрутизацией).
- Изменение или сужение диапазона в дальнейшем приведет к сбоям; планируйте емкость заранее.

Private Service Connect (PSC) расширяет приватное подключение на:

Google API (потребитель создает эндпоинты с приватными IP-адресами в подсети, а DNS сопоставляет имена API с этими IP-адресами).
Партнерские и SaaS-сервисы, опубликованные через service attachments.
Ваши собственные сервисы, приватно опубликованные для других проектов или организаций через service attachments.

Модель производитель-потребитель:

Производитель публикует service attachment в регионе, который поддерживается внутренним балансировщиком нагрузки. Производитель может требовать списки разрешенных проектов/организаций потребителей и указывать квоты на подключения.
Потребитель создает эндпоинт PSC (правило пересылки) в том же регионе, нацеленный на service attachment производителя. Эндпоинт получает IP-адрес из выбранной подсети.

Ограничения и компромиссы при проектировании:

PSC является региональным; развертывайте его в каждом регионе близко к потребителям. Используйте политики DNS или взвешенные записи для направления ближайших клиентов и обеспечения отказоустойчивости.
Транзитивность через PSC отсутствует; потребители не могут выстраивать цепочки сервисов через эндпоинт.
IP-адрес источника не сохраняется сквозным образом через PSC; проектируйте средства контроля на стороне производителя с учетом этого (например, полагайтесь на идентификацию или авторизацию на уровне приложения).

Распространенные режимы отказа:

Сбои проверок работоспособности ILB производителя приводят к отказу в PSC-соединениях.
Эндпоинт потребителя создан в другом регионе, отличном от региона service attachment.
Политика запрета производителя или отсутствие проекта в списке разрешенных блокирует соединения.
DNS не указывает на IP-адрес эндпоинта, или пересекающиеся приватные зоны разрешаются в неверный пункт назначения.

VPC Service Controls, периметры, правила ingress/egress и сопоставление DNS

VPC Service Controls (VPC‑SC) определяют периметры безопасности вокруг управляемых Google ресурсов для предотвращения эксфильтрации данных. Внутри периметра запросы к защищенным сервисам должны исходить из проектов, входящих в область действия, и удовлетворять любым настроенным уровням доступа.

Периметры:
- Стандартные периметры защищают проекты, в которых хранятся данные (например, BigQuery, Cloud Storage).
- Мосты периметров (Perimeter bridges) разрешают ограниченное взаимодействие между в остальном изолированными периметрами.
- Правила для входящего трафика (Ingress rules) предоставляют определенный доступ из-за пределов периметра (например, из проектов CI/CD или мониторинга).
- Правила для исходящего трафика (Egress rules) ограничивают, какие внешние сервисы или проекты внутри Google Cloud могут быть вызваны.
Выбор эндпоинта:
- Используйте restricted.googleapis.com, чтобы ограничить вызовы API только VPC‑SC-совместимыми сервисами и избежать случайных вызовов публичных эндпоинтов, которые не поддерживают периметры.
- PSC для Google API предлагает более строгий контроль, удерживая трафик на приватных IP-адресах и обеспечивая региональную привязку, но все равно требует настройки периметра для авторизации.
DNS и именование:
- Реализуйте split‑horizon DNS с помощью приватных зон Cloud DNS, чтобы внутренние клиенты разрешали имена API в приватные цели.
- Предпочитайте записи для каждого сервиса или CNAME на restricted.googleapis.com вместо использования wildcard-записи для всего домена googleapis.com, что может нарушить работу сервисов, которые должны оставаться публичными.
- Для PSC публикуйте A-записи, указывающие на IP-адрес каждого эндпоинта. Используйте отдельные зоны для каждой среды, чтобы предотвратить случайное использование ресурсов из другой среды.

Подводные камни:

Использование Cloud NAT для доступа к публичному googleapis.com может обойти замысел VPC‑SC, если правила периметра явно не ограничивают исходящий трафик; используйте NAT в паре с restricted DNS или PSC.
Некоторые API имеют несколько имен хостов (например, эндпоинты JSON и XML); убедитесь, что ваше сопоставление DNS охватывает все имена, которые используют ваши клиенты.
Неправильная настройка периметра приводит к блокировке доступа (fail-closed); отслеживайте логи Access Transparency и VPC‑SC для обнаружения отказов.

← Cloud DNS · Все домены · Маршрутизация →

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