정책 및 권한

정책을 생성하고 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로 작업할 수 있다.

주제

1. 정책 유형

다음의 정책 유형은 AWS에서 사용할 수 있으며 가장 자주 사용하는 정책 유형에서 빈도가 낮은 정책 유형 순으로 나열된다.

아이덴터티 기반 정책 - 관리형 및 인라인 정책을 IAM 아이덴터티(사용자, 사용자가 속한 그룹 또는 역할)에 연결한다. 아이덴터티 기반 정책은 아이덴터티에 권한을 부여한다.
리소스 기반 정책 - 인라인 정책을 리소스에 연결한다. 리소스 기반 정책의 가장 일반적인 예제는 Amazon S3 버킷 정책 및 IAM 역할 신뢰 정책이다. 리소스 기반 정책은 정책에 지정된 보안 주체에 권한을 부여한다. 보안 주체는 리소스와 동일한 계정 또는 다른 계정에 있을 수 있다.
권한 경계 - 관리형 정책을 IAM 엔터티(사용자 또는 역할)에 대한 권한 경계로 사용한다. 해당 정책은 아이덴터티 기반 정책을 통해 엔터티에 부여할 수 있는 최대 권한을 정의하지만, 권한을 부여하지는 않는다. 권한 경계는 리소스 기반 정책을 통해 엔터티에 부여할 수 있는 최대 권한을 정의하지 않는다.
Organizations SCP - AWS Organizations 서비스 제어 정책(SCP)을 사용하여 조직 또는 조직 단위(OU)의 계정 멤버에 대한 최대 권한을 정의한다. SCP는 아이덴터티 기반 정책이나 리소스 기반 정책을 통해 계정 내 엔터티(사용자나 역할)에 부여하는 권한을 제한하지만, 권한을 부여하지는 않는다.
액세스 제어 목록(ACL) - ACL을 사용하여 ACL이 연결된 리소스에 액세스할 수 있는 다른 계정의 보안 주체를 제어한다. ACL는 리소스 기반 정책과 비슷하다. 다만 JSON 정책 문서 구조를 사용하지 않은 유일한 정책 유형이다. ACL은 지정된 보안 주체에 권한을 부여하는 교차 계정 권한 정책이다. ACL은 동일 계정 내 엔터티에 권한을 부여할 수 없다.
세션 정책 - AWS CLI 또는 AWS API를 사용하여 역할이나 페더레이션 사용자를 수임할 때 고급 세션 정책을 전달한다. 세션 정책은 역할이나 사용자의 아이덴터티 기반 정책을 통해 세션에 부여하는 권한을 제한한다. 세션 정책은 생성된 세션에 대한 권한을 제한하지 않지만, 권한을 부여하지도 않는다.

1) 아이덴터티 기반 정책

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

관리형 정책 - AWS 계정에 속한 다수의 사용자, 그룹 및 역할에게 독립적으로 연결할 수 있는 아이덴터티 기반 정책이다. 두 가지 유형의 관리형 정책이 있다.
- AWS 관리형 정책 - AWS에서 생성 및 관리하는 관리형 정책이다.
- 고객 관리형 정책 - 사용자가 자신의 AWS 계정에서 생성 및 관리하는 관리형 정책이다. 고객 관리형 정책은 AWS 관리형 정책보다 정책에 대해 더욱 정밀하게 제어할 수 있다.
인라인 정책 - 단일 사용자, 그룹 또는 역할에 직접 추가하는 정책이다. 인라인 정책은 정책과 아이덴터티를 정확히 1대 1 관계로 유지한다. 이는 아이덴터티를 삭제하면 삭제된다.

2) 리소스 기반 정책

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

교차 계정 액세스를 활성화하려는 경우 전체 계정이나 다른 계정의 IAM 개체를 리소스 기반 정책의 보안 주체로 지정할 수 있다. 리소스 기반 정책에 교차 계정 보안 주체를 추가하는 것은 트러스트 관계 설정의 절반밖에 되지 않는다는 것을 유념한다. 또한 보안 주체와 리소스가 별도의 AWS 계정에 있는 경우 아이덴터티 기반 정책을 사용하여 보안 주체에 리소스에 대한 액세스 권한을 부여해야 한다. 하지만 리소스 기반 정책이 동일 계정의 보안 주체에 액세스를 부여하는 경우 추가 아이덴터티 기반 정책이 필요하지 않다.

IAM 서비스는 역할 신뢰 정책이라고 하는 리소스 기반 정책 유형 하나만 지원하며, 이 유형은 IAM 역할에 연결된다. IAM 역할은 아이덴터티이기도 하고 리소스 기반 정책을 지원하는 리소스이기도 하다. 그러므로 IAM 역할에 신뢰 정책과 아이덴터티 기반 정책을 모두 연결해야 한다. 신뢰 정책은 역할을 수임할 수 있는 보안 주체 엔터티(계정, 사용자, 역할 및 페더레이션 사용자)를 정의한다.

3) IAM 권한 경계

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

4) 서비스 제어 정책(SCP)

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

5) ACL(액세스 제어 목록)

ACL(액세스 제어 목록)은 리소스에 액세스할 수 있는 다른 계정의 보안 주체를 제어할 수 있는 서비스 정책이다. ACL은 동일 계정 내에서 보안 주체에 대한 액세스를 제어하는 데 사용할 수 없다. ACL는 리소스 기반 정책과 비슷하다. 다만 JSON 정책 문서 형식을 사용하지 않은 유일한 정책 유형이다. Amazon S3, AWS WAF 및 Amazon VPC는 ACL을 지원하는 대표적인 서비스이다.

