Рекомендации по делегированию доступа к данным в домене

Как администратор, вы можете делегировать доступ к данным в домене, чтобы внутренние и сторонние приложения могли получать доступ к данным Google Workspace сотрудников без их согласия. Для этого нужно создать сервисный аккаунт в консоли Google Cloud и делегировать ему права на уровне домена в консоли администратора Google. В ней также можно предоставить ему ограниченные области действия API. Подробнее о том, как управлять доступом к API, используя делегирование доступа к данным в домене…

Как управлять сервисными аккаунтами и защитить их

Продукт Identity and Access Management (IAM) содержит рекомендации по использованию сервисных аккаунтов для ограничения доступа и защиты от повышения привилегий и угроз неотказуемости. Подробнее…

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

	Используйте прямой доступ к сервисному аккаунту или запрос доступа OAuth Не используйте делегирование доступа к данным в домене, если вы можете выполнить задачу напрямую с помощью сервисного аккаунта или запроса доступа OAuth. Если альтернативы делегированию доступа к данным в домене нет, ограничьте набор областей действия OAuth, которые может использовать сервисный аккаунт. Хотя области действия OAuth не ограничивают круг пользователей, от имени которых может действовать сервисный аккаунт, с их помощью можно ограничить типы данных, к которым у сервисного аккаунта есть доступ. Если возможно, не используйте делегирование доступа к данным в домене
	Запретите создание и загрузку ключей сервисных аккаунтов Настройте политики организации таким образом, чтобы запретить создание и загрузку ключей для сервисных аккаунтов, которым делегирован доступ к данным в домене. Это ограничит возможность выполнения действий от имени сервисных аккаунтов с помощью их ключей. Запретите пользователям создавать и загружать ключи сервисных аккаунтов
	Отключите автоматическое предоставление ролей для сервисных аккаунтов по умолчанию Сервисным аккаунтам, созданным по умолчанию, предоставляется роль "Редактор" с правом на просмотр и изменение всех ресурсов в проекте Google Cloud. Вы можете отключить автоматическое предоставление ролей для сервисных аккаунтов по умолчанию, чтобы они не получали роль "Редактор" автоматически. Это затруднит использование таких аккаунтов злоумышленниками. Не используйте автоматическое предоставление ролей для сервисных аккаунтов по умолчанию
	Ограничьте горизонтальное перемещение Горизонтальное перемещение – право сервисного аккаунта в одном проекте действовать от имени сервисного аккаунта в другом проекте. При этом может возникнуть риск несанкционированного доступа к ресурсам. Используйте отчеты о горизонтальном перемещении, чтобы обнаружить и ограничить такие возможности. Используйте отчеты о горизонтальном перемещении, чтобы ограничить горизонтальное перемещение
	Ограничьте доступ к сервисным аккаунтам, которым делегирован доступ к данным в домене Не допускайте, чтобы пользователь мог менять правила разрешений для сервисного аккаунта, если у этого аккаунта больше прав доступа, чем у пользователя. Ограничьте доступ к сервисным аккаунтам, которым делегирован доступ к данным в домене, с помощью ролей IAM. Запретите пользователям менять правила разрешений для сервисных аккаунтов, у которых больше прав доступа, чем у этих пользователей

Защитите сервисные аккаунты от внутренних угроз

Используйте делегирование доступа к данным в домене, только если крайне необходимо, чтобы приложение могло получить доступ к данным Google Workspace без согласия пользователя. В остальных случаях старайтесь использовать альтернативные решения, например OAuth с согласием пользователя или приложения из каталога Marketplace. Подробную информацию можно найти в Google Workspace Marketplace.

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

	Предоставляйте минимальный необходимый набор прав Убедитесь, что у сервисных аккаунтов, которым делегирован доступ к данным в домене, есть только те права, которые необходимы для выполнения функций, для которых они были созданы. Не предоставляйте доступ к областям действия OAuth, которые не являются необходимыми.
	Размещайте сервисные аккаунты в специальных проектах Google Cloud Убедитесь, что сервисные аккаунты, которым делегирован доступ к данным в домене, размещены в отдельных проектах Google Cloud. Не используйте эти проекты для других целей.
	Не используйте ключи сервисных аккаунтов Использовать ключи сервисных аккаунтов для делегирования доступа к данным в домене не обязательно. Вместо них пользуйтесь signJwt API. Не используйте ключи сервисных аккаунтов для делегирования доступа к данным в домене
	Ограничьте доступ к проектам с делегированием данных в домене Предоставьте право на редактирование проектов Google Cloud с делегированием данных в домене минимальному необходимому количеству пользователей. Узнать, у кого есть доступ к сервисным аккаунтам, можно с помощью Cloud Asset Inventory API. Например, используйте Cloud Shell, чтобы выполнить следующую команду: gcloud asset get-effective-iam-policy --scope=organizations/<ORG_ID> --names=//iam.googleapis.com/projects/<PROJECT_ID>/serviceAccounts/ <SERVICE_ACCOUNT_ID> ORG_ID – идентификатор вашей организации Google Cloud. Подробнее… PROJECT_ID – идентификатор проекта Google Cloud, в котором находится сервисный аккаунт. Подробнее… SERVICE_ACCOUNT_ID – идентификатор сервисного аккаунта. Он указан в консоли администратора в разделе "Идентификатор клиента" на странице делегирования доступа к данным в домене или в адресе электронной почты сервисного аккаунта. Подробнее… Обратите внимание на разрешения или роли владельца и редактора, например iam.serviceAccountTokenCreator или iam.serviceAccountKeyAdmin, чтобы понять, у кого есть прямые или унаследованные права на использование сервисного аккаунта. Определите, у кого есть доступ к сервисным аккаунтам Google Cloud

Статьи по теме

• Рекомендации по обеспечению безопасности
• Cloud Shell
• Как управлять доступом к API, используя делегирование доступа к данным в домене