#4. AWS Security Reference Architecture

cl0·2025년 11월 23일
AWS_SRA

AWS_SRA

목록 보기
5/19

  • 계정/권한 관리(SSO)
  • 대규모 멀티 계정에서 사람 접근을 어떻게 관리하는지 나타냄
  • 여러 회사 계정/앱에 대한 권한을 IAM Identity Center 하나로 관리하는 구조를 보여줌
  • 사람 → 회사 IdP → IAM Identity Center → AWS 계정/앱

이 그림은 “여러 회사 계정·앱에 대한 권한을 IAM Identity Center 하나로 관리하는 구조”를 보여줘.
“사람 → 회사 IdP → IAM Identity Center → AWS 계정/앱” 이런 흐름이라고 생각하면 편해.

1. 전체 스토리 한 번에 보기

  1. 직원은 회사 계정(AD, Okta, Entra ID 등)으로 로그인한다.

  2. 이 계정 정보가 IAM Identity Center(예전 AWS SSO)로 Sync(동기화) 된다.

    • 사용자/그룹 목록만 복제해 두는 것.

  3. 사용자가 로그인하려 하면, IAM Identity Center가 다시 회사 IdP에 Authenticate(인증)를 맡긴다.

  4. 인증이 끝나면 IAM Identity Center가

    • “이 사람은 어떤 AWS 계정에 어떤 권한으로 들어갈 수 있는지”
    • “어떤 SaaS / 내부 앱에 접근할 수 있는지”
      를 판단해서 SSO 화면을 보여준다.

  5. 사용자는 그 화면에서

    • AWS 계정 타일 클릭 → 해당 AWS 계정에 임시 자격증명으로 로그인
    • Application 타일 클릭 → SAML로 연동된 앱(예: Security 팀 콘솔, Jira, Splunk 등)에 로그인

이 모든 설정을 Shared Services account 하나에서 중앙집중으로 관리하는 구조이다.

2. 회사의 IdP(신원 제공자)들

왼쪽 큰 사각형이 “회사 쪽 IdP” 영역이야.

  • Active Directory
  • Microsoft Entra ID(Azure AD)
  • Okta
  • Google Workspace
  • OneLogin, Ping, JumpCloud, CyberArk
  • 기타 SAML 2.0 호환 IdP

여기서 하는 일

  1. 사용자·그룹 원장(Source of Truth)

    • 계정/그룹을 실제로 관리하는 곳.

  2. 인증(Authentication)

    • 아이디/비밀번호, MFA, 보안 정책(회사 밖에서 접속 금지 등)을 여기서 적용.

Sync vs Authenticate 화살표 의미

  • Sync →

    • SCIM 같은 프로토콜로 “사용자/그룹 목록”을 IAM Identity Center 디렉터리에 복제.
    • 예: AD에 Cloud-Security 그룹에 사람이 추가되면, Identity Center 디렉터리에도 자동 반영.

  • ← Authenticate

    • 누가 로그인 버튼을 누르면 Identity Center가 “가서 이 사람 맞는지 확인 좀 해줘” 하고
      IdP로 리다이렉트해서 인증을 맡기는 것(SAML/OIDC).

한 줄 요약:
왼쪽은 사람을 ‘기록하고 확인’하는 곳,
가운데는 ‘그 사람이 어디까지 들어갈지’ 결정하는 곳.

3. Shared Services account + IAM Identity Center

이 박스가 AWS 쪽 중앙 권한 관리 계정이다.

3-1. Shared Services account 란?

  • AWS Organizations 안에서
    “공통 서비스(보안, 계정관리, 빌링, IAM Identity Center 등)를 운영하는 전용 계정”으로 자주 쓰는 패턴.

  • 여기서 IAM Identity Center를 delegated admin으로 설정하면,

    • Organizations에 포함된 모든 AWS 계정에 대한 권한을 이 계정에서 한 번에 관리할 수 있다.

3-2. IAM Identity Center

  1. Multi-account permissions (위, 초록색)

여러 AWS 계정에 대한 권한을 한 곳에서 관리

  • Permission set을 정의 → 여러 계정에 “복사/배포”하는 구조.

  • 예:

    • Security-ReadOnly – 모든 운영 계정에 read-only 권한
    • Incident-Responder – 특정 계정에만 EC2 Snapshot 생성, GuardDuty 조회, CloudTrail 읽기 권한 등

  • 사용자는 “어느 계정에 어떤 permission set으로 들어갈 수 있는지” 조합으로 표현.

  1. Application assignments (아래, 빨간색)

    SSO로 접속하는 각종 애플리케이션에 대한 접근 설정

    • AWS가 제공하는 앱 / 고객이 만든 내부 앱을 SAML 기반 SSO로 연결.

    • 예:

      • Splunk-Cloud, Jira, Security Onboarding Portal, CloudGuard 콘솔 등

    • “이 그룹은 이 애플리케이션에 접근 가능”을 Identity Center에서 지정.

