IAM의 정책 및 권한

정책을 생성하고 IAM 자격 증명(사용자, 사용자 그룹 또는 역할) 또는 AWS 리소스에 연결하여 AWS에서 액세스를 관리합니다. 정책은 자격 증명이나 리소스와 연결될 때 해당 권한을 정의하는 AWS의 객체입니다. AWS는 IAM 보안 주체(사용자 또는 역할)가 요청을 보낼 때 이러한 정책을 평가합니다. 정책에서 권한은 요청이 허용되거나 거부되는지를 결정합니다. 대부분의 정책은 AWS에 JSON 문서로 저장됩니다. AWS에서는 자격 증명 기반 정책, 리소스 기반 정책, 권한 경계, Organizations SCP, ACL 및 세션 정책이라는 여섯 가지 정책 유형을 지원합니다.

IAM 정책은 태스크를 수행하기 위해 사용하는 방법과 상관없이 작업에 대한 권한을 정의합니다. 예를 들어, 정책이 GetUser 작업을 허용한다면 이 정책이 있는 사용자는 AWS Management Console, AWS CLI, 또는 AWS API에서 사용자 정보를 얻을 수 있습니다. IAM 사용자를 생성할 경우 콘솔 또는 프로그래밍 방식 액세스를 허용하도록 선택할 수 있습니다. 콘솔 액세스가 허용되는 경우 IAM 사용자는 로그인 보안 인증 정보를 사용하여 콘솔에 로그인할 수 있습니다. 프로그래밍 방식의 액세스가 허용되는 경우 사용자는 액세스 키를 사용하여 CLI 또는 API로 작업할 수 있습니다.

정책 유형

다음의 정책 유형은 AWS에서 사용할 수 있으며 가장 자주 사용하는 정책 유형에서 빈도가 낮은 정책 유형순으로 나열됩니다. 자세한 정보는 각 정책 유형에 따른 섹션을 참조하세요.

• 아이덴티티 기반 정책 - 관리형 및 인라인 정책을 IAM 아이덴티티(사용자, 사용자가 속한 그룹 또는 역할)에 연결합니다. 자격 증명 기반 정책은 자격 증명에 권한을 부여합니다.

• 리소스 기반 정책 - 인라인 정책을 리소스에 연결합니다. 리소스 기반 정책의 가장 일반적인 예제는 Amazon S3 버킷 정책 및 IAM 역할 신뢰 정책입니다. 리소스 기반 정책은 정책에 지정된 보안 주체에 권한을 부여합니다. 보안 주체는 리소스와 동일한 계정 또는 다른 계정에 있을 수 있습니다.

• 권한 경계 - 관리형 정책을 IAM 엔터티(사용자 또는 역할)에 대한 권한 경계로 사용합니다. 해당 정책은 자격 증명 기반 정책을 통해 엔터티에 부여할 수 있는 최대 권한을 정의하지만, 권한을 부여하지는 않습니다. 권한 경계는 리소스 기반 정책을 통해 엔터티에 부여할 수 있는 최대 권한을 정의하지 않습니다.

• Organizations SCP - AWS Organizations 서비스 제어 정책(SCP)을 사용하여 조직 또는 조직 단위(OU)의 계정 멤버에 대한 최대 권한을 정의합니다. SCP는 자격 증명 기반 정책이나 리소스 기반 정책을 통해 계정 내 엔터티(사용자나 역할)에 부여하는 권한을 제한하지만, 권한을 부여하지는 않습니다.

• 액세스 제어 목록(ACL) - ACL을 사용하여 ACL이 연결된 리소스에 액세스할 수 있는 다른 계정의 보안 주체를 제어합니다. ACL는 리소스 기반 정책과 비슷합니다. 다만 JSON 정책 문서 구조를 사용하지 않은 유일한 정책 유형입니다. ACL은 지정된 보안 주체에 권한을 부여하는 크로스 계정 권한 정책입니다. ACL은 동일 계정 내 엔터티에 권한을 부여할 수 없습니다.

