Элементы управления сервисами VPC – Лаборатория кода BigQuery Protection I

1. Введение

В этом практическом занятии вы узнаете, как защитить API BigQuery с помощью VPC Service Controls . В начале занятия ни один API-сервис не защищен периметром сервиса, что позволяет выполнять запросы к общедоступным наборам данных, а результаты сохранять в таблице проекта. Запрос выполняется в одном проекте, а таблица (где сохраняются результаты) создается в другом проекте, имитируя ситуацию, когда данные могут храниться в одном проекте, но доступ к ним осуществляется через другой проект.

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

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

2. Настройка ресурсов и требования

Прежде чем начать

В этом практическом занятии мы предполагаем, что вы уже знаете:

• Основы выполнения запросов в BigQuery : вы можете ознакомиться с этим практическим примером , чтобы узнать, как выполнять запросы к набору данных Википедии в BigQuery.
• Как создать и управлять папкой
• Как создать проект в папке или переместить существующий проект в папку
• Как создать политику ограниченного доступа
• Как создать и настроить периметр обслуживания
• Как найти нарушения политики безопасности в журналах событий

Настраивать

Наша первоначальная конфигурация выглядит следующим образом:

Если вы прошли базовый курс по управлению службами VPC , вы можете повторно использовать те же проекты, папку и периметр службы.

• Организация Google Cloud.
• Папка в структуре организации. В рамках данного практического занятия мы будем называть её codelab-folder .
• Два проекта Google Cloud находятся в одной папке, codelab-folder . Для данного практического занятия мы будем называть их project-1 и project-2
  • Если папка и проекты еще не созданы, в консоли Google Cloud создайте папку в рамках организации и создайте два новых проекта в этой созданной папке.
• Необходимые разрешения:
  • Роли IAM для управления папками : назначаются на уровне папки.
  • Роли IAM для управления проектами : назначаются на уровне проекта.
  • Роли IAM, необходимые для настройки управления службами VPC : назначаются на уровне организации.
  • Роли IAM для управления BigQuery : назначаются на уровне проекта.
  • Роли IAM для управления экземпляром Compute Engine : назначаются на уровне проекта.
• Счет для выставления счетов по обоим проектам, project-2 и project-1 .

Для выполнения этого практического задания вы можете назначить себе следующие предопределенные роли: администратор папки и создатель проекта (на уровне папки), владелец (на уровне проекта), администратор BigQuery (на уровне проекта) и администратор Access Context Manager (на уровне организации); у вас будут необходимые роли для настройки ресурсов, необходимых для всего практического задания.

Создайте стандартный сервисный периметр.

В этом практическом занятии мы будем использовать стандартный проект защиты периметра обслуживания project-1 .

• Создайте обычный периметр , perimeter-1 , и добавьте project-1 .

В пределах периметра пока не следует ограничивать предоставление каких-либо услуг. Мы сделаем это позже.

Создание виртуальной машины Compute Engine

В этом практическом занятии мы будем использовать 1 экземпляр Compute Engine в project-2 , расположенный в us-central1 и использующий сеть VPC по умолчанию с именем default .

• Вы можете использовать документацию в качестве руководства для создания экземпляра Compute Engine из общедоступного образа .

Для этой практической работы мы будем использовать сеть VPC по умолчанию , названную default . Вы также можете использовать любую другую сеть, если она имеет хотя бы одну подсеть.

Расходы

Для использования облачных ресурсов/API необходимо включить оплату в консоли Google Cloud. Мы рекомендуем отключить используемые ресурсы, чтобы избежать дополнительных расходов после завершения этого практического занятия. Новые пользователи Google Cloud могут воспользоваться программой бесплатной пробной версии стоимостью 300 долларов США.

Ресурсы, требующие затрат, — это экземпляры BigQuery и Compute Engine. Вы можете оценить стоимость, используя калькулятор цен BigQuery и калькулятор цен Compute Engine .

3. Доступ к BigQuery без ограничений, накладываемых службами VPC.

Запрос к общедоступному набору данных и сохранение результатов в project-1

