AWS IAM Identity Center научился мигрировать с Active Directory без потери пользователей и назначений

AWS IAM Identity Center управляет доступом пользователей к ресурсам Amazon Web Services (AWS), включая аккаунты AWS и приложения. С его помощью можно создавать и администрировать учетные записи внутри хранилища Identity Center либо подключаться к другим источникам идентификации. Организации, которые меняют провайдера идентификации (IdP), консолидируют идентификационную инфраструктуру, внедряют новые возможности single sign-on или уходят с устаревших локальных систем, могут нуждаться в смене источника идентификации в IAM Identity Center. Ранее миграция с Active Directory на другой источник идентификации приводила к удалению пользователей, групп, членства и назначений в момент переключения. Теперь переход с Active Directory сохраняет пользователей, группы, членство и назначения — так же, как это уже работало при переходах между внешним IdP и каталогом Identity Center. Единственное исключение: при переключении на Active Directory пользователи, группы и назначения по-прежнему удаляются. Поскольку изменение применяется ко всей инстанции Identity Center одновременно, AWS настоятельно рекомендует провести тестовую валидацию и репетицию миграции.

Подробности

Источник идентификации — это система записи, определяющая, какой каталог хранит основную копию пользовательских идентичностей и членства в группах, используемых для доступа к AWS. Каждая инстанция IAM Identity Center подключается только к одному источнику идентификации одновременно. Поддерживаются три основных варианта: каталог Identity Center (хранилище по умолчанию, не зависящее от внешнего провайдера), Active Directory (интеграция с локальным Microsoft Active Directory или AWS Managed Microsoft AD через AWS Directory Service) и внешний IdP (провайдеры с поддержкой SAML 2.0, включая Okta Universal Directory). В опубликованном руководстве AWS приводит архитектурные рекомендации и пошаговый runbook для перехода с Active Directory на Okta, включая примеры кода для автоматизации процесса. Okta используется как представительный пример SAML 2.0-провайдера, и его упоминание не означает endorsement конкретного IdP. Материал адресован администраторам AWS, инженерам по идентификации и проектным командам, которым предстоит безопасно сменить источник идентификации. Отдельно отмечено, что миграция затрагивает всю инстанцию целиком, а не отдельные аккаунты или приложения, — это повышает цену ошибки при cutover.

Что делать

Спланируйте миграцию заранее: определите целевой источник идентификации (внешний IdP или каталог Identity Center), проверьте соответствие групп и назначений прав в целевом каталоге и убедитесь, что выбранный IdP поддерживает SAML 2.0. Обязательно проведите тестовую валидацию и полную репетицию переключения на тестовой инстанции — AWS прямо рекомендует это из-за одномоментного применения изменений ко всей инстанции. Используйте опубликованный runbook и примеры кода для автоматизации миграции permission sets. Учтите, что переход на Active Directory по-прежнему сопровождается удалением пользователей, групп и назначений, — для этого сценария требуется отдельная стратегия. После cutover проверьте доступность аккаунтов и приложений для ключевых групп пользователей. Обновление снимает главный риск смены источника идентификации — потерю настроенных назначений прав, — но не отменяет необходимости тщательного планирования и проверки перед переключением.

Источник: AWS Security Blog