lhywk 님의 블로그

IAM Identity Center 본문

AWS

IAM Identity Center

lhywk 2026. 5. 2. 12:49

개발 계정, 스테이징 계정, 프로덕션 계정, 보안 계정, 로깅 계정 — AWS Organizations를 잘 쓰는 기업이라면 계정이 수십 개입니다. 각 계정마다 Federation을 따로 설정하고, IAM Role을 따로 만들고, 사용자를 따로 관리한다면 운영 비용이 폭발합니다.

AWS IAM Identity Center는 이 문제를 해결하기 위해 만들어진 서비스입니다.

 

"계정 하나에 로그인하면, 권한이 있는 모든 계정에 클릭 한 번으로 전환"

이것이 IAM Identity Center가 해결하는 핵심 문제입니다. 

 

1. IAM Identity Center란?

1-1. 이름의 역사

IAM Identity Center는 2022년 7월 이전까지 AWS Single Sign-On(AWS SSO) 이라고 불렸습니다. 기능이 크게 확장되면서 이름이 바뀌었지만, API 네임스페이스(sso, identitystore)는 하위 호환성을 위해 그대로 유지됩니다.

문서나 블로그에서 "AWS SSO"를 보더라도 IAM Identity Center와 같은 서비스입니다.

1-2. IAM Identity Center가 해결하는 문제

기존 방식의 문제점:

계정 A (개발)      → IAM User alice_dev / 별도 비밀번호
계정 B (스테이징)  → IAM User alice_stg / 또 다른 비밀번호
계정 C (프로덕션)  → IAM User alice_prod / 또 다른 비밀번호

이 방식은:

  • 계정마다 별도 IAM User 관리 필요
  • 퇴사 시 모든 계정에서 일일이 비활성화해야 함
  • MFA도 계정마다 따로 설정
  • CloudTrail 로그에 IAMUser:alice_prod 처럼 계정별 다른 identity로 기록 → 추적 어려움

IAM Identity Center 방식:

회사 IdP (Okta / Azure AD / AWS 내부 디렉터리)
    ↓ 한 번 로그인
IAM Identity Center
    ↓ 클릭 한 번으로
계정 A (개발)     → 자동 임시 자격 증명 발급
계정 B (스테이징) → 자동 임시 자격 증명 발급
계정 C (프로덕션) → 자동 임시 자격 증명 발급

퇴사 시 IdP에서 계정 하나만 비활성화하면 모든 AWS 계정 접근이 차단됩니다.

1-3. IAM Identity Center vs 직접 IAM Federation

IAM 직접 Federation(SAML/OIDC)과 비교하면:

항목 직접 IAM Federation IAM Identity Center
설정 복잡도 계정마다 별도 설정 한 번 설정, 전체 계정 적용
다중 계정 어려움 (각 계정 개별 설정) 핵심 기능 (다중 계정 통합)
Permission 관리 계정마다 IAM Role 직접 설정 Permission Set 중앙 관리
CLI 지원 복잡한 AssumeRole 설정 aws sso login 명령어 하나
감사 계정별 분산 IAM Identity Center 중앙 통합
AWS 권장 방향 단순 환경 다중 계정 환경의 표준

 

2. IAM Identity Center의 핵심 구성 요소

2-1. 자격 증명 소스 (Identity Source)

IAM Identity Center는 사용자를 직접 관리하지 않습니다. 외부의 자격 증명 소스에서 사용자를 가져옵니다. 세 가지 옵션이 있습니다.

옵션 1: IAM Identity Center 내부 디렉터리 (기본값)

  • IAM Identity Center 자체에 사용자/그룹을 직접 생성
  • 외부 IdP가 없는 스타트업이나 소규모 팀에 적합
  • 가장 빠르게 시작할 수 있음

