Рекомендации по делегированию полномочий в масштабе всего домена

Как администратор, вы можете использовать делегирование на уровне домена, чтобы разрешить внутренним и сторонним приложениям доступ к данным Google Workspace ваших пользователей, минуя согласие конечного пользователя. Для этого создайте учетную запись службы в консоли Google Cloud и делегируйте этой учетной записи полномочия на уровне домена в консоли администратора Google. Вы также можете предоставить учетной записи службы ограниченные области действия API в консоли администратора. Для получения дополнительной информации о делегировании на уровне домена перейдите к разделу «Управление доступом к API с помощью делегирования на уровне домена» .

Управление и обеспечение безопасности учетных записей пользователей.

Управление идентификацией и доступом (IAM) предоставляет рекомендации по использованию служебных учетных записей для ограничения доступа и защиты от повышения привилегий и угроз, связанных с невозможностью отказа от авторства. Для ознакомления с рекомендациями перейдите в раздел «Рекомендации по использованию служебных учетных записей» .

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

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

Избегайте использования делегирования в масштабах всего домена, если вы можете выполнить свою задачу напрямую, используя учетную запись службы или согласие OAuth.

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

Избегайте использования делегирования в масштабах всего домена.

Ограничить создание и загрузку ключей учетных записей служб.

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

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

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

Сервисным учетным записям, создаваемым по умолчанию, присваивается роль «Редактор», которая позволяет учетной записи читать и изменять все ресурсы в проекте Google Cloud. Вы можете отключить автоматическое присвоение ролей сервисным учетным записям по умолчанию, чтобы гарантировать, что они не будут автоматически получать роль «Редактор» и их будет сложно использовать злоумышленниками.

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

Ограничьте боковые движения.

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

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

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

Не позволяйте пользователю изменять политику разрешений для учетной записи службы, если у этой учетной записи службы больше привилегий, чем у пользователя. Используйте роли IAM для ограничения доступа к учетным записям служб с делегированием прав в масштабе всего домена.

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

Защитите учетные записи пользователей от внутренних рисков.

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

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

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

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

Размещайте сервисные учетные записи в выделенных проектах Google Cloud.

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

Избегайте использования ключей учетных записей служб.

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

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

Ограничить доступ к проектам, имеющим делегирование полномочий в рамках всего домена.

Сведите к минимуму количество пользователей, имеющих доступ на редактирование проектов Google Cloud, настроив делегирование на уровне домена. Вы можете использовать API Cloud Asset Inventory, чтобы узнать, кто имеет доступ к учетным записям служб. Например, используйте 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 owner и editor.

Разберитесь, кто имеет доступ к учетным записям сервисов Google Cloud.