• 세션 정책 - AWS CLI 또는 AWS API를 사용하여 역할이나 페더레이션 사용자를 수임할 때 고급 세션 정책을 전달합니다. 세션 정책은 역할이나 사용자의 자격 증명 기반 정책을 통해 세션에 부여하는 권한을 제한합니다. 세션 정책은 생성된 세션에 대한 권한을 제한하지 않지만, 권한을 부여하지도 않습니다. 자세한 정보는 세션 정책을 참조하세요.

자격 증명 기반 정책

자격 증명 기반 정책은 자격 증명(사용자, 사용자 그룹 및 역할)이 무슨 작업을 어느 리소스에서 어떤 조건에서 수행할 수 있는지를 제어하는 JSON 권한 정책 문서입니다. 자격 증명 기반 정책을 추가로 분류할 수 있습니다.

• 관리형 정책 - AWS 계정에 속한 다수의 사용자, 그룹 및 역할에 독립적으로 연결할 수 있는 자격 증명 기반 정책입니다. 두 가지 유형의 관리형 정책이 있습니다.

  • AWS 관리형 정책 - AWS에서 생성 및 관리하는 관리형 정책입니다.

  • 고객 관리형 정책 - 사용자가 자신의 AWS 계정에서 생성 및 관리하는 관리형 정책입니다. 고객 관리형 정책은 AWS 관리형 정책보다 정책에 대해 더욱 정밀하게 제어할 수 있습니다.

• 인라인 정책 - 단일 사용자, 그룹 또는 역할에 직접 추가하는 정책입니다. 인라인 정책은 정책과 자격 증명을 정확히 1대 1 관계로 유지합니다. 이는 자격 증명을 삭제하면 삭제됩니다.

관리형 정책을 사용할지 아니면 인라인 정책을 사용할지를 선택하는 방법은 관리형 정책과 인라인 정책의 선택 섹션을 참조하세요.

리소스 기반 정책

리소스 기반 정책은 Amazon S3 버킷과 같은 리소스에 연결하는 JSON 정책 문서입니다. 이러한 정책은 지정된 보안 주체에 해당 리소스에 대한 특정 작업을 수행할 수 있는 권한을 부여하고 이러한 권한이 적용되는 조건을 정의합니다. 리소스 기반 정책은 인라인 정책입니다. 관리형 리소스 기반 정책은 없습니다.

크로스 계정 액세스를 활성화하려는 경우 전체 계정이나 다른 계정의 IAM 개체를 리소스 기반 정책의 보안 주체로 지정할 수 있습니다. 리소스 기반 정책에 크로스 계정 보안 주체를 추가하는 것은 트러스트 관계 설정의 절반밖에 되지 않는다는 것을 유념하세요. 또한 보안 주체와 리소스가 별도의 AWS 계정에 있는 경우 자격 증명 기반 정책을 사용하여 보안 주체에 리소스에 대한 액세스 권한을 부여해야 합니다. 하지만 리소스 기반 정책이 동일 계정의 보안 주체에 액세스를 부여하는 경우 추가 자격 증명 기반 정책이 필요하지 않습니다. 교차 서비스 액세스 권한을 부여하기 위한 단계별 지침은 튜토리얼: IAM 역할을 사용한 AWS 계정 간 액세스 권한 위임 섹션을 참조하세요.

IAM 서비스는 역할 신뢰 정책이라고 하는 리소스 기반 정책 유형 하나만 지원하며, 이 유형은 IAM 역할에 연결됩니다. IAM 역할은 자격 증명이기도 하고 리소스 기반 정책을 지원하는 리소스이기도 합니다. 그러므로 IAM 역할에 신뢰 정책과 자격 증명 기반 정책을 모두 연결해야 합니다. 신뢰 정책은 역할을 수임할 수 있는 보안 주체 엔터티(계정, 사용자, 역할 및 페더레이션 사용자)를 정의합니다. IAM 역할과 다른 리소스 기반 정책 간의 차이에 대해 알아보려면 IAM의 크로스 계정 리소스 액세스 섹션을 참조하세요.

리소스 기반 정책을 지원하는 다른 서비스를 확인하려면 AWS IAM으로 작업하는 서비스 섹션을 참조하세요. 리소스 기반 정책에 대해 자세히 알아보려면 자격 증명 기반 정책 및 리소스 기반 정책 섹션을 참조하세요. 해당 신뢰 영역(신뢰할 수 있는 조직 또는 계정) 외의 계정 내 보안 주체가 역할을 수임하는 권한이 있는지 자세히 알고 싶다면, IAM Access Analyzer란 무엇일까요?를 참조하세요.

