IAM 리소스 - AWS 권장 가이드

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

IAM 리소스

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

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

 

사용 사례 또는 정책

효과

에서 관리

용도

와 관련됨

영향

에 배포됨

서비스 제어 정책(SCP)

제한

플랫폼 또는 보안 팀과 같은 중앙 팀 [1]

가드레일, 거버넌스

조직, OU, 계정

조직, OU 및 계정의 모든 보안 주체

조직 관리 계정 [2]

리소스 제어 정책(RCPs)

제한

플랫폼 또는 보안 팀과 같은 중앙 팀 [1]

가드레일, 거버넌스

조직, OU, 계정

멤버 계정의 리소스 [12]

조직 관리 계정 [2]

기준 계정 자동화 정책(플랫폼이 계정을 운영하는 데 사용하는 IAM 역할)

권한 부여 및 제한

플랫폼, 보안 또는 IAM 팀과 같은 중앙 팀 [1]

(기준) 워크로드가 아닌 자동화 역할에 대한 권한 [3]

단일 계정 [4]

멤버 계정 내에서 자동화에 사용되는 보안 주체

멤버 계정

기본 인적 정책(사용자에게 작업을 수행할 수 있는 권한을 부여하는 IAM 역할)

권한 부여 및 제한

플랫폼, 보안 또는 IAM 팀과 같은 중앙 팀 [1]

인적 역할에 대한 권한 [5]

단일 계정 [4]

페더레이션 보안 주체 [5] 및 IAM 사용자 [6]

멤버 계정

권한 경계(권한 있는 개발자가 다른 보안 주체에게 할당할 수 있는 최대 권한)

제한

플랫폼, 보안 또는 IAM 팀과 같은 중앙 팀 [1]

애플리케이션 역할에 대한 가드레일(적용해야 함)

단일 계정 [4]

이 계정의 애플리케이션 또는 워크로드에 대한 개별 역할 [7]

멤버 계정

애플리케이션에 대한 시스템 역할 정책(개발자가 배포한 인프라에 연결된 역할)

권한 부여 및 제한

개발자에게 위임 [8]

애플리케이션 또는 워크로드에 대한 권한 [9]

단일 계정

이 계정의 보안 주체

멤버 계정

리소스 정책

권한 부여 및 제한

개발자에게 위임 [8,10]

리소스에 대한 권한

단일 계정

계정의 보안 주체 [11]

멤버 계정

중앙 루트 사용자 관리

권한 부여 및 제한

플랫폼, 보안 또는 IAM 팀과 같은 중앙 팀 [1]

멤버 계정 루트 사용자를 대규모로 중앙에서 관리

Organization

멤버 계정의 모든 루트 사용자

조직 관리 계정, 위임된 관리자 계정

  

테이블의 참고 사항:

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

  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 정책은 모든 계정의 모든 보안 주체를 참조하여 리소스에 대한 액세스를 허용하거나 거부할 수 있습니다. 익명 보안 주체를 참조하여 퍼블릭 액세스를 활성화할 수도 있습니다.

  12. RCPs AWS 서비스의 하위 집합에 대한 리소스에 적용됩니다. 자세한 내용은 AWS Organizations 설명서의 RCPs를 지원하는 AWS 서비스 목록을 참조하세요. AWS Organizations

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

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

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

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

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

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

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

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

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

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