옵션 2: Active Directory (AWS Managed AD 또는 AD Connector)

  • AD와 연동
  • 기업 AD 그룹이 IAM Identity Center 그룹으로 동기화됨
  • 온프레미스 AD 사용자가 AWS에 SSO 접근 가능

옵션 3: 외부 IdP (Okta, Azure AD, Google Workspace 등)

  • SAML 2.0으로 인증 연결
  • SCIM으로 사용자/그룹 자동 동기화
  • 대부분의 기업이 선호하는 방식

중요한 특성: 외부 IdP를 자격 증명 소스로 사용할 때, IAM Identity Center는 사용자의 비밀번호나 MFA 디바이스를 저장하지 않습니다. 인증은 여전히 외부 IdP가 담당하고, IAM Identity Center는 권한 부여를 담당합니다. 사용자 이름과 그룹 멤버십 같은 속성의 동기화된 복사본만 보관합니다.

 

2-2. Permission Set (권한 세트)

Permission Set은 IAM Identity Center의 핵심 개념입니다. IAM Role의 템플릿이라고 생각하면 됩니다.

공식 정의: 권한 세트는 하나 이상의 IAM 정책 컬렉션을 정의하는 템플릿으로, 조직의 사용자 및 그룹에 대한 AWS 계정 액세스 할당을 간소화합니다.

Permission Set을 계정에 할당하면, 해당 계정에 자동으로 IAM Role이 생성됩니다. 사용자가 그 계정에 접속하면 이 Role을 자동으로 수임(AssumeRole)하는 방식입니다.

 

Permission Set의 구성:

Permission Set: "Developer"
├── AWS 관리형 정책: PowerUserAccess
├── 고객 관리형 정책: CompanyDevPolicy
├── 인라인 정책: (선택 사항)
└── Permission Boundary: (선택 사항)

 

Permission Set의 핵심 특성:

  • 계정마다 IAM Role을 직접 만들 필요가 없음
  • Permission Set 하나를 수십 개의 계정에 동시에 적용 가능
  • Permission Set을 수정하면, 연결된 모든 계정의 IAM Role이 자동 업데이트
  • 세션 기간 설정 가능 (기본 1시간, 최대 12시간)

 

2-3. 계정 할당 (Account Assignment)

할당(Assignment)은 "누가, 어떤 계정에, 어떤 Permission Set으로 접근 가능한가" 를 정의합니다.

[Alice] + [개발 계정] + [Developer Permission Set] → Alice는 개발 계정에 Developer로 접근 가능
[Alice] + [프로덕션 계정] + [ReadOnly Permission Set] → Alice는 프로덕션 계정에 ReadOnly로만 접근 가능
[DB팀 그룹] + [모든 계정] + [DBA Permission Set] → DB팀 전원이 모든 계정에 DBA 권한으로 접근 가능

그룹에 할당하면 그룹 멤버십 변경으로 권한이 자동 조정됩니다. 신입 사원이 "개발팀" 그룹에 추가되는 순간 개발 계정 접근 권한이 자동으로 부여됩니다.

 

2-4. AWS 액세스 포털 (Access Portal)

사용자가 실제로 접속하는 웹 인터페이스입니다. 주소는 https://[조직별 서브도메인].awsapps.com/start 형태입니다.

로그인하면:

  • 접근 권한이 있는 모든 AWS 계정 목록
  • 각 계정별 사용 가능한 Permission Set (역할)
  • 클릭 한 번으로 해당 계정의 AWS 콘솔 접속
  • 임시 자격 증명 (CLI/SDK용) 복사

 

3. IAM Identity Center의 내부 동작 원리

3-1. 로그인부터 AWS 콘솔 접속까지

표면적으로는 "로그인하고 계정 클릭"이지만, 내부에서는 다음이 일어납니다.

사용자 → Access Portal 접속
   ↓
IdP 인증 (Okta/Azure AD/내부 디렉터리)
   ↓
IAM Identity Center: 세션 토큰 발급 (포털 세션, 기본 8시간)
   ↓