IAM 권한 경계

권한 경계는 자격 증명 기반 정책을 통해 IAM 엔터티에 부여할 수 있는 최대 권한을 설정하는 고급 기능입니다. 엔터티에 대한 권한 경계를 설정할 경우 해당 엔터티는 자격 증명 기반 정책 및 관련 권한 경계 모두에서 허용되는 작업만 수행할 수 있습니다. 사용자나 역할을 보안 주체로 지정하는 리소스 기반 정책은 권한 경계에 제한을 받지 않습니다. 이러한 정책 중 하나에 포함된 명시적 거부는 허용을 재정의합니다. 권한 경계에 대한 자세한 정보는 IAM 엔터티의 권한 범위 섹션을 참조하세요.

서비스 제어 정책(SCP)

AWS Organizations는 기업이 소유하는 AWS 계정을 그룹화하고 중앙에서 관리할 수 있는 서비스입니다. 조직에서 모든 기능을 활성화할 경우 서비스 제어 정책(SCP)을 임의의 또는 모든 계정에 적용할 수 있습니다. SCP는 조직 또는 조직 단위(OU)에 최대 권한을 지정하는 JSON 정책입니다. SCP는 각 AWS 계정 루트 사용자를 비롯하여 멤버 계정의 엔터티에 대한 권한을 제한합니다. 이러한 정책 중 하나에 포함된 명시적 거부는 허용을 재정의합니다.

Organizations 및 SCP에 대한 자세한 내용은 AWS Organizations 사용 설명서의 SCP 작동 방식을 참조하세요.

ACL(액세스 제어 목록)

ACL(액세스 제어 목록)은 리소스에 액세스할 수 있는 다른 계정의 보안 주체를 제어할 수 있는 서비스 정책입니다. ACL은 동일 계정 내에서 보안 주체에 대한 액세스를 제어하는 데 사용할 수 없습니다. ACL는 리소스 기반 정책과 비슷합니다. 다만 JSON 정책 문서 형식을 사용하지 않은 유일한 정책 유형입니다. Amazon S3, AWS WAF 및 Amazon VPC는 ACL을 지원하는 대표적인 서비스입니다. ACL에 대해 자세히 알아보려면 Amazon Simple Storage Service 개발자 안내서의 ACL(액세스 제어 목록) 개요를 참조하세요.

세션 정책

세션 정책은 역할 또는 페더레이션 사용자에 대해 임시 세션을 프로그래밍 방식으로 생성할 때 파라미터로 전달하는 고급 정책입니다. 세션에 대한 권한은 세션을 생성하는 데 사용되는 IAM 엔터티(사용자 또는 역할)에 대한 자격 증명 기반 정책과 세션 정책의 교집합입니다. 또한 권한을 리소스 기반 정책에서 가져올 수도 있습니다. 이러한 정책 중 하나에 포함된 명시적 거부는 허용을 재정의합니다.

AssumeRole, AssumeRoleWithSAML 또는 AssumeRoleWithWebIdentity API 작업을 사용하여 프로그래밍 방식으로 역할 세션을 생성하고 세션 정책을 전달할 수 있습니다. Policy 파라미터를 사용하여 단일 JSON 인라인 세션 정책 문서를 전달할 수 있습니다. PolicyArns 파라미터를 사용하여 최대 10개까지 관리형 세션 정책을 지정할 수 있습니다. 역할 세션 생성에 대한 자세한 정보는 임시 보안 자격 증명 요청 섹션을 참조하세요.

페더레이션 사용자 세션을 생성할 경우 IAM 사용자의 액세스 키를 사용하여 GetFederationToken API 작업을 프로그래밍 방식으로 호출할 수 있습니다. 또한 세션 정책도 전달해야 합니다. 결과적으로 얻는 세션의 권한은 자격 증명 기반 정책과 세션 정책의 교집합입니다. 페더레이션 사용자 생성에 대한 자세한 정보는 GetFederationToken - 사용자 지정 아이덴티티 브로커를 통한 페더레이션 단원을 참조하십시오.