1. Чтобы проверить доступность API BigQuery, перейдите на страницу BigQuery Studio и откройте проекты project-2 и project-1 . Вы должны иметь возможность это сделать, поскольку, даже если project-1 находится в зоне действия сервиса, эта зона пока не защищает ни один сервис.
2. В project-2 выполните следующий запрос для обращения к общедоступному набору данных .

SELECT  name, SUM(number) AS total
FROM  `bigquery-public-data.usa_names.usa_1910_2013`
GROUP BY   name
ORDER BY total DESC
LIMIT 10;

После выполнения запроса к общедоступному набору данных (при этом оставаясь в project-2 ):

1. Нажмите «Сохранить результаты» и выберите таблицу BigQuery (см. скриншот ниже).
2. Выберите project-1 в качестве целевого проекта.
3. Назовите набор данных codelab_dataset . (Выберите «СОЗДАТЬ НОВЫЙ НАБОР ДАННЫХ» , если не используется существующий набор данных).
4. Назовите таблицу следующим образом: codelab-table .
5. Нажмите « Сохранить ».

Данные из общедоступного набора данных были успешно сохранены в project-1 в результате выполнения запроса из project-2 .

Запрос к набору данных сохранен в project-1 из project-2

Оставаясь в project-2 BigQuery Studio, выполните следующий запрос для выбора данных из:

• Проект: project-1
• Набор данных: codelab_dataset
• Таблица: codelab-table

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

Запрос должен выполниться успешно, поскольку ни project-2 , ни project-1 не ограничены использованием BigQuery. Доступ к BigQuery разрешен из любого места и из любого места при условии наличия у пользователя соответствующих разрешений IAM.

Эта диаграмма иллюстрирует процесс запроса данных из набора данных BigQuery, выполняемого субъектом. Каждый запрос BigQuery инициирует задание BigQuery, которое затем выполняет фактическую операцию — в данном сценарии — извлечение данных. Доступ субъекта демонстрируется с экземпляра Compute Engine и из интернета, при этом запросы выполняются из общедоступного набора данных и из отдельного проекта Google Cloud. Процесс запроса данных ( GetData ) проходит успешно, без блокировки со стороны VPC Service Controls.

4. Защита API BigQuery в проекте исходного набора данных.

Измените конфигурацию perimeter perimeter-1 и ограничьте доступ к сервису BigQuery API, а также к защищаемому ресурсу project-1 .

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

В project-2 выполните следующий запрос в BigQuery Studio, как и на предыдущем шаге:

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

Произойдёт нарушение правил VPC Service Controls RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER

Журнал аудита нарушений будет находиться в project-1 , поскольку именно там произошло нарушение, связанное с пересечением периметра. Журналы можно фильтровать по наблюдаемому уникальному идентификатору vpcServiceControlsUniqueId (замените VPC_SC_DENIAL_UNIQUE_ID на наблюдаемый уникальный идентификатор).

severity=ERROR
resource.type="audited_resource"
protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="[*VPC_SC_DENIAL_UNIQUE_ID*]"

Нарушение связано с нарушением egressViolations а именно:

• principalEmail : [учетная запись пользователя, выполняющего запрос]
• callerIp : [IP-адрес пользовательского агента, выполняющего запрос]

     "egressViolations": [
       {
         "targetResource": "projects/project-2",
         "sourceType": "Resource",
         "source": "projects/project-1",
         "servicePerimeter": "accessPolicies/REDACTED/servicePerimeters/perimeter-1",
         "targetResourcePermissions": [ "bigquery.jobs.create"]
       }      ],

5. Устранение ошибки при создании задания BigQuery.

Нарушение правил управления службами VPC связано с разрешением bigquery.jobs.create , установленным в качестве целевого разрешения из-за особенностей работы BigQuery. При использовании консоли Google Cloud (или инструмента командной строки bq ) для управления данными BigQuery, BigQuery создает задания, которые затем используются для выполнения необходимых действий. При этом первым событием является создание задания BigQuery .

На этой диаграмме показано, как субъект выполняет запрос из project-2 к набору данных в project-1 Операция создания задания BigQuery из проекта набора данных ( project-1 ) в проекте, из которого выполняется запрос ( project-2 ), завершается ошибкой нарушения исходящего трафика VPC Service Controls из-за защиты API BigQuery периметром службы perimeter-1 ). При наличии периметра невозможно инициировать запросы к API BigQuery из project-1 за пределы периметра или за пределы периметра в сторону защищаемого проекта, если это не разрешено конфигурациями периметра службы.

