IAM 리소스

간단한 설문 조사에 참여하여 AWS 보안 참조 아키텍처(AWS SRA)의 미래에 영향을 미칩니다.

AWS Identity and Access Management(IAM)는 기존 아키텍처 다이어그램에 포함된 서비스가 아니지만 AWS 조직, AWS 계정 및 AWS 서비스의 모든 측면을 다룹니다. 먼저 IAM 엔터티를 생성하고 권한을 부여하지 않으면 AWS 서비스를 배포할 수 없습니다. IAM에 대한 전체 설명은이 문서의 범위를 벗어나지만이 섹션에서는 모범 사례 권장 사항 및 추가 리소스에 대한 포인터에 대한 중요한 요약을 제공합니다.

• IAM 모범 사례는 AWS 설명서의 IAM의 보안 모범 사례, AWS 보안 블로그의 IAM 문서, AWS re:Invent 프레젠테이션을 참조하세요.

• AWS Well-Architected 보안 원칙은 권한 가드레일 정의, 최소 권한 액세스 권한 부여, 퍼블릭 및 크로스 계정 액세스 분석, 리소스를 안전하게 공유, 지속적인 권한 감소, 긴급 액세스 프로세스 설정 등 권한 관리 프로세스의 주요 단계를 간략하게 설명합니다.

• 다음 표와 함께 제공되는 참고 사항은 사용 가능한 IAM 권한 정책 유형 및 보안 아키텍처에서 이를 사용하는 방법에 대한 권장 지침의 개략적인 개요를 제공합니다. 자세한 내용은 적절한 IAM 정책 혼합 선택에 대한 AWS re:Invent 2020 동영상을 참조하세요.

 

사용 사례 또는 정책	효과	에서 관리	용도	관련	영향	에 배포됨
서비스 제어 정책(SCP)	제한	플랫폼 또는 보안 팀과 같은 중앙 팀 [1]	가드레일, 거버넌스	조직, OU, 계정	조직, OU 및 계정의 모든 보안 주체	조직 관리 계정 [2]
기준 계정 자동화 정책(플랫폼이 계정을 운영하는 데 사용하는 IAM 역할)	권한 부여 및 제한	플랫폼, 보안 또는 IAM 팀과 같은 중앙 팀 [1]	(기준) 워크로드가 아닌 자동화 역할에 대한 권한 [3]	단일 계정 [4]	멤버 계정 내에서 자동화에 사용되는 보안 주체	멤버 계정
기준 인적 정책(사용자에게 작업을 수행할 수 있는 권한을 부여하는 IAM 역할)	권한 부여 및 제한	플랫폼, 보안 또는 IAM 팀과 같은 중앙 팀 [1]	인적 역할에 대한 권한 [5]	단일 계정 [4]	페더레이션 보안 주체 [5] 및 IAM 사용자 [6]	멤버 계정
권한 경계(권한 있는 개발자가 다른 보안 주체에게 할당할 수 있는 최대 권한)	제한	플랫폼, 보안 또는 IAM 팀과 같은 중앙 팀 [1]	애플리케이션 역할에 대한 가드레일(적용해야 함)	단일 계정 [4]	이 계정의 애플리케이션 또는 워크로드에 대한 개별 역할 [7]	멤버 계정
애플리케이션에 대한 시스템 역할 정책(개발자가 배포한 인프라에 연결된 역할)	권한 부여 및 제한	개발자에게 위임 [8]	애플리케이션 또는 워크로드에 대한 권한 [9]	단일 계정	이 계정의 보안 주체	멤버 계정
리소스 정책	권한 부여 및 제한	개발자에게 위임 [8,10]	리소스에 대한 권한	단일 계정	계정의 보안 주체 [11]	멤버 계정

  

테이블의 참고 사항:

1. 기업은 이러한 독립적인 제어의 책임을 나누고 서로의 정책을 동료 검토하는 중앙 집중식 팀(예: 클라우드 플랫폼, 보안 운영 또는 자격 증명 및 액세스 관리 팀)을 많이 보유하고 있습니다. 테이블의 예제는 자리 표시자입니다. 기업에 가장 효과적인 업무 분리를 결정해야 합니다.

2. SCPs 사용하려면 AWS Organizations 내의 모든 기능을 활성화해야 합니다.