리소스 기반 정책에서 사용자 또는 역할의 ARN을 보안 주체로 지정할 수 있습니다. 이 경우, 세션이 생성되기 전에 리소스 기반 정책의 권한이 역할 또는 사용자의 자격 증명 기반 정책에 추가됩니다. 이 세션 정책은 리소스 기반 정책 및 자격 증명 기반 정책을 통해 부여되는 모든 권한을 제한합니다. 결과적으로 얻는 세션의 권한은 세션 정책과 리소스 기반 정책에 추가로 자격 증명 기반 정책의 교집합입니다.

리소스 기반 정책에서 세션의 ARN을 보안 주체로 지정할 수 있습니다. 이 경우, 세션이 생성된 후 리소스 기반 정책의 권한이 추가됩니다. 리소스 기반 정책 권한은 세션 정책에 제한을 받지 않습니다. 결과 세션에는 리소스 기반 정책의 모든 권한 + 자격 증명 기반 정책과 세션 정책의 권한 교집합이 부여됩니다.

권한 경계를 사용하여 세션을 생성하는 데 사용되는 사용자 또는 역할의 최대 권한 설정할 수 있습니다. 이 경우, 결과적으로 얻는 세션의 권한은 세션 정책, 권한 경계 및 자격 증명 기반 정책의 교집합입니다. 단, 권한 경계는 결과 세션의 ARN을 지정하는 리소스 기반 정책이 부여하는 권한을 제한할 수 없습니다.

정책 및 루트 사용자

AWS 계정 루트 사용자는 어떤 정책에는 영향을 받지만 이외의 정책에는 영향을 받지 않습니다. 자격 증명 기반 정책을 루트 사용자로 연결할 수 없고 루트 사용자에 대한 권한 경계를 설정할 수 없습니다. 그러나, 루트 사용자를 리소스 기반 정책 또는 ACL의 보안 주체로 지정할 수 있습니다. 루트 사용자는 여전히 계정의 멤버입니다. 계정이 AWS Organizations의 조직 멤버인 경우 루트 사용자는 계정의 SCP에 의해 영향을 받습니다.

JSON 정책 개요

대부분의 정책은 AWS에 JSON 문서로서 저장됩니다. 자격 증명 기반 정책, 경계를 설정할 수 있는 정책은 사용자 또는 역할에 연결할 수 있는 JSON 정책 문서입니다. 리소스 기반 정책은 리소스에 연결하는 JSON 정책 문서입니다. SCP는 AWS Organizations 조직 단위(OU)에 연결하는 제한된 구문이 있는 JSON 정책 문서입니다. ACL은 리소스에도 연결되지만 다른 구문을 사용해야 합니다. 세션 정책은 역할 또는 페더레이션 사용자 세션을 수임할 때 제공하는 JSON 정책입니다.

JSON 구문을 이해할 필요가 없습니다. AWS Management Console의 시각적 편집기를 사용하면 JSON을 사용하지 않고 고객 관리형 정책을 생성하고 편집할 수 있습니다. 그러나 그룹 또는 복잡한 정책에 대해 인라인 정책을 사용하는 경우에는 콘솔을 사용하여 JSON 편집기에서 해당 정책을 생성하고 편집해야 합니다. 시각적 편집기 사용에 대한 자세한 정보는 IAM 정책 생성 및 IAM 정책 편집 섹션을 참조하세요.

JSON 정책을 생성하거나 편집할 때 IAM은 효과적인 정책을 생성하는 데 도움이 되는 정책 검증을 수행할 수 있습니다. IAM은 JSON 구문 오류를 식별하는 반면, IAM Access Analyzer는 정책을 더욱 구체화하는 데 도움이 되는 권장 사항과 함께 추가 정책 검사를 제공합니다. 정책 검증에 대한 자세한 내용은 IAM 정책 검증 섹션을 참조하세요. IAM Access Analyzer 정책 확인 및 실행 가능한 권장 사항에 대한 자세한 내용은 IAM Access Analyzer 정책 검증을 참조하세요.

JSON 정책 문서 구조

다음 그림처럼 JSON 정책 문서는 이러한 요소를 포함합니다.

• 문서 상단에 위치하는 정책 전반의 선택적 정보

