SCP와 권한 세트를 설계하는 모범 사례에 대한 정리 - 1

안녕하세요 클래스메소드의 이수재입니다.

이번에 맡은 프로젝트에서 organization을 이용한 환경 설계 부분을 담당하게 되었습니다.
조사하며 알게된 내용을 스스로 정리할 겸 블로그로 써보고자 합니다.

글은 두 편으로 나뉘어지며 다음을 알아보고자 합니다.

1. 멀티 어카운트 환경 설계의 핵심 컨셉
2. OU 및 SCP 설계의 베스트 프랙티스
3. OU 및 SCP 설계의 안티 패턴
4. IAM Identity Center 의 개요
5. IAM Identity Center 유저 그룹 및 권한 세트 설계의 베스트 프랙티스
6. IAM Identity Center 유저 그룹 및 권한 세트 설계의 안티 패턴

1. 멀티 어카운트 환경 설계의 핵심 컨셉

한 조직에서 여러 어카운트를 가진 상태로 환경을 운용하다 보면 비즈니스가 성정함에 따라 누가 어떤 리소스를 만들었는지, 보안 설정은 제대로 되어 있는지, 비용은 어느 팀에서 발생했는지 파악하기 힘들어집니다.
이러한 관리를 위해서 AWS에서는 AWS Organization과 같은 다양한 서비스를 제공하고 있으며, 이에 따른 모범 사례도 제공하고 있습니다.

하지만 많은 분들이 Organization을 도입하고 운용할 때, OU를 어떻게 나눌지 혹은 SCP를 어떻게 적용할지 등 기술적인 '어떻게(How)'에만 집중하는 경향이 있습니다.

저는 기술적인 내용보다도 멀티 어카운트 환경을 설계하기 위해 이해해야 할 3가지 핵심 컨셉을 먼저 설명하고자 합니다.^[1]

컨셉 1: 영향 범위 최소화 (Minimizing Blast Radius)

계정을 분리하는 것은 비용과 보안 사고의 영향 범위를 최소화하는 가장 효과적인 첫걸음

가장 기본적인 포인트입니다.
만약 하나의 AWS 계정에 모든 프로덕션, 개발, 테스트 환경이 함께 있다면 어떻게 될까요? 개발 환경에서의 작은 실수가 프로덕션 데이터베이스에 영향을 주거나, 테스트용으로 사용한 리소스 때문에 예상치 못한 비용 폭탄을 맞을 수도 있습니다.
즉, 하나의 보안 사고가 회사 전체의 리소스에 영향을 미치게 됩니다.

이를 조정하는 것이 '영향 범위(Blast Radius)' 의 설정입니다.

AWS 계정은 보안, 비용, 리소스에 대한 가장 강력하고 명확한 경계선입니다.

따라서 워크로드, 환경, 팀, 규정 준수 요건에 따라 계정을 분리하는 것이 좋습니다.

컨셉 2: 다계층 방어 (Defense in Depth)

SCP로 큰 틀을 막고, IAM 권한 세트로 사용자의 실제 직무에 필요한 최소한의 권한을 부여하여 다계층 방어를 구축

"SCP로 허용된 서비스만 쓰도록 막았으니, 권한 세트는 PowerUser로 줘도 괜찮지 않을까?"

이것은 멀티 어카운트 설계 시 가장 빠지기 쉬운 함정 중 하나입니다. 견고한 보안은 여러 겹의 방어 계층으로 이루어집니다.

이 모델을 '성'에 비유할 수 있습니다.

1. 외벽 = 서비스 제어 정책 (SCP):

   • 이것은 성 전체를 둘러싼 가장 바깥쪽의 견고한 벽입니다.
   • 이 벽은 조직 전체의 보안 기준선을 설정하며, 누구도 이 규칙을 어길 수 없습니다.

2. 내부 출입증 = IAM 권한 세트 (Permission Set):

   • 외벽을 통과해 성 안으로 들어왔다고 해서 모든 건물에 들어갈 수 있는 것은 아닙니다. 각 개인은 자신의 직무에 맞는 '출입증'을 받습니다.
   • 즉 모든 유저는 자신에게 필요한 리소스에만 접속할 수 있도록 하는 것이 좋습니다.

만약 외벽(SCP)만 믿고 모든 사람에게 모든 건물을 출입할 수 있는 마스터 키(PowerUserAccess)를 나눠준다면, 외벽에 작은 구멍 하나만 뚫려도 성 전체가 약탈당할 것입니다.
SCP와 IAM 권한 세트라는 두 개의 방어 계층이 모두 있어야만 안전합니다.

컨셉 3: 역할 분리 및 권한 위임

