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

1. Введение

В этой лабораторной работе вы узнаете, как защитить BigQuery API с помощью 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 (на уровне проекта) и администратор диспетчера контекста доступа (на уровне организации); и у вас будут необходимые роли для настройки ресурсов, необходимых для всей этой лаборатории кода.

Создайте регулярный периметр обслуживания

В этой кодовой лаборатории мы будем использовать обычный сервисный периметр, защищающий 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. Откройте project-2 и project-1 , чтобы проверить, можете ли вы получить доступ к BigQuery API, посетив страницу BigQuery Studio . У вас должна быть возможность это сделать, потому что даже если 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.

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

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

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

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

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

Произойдет нарушение правил управления службами VPC 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 из-за perimeter-1 защищающего BigQuery API. При наличии периметра запросы BigQuery API не могут быть инициированы из project-1 за пределы периметра или инициированы за пределами периметра в сторону защищенного проекта; если это не разрешено конфигурациями периметра службы.

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

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

Чтобы исправить наблюдаемое выходное нарушение, создайте выходное правило, которое разрешает трафик в направлении targetResource ( 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 Service Controls не означает, что других нарушений не произойдет. Новый вызов 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] должно быть разрешено пересекать границу периметра.
• ТО | проекты: указанный идентификатор может пересекать границы периметра, только если местом назначения является указанный проект project-1 .
• ТО | Службы: указанный идентификатор может инициировать трафик внутри периметра, только если вызов API предназначен для API BigQuery и указанного метода bigquery.tables.getData .

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

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

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

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

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

Дополнительные ограничения могут быть реализованы путем использования уровня доступа в правилах входа и выхода для указания контекста пользователя. Например, вы можете разрешить доступ на основе IP-адреса источника в сочетании с ранее настроенным правилом входящего трафика, которое разрешает доступ по идентификатору вызывающего абонента. Доступ по исходному IP-адресу возможен для обоих диапазонов общедоступных IP-адресов CIDR при условии, что пользовательскому клиенту присвоен общедоступный 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 используется доступ по умолчанию , который не разрешает доступ к BigQuery API.
• К экземпляру 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 , убедитесь, что:

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

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

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

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 не взимается отдельная плата, когда служба не используется, рекомендуется очистить настройку, используемую в этой лаборатории. Вы также можете удалить экземпляр виртуальной машины и наборы данных BigQuery или проекты Google Cloud, чтобы избежать дополнительных расходов. При удалении облачного проекта прекращается выставление счетов за все ресурсы, используемые в этом проекте.

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

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

В этой лабораторной работе вы создали периметр VPC Service Controls, внедрили его и устранили неполадки.

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

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

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

Лицензия

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