사용자가 계정 + Permission Set 선택
   ↓
IAM Identity Center → STS AssumeRole 내부 호출
   ↓
해당 계정에 자동 생성된 IAM Role 수임
   ↓
단기 자격 증명 반환 (기본 1시간)
   ↓
AWS 콘솔 세션 시작 / CLI 임시 자격 증명 사용

3-2. 두 가지 세션의 구분

IAM Identity Center에는 두 종류의 세션이 있습니다. 이 구분을 이해하지 못하면 "왜 1시간마다 다시 로그인해야 하지?"라는 혼란이 생깁니다.

① 포털 세션 (Access Portal Session)

  • Access Portal(awsapps.com/start)에 로그인한 세션
  • 기본 8시간, 최대 90일까지 설정 가능
  • 이 세션이 유효한 동안 재인증 없이 계정을 전환할 수 있음

② 권한 세트 세션 (Permission Set Session)

  • 특정 계정 + Permission Set으로 발급된 임시 자격 증명 세션
  • 기본 1시간, 최대 12시간
  • 이 세션이 만료되면 포털에서 다시 클릭해야 함 (포털 재로그인은 불필요)
포털 세션 (8시간) ──────────────────────────────────────────────→
                 권한세트 세션(1h)  권한세트 세션(1h)  권한세트 세션(1h) ...

CLI를 사용할 때는 토큰 자동 갱신이 지원됩니다. IAM Identity Center의 액세스 토큰은 매시간 확인되며 새로 고침 토큰을 사용하여 자동으로 새로 고쳐집니다. 포털 세션이 유효한 동안 CLI는 자동으로 자격 증명을 갱신합니다.

 

4. 외부 IdP 연동 — SAML + SCIM

4-1. SAML과 SCIM의 역할 분리

외부 IdP(Okta, Azure AD 등)와 연동할 때 두 가지 프로토콜이 함께 사용됩니다.

SAML 2.0 → 인증(Authentication)

  • 사용자가 누구인지 확인하는 역할
  • IdP가 SAML Assertion을 발급 → IAM Identity Center가 사용자 인증

SCIM 2.0 → 프로비저닝(Provisioning)

  • 사용자/그룹 정보를 자동 동기화하는 역할
  • IdP에서 SCIM 프로토콜로 IAM Identity Center로 사용자 정보를 실시간 푸시
  • 사용자 생성/수정/삭제, 그룹 멤버십 변경이 자동 반영

SAML만 쓰고 SCIM이 없으면 어떻게 될까요? IAM Identity Center는 인증은 할 수 있지만, 누가 어떤 그룹에 속하는지 알 수 없습니다. SAML 프로토콜 자체는 사용자/그룹 정보를 조회하는 기능을 제공하지 않기 때문에, IAM Identity Center에 미리 사용자와 그룹을 수동으로 프로비저닝하거나, SCIM을 통해 자동화해야 합니다.

 

4-2. SCIM 동작 방식

Okta (IdP)
   │
   │ 사용자 추가/수정/삭제 발생
   │
   ├─ SCIM API POST/PUT/DELETE
   ↓
IAM Identity Center SCIM 엔드포인트
   https://scim.us-east-1.amazonaws.com/[인스턴스ID]/scim/v2
   │
   ├─ 사용자 동기화
   ├─ 그룹 동기화
   └─ 멤버십 동기화

SCIM으로 동기화되는 것:

  • 사용자 이름(username), 이메일, 이름, 부서 등 속성
  • 그룹 및 그룹 멤버십

SCIM으로 동기화되지 않는 것:

  • 비밀번호 (인증은 여전히 IdP가 담당)
  • MFA 디바이스

 

4-3. 지원하는 외부 IdP

IdP SAML 지원 SCIM 지원 AWS 공식 통합 가이드