Нарушение правил выхода можно устранить, создав правило выхода, основанное на:

• Источник (FROM): а именно адрес электронной почты пользователя и контекст (например, IP-адрес вызывающего абонента, состояние устройства, местоположение и т. д.).
• Назначение (TO): а именно, целевой ресурс, услуга и метод или разрешение.

Для устранения выявленного нарушения исходящего трафика создайте правило исходящего трафика, разрешающее трафик к целевому ресурсу ( project-2 ) для учетной записи пользователя, выполняющей запрос ( [e-mail] ) в службе BigQuery, и обладающей разрешением на использование метода/правила bigquery.jobs.create .

Ожидаемое поведение настроенного правила исходящего трафика:

• ОТ | Идентификаторы: только указанному пользователю [e-mail] должно быть разрешено пересекать границу периметра.
• КОМУ | проектам: указанный идентификатор может пересекать границы периметра только в том случае, если пунктом назначения является указанный проект project-2 .
• КОМУ | Сервисы: указанный идентификатор может инициировать трафик за пределами периметра, в направлении указанного проекта, только если вызов API предназначен для указанного сервиса и метода. В противном случае, например, если они попытаются использовать другой сервис, защищенный периметром сервисов, операция будет заблокирована, поскольку другие сервисы не разрешены.

Проверьте исправление: Правило выхода

После того, как правило исходящего трафика будет настроено, выполните тот же запрос.

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

Произойдёт ещё одно нарушение, на этот раз нарушение NO_MATCHING_ACCESS_LEVEL . Новое нарушение отличается от первого по целевому проекту и методу.

Устранение одного нарушения правил управления службами VPC не означает, что других нарушений не возникнет. Новый вызов API с контекстом, отличным от разрешенного уже настроенной политикой, вызовет другое нарушение.

Новое нарушение представляет собой нарушение входящего трафика.

• principalEmail : [учетная запись пользователя, выполняющего запрос]
• callerIp : [IP-адрес пользовательского агента, выполняющего запрос]

ingressViolations: [
0: {
 servicePerimeter: "accessPolicies/REDACTED/servicePerimeters/perimeter-1"
 targetResource: "projects/project-1"
 targetResourcePermissions: [0: "bigquery.tables.getData"]}
 ]

Нарушение в методе bigquery.tables.getData вызвано вызовом API, инициированным заданием BigQuery, которое пытается получить данные из таблицы BigQuery.

Важно понимать, как работает тот или иной API-сервис, чтобы предвидеть возможные нарушения.

6. Исправление ошибки при получении данных из таблицы BigQuery

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

Нарушение правил входящего трафика устраняется с помощью правила входящего трафика, которое настроено следующим образом:

• Источник (FROM): а именно адрес электронной почты пользователя и контекст (например, IP-адрес вызывающего абонента, состояние устройства, местоположение и т. д.).
• Назначение (TO): а именно, целевой ресурс, услуга и метод или разрешение.

Правило входящего трафика разрешит трафик к project-1 от указанного пользователя по указанному сервису и методу.

Ожидаемое поведение настроенного правила входящего трафика:

• ОТ | Идентификаторы: только указанному пользователю [e-mail] должно быть разрешено пересекать границу периметра.
• TO | проекты: указанный идентификатор может пересекать границы периметра только в том случае, если пунктом назначения является указанный проект project-1 .
• КОМУ | Сервисы: указанное удостоверение может инициировать трафик внутри периметра только в том случае, если вызов API предназначен для API BigQuery и указанного метода bigquery.tables.getData .

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

Нам удалось успешно ограничить использование API BigQuery в project-1 таким образом, что им может пользоваться только пользователь [e-mail] , а не [e-mail] .

Эта диаграмма иллюстрирует, как два разных пользователя пытаются запросить один и тот же набор данных. Доступ пользователя [e-mail] (пунктирные синие линии) запрещен настройками VPC Service Controls, поскольку конфигурация периметра обслуживания не позволяет ему выполнять операции BigQuery из project-1 или в направлении к нему. Доступ пользователя [e-mail] (зеленая сплошная линия) успешен, поскольку конфигурациями VPC Service Controls ему разрешено выполнять операции из project-1 и в направлении к нему.

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

