lhywk 님의 블로그

AWS Organizations + SCP 본문

AWS

AWS Organizations + SCP

lhywk 2026. 5. 2. 12:57

 

이제 계정 자체를 어떻게 구조화하고 통제할 것인가를 다룰 차례입니다.

계정이 2~3개일 때는 수동으로 관리해도 됩니다. 그런데 계정이 10개, 20개, 50개로 늘어나면 얘기가 달라집니다.

  • 개발자가 실수로 프로덕션 계정에서 비용이 많이 드는 GPU 인스턴스를 켜놨습니다
  • 보안 팀 모르게 누군가 특정 계정에서 CloudTrail을 꺼버렸습니다
  • 데이터 규정 준수상 특정 리전에서만 리소스를 생성해야 하는데, 다른 리전에도 생겨버렸습니다
  • 새로 입사한 개발자가 어떤 계정에서 무엇을 할 수 있는지 기준이 없습니다

이런 문제들을 한꺼번에 해결하는 것이 AWS Organizations이고, 그 핵심 통제 도구가 SCP(Service Control Policy)입니다.

이번 글에서 다루는 것:

  • AWS Organizations의 구조와 왜 다중 계정이 모범 사례인가
  • SCP의 동작 원리와 IAM Policy와의 결정적 차이
  • OU 설계 전략 — 실무에서 쓰이는 패턴
  • SCP 작성 전략과 실전 예제
  • IAM Access Analyzer로 권한을 지속적으로 검토하는 방법

 

1. 왜 다중 계정이 모범 사례인가?

AWS 계정을 하나만 사용하는 것은 마치 회사 직원 전체가 하나의 Linux 서버를 root 계정으로 공유하는 것과 같습니다. 편하긴 하지만 위험이 집중됩니다.

다중 계정 전략이 권장되는 이유는 크게 네 가지입니다.

① 폭발 반경(Blast Radius) 제한 어떤 계정에서 보안 사고가 나도, 다른 계정의 리소스는 영향을 받지 않습니다. 개발 계정이 해킹되어도 프로덕션 데이터는 안전합니다.

② 자연스러운 결제 경계 계정별로 비용이 독립적으로 추적됩니다. 개발/스테이징/프로덕션 각각 얼마가 드는지 Consolidated Billing으로 한눈에 보면서도, 계정별 책임이 명확합니다.

③ 리소스 격리 서비스 할당량(Quota)이 계정 단위로 관리되므로, 하나의 워크로드가 할당량을 모두 소진해도 다른 계정은 영향을 받지 않습니다.

④ 거버넌스 단순화 SCP로 계정/OU 단위의 가드레일을 설정하면, 계정 내부의 IAM 설정이 어떻게 되어있든 관계없이 조직 전체 정책을 강제할 수 있습니다.

 

2. AWS Organizations 구조

2-1. 핵심 개념

Organization(조직) : 중앙에서 관리할 수 있으며 최상단에 루트가 있고, 그 아래에는 조직 단위가 중첩된 트리형 계층 구조로 구성할 수 있는 AWS 계정의 모음입니다. 조직은 무료로 사용할 수 있습니다.

관리 계정(Management Account) : 조직을 생성하는 데 사용하는 AWS 계정입니다. 이 계정에서 조직 내 다른 계정을 생성하거나 초대하고, OU를 구성하고, SCP를 적용합니다. 이전에는 "마스터 계정(Master Account)"이라고 불렸습니다.

 

중요: 관리 계정은 SCP의 영향을 받지 않습니다. SCP는 멤버 계정에만 적용됩니다. 따라서 관리 계정에는 워크로드를 배포하지 않는 것이 강력히 권장됩니다. 관리 계정의 역할은 Organizations 자체의 관리에 집중되어야 합니다.

 

멤버 계정(Member Account) : 조직의 나머지 계정들입니다. 관리 계정에서 직접 생성하거나, 기존 계정을 초대할 수 있습니다.

루트(Root) : 조직 계층 구조의 최상위 컨테이너입니다. 루트에 SCP를 연결하면 조직의 모든 계정에 적용됩니다.

OU(Organizational Unit) : 조직 내 계정의 논리적 그룹화입니다. OU는 다른 OU를 포함할 수 있어 계층 구조를 만들 수 있습니다. OU를 최대 5단계까지 중첩할 수 있으며, OU에 SCP를 연결하면 해당 OU의 모든 하위 계정과 하위 OU에 상속됩니다.

