ControlTower 계정 관리 모범 사례
AWS Control Tower를 통해 중앙집중식으로 계정 관리와 보안을 자동화하여 일관된 정책 적용이 가능합니다.
개요
Control Tower 환경에서 다수의 계정을 관리할 때 조직 수준의 일관된 정책이 필요합니다. 개별 계정 수준에서만 제어할 경우 리소스 관리 부담이 크고 정책 적용의 일관성을 보장하기 어렵습니다. 또한 특정 기간내 접근을 허용하고 제한해야하는 특정 요구사항이나 예상치 못한 비용 발생과 보안 위협이 발생했을 때 대처가 어렵습니다.
따라서 이 문서에서는 이를 효율적으로 관리하기 위한 자동화된 접근 제어 방식이나 활동을 추적하고 정책 위반을 파악하는 로깅 및 모니터링 시스템에 대해 확인해봅니다. 모범사례를 확인하여 Control Tower 및 Organizations에서 계정 관리를 위한 모범 사례를 확인하고 운영에 적용하기 위한 방법을 정리하였습니다.
핵심 용어
AWS Organization의 서비스 제어 정책(SCP) - 거버넌스
서비스 제어 정책(SCP)은 AWS Organizations의 기능으로, 조직 또는 조직 단위(OU) 내의 모든 계정에 대해 최대 사용 가능한 권한을 중앙에서 제어할 수 있도록 합니다.
SCP는 개별 IAM 정책에 관계없이 멤버 계정 내의 IAM 사용자 및 역할이 수행할 수 있는 작업을 제한하는 가드레일 역할을 합니다. 이는 Control Tower로 관리되는 멀티 계정 환경 전체에 일관된 보안 및 규정 준수 표준을 적용하는 강력한 도구입니다. Control Tower는 서비스 제어 정책(SCP)을 사용하여 예방적 제어를 구현하기 위해 AWS Organizations를 자동으로 설정하며, 사용자 지정 SCP를 추가로 생성하고 연결할 수 있습니다 .
Control Tower에 의한 SCP의 자동 구현은 조직 수준에서 기본 액세스 제한을 설정하는 데 있어 SCP의 중요성을 강조합니다. SCP는 조직 내에서 권한을 관리하는 데 사용되는 조직 정책 유형으로, IAM 사용자 및 역할에 대해 최대 사용 가능한 권한을 중앙에서 제어할 수 있도록 합니다 . SCP는 권한을 부여하는 것이 아니라 최대 사용 가능한 권한을 지정하는 액세스 제어입니다. 이는 SCP가 경계를 정의하고 IAM 정책이 해당 경계 내에서 권한을 부여하는 계층화된 접근 방식을 통해 아무리 광범위한 IAM 정책이라도 SCP가 더 높은 수준에서 제한할 수 있음을 보장합니다.
SCP는 조직 단위 수준에서 AWS 계정의 사용자, 역할 및 루트 사용자가 보유할 수 있는 최대 권한 수준을 제한하는 제어 역할을 하며, 가드레일 역할을 합니다 . OU 수준에서 SCP를 적용하면 조직 내 계정 그룹화에 따라 다양한 액세스 제한을 유연하게 적용할 수 있어 비즈니스 단위 또는 프로젝트 요구 사항에 따라 맞춤형 거버넌스가 가능합니다. SCP는 허용 및 거부 기능을 모두 포함할 수 있으며, 주로 거부 규칙에 사용됩니다. SCP 구현을 위한 거부 목록 전략과 허용 목록 전략이 있습니다 . 거부 목록과 허용 목록 전략 중에서 선택하는 것은 조직의 위험 감수 성향 및 운영 선호도에 따라 SCP 구현에 대한 다양한 접근 방식을 제공합니다.
SCP가 계정에서 작업을 거부하면 해당 계정의 어떤 엔티티도 해당 작업을 수행할 수 없으며, IAM 권한이 허용하는 경우에도 마찬가지입니다 . 이는 SCP 거부의 절대적인 성격으로 인해 의도치 않은 결과 및 운영 중단을 방지하기 위해 신중한 계획 및 테스트가 필요함을 시사합니다.

