Identity & Access 관리

간략한 요약

IAM은 어떤 조건에서 어떤 조건에서 어떻게 통제되는지에 액세스 할 수있는 프로세스, 정책 및 도구 모음입니다. 목표: 중복 권리 최소화, 공격 표면 감소, 온 보딩 및 감사 가속, 규정 준수 (PCI DSS, GDPR 등) 및 측정 가능한 액세스 안정성.

기본 개념

신원: 개인 (직원, 계약자), 서비스/응용 프로그램, 장치.
인증 (AuthN): 확인하는 사람 (암호 → MFA → 비밀번호가없는 FIDO2/통과 체계).
승인 (AuthZ): "허용되는 것" (RBAC/ABAC/ReBAC, 정책) 결정.
자격 증명: 비밀번호, 키, 토큰, 인증서 (mSL).
비밀 관리: KMS/HSM/Vault, 회전, 짧은 TTL, 동적 비밀.
수명주기: JML (Joiner-Mover-Leaver) -역할 생성, 변경, 리콜.

대상 IAM 아키텍처

• IdP (ID 제공자): SSO, MFA, 디렉토리, 페더레이션 (OIDC/SAML), 위험 정책.
• PDP/PEP: 결정/시행-정책 엔진 (OPA/시더) + 응용 프로그램 포인트 (API 게이트웨이, 프록시, 서비스 메시).
• 카탈로그/HR 시스템: 직원과 역할에 의한 진실의 근원
• 프로비저닝: SCIM/자동화를 통해 액세스를 생성/수정/취소합니다.
• 감사: 중앙 집중식 로그, UEBA, 역할 및 액세스 보고서.

• SSO (+ MFA) → 토큰 문제 (OIDC/JWT/SAML) → PEP는 토큰/컨텍스트 → PDP가 정책 (역할/속성/위험) 을 결정하고 → 응용 프로그램 문제/액세스를 거부합니다.

인증: 암호에서 패스키까지

암호: 암호 관리자, 최소 12-14 자, "캘린더에 따라" 회전하지 않고 사고시 필수입니다.
기본 MFA: TOTP/WebAuthn/Push; 주요 요인으로 SMS를 피하십시오.
비밀번호없는 로그인: 중요한 도메인을위한 FIDO2/통과 키.
적응 형 권한: 위험 신호 (지리, ASN, 장치, 이상) → 추가 요인/차단이 필요합니다.

승인: RBAC, ABAC, ReBAC

RBAC: 기능에 해당하는 역할 (지원, 재무, DevOps). 간단하고 이해할 수 있지만 "성장".
ABAC: 속성 (부서, 위험 수준, 시간, 영역, 리소스 라벨) 에 대한 규칙. 확장 가능.
ReBAC: "누가 속한" 관계 (프로젝트 소유자, 팀원). 다중 테넌트 시나리오를위한 편리함.

• RBAC (기본 그리드) + ABAC/ReBAC (컨텍스트/경계) 를 결합하십시오.
• JIT (Just-In-Time): 요청/앱을 통한 임시 권한 발급, 자동 취소.
• JEA (Just-Enough Access): 운영에 대한 최소 권한.
• PAM: 세션 브로커, 스크린/명령 기록 및 단기 크레딧 발행과 함께 격리 된 "강력한" 액세스 (DB/클라우드 관리자).

연맹 및 SSO

프로토콜: OIDC (JWT 토큰), SAML 2. 0 (XML 어설 션) - 외부 제공 업체/파트너 용.
SSO: MFA를 사용한 단일 진입 지점, 피싱 감소, 중앙 집중식 리콜.
B2B/B2C: 파트너와의 연합, 도메인 제한, 도메인 기반 정책.
mSL/m2m: 서비스의 경우 단기 x.509 (SPIFFE/SVID) 또는 OAuth2 클라이언트 자격 증명을 사용하십시오.

수명주기 (JML) 및 프로비저닝

Joiner: HR/디렉토리의 계정 및 기본 역할에 대한 자동 SCIM 프로비저닝.
계산: 속성 (부서, 프로젝트, 위치) 별로 역할이 자동으로 변경됩니다.
휴가: SSO, 키, 토큰, 저장소/클라우드/CI/CD 액세스에 대한 즉각적인 리콜.
프로세스: 액세스 요청 (ITSM), SoD 매트릭스 (업무 분할), 정기적 인 액세스 검토.