2-2. 정책 상속 원리

SCP는 계층 구조를 타고 상속됩니다. 이것이 OU 설계의 핵심입니다.

루트 (Root)
├── SCP: DenyLeaveOrganization
│
├── OU: Security
│   ├── SCP: SecurityReadOnly
│   └── 계정: Log Archive
│   └── 계정: Security Tooling
│
├── OU: Workloads
│   ├── SCP: DenyExpensiveInstances
│   │
│   ├── OU: Prod
│   │   ├── SCP: DenyDeleteCloudTrail, DenyPublicS3
│   │   └── 계정: Prod-App1
│   │   └── 계정: Prod-App2
│   │
│   └── OU: Dev
│       ├── SCP: DenyProdServices
│       └── 계정: Dev-App1
│       └── 계정: Dev-App2

이 구조에서 Prod-App1 계정이 받는 SCP는 루트 SCP + Workloads OU SCP + Prod OU SCP 세 가지를 모두 상속받습니다. 위로 올라갈수록 더 많은 제약이 누적됩니다.

 

3. SCP(Service Control Policy)

3-1. SCP란?

SCP는 조직의 권한을 관리하는 데 사용할 수 있는 조직 정책 유형입니다. SCP는 조직 내 모든 IAM 사용자 및 IAM 역할에 대해 사용 가능한 최대 권한을 중앙에서 제어합니다.

2편에서 다룬 Permission Boundary가 IAM 엔터티(User/Role) 단위의 상한선이라면, SCP는 AWS 계정 전체 단위의 상한선입니다.

3-2. SCP의 결정적 특성 — 권한을 부여하지 않는다

SCP에 대해 가장 많이 오해하는 부분이 있습니다.

 

SCP는 어떠한 권한도 부여하지 않습니다.

SCP가 "Effect": "Allow"를 포함하더라도 그것은 "이 범위 안에서는 IAM 정책이 Allow를 줄 수 있다"는 의미이지, SCP가 직접 권한을 주는 것이 아닙니다. 실제 권한은 여전히 IAM 정책이 부여합니다.

실제 권한 = IAM Policy가 허용하는 것 ∩ SCP가 허용하는 것

즉, 두 가지가 모두 Allow해야만 실제로 허용됩니다. 어느 하나라도 Deny하거나, 어느 하나에서 Allow가 없으면 거부됩니다.

3-3. SCP vs IAM Policy 비교

항목 IAM Policy SCP

항목 IAM Policy SCP
적용 대상 IAM User/Group/Role 계정 전체 (멤버 계정의 모든 IAM 엔터티)
관리 위치 각 계정 내부 Organizations 관리 계정
권한 부여 여부 직접 부여 가능 부여 불가, 상한선만 설정
Root User 제한 불가 가능 (루트 포함 모든 엔터티)
관리 계정 적용 해당 적용 안 됨
서비스 연결 역할 제한 가능 불가
상속 없음 계층 구조 상속

중요한 차이: IAM Policy는 Root User를 제한할 수 없지만, SCP는 멤버 계정의 Root User에도 적용됩니다. (단, 관리 계정은 예외)

3-4. SCP 작동 방식: 허용 목록 vs 거부 목록

SCP를 작성하는 전략이 두 가지 있습니다.

 

전략 1: 허용 목록(Allow List)

기본적으로 모든 것을 차단하고, 허용할 것만 명시합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "s3:*",
        "rds:*",
        "lambda:*",
        "iam:*"
      ],
      "Resource": "*"
    }
  ]
}

이 SCP만 있으면, 명시된 서비스 외에는 전부 차단됩니다.

장점: 허용된 것만 쓸 수 있어 매우 엄격한 제어 가능 단점: 새로운 서비스를 사용하려면 매번 SCP를 수정해야 함. 잘못 설정하면 운영이 중단될 수 있음

 

전략 2: 거부 목록(Deny List) — 실무에서 더 일반적

기본적으로 기존 FullAWSAccess SCP로 모든 것을 허용하고, 금지할 것만 Deny로 명시합니다.

AWS는 기본적으로 모든 루트, OU, 계정에 FullAWSAccess SCP를 연결합니다. 그 위에 Deny를 추가하는 방식입니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyExpensiveInstances",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringNotLike": {
          "ec2:InstanceType": [
            "t3.*",
            "t3a.*",
            "m5.*",
            "c5.*"
          ]
        }
      }
    }
  ]
}

