Базовое руководство по управлению службами VPC II. Устранение нарушений исходящего трафика

1. Введение

VPC Service Controls (VPC-SC) — это средство контроля безопасности на уровне организации в Google Cloud, позволяющее корпоративным клиентам снижать риски утечки данных. VPC Service Controls обеспечивает доступ в стиле «нулевого доверия» к многопользовательским сервисам, позволяя клиентам ограничивать доступ к авторизованным IP-адресам, контексту клиента и параметрам устройства при подключении к многопользовательским сервисам из интернета и других сервисов, чтобы уменьшить как преднамеренные, так и непреднамеренные потери. Как мы видели в базовом руководстве по VPC Service Controls I , вы можете использовать VPC Service Controls для создания периметров, защищающих ресурсы и данные сервисов, которые вы явно указываете.

Если вы еще не прошли базовый курс по управлению службами VPC (VPC Service Controls Basic Tutorial I) , начните с него, чтобы выполнить необходимую предварительную настройку для этого курса.

Цели данного учебного пособия:

• Разберитесь в основах управления службами VPC.
• Обновите периметр обслуживания и протестируйте его в режиме пробного запуска.
• Защитите два сервиса с помощью VPC Service Controls.
• Устранение ошибки нарушения исходящего трафика в настройках VPC Service Controls при отображении объекта из Cloud Storage.

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

Для выполнения этого урока нам необходимы следующие предварительные условия:

• Организация GCP.
• Папка в разделе «Организация».
• В одной и той же организации в папке размещены 2 проекта GCP.
• Необходимые разрешения на уровне организации.
• Счет для выставления счетов по обоим проектам.
• Базовое руководство по управлению службами VPC. Настройка управления службами VPC и диспетчера контекста доступа.

Настройка ресурсов

1. Настройте ресурсы, как описано в разделе «Настройка ресурсов» базового руководства по управлению службами VPC (версия I).
2. Убедитесь, что у вас есть необходимые права для администрирования облачного хранилища.
3. В этом руководстве мы начнём использовать CLI вместо облачной консоли. В одной из сред разработки настройте CLI gcloud:

• Cloud Shell : чтобы использовать онлайн-терминал с уже настроенным интерфейсом командной строки gcloud, активируйте Cloud Shell.

Активируйте Cloud Shell, щелкнув значок в правом верхнем углу консоли облака. Инициализация сессии может занять несколько секунд. Более подробную информацию см. в руководстве по Cloud Shell .

• Локальная оболочка : для использования локальной среды разработки установите и инициализируйте интерфейс командной строки gcloud.

Расходы

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

Единственными ресурсами, которые будут оплачиваться, являются экземпляр виртуальной машины и объект облачного хранилища. Ориентировочную стоимость экземпляра виртуальной машины можно найти в калькуляторе цен . Ориентировочную стоимость облачного хранилища можно найти в этом прайс-листе .

3. Создайте корзину хранения и объект.

Как уже упоминалось ранее, мы будем повторно использовать ресурсы, созданные в предыдущем уроке . Поэтому мы продолжим создание сегмента Cloud Storage. В этом уроке мы начнем использовать CLI gcloud вместо консоли.

1. В консоли Google выберите ProjectX. В этом проекте мы будем создавать хранилище (Storage Bucket) и объект (объект).
2. Убедитесь, что в облачной оболочке установлен режим использования ProjectX, выполнив следующую команду:

gcloud config set project PROJECT_ID

3. В среде разработки выполните следующую команду:

gcloud storage buckets create gs://BUCKET_NAME --location=us-central1

Названия ведер уникальны во всем мире. Ознакомьтесь с этим документом , чтобы узнать больше о том, как назвать свое ведро.

4. Создайте объект хранилища, чтобы мы могли считывать его из экземпляра виртуальной машины, расположенного в ProjectZ. Мы создадим текстовый файл (.txt).

nano hello.txt 

В текстовый файл можно добавить всё, что угодно.

5. Загрузите объект в хранилище.

gcloud storage cp /home/${USER}/hello.txt gs://BUCKET_NAME

6. Убедитесь, что объект загружен в хранилище, выведя его список .

gcloud storage ls gs://BUCKET_NAME

В консоли должен отображаться файл hello.txt.

4. Защита API облачного хранилища

В предыдущем практическом занятии мы создали периметр и защитили API Compute Engine. В этом занятии мы отредактируем наш периметр в режиме тестового запуска и добавим Cloud Storage. Это поможет нам определить влияние защиты периметра, показав нарушения VPC Service Controls в журналах аудита, но ресурсы останутся доступными до тех пор, пока мы не обеспечим защиту периметра.

При создании обычного периметра автоматически создается и пробный периметр. Именно его мы будем редактировать в этой лабораторной работе.