Текущая конфигурация позволяет назначенному пользователю выполнять запросы к BigQuery в project-1 из любого места; из любой точки интернета, если ему предоставлены разрешения IAM на запрос данных и при условии использования его учетной записи. С точки зрения безопасности это означает, что в случае взлома учетной записи любой, кто получит к ней доступ, сможет получить доступ к данным BigQuery без каких-либо дополнительных ограничений.

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

Создание уровня доступа с условием доступа по внутреннему IP-адресу.

В той же папке с политикой доступа откройте страницу «Диспетчер контекста доступа» , чтобы создать уровень доступа .

1. На странице «Диспетчер контекста доступа» выберите «СОЗДАТЬ УРОВЕНЬ ДОСТУПА» .
2. В панели «Новый уровень доступа»:
   1. Укажите заголовок : можно использовать codelab-al .
   2. В разделе «Условия» нажмите «IP-подсети» .
   3. Выберите вкладку «Частный IP-адрес» и нажмите «Выбрать сети VPC» .
   4. В панели «Добавить сети VPC» вы можете либо найти сеть default , либо вручную ввести полное имя сети в формате //compute.googleapis.com/projects/project-2/global/networks/default .
   5. Нажмите «Добавить сеть VPC» .
   6. Нажмите ВЫБРАТЬ IP-ПОДСЕТИ .
   7. Выберите регион, в котором находится экземпляр виртуальной машины. Для данного практического задания это us-central1 .
   8. Нажмите СОХРАНИТЬ .

Мы создали уровень доступа, который, однако, пока не применяется ни к каким политикам доступа по периметру или въезда/выезда.

Добавьте уровень доступа к правилу входящего трафика.

Для того чтобы гарантировать, что пользователь, которому разрешено действие правила входящего трафика, также проверяется на соответствие уровню доступа, необходимо настроить уровень доступа в правиле входящего трафика. Правило входящего трафика, разрешающее доступ к данным запроса, находится в perimeter-1 . Измените правило входящего трафика, чтобы определить источник как уровень доступа codelab-al .

Тестирование новых конфигураций

После добавления уровня доступа в правило входящего трафика тот же запрос BigQuery завершится с ошибкой, если его не выполнить с клиентского компьютера в сети VPC default для проекта project-2 . Чтобы проверить это поведение, выполните запрос из консоли Google Cloud, когда конечное устройство подключено к интернету. Запрос завершится неудачей, сопровождаясь сообщением о нарушении правил входящего трафика.

По умолчанию:

• Область доступа экземпляра Compute Engine по умолчанию устанавливается на значение «доступ по умолчанию» , что не позволяет получить доступ к API BigQuery.
• К экземпляру Compute Engine будет привязана учетная запись службы Compute Engine по умолчанию . При этом все команды, выполняемые с виртуальной машины, будут запускаться от имени этой учетной записи службы, которая должна иметь формат [e-mail] .
  Можно изменить как область доступа, так и учетную запись службы, привязанную к виртуальной машине.

Тот же запрос можно выполнить из сети VPC default , расположенной в project-2 Аналогично, выполнение того же запроса BigQuery из экземпляра Compute Engine, расположенного в project-2 и использующего сеть VPC default также завершится ошибкой. Это связано с тем, что правило входящего трафика по-прежнему настроено таким образом, чтобы разрешать доступ только пользователю [e-mail] . Однако виртуальная машина использует учетную запись службы Compute Engine по умолчанию.

Для успешного выполнения той же команды из экземпляра Compute Engine в project-2 убедитесь в следующем:

• Виртуальная машина имеет права доступа к API BigQuery. Это можно сделать, выбрав в качестве области доступа виртуальной машины «Разрешить полный доступ ко всем облачным API» .
• Для доступа к виртуальной машине учетной записи службы, подключенной к ней, необходимы следующие разрешения IAM:
  • Создание заданий BigQuery в project-2
  • Получите данные BigQuery из таблицы BigQuery, расположенной в project-1
