왜 AWS Delegated Administrators가 AWS Multi-Account Architectures에 필수적인가
Source: Dev.to
위임된 관리자(Delegated Administrators)란?
위임된 관리자는 AWS 조직 내에서 특정 AWS 서비스를 전체 계정에 걸쳐 관리하도록 지정된 멤버 계정입니다. GuardDuty, Security Hub, CloudTrail과 같은 서비스를 관리 계정에서 직접 관리하는 대신, 해당 서비스를 위한 위임된 관리자로 멤버 계정을 등록합니다.
등록이 완료되면 해당 멤버 계정은 조직 전체에 걸쳐 서비스를 구성, 모니터링 및 관리하는 데 필요한 권한을 얻게 됩니다. 위임된 관리자는 다음을 수행할 수 있습니다:
- 모든 계정의 탐지 결과 보기
- 조직 전체에 걸쳐 구성 배포
- 관리 계정에 접근할 필요 없이 관리 작업 수행
이렇게 하면 서비스 관리가 관리 계정(여기서는 SCP가 적용되지 않고 위험이 집중되는 곳)에서 전용 멤버 계정(여기서는 SCP가 최소 권한을 강제하고 영향을 제한할 수 있는 곳)으로 이동합니다.
위임된 관리자가 중요한 이유
관리 계정 보호
관리 계정은 AWS 조직의 루트이며 청구, 조직 구조, 계정 생성 및 조직 전체 정책을 제어합니다. 따라서 공격자에게 가장 매력적인 대상이 됩니다.
서비스 제어 정책(SCP)에는 중요한 제한이 하나 있습니다: 관리 계정에는 적용되지 않습니다. 관리 계정 내의 주체가 광범위한 IAM 권한을 가지고 있다면, 조직 전체 인프라에 파괴적인 행동을 막아줄 조직 차원의 방어선이 없습니다.
GuardDuty, Security Hub, Config와 같은 보안 서비스를 직접 관리 계정에서 실행하면 위험이 더욱 커집니다. 이러한 서비스가 실행 중인 관리 계정이 침해되면 공격자는 보안 도구에 대한 가시성을 얻고 모든 계정에 대한 탐지를 비활성화할 수 있습니다.
위임된 관리자는 이 위험을 관리 계정 밖으로 옮깁니다. 보안 서비스는 전용 보안 계정에서 실행되며, 여기서는 SCP가 주체가 할 수 있는 행동을 제한합니다. 해당 계정이 침해되더라도 영향 범위는 보안 서비스 관리에 국한되고, 조직 전체의 청구 및 계정 구조는 영향을 받지 않습니다.
다중 계정 모범 사례
위임된 관리자는 나중에 추가하는 선택적 최적화가 아니라, 다중 계정 AWS 환경을 안전하게 운영하기 위해 반드시 필요합니다.
잘 설계된 다중 계정 전략에서는 계정을 기능별로 구분합니다:
- 보안 계정 – 보안 서비스 전용
- 인프라 계정 – 공유 네트워킹 및 플랫폼 서비스 전용
- 워크로드 계정 – 애플리케이션 전용
이 구조는 위임된 관리와 같은 패턴을 지원하기 위해 존재합니다. 위임된 관리자가 없으면 조직 전체 서비스를 관리 계정에서 운영해야 하며, 이는 위험을 집중시키고 업무 분리를 위반하게 됩니다. 위임된 관리자를 사용하면 팀 책임에 맞춰 목적에 맞게 설계된 계정에 서비스 관리를 분산시킬 수 있습니다.
이는 이론이 아니라 실제 이유입니다. AWS 모범 사례에서는 작은 조직이라도 전용 보안 및 로그 아카이브 계정을 권장합니다. 이러한 계정이 바로 위임 대상이 되어, 관리 계정을 손상시키지 않으면서 규모에 맞는 안전한 서비스 관리를 가능하게 합니다.
보안 및 운영상의 이점
계정 경계를 통한 업무 분리
위임된 관리자는 조직이 실제로 운영되는 방식을 반영한 팀 기반 접근 방식을 가능하게 합니다.
- 보안 팀은 보안 계정에서 Security Hub, GuardDuty, IAM Access Analyzer를 관리합니다.
- 네트워크 팀은 네트워크 계정에서 Firewall Manager를 관리합니다.
- 플랫폼 팀은 공유 서비스 계정에서 Systems Manager와 CloudFormation StackSets를 관리합니다.
각 팀은 자신이 담당하는 서비스에 필요한 접근 권한만을 갖게 되며, 관리 계정에 대한 자격 증명을 요구하지 않습니다. 이는 자격 증명 확산을 줄이고, 접근 검토를 단순화하며, 복잡한 IAM 정책 대신 계정 경계를 통한 업무 분리를 강화합니다.
영향 범위 제한
Security Hub의 위임된 관리자가 조직 전체 보안 탐지를 관리하는 것은 강력하지만, 해당 계정이 침해될 경우 영향은 Security Hub 운영에만 국한됩니다. 공격자는 계정을 삭제하거나 청구 정보를 변경하거나 조직 구조를 수정할 수 없습니다. 이러한 권한은 여전히 관리 계정에만 존재하기 때문입니다.
SCP를 사용하면 위임된 관리자 계정이 지정된 서비스만 관리하도록 추가 제한할 수 있습니다. 예를 들어, Security Hub 위임된 관리자인 보안 계정은 EC2 인스턴스 실행, S3 버킷 생성, Lambda 배포 권한이 필요하지 않습니다. SCP는 이러한 권한을 차단하면서 보안 서비스 운영만 허용합니다.
중앙화된 가시성 vs. 중앙화된 위험
위임된 관리자가 없을 때 보안 모니터링을 중앙화하면 보안 서비스 관리가 관리 계정에 집중되어 가시성과 위험 사이에 긴장이 발생합니다. 위임을 통해 중앙화된 가시성(위임된 관리자는 모든 계정의 탐지를 볼 수 있음)을 유지하면서도 중앙화된 위험(관리 계정은 최소 권한만 보유하고 보호됨)을 피할 수 있습니다.
위임된 관리자를 설정하기 위한 전제 조건
AWS Organizations 활성화 필요
위임된 관리자는 AWS Organizations 내에서만 존재합니다. 아직 독립형 AWS 계정을 사용 중이라면, 먼저 AWS Organizations를 활성화하여 위임에 필요한 중앙 관리 구조를 구축하십시오.
AWS Organizations는 다중 계정 관리의 기반을 제공합니다: 조직 단위, 정책 상속, 통합 청구, 그리고 서비스의 조직 전체 활성화 기능. Organizations가 없으면 위임된 관리자를 지정할 구조가 없습니다.
전용 멤버 계정 확보
위임된 관리자를 지정하려면 전용 멤버 계정이 필요합니다. 최소한 다음과 같은 계정이 있어야 합니다:
- 보안 계정 – 보안 서비스 위임용(Security Hub, GuardDuty, Config, IAM Access Analyzer)
- 로그 아카이브 계정 – 중앙 로그 위임용(CloudTrail)
- 네트워크 계정 – 네트워크 서비스 위임용(Firewall Manager)
- 공유 서비스 계정 – 운영 서비스 위임용(Systems Manager, CloudFormation StackSets)
워크로드 계정(프로덕션, 개발, 스테이징)을 위임된 관리자로 사용하지 마십시오. 애플리케이션 워크로드와 위임된 관리가 혼합되면 접근 제어와 사고 대응이 복잡해집니다.
위임을 지원하는 계정 구조 설계에 대한 자세한 내용은 AWS 다중 계정 전략 포스트를 참고하십시오.
신뢰된 액세스(Trusted Access) 활성화
각 AWS 서비스는 조직 내에서 위임된 관리자로 등록되기 전에 신뢰된 액세스를 활성화해야 합니다. 이 단계는 서비스가 조직 하에 있는 여러 계정에서 작동할 수 있도록 허용합니다.
(추가 구현 단계는 여기에서 이어집니다.)