관리 계정은 조직의 소유와 결제 등 최소한의 역할만 수행하고, 실제 서비스 관리는 '위임된 관리자' 계정에 위임하여 역할을 명확히 분리해야 합니다.

Organization을 생성하면 이를 관리할 관리 계정(Management Account) 을 지정하고 운용하게 됩니다.
Organization에 관한 모든 작업을 처리할 수 있는 슈퍼 계정과 같지만 일상적인 운영에는 사용하지 않는 것을 권장하고 있습니다.

쉽게 보자면 CEO와 부서장의 역할과 같다고 보면 될 것 같습니다.

• 관리 계정 = CEO
  • 회사를 설립하고(조직 생성), 부서를 만들거나 없애고(계정 및 OU 관리), 회사 전체의 돈을 관리하는(통합 결제) 최종 책임자입니다.
  • CEO의 인감(루트 사용자 자격 증명)은 금고에 안전하게 보관하고, 극히 제한적인 경우에만 사용해야 합니다.
• 위임된 관리자 계정 (Delegated Administrator) = 부서장
  • CEO는 각 분야의 전문가인 부서장에게 업무를 위임합니다.
    • "회사 전체의 보안 관리는 보안팀장에게 맡긴다", "직원들의 출입증 관리는 인사팀장에게 맡긴다" 등
  • 마찬가지로, 관리 계정은 GuardDuty, Security Hub, IAM Identity Center와 같은 서비스의 관리 권한을 특정 멤버 계정에 위임할 수 있습니다.
    • 예로 들면 보안과 관련된 서비스는 Security-Tooling 계정에 위임하는 등
  • 이제 각 위임된 관리자는 자신이 맡은 서비스에 대해 일상적인 운영을 자율적으로 수행합니다.
  • 각 서비스는 한 명의 위임된 관리자를 지정할 수 있으며, 서비스 별로 다른 계정을 위임된 관리자로 지정할 수 있습니다.

이 모델은 관리 계정의 노출을 최소화하여 보안을 극대화하고, 각 팀이 전문성을 발휘하여 효율적으로 운영할 수 있게 해줍니다.

실제로 도입할 때는 모두 고려하기 어렵다

위에서 설명한 핵심 개념을 "이해하고 설계할 때 고려해야 한다" 라는 것을 머리로는 이해할 수 있었습니다.
하지만 실제로 환경을 설계하고 생성할 때, 처음부터 모두 반영하기 어려운게 현실입니다.^[2]
이러한 점을 고려하여 처음에 멀티 어카운트 환경을 생성할 때는 어떤식으로 조정해가면 좋을지도 적어보겠습니다.

2. OU 및 SCP 설계의 베스트 프랙티스

견고한 OU 구조는 명확한 역할 분리와 확장성을 기반으로 합니다.
멀티 어카운트 환경을 설계하기 위해 AWS에서는 다음과 같은 기능 기반의 OU 구조를 시작점으로 권장합니다.

1: 기능 기반의 OU 구조 설계

계정을 단순히 팀 이름이나 프로젝트 이름으로 나열하는 것이 아니라, 각 OU가 어떤 '기능'을 수행하는지를 기준으로 구조를 설계해야 합니다.

AWS의 베스트 프랙티스 블로그에 따르면 다음과 같은 구조를 권장하고 있습니다.

조직의 OU를 설계하는데 있어 가장 우선시 되는 것은 SecurityOU 와 Infrastructure OU　입니다.
이 둘을 합쳐 FoundationOU(기초OU) 라고 합니다.

• Security OU: 조직의 보안을 책임지는 '감시탑'입니다. 모든 계정의 로그(CloudTrail)를 중앙에서 수집하는 Log-Archive 계정과, 보안 서비스(GuardDuty, Security Hub)를 관리하고 감사를 수행하는 Security-Tooling 계정을 배치합니다. 이 OU에는 가장 엄격한 SCP와 접근 제어가 적용되어야 합니다.
• Infrastructure OU: 조직 전체에 공통적으로 제공되는 인프라 서비스를 관리합니다. 예를 들어, 외부와의 네트워크 연결을 담당하는 Transit Gateway 등이 포함된 Network 계정이나 모든 계정에서 공유하는 네트워크 이외의 서비스를 관리하는 SharedInfra 계정이 여기에 속할 수 있습니다.

기초가 되는 OU를 생성한 후에는 이 외의 환경에서 사용될 OU를 생성합니다.
예로 들면 다음과 같은 OU를 생성할 수 있습니다.

