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

1. Введение

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

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

Цели этого руководства:

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

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

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

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

Ресурсы-настройка

1. Настройте ресурсы, как описано в разделе «Настройка ресурсов» базового руководства VPC Service Controls I.
2. Убедитесь, что у вас есть необходимые разрешения для администрирования Cloud Storage.
3. В этом уроке мы собираемся использовать CLI вместо облачной консоли. В одной из сред разработки настройте gcloud CLI:

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

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

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

Расходы

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

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

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

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

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

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

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 Cloud Storage обновлен, описав периметр.

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

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

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

5. Убедитесь, что API Cloud Storage защищен.

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

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

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

gcloud storage ls gs://BUCKET_NAME

Поскольку API Cloud Storage защищен в режиме пробного запуска, вы сможете составить список ресурсов, но в журналах аудита 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"

Этот фильтр покажет нам последнее нарушение в режиме пробного запуска, принадлежащее Cloud Storage. Вот пример того, как выглядит журнал, и мы можем проверить, что нарушение является выходным при попытке составить список содержимого в корзине, расположенной в 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 к облачному хранилищу приводит к нарушению контроля обслуживания VPC, мы усилим периметр с помощью новой конфигурации. Откройте Cloud Shell и установите периметр пробного запуска:

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

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

gcloud storage ls gs://BUCKET_NAME

Вместо списка объектов Storage мы получим нарушение VPC Service Control в интерфейсе командной строки VM:

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. Мы будем искать последний журнал ошибок. Поскольку вызов 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 Console перейдите к средству выбора проектов и выберите ProjectZ, затем перейдите в Compute Engine > VM Instances .
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 из CLI экземпляра виртуальной машины.

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

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

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

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 License.