🔥 Organizations와 SCP: 조직 전체 권한 제어

앞 글 끝에서 조직 단위로 권한을 제어하는 이야기를 예고했다. 계정이 하나일 때는 IAM의 네 요소만으로 버티지만, 계정이 여러 개로 늘어나면 그 틀만으로는 해결되지 않는 문제가 생긴다.

내가 이 전환을 처음 느낀 순간은 단순했다. 개발·스테이징·프로덕션 계정을 따로 쓰기로 한 뒤, 세 계정 전부에 "EC2 인스턴스는 ap-northeast-2 바깥에서는 절대 띄우지 말자"는 규칙을 걸고 싶었다. 세 계정에 똑같은 권한 경계를 심어두면 될까? 된다. 단, 계정이 늘어날 때마다 누군가 수동으로 그 권한 경계를 복사해 붙여야 한다. 누군가 새 계정을 만들고 그 단계를 잊으면 그 계정은 조용히 무방비 상태가 된다.

AWS Organizations와 SCP는 바로 이 문제를 다룰 때 필요하다. 개별 계정의 IAM 위에서 조직 전체의 권한 상한을 한 번 더 제한하는 구조다.

Organizations: 계정들을 하나의 트리로 묶는다

Organizations는 2017-02-27에 GA된 서비스로, 여러 AWS 계정을 하나의 조직으로 묶어준다. 기능 세트는 두 가지다. Consolidated Billing only는 이름 그대로 결제만 합쳐준다. SCP는 쓸 수 없다. 반면 All features는 Organizations의 모든 기능을 연다. 둘 사이의 경계는 꽤 묵직하다. Consolidated → All features 방향으로만 승급이 가능하고, 반대는 되지 않는다. 그리고 All features로 올라갈 때는 이전에 초대로 합류한 멤버 계정들이 한 번씩 수락을 해줘야 한다(Organizations에서 생성된 계정은 승인 요청을 받지 않는다).

트리의 구성 요소는 단순하다. Root(조직의 최상위 컨테이너), OU(계정들을 묶는 폴더), Account(실제로 리소스를 담는 계정). 한 계정은 정확히 하나의 OU(또는 Root) 아래에만 속할 수 있고, OU는 Root를 기준으로 5단계까지 중첩할 수 있다. 한 조직당 OU 기본 한도는 2,000개(소프트 리밋)다.

계정은 두 종류로 나뉜다. Management account(예전 이름 master account)와 Member account다. 조직을 처음 만든 계정이 Management가 되고, 나머지 전부는 Member다. 이 구분이 단순한 라벨이 아니라는 점이 뒤에서 SCP를 이해하는 핵심이 된다.

SCP는 권한을 주지 않는다. 권한 상한만 정한다

여기까지 보면 "그럼 SCP는 IAM Policy의 조직판이네"라고 생각하기 쉽다. 반은 맞고 반은 틀리다.

SCP는 형태상 IAM Policy와 같은 JSON을 쓴다. Effect, Action, Resource, Condition. 하지만 평가 관점에서 SCP는 권한을 부여하지 않는다. 허용 범위의 상한만 정한다. SCP에 "Effect": "Allow", "Action": "s3:*"를 썼다고 해서 그 계정이 S3를 쓸 수 있게 되는 게 아니다. Identity-based 정책이나 Resource-based 정책이 실제 권한을 부여해야 하고, SCP는 그 권한이 넘지 못할 최대 범위를 정의한다. SCP가 동작하는 지점은 정책 평가 흐름: Allow와 Deny가 만나면 에서 살펴본 6단계 평가 순서 중 두 번째 관문에 해당한다.

그런데 SCP의 평가는 또 하나 독특한 규칙을 따른다. 단순한 "상속"이 아니라는 점이다.

• Allow가 되려면 Root → 경로 위의 모든 OU → 계정까지, 체인의 모든 단계에 해당 Action을 허용하는 Statement가 있어야 한다. 어느 한 단계라도 빠지면 그 Action은 Deny된다.
• Deny는 정반대다. 체인의 어느 단계에든 해당 Action에 대한 Deny가 있으면, AWS는 그 아래 모든 계정에서 그 Action을 차단한다.

이 비대칭을 이해하지 못한 채 Root에 붙어 있는 기본 정책 FullAWSAccess를 "정리 좀 하자"면서 떼어낸 순간, 그 조직의 모든 Member 계정이 한순간에 아무것도 못 하는 상태가 된다. FullAWSAccess는 Organizations가 Root·모든 OU·모든 계정에 기본으로 붙여주는 "체인의 모든 레벨에 Allow를 깔아주는" 안전장치다. Deny-list 전략을 쓸 거라면 이걸 그대로 두고 위에 Deny 문장만 얹어야 한다. 반대로 Allow-list 전략을 쓰고 싶으면 이걸 떼어내고, 체인의 모든 레벨에 직접 Allow를 다시 심어야 한다. 후자가 훨씬 조심스러운 길이다.

Management account는 SCP가 걸리지 않는다

이 구조에서 가장 자주 놓치는 지점이 Management account의 예외다. SCP는 Member 계정에만 걸린다. Management 계정의 IAM User·Role은 어떤 SCP가 Root에 붙어 있든 영향을 받지 않는다.

