IAM 리소스 - AWS 규범적 지침

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

IAM 리소스

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

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

 

사용 사례 또는 정책

효과

관리 대상

용도

관련

영향

에 배포됨

서비스 제어 정책(SCPs)

제한

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

가드레일, 거버넌스

조직, OU, 계정

Organization, 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 StackSetsWord를 사용하여 여러 계정에 복제하거나 배포할 수 있습니다.

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

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

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

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

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

  10. 로컬 계정 권한 외에도 중앙 집중식 팀(예: 클라우드 플랫폼 팀 또는 보안 운영 팀)은 종종 일부 리소스 기반 정책을 관리하여 계정 간 액세스를 통해 계정을 운영할 수 있도록 합니다(예: 로깅을 위한 S3 버킷에 대한 액세스 제공).

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

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

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

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

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

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

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

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

  • IAM 액세스 어드바이저, AWS CloudTrailWord, AWS IAM Access Analyzer 및 관련 도구를 사용하여 부여된 과거 사용량 및 권한을 정기적으로 분석합니다. 명백한 초과 권한을 즉시 해결합니다.

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

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