1. В консоли Google выберите свою организацию; перейдите в раздел «Управление службами VPC» . Убедитесь, что вы находитесь в области действия организации.
2. Откройте Cloud Shell и обновите периметр "SuperProtection" для пробного запуска, созданный в предыдущей лабораторной работе:

gcloud access-context-manager perimeters dry-run update SuperProtection --policy=POLICY --add-restricted-services=storage.googleapis.com

3. Убедитесь, что API облачного хранилища обновлен, указав его параметры.

gcloud access-context-manager perimeters dry-run describe SuperProtection --policy=POLICY 

В выходных данных вы увидите, что API облачного хранилища указан ниже списка ограниченных сервисов.

вместе с API Compute Engine, но с меткой " -vpcAccessibleServices: {}" :

5. Убедитесь, что API облачного хранилища защищен.

В режиме пробного запуска убедитесь, что периметр "SuperProtection" отображает отказ, перечислив объекты из экземпляра виртуальной машины, созданного в ProjectZ, в ProjectX, на котором размещен сегмент хранилища.

1. В консоли Cloud перейдите к селектору проектов и выберите ProjectZ, затем перейдите в Compute Engine > Экземпляры виртуальных машин .
2. Нажмите кнопку SSH, чтобы подключиться к экземпляру виртуальной машины и получить доступ к ее командной строке.

3. Перечислите файл hello.txt, который мы загрузили ранее.

gcloud storage ls gs://BUCKET_NAME

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

4. Перейдите в API Logs Explorer в ProjectZ и найдите последнее сообщение об ошибке VPC Service Controls. Вы можете использовать этот фильтр, чтобы получить нужный нам лог:

protoPayload.status.details.violations.type="VPC_SERVICE_CONTROLS"
"(Dry Run Mode) Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier:UNIQUE_ID"

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

egressViolations: [
0: {
servicePerimeter: "accessPolicies/POLICY/servicePerimeters/SuperProtection"
source: "projects/PROJECTX_ID"
sourceType: "Network"
targetResource: "projects/PROJECTZ_ID"
}
]
resourceNames: [
0: "projects//buckets/BUCKET_NAME"
]
securityPolicyInfo: {
organizationId: "ORGANIZATION_ID"
servicePerimeterName: "accessPolicies/POLICY/servicePerimeters/SuperProtection"
}
violationReason: "NETWORK_NOT_IN_SAME_SERVICE_PERIMETER"
vpcServiceControlsUniqueId: "UNIQUE_ID"
}
methodName: "google.storage.objects.list"

5. Поскольку мы подтвердили, что вызов API к Cloud Storage приводит к нарушению правил управления службами VPC, мы применим новую конфигурацию для обеспечения безопасности периметра. Откройте Cloud Shell и выполните тестовый запуск периметра:

gcloud access-context-manager perimeters dry-run enforce SuperProtection --policy=POLICY --async

6. Подключитесь к экземпляру виртуальной машины по SSH и снова выведите список сегментов хранилища, чтобы убедиться, что периметр "тестового запуска" был применен корректно.

gcloud storage ls gs://BUCKET_NAME

Вместо списка объектов хранилища в командной строке виртуальной машины мы получим сообщение о нарушении управления службой VPC:

ERROR: (gcloud.storage.ls) User [[e-mail]] does not have permission to access b instance [BUCKET_NAME] (or it may not exist): Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier:"UNIQUE_ID"

Нам удалось успешно предотвратить утечку данных, используя средства контроля служб VPC, которые запрещают чтение данных из ресурсов за пределами периметра сети или их копирование в такие ресурсы.

6. Устранение неполадок, связанных с отказом в предоставлении списка рассылки.

Мы собираемся устранить ошибку, полученную от CLI экземпляра виртуальной машины. Давайте проверим журналы аудита и найдем уникальный идентификатор VPC Service Controls.

1. Перейдите в меню выбора проекта и выберите ProjectZ.
2. Найдите уникальный идентификатор элементов управления службой VPC в журналах аудита, используя следующий запрос в обозревателе журналов:

resource.type="audited_resource"
protoPayload.metadata."@type"="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"

Это отобразит все журналы аудита VPC Service Controls. Нам понадобится последний журнал ошибок. Поскольку вызов API был выполнен из экземпляра виртуальной машины, субъектом должна быть учетная запись службы Compute Engine " [e-mail]"

Поскольку у нас уже есть уникальный идентификатор VPC Service Controls, мы можем использовать его для получения нужного журнала напрямую, применив следующий фильтр:

protoPayload.metadata.vpcServiceControlsUniqueId="UNIQUE_ID"

3. Щелкните заголовок «Управление службами VPC» и выберите «Устранение неполадок, связанных с отказом», чтобы открыть средство устранения неполадок управления службами VPC.

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

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