비밀, 키 및 회전

KMS/HSM: 루트/크리티컬 키를 저장하고 작업 감사를 가능하게합니다.
Vault/Secrets 관리자: TTL 완료시 동적 크레딧 (DB, 클라우드), 자동 반복.
회전: 일정 및 사고시 OAuth 토큰, JWT 서명 키, 서비스 암호.
mSL: 수명이 짧은 인증서 (시간/일), 자동 재발행.

정책 및 솔루션 엔진

선언 성: Git에 매장 정책; CI (정책 테스트) 를 체크인하십시오.
상황: 시간/위치/ASN/위험 수준/장치 상태 (MDM/EDR).

rego package authz. payments default allow = false

allow {
input. user. role == "finance"
input. device. compliant == true input. action == "read"
input. resource. type == "report"
time. now_hh >= 8 time. now_hh <= 20
}

모니터링, SLO 및 감사

• AuthN/AuthZ (%) 의 성공, p95 로그인/결정 시간, MFA/비밀번호없는 입력 공유.
• JIT/PAM 에스컬레이션 수, 평균 권한 기간.
• 준수 장치의 적용 범위, 수명이 짧은 비밀의 공유.

• SSO/IdP의 가용성 한 달에 95%.
• p95 AuthZ 결정
• 오프 보드 후 계정의 100% 종료
• 감사 및 UEBA: 중앙 집중식 불변 로그 (액세스, 역할 변경, 입력 실패, PDP 솔루션), 행동 분석 및 이상 경보.

IAM의 사고-응답

토큰/키의 타협: 즉시 취소, 강제 로그아웃, 서명 키 회전, 단기 비밀 재발행.
권리 남용: 계정을 일시 중지하고 JIT/JEA를 차단하고 인근 기관에 대한 액세스 검토를 수행하십시오.
오프라인 모드 (TTL이 짧은 토큰의 임시 캐시 검증), 우선 순위 복구 절차 등 IdP를 사용할 수 없습니다.
피싱: 필수 MFA, 세션 위험 점검, 사용자에게 알림, 교육.

구름과 쿠 베르네 테스 (패턴)

Public Cloud IAM: 특권이 가장 적은 기본 역할을 사용하십시오. "영원한" 키 대신-클라우드에 대한 OIDC 연합 (IRSA/워크로드 아이덴티티) 의 워크로드.
Kubernetes: 네임 스페이스/역할별 RBAC, '클러스터 관리자' 제한; 비밀-외부 관리자를 통한; L7 정책을위한 서비스 메쉬 + OPA; 입학 컨트롤러 (서명 된 이미지, 금지 ": 최신").
API 게이트웨이: 민감한 엔드 포인트는 JWT/mTLS, 속도 제한, 서명 요청 (HMAC) 을 확인합니다.

iGaming/fintech에 대한 연습

액세스 도메인: 결제, 사기 방지, PII, 컨텐츠 제공 업체-역할 및 네트워크 세그먼트와 분리됩니다.
SoD: 상충되는 역할을 결합하지 마십시오 (예: 프로모션 + 승인 결제 생성).
PAM 및 JIT: PSP/뱅크 및 prod-DB에 액세스하려면 녹음 및 자동 리콜이있는 세션 브로커를 통해서만 가능합니다.
준수: PCI DSS-MFA, 최소 권한, CHD 영역 세분화; GDPR-데이터 최소화 원칙 및 PII 액세스 포인트 로그.
파트너 및 컨텐츠 제공 업체: 연합 및 임차인 정책; 수명이 짧은 토큰 및 IP/ASN 허용 목록.

공통 오류

"영원한" 키 및 토큰: 회전이없고 TTL → 누출 위험이 높습니다.
수동 오프 보딩: 권리 취소 → "유령" 액세스 지연.
Monolith 역할: 구성 및 속성 대신 하나의 "슈퍼 역할".
관리자 패널에서만 MFA: MFA는 모든 입력 및 중요한 작업에 대한 것이어야합니다.
"아무데도" 로그: 중앙 집중화가 없으며 UEBA → 나중에 사건을 탐지합니다.

IAM 구현 로드맵