• 하나 이상의 개별 문

각 설명문에는 단일 권한에 대한 정보가 포함되어 있습니다. 정책에 설명문이 여러 개 포함되어 있는 경우, AWS는 설명문을 평가하는 동안 전체에 대해 논리 OR을 적용합니다. 요청 하나에 적용되는 정책이 여럿인 경우, AWS는 정책을 평가하는 동안 전체에 걸쳐 논리 OR을 적용합니다.

문의 정보는 일련의 요소 안에 포함되어 있습니다.

• Version - 사용하고자 하는 정책 언어의 버전을 지정합니다. 최신 2012-10-17 버전을 사용하는 것이 좋습니다. 자세한 정보는 IAM JSON 정책 요소: Version 섹션을 참조하세요.

• Statement - 이 주요 정책 요소를 다음 요소의 컨테이너로 사용합니다. 정책에 설명문 둘 이상을 포함할 수 있습니다.

• Sid(선택 사항) - 선택 설명문 ID를 포함하여 설명문들을 구분합니다.

• Effect - Allow 또는 Deny를 사용하여 정책에서 액세스를 허용하는지 또는 거부하는지 여부를 설명합니다.

• Principal(일부 상황에서만 필요) - 리소스 기반 정책을 생성하는 경우 액세스를 허용하거나 거부할 계정, 사용자, 역할 또는 페더레이션 사용자를 표시해야 합니다. 사용자 또는 역할에 연결할 IAM 권한 정책을 생성하면 이 요소를 포함할 수 없습니다. 보안 주체는 사용자 또는 역할을 의미합니다.

• Action - 정책이 허용하거나 거부하는 작업 목록을 포함합니다.

• Resource(일부 상황에서만 필요) - IAM 권한 정책을 생성하는 경우 작업이 적용되는 리소스 목록을 지정해야 합니다. 리소스 기반 정책을 생성하는 경우 이 요소는 선택 사항입니다. 이 요소를 포함하지 않으면 작업이 적용되는 리소스는 정책이 연결된 리소스입니다.

• Condition(선택 사항) - 정책에서 권한을 부여하는 상황을 지정합니다.

이러한 요소와 기타 더 고급 정책 요소에 대한 자세한 정보는 IAM JSON 정책 요소 참조 섹션을 참조하세요.

복수의 문 및 복수의 정책

엔터티(사용자 또는 역할)에 부여할 권한을 하나 이상 정의하고자 할 경우, 단일 정책에 여러 설명문을 사용할 수 있습니다. 여러 정책을 연결할 수도 있습니다. 단일한 설명문에 여러 권한을 정의하고자 할 경우, 정책이 기대하는 액세스를 보장하지 않을 수 있습니다. 리소스 유형에 따라 정책을 나누는 것이 좋습니다.

정책의 제한된 크기로 인해 더 복잡한 권한에 대해서는 여러 정책을 사용해야 할 수도 있습니다. 개별 사용자 관리형 정책에 권한의 기능적 그룹화를 만드는 방법이 좋습니다. 예를 들어, IAM 사용자 관리용 정책 하나, 자기 관리용 하나 및 S3 버킷 관리용 기타 정책 하나를 생성합니다. 여러 설명문과 여러 정책의 조합과 상관없이 AWS는 동일한 방식으로 정책을 평가합니다.

예를 들어, 다음 정책에는 설명문이 세 개 있으며 각 설명문은 단일 계정에 별도의 권한 세트를 부여합니다. 설명문은 다음을 정의합니다.

• Sid(설명문 ID)의 FirstStatement 첫 번째 설명문은 연결된 정책으로 사용자가 자체 암호를 변경하도록 허용합니다. 이 문에서 Resource 요소는 “*”(“모든 리소스”를 의미)이지만 실제로 ChangePassword API 작업(또는 동등한 change-password CLI 명령)은 요청을 수행한 사용자의 암호에만 영향을 미칩니다.

• 두 번째 문은 사용자가 자신의 AWS 계정에 있는 모든 Amazon S3 버킷을 나열할 수 있도록 합니다. 이 문에서 Resource 요소는 "*"("모든 리소스"를 의미)이지만 정책에서 다른 계정의 리소스에 대한 액세스 권한을 부여하지 않으므로 사용자는 자신의 AWS 계정에 있는 버킷만 나열할 수 있습니다.