6) 세션 정책

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

AssumeRole, AssumeRoleWithSAML 또는 AssumeRoleWithWebIdentity API 작업을 사용하여 프로그래밍 방식으로 역할 세션을 생성하고 세션 정책을 전달할 수 있다. Policy 파라미터를 사용하여 단일 JSON 인라인 세션 정책 문서를 전달할 수 있다. PolicyArns 파라미터를 사용하여 최대 10개까지 관리형 세션 정책을 지정할 수 있다.

페더레이션 사용자 세션을 생성할 경우 IAM 사용자의 액세스 키를 사용하여 GetFederationToken API 작업을 프로그래밍 방식으로 호출할 수 있다. 또한 세션 정책도 전달해야 한다. 결과적으로 얻는 세션의 권한은 IAM 사용자의 아이덴터티 기반 정책과 세션 정책의 교집합이다.

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

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

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

2. 정책 및 루트 사용자

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

3. JSON 정책 개요

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

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

JSON 정책을 생성하거나 편집할 때 IAM은 효과적인 정책을 생성하는 데 도움이 되는 정책 검증을 수행할 수 있다. IAM은 JSON 구문 오류를 식별하는 반면, IAM Access Analyzer는 정책을 더욱 구체화하는 데 도움이 되는 권장 사항과 함께 추가 정책 검사를 제공한다.

1) JSON 정책 문서 구조

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

문서 상단에 위치하는 정책 전반의 선택적 정보
하나 이상의 개별 문

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

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

Version - 사용하고자 하는 정책 언어의 버전을 지정한다. 가장 좋은 방법은 최신 2012-10-17 버전을 사용하는 것이다.
Statement - 이 주요 정책 요소를 다음 요소의 컨테이너로 사용한다. 정책에 설명문 둘 이상을 포함할 수 있다.
Sid(선택 사항) - 선택 설명문 ID를 포함하여 설명문들을 구분한다.
Effect - Allow 또는 Deny를 사용하여 정책에서 액세스를 허용하는지 또는 거부하는지 여부를 설명한다.
Principal(일부 상황에서만 필요) - 리소스 기반 정책을 생성하는 경우 액세스를 허용하거나 거부할 계정, 사용자, 역할 또는 페더레이션 사용자를 표시해야 한다. 사용자 또는 역할에 연결할 IAM 권한 정책을 생성하면 이 요소를 포함할 수 없다. 보안 주체는 사용자 또는 역할을 의미한다.
Action - 정책이 허용하거나 거부하는 작업 목록을 포함한다.
Resource(일부 상황에서만 필요) - IAM 권한 정책을 생성하는 경우 작업이 적용되는 리소스 목록을 지정해야 한다. 리소스 기반 정책을 생성하는 경우 이 요소는 선택 사항이다. 이 요소를 포함하지 않으면 작업이 적용되는 리소스는 정책이 연결된 리소스이다.
Condition(선택 사항) - 정책에서 권한을 부여하는 상황을 지정한다.

2) 복수의 문 및 복수의 정책

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

정책의 제한된 크기로 인해 더 복잡한 권한에 대해서는 여러 정책을 사용해야 할 수도 있다. 개별 사용자 관리형 정책에 권한의 기능적 그룹화를 만드는 방법이 좋다. 예를 들어, 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"}}
    }
  ]
}

3) 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/*"
    ]
  }]
}

4. 최소 권한 부여

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

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

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

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

액세스 수준 그룹화 이해 - 액세스 수준 그룹화를 사용하면 정책이 부여하는 액세스 수준을 이해할 수 있다. 정책 작업은 List, Read, Write, Permissions management 또는 Tagging으로 분류된다. 예를 들어 List 및 Read 액세스 레벨에서 작업을 선택하여 사용자에게 읽기 전용 액세스 권한을 부여할 수 있다.
정책 검증 - JSON 정책을 생성 및 편집할 때 IAM Access Analyzer를 사용하여 정책 검증을 수행할 수 있다. 기존 정책을 모두 검토하고 검증하는 것이 좋다. IAM Access Analyzer는 정책 검증을 위해 100개 이상의 정책 확인 항목을 제공한다. 정책의 문이 지나치게 허용적이라고 생각되는 액세스를 허용하는 경우 보안 경고를 생성한다. 최소 권한을 부여하기 위해 작업할 때 보안 경고를 통해 제공되는 실행 가능한 권장 사항을 사용할 수 있다.
액세스 활동에 기반한 정책 생성 - 부여하는 권한을 세분화할 수 있도록 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 CloudTrail에서 계정 이벤트 검토 - 권한을 추가로 줄이려면 AWS CloudTrail 이벤트 기록의 계정 이벤트를 볼 수 있다. CloudTrail 이벤트 로그에는 정책의 권한을 줄이는 데 사용할 수 있는 자세한 이벤트 정보가 포함되어 있다. 로그에는 IAM 엔터티에 필요한 작업 및 리소스만 포함되어 있다.

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

Amazon DynamoDB 개발자 안내서의 Amazon DynamoDB에 대한 인증 및 액세스 제어
Amazon Simple Storage Service 사용 설명서의 버킷 정책 및 사용자 정책 사용
Amazon Simple Storage Service 사용 설명서의 액세스 제어 목록(ACL) 개요

References

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/access_policies.html