authenticationInfo: {
principalEmail: "[e-mail]"
egressViolations: [
0: {
servicePerimeter: "accessPolicies/POLICY/servicePerimeters/SuperProtection"
source: "projects/PROJECTZ_ID"
sourceType: "Network"
targetResource: "projects/PROJECTX_ID"
}
violationReason: "NETWORK_NOT_IN_SAME_SERVICE_PERIMETER"

Этой информации достаточно, чтобы понять, что нам нужно создать правило исходящего трафика, позволяющее учетной записи службы Compute Engine получать доступ к хранилищу из ProjectZ в ProjectX. Также мы видим, что сети находятся не в одном периметре, поэтому нам нужно разрешить обмен данными между службами через VPC и совместное использование данных между периметрами служб.

4. Активируйте Cloud Shell и создайте файл .yaml с правилом исходящего трафика, используя текстовый редактор.

nano egresstorage.yaml 

- egressTo:
    operations:
    - serviceName: storage.googleapis.com
      methodSelectors:
      - method: \"*\"
    resources:
    - projects/PROJECTX_ID
 egressFrom:
    identities:
    - serviceAccount:[e-mail]

5. Обновите политику входящего трафика , которая защищает ProjectZ.

gcloud access-context-manager perimeters update SuperProtection --set-egress-policies=egresstorage.yaml --policy=POLICY 

Теперь мы можем снова попробовать получить доступ к хранилищу из экземпляра виртуальной машины.

1. В консоли Cloud перейдите к селектору проектов и выберите ProjectZ, затем перейдите в Compute Engine > Экземпляры виртуальных машин .
2. Нажмите кнопку SSH, чтобы подключиться к экземпляру виртуальной машины и получить доступ к ее командной строке.
3. После входа в командную строку виртуальной машины попробуйте вывести список объектов в сегменте хранения.

gcloud storage ls gs://BUCKET_NAME/

Вы получите следующее сообщение об ошибке:

ERROR: (gcloud.storage.ls) User [[e-mail]] does not have permission to access b instance [BUCKET_NAME] (or it may not exist): [e-mail] does not have storage.objects.list access to the Google Cloud Storage bucket. Permission 'storage.objects.list' denied on resource (or it may not exist).

4. Для того чтобы иметь возможность отображать список объектов в хранилище, необходимо предоставить учетной записи службы Compute Engine разрешение на чтение объектов .

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member=serviceAccount:[e-mail] --role=roles/storage.objectViewer

5. Давайте еще раз попробуем вывести содержимое файла hello.txt из командной строки виртуальной машины.

gcloud storage ls gs://BUCKET_NAME/
.
.
gs://BUCKET_NAME/hello.txt

Теперь мы можем вывести список объектов без нарушения прав доступа в настройках служб VPC, но как насчет загрузки файла? Давайте попробуем это.

gcloud storage cp gs://BUCKET_NAME/hello.txt /home/${USER}

В результате мы получим следующий результат.

Copying gs://BUCKET_NAME/hello.txt to file:///home/${USER}
 Completed files 1/1 | 54.0B/54.0B  

7. Уборка

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

1. Чтобы удалить экземпляр виртуальной машины, установите флажок слева от имени экземпляра виртуальной машины, а затем нажмите кнопку «Удалить» .

2. Для удаления периметра выполните следующие шаги:

• В консоли Google Cloud щелкните «Безопасность» , а затем в разделе «Организация» щелкните «Управление службами VPC» .
• На странице «Управление службами VPC» в строке таблицы, соответствующей периметру, который вы хотите удалить, нажмите кнопку «Удалить».

3. Для удаления уровня доступа выполните следующие действия:

• В консоли Google Cloud откройте страницу «Менеджер контекста доступа» в области папок.
• В таблице, в строке, соответствующей уровню доступа, который вы хотите удалить, нажмите значок «Удалить», а затем нажмите «Удалить» .

4. Для удаления объекта Storage и сегмента Bucket выполните следующие действия:

• В консоли Google Cloud откройте страницу «Корзины Cloud Storage» .
• Установите флажок рядом с созданным вами сегментом.
• Нажмите «Удалить» .
• В открывшемся окне подтвердите, что хотите удалить корзину.
• Нажмите «Удалить» .

5. Для завершения проекта выполните следующие действия:

• В консоли Google Cloud перейдите на страницу «Настройки IAM и администрирования» проекта, который вы хотите удалить.
• На странице «Настройки IAM и администрирования» нажмите «Выключить» .
• Введите идентификатор проекта и нажмите «Выключить в любом случае» .

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

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

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

• См. документацию по управлению службами VPC .
• См. документацию по менеджеру контекста доступа .
• См. документацию по устранению неполадок VPC-SC .
• См. документацию по правилам входа и выхода.
• См. документацию по пробному запуску.
• См. документацию по облачному хранилищу.

Лицензия

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