장점: 기존 운영에 영향 최소화, 점진적으로 가드레일 추가 가능 단점: Deny가 누락되면 허용될 수 있음

3-5. SCP의 제한사항 — 반드시 알아야 할 것들

제한 1: 관리 계정에는 적용 안 됨 SCP는 멤버 계정에만 적용됩니다. 관리 계정의 IAM 엔터티는 SCP의 영향을 받지 않습니다.

제한 2: 서비스 연결 역할(Service-Linked Role)에는 적용 안 됨 AWSServiceRoleFor* 형태의 서비스 연결 역할은 SCP로 제한할 수 없습니다.

제한 3: 리소스 기반 정책에는 직접 영향 안 줌 SCP는 계정 내 IAM 엔터티에 적용됩니다. 다른 계정의 사용자가 리소스 기반 정책(S3 버킷 정책 등)으로 접근하는 경우, 그 외부 사용자에게는 SCP가 적용되지 않습니다.

제한 4: SCP 크기 제한 각 SCP는 최대 5,120바이트입니다. 복잡한 정책은 여러 SCP로 분리해야 합니다.

 

4. OU 설계 전략

OU를 설계할 때 가장 중요한 원칙이 있습니다.

 

OU는 회사 조직도를 따르는 게 아니라, 적용할 제어 정책이 같은 계정끼리 묶어야 합니다.

예를 들어, "개발팀 계정"과 "마케팅팀 계정"을 팀 기준으로 묶는 것이 아니라, "프로덕션 환경 계정"과 "비프로덕션 환경 계정"으로 묶어야 SCP를 효율적으로 적용할 수 있습니다.

4-1. AWS 권장 기본 OU 구조

AWS는 다음과 같은 기본 OU 구조를 권장합니다.

Root
├── Security OU
│   ├── Log Archive 계정     (모든 계정의 CloudTrail/Config 로그 집중)
│   └── Security Tooling 계정 (GuardDuty, Security Hub 중앙 관리)
│
├── Infrastructure OU
│   ├── Network 계정         (Transit Gateway, VPC, Route53 등)
│   └── Shared Services 계정 (공유 AD, 공유 ECR 등)
│
├── Workloads OU
│   ├── Prod OU
│   │   └── App1-Prod, App2-Prod ...
│   └── SDLC OU (비프로덕션)
│       └── App1-Dev, App1-Staging ...
│
├── Sandbox OU              (개발자 자유 실험 계정, 강한 제한 없음)
│
└── Management OU (선택)    (관리 도구 계정)

 

4-2. 각 OU의 역할과 SCP

Security OU:

  • 목적: 보안 서비스 집중 관리, 감사 로그 보관
  • 적용 SCP: 읽기 전용 제한 (로그 삭제 방지), 로그 아카이브 계정은 외부 접근 최소화
  • 특이사항: 보안 팀만 접근 가능, 일반 개발자 접근 차단

Infrastructure OU:

  • 목적: 네트워킹, 공유 서비스
  • 적용 SCP: 네트워크 관련 서비스만 허용

Workloads > Prod OU:

  • 목적: 프로덕션 환경 격리
  • 적용 SCP:
    • CloudTrail 비활성화 방지
    • S3 퍼블릭 액세스 허용 방지
    • 루트 사용자 활동 차단
    • 특정 리전 외 리소스 생성 방지

Workloads > SDLC OU:

  • 목적: 개발/스테이징 환경
  • 적용 SCP: 비용 관련 제한 (고가 인스턴스 차단), 프로덕션 데이터 접근 차단

Sandbox OU:

  • 목적: 개발자 자유 실험, 학습
  • 적용 SCP: 비용 상한 (특정 인스턴스 차단, 특정 리전 제한), 데이터 유출 방지

 

4-3. 실무 OU 설계 시 주의사항

계정은 하나의 OU에만 속할 수 있습니다. 계정을 여러 OU에 중복 배치할 수 없습니다. 따라서 제어 정책의 교집합이 필요한 경우, OU 상속 계층을 잘 활용해야 합니다.

OU 이동 시 SCP가 즉시 변경됩니다. 계정을 다른 OU로 옮기면 SCP가 즉시 재계산됩니다. 프로덕션 계정을 잘못된 OU로 옮기면 운영이 중단될 수 있습니다. 반드시 테스트 후 이동하세요.

너무 깊게 중첩하지 마세요. 최대 5단계까지 중첩 가능하지만, 3단계 이상으로 깊어지면 "이 계정에 어떤 SCP가 적용되는지" 파악하기 어려워집니다.

 