IdP SAML 지원  SCIM 지원 AWS 공식 통합 가이드
Okta ✅ ✅ ✅
Microsoft Entra ID (Azure AD) ✅ ✅ ✅
Google Workspace ✅ ✅ (제한적) ✅
OneLogin ✅ ✅ ✅
PingFederate ✅ ✅ ✅
JumpCloud ✅ ✅ ✅
Active Directory (직접)   AD 동기화 ✅

5. Permission Set 설계 전략

Permission Set 설계는 IAM Identity Center에서 가장 중요한 의사결정 중 하나입니다. 잘못 설계하면 관리가 복잡해지고, 잘 설계하면 수십 개 계정을 몇 개의 Permission Set으로 깔끔하게 관리할 수 있습니다.

5-1. 직무 기반 (Job Function) 설계

가장 일반적이고 권장되는 방식입니다. 업무 역할에 맞춰 Permission Set을 설계합니다.

Permission Sets:
├── AdministratorAccess   → DevOps/인프라팀 관리자
├── PowerUserAccess       → 개발자 (IAM 관리 제외)
├── ReadOnlyAccess        → 뷰어, 감사, BI팀
├── DatabaseAdmin         → DB 관리자 (RDS, DynamoDB 등)
├── SecurityAudit         → 보안팀 감사용
├── BillingAdmin          → 재무팀 (Cost Explorer, Budgets)
└── NetworkAdmin          → 네트워크팀 (VPC, Route53 등)

 

5-2. 환경별 권한 차등

같은 사람에게 환경마다 다른 권한 레벨을 부여하는 패턴입니다.

[개발자 Alice]
├── 개발 계정     → PowerUserAccess (자유롭게 개발)
├── 스테이징 계정 → ReadOnlyAccess + 특정 서비스 배포 권한
└── 프로덕션 계정 → ReadOnlyAccess (읽기 전용, 배포는 CI/CD로만)

이 패턴이 중요한 이유: 개발자가 실수로 프로덕션을 건드리는 것을 구조적으로 방지합니다.

 

5-3. Permission Set에 Permission Boundary 적용

Permission Set에도 2편에서 다룬 Permission Boundary를 적용할 수 있습니다. 이를 통해 개발자가 실수로 IAM 권한을 확장하더라도, Boundary 범위를 벗어나지 못하도록 안전망을 추가할 수 있습니다.

Permission Set: Developer
├── 정책: PowerUserAccess
└── Permission Boundary: DeveloperBoundaryPolicy
    (IAM 변경, Billing 접근 등 차단)

5-4. 계정 수에 따른 할당 전략

소규모 (계정 5개 이하): 개별 계정에 직접 할당 중규모 (계정 10~50개): 계정 태그나 OU 단위로 그룹 할당 대규모 (계정 50개 이상): Infrastructure as Code(Terraform, CDK)로 할당 자동화

 

6. AWS CLI에서 IAM Identity Center 사용하기

6-1. 왜 CLI 설정이 중요한가

IAM Identity Center를 사용하면 Access Key를 발급할 필요가 없습니다. 대신 aws sso login 명령으로 브라우저 인증을 거쳐 임시 자격 증명을 자동으로 받아옵니다.

이 방식의 장점:

  • Access Key 유출 위험 없음
  • 자동 만료 + 자동 갱신
  • 여러 계정/역할을 프로파일로 쉽게 전환
  • MFA가 브라우저 로그인에서 이미 처리됨

6-2. CLI 설정 방법

방법 1: 대화형 설정 (처음 설정할 때)

aws configure sso

SSO session name (Recommended): company-sso
SSO start URL [None]: https://d-1234567890.awsapps.com/start
SSO region [None]: ap-northeast-2
SSO registration scopes [sso:account:access]: (Enter)

# 브라우저가 열리며 로그인 진행
# 로그인 후 CLI로 돌아오면 계정 목록이 표시됨