• Workloads OU: 실제 서비스가 운영되는 모든 계정을 포함합니다. 다시 Prod(운영)와 Dev(개발) 의 하위 OU로 분리하여, 운영 환경에는 더 강력한 보호 정책을 적용할 수 있습니다.
• Sandbox OU: 개발자들이 AWS의 새로운 서비스를 자유롭게 실험하고 학습할 수 있는 공간입니다. 이 OU의 계정들은 프로덕션 네트워크와 완전히 분리하고, 비용 초과를 막기 위한 예산 알림을 설정하는 것이 중요합니다.
• Policy Staging OU: 조직 관리자가 OU 설정이나 SCP 등을 테스트하고 검증하기 위해 사용되는 OU입니다.

이외에 권장되는 추가 OU는 공식 문서를 참고해주세요.

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous_best_practices.html

2: SCP는 '블랙 리스트(=거부 목록(Deny List))'으로 활용하라

"기본적으로 모든 것을 허용하되(FullAWSAccess), 절대로 일어나서는 안 되는 위험한 행동만 명시적으로 금지(Deny)" 하는 '블랙 리스트 혹은 거부 목록(Deny List)' 방식이라고 합니다.

왜 블랙 리스트 방식이 좋은가?

• 민첩성(Agility): AWS에서 새로운 서비스나 기능이 출시되었을 때, 개발자들은 별도의 SCP 수정 없이 즉시 사용해 볼 수 있습니다. 조직의 혁신 속도를 저해하지 않습니다.
• 관리 용이성: 허용할 수많은 서비스를 나열하는 것보다, 금지해야 할 몇 가지 핵심적인 위험만 관리하는 것이 훨씬 간단하고 실수가 적습니다.

반드시 추가해야 할 Deny SCP 예시:

1. 조직의 근간 보호:
   • 멤버 계정이 조직에서 무단으로 탈퇴하는 것을 방지 (organizations:LeaveOrganization)
   • 중앙 감사 로그(CloudTrail)가 중지되거나 삭제되는 것을 방지 (cloudtrail:StopLogging, cloudtrail:DeleteTrail)
2. 보안 모범 사례 강제:
   • 루트 사용자의 액세스 키 생성을 금지 (iam:CreateAccessKey on Root)
   • 기본 VPC가 아닌, 의도적으로 설계된 VPC만 사용하도록 강제 (ec2:DeleteVpc on Default VPC)
3. 지역 거버넌스:
   • 허용되지 않은 리전(Region)에서 리소스를 생성하는 것을 방지 (* on Not aws:RequestedRegion)

이러한 SCP를 각 OU의 특성에 맞게 적용하고 추가하는 것이 좋습니다.
예를 들어, Prod OU에는 더 엄격한 규칙을, Sandbox OU에는 비교적 느슨한 규칙을 적용할 수 있습니다.

그리고 계정에서 사용할 수 있는 권한은 SCP와 IAM이 결합한 결과가 되기 때문에 정책 평가 기준을 숙지하는 것이 좋습니다.
https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/reference_policies_evaluation-logic.html

로직을 이해하면 SCP가 권한을 부여하지 않는다는 것을 알 수 있습니다.
즉, SCP는 권한을 확인하는 "필터"로 생각할 수 있습니다.

또한 어떠한 작업을 허용하려면 다음 각 요소에 명시적 허용이 있어야 합니다.

• AWS 계정 자체
• AWS 계정 상단의 OU
• 조직의 루트

즉, 명시적 허용이 없으면 거부됩니다. 이는 권한 모델이 기본적으로 거부(암시적 거부)임을 의미합니다.
물론 명시적인 거부가 있는 경우에는 다른 곳에 허용하더라도 거부(=명시적 거부 우선)됩니다.

SCP의 설계가 어렵다면

실제로 SCP를 설정하다보면 권장되는 서비스는 제한했지만 이후에 어떤 식으로 수정해나가면 될지 감이 잡히지 않는 경우가 있습니다.
또한 위의 컨셉 2와 같이 AWS 환경에서는 최소 권한이 권장 사항이기 때문에 불필요한 서비스에 대해서는 제한하는 것이 바람직해 보입니다.

다만 어떤 서비스가 필요하고 불필요한지 파악하는게 힘들기 때문에 IAM Access Analyzer 를 사용하여 검토하는 것을 권장합니다.
https://aws.amazon.com/ko/iam/access-analyzer/

저도 처음에는 권장되는 사항이나 확실히 불필요한 서비스에 대해서 SCP를 사용하여 권한을 제한하고, 이후 검증 단계에서 사용해보며 불필요한 권한은 점차 제한해가는 방식으로 SCP를 최적화하였습니다.

조직에서 사용할 할 때는 아래 글도 참고할 수 있습니다.
https://aws.amazon.com/ko/blogs/korea/new-use-aws-iam-access-analyzer-in-aws-organizations/

https://repost.aws/ko/knowledge-center/iam-access-analyzer-organization

