한 조직에서 여러 AWS 계정을 관리하기 위해 AWS Organizations를 사용합니다. 솔루션스 아키텍트는 관리자 역할만 조직 전체에서 IAM 작업을 수행할 수 있도록 정책을 적용해야 합니다. 아키텍트는 모든 AWS 계정에 액세스할 수 없습니다. 운영 오버헤드가 가장 적으면서 이를 적용하는 방법은 무엇입니까?

정답은 모든 계정에 적용되고 관리자 역할이 있는 보안 주체를 제외한 모든 보안 주체에 대한 IAM 작업을 거부하는 SCP(Service Control Policy)를 생성하고 SCP를 루트 OU에 연결하는 것입니다. SCP는 AWS Organizations의 모든 계정에 적용되는 가드레일 역할을 하여, 관리자 역할이 아닌 다른 역할이 IAM 작업을 수행하는 것을 효과적으로 차단합니다. 루트 OU에 연결하면 조직 내 모든 계정에 정책이 상속되어 최소한의 운영 오버헤드로 광범위한 적용 범위를 제공합니다. 다른 옵션들은 다음과 같은 이유로 적절하지 않습니다. "모든 계정에 적용되고 관리자 역할에 대해서만 IAM 작업을 허용하는 SCP(Service Control Policy)를 생성합니다. SCP를 루트 OU에 연결합니다."는 기본적으로 모든 IAM 작업을 거부하고 특정 관리자 역할만 허용하는 명시적 Deny 정책이 없으므로 의도한 보안 제어를 완전히 달성하지 못할 수 있습니다. SCP는 명시적 Deny가 명시적 Allow보다 우선하므로, 명시적 Deny를 사용하는 것이 더 강력한 제어 방식입니다. "모든 IAM 관련 이벤트에 대해 Lambda 함수를 트리거하도록 AWS CloudTrail을 구성합니다. 호출하는 사용자가 관리자가 아닌 경우 Lambda 함수가 작업을 거부하도록 합니다."는 실시간으로 작업을 거부하기 어렵고, 복잡한 로직과 추가적인 운영 오버헤드를 발생시킵니다. "IAM 작업을 허용하는 IAM 권한 경계를 정의하고 모든 계정의 모든 관리자 역할에 해당 권한 경계를 연결합니다."는 각 계정의 모든 관리자 역할에 수동으로 권한 경계를 연결해야 하므로 운영 오버헤드가 높고, 새로운 역할이 생성될 때마다 수동으로 적용해야 하는 번거로움이 있습니다. 또한, 권한 경계는 역할이 가질 수 있는 최대 권한을 설정할 뿐, 특정 작업을 명시적으로 거부하는 데는 SCP만큼 효과적이지 않습니다.