#6. AWS Security Reference Architecture

cl0·2025년 11월 24일
AWS_SRA

AWS_SRA

목록 보기
7/19

  • AWS IAM Identity Center(옛 AWS SSO) 를 중심으로 사람 -> 권한 -> 여러 AWS 계정 & 애플리케시션을 한 곳에서 관리하는 구조를 보여준다.

이 그림은 AWS IAM Identity Center(옛 AWS SSO) 를 중심으로
“사람 → 권한 → 여러 AWS 계정 & 애플리케이션”을 한 곳에서 관리하는 구조를 보여줘요.
한 번씩 요소를 뜯어서 볼게.

1. 전체 시나리오

회사 예시를 하나 생각한다.

  • 계정:

    • SharedServices (공통 서비스 계정)
    • Dev, Prod, Security, Logging … 여러 AWS 계정

  • 사람:

    • 개발자 A: Dev 계정은 Admin, Prod 계정은 ReadOnly
    • 분석가 B: Dev/Prod 둘 다 ReadOnly

  • 또, Jira / GitLab 같은 SaaS 애플리케이션도 SSO로 붙이고 싶다.

이걸 계정마다 IAM User/Role을 따로 만들고 관리하면 귀찮으니까,
Identity Center를 Shared Services 계정에 두고,
여기서 유저·그룹·권한 세트를 한 번에 관리하는 구조가 이 다이어그램이다.

2. Shared Services account & Identity Center directory

2-1. Shared Services account

좌측 상단 “Shared Services account”
→ 조직 전체에서 공통으로 쓰는 보안/인증/로깅 같은 걸 모아두는 계정.

2-2. IAM Identity Center directory (사용자 저장소)

큰 흰 박스 안의

“Create and manage identities in AWS
IAM Identity Center directory”

  • 여기서 하는 일

    • 사용자 계정 생성 (예: alice@example.com, bob@example.com)
    • 그룹 정의 (Dev-Admin, Prod-ReadOnly, Security-Team 등)

  • 이 “directory”는 크게 두 가지 경우가 있다.

    1. AWS 자체 디렉터리 (그림에 나온 것)
    2. 외부 IdP랑 연동 (Okta, Azure AD, Google Workspace 등)

지금 그림은 AWS 안에서 직접 계정 관리하는 것으로 이해할 수 있다.

3. AWS IAM Identity Center (delegated)

3-1. delegated admin 이란?

보통 Identity Center 자체는 Organizations 관리 계정에 설치되지만,
실제 관리는 다른 계정(여기서는 Shared Services)에 “위임(delegated)” 할 수 있다.

  • 관리 계정(Management Account)
    → Organizations 전체 컨트롤
  • Delegated Identity Center 계정(여기 그림의 Shared Services)
    → 유저/그룹/권한 세트/애플리케이션 할당을 실질적으로 관리

그래서:

  • Sync: 디렉터리에서 정의한 유저·그룹 정보가
    Identity Center 서비스로 동기화
  • Authenticate: 사용자가 로그인할 때,
    Identity Center가 디렉터리에 물어봐서 “이 사람 맞냐?” 확인

정리하면

  • 디렉터리 = “사람 정보 DB”
  • Identity Center 서비스 = “SSO 게이트웨이 & 권한 배포기”

4. 오른쪽 중앙: 권한을 한 곳에서 관리

4-1. 위 – Multi-account permissions

“Multi-account permissions
One place to manage permissions”

  • 여기서 하는 것:

    • Permission Set 정의

      • 예: Dev-AdministratorAccess, Prod-ReadOnly, Security-Auditor …

    • 이 Permission Set을 여러 AWS 계정에 한 번에 매핑

      • 예: Dev-AdministratorAccess → Dev, Sandbox 계정에만
      • Org-ReadOnly → 모든 계정에 공통 적용

Identity Center는 이 정의를 기반으로 각 계정에 IAM Role을 자동 생성한다.

  • Dev 계정에는 예를 들어
    AWSReservedSSO_Dev-AdministratorAccess_123abc 같은 Role이 자동으로 생김
  • 사용자가 SSO 포털에서 Dev 계정을 선택하면 이 Role로 AssumeRole.

4-2. 아래 – Application assignments

“Application assignments
One place to manage permissions”

  • AWS 계정 말고, 애플리케이션 SSO 설정

    • 예: Slack, Jira, GitLab, Salesforce, 콘솔형 SaaS, 내부 웹앱 등

  • Identity Center가 IdP 역할을 해서 SAML/OIDC로 로그인 토큰을 넘겨줌

  • 유저/그룹 단위로

    • “이 사람은 Jira, Slack, GitLab 접근 가능”
    • “이 팀은 Salesforce ReadOnly” 같은 식으로 한 번에 매핑