3. 파이프라인에 대한 권한, 배포 도구, 모니터링 도구(예: AWS Lambda 및 AWS Config 규칙) 및 기타 권한과 같은 자동화를 활성화하려면 일반적인 기준 역할 및 정책이 일반적으로 필요합니다. 이 구성은 일반적으로 계정이 프로비저닝될 때 전달됩니다.

4. 이는 단일 계정의 리소스(예: 역할 또는 정책)와 관련이 있지만 AWS CloudFormation StackSets를 사용하여 여러 계정에 복제하거나 배포할 수 있습니다.

5. 중앙 팀이 모든 멤버 계정에 배포하는 기본 인적 역할 및 정책의 핵심 세트를 정의합니다(대개 계정 프로비저닝 중에). 플랫폼 팀의 개발자, IAM 팀, 보안 감사 팀을 예로 들 수 있습니다.

6. 가능하면 자격 증명 페더레이션(로컬 IAM 사용자 대신)을 사용합니다.

7. 권한 경계는 위임된 관리자가 사용합니다. 이 IAM 정책은 최대 권한을 정의하고 다른 정책(리소스에 대한 모든 작업을 허용하는 "*:*" 정책 포함)을 재정의합니다. 권한 경계는 역할(예: 워크로드 성능 역할)을 생성하고 정책을 연결하기 위한 조건으로 기준 인적 정책에 필요합니다. SCPs와 같은 추가 구성은 권한 경계의 연결을 적용합니다.

8. 이는 충분한 가드레일(예: SCPs 및 권한 경계)이 배포되었다고 가정합니다.

9. 이러한 선택적 정책은 계정 프로비저닝 중에 또는 애플리케이션 개발 프로세스의 일부로 제공될 수 있습니다. 이러한 정책을 생성하고 연결할 수 있는 권한은 애플리케이션 개발자의 자체 권한에 의해 관리됩니다.

10. 로컬 계정 권한 외에도 중앙 집중식 팀(예: 클라우드 플랫폼 팀 또는 보안 운영 팀)은 계정 운영을 위한 교차 계정 액세스(예: 로깅을 위해 S3 버킷에 대한 액세스 제공)를 활성화하기 위해 일부 리소스 기반 정책을 관리하는 경우가 많습니다.

11. 리소스 기반 IAM 정책은 모든 계정의 모든 보안 주체를 참조하여 리소스에 대한 액세스를 허용하거나 거부할 수 있습니다. 익명 보안 주체를 참조하여 퍼블릭 액세스를 활성화할 수도 있습니다.

 IAM 자격 증명에 잘 설명된 작업 세트에 필요한 권한만 있는지 확인하는 것은 악의적이거나 의도하지 않은 권한 침해 위험을 줄이는 데 매우 중요합니다. 최소 권한 모델을 설정하고 유지하려면 초과 권한을 지속적으로 업데이트, 평가 및 완화하기 위한 신중한 계획이 필요합니다. 다음은 해당 계획에 대한 몇 가지 추가 권장 사항입니다.

• 조직의 거버넌스 모델과 설정된 위험 선호도를 사용하여 특정 가드레일 및 권한 경계를 설정합니다.

• 지속적인 반복 프로세스를 통해 최소 권한을 구현합니다. 이는 일회성 연습이 아닙니다.

• SCPs 사용하여 실행 가능한 위험을 줄입니다. 이는 좁은 대상 제어가 아닌 광범위한 가드레일입니다.

• 권한 경계를 사용하여 IAM 관리를 더 안전한 방식으로 위임합니다.

  • 위임된 관리자가 자신이 생성하는 역할 및 사용자에게 적절한 IAM 경계 정책을 연결해야 합니다.

• defense-in-depth 접근 방식(자격 증명 기반 정책과 함께)으로 리소스 기반 IAM 정책을 사용하여 리소스에 대한 광범위한 액세스를 거부합니다.

• IAM Access Advisor, AWS CloudTrail, AWS IAM Access Analyzer 및 관련 도구를 사용하여 부여된 과거 사용량 및 권한을 정기적으로 분석합니다. 명백한 초과 권한을 즉시 해결합니다.

• 별표를 와일드카드로 사용하여 모든 리소스를 표시하는 대신 해당하는 경우 특정 리소스에 대한 광범위한 작업의 범위를 지정합니다.

• 요청에 따라 IAM 정책 예외를 빠르게 식별, 검토 및 승인하는 메커니즘을 구현합니다.