Перейти к содержимому

Обзор

Сервис IAM (Identity and Access Management) позволяет организовать доступ к ресурсам таким образом, что операции над ресурсами могут выполнять только пользователи с необходимыми правами доступа.

При любой операции, подразумевающей доступ к ресурсу, есть субъект и объект доступа.

Для управления доступом IAM использует политику Role-Based Access Management (RBAC): возможность доступа к объекту определяется ролью, которая назначена субъекту.

Роль — это фиксированный набор разрешений. В IAM предусмотрены базовые роли viewer, editor, admin, а также сервисные роли. Роль назначается аккаунту в рамках определенной области видимости, то есть действие роли ограничивается этой областью видимости.

Область видимости (scope) — это ограниченная область, в пределах которой применяются разрешения, предусмотренные ролью. В ролевой модели IAM действуют области видимости на уровнях:

  • организации,
  • каталога,
  • проекта,
  • ресурса.

Пример:
Если аккаунту назначена роль admin:

  • на ресурс — аккаунт может управлять только этим ресурсом;
  • на проект — аккаунт может управлять проектом и всеми ресурсами проекта;
  • на каталог — аккаунт может управлять каталогом, всеми вложенными каталогами, проектами и их ресурсами;
  • на организацию — аккаунт может управлять всеми каталогами, проектами и ресурсами организации.

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

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

В IAM существует наследование прав доступа от родительской области видимости к дочерней:

  • организация → каталоги, проекты, ресурсы;
  • каталог → вложенные каталоги, проекты, ресурсы;
  • проект → ресурсы.

Пример:
У аккаунта отсутствуют роли editor или admin на проекте. Если аккаунту назначить роль storage.bucket.admin, то:

  • аккаунт сможет управлять всеми ресурсами Object Storage в проекте;
  • не сможет управлять другими ресурсами проекта.

Пример:
У аккаунта есть назначенные роли editor на проект и admin на ресурс. Если отозвать роль admin на ресурс, то аккаунт все равно сможет редактировать этот ресурс, так как все ресурсы наследуют роль editor от проекта.

  1. Перед выполнением любой операции с ресурсом сервис IAM проверяет, разрешена ли эта операция для пользователя.
  2. Если роль, назначенная пользователю, предусматривает разрешение на выполнение этой операции, то IAM не блокирует выполнение операции; в противном случае выводится ошибка.

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

  • Пользовательские и федеративные аккаунты — учетные записи реальных пользователей, которые зарегистрировались в MWS. Пользовательские и федеративные аккаунты различаются способом аутентификации.
  • Сервисный аккаунт — учетная запись, создаваемая пользователем для программного взаимодействия. Используется приложениями, скриптами (например, AWS CLI, SDK и т.п.), а также сервисами для выполнения операций от их имени. Пользователь может управлять сервисным аккаунтом и изменять его набор прав. Подробнее о сервисных аккаунтах
  • Сервисный агент — служебная учетная запись, которая создается автоматически при активации конкретного сервиса и позволяет ему взаимодействовать с другими сервисами. Пользователь не может создать или удалить сервисный агент, но может изменить его набор прав. Подробнее о сервисных агентах.

Сервис IAM доступен в проекте по умолчанию и не требует активации.