최소 권한 원칙(Least Privilege)에 따른 IAM Role 설계 가이드는 어디서 확인할 수 있나요?

최소 권한 원칙(Least Privilege) IAM 설계 가이던스

1단계: 분석 (Analyze) - 사용자의 실제 발자취 추적

처음부터 완벽한 정책을 짜는 것은 불가능에 가깝습니다. AWS가 제공하는 분석 도구를 활용하세요.

• IAM Access Analyzer: 특정 기간 동안 사용자가 실제로 호출한 API 로그(CloudTrail)를 기반으로 '딱 쓴 만큼만' 허용하는 정책 초안을 자동으로 생성해 줍니다.

• Last Accessed Information: IAM 콘솔에서 해당 사용자나 역할이 마지막으로 특정 서비스를 사용한 날짜를 확인하여, 사용하지 않는 권한을 과감히 제거하세요.

2단계: 범위 지정 (Scoping) - 리소스 레벨 권한 부여

Action: s3:*, Resource: *와 같은 와일드카드는 가장 피해야 할 습관입니다.

• 전략: Resource 항목에 전체가 아닌 특정 ARN(Amazon Resource Name)을 명시하세요.

• 예시: "모든 S3 버킷 허용"이 아니라 "arn:aws:s3:::my-production-data/*"와 같이 특정 버킷으로 범위를 좁혀야 합니다.

3단계: 가드레일 설치 (Permission Boundaries)

개별 Role의 권한이 아무리 커도, 그 Role이 넘을 수 없는 '최대 한계선'을 설정하는 기능입니다.

• 활용: 개발자에게 IAM Role 생성 권한을 주되, 그 Role이 관리자 권한을 가질 수 없도록 Permission Boundary를 걸어두면 권한 상승(Privilege Escalation) 사고를 원천 차단할 수 있습니다.

4단계: 속성 기반 접근 제어 (ABAC) 활용

사용자가 많아질수록 개별 정책 관리는 불가능해집니다. 이때 태그(Tag)를 활용하세요.

• 전략: "프로젝트A 태그를 가진 사용자는 프로젝트A 태그가 붙은 EC2만 제어할 수 있다"는 식의 정책을 하나만 짜두면, 리소스가 늘어나도 정책 수정 없이 권한이 자동 관리됩니다.

5단계: 정기적인 감사 (Audit)

보안은 '상태'가 아니라 '과정'입니다.

• Credential Report: 계정 내 모든 사용자의 비밀번호/액세스 키 변경 이력을 주기적으로 다운로드하여 점검하세요.

• IAM Access Advisor: 서비스별 미사용 기간을 체크하여 90일 이상 사용하지 않은 권한은 즉시 회수하는 프로세스를 수립하세요.

정책 유형별 비교 및 선택 기준