IAM 리소스 - AWS 규범적 지침

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

IAM 리소스

간단한 설문조사를 통해 AWS 보안 참조 아키텍처 (AWSSRA) 의 미래에 영향을 미치세요.

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. 기업에는 많은 중앙 집중식 팀 (예: 클라우드 플랫폼, 보안 운영 또는 ID 및 액세스 관리 팀) 이 있어 이러한 독립 제어의 책임을 분담하고 서로의 정책을 동료 검토합니다. 표의 예는 플레이스홀더입니다. 기업에 가장 효과적인 직무 분리를 결정해야 합니다.

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

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

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

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

  6. 가능하면 (로컬 IAM 사용자 대신) ID 페더레이션을 사용하십시오.

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

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

  9. 이러한 선택적 정책은 계정 공급 중에 제공되거나 애플리케이션 개발 프로세스의 일부로 제공될 수 있습니다. 이러한 정책을 만들고 첨부할 수 있는 권한은 애플리케이션 개발자의 자체 권한에 따라 관리됩니다.

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

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

 IAM ID에 잘 설명된 일련의 작업에 필요한 권한만 갖도록 하는 것은 악의적이거나 의도하지 않은 권한 남용의 위험을 줄이는 데 매우 중요합니다. 최소 권한 모델을 수립하고 유지하려면 과도한 권한을 지속적으로 업데이트, 평가 및 완화하기 위한 신중한 계획이 필요합니다. 해당 계획에 대한 몇 가지 추가 권장 사항은 다음과 같습니다.

  • 조직의 거버넌스 모델과 확립된 위험 수용 범위를 사용하여 구체적인 가드레일과 권한 경계를 설정하세요.

  • 지속적으로 반복되는 프로세스를 통해 최소 권한을 구현하세요. 이는 한 번의 연습이 아닙니다.

  • SCP를 사용하여 실행 가능한 위험을 줄이세요. 이는 광범위한 가드레일을 위한 것이지, 대상을 좁히는 통제를 위한 것이 아닙니다.

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

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

  • defense-in-depth 접근 방식으로는 (ID 기반 정책과 함께) 리소스 기반 IAM 정책을 사용하여 리소스에 대한 광범위한 액세스를 거부하십시오.

  • IAM 액세스 어드바이저, AWS CloudTrail, AWS IAM 액세스 분석기 및 관련 도구를 사용하여 과거 사용 및 부여된 권한을 정기적으로 분석하십시오. 명백한 과다 권한을 즉시 수정하십시오.

  • 모든 리소스를 나타내는 와일드카드로 별표를 사용하는 대신 해당하는 경우 특정 리소스로 광범위한 조치를 취하십시오.

  • 요청에 따라 IAM 정책 예외를 신속하게 식별, 검토 및 승인하는 메커니즘을 구현하십시오.