5. 실전 SCP 예제

5-1. 특정 리전 외 리소스 생성 방지

규정 준수(Compliance) 요건으로 특정 리전에서만 리소스를 생성해야 하는 경우입니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideApNortheast2",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "route53:*",
        "budgets:*",
        "waf:*",
        "cloudfront:*",
        "sts:*",
        "support:*",
        "health:*",
        "s3:GetBucketLocation",
        "s3:ListAllMyBuckets"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-2",
            "us-east-1"
          ]
        }
      }
    }
  ]
}

주의: NotAction을 사용해서 글로벌 서비스(IAM, CloudFront, Route53 등)는 제외해야 합니다. 이들은 리전 없이 동작하기 때문에 리전 제한에서 예외처리가 필요합니다.

 

5-2. CloudTrail 비활성화 방지

모든 프로덕션 계정에서 CloudTrail을 끄거나 삭제하는 것을 방지합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyCloudTrailDisable",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging",
        "cloudtrail:UpdateTrail"
      ],
      "Resource": "*"
    }
  ]
}

 

5-3. S3 퍼블릭 액세스 허용 방지

프로덕션 계정에서 S3 버킷을 실수로 퍼블릭으로 열어놓는 것을 방지합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyS3PublicAccess",
      "Effect": "Deny",
      "Action": [
        "s3:PutBucketPublicAccessBlock",
        "s3:DeletePublicAccessBlock"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "s3:PublicAccessBlockConfiguration/BlockPublicAcls": "false"
        }
      }
    },
    {
      "Sid": "DenyPublicBucketPolicy",
      "Effect": "Deny",
      "Action": "s3:PutBucketPolicy",
      "Resource": "*",
      "Condition": {
        "Bool": {
          "s3:PolicyIsPublic": "true"
        }
      }
    }
  ]
}

 

5-4. 고비용 인스턴스 차단 (개발 환경)

개발/샌드박스 계정에서 GPU나 대형 인스턴스 사용을 방지합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyExpensiveEC2",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringNotLike": {
          "ec2:InstanceType": [
            "t2.*",
            "t3.*",
            "t3a.*",
            "m5.*",
            "m5a.*",
            "c5.*",
            "r5.*"
          ]
        }
      }
    }
  ]
}

 

5-5. 계정이 Organizations를 탈퇴하지 못하도록 방지

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeaveOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}

이 SCP를 루트에 연결하면, 모든 멤버 계정이 Organizations를 임의로 탈퇴할 수 없습니다.

 

5-6. 보안 서비스 비활성화 방지 (루트 적용)

GuardDuty, Security Hub, Config 등 핵심 보안 서비스를 끄지 못하도록 합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDisableSecurityServices",
      "Effect": "Deny",
      "Action": [
        "guardduty:DeleteDetector",
        "guardduty:DisassociateFromMasterAccount",
        "guardduty:StopMonitoringMembers",
        "securityhub:DisableSecurityHub",
        "config:DeleteConfigurationRecorder",
        "config:StopConfigurationRecorder"
      ],
      "Resource": "*"
    }
  ]
}

 

 

6. SCP가 IAM Policy를 어떻게 제한하는가 — 실습

이 실습은 SCP가 AdministratorAccess 권한을 가진 IAM 사용자도 제한할 수 있음을 직접 확인합니다.

실습 준비

  • AWS Organizations가 활성화된 관리 계정
  • 멤버 계정 1개 (테스트용)
  • 멤버 계정에 AdministratorAccess 권한의 IAM User 또는 Role

Step 1: 테스트용 SCP 생성

관리 계정에서:

Organizations 콘솔 → 정책 → 서비스 제어 정책
→ 정책 생성

이름: DenyEC2-Test
설명: EC2 접근을 완전히 차단하는 테스트 SCP

JSON 편집:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyEC2ForTest",
      "Effect": "Deny",
      "Action": "ec2:*",
      "Resource": "*"
    }
  ]
}

Step 2: SCP를 멤버 계정에 연결

Organizations 콘솔 → AWS 계정 → 멤버 계정 선택
→ 정책 → 서비스 제어 정책 → 연결
→ DenyEC2-Test 선택 → 정책 연결

Step 3: 멤버 계정에서 EC2 접근 시도

멤버 계정의 AdministratorAccess IAM User로 로그인 후:

# EC2 인스턴스 목록 조회 시도
aws ec2 describe-instances --region ap-northeast-2