• Для корректного ввода и вывода данных необходимо разрешить использование учетной записи службы Compute Engine по умолчанию.

Теперь нам нужно добавить учетную запись службы Compute Engine по умолчанию в правила входящего трафика (чтобы разрешить получение данных из таблицы BigQuery) и в правило исходящего трафика (чтобы разрешить создание заданий BigQuery).

На экземпляре Compute Engine в project-2 расположенном в сети VPC default , выполните следующую команду bq query :

bq query --nouse_legacy_sql \
'SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;'

При текущей конфигурации команда BigQuery будет выполнена успешно только в том случае, если:

• запустить на виртуальной машине, используя сеть VPC по умолчанию в project-2 , и
• расположен в указанном регионе us-central1 (подсеть IP) и
• Запуск с использованием учетной записи службы Compute Engine по умолчанию, настроенной в периметре обслуживания.

Команда BigQuery завершится ошибкой, если её запустить из любого другого места, включая:

• если запущено на виртуальной машине с использованием сети VPC по умолчанию в project-2 , но расположенной в другом регионе, чем подсеть, добавленная в уровень доступа, или
• если запущено пользователем [e-mail] с использованием пользовательского клиента в интернете.

На этой диаграмме показан доступ, инициированный одним и тем же пользователем, [e-mail] , из двух разных мест: интернета и экземпляра Compute Engine. Доступ к BigQuery напрямую из интернета (синие пунктирные линии) блокируется средствами управления службами VPC, в то время как доступ с виртуальной машины (зеленые сплошные линии) — с использованием учетной записи службы Compute Engine по умолчанию — разрешен. Разрешенный доступ обусловлен тем, что периметр службы настроен таким образом, чтобы разрешать доступ к защищенным ресурсам с внутреннего IP-адреса.

8. Уборка

Хотя за использование VPC Service Controls, когда сервис не используется, отдельная плата не взимается, рекомендуется очистить конфигурацию, используемую в этой лабораторной работе. Вы также можете удалить экземпляр виртуальной машины и наборы данных BigQuery или проекты Google Cloud, чтобы избежать дополнительных расходов. Удаление проекта Cloud прекращает выставление счетов за все ресурсы, используемые в этом проекте.

• Для удаления экземпляра виртуальной машины выполните следующие действия:
  • В консоли Google Cloud перейдите на страницу «Экземпляры виртуальных машин» .
  • Установите флажок слева от имени экземпляра виртуальной машины, затем выберите «Удалить» и снова нажмите «Удалить» для подтверждения.
• Для удаления зоны обслуживания выполните следующие действия:
  • В консоли Google Cloud выберите «Безопасность» , а затем «Управление службами VPC» на уровне, к которому применяется политика доступа, в данном случае — на уровне папки.
  • На странице «Управление службами VPC» в строке таблицы, соответствующей периметру, который вы хотите удалить, нажмите кнопку «Удалить» .
• Чтобы удалить уровень доступа , выполните следующие действия:
  • В консоли Google Cloud откройте страницу «Менеджер контекста доступа» в области папок.
  • В таблице найдите строку с уровнем доступа, который вы хотите удалить, выберите меню с тремя точками , а затем выберите «Удалить» .
• Для завершения проектов выполните следующие шаги:
  • В консоли Google Cloud перейдите на страницу «Настройки IAM и администрирования» проекта, который вы хотите удалить.
  • На странице «Настройки IAM и администрирования» выберите «Завершение работы» .
  • Введите идентификатор проекта и выберите «В любом случае завершить работу» .

9. Поздравляем!

В этом практическом задании вы создали периметр управления службами VPC, обеспечили его соблюдение и устранили неполадки.

Узнать больше

Вы также можете рассмотреть следующие сценарии:

• Выполните тот же запрос к общедоступному набору данных после того, как проект будет защищен с помощью VPC Service Controls.
• Добавьте project-2 в том же периметре, что и project-1 .
• Добавьте project-2 в отдельный периметр, а project-1 оставьте в пределах текущего периметра.
• Выполняйте запросы для обновления данных в таблице, а не только для их извлечения.

Лицензия

Данная работа распространяется под лицензией Creative Commons Attribution 2.0 Generic.