AWS IAM 대규모 적용: 거버넌스, 다중 계정 보안 및 조직 제어 (3부)

발행: 3일 전 (2025년 12월 15일 오후 10:38 GMT+9)

9 min read

원문: Dev.to

Source: Dev.to

단일 계정 IAM이 확장되지 않는 이유

단일 AWS 계정은 실험이나 작은 프로젝트에 충분할 수 있습니다. 하지만 팀과 워크로드가 증가함에 따라 이 접근 방식은 여러 문제를 초래합니다:

개발, 스테이징, 프로덕션 환경을 격리하기 어려움
중요한 리소스에 대한 실수로 인한 접근 위험이 높음
보안 사고 시 블라스트‑반경(영향 범위) 제어가 제한적임
감사 가능성 및 규정 준수 추적이 미흡함

현대적인 AWS 아키텍처는 멀티‑계정 전략과 중앙 집중식 거버넌스를 채택함으로써 이러한 문제를 해결합니다.

멀티‑계정 AWS 모델

AWS는 복잡한 IAM 규칙을 단일 계정에 의존하기보다 여러 계정을 사용해 환경을 구성할 것을 권장합니다. 일반적인 기본 구조는 다음과 같습니다:

관리 계정 – 조직 및 청구를 소유
보안 계정 – 중앙 로그, GuardDuty, IAM 분석
공유 서비스 계정 – CI/CD, IAM 연동, 도구
워크로드 계정 – 개발, 스테이징, 프로덕션용 별도 계정

각 계정은 기본적으로 격리되어 있어 잘못된 구성이나 자격 증명 탈취 시 영향을 크게 줄일 수 있습니다.

AWS Organizations: 중앙 집중식 계정 관리

AWS Organizations를 사용하면 단일 관리 계정에서 여러 AWS 계정을 관리할 수 있습니다. 통합 청구, 계층형 조직 단위(OU), 중앙 정책 적용 기능을 제공합니다.

Organizations를 통해 팀은 다음을 수행할 수 있습니다:

프로그래밍 방식으로 계정 생성 및 관리
계정 그룹에 거버넌스 정책 적용
사용 가능한 AWS 서비스 제어
보안 요구 사항을 일관되게 강제

IAM은 각 계정 내에 그대로 존재하지만, Organizations는 그 위에 추가적인 제어 레이어를 제공합니다.

서비스 제어 정책(SCP): 권한이 아닌 가드레일

SCP는 종종 오해됩니다. 권한을 부여하는 것이 아니라 계정이나 OU가 가질 수 있는 최대 권한을 정의합니다. SCP를 필터에 비유하면, IAM 정책이 동작을 허용하더라도 SCP가 이를 차단할 수 있습니다.

일반적인 SCP 사용 사례

CloudTrail 또는 GuardDuty 비활성화 방지
조직에서 승인하지 않은 리전 사용 제한
비상 상황을 제외하고 루트 사용자 접근 차단
공개 S3 버킷 생성 금지
보안 관련 리소스 삭제 방지

SCP는 개별 IAM 정책을 수정하지 않고도 조직 전체의 보안 태세를 강제합니다.

예시 SCP: 리전 제한

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "NotAction": "iam:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["ap-south-1"]
        }
      }
    }
  ]
}

위 정책은 IAM을 제외한 모든 서비스가 특정 리전(ap-south-1)으로 제한되도록 하여 규정 준수와 비용 통제를 돕습니다.

중앙 집중식 신원 및 접근 관리

규모가 커지면 각 계정에 IAM 사용자를 생성하는 방식은 비효율적이며 보안 위험이 큽니다. 조직에서는 **신원 연동(identity federation)**을 활용합니다.

권장 접근 방식

외부 신원 제공자(IAM Identity Center, Active Directory, Okta, Azure AD) 사용
사용자는 한 번만 인증
대상 계정에서 역할을 가정하고, 역할에 맞는 권한 부여

이점

싱글 사인온(SSO)
중앙에서 사용자 수명 주기 관리
장기 AWS 자격 증명 불필요
강력한 감사 가능성

접근은 역할 기반이며, 일시적이고 감사 가능한 형태가 됩니다.

멀티‑계정 환경에서의 역할 설계

깨끗한 역할 전략은 유지 보수성을 위해 필수적입니다.

모범 사례

계정 간에 표준화된 역할 이름 사용
읽기 전용, 개발자, 관리자 역할을 구분
와일드카드 권한 부여 금지
신뢰 정책을 신중히 설정해 역할을 가정할 수 있는 주체 제한
민감한 접근에 대해서는 짧은 세션 기간 선호

이러한 일관성은 온보딩, 자동화, 사고 대응을 단순화합니다.

중앙 집중식 로깅 및 모니터링

보안 가시성은 모든 계정에 걸쳐 중앙에서 관리되어야 합니다. 일반적으로 조직은 로그를 전용 보안 계정으로 라우팅합니다:

모든 계정의 CloudTrail 로그
VPC Flow Logs
AWS Config 데이터
GuardDuty 결과

이 구성을 통해 워크로드 계정이 보안 증거를 억제하거나 변조하는 것을 방지할 수 있습니다.

조직 수준의 IAM Access Analyzer

Access Analyzer는 조직 전체에서 다음을 식별하도록 활용됩니다:

공개적으로 공유된 리소스
의도치 않은 교차 계정 접근
과도하게 허용된 정책
외부 주체가 민감한 서비스에 접근

정기적으로 Access Analyzer를 실행하면 잘못된 구성을 조기에 발견하고 지속적인 규정 준수를 지원합니다.

속성 기반 접근 제어(ABAC)

ABAC는 개별 신원 대신 속성(태그)을 기반으로 접근을 허용함으로써 정책 복잡성을 낮춥니다.

예시

사용자에 department=finance 태그 부여
리소스에 department=finance 태그 부여

태그가 일치할 때만 정책이 허용됩니다. 팀이 성장하고 변화함에 따라 이 모델은 잘 확장됩니다.

루트 계정 보호

성숙한 AWS 환경에서는 루트 계정을 강력히 잠궈 둡니다:

MFA 활성화
접근 키 없음
최소한의 사용만 허용
자격 증명은 안전하게 보관
비상 상황(브레이크글라스) 시에만 접근

루트 계정은 일상적인 작업에 절대 사용되지 않아야 합니다.

결론

규모에 맞는 IAM은 더 많은 정책을 작성하는 것이 아니라, 계정·팀·워크로드 전반에 일관된 보안 경계를 적용하는 시스템을 설계하는 것입니다. AWS Organizations, SCP, 연동된 접근, 중앙 모니터링이 결합된 거버넌스 프레임워크는 보안과 운영 유연성 사이의 균형을 제공합니다.

올바르게 구현된 IAM은 장애물이 아니라 촉진제가 되어, 팀이 빠르게 움직이면서도 강력한 보안 보장을 유지할 수 있게 합니다.