Удаление паспортного аккаунта из организации

Данная инструкция описывает, как удалить привилегированный паспортный аккаунт с ролью organization-manager.organizations.owner из организации.

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

Удалить привилегированный аккаунт можно, если предварительно передать роль organization-manager.organizations.owner федеративному аккаунту. Однако в этом случае возникает риск, что возможная поломка федерации (на стороне облака или клиента) приведет к невозможности управлять организацией с помощью любого из федеративных аккаунтов.

Инструкция содержит действия по митигации риска, связанного с поломкой федерации.

Основные действияОсновные действия

1. Создайте федерацию.

2. Проверьте работу федерации, войдя от имени одного из федеративных пользователей.

3. Назначьте роль organization-manager.organizations.owner федеративному пользователю:

   CLI

   yc organization-manager organization add-access-binding \
       --id= <идентификатор_организации> \
       --subject= federatedUser:<идентификатор_федеративного_аккаунта> \
       --role=organization-manager.organizations.owner
   

4. Создайте служебное облако security.

5. Назначьте роль admin на облако security офицерам безопасности, которые смогут восстановить доступ к облаку в случае поломки федерации.

6. Создайте сервисный аккаунт в облаке security для резервного восстановления доступа к организации.

   Если вы используете уже существующий сервисный аккаунт, убедитесь, что у него отсутствуют статические и API-ключи.

   CLI

   yc iam api-key list --service-account-id=<идентификатор_сервисного_аккаунта> 
   yc iam access-key list --service-account-id=<идентификатор_сервисного_аккаунта> 
   

   Важно

   Офицер безопасности имеет возможность повысить себе роль вплоть до organization-manager.organizations.owner за счет того, что он контролирует сервисный аккаунт, которому назначена такая роль. Убедитесь, что в административный доступ к облаку security и сервисному аккаунту есть только у офицеров безопасности, для этого выполните команду:

   CLI

   yc iam service-account list-access-bindings --id <идентификатор_сервисного_аккаунта>
   

   Учитывайте, что сервисным аккаунтом смогут управлять все пользователи с ролью admin на каталог, облако или организацию, где расположен этот сервисный аккаунт. Таким образом, при получении контроля над сервисным аккаунтом пользователи смогут совершать любые действия в организации, в том числе назначать себе роли вплоть до organization-manager.organizations.owner. Следите, чтобы роль admin на сервисный аккаунт, а также на каталог, облако, организацию, где он расположен, была только у доверенных пользователей.

7. Назначьте сервисному аккаунту роль organization-manager.organizations.owner:

   CLI

   yc organization-manager organization add-access-binding \
       --id= <идентификатор_организации> \
       --service-account-id=<идентификатор_сервисного_аккаунта> \
       --role=organization-manager.organizations.owner 
   

8. Создайте авторизованный ключ для сервисного аккаунта.

9. Сохраните файл ключа в доверенном хранилище.

10. Удалите роль organization-manager.organizations.owner у паспортного аккаунта через консоль или интерфейс командной строки:

    CLI

    yc organization-manager organization remove-access-binding \
        --id=<идентификатор_организации> \
        --user-account-id=<идентификатор_паспортного_аккаунта> \
        --role=organization-manager.organizations.owner 
    

Дополнительные мерыДополнительные меры

Настройте Audit Trails на действия с сервисным аккаунтом и федеративной учетной записью, которые обладают ролью organization-manager.organizations.owner:

1. Настройте сбор аудитных логов с уровня организации в Yandex Audit Trails.

2. Отслеживайте как минимум следующие события (в Object Storage, лог-группе, Managed ELK и в вашем SIEM):

   • Создание ключей для сервисного аккаунта (события: yandex.cloud.audit.iam.CreateAccessKey, yandex.cloud.audit.iam.CreateKey, yandex.cloud.audit.iam.CreateApiKey и authentication.subject_id = <идентификатор_сервисного_аккаунта>).
   • Назначение прав доступа на сервисный аккаунт (событие: UpdateServiceAccountAccessBindings и details.service_account_id = <идентификатор_сервисного_аккаунта>).
   • Любое действие с правами organization-manager.organizations.owner (.authentication.subject_id == <идентификатор_пользователя_с_данными_правами>).

Для анализа и реагирования на события в Audit Trails можно использовать Managed ELK.

Действия в случае поломки федерацииДействия в случае поломки федерации

1. Получите доступ к сохраненному в доверенном хранилище авторизованному ключу.

2. Аутентифицируйтесь от имени сервисного аккаунта.

3. Далее:

   • Либо назначьте роль organization-manager.organizations.owner паспортной учетной записи и с ее помощью восстановите федерацию.
   • Либо восстановите федерацию из интерфейса командной строки CLI.

4. Проверьте доступ от лица федеративного пользователя.

Действия после восстановления федерацииДействия после восстановления федерации

1. Если паспортной учетной записи была выдана роль organization-manager.organizations.owner — отзовите роль.
2. Создайте новый авторизованный ключ для сервисного аккаунта и сохраните его в доверенном хранилище.