AWS IAM을 통한 계정 내 세분화된 액세스 제어
IAM을 통해 AWS 사용자, 그룹 및 역할을 생성하고 관리하여 AWS 리소스에 대한 특정 권한을 할당할 수 있습니다.
Control Tower 환경 내에서 IAM은 개별 계정 내의 리소스에 누가 액세스할 수 있는지 정의하고, 필요한 경우 계정 간 액세스를 활성화하는 데 중요한 역할을 합니다. AWS 계정은 IAM 아이덴티티(사용자, 그룹, 역할 등)를 포함한 모든 소유 리소스를 관리하는 하나의 컨테이너로 동작합니다. 이는 IAM이 각 계정 내에서 액세스를 제어하는 기본적인 메커니즘임을 확인할 수 있습니다.
계정 내의 리소스 컨테이너화는 최소 권한 원칙을 강화하며, 액세스는 계정 수준에서 부여되고 내부적으로 더욱 세분화됩니다. 랜딩 존에서 작업을 수행하려면 IAM 또는 AWS IAM Identity Center를 통해 인증을 거쳐야 하며, 정의된 권한 집합으로 액세스가 제어됩니다 . 이는 Control Tower 환경에서 작업을 승인하는 데 IAM이 중요한 역할을 한다는 것을 강조합니다. IAM은 역할, 그룹, 정책 및 신뢰 관계를 사용하여 서비스 및 리소스에 대한 액세스를 제어합니다 . IAM 내의 다양한 도구는 Control Tower 환경에서 조직의 다양한 요구 사항과 보안 요구 사항에 맞는 액세스 제어 모델을 설계하는 데 유연성을 제공합니다.
- https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/best-practices.html
- https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/best-practices-use-cases.html
AWS Control Tower 제어 활용
Control Tower Controls Reference Guide를 통해 다양한 유형의 제어(필수, 예방, 탐지, 사전 예방, 강력히 권장, 선택 사항)를 나열하고 IAM 제어 및 계정 내 백업을 구성하여 탐지 및 예방 제어를 구성할 수 있습니다.
AWS Foundational Security Best Practices를 참고하였으며 Best Practices에 따라 AWS Security Hub 제어를 사용하여 기본 계정 구성을 조정하는 데 도움이 되는 필수 및 선택적 고급 규칙인 제어를 적용할 수 있습니다.
하지만 Control Tower는 계정 간 액세스 권한이 생성되고 변경되지 않도록 제어를 적용하는 데 도움을 줄 뿐, 특정 제어에 대한 자세한 내용은 제공하지 않습니다 . 이는 Control Tower가 멀티 계정 관리의 핵심 측면인 계정 간 액세스를 관리하는 역할을 수행함을 나타내며 Control Tower를 사용함에도 IAM과 같은 보안 관리가 필요하다는 것을 입증합니다.
모범 사례 정리
위 내용을 통해 정리하면 다음과 같습니다.
강력한 액세스 관리를 위한 권장 사항
- 최소 권한 원칙을 구현하여 사용자와 역할이 작업을 수행하는 데 필요한 권한만 부여합니다.
- 자격 증명을 공유하는 대신 IAM 역할을 사용하여 계정 간 액세스를 수행합니다.
- 특히 관리 계정에 대해 모든 사용자에 대해 다단계 인증(MFA)을 적용합니다.
- IAM 정책 및 액세스 패턴을 정기적으로 검토하고 감사합니다.
- AWS Organizations 서비스 제어 정책(SCP)을 활용하여 조직 전체의 액세스 제한을 적용합니다.
- 정책 및 제어를 효과적으로 적용할 수 있도록 논리적이고 확장 가능한 조직 단위(OU) 구조를 설계합니다.
- AWS IAM Identity Center를 사용하여 여러 계정에 걸쳐 중앙 집중식 아이덴티티 관리 및 싱글 사인온을 구현합니다.
- AWS CloudTrail, AWS Config 및 AWS Security Hub를 사용하여 강력한 모니터링 및 경고를 구현하여 무단 액세스 시도를 감지하고 대응합니다.
- 액세스 권한 부여, 검토 및 해지에 대한 명확한 프로세스를 수립합니다.
- 액세스 관리와 관련된 보안 모범 사례에 대해 사용자를 정기적으로 교육합니다.
케이스
1. SCP(서비스 제어 정책)를 활용한 조직 수준 제한
- AWS Organizations의 SCP를 사용하여 참가자 계정이 속한 OU(조직 단위)에 제한 정책 적용
- 허용된 서비스 및 작업만 화이트리스트로 지정하는 접근 제어 방식을 의미합니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:DescribeInstances",
"s3:CreateBucket",
"s3:PutObject"
// 강의/이벤트에 필요한 서비스 목록
],
"Resource": "*"
},
]
}
AWS SCP에는 모든 허용 규칙인 AWSFullAccess
가 존재합니다.
해당 FullAccess를 제거하고 특정 허용 규칙만 연결하여 AWS 권한을 제거할 수 있도록 설정하거나 Deny 규칙을 추가하여 명시적인 거부 규칙을 생성합니다.

