AWS Organizations SCP 가드레일 설계 플레이북 - 계정은 늘어나는데 운영 통제는 더 단순하게

왜 지금 SCP 설계가 다시 중요해졌나

AWS 계정이 3개일 때는 콘솔 권한 몇 개만 잘 막아도 운영이 굴러갑니다.
하지만 계정이 20개, 50개, 100개를 넘어가기 시작하면 이야기가 달라집니다.

계정마다 IAM 정책이 조금씩 달라진다
운영팀이 허용하지 않은 리전이 열려 있다
실수로 퍼블릭 S3 버킷이 생성된다
보안팀은 막고 싶고 제품팀은 빨리 배포하고 싶다

이 시점부터는 개별 계정의 IAM 정책만으로 통제하는 방식이 한계를 드러냅니다.
이때 가장 강한 상위 제어 수단이 Service Control Policy입니다.

SCP는 “누가 무엇을 할 수 있는가”를 세밀하게 허용하는 도구라기보다,
“조직 전체에서 절대 하면 안 되는 일”을 상단에서 잘라내는 가드레일에 가깝습니다.

SCP를 처음 설계할 때 자주 하는 실수

가장 흔한 실패 패턴은 아래 두 가지입니다.

1. 처음부터 너무 많은 것을 막는다

보안 요구사항을 한 번에 다 반영하려고 하면 배포가 막히고, 예외 요청이 폭증합니다.

특정 리전 차단
루트 사용자 활동 차단
퍼블릭 S3 생성 차단
CloudTrail 삭제 차단
KMS 키 삭제 차단
IAM 사용자 생성 차단

이 모든 항목이 필요할 수는 있습니다.
문제는 “한 번에” 넣으면 제품팀이 어디서 막혔는지 이해하지 못하고 운영 반발만 커진다는 점입니다.

2. 예외 계정을 정책 밖으로 빼버린다

예외가 필요한 계정이 생길 때마다 SCP를 해제하면 조직 정책의 의미가 약해집니다.

좋은 예외 처리는 아래처럼 해야 합니다.

예외 계정을 별도 OU로 분리한다
왜 예외가 필요한지 기록한다
예외 기간을 둔다
만료 후 기본 OU로 복귀시키는 절차를 만든다

즉, 예외는 “정책 파괴”가 아니라 “통제된 구조 안의 별도 경로”여야 합니다.

가장 먼저 적용할 가드레일 5개

처음 도입하는 팀이라면 아래 5개부터 시작하는 것이 현실적입니다.

1. 허용 리전 제한

가장 단순하면서도 효과가 큽니다.

운영하지 않는 리전에서 리소스가 생성되는 사고를 막는다
비용 분산과 보안 탐지를 단순화한다
감사 범위를 줄일 수 있다

특히 실습 계정과 운영 계정이 섞여 있는 조직에서는 리전 통제만으로도 혼란이 크게 줄어듭니다.

2. 루트 계정 사용 최소화

루트 계정 로그인이나 액세스 키 사용은 조직 차원에서 거의 금지해야 합니다.

루트 액세스 키 생성 차단
루트 사용자 활동 모니터링
긴급 상황 외 사용 금지

루트는 “사용 금지”가 아니라 “최후의 복구 수단”으로 다뤄야 합니다.

3. 감사 로그 비활성화 방지

CloudTrail, Config, GuardDuty 같은 핵심 감사 체계는 쉽게 꺼지면 안 됩니다.

CloudTrail 삭제 차단
Config Recorder 중지 차단
보안 탐지 서비스 비활성화 제한

운영 중 장애가 나면 사람은 보통 로그를 지우지는 않더라도, “임시로 꺼두자”는 유혹을 받습니다.
SCP는 이 임시 조치를 장기 사고로 번지지 않게 막아줍니다.

4. 퍼블릭 노출 기본 차단

S3, ECR, 특정 네트워크 구성처럼 외부 노출과 연결된 리소스는 상단에서 최소한의 제한을 주는 편이 좋습니다.

모든 퍼블릭 구성을 일괄 차단할 수는 없지만, 최소한 아래는 먼저 볼 가치가 있습니다.

퍼블릭 S3 ACL 차단
승인되지 않은 인터넷 게이트웨이 패턴 제한
특정 태그 없는 외부 공개 리소스 생성 제한

5. 조직 표준 밖의 IAM 패턴 차단

운영 조직이 IAM Role 중심으로 표준화하고 있다면, IAM User 남발은 초기에 줄여야 합니다.

IAM User 생성 제한
장기 Access Key 발급 제한
필수 태그 없는 Role 생성 제한

IAM은 시간이 지날수록 정리 비용이 기하급수적으로 커집니다.
초기에 틀을 잡아두는 편이 훨씬 저렴합니다.

OU 기준으로 정책을 나누는 방법

SCP는 계정보다 OU 구조와 함께 설계해야 유지보수가 쉽습니다.

추천 구조는 대체로 아래 흐름입니다.

Security OU: 가장 강한 통제
Production OU: 감사, 리전, 외부 노출 제약 강함
Shared Services OU: 중앙 인프라 운영용 예외 일부 허용
Development OU: 제품 개발 자유도 높음
Sandbox OU: 비용과 외부 노출만 최소한 통제

여기서 중요한 것은 정책을 “OU 목적” 기준으로 나누는 것입니다.

나쁜 예:

OU는 조직도 기준
정책은 서비스별로 뒤섞임

좋은 예:

OU는 운영 성격 기준
정책은 통제 목적 기준

즉, 계정이 어느 본부 소속인지보다 “이 계정이 어떤 위험 등급의 운영을 하는지”가 더 중요합니다.

운영팀과 제품팀이 덜 싸우는 정책 구조

정책은 기술보다 커뮤니케이션 구조가 더 중요할 때가 많습니다.

실무에서는 아래 원칙이 효과적입니다.

정책 문장은 짧게

“왜 막히는지”가 한 번에 이해되어야 합니다.

허용 리전 외 배포 금지
감사 로그 비활성화 금지
승인되지 않은 외부 공개 금지

예외 요청 경로를 문서화

정책 자체보다 더 중요한 것은 “막혔을 때 어떻게 풀 수 있는가”입니다.

요청 채널
승인 주체
예외 기간
복귀 조건

배포 전 검증 루프 마련

정책이 운영 계정에 바로 적용되면 충돌이 큽니다.

sandbox OU 적용
shared services 검증
production OU 단계적 반영

보안팀이 정책을 던지고 제품팀이 맞는 구조가 아니라,
운영 전 검증을 공동으로 수행하는 구조가 되어야 장기적으로 정착합니다.

마무리

SCP는 강력하지만, 잘못 쓰면 조직의 배포 속도를 크게 떨어뜨릴 수 있습니다.
그래서 핵심은 “많이 막는 것”이 아니라 “조직 전체에서 진짜로 금지해야 할 것만 선명하게 막는 것”입니다.

정리하면 아래 세 가지가 중요합니다.

처음부터 모든 것을 막지 말고 상위 5개 가드레일부터 시작할 것
예외는 정책 해제가 아니라 OU 구조 안의 통제된 경로로 만들 것
계정이 아니라 OU 목적과 운영 위험 등급 기준으로 정책을 설계할 것

멀티계정 운영은 결국 계정을 늘리는 문제가 아니라,
“늘어난 계정을 어떤 규칙으로 계속 같은 방향으로 관리할 것인가”의 문제입니다.
SCP는 그 규칙을 가장 강하게 고정하는 도구입니다.