“One place to manage permissions” – 권한 관리를 한 곳에서.

4. 보안/거버넌스 서비스

Shared Services account 맨 아래 줄:

  • AWS Security Hub (CSPM)
  • Amazon GuardDuty
  • Amazon Macie
  • AWS Config
  • AWS IAM Access Analyzer
  • Organization trail(= Org 레벨 CloudTrail)

이건 이 계정에서 주로 관리·모니터링할 보안 서비스들을 의미함.

예시:

  • Security Hub를 이 계정에서 organizations 통합 계정으로 두고,
    각 멤버 계정의 보안 상태를 한 번에 본다.
  • Organization trail을 여기서 만들어서,
    Organizations 전체의 API 호출 로그를 중앙 S3로 모은다.
  • Access Analyzer로 cross-account 권한, 퍼블릭 접근 S3 등을 분석.

즉, 보안 팀이 쓰는 도구들을 Shared Services account에 모아 놓고,
그걸 다시 IAM Identity Center 권한으로 접근·제어하는 그림.

5. 실제로 접근하는 대상들

5-1. AWS accounts

  • 여러 AWS 계정(운영, 개발, 보안툴, 로그아카이브, 포렌식 등)에 대해

    • Identity Center에서 “어느 그룹이 어느 계정에 어떤 권한으로 들어갈지”를 정의해 둠.

  • 사용자가 브라우저에서 SSO 포털에 로그인하면:

    1. “AWS accounts” 섹션에 계정별 타일이 보이고
    2. Shared-Prod (Security-ReadOnly) 같은 식으로 role이 표시됨.
    3. 클릭하면 해당 계정 콘솔로 자동 로그인 (STS AssumeRole + SAML).

5-2. AWS-managed / Customer-managed applications

  • AWS가 제공하는 앱 (예: Amazon Managed Grafana, Amazon QuickSight)
    또는 사용자가 구축한 앱(내부 Portal, 보안 콘솔 등)을
    Identity Center를 통해 SSO 접속하게 만드는 것.

  • 회사 입장에서 보면:

    • 직원은 아이디 하나로

      • 여러 AWS 계정
      • 여러 SaaS/내부 애플리케이션
        에 접속 가능 → 계정/비밀번호 난립 방지, 접근통제·감사 용이.

6. 예시 시나리오 (보안팀 기준)

배경

  • 회사 IdP = Microsoft Entra ID

  • user1은 Cloud-Security라는 그룹에 속해 있음.

  • AWS Organizations 안에

    • Security-Tooling 계정 (Shared Services)
    • Prod-1, Prod-2, Log-Archive, Forensics 등 여러 계정 존재.

설정

  1. Entra ID ↔ IAM Identity Center

    • SCIM으로 Cloud-Security 그룹과 사용자 계정 Sync.

  2. Identity Center에서 Permission set 정의

    • Security-ReadOnly : CloudTrail/Config/GuardDuty/SecurityHub 읽기 권한
    • Security-IncidentResponder : EC2 Snapshot, S3 Read, IAM Read 등 추가 권한

  3. Multi-account assignment

    • Cloud-Security 그룹 →

      • Prod-1, Prod-2 계정에는 Security-ReadOnly
      • Forensics 계정에는 Security-IncidentResponder

  4. Application assignment

    • Cloud-Security 그룹 →

      • CloudGuard SaaS 앱 SSO 사용 가능
      • Internal-IR-Portal SAML 앱 사용 가능

user1이 실제로 사용할 때

  1. user1이 회사 계정으로 SSO 포털 접속 → Entra ID에서 인증(MFA 포함).

  2. 브라우저에 IAM Identity Center 포털이 뜨고,

    • AWS Accounts:

      • Prod-1 (Security-ReadOnly)
      • Prod-2 (Security-ReadOnly)
      • Forensics (Security-IncidentResponder)

    • Applications:

      • CloudGuard
      • IR-Portal
        이런 타일이 보여.

  3. 오늘은 사고 분석이 필요해서 Forensics (Security-IncidentResponder)를 클릭

    • STS 임시 자격증명으로 Forensics 계정 콘솔에 자동 로그인.

  4. 조사 후 CloudGuard 앱 타일을 클릭해서 SaaS 콘솔도 바로 들어감.

도연 입장에서는 “로그인 한 번, 버튼 클릭 몇 번”으로
필요한 AWS 계정과 보안 툴에 자연스럽게 오갈 수 있고,
보안팀 입장에서는 “그룹 단위로 모든 권한을 한 곳에서 관리” 가능.

profile
cl0
이전 포스트

#3. AWS Security Reference Architecture

다음 포스트

#5. AWS Security Reference Architecture

0개의 댓글