1. 사용자/서비스/리소스 목록; 데이터 및 감도 맵.
2. 모두를위한 SSO + MFA에는 피싱 방지 요소가 포함됩니다.
3. 역할 모델: 컨텍스트에 대한 기본 RBAC + 속성 (ABAC); SoD 매트릭스.

4. SCIM 프로비저닝: HR/카탈로그에서 권리의 자동 생성/변경/취소; ITSM의 응용 프로그램 및 업데이트

5. PAM 및 JIT/JEA: 특권 액세스; 녹음 세션, 짧은 TTL.
6. 비밀 관리: 정적 키 거부; 인증서가 짧은 동적 비밀, 회전, mTLS.
7. Git + CI의 정책: 규칙 테스트, 변경 제어, 카나리아 정책 배포.
8. 관찰 및 SLO: AuthN/AuthZ 대시 보드, 경고, 정기적 인 액세스 검토.

아티팩트의 예

AWS IAM 정책 (S3 보고서를 읽기위한 최소)

json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "ReadOnlyReports",
"Effect": "Allow",
"Action": ["s3:GetObject","s3:ListBucket"],
"Resource": [
"arn:aws:s3:::reports-bucket",
"arn:aws:s3:::reports-bucket/"
],
"Condition": {
"IpAddress": { "aws:SourceIp": "203. 0. 113. 0/24" }
}
}]
}

Kubernetes RBAC (네임 스페이스 범위 개발자)

yaml apiVersion: rbac. authorization. k8s. io/v1 kind: Role metadata:
name: dev-read-write namespace: app-prod rules:
- apiGroups: ["","apps"]
resources: ["pods","deployments","services","configmaps"]
verbs: ["get","list","watch","create","update","patch","delete"]
apiVersion: rbac. authorization. k8s. io/v1 kind: RoleBinding metadata:
name: dev-bind namespace: app-prod subjects:
- kind: User name: alice@example. com roleRef:
kind: Role name: dev-read-write apiGroup: rbac. authorization. k8s. io

OIDC: ABAC 승인 (예)

json
{
"sub": "d81f0b5c-...",
"email": "bob@example. com",
"dept": "finance",
"role": "analyst",
"device_compliant": true,
"tenant": "casino-eu"
}

정책은 리소스와 일치하도록 '장치 _ 호환 = 참' 및 '테넌트' 를 요구할 수 있습니다.

체크리스트

• SSO는 모든 응용 프로그램에 활성화되어 있습니다. 기본적으로 MFA는 우선 순위가 높습니다.
• RBAC 정의; ABAC/ReBAC는 컨텍스트를 추가합니다. JIT/JEA에 의해 구현.
• PAM은 특권 액세스를 보호합니다. 세션이 기록되고 있습니다.
• HR로부터의 SCIM 프로비저닝; 오프 보드는 완전히 자동화되어 있습니다.
• 짧은 TTL로 비밀은 역동적입니다. 회전이 자동화됩니다.
• 정책은 CI에서 테스트 된 Git에서 다양합니다. 카나리아 계산이 있습니다.
• AuthN/AuthZ에 따른 대시 보드 및 SLO; 중앙 집중식 로그 및 UEBA.
• 정기 액세스 검토 및 SoD 검사; 규정 준수에 대한 보고서.

FAQ

ReBAC는 모두가 필요합니까?
아니요, 그렇지 않습니다. RBAC + ABAC는 간단한 환경에 충분합니다. ReBAC는 복잡한 자원 소유 및 다중 임대 계층에서 유용합니다.

지역 계정을 떠날 수 있습니까?

엄격한 제한 및 정기적 인 검증이있는 브레이크 글래스 및 오프라인 시나리오에만 해당됩니다

"역할 폭발" 을 줄이는 방법?
자원 세분성을 높이고 ABAC/템플릿을 사용하며 리뷰를 자동화하고 미사용 역할을 버립니다.

합계

성숙한 IAM 아키텍처는 SSO + MFA, 최소 필요한 권리, 자동화 된 JML, 중앙 집중식 정책 및 관찰 가능성입니다. RBAC를 속성 및 관계형 모델과 결합하고 JIT/JEA 및 PAM을 적용하며 프로비저닝 및 비밀 교체를 자동화함으로써 보안 및 비즈니스 요구 사항을 충족하는 관리, 감사 및 확장 가능한 액세스를 얻을 수 있습니다.