[AWS 실험] 6 - S3 Deep Dive: 액세스 포인트

시작하기 전에 액세스 포인트, ACL, 버킷 정책, IAM, 미리 서명된 URL 등과 같은 내부/외부 액세스에서 S3 버킷 액세스를 제한하는 방법은 너무 많습니다. 이번 포스팅에서는 Access Point가 무엇인지, 어떻게 사용하는지에 대해 집중적으로 설명하겠습니다.

1. 액세스 포인트란?

AWS의 공식 문서에 따르면 Access Point는 ...

"As an application set grows, the bucket policy becomes more complex, time consuming to manage, and needs to be audited to make sure that changes don’t have an unexpected impact on another application."(Amazon Web Services)

"Amazon S3 Access Points, a feature of S3, simplify data access for any AWS service or customer application that stores data in S3. With S3 Access Points, customers can create unique access control policies for each access point to easily control access to shared datasets."(Amazon Web Services)

Access Point는 많은 사용자 수준 액세스를 구성하려는 경우에 유용합니다. 주로 버킷 수준 액세스를 처리하고 제약 조건이 상당히 적다면 버킷 정책을 고수하는 것이 여전히 최선의 선택이 될 것입니다. 선택은 전적으로 개발자에게 달려 있습니다. 개인적으로 소규모 프로젝트는 Access Point를 사용하여 S3 접근성을 관리할 필요가 없다고 생각합니다.

그러나 여전히 미래의 큰 프로젝트에서는 버킷 정책이 매우 커질 경우를 대비하여 Access Point로 작업하는 방법을 아는 것이 매우 중요합니다. Access Point 정책을 사용하면 정책을 세분화하고 구성할 수 있기 때문입니다.

2. 그렇다면 Access Point는 어떻게 사용하나요?

워크플로우는 간단합니다. 먼저 s3:DataAccessPointArn , s3:DataAccessPointAccount 및 s3:AccessPointNetworkOrigin 와 같은 특수 태그를 사용하여 IAM 사용자에게 제한된 S3 권한을 부여합니다. 둘째, 버킷 정책 및 액세스 포인트 정책을 구성하여 액세스 포인트를 통해서만 사용자에게 S3 권한을 부여합니다.

3. IAM 정책을 이용한 간단한 실험

실험 워크플로우

IAM 사용자에게 제한된 s3 권한을 부여합니다.

버킷에 대한 액세스 포인트를 생성하고 IAM 사용자가 액세스할 수 있도록 합니다.

예상되는 동작

IAM 사용자가 버킷에 직접 액세스하여 s3:GetObject를 수행하면 객체 대신 Access Denied 오류가 발생합니다.

IAM 사용자가 생성된 Access Point를 통해 버킷에 액세스하여 s3:GetObject를 수행하면 사용자가 객체를 가져옵니다.

s3:GetObject 및 s3:PutObject를 제외한 전체 s3 권한이 있는 IAM 사용자를 생성합니다. 요청이 액세스 포인트에서 오지 않는 경우 해당 작업을 거부합니다demo-access-point. 나는 s3:DataAccessPointArn 속성을 사용했습니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::*",
                "arn:aws:s3:*:<ACCOUNT_ID>:accesspoint/demo-access-point",
                "arn:aws:s3:*:<ACCOUNT_ID>:accesspoint/demo-access-point/*"
            ]
        },
        {
            "Effect": "Deny",
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotLike": {
                    "s3:DataAccessPointArn": "arn:aws:s3:*:<ACCOUNT_ID>:accesspoint/*"
                }
            }
        }
    ]
}

액세스 포인트를 만들지 않았으므로 새로 만들어 보겠습니다.

고유한 이름으로 버킷을 생성합니다. demo-for-access-point-tutorial를 사용했습니다.

파일을 업로드하고 이름이 demo-access-point인 액세스 포인트를 생성합니다. 액세스 포인트 정책의 경우 IAM 사용자가 s3:GetObject 및 s3:PutObject를 수행하도록 허용합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GetObject",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<ACCOUNT_ID>:user/DemoAccessPointUser"
            },
            "Action": ["s3:GetObject","s3:PutObject"],
            "Resource": "arn:aws:s3:<REGION><ACCOUNT_ID>:accesspoint/demo-access-point/object/*"
        }
    ]
}

축하해요! 액세스 포인트 정책 및 IAM 정책을 사용하여 사용자의 s3 GetObject 및 PutObject 권한을 제한했습니다!

출력물을 확인해보자

사례 #1: 버킷을 통해 객체에 액세스 시도

사례 #2: 액세스 포인트를 통해 객체에 액세스 시도

4. 결론

Access Point는 버킷의 버킷 정책이 너무 커서 관리하기 어려울 수 있기 때문에 특정 버킷에 대한 액세스를 제한해야 하는 IAM 사용자 및 그룹이 많을 때 유용할 수 있습니다.