Security / AWS WIKI
AWS IAM
사용자와 서비스가 AWS 리소스에 접근할 수 있는 범위를 제어합니다.
기존 기술로 보면
일반 IAM은 신원을 확인하고 권한을 부여·회수하는 체계입니다. 디렉터리·SSO·RBAC·접근 제어가 이 역할에 연결되지만 서로 같은 제품은 아닙니다.
AWS에서 달라지는 점
AWS IAM은 계정의 글로벌 서비스입니다. Principal·JSON Policy·Role·STS 임시 자격 증명으로 API/리소스 접근을 평가하며, 네트워크 경로나 OS 로그인을 대신하지 않습니다.
- 인증 ≠ 인가
- 사람은 연동 · 서비스는 Role
- Allow보다 적용 Deny 우선
누가 · 무엇을 · 어디에
- Principal사람 / 서비스의 요청 주체
- 인증자격 증명으로 신원 확인
- 권한 평가정책 · 조건 · 제한 확인
- Action → Resource허용된 작업만 실행
- 인증 Authentication
- 콘솔 로그인 또는 서명된 API 요청의 신원을 확인합니다.
- 인가 Authorization
- 인증된 요청도 Action·Resource·Condition에 맞는 권한이 있어야 합니다.
접근 설계 선택
01사람의 인증연동 / Identity Center / User
신규 환경은 임시 접근 우선. 기존 환경은 User·연동·장기 Key 의존을 먼저 조사합니다.
인증 경로를 바꾸면 콘솔/CLI 도구·복구 절차도 바뀝니다.
조건에 따라 다름변경 영향 →AWS · 임시 접근 / 최소 권한 · AWS 공식 문서 ↗02서비스의 Role앱 역할과 배포 권한 분리
EC2 앱은 Instance Profile + Role로 S3에 접근. 배포자의 PassRole 권한은 별도로 제한합니다.
역할을 누가 맡는지와 맡은 뒤 하는 일을 따로 검증합니다.
변경 가능 · 영향 있음변경 영향 →AWS · EC2 Role / Instance Profile · AWS 공식 문서 ↗03정책 관리 방식AWS / Customer / Inline
재사용·소유권·버전·연결 대상을 기준으로 선택합니다.
공유 managed 정책 변경은 여러 주체의 접근에 영향을 줍니다.
변경 가능 · 영향 있음변경 영향 →AWS · Managed / Inline 정책 · AWS 공식 문서 ↗04리소스 정책Bucket 등 지원 리소스의 허용
Principal과 Action/Resource를 지정하고 계정 경계·상한·Deny를 확인합니다.
주체 정책과 리소스 정책의 역할은 같지 않습니다.
변경 가능 · 영향 있음변경 영향 →AWS · Identity / Resource 정책 · AWS 공식 문서 ↗05최소 권한 / Condition필요 작업 · 대상 · 조건
읽기와 쓰기, Bucket과 Object ARN을 구분하고 실제 업무에서 필요한 조건을 정합니다.
와일드카드 축소는 보안을 높이지만 누락 Action으로 앱이 실패할 수 있습니다.
변경 가능 · 영향 있음변경 영향 →AWS · JSON 정책 요소 · AWS 공식 문서 ↗06교차 계정 접근호출 권한 + 대상 신뢰
호출 계정의 AssumeRole 권한과 대상 Role Trust·Permissions를 각각 확인합니다.
정확한 주체·조건 없이 신뢰를 넓히면 외부 접근 범위가 커집니다.
변경 가능 · 영향 있음변경 영향 →AWS · Role Trust / 교차 계정 · AWS 공식 문서 ↗07MFA / 복구사람의 접근 보호
MFA를 적용하고 분실·퇴사·긴급 접근 절차를 확인합니다.
MFA 등록과 모든 API에 MFA 조건을 강제하는 것은 별개입니다.
조건에 따라 다름변경 영향 →AWS · MFA / 사람의 접근 · AWS 공식 문서 ↗08권한 상한Boundary / 조직 Guardrail
위임 관리 시 상한을 검토합니다. Boundary와 SCP는 권한을 부여하지 않습니다.
잘못 제한하면 정상 배포와 운영도 AccessDenied가 됩니다.
변경 가능 · 영향 있음변경 영향 →AWS · Boundary / Resource grant 예외 · AWS 공식 문서 ↗09세션과 장기 Key만료 · 갱신 · 제거
임시 세션 갱신을 우선하고 장기 Key가 꼭 필요한 경우 사용처·소유자·유출 대응을 관리합니다.
세션 시간 변경은 기존 세션 즉시 취소가 아닙니다.
조건에 따라 다름변경 영향 →AWS · Role 세션 설정 · AWS 공식 문서 ↗주체 · 정책 · 권한 판단
누가 요청하는가와 무엇을 할 수 있는가는 별개입니다.
Root / User / Group / Role직접 ID · 정책 묶음 · 임시 역할 구분
Root계정의 최상위 주체 · 일상 작업용 아님
- 용도
- Root 전용 작업 등 꼭 필요한 경우
- 보호
- MFA·복구 경로 보호, Root Access Key 생성 회피
일반 IAM 주체의 기본 implicit deny 설명을 Root에 그대로 적용하지 않습니다. 적용되는 조직 정책 등 제한은 별도입니다.
AWS · Root 용도 / 보호 · AWS 공식 문서 ↗IAM User계정 안의 개별 ID · 지속 자격 증명 가능
- 자격 증명
- 설정한 콘솔 암호 / 장기 Access Key
- 판단
- 사람은 연동·Identity Center의 임시 접근 우선. 지원하지 않는 사용 사례에서 필요성 검토
모든 사람에게 User와 영구 키를 발급하는 것을 기본 구성으로 삼지 않습니다.
AWS · 임시 접근 / 최소 권한 · AWS 공식 문서 ↗IAM Group여러 User에 정책을 묶어 적용
- 구성원
- IAM User만 포함 · Role/다른 Group 포함 불가
- 정체
- 로그인하거나 AssumeRole하는 Principal이 아님
Bucket/Trust Policy의 Principal에 Group을 지정할 수 없습니다.
AWS · IAM Group / Principal 제약 · AWS 공식 문서 ↗IAM Role신뢰 조건을 통과하면 임시로 맡는 권한
- 자격 증명
- Role 자체에 일반 암호·장기 Access Key 없음
- 두 정책
- Trust는 누가 맡는지, Permissions는 맡고 무엇을 하는지
Role을 만들었다고 자동으로 누구나 맡거나 모든 서비스에 접근하지 않습니다.
AWS · IAM Role · AWS 공식 문서 ↗정책의 위치 · 관리 · 상한서로 다른 분류 축 · Boundary/SCP는 권한 부여 아님
연결 위치
Identity-basedUser / Group / Role에 연결
- 질문
- 이 주체가 어떤 리소스에 무엇을 할 수 있는가?
- Principal
- 연결한 주체에서 정해짐 · JSON에 Principal을 쓰지 않음
Group 정책은 구성원 User의 권한에 반영됩니다.
AWS · Identity / Resource 정책 · AWS 공식 문서 ↗Resource-based지원 리소스에 연결 · 예: S3 Bucket Policy
- 질문
- 이 리소스에 누가 어떤 작업을 할 수 있는가?
- Principal
- 접근 주체를 명시 · Role Trust Policy도 이 유형
모든 AWS 리소스가 리소스 정책을 지원하지는 않습니다.
AWS · Identity / Resource 정책 · AWS 공식 문서 ↗Identity 정책 관리 방식
AWS managedAWS가 만들고 갱신하는 재사용 정책
- 편의
- 기존 작업용 정책을 빠르게 연결
- 책임
- AWS 갱신과 내 작업 범위의 차이를 검토
쉽게 연결할 수 있다는 것이 최소 권한을 보장하지 않습니다.
AWS · Managed / Inline 정책 · AWS 공식 문서 ↗Customer managed내 계정이 소유하는 재사용 정책
- 제어
- 자체 정책·버전을 관리하고 여러 주체에 연결
- 변경
- 같은 정책을 사용하는 주체 전체에 영향
이전 버전·연결 대상을 확인하고 변경합니다.
AWS · Managed / Inline 정책 · AWS 공식 문서 ↗Inline특정 User / Group / Role에 직접 포함
- 관계
- 주체와 1:1 · 재사용 managed 정책과 다름
- 운영
- 개별 변경·백업·추적 필요
관리 방식과 연결 위치는 다른 분류 축입니다. Bucket Policy를 User의 Inline 정책과 혼동하지 않습니다.
AWS · Managed / Inline 정책 · AWS 공식 문서 ↗제한 / Guardrail
Permissions BoundaryUser / Role의 권한 상한 · 권한 부여 아님
- 일반 경로
- Identity 권한과 Boundary가 함께 허용해야 함
- 예외
- 같은 계정의 직접 User/Session ARN 리소스 권한은 implicit deny 적용이 다를 수 있음
Boundary만 붙여서는 권한이 생기지 않습니다. 적용되는 explicit deny는 여전히 우선합니다.
AWS · Boundary / Resource grant 예외 · AWS 공식 문서 ↗SCP · Organizations조직의 멤버 계정 권한 제한 · 권한 부여 아님
- 위치
- IAM 주체에 직접 연결하는 정책이 아닌 조직 Guardrail
- 범위
- 멤버 계정에 적용 · 관리 계정/Service-linked Role에는 동일 적용 아님
SCP가 허용해도 별도의 권한 부여가 필요합니다. 적용되는 상위 조직 경로의 제한도 확인합니다.
AWS · Organizations SCP 적용 범위 · AWS 공식 문서 ↗Session Policy발급 세션의 범위를 추가로 제한
- 전달
- AssumeRole 시 선택적으로 전달
- 효과
- Role Identity 권한 경로에서는 권한 확대가 아닌 교집합
직접 Session ARN에 부여한 리소스 권한의 예외는 평가 범위에서 구분합니다.
AWS · AssumeRole / 임시 자격 증명 · AWS 공식 문서 ↗Policy JSON · 요소별 의미Identity / Resource / Trust 예시
역할을 맡은 뒤 허용되는 S3 작업
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-study-bucket/reports/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "true"
}
}
}]
}Effect
Allow는 이 문장이 일치할 때 허용 근거입니다. 다른 적용 정책의 Deny까지 이기지는 않습니다.
Version은 JSON 문법 버전이며 자료 확인일이 아닙니다.
Identity 정책에는 Principal을 넣지 않습니다. 조건이 맞지 않으면 이 Allow가 적용되지 않는 것이지 explicit deny가 생성되는 것은 아닙니다.
학습용 최소 문장입니다. 배포용 완성 정책이나 전체 최소 권한을 보장하지 않습니다.
AWS · JSON 정책 요소 · AWS 공식 문서 ↗Permission Evaluation · 접근 판단허용 근거 → 적용 제한 → 결과
고정된 학습 사례 · 실제 정책 계산기가 아닙니다. 인증 성공 후 일반 IAM Role의 S3 GetObject 요청을 가정합니다. 표에 없는 정책·조건은 해당 사례에서 차단하지 않으며, 리소스는 SSE-S3 객체입니다.
같은 계정 · Identity/Resource Allow 없음
Role Session → s3:GetObject → reports/demo.txt
- 기본값일치하는 Allow 없음허용 없음
- Identity / Resource어느 쪽에도 읽기 허용 없음허용 없음
허용 없음 · Implicit deny네트워크 연결·인증 성공만으로 읽기 권한은 생기지 않습니다.
단순 교집합으로 설명할 수 없는 경우
- 같은 계정에서 User ARN 또는 STS Role Session ARN에 직접 부여한 Resource 권한은 Identity·Boundary·Session의 implicit deny 적용이 다릅니다. 정확한 Role ARN grant와 구분하세요.
- 교차 계정은 호출 계정과 대상 계정 양쪽 권한을 확인합니다. Trust/KMS 키 등은 별도의 명시적 허용 조건이 있습니다.
- SCP/RCP·Session·Endpoint Policy·S3 공개 차단·암호화 키 등 적용 요소를 실제 환경에서는 모두 확인해야 합니다. 이 사례 표가 전체 AWS 평가를 대체하지 않습니다.
Trust ≠ Permissions누가 맡는가 → 맡고 무엇을 하는가
EC2 → Service RoleEC2가 맡고, 앱은 임시 자격 증명 사용
- 신뢰
- Principal: ec2.amazonaws.com
- 권한
- Role Permissions: 필요한 S3 Action/Resource
- 연결
- EC2에는 Instance Profile로 연결 · 연결 작업자의 iam:PassRole 등 권한 별도
AWS SDK의 자격 증명 제공 경로를 사용합니다. 앱이 자신의 Role을 반복 AssumeRole해야 하는 것은 아닙니다.
AWS · EC2 Role / Instance Profile · AWS 공식 문서 ↗Lambda → Execution Role함수의 실행 주체와 권한을 분리
- 신뢰
- Principal: lambda.amazonaws.com
- 권한
- 함수가 호출할 API·로그 쓰기 등 필요한 작업
Execution Role의 Trust와 호출 리소스 권한은 서로 다른 목적입니다.
AWS · Lambda Execution Role · AWS 공식 문서 ↗계정 A → 계정 B Role호출자 권한과 대상 신뢰 양쪽 확인
- A
- 호출자에게 B의 Role ARN에 대한 sts:AssumeRole 허용
- B
- 대상 Trust에 A의 정확한 주체·조건 허용
- 수임 후
- B Role의 권한과 적용되는 제한으로 리소스 접근
신뢰만 추가해서는 교차 계정 접근이 완성되지 않습니다. 외부 주체를 과도하게 신뢰하지 않습니다.
AWS · Role Trust / 교차 계정 · AWS 공식 문서 ↗STS · 임시 자격 증명역할 수임 → 발급 → API 요청 → 만료 / 갱신
- 01AssumeRole 요청
허용된 주체가 역할 수임 요청
- 02STS 발급
신뢰·수임 권한·조건 평가
- 03임시 세션
Access Key ID + Secret + Session Token
- 04API 요청
Role Session으로 리소스 접근
- 05만료 / 갱신
만료 전에 지원 SDK 등으로 갱신
- 장기 Key와 차이
- 만료가 있는 세션이며 Session Token도 필요합니다. 예시에는 실제 자격 증명을 표시하지 않습니다.
- 수명
- 요청 시간·역할 설정·수임 방식에 따라 제한됩니다. 모든 세션이 같은 길이는 아닙니다.
- 변경
- Role 최대 세션 시간 변경은 다음 수임부터 적용됩니다. 기존 세션을 즉시 취소하는 기능이 아닙니다.
Trust 변경과 이미 발급된 세션 차단은 별개입니다. 유출 대응은 Role session revoke/해당 접근 Deny 등 적용 가능한 절차를 따로 확인합니다.
AWS · AssumeRole / 임시 자격 증명 · AWS 공식 문서 ↗AWS · Role 세션 설정 · AWS 공식 문서 ↗AWS · Role 세션 취소 / 영향 · AWS 공식 문서 ↗4가지 접근 상황EC2→S3 · 사람 · 교차 계정 · Bucket/Identity
EC2 앱 → S3서버에 영구 키를 저장하지 않는 접근
- Principal
- Instance Profile로 연결한 Role의 세션
- Trust
- EC2 서비스가 Role을 수임
- Policy
- Role에 필요한 S3 객체 읽기 · Bucket/조직 제한 확인
- 자격 증명 / 결과
- SDK가 임시 자격 증명 사용·갱신 → 허용 객체 읽기
EC2 네트워크 경로만 있어서는 접근 불가. Role 연결과 iam:PassRole 등 구성 권한도 별도입니다.
AWS · EC2 Role / Instance Profile · AWS 공식 문서 ↗사람 → 콘솔 / API연동·Identity Center·임시 접근 우선
- Principal
- 연동된 사람의 AWS Role Session
- Trust
- 선택한 연동/Identity Center의 설정
- Policy
- 업무별 권한·MFA/연동 조건 확인
- 자격 증명 / 결과
- 로그인 세션·CLI 임시 자격 증명 → 허용 업무 실행
Identity Center 상세 구축은 범위 밖입니다. 기존 IAM User는 필요성을 조사하고 장기 Key 의존을 줄입니다.
AWS · 임시 접근 / 최소 권한 · AWS 공식 문서 ↗계정 A → B의 Role수임 권한과 신뢰를 양쪽에서 확인
- Principal
- A의 호출자 → B Role의 세션
- Trust
- B가 A의 정확한 주체를 신뢰
- Policy
- A의 AssumeRole 허용 + B Role의 대상 작업 권한
- 자격 증명 / 결과
- STS 임시 자격 증명 → B Role 범위의 작업
Trust 조건·외부 위임 범위를 검토합니다. 호출자에 허용만 있거나 대상에 신뢰만 있어서는 완성되지 않습니다.
AWS · AssumeRole / 임시 자격 증명 · AWS 공식 문서 ↗S3 Bucket + Identity 정책같은 계정과 교차 계정을 구분
- Principal
- S3에 요청하는 기존 Role Session
- Trust
- S3 허용 자체가 Role 수임 신뢰를 대신하지 않음
- Policy
- 같은 계정은 부여 대상에 따라 Identity 또는 Resource Allow 가능. 교차 계정 직접 접근은 양쪽 확인
- 자격 증명 / 결과
- 기존 임시 세션 → Bucket/조직 등 제한을 통과한 작업만 허용
모든 경우를 정책의 단순 합집합/교집합 한 가지로 설명하지 않습니다.
AWS · Identity / Resource 정책 · AWS 공식 문서 ↗권한 관리와 관련 비용 구분
- IAM / STS / Identity Center서비스 사용에 추가 요금 없음
- Access Analyzer외부 분석·기본 검증과 유료 기능 구분
- 감사 / 로그CloudTrail 선택 기능·저장·전송 비용 확인
- 실제 리소스허용한 EC2 / S3 등 자체 과금
IAM이 무료여도 IAM 권한으로 실행한 EC2/S3와 선택한 분석·감사 기능은 별도 비용이 생길 수 있습니다.
비용 범위와 확인 조건금액 계산 없이 과금 대상을 구분
IAM·STS·Identity Center 사용 자체는 추가 요금이 없습니다. Access Analyzer의 외부 접근 분석·정책 검증/생성은 추가 요금이 없지만 내부 접근·미사용 접근 분석과 Custom Policy Checks는 유료입니다. 분석 종류·Region·대상 수·실행 횟수를 공식 가격표에서 확인합니다. CloudTrail의 이벤트 기록·Trail/Lake·저장 범위는 구분하며 관련 S3 등 비용도 검토합니다. 무료 범위를 AWS 전체 청구액 0원으로 해석하지 않습니다.
IAM / STS / Identity CenterAWS · IAM 역할 / 비용 / 전파 · AWS 공식 문서 ↗
Access AnalyzerAWS · Access Analyzer 요금 / 무료 범위 · AWS 공식 문서 ↗
정책 변경 · 접근 장애 · 운영
설정 변경 가능성 Matrix변경 가능 · 영향 있음 · 조건에 따라 다름
Policy 내용변경 가능 · 영향 있음연결된 주체의 접근 범위 변경
실제 Action/ARN/Condition와 의존 앱을 확인하고 작은 범위에서 검증. Customer managed는 이전 버전 보관, Inline은 별도 백업.
- 반영 / 재시작
- 전파 지연 가능 · IAM 변경 자체는 앱 재시작 요구 없음. 앱의 캐시·재인증·재시도는 별도 확인
- 기존 세션
- 발급된 세션의 후속 요청 권한도 정책 변경 영향을 받을 수 있음
- 보안 / 중단
- 누락 Allow / 추가 Deny로 앱·운영 작업 실패 가능
- 되돌림
- 이전 버전/내용 복원 · 노출되거나 삭제된 데이터는 정책 복원만으로 복구 안 됨
- AWS managed 내용은 직접 편집하지 못함
- 신규 선택과 기존 정책 변경은 영향 대상이 다름
Policy 연결 / 해제변경 가능 · 영향 있음정책을 누구에게 적용하는가
직접 연결·Group·Resource Policy 등 다른 권한 경로를 함께 조사합니다.
- 반영 / 재시작
- 전파 지연 가능 · IAM 변경 자체는 앱 재시작 요구 없음. 앱의 캐시·재인증·재시도는 별도 확인
- 기존 세션
- 후속 요청 평가에 영향 · 연결 해제가 모든 세션 취소와 같지 않음
- 보안 / 중단
- 공유 정책의 대상 누락/과다 연결 주의
- 되돌림
- 이전 연결 복원 · 다른 경로의 권한도 확인
- 정책 하나를 해제해도 다른 Allow 경로가 있을 수 있음
Role Trust변경 가능 · 영향 있음새 역할 수임의 주체 / 조건 변경
정확한 Principal·수임 경로·조건을 확인하고 EC2/Lambda/외부 계정 사용처를 검증합니다.
- 반영 / 재시작
- 전파 지연 가능 · IAM 변경 자체는 앱 재시작 요구 없음. 앱의 캐시·재인증·재시도는 별도 확인
- 기존 세션
- Trust를 좁혀도 이미 발급한 세션이 즉시 모두 취소되는 것으로 가정하지 않음
- 보안 / 중단
- 새 수임 실패·자격 증명 갱신 실패 또는 외부 수임 허용
- 되돌림
- 이전 Trust 복원 · 기존 세션 차단은 별도 절차
- 신뢰와 리소스 작업 권한을 혼동하지 않기
Access Key 교체 / 비활성화조건에 따라 다름실사용 의존성과 유출 대응 확인
장기 Key 사용처 조사 → 새 자격 증명 전환 확인 → 기존 Key 비활성화 → 삭제 판단. Secret은 생성 시만 확인 가능.
- 반영 / 재시작
- 전파 지연 가능 · IAM 변경 자체는 앱 재시작 요구 없음. 앱의 캐시·재인증·재시도는 별도 확인
- 기존 세션
- 장기 Key 비활성화와 이미 수임한 Role 세션 대응은 분리해서 확인
- 보안 / 중단
- 기존 Key 사용하는 앱 실패 · 유출 시 권한/세션까지 조사
- 되돌림
- 비활성 Key는 재활성화 가능 · 삭제한 Key/Secret은 복구 불가
- 실제 Key를 코드·로그·Wiki에 적지 않기
- 유출된 Key는 단순 재활성화로 되돌리지 않기
MFA / 인증 조건조건에 따라 다름접근 보호와 복구 경로 함께
주체별 인증 방식·장치·연동·정책 조건·복구 수단을 확인합니다.
- 반영 / 재시작
- 전파 지연 가능 · IAM 변경 자체는 앱 재시작 요구 없음. 앱의 캐시·재인증·재시도는 별도 확인
- 기존 세션
- 등록 변경만으로 기존 세션 전부 차단된다고 가정하지 않음
- 보안 / 중단
- 조건 미충족 접근 차단 · 장치 분실로 정상 사용자 잠김
- 되돌림
- 검증된 복구 경로로 재등록 · 보호 완화는 승인 검토
- MFA를 등록했다고 장기 Key의 모든 API 요청이 자동 MFA 보호되는 것은 아님
Group 구성변경 가능 · 영향 있음구성원 User의 정책 적용 변경
구성원과 그룹 정책을 비교하고 역할 변경/퇴사 처리를 검증합니다.
- 반영 / 재시작
- 전파 지연 가능 · IAM 변경 자체는 앱 재시작 요구 없음. 앱의 캐시·재인증·재시도는 별도 확인
- 기존 세션
- 구성원 User의 후속 권한 평가에 영향
- 보안 / 중단
- 직무보다 넓은 그룹 권한·기존 접근 상실
- 되돌림
- 이전 구성 복원 · 별도 User 정책 확인
- Group은 Role/연동 사용자 집합이나 요청 Principal이 아님
Permissions Boundary변경 가능 · 영향 있음Identity 경로의 상한 변경
Allow가 있어도 상한에 포함되는지 확인하고 Resource grant 대상별 예외를 검토합니다.
- 반영 / 재시작
- 전파 지연 가능 · IAM 변경 자체는 앱 재시작 요구 없음. 앱의 캐시·재인증·재시도는 별도 확인
- 기존 세션
- 후속 요청에도 상한 제한 영향 가능
- 보안 / 중단
- 운영 잠김 / 위임 관리 범위 확대
- 되돌림
- 이전 상한 복원 · 제거가 안전한 롤백이라고 가정하지 않음
- Boundary는 권한 부여가 아님
- Deny + NotPrincipal 조합은 Boundary 주체에 예상 밖 차단 가능
Role 세션 시간 / 취소조건에 따라 다름다음 수임 설정과 기존 세션 대응 구분
최대 세션 시간은 다음 수임부터 적용. 유출 세션은 해당 Role/연동 경로의 취소 절차를 별도 검토합니다.
- 반영 / 재시작
- 전파 지연 가능 · IAM 변경 자체는 앱 재시작 요구 없음. 앱의 캐시·재인증·재시도는 별도 확인
- 기존 세션
- 시간을 줄여도 기존 세션 즉시 만료 아님 · AWS 서비스 수임은 해당 최대 시간 적용 방식이 다름
- 보안 / 중단
- Revoke는 정상 사용자의 작업도 차단할 수 있음
- 되돌림
- 시간 설정 복원 가능 · 취소용 Deny를 제거하면 미만료 세션 권한이 다시 유효할 위험
- Identity Center가 만든 Role 세션은 Identity Center의 별도 취소 절차
- Role Trust 수정만으로 유출 세션 대응 완료로 보지 않기
일반적인 사용 패턴상황별 예시 · 정답이나 추천 순위 아님
사람 / 업무
연동과 임시 접근을 출발점으로
- 직무별 최소 권한·MFA
- 퇴사/직무 변경과 세션 대응
- 기존 User·Key 필요성 조사
Identity Center·IdP 전체 구축은 별도 범위
앱 / 서비스
EC2 Role 등 서비스의 임시 접근
- 앱 권한과 배포자 PassRole 분리
- SDK 갱신·실제 Action 확인
- S3·키·Endpoint 등 대상 제한 조사
앱 파일에 장기 Key 저장을 기본값으로 두지 않기
Terraform / CI/CD
변경 주체의 권한과 실행 승인
- 단기 연동 인증·실행 Role 검토
- 환경별 권한·plan/apply 분리
- CloudTrail로 변경 주체 확인
Terraform을 쓰는 것 자체가 IAM 최소 권한이나 승인 절차를 보장하지 않음
잘못 바꾸면 생기는 일통신 · 데이터 · 공개 범위 · 권한 · 비용
Root 일상 사용최상위 자격 증명으로 운영 → 넓은 계정 피해주의
필요 작업으로 한정하고 MFA·복구 경로 보호, 장기 Root Key 회피.
AWS · Root 용도 / 보호 · AWS 공식 문서 ↗오래된 / 유출 Key사용처 불명·코드에 저장 → 지속적 무단 접근주의
소유자·사용 기록 조사, 임시 접근 전환, 미사용 제거·유출 대응과 안전한 교체.
AWS · Access Key 관리 · AWS 공식 문서 ↗Wildcard / Admin 남용모든 Action/Resource를 허용 → 필요 이상 변경·데이터 접근주의
실제 API/대상/조건과 배포에 필요한 권한을 분리해 줄이고 기능 회귀 확인.
AWS · 임시 접근 / 최소 권한 · AWS 공식 문서 ↗넓은 Trust / 교차 계정외부 주체·조건 조사 누락 → 예상 밖 Role 수임주의
호출 권한과 대상 신뢰를 양쪽 확인하고 외부 접근 분석·정확한 Principal 검토.
AWS · Role Trust / 교차 계정 · AWS 공식 문서 ↗MFA 등록만 믿음API 보호·복구 조건 미확인 → Key 경로 위험 / 로그인 잠김주의
인증 방식과 MFA 강제 정책·지원 방식·대체 복구 수단을 따로 검토.
AWS · MFA 보호 API 접근 · AWS 공식 문서 ↗미사용 권한 잔존퇴사·직무 변경 후 방치 → 불필요한 접근 지속주의
User/Role/정책/Key 사용과 마지막 접근을 검토하고 안전하게 회수.
AWS · 임시 접근 / 최소 권한 · AWS 공식 문서 ↗정책 변경 후 장애조건·상한·전파 지연 미검증 → AccessDenied / 배포 실패주의
요청 주체·Action·ARN·적용 Deny를 확인하고 작은 변경·검증·복원 수단 확보.
AWS · IAM 전파 / 장애 조사 · AWS 공식 문서 ↗Trust 축소로 대응 종료이미 발급한 세션 미조사 → 미만료 접근 위험 잔존주의
발급 시점·만료·Role session revoke 등 해당 경로의 차단과 정상 사용자 영향을 확인.
AWS · Role 세션 취소 / 영향 · AWS 공식 문서 ↗구축 / 운영 확인리소스 설정과 공통 기반을 함께 확인
최소 권한 / 신뢰
- Principal·실제 Action·Resource·Condition 확인
- Trust / Permissions / Guardrail 구분
- 서비스 Role·연동 접근·MFA 검토
권한과 네트워크 연결은 별개 조건입니다.
AWS · 요청 권한 평가 / Deny / 예외 · AWS 공식 문서 ↗자격 증명 / 복구
- 미사용 자격 증명 제거·필요한 Key 안전하게 교체
- 세션 갱신·유출 차단·복구 경로 확인
- Root와 긴급 접근 보호
Role 세션 취소는 정상 사용자도 차단할 수 있습니다.
AWS · Role 세션 취소 / 영향 · AWS 공식 문서 ↗감사 / 검토
- CloudTrail 로그인·IAM/STS 변경 주체 확인
- Access Analyzer로 정책·외부/미사용 접근 검토
- 변경 전후 업무 API와 rollback 경로 검증
CloudTrail 기록과 CloudWatch 지표는 역할이 다르며 분석·보관 비용도 별도로 확인합니다.
AWS · IAM / STS CloudTrail 감사 · AWS 공식 문서 ↗프로젝트와 공통 준비에 연결
기본 3-Tier 웹 시스템 →
Access ControlAWS 작업 권한
Terraform 기반 AWS 인프라 구축/운영 →
Access Control권한: 배포 / 운영 범위