# 사용할 계정/역할 선택
The only AWS account available to you is: 123456789012
Using the account ID 123456789012
The only role available to you is: Developer
Using the role name "Developer"

# 프로파일 이름 설정
CLI default client Region [ap-northeast-2]: ap-northeast-2
CLI default output format [None]: json
CLI profile name [Developer-123456789012]: dev-developer

방법 2: ~/.aws/config 직접 편집

# ~/.aws/config

# SSO 세션 정의 (공통)
[sso-session company]
sso_start_url = https://d-1234567890.awsapps.com/start
sso_region = ap-northeast-2
sso_registration_scopes = sso:account:access

# 개발 계정 - Developer 역할
[profile dev-developer]
sso_session = company
sso_account_id = 111111111111
sso_role_name = Developer
region = ap-northeast-2
output = json

# 스테이징 계정 - ReadOnly 역할
[profile stg-readonly]
sso_session = company
sso_account_id = 222222222222
sso_role_name = ReadOnly
region = ap-northeast-2
output = json

# 프로덕션 계정 - ReadOnly 역할
[profile prod-readonly]
sso_session = company
sso_account_id = 333333333333
sso_role_name = ReadOnly
region = ap-northeast-2
output = json

# 프로덕션 계정 - Administrator (긴급 사용)
[profile prod-admin]
sso_session = company
sso_account_id = 333333333333
sso_role_name = AdministratorAccess
region = ap-northeast-2
output = json

방법 3: 로그인 및 사용

# SSO 로그인 (브라우저 열림, 한 번만 하면 세션 동안 유효)
aws sso login --sso-session company

# 개발 계정에서 작업
aws s3 ls --profile dev-developer
aws ec2 describe-instances --profile dev-developer

# 프로덕션은 ReadOnly
aws s3 ls --profile prod-readonly
aws ec2 terminate-instances ... --profile prod-readonly
# → 권한 없음 오류 (의도된 동작)

# 현재 어떤 자격 증명인지 확인
aws sts get-caller-identity --profile dev-developer

# 로그아웃
aws sso logout

6-3. 자동 자격 증명 갱신

IAM Identity Center CLI 설정의 큰 장점 중 하나는 자동 자격 증명 갱신입니다. 포털 세션이 유효한 동안 AWS CLI와 SDK는 자격 증명이 만료되기 전에 자동으로 새로운 자격 증명을 갱신합니다. 덕분에 오래 실행되는 스크립트나 배치 작업 중 자격 증명이 만료되어 실패하는 상황을 방지할 수 있습니다.

인증 토큰 캐시는 ~/.aws/sso/cache/ 디렉터리에 저장됩니다.

 

7. 실습: IAM Identity Center 설정부터 CLI 사용까지

 

전제 조건: AWS Organizations가 활성화되어 있어야 합니다. (관리 계정에서 IAM Identity Center를 활성화합니다)

Step 1: IAM Identity Center 활성화

IAM Identity Center 콘솔 → [Enable] 클릭

→ 조직 인스턴스 선택 (권장, Organizations 관리 계정에 배포)
→ 활성화 완료 (몇 초 이내)

활성화 후 AWS 액세스 포털 URL 확인:

설정 → AWS 액세스 포털 URL:
https://d-1234567890.awsapps.com/start

이 URL을 직원들에게 공유합니다.

Step 2: 내부 디렉터리로 사용자/그룹 생성 (외부 IdP가 없는 경우)

IAM Identity Center → 사용자 → 사용자 추가

사용자 이름: alice
이름: Alice Kim
이메일: alice@example.com
→ 사용자 추가

# 비밀번호 설정 이메일이 alice@example.com으로 발송됨
IAM Identity Center → 그룹 → 그룹 생성

그룹 이름: Developers
설명: 개발팀 멤버
→ 그룹 생성 → alice 추가

Step 3: Permission Set 생성

IAM Identity Center → 권한 세트 → 권한 세트 생성