• 세 번째 설명문은 사용자가 confidential-data라는 버킷에 있는 객체를 나열 및 검색할 수 있도록 하지만, 이는 사용자가 멀티 팩터 인증(MFA)에서 인증한 경우에 한합니다. 정책의 Condition 요소는 MFA 인증을 수행합니다.

  정책 문에 Condition 요소가 포함된 경우, Condition 요소가 true로 평가된 경우에만 해당 문이 유효합니다. 이때 Condition은 사용자가 MFA 인증된 경우 true로 평가됩니다. 사용자가 MFA 인증되지 않은 경우, 이 Condition은 false로 평가됩니다. 이 경우 이 정책의 세 번째 설명문과 사용자는 confidential-data 버킷을 적용하지 않고 이에 액세스할 수 없습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "FirstStatement",
      "Effect": "Allow",
      "Action": ["iam:ChangePassword"],
      "Resource": "*"
    },
    {
      "Sid": "SecondStatement",
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "*"
    },
    {
      "Sid": "ThirdStatement",
      "Effect": "Allow",
      "Action": [
        "s3:List*",
        "s3:Get*"
      ],
      "Resource": [
        "arn:aws:s3:::confidential-data",
        "arn:aws:s3:::confidential-data/*"
      ],
      "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
    }
  ]
}

JSON 정책 구문 예제

다음 자격 증명 기반 정책은 example_bucket이라는 하나의 Amazon S3 버킷 목록에 암시된 보안 주체를 허용합니다.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::example_bucket"
  }
}

다음 리소스 기반 정책은 Amazon S3 버킷에 연결될 수 있습니다. 이 정책에서는 특정 AWS 계정 구성원이 mybucket라는 버킷의 모든 Amazon S3 작업을 수행할 수 있도록 합니다. 작업 내 버킷 또는 객체에 수행될 수 있는 모든 작업을 허용합니다. (이 정책은 계정에만 신뢰를 부여하므로, 해당 계정의 개별 사용자는 지정된 Amazon S3 작업에 대한 권한을 다시 부여받아야 합니다.)

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "1",
    "Effect": "Allow",
    "Principal": {"AWS": ["arn:aws:iam::account-id:root"]},
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::mybucket",
      "arn:aws:s3:::mybucket/*"
    ]
  }]
}

공통 시나리오가 포함되는 예제 정책은 IAM 자격 증명 기반 정책의 예 섹션을 참조하세요.

최소 권한 부여

IAM 정책을 생성할 때는 최소 권한 부여의 표준 보안 조언을 따르거나, 작업 수행에 필요한 최소한의 권한만 부여합니다. 사용자(역할)가 수행해야 하는 작업을 파악한 후 사용자들이 해당 작업만 수행하도록 사용자에 대한 정책을 작성합니다.

최소한의 권한 조합으로 시작하여 필요에 따라 추가 권한을 부여합니다. 처음부터 권한을 많이 부여한 후 나중에 줄이는 방법보다 이 방법이 안전합니다.

최소 권한의 대안으로 AWS 관리형 정책 또는 와일드카드(*)를 사용하는 정책 권한을 사용하여 정책을 시작할 수 있습니다. 보안 주체가 작업을 수행하는 데 필요한 것보다 더 많은 권한을 부여할 경우 보안 위험을 고려하세요. 이러한 보안 주체를 모니터링하여 사용 중인 권한을 확인합니다. 그런 다음 최소 권한 정책을 작성합니다.

IAM에서는 부여하는 권한을 구체화하는 데 도움이 되는 몇 가지 옵션을 제공합니다.

• 액세스 수준 그룹화 이해 - 액세스 수준 그룹화를 사용하면 정책이 부여하는 액세스 수준을 이해할 수 있습니다. 정책 작업은 List, Read, Write, Permissions management 또는 Tagging으로 분류됩니다. 예를 들어 List 및 Read 액세스 레벨에서 작업을 선택하여 사용자에게 읽기 전용 액세스 권한을 부여할 수 있습니다. 정책 요약을 사용하여 액세스 레벨 권한을 이해하는 방법에 대해 알아보려면 정책 요약의 액세스 레벨 이해하기 섹션을 참조하세요.