# 예상 결과:
# An error occurred (UnauthorizedAccess) when calling the
# DescribeInstances operation: You are not authorized to perform
# this operation.

AdministratorAccess가 있음에도 EC2가 완전히 차단됩니다.

IAM Policy Simulator에서도 확인:

Policy Simulator → 멤버 계정의 AdministratorAccess IAM User 선택
→ EC2 서비스 → DescribeInstances
→ [Run Simulation]
결과: denied by Organizations SCP

 

Step 4: SCP 예외 처리 — 특정 Role은 허용

실무에서는 특정 역할(예: 보안팀, SRE)은 예외로 EC2에 접근해야 하는 경우가 있습니다. Condition의 ArnNotLike로 예외를 만들 수 있습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyEC2ExceptSRE",
      "Effect": "Deny",
      "Action": "ec2:*",
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:role/SRERole",
            "arn:aws:iam::*:role/SecurityAdminRole"
          ]
        }
      }
    }
  ]
}

SRERole과 SecurityAdminRole을 가진 사람은 EC2 접근 가능, 나머지는 차단됩니다.

Step 5: 정리

실습이 끝나면 SCP를 반드시 분리하세요:

Organizations 콘솔 → 멤버 계정 → 정책
→ DenyEC2-Test → 분리(Detach)

 

 

7. IAM Access Analyzer

 

7-1. Access Analyzer가 필요한 이유

권한을 주는 것은 쉽지만, 시간이 지나면서 의도치 않게 과도해진 권한이 쌓입니다.

  • 6개월 전에 프로젝트용으로 만든 IAM Role이 지금도 AdministratorAccess를 갖고 있음
  • S3 버킷이 실수로 퍼블릭으로 열려 있었는데 아무도 몰랐음
  • 테스트용 Lambda 함수의 역할이 삭제되지 않고 계속 존재함

IAM Access Analyzer는 이런 문제를 지속적으로 탐지하고 알려주는 서비스입니다.

 

7-2. Access Analyzer의 세 가지 분석 유형

① 외부 액세스 분석기 (External Access Analyzer) — 무료

신뢰 영역(Trust Zone, 보통 하나의 계정 또는 Organizations) 외부에서 접근할 수 있는 리소스를 탐지합니다.

분석 대상:

  • S3 버킷 (버킷 정책, ACL)
  • IAM Role (신뢰 정책)
  • KMS 키
  • Lambda 함수/계층
  • SQS 대기열
  • Secrets Manager 비밀
  • ECR 리포지토리

예시 결과:

S3 버킷 'prod-data-bucket'이 공개적으로 읽기 가능합니다
IAM Role 'AnalyticsRole'이 외부 계정 999999999 에서 AssumeRole 가능합니다

 

② 미사용 액세스 분석기 (Unused Access Analyzer) — 유료 ($0.2/IAM엔터티/월)

실제로 사용되지 않는 권한, 자격 증명, 역할을 탐지합니다.

예시 결과:

IAM Role 'OldProjectRole' — 180일 이상 사용되지 않음
IAM User 'alice' — S3 권한이 부여됐지만 S3를 한 번도 사용하지 않음 (90일)
Access Key AKIA... — 60일 이상 미사용

 

③ 정책 검증 (Policy Validation) — 무료

새 정책을 작성하거나 저장할 때 100개 이상의 보안 모범 사례 체크를 수행합니다.

예시 경고:

이 정책은 와일드카드 액션(*) 을 사용합니다. 최소 권한을 위해 구체적인 액션을 지정하세요
이 정책의 리소스 ARN 형식이 잘못되었습니다

 

7-3. 신뢰 영역(Trust Zone) 설정

분석기를 만들 때 신뢰 영역을 설정합니다. 이 영역 밖에서의 접근이 "외부 접근"으로 분류됩니다.

  • 계정 수준 분석기: 해당 계정 외부 = 외부 접근
  • 조직 수준 분석기: Organizations 외부 = 외부 접근 (같은 조직 내 계정 간 접근은 내부로 간주)

대부분의 기업은 Organizations 전체를 신뢰 영역으로 설정하고, 조직 외부에서 접근 가능한 리소스를 모니터링합니다.

 

7-4. 실습: Access Analyzer 설정 및 결과 확인

Step 1: 외부 액세스 분석기 생성

IAM 콘솔 → Access Analyzer → 분석기 생성

이름: external-access-analyzer
유형: 외부 액세스 분석기
신뢰 영역: AWS 계정 (단일 계정) 또는 조직 선택