이건 설계상 버그가 아니라 기능이다. 실수로 SCP를 잘못 걸어서 조직 전체가 잠겨 버렸을 때, Management 계정이 break-glass 역할을 해야 하기 때문이다. 만약 Management도 SCP에 묶여 있다면, 그 SCP를 수정할 자격 있는 사람이 동시에 그 SCP 때문에 작업하지 못하는 역설이 발생한다.

그래서 AWS의 권장 아키텍처는 일관되다. Management 계정에서는 워크로드를 돌리지 말아야 한다. 조직 관리·결제·감사·Trusted access 설정만 한다. 그 위에 사람의 권한도 최소한만 둔다. Management 계정의 남용이 권한 사고의 가장 큰 뇌관이라는 걸 AWS는 경험으로 알고 있는 느낌이다.

예외는 이것 하나가 아니다. SCP는 service-linked role에도 걸리지 않는다. SLR은 AWS 서비스가 "자기 일을 하기 위해" 계정에 자동으로 심어둔 Role이라, SCP로 틀어막으면 서비스 자체가 동작을 멈춘다. 반대로 Member 계정의 root user는 SCP가 걸린다. 이 점 때문에 Member 계정 root의 범용 사용은 막되 오용된 버킷 정책 복구 같은 root-only 작업은 살려두는 식의 "deny 전부, except root-only actions" 패턴이 SCP 현업 가이드에서 자주 보이는 관용구가 됐다.

Deny list vs Allow list: 같은 목표, 다른 비용

"Prod OU의 모든 계정은 ap-northeast-2에서만 리소스를 띄우자"는 규칙을 생각해보자. 두 가지 길이 있다.

Deny list 쪽에서는 기본 FullAWSAccess를 그대로 두고, Prod OU에 Deny * with Condition: aws:RequestedRegion != ap-northeast-2를 하나 붙인다. 간단하고, 새 서비스가 나와도 자동으로 범위 안에 들어온다. 단점은 "언제든 새 Deny가 필요한 서비스가 생길 수 있다"는 예민함이다.

Allow list 쪽은 정반대다. FullAWSAccess를 떼어내고, 허용하고 싶은 서비스·액션을 체인의 모든 레벨에 직접 Allow로 써둔다. 조직이 쓰는 서비스가 명확하게 몇 개로 좁혀져 있는 규제 산업(금융, 의료)에서 쓴다. 정책 파일이 길어지고, 새 서비스를 채택할 때마다 Allow를 추가하는 운영 루틴이 필요하다.

대부분의 조직은 Deny list로 시작한다. 그리고 규제 대응이 요구되는 일부 OU(예: PCI 워크로드 전용 OU)만 Allow list로 돌려 감싸는 혼합 구조로 간다.

언제 Organizations와 SCP를 쓰지 말아야 하는가

지금까지의 이야기는 "계정이 여러 개다"를 전제로 한다. 계정이 1–2개뿐이고 앞으로도 늘어날 계획이 없다면, Organizations를 켜는 것 자체가 오버헤드다. 사람이 Management 계정과 Member 계정을 구분해서 운영해야 하고, SCP를 다루는 리뷰 루틴이 생겨야 하고, 실수로 Root에 Deny 한 줄 잘못 걸었다가 모든 계정이 멎는 사고의 가능성을 관리해야 한다.

그 비용을 권한 경계 + 잘 쓴 Identity-based 정책이 1–2개 계정에서는 충분히 대체한다. "관리형"이라는 단어에 설득당해서 조직 구조부터 먼저 만드는 건 대개 역순이다. 계정이 정말로 늘어나고 있어 통제가 필요한가가 먼저 와야 하고, 그 다음에 Organizations가 답으로 온다.

덤으로, 2024-11-13에 Resource Control Policy(RCP) 라는 동생이 합류했다. SCP가 "내 조직의 IAM 주체가 무엇을 할 수 있는가"의 상한을 내리는 도구라면, RCP는 "내 조직의 리소스가 누구에게 열려 있는가"의 상한을 내리는 도구다. 출시 시점 지원 서비스는 S3·STS·KMS·SQS·Secrets Manager다. SCP·RCP 모두 SLR과 Management account에는 걸리지 않는다는 예외를 공유한다. 이름이 비슷해서 혼동하기 쉬운데, 주체 쪽이냐 리소스 쪽이냐가 결정적인 차이다.

마무리

SCP를 어떻게 봐야 하는지는 이제 분명하다. 예전엔 SCP를 "조직 단위의 IAM Policy"라고 두루뭉술하게 부른 적이 있다. 지금은 "체인의 모든 단계에 Allow가 있어야만 허용되고, 어느 한 단계의 Deny만으로도 전부 막히는 권한 상한"이라고 본다. 이 비대칭을 이해하면 FullAWSAccess가 왜 그렇게 조심스러운 기본값인지, Management 계정이 왜 SCP를 피해 가는지, Deny list가 왜 대다수의 기본 선택인지를 한 번에 설명할 수 있다.

Organizations까지 올라오면 다음 문제는 사람 권한을 어디에서 묶어 관리하느냐다. 그 지점에서 IAM Identity Center가 답으로 들어온다.

참고 자료

• Service control policies (SCPs): AWS 공식 문서: SCP의 정의, 기본 정책, Management account 예외
• SCP evaluation: AWS 공식 문서: Allow/Deny의 비대칭 평가 규칙
• Quotas and service limits for AWS Organizations: OU 5단계, SCP 5,120자, 계정당 직접 attach 5개
• Introducing resource control policies (RCPs): 2024-11-13 출시, 리소스 쪽 권한 상한