• 정책 검증 - JSON 정책을 생성 및 편집할 때 IAM Access Analyzer를 사용하여 정책 검증을 수행할 수 있습니다. 기존 정책을 모두 검토하고 검증하는 것이 좋습니다. IAM Access Analyzer는 정책 검증을 위해 100개 이상의 정책 확인 항목을 제공합니다. 정책의 문이 지나치게 허용적이라고 생각되는 액세스를 허용하는 경우 보안 경고를 생성합니다. 최소 권한을 부여하기 위해 작업할 때 보안 경고를 통해 제공되는 실행 가능한 권장 사항을 사용할 수 있습니다. IAM Access Analyzer가 제공하는 정책 확인 사항에 대한 자세한 내용은 IAM Access Analyzer 정책 검증을 참조하세요.

• 액세스 활동에 기반한 정책 생성 - 부여하는 권한을 세분화할 수 있도록 IAM 엔터티(사용자 또는 역할)의 액세스 활동을 기반으로 IAM 정책을 생성할 수 있습니다. IAM Access Analyzer는 사용자의 AWS CloudTrail 로그를 검토하고 지정된 기간에 역할에 의해 사용된 권한이 포함된 정책 템플릿을 생성합니다. 이 템플릿을 사용하여 세분화된 권한이 포함된 관리형 정책을 생성한 다음 IAM 엔터티에 연결할 수 있습니다. 이렇게 하면 특정 사용 사례에 사용자나 역할이 AWS 리소스와 상호 작용하는 데 필요한 권한만 부여됩니다. 자세한 내용은 액세스 활동을 기반으로 정책 생성 섹션을 참조하세요.

• 마지막으로 액세스한 정보 사용 - 최소 권한으로 도울 수 있는 또 다른 기능은 마지막으로 액세스한 정보입니다. IAM 사용자, 그룹, 역할 또는 정책에 대한 IAM 콘솔 세부 정보 페이지의 액세스 관리자(Access Advisor) 탭에서 이 정보를 확인합니다. 마지막으로 액세스한 정보에는 Amazon EC2, IAM, Lambda, Amazon S3와 같은 일부 서비스에 마지막으로 액세스하여 작업한 정보가 포함됩니다. AWS Organizations 관리 계정 자격 증명을 사용하여 로그인하는 경우 IAM 콘솔의 AWS Organizations 섹션에서 마지막으로 액세스한 서비스 정보를 볼 수 있습니다. 또한 AWS CLI 또는 AWS API를 사용하여 IAM 또는 조직의 엔터티 또는 정책에 대해 마지막으로 액세스한 정보 보고서를 검색할 수 있습니다. 이 정보를 사용하여 불필요한 권한을 확인할 수 있으므로 IAM 또는 Organizations 정책을 미세 조정함으로써 최소 권한의 원칙을 보다 잘 준수할 수 있습니다. 자세한 내용은 마지막으로 액세스한 정보를 사용하여 AWS에서의 권한 재정의 섹션을 참조하세요.

• AWS CloudTrail에서 계정 이벤트 검토 - 권한을 추가로 줄이려면 AWS CloudTrail 이벤트 기록의 계정 이벤트를 볼 수 있습니다. CloudTrail 이벤트 로그에는 정책의 권한을 줄이는 데 사용할 수 있는 자세한 이벤트 정보가 포함되어 있습니다. 로그에는 IAM 엔터티에 필요한 작업 및 리소스만 포함되어 있습니다. 자세한 내용은 AWS CloudTrail 사용 설명서의 CloudTrail 콘솔에서 CloudTrail 이벤트 보기를 참조하세요.

자세한 내용은 서비스별 리소스에 대해 정책을 작성하는 방법의 예제를 제공하는 각 서비스의 다음 정책 주제를 참조하세요.

• Amazon DynamoDB 개발자 안내서의 Amazon DynamoDB에 대한 인증 및 액세스 제어

• Amazon Simple Storage Service 사용 설명서의 버킷 정책 및 사용자 정책 사용

• Amazon Simple Storage Service 사용 설명서의 액세스 제어 목록(ACL) 개요