→ 분석기 생성

생성 직후부터 분석이 시작되며 수 분 내에 결과가 나타납니다.

 

Step 2: 결과 확인 및 처리

Access Analyzer → 활성 결과(Active Findings)

예시 결과:
┌─────────────────────────────────────────────────────┐
│ 리소스: arn:aws:s3:::my-test-bucket                 │
│ 액세스 유형: Public                                 │
│ 원인: 버킷 정책이 모든 보안 주체에게 읽기 허용      │
│ 상태: Active                                       │
└─────────────────────────────────────────────────────┘

결과에 대해 취할 수 있는 조치:

  • 아카이브(Archive): 의도된 공개 접근이면 아카이브 (이후 변경 시 재활성화)
  • 해결(Resolve): 버킷 정책을 수정하여 실제로 문제를 해결

 

Step 3: CLI로 결과 조회

# 분석기 목록 조회
aws accessanalyzer list-analyzers

# 활성 결과 조회
aws accessanalyzer list-findings \
  --analyzer-arn "arn:aws:accessanalyzer:ap-northeast-2:ACCOUNT_ID:analyzer/external-access-analyzer" \
  --filter '{"status": {"eq": ["ACTIVE"]}}'

# 결과를 JSON으로 출력하여 보안 팀 리포트 생성
aws accessanalyzer list-findings \
  --analyzer-arn "arn:aws:accessanalyzer:..." \
  --query 'findings[*].{Resource:resource,Type:resourceType,Status:status}' \
  --output table

 

Step 4: 미사용 액세스 분석기 생성 (유료)

Access Analyzer → 분석기 생성

이름: unused-access-analyzer
유형: 미사용 액세스 분석기
미사용 액세스 기간: 90일 (이 기간 이상 미사용 시 결과 생성)
범위: 계정 또는 조직

90일 동안 사용되지 않은 역할, 사용자, 액세스 키 목록이 생성됩니다. 이를 주기적으로 검토하고 불필요한 권한을 제거합니다.

 

8. Organizations + SCP + Identity Center 통합 뷰

지금까지 배운 것들이 어떻게 연결되는지 정리합니다.

AWS Organizations (계정 구조 및 거버넌스)
    │
    ├── SCP (계정 단위 최대 권한 상한선)
    │       ↓ 상속
    │   루트 → OU → 계정
    │
    ├── IAM Identity Center (SSO 접근)
    │       ↓
    │   Permission Set → IAM Role (각 계정에 자동 생성)
    │       ↓
    │   사용자가 해당 Role 수임 → SCP 범위 내에서만 작업 가능
    │
    └── IAM Access Analyzer (권한 지속 모니터링)
            ↓
        외부 접근 탐지, 미사용 권한 탐지

 

최종 권한 결정 공식:

실제 허용 = (IAM Policy가 Allow) ∩ (SCP가 Allow) ∩ (Permission Boundary가 Allow)
단, 어디서든 Explicit Deny가 있으면 무조건 DENY

 

 

 

 

AWS Organizations:

  • 다중 계정을 중앙에서 관리하는 서비스
  • 관리 계정 + 멤버 계정 + OU 계층 구조
  • 관리 계정에 워크로드 배포 금지

SCP:

  • 계정 단위의 최대 권한 상한선 — 권한을 부여하지 않고 제한만 함
  • 루트 → OU → 계정 순으로 상속
  • IAM Policy와 교집합이 실제 유효 권한
  • 관리 계정, 서비스 연결 역할에는 미적용

OU 설계:

  • 조직도가 아닌, 같은 제어 정책이 필요한 계정끼리 묶기
  • Security / Infrastructure / Workloads(Prod + SDLC) / Sandbox 기본 구조

IAM Access Analyzer:

  • 외부 접근 분석기: 의도치 않게 열린 리소스 탐지 (무료)
  • 미사용 액세스 분석기: 오래된 권한, 미사용 역할 탐지 (유료)
  • 정책 검증: 새 정책 작성 시 모범 사례 체크 (무료)

 

 

 

참고 자료

'AWS' 카테고리의 다른 글

AWS Security Hub  (0) 2026.05.11
ERGO의 이벤트 기반 보안 자동 대응 아키텍처 분석  (0) 2026.05.09
IAM Identity Center  (0) 2026.05.02
Directory Service  (0) 2026.05.02
IAM Federation + OIDC  (0) 2026.05.02
'AWS' Related Articles more