즉,

  • 위(녹색): “AWS 계정에 무슨 권한?”
  • 아래(빨강): “각 애플리케이션 접근 권한?”

둘 다 한 콘솔(Identity Center) 에서 설정 → 운영 단순화.

5. 실제 Access 대상

  1. AWS accounts

    • Dev, Prod, Logging, Security, Sandbox 등 모든 멀티 계정
    • 사용자는 SSO 포털에서 “어느 계정/Role로 들어갈지” 클릭

  2. AWS-managed applications / Customer-managed applications

    • AWS에서 제공하는 관리형 서비스 콘솔들 (예: Security Hub 콘솔 등)
    • 외부 SaaS 또는 자체 구축 웹앱 (SAML/OIDC 연동)

사용자 입장에서의 플로우 예시:

  1. alice@example.com 이 사내 포털에서 “AWS 계정 포털” 클릭

  2. Identity Center 로그인 페이지로 이동 (Authenticate 단계)

  3. 로그인 성공 후,

    • Dev account – Admin
    • Prod account – ReadOnly
    • Jira
    • GitLab 같은 타일이 쭉 보임

  4. Dev account – Admin 을 클릭하면

    • 자동으로 Dev 계정 콘솔에, Admin Role로 로그인 (AssumeRole + SAML)

비밀번호는 한 번만, 여러 계정과 앱에 자동으로 연결.

6. 보안·감사 서비스들

  • AWS Security Hub CSPM
  • Amazon GuardDuty
  • Amazon Macie
  • AWS Config
  • AWS IAM Access Analyzer
  • Organization trail (조직 단위 CloudTrail)

각 서비스가 하는 일 간단히 정리해보면:

  1. Security Hub CSPM

    • 여러 계정의 설정을 모아서 CIS, NIST 같은 기준으로 컴플라이언스 점검
    • GuardDuty/Config/Macie 등에서 오는 Findings를 통합 뷰로 제공

  2. GuardDuty

    • 계정/네트워크/로그(CloudTrail, VPC Flow Logs, DNS Logs 등)를 분석해서
      침입 징후, 악성 IP, 비정상 API 호출 탐지

  3. Macie

    • S3 안의 데이터에서 개인정보, 민감정보를 자동 탐지하고
      노출 위험을 분석

  4. Config

    • 리소스 설정 스냅샷/변경 이력 추적
    • “이 S3 버킷이 언제부터 Public이었냐?” 같은 질문에 답해줌

  5. IAM Access Analyzer

    • 리소스 정책을 분석해서
      “이 S3 버킷은 외부 계정에서 접근 가능한가?” 등 과도하게 열린 권한을 찾아줌

  6. Organization trail (CloudTrail 조직 트레일)

    • AWS Organizations 전체 계정에 공통으로 CloudTrail 로그를 남기는 설정
    • 모든 계정의 API 호출 기록을 중앙 계정으로 모음

이들을 Identity Center 구조와 함께 쓰면:

  • 누가 어떤 계정·어떤 Role로 들어와서

    • 어떤 API를 호출했는지(CloudTrail/Org Trail)
    • 이때 설정이 어떻게 바뀌었는지(Config)
    • 그 설정이 보안 기준을 만족하는지(Security Hub)
    • 악성 행위는 없는지(GuardDuty)
    • 민감데이터 노출은 없는지(Macie)
    • 권한이 과도하게 열려 있지는 않은지(Access Analyzer)

까지 전 계정 관점에서 통합 모니터링이 가능해지는 구조.

7. 흐름 정리

  1. 사람 만들기

    • Shared Services 계정의 Identity Center directory에서
      유저/그룹 생성

  2. 동기화 & 인증

    • 디렉터리 ↔ Identity Center (delegated) 간에

      • Sync: 유저·그룹 정보 동기화
      • Authenticate: 로그인 시 사용자 인증

  3. 권한 설계

    • Identity Center에서

      • Permission Set 정의 (AWS 계정용)
      • Application Assignment 정의 (SaaS/내부앱용)

  4. 배포

    • Permission Set을 여러 AWS 계정에 연결 → 각 계정에 IAM Role 자동 생성
    • 앱에는 SAML/OIDC 설정으로 연동

  5. 사용

    • 사용자는 SSO 포털 하나에서

      • 필요한 AWS 계정/Role 선택
      • 필요한 애플리케이션(예: Jira) 선택

  6. 감사 & 보안

    • 아래 깔린 Security Hub, GuardDuty, Macie, Config, Access Analyzer, Org Trail로

      • 전체 계정의 설정·행위·민감데이터·권한을 모니터링
profile
cl0
이전 포스트

#5. AWS Security Reference Architecture

다음 포스트

#7. AWS Security Reference Architecture

0개의 댓글