3. OU 및 SCP 설계의 안티 패턴

반대로 안티 패턴에 대해 알아두고 이를 피한다면 안전한 환경을 구성할 수 있습니다.

1: 플랫(Flat)한 OU 구조

모든 계정을 Root 바로 아래에 나열하는 방식입니다.

이런 구성의 문제점은 다음과 같습니다. ^[3]

• 정책 관리의 어려움: 운영 환경과 개발 환경에 다른 SCP를 적용하고 싶을 때, 각 계정에 개별적으로 정책을 연결해야 합니다. 계정이 수십, 수백 개로 늘어나면 관리가 불가능해집니다.
• 확장성 부재: 새로운 환경(예: Staging, QA)이나 부서가 추가될 때마다 구조 전체가 복잡해집니다.

2: 너무 깊거나 복잡한 OU 구조

조직의 부서 구조를 그대로 OU에 반영하여 10단계 이상의 깊은 구조를 만드는 경우입니다.

이런 구성의 문제점은 다음과 같습니다.

• 권한 문제 해결의 어려움: 어떤 사용자가 특정 작업을 수행할 수 없는 경우, Root부터 해당 계정까지 모든 OU에 연결된 SCP를 일일이 확인해야 원인을 찾을 수 있습니다. 문제 해결 시간이 기하급수적으로 늘어납니다.
• 관리의 복잡성: 불필요하게 복잡한 구조는 관리 포인트를 늘리고 실수를 유발합니다.

권장 사항으로는 OU의 깊이는 3~4단계를 넘지 않도록 단순하게 유지하는 것이 좋습니다.

3: SCP를 '화이트 리스트(=허용 목록(Allow List))'으로 사용하기

화이트 리스트 방식도 SCP 전략 중 하나입니다.
"기본적으로 모든 것을 금지하고, 사용할 서비스만 명시적으로 허용(Allow)" 하는 방식입니다.

화이트 리스트 방식의 문제점은 다음과 같스니다.

• 낮은 민첩성: 개발자가 새로운 AWS 서비스를 사용하려면 항상 관리자에게 SCP 변경을 요청해야 합니다. 이는 조직의 기술 도입 속도를 심각하게 저해합니다.
• 유지보수의 어려움: AWS는 끊임없이 새로운 기능과 서비스를 출시합니다. 이 모든 것을 파악하고 허용 목록에 계속 추가하는 것은 현실적으로 불가능에 가깝습니다. 또한, 서비스 간의 숨겨진 의존성을 파악하지 못하면 의도치 않게 서비스가 동작하지 않는 문제가 발생합니다.
• 보안의 착각: 허용 목록이 더 안전하다고 생각하기 쉽지만, 관리자가 실수로 너무 넓은 범위(ec2:* 등)를 허용하는 순간, 그 정책이 적용된 모든 계정의 보안이 한 번에 무너질 수 있습니다.

즉, 유지 관리 비용이 많이 듭니다.
특히 "원래 접근하고 싶은 액션이 누락으로 인해 액세스할 수 없다" 라는 상황이 실제 운용 중에 자주 발생합니다.

마무리

지금까지 성공적인 멀티 어카운트 환경을 설계하기 위한 3가지 핵심 컨셉인 영향 범위 최소화, 다계층 방어, 역할 분리 및 권한 위임 그리고 OU와 SCP 설계의 베스트 프랙티스와 안티 패턴에 대해 알아보았습니다.

잘 설계된 OU와 SCP는 여러분의 멀티 어카운트 환경을 안전하고 효율적으로 운영할 수 있는 튼튼한 뼈대가 되어줄 것입니다.

다음 편에서는 이 뼈대 위에서 실제 사용자들이 활동할 수 있도록, IAM Identity Center를 활용한 사용자 그룹 및 권한 세트 설계의 베스트 프랙티스에 대해 알아보겠습니다.

긴 글 읽어주셔서 감사합니다.
오탈자 및 내용 피드백은 must01940 지메일로 보내주시면 감사합니다.

문의 사항은 클래스메소드코리아로!

클래스메소드코리아에서는 다양한 세미나 및 이벤트를 진행하고 있습니다.
진행중인 이벤트에 대해 아래 페이지를 참고해주세요.

https://classmethod.kr/board/library

AWS에 대한 상담 및 클래스메소드 멤버스에 관한 문의사항은 아래 메일로 연락주시면 감사드립니다!
Info@classmethod.kr

脚注

1. 즉, 왜(why)에 대해서 설명하고자 합니다 ↩︎

2. 도입 후에 환경의 변화가 거의 없을 것으로 예상된다면 처음부터 고려하며 설계하는 것도 가능합니다 ↩︎

3. OU를 사용하는 이유와 같습니다 ↩︎