[타입 선택]
사전 정의된 권한 세트 → PowerUserAccess 선택
(또는 사용자 지정으로 직접 정책 구성)

[세부 정보]
권한 세트 이름: Developer
설명: 개발자용 - IAM 관리 제외 전체 서비스
세션 기간: 4시간

→ 생성

고급 설정 (추가 정책 연결):

권한 세트 → Developer → 편집
→ AWS 관리형 정책 추가: 필요한 경우 추가
→ 고객 관리형 정책 추가: 사내 커스텀 정책
→ 권한 경계 설정: DeveloperBoundary (선택)

Step 4: 계정에 할당

IAM Identity Center → AWS 계정 → [계정 선택]
→ 사용자 및 그룹 할당

[계정: 개발 계정 (111111111111)]
→ 그룹 할당: Developers
→ 권한 세트: Developer
→ 할당

# 자동으로 개발 계정에 IAM Role이 생성됨
# Role 이름: AWSReservedSSO_Developer_[고유ID]

Step 5: 사용자 입장에서 로그인

1. https://d-1234567890.awsapps.com/start 접속
2. alice / 비밀번호 로그인 (MFA 설정 권장)
3. 화면에 접근 가능한 계정 목록 표시:
   ┌─────────────────────────────────┐
   │ 개발 계정 (111111111111)        │
   │ Developer                [접속] │
   │ [자격 증명 복사]                │
   └─────────────────────────────────┘
4. [접속] 클릭 → 개발 계정 AWS 콘솔로 이동

Step 6: CLI 설정 및 사용

# AWS CLI v2 설치 확인
aws --version
# aws-cli/2.x.x 이상이어야 함 (v1은 SSO 지원 제한적)

# 대화형 SSO 설정
aws configure sso

SSO session name: mycompany
SSO start URL: https://d-1234567890.awsapps.com/start
SSO region: ap-northeast-2

# 브라우저에서 로그인 완료 후
# 계정 및 역할 선택 → 프로파일 이름 입력
CLI profile name: dev

# 사용
aws sso login --sso-session mycompany
aws s3 ls --profile dev
aws sts get-caller-identity --profile dev

예상 출력:

{
    "UserId": "AROA...:alice",
    "Account": "111111111111",
    "Arn": "arn:aws:sts::111111111111:assumed-role/AWSReservedSSO_Developer_xxxx/alice"
}

alice라는 사용자 이름이 CloudTrail 로그에도 기록됩니다. 여러 계정을 쓰더라도 동일한 identity로 추적 가능합니다.

 

8. 외부 IdP 연동 실습 — Okta 또는 Azure AD

8-1. Azure AD (Microsoft Entra ID) 연동 개요

전체 설정 흐름:

[1단계: Azure 포털]
Enterprise Applications → AWS IAM Identity Center 앱 추가
→ SSO 설정 (SAML) → 페더레이션 메타데이터 XML 다운로드

[2단계: IAM Identity Center 콘솔]
설정 → ID 소스 변경 → 외부 ID 제공업체
→ Azure AD 메타데이터 XML 업로드
→ IAM Identity Center 메타데이터 다운로드 → Azure에 업로드

[3단계: SCIM 설정]
IAM Identity Center → 설정 → 자동 프로비저닝 활성화
→ SCIM 엔드포인트 URL + 액세스 토큰 복사
→ Azure AD 프로비저닝 탭에서 입력

[4단계: 사용자/그룹 Azure에서 할당]
Azure AD → IAM Identity Center 앱 → 사용자/그룹 할당
→ 자동으로 IAM Identity Center에 동기화됨

8-2. SCIM 자동 프로비저닝 핵심 명령

IAM Identity Center 콘솔에서 SCIM을 활성화합니다:

IAM Identity Center → 설정 → 자동 프로비저닝
→ [활성화] 클릭

