Управление доступом в Key Management Service
В этом разделе вы узнаете:
- на какие ресурсы можно назначить роль;
- какие роли действуют в сервисе;
- какие роли необходимы для того или иного действия.
Об управлении доступом
Все операции в Yandex Cloud проверяются в сервисе Yandex Identity and Access Management. Если у субъекта нет необходимых разрешений, сервис вернет ошибку.
Чтобы выдать разрешения к ресурсу, назначьте роли на этот ресурс субъекту, который будет выполнять операции. Роли можно назначить аккаунту на Яндексе, сервисному аккаунту, федеративным пользователям, группе пользователей или системной группе. Подробнее читайте в разделе Как устроено управление доступом в Yandex Cloud.
Назначать роли на ресурс могут те, у кого есть роль admin
, resource-manager.clouds.owner
или organization-manager.organizations.owner
на этот ресурс.
На какие ресурсы можно назначить роль
Как и в других сервисах, роль можно назначить на облако, каталог или сервисный аккаунт. Роли, назначенные на облако или каталог, действуют и на вложенные ресурсы.
В консоли управления, через YC CLI или API Yandex Cloud роль можно назначить на отдельные ресурсы сервиса:
- Симметричный ключ шифрования
- Асимметричный ключ шифрования
- Асимметричная ключевая пара электронной подписи
Какие роли действуют в сервисе
Управлять доступом к ключам KMS можно как с помощью сервисных, так и с помощью примитивных ролей.
На диаграмме показано, какие роли есть в сервисе и как они наследуют разрешения друг друга. Например, в editor
входят все разрешения viewer
. После диаграммы дано описание каждой роли.
Сервисные роли
Сервисные роли обеспечивают более гранулярный, учитывающий специфику сервиса, контроль над ключами KMS: предполагают строгое разделение субъектов на администраторов ключей (роль kms.admin
) и пользователей (роль kms.keys.encrypterDecrypter
).
Пользователи, у которых отсутствует роль resource-manager.clouds.owner
или роль admin
, не могут назначать роли через консоль управления.
kms.keys.encrypter
Роль kms.keys.encrypter
позволяет шифровать данные, а также просматривать информацию о ключах.
kms.keys.decrypter
Роль kms.keys.decrypter
позволяет расшифровывать данные, а также просматривать информацию о ключах.
kms.keys.encrypterDecrypter
Роль kms.keys.encrypterDecrypter
позволяет шифровать и расшифровывать данные, а также просматривать информацию о ключах. Включает все права ролей kms.keys.encrypter
и kms.keys.decrypter
.
kms.asymmetricEncryptionKeys.publicKeyViewer
Роль kms.asymmetricEncryptionKeys.publicKeyViewer
позволяет получать открытый ключ асимметричной ключевой пары шифрования.
kms.asymmetricSignatureKeys.publicKeyViewer
Роль kms.asymmetricSignatureKeys.publicKeyViewer
позволяет получать открытый ключ асимметричной ключевой пары подписи.
kms.asymmetricSignatureKeys.signer
Роль kms.asymmetricSignatureKeys.signer
позволяет подписывать данные с помощью закрытого ключа асимметричной ключевой пары подписи.
kms.asymmetricEncryptionKeys.decrypter
Роль kms.asymmetricEncryptionKeys.decrypter
позволяет расшифровывать данные с помощью закрытого ключа асимметричной ключевой пары шифрования.
kms.auditor
Роль kms.auditor
дает право просматривать список ключей подписи и шифрования и получать информацию о правах доступа к подписи и шифрованию. Роль не позволяет получить публичный ключ.
kms.viewer
Роль kms.viewer
позволяет читать информацию о ключах.
kms.editor
Роль kms.editor
позволяет управлять ключами (просмотр, создание, изменение, ротация, шифрование и расшифровка данных). Включает все права ролей kms.viewer
и kms.keys.encrypterDecrypter
.
kms.admin
Роль kms.admin
позволяет назначать произвольные роли на ключи с помощью CLI и API, удалять ключи и версии ключей, изменять основную версию. Включает все права роли kms.editor
.
Примитивные роли
auditor
Позволяет просматривать конфигурацию и метаданные сервиса без возможности доступа к данным.
viewer
Позволяет просматривать информацию о ресурсах.
editor
Позволяет управлять ресурсами, например создавать, изменять и удалять их.
admin
Позволяет управлять ресурсами и доступом к ним.
Подробнее о примитивных ролях см. в справочнике ролей Yandex Cloud.
Какие роли мне необходимы
Пример разграничения доступа к ключам
С ролями рекомендуется работать следующим образом:
- Владелец (роль
resource-manager.clouds.owner
) или администратор (рольadmin
) облака назначает рольkms.admin
администратору KMS. - Администратор KMS создает необходимое количество ключей и назначает (с помощью CLI или API) роли для их использования: субъекты, представляющие разные команды, получают роли
kms.keys.encrypter
,kms.keys.decrypter
,kms.asymmetricEncryptionKeys.publicKeyViewer
,kms.asymmetricEncryptionKeys.decrypter
иkms.editor
на ключи и каталоги.
Хорошей практикой является хранение ключей KMS в выделенном каталоге, отдельно от других ресурсов Yandex Cloud.
Действие | Методы | Необходимые роли |
---|---|---|
KMS | ||
Получение информации о ключах и версиях | get , listVersions |
kms.viewer на ключ на каталог |
Операции симметричного шифрования и расшифрования | encrypt , decrypt , reEncrypt , generateDataKey |
kms.keys.encrypterDecrypter на ключ (шифрование и расшифрование), kms.keys.encrypter на ключ (только шифрование), kms.keys.decrypter на ключ (только расшифрование) |
Получение списка ключей в каталоге | list |
kms.auditor на каталог |
Получение открытого ключа асимметричной ключевой пары шифрования | kms.asymmetricEncryptionKeys.publicKeyViewer на ключ |
|
Расшифрование с помощью закрытого ключа асимметричной ключевой пары шифрования | kms.asymmetricEncryptionKeys.decrypter на ключ |
|
Создание и изменение ключа | create , update |
kms.editor на каталог |
Ротация ключа | rotate |
kms.editor на ключ |
Смена основной версии | setPrimaryVersion |
kms.admin на ключ |
Удаление ключей и удаление версий | delete , scheduleVersionDestruction , cancelVersionDestruction |
kms.admin на ключ |
Назначение роли, отзыв роли | setAccessBindings , updateAccessBindings |
kms.admin на ключ |
Просмотр назначенных ролей на ключ | listAccessBindings |
kms.auditor на ключ |