Как использовать AWS Control Tower, но игнорировать функцию единого входа AWS в пользу индивидуального подхода к ADFS?

Question

Цель: использовать все функции AWS Control Tower, кроме AWS SSO, поскольку организация, с которой я работаю, не хочет изменять какие-либо аспекты управления идентификацией и единого входа в настоящее время.

В настоящее время эта организация использует ADFS в своем центре обработки данных для единого входа с MFA и имеет некоторые средства автоматизации и процессы для настройки новой учетной записи AWS с этим решением для идентификации.

Меня не волнует, запускается ли эта интеграция с ADFS автоматически при создании новой учетной записи, поскольку в организации еще не было такого уровня автоматизации для идентификации, и цель не состоит в том, чтобы это изменить.

В ответах на часто задаваемые вопросы об AWS Control Tower рекомендуется использовать решение Landing Zones вместо Control Tower, если вам нужен более индивидуальный подход:

В то время как Control Tower автоматизирует создание новой зоны посадки с предварительно настроенными схемами (например, AWS SSO для каталога и доступа), решение AWS Landing Zone обеспечивает настраиваемую настройку зоны посадки с широкими возможностями настройки с помощью настраиваемых надстроек (например,, Active Directory, Okta Directory) и текущих модификаций с помощью конвейера развертывания и настройки кода.

Шаблоны и руководства CloudFormation для подхода к зонам посадки находятся здесь:

• Шаблон инициирования зоны приземления CloudFormation:https://s3.amazonaws.com/solutions-reference/aws-landing-zone/latest/aws-landing-zone-initiation.template
• Руководство разработчика AWS Landing Zone:https://s3.amazonaws.com/solutions-reference/aws-landing-zone/latest/aws-landing-zone-developer-guide.pdf
• Руководство по внедрению зоны приземления AWS:https://s3.amazonaws.com/solutions-reference/aws-landing-zone/latest/aws-landing-zone-implementation-guide.pdf
• Руководство пользователя AWS Landing Zone:https://s3.amazonaws.com/solutions-reference/aws-landing-zone/latest/aws-landing-zone-user-guide.pdf

Но мне нужно все: простота Control Tower и использование индивидуального подхода к идентификации. Кроме того, организация использует Terraform, поэтому я не хочу вводить кучу шаблонов CloudFormation, а AWS Terraform Landing Zone Accelerator (TLZ) еще не выпущен, несмотря на то, что он был объявлен более года назад.

В AWS Control Tower Account Factory требуется ввести адрес электронной почты AWS SSO, поэтому кажется, что нет никакого способа обойтись без использования AWS SSO, по крайней мере, во время первоначальной настройки или "регистрации учетной записи":

Другой аспект этого: поскольку организация использует ADFS для входа в AWS, я не могу получить доступ к учетной записи, созданной AWS Control Tower, через роль переключателя на AWSControlTowerExecution которую создает Control Tower, потому что я вошел в учетную запись Control Tower (главную) через федерацию.

(Главный в AWSControlTowerExecutionотношения доверия роли - это номер основной учетной записи. Когда вы аутентифицированы через федерацию, AWS не видит вашего принципала как часть учетной записи, в которую вы вошли в федерацию, поэтому AWSControlTowerExecution роль не доверяет мне, федеративному пользователю, так сказать.)

Answer 1

Вы можете использовать AWS SSO в качестве значений по умолчанию для Control Tower, включая AWS SSO, использовать пользователя SSO для входа в новую учетную запись и настройки ADFS, а затем сделать пользователя SSO бесполезным с помощью политики AWS Service Control (SCP).

Итак, в Account Factory введите адрес электронной почты и имя для полей SSO по мере необходимости.

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

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

Вам будет предложено создать пароль, а затем войти в систему по ссылке, которую вы можете найти в Control Tower > Пользователи и доступ> URL-адрес пользовательского портала.

После того, как вы войдете в только что созданную учетную запись с помощью этого входа в систему AWS SSO, вы можете настроить ADFS, используя процесс вашей организации.

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

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAWSSSOUser",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "ForAnyValue:StringLike": {
                    "aws:PrincipalArn": [
                        "*AWSReservedSSO*"
                    ]
                }​​​​​​
            }​​​​​​
        }​​​​​​
    ]
}​​​​​​

Пользователь SSO по-прежнему сможет войти в эту учетную запись, но не сможет ничего делать или видеть.

Однако, чтобы упростить это, вы можете подождать, пока не будут созданы все учетные записи, чтобы добавить этот SCP. Таким образом, вы можете сначала создать OU для новых учетных записей в AWS Organizations, затем переместить новые учетные записи в это OU и, наконец, применить этот SCP ко всему OU.

Это вложение SCP не имеет риска заблокировать вас, потому что в качестве резервного / прерывистого доступа вы все равно можете создать пользователя IAM в основной учетной записи и переключить роли на учетную запись, созданную Control Tower.