장점:
- 조직 수준에서 일괄 적용 가능하며 중앙화 구성
- 관리자 실수로 인한 과도한 권한 부여 방지
- 모든 참가자에게 동일한 정책 적용 가능
단점:
- 시간 기반 제한 및 조건을 SCP 자체에 구현 불가
2. IAM 권한 경계(Permission Boundaries)를 활용한 개인별 제한
- 각 참가자 계정에 IAM 권한 경계 설정
- AWS CloudFormation 템플릿을 사용하여 표준화된 방식으로 배포
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:*",
"s3:*"
// 이벤트에 필요한 서비스
],
"Resource": "*",
"Condition": {
"DateLessThan": {"aws:CurrentTime": "2023-12-31T23:59:59Z"},
"DateGreaterThan": {"aws:CurrentTime": "2023-12-01T00:00:00Z"}
}
}
]
}
장점:
- 시간 기반 제한 가능
- 참가자별 맞춤형 권한 설정 가능
- 기존 IAM 정책과 함께 작동
단점:
- 계정별로 개별 설정 필요하며 계정별 설정이 달라질 수 있는 가능성이 존재합니다.
자격 증명은 다음 예제를 참고합니다.
https://docs.aws.amazon.com/kokr/IAM/latest/UserGuide/accesspolicies_examples.html
3. 태그 기반 리소스 제한 정책
- 각 이벤트별 리소스에 특정 태그 적용
- 태그가 없는 리소스 생성 금지 정책 적용
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ec2:RunInstances",
"s3:CreateBucket"
// 리소스 생성 작업
],
"Resource": "*",
"Condition": {
"StringNotEquals": {"aws:RequestTag/EventProject": "Allowed"},
"Null": {"aws:RequestTag/EventProject": "false"}
}
}
]
}
장점:
- 리소스 유형별 세밀한 제어 가능
- 기존 태그 지정 전략과 통합 가능
- 이벤트 종료 후 리소스 식별 및 정리 용이 및 리소스 식별 및 구체적인 분류 가능
단점:
- 모든 서비스가 태그 기반 권한을 지원하지 않으며 사용자에게 불필요한 작업 요구
- 정책 구성이 복잡해질 수 있음
4. 통합 접근법 (권장)
- SCP + IAM 권한 경계 + 자동화된 정책 적용 결합
- Control Tower의 Customizations for Control Tower(CfCT) 활용
- Account Factory를 통해 새 계정을 생성하면 계정에 연결된 모든 리소스가 자동으로 배포/구성이 가능 사용자 지정 템플릿과 정책을 조직 내 개별 계정 및 조직 단위(OU)에 IaC 형태로 배포할 수 있습니다.
구현 단계:
- 이벤트 참가자용 OU 생성 및 기본 SCP 적용
- Account Factory로 계정 생성 시 표준화된 IAM 권한 경계 자동 적용
- Account Factory Terraform - https://tech.cloud.nongshim.co.kr/blog/aws/2346/
- AWS Lambda를 사용하여 이벤트 시작 시 계정 활성화, 종료 시 제한 정책 적용 및 이벤트 트리거
- AWS Config Rules로 비준수 리소스 모니터링
- AWS CloudTrail로 모든 활동 로깅
장점:
- 다중 레이어 방어로 보안 강화
- 자동화된 수명 주기 관리
- 확장 가능하고 반복 가능한 접근 방식
- 포괄적인 감사 및 모니터링
단점:
- 초기 설정의 복잡성
- IaC를 활용하기 위한 여러 AWS 서비스에 대한 이해 필요
https://docs.aws.amazon.com/ko_kr/controltower/latest/userguide/cfct-overview.html
Reference
- https://aws.amazon.com/ko/organizations/getting-started/best-practices/
- https://docs.aws.amazon.com/kokr/organizations/latest/userguide/orgsbest-practices.html
- https://docs.aws.amazon.com/kokr/organizations/latest/userguide/best-practicesmember-acct.html
- https://docs.aws.amazon.com/ko_kr/securityhub/latest/userguide/fsbp-standard.html