인바운드 자동 프로비저닝 정보:
SCIM 엔드포인트: https://scim.ap-northeast-2.amazonaws.com/[ID]/scim/v2/
액세스 토큰: [토큰 표시] ← 이 값을 반드시 복사해두세요 (이후 재확인 불가)

주의: SCIM 액세스 토큰은 생성 시 한 번만 전체 값을 볼 수 있습니다. 이 토큰을 외부 IdP의 SCIM 설정에 입력합니다.

 

9. 운영 시 고려사항

9-1. 퇴사자 처리 자동화

IAM Identity Center의 가장 큰 보안 이점은 퇴사자 처리 자동화입니다.

SCIM이 설정된 경우:

1. HR에서 Okta/Azure AD 계정 비활성화
   ↓
2. SCIM이 IAM Identity Center에 사용자 비활성화 신호 전달
   ↓
3. IAM Identity Center가 사용자의 모든 활성 세션 즉시 종료
   ↓
4. 모든 AWS 계정 접근 차단 (자동, 즉시)

이 과정이 수동이라면 사람이 수십 개의 계정에서 직접 하나씩 비활성화해야 하는데, 현실적으로 누락이 생기고 그 틈이 보안 위험이 됩니다.

9-2. MFA 정책

내부 디렉터리 사용 시: IAM Identity Center에서 직접 MFA 정책을 설정합니다.

IAM Identity Center → 설정 → MFA
→ MFA 적용: 모든 사용자에게 필수
→ 허용 인증 방법: 인증 앱, 보안 키 (Passkey)

외부 IdP 사용 시: MFA는 외부 IdP(Okta, Azure AD 등)에서 관리합니다. IAM Identity Center는 별도 MFA 설정이 필요 없습니다.

9-3. 감사 (CloudTrail 통합)

IAM Identity Center를 통한 모든 접근은 CloudTrail에 사용자 이름 포함 기록됩니다.

{
  "eventName": "AssumeRoleWithSAML",
  "userIdentity": {
    "type": "SAMLUser",
    "principalId": "...:alice@company.com",
    "arn": "arn:aws:sts::111111111111:assumed-role/AWSReservedSSO_Developer_xxx/alice@company.com"
  },
  "requestParameters": {
    "roleArn": "arn:aws:iam::111111111111:role/AWSReservedSSO_Developer_xxx",
    "durationSeconds": 3600
  }
}

alice@company.com이 무엇을 했는지 모든 계정에서 동일한 형식으로 추적됩니다.

 

 

 

IAM Identity Center의 본질:

  • 다중 계정 환경에서 중앙 집중적 ID 관리와 SSO의 해결책
  • 계정마다 IAM User를 만들 필요 없음
  • 외부 IdP와 SAML+SCIM으로 연동하면 완전 자동화

핵심 구성 요소:

  • 자격 증명 소스: 어디서 사용자 정보를 가져오는가
  • Permission Set: IAM Role 템플릿, 계정에 자동 Role 생성
  • 계정 할당: 누가, 어떤 계정에, 어떤 Permission Set으로

설계 원칙:

  • 직무 기반 Permission Set 설계
  • 환경마다 권한 차등 (개발 > 스테이징 > 프로덕션)
  • Administrator는 세션 기간 짧게
  • SCIM으로 퇴사자 처리 자동화

CLI:

  • aws configure sso로 설정
  • aws sso login으로 브라우저 인증
  • Access Key 없이도 모든 AWS CLI 사용 가능

 

 

참고 자료

'AWS' 카테고리의 다른 글

ERGO의 이벤트 기반 보안 자동 대응 아키텍처 분석  (0) 2026.05.09
AWS Organizations + SCP  (3) 2026.05.02
Directory Service  (0) 2026.05.02
IAM Federation + OIDC  (0) 2026.05.02
Bybit / Safe{Wallet} 사고 사례 분석  (1) 2026.04.29
'AWS' Related Articles more