S3 Files 파일 시스템에 대한 클라이언트 액세스 제어
이 주제에서는 파일 시스템 정책, IAM ID 정책 및 네트워크 제어를 사용하여 어떤 클라이언트가 어떤 액세스 포인트를 통해 S3 Files 파일 시스템에 액세스할 수 있는지 제어하는 방법을 설명합니다.
S3 Files 액세스 포인트
S3 Files 액세스 포인트는 대규모 데이터 액세스 관리를 간소화하는 파일 시스템에 대한 애플리케이션별 진입점입니다. 액세스 포인트를 사용하면 액세스 포인트를 통해 이루어지는 모든 파일 시스템 요청에 대해 사용자 ID와 권한을 적용하고, 클라이언트가 지정된 루트 디렉터리와 하위 디렉터리 내의 데이터에만 액세스하도록 제한할 수 있습니다.
액세스 포인트는 클라이언트가 파일 시스템에서 수행할 수 있는 작업의 범위를 지정합니다. 어떤 클라이언트가 액세스 포인트를 사용할 수 있는지는 제한하지 않습니다. s3files:ClientMount 권한이 있는 계정의 모든 역할은 파일 시스템 정책에서 제한하지 않는 한 파일 시스템의 모든 액세스 포인트를 통해 마운트할 수 있습니다. 어떤 클라이언트가 어떤 액세스 포인트를 사용할 수 있는지 제어하려면 네트워크 제어(연결 차단), 파일 시스템 리소스 정책(ID 정책 변경 후에도 지속되는 명시적 거부), IAM ID 정책(역할에 대한 최소 권한)이라는 세 가지 계층을 결합합니다.
S3 Files는 마운트 시마다 파일 시스템 정책을 기준으로 s3files:ClientMount, s3files:ClientWrite 및 s3files:ClientRootAccess를 평가합니다. s3files:AccessPointArn 조건 키 또한 모든 마운트 시 평가되므로, 지정한 액세스 포인트를 제외한 모든 액세스 포인트를 통한 액세스를 차단하는 단일 거부 문을 작성할 수 있습니다. 필요한 작업이 거부되거나 승인되지 않으면 파일 작업이 수행되기 전에 마운트가 실패합니다. 다음 두 섹션에서는 워크로드를 특정 액세스 포인트로 제한하는 것과 워크로드의 파일 시스템 액세스를 완전히 거부하는 것이라는 두 가지 일반적인 요구 사항을 다룹니다.
특정 액세스 포인트로 액세스 제한
이 패턴은 역할(예: EC2 인스턴스 역할 또는 ECS 작업 역할)이 특정 액세스 포인트를 통해서만 파일 시스템을 마운트해야 할 때 적용됩니다. 조건 키는 s3files:AccessPointArn입니다. 정책에는 지정된 액세스 포인트에 대한 Allow와 그 외 모든 액세스 포인트에 대한 명시적 Deny가 모두 필요합니다. IAM 허용 권한 부여는 ID 및 리소스 정책 전반에 걸쳐 추가되며, 명시적 거부가 없으면 별도의 정책으로 다른 액세스 포인트에 대한 액세스 권한을 부여할 수 있습니다.
파일 시스템 정책 예시:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowComputeAOnlyViaSpecificAP", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT:role/compute-a-role" }, "Action": [ "s3files:ClientMount", "s3files:ClientWrite" ], "Condition": { "StringEquals": { "s3files:AccessPointArn": "arn:aws:s3files:REGION:ACCOUNT:file-system/fs-ID/access-point/fsap-ID" } } }, { "Sid": "DenyComputeAIfWrongAP", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::ACCOUNT:role/compute-a-role" }, "Action": "s3files:Client*", "Condition": { "StringNotEquals": { "s3files:AccessPointArn": "arn:aws:s3files:REGION:ACCOUNT:file-system/fs-ID/access-point/fsap-ID" } } } ] }
compute-a-role 역할은 요청이 fsap-ID를 대상으로 하는 경우에만 마운트 및 쓰기 권한이 허용되며, 이 파일 시스템의 다른 모든 액세스 포인트에서는 명시적으로 거부됩니다. 리소스 정책의 명시적 거부는 ID 정책으로 재정의할 수 없으므로, 나중에 더 광범위한 IAM 정책이 역할에 연결되더라도 이 제한은 유지됩니다.
마운트 명령:
sudo mount -t s3files -o accesspoint=fsap-ID fs-ID:/ /mnt/s3files
모든 액세스 포인트를 통한 워크로드 액세스 거부
이 패턴은 역할이 S3 Files 파일 시스템과 계정을 공유하지만, 어떤 액세스 포인트를 통해서나 직접적으로 마운트해서는 안 될 때 적용됩니다. 모든 액세스 포인트 사용을 차단하려면, 가장 강력한 격리 보장부터 가장 약한 격리 보장까지 순서대로 세 개의 계층을 적용합니다.
1. 네트워크 제어. compute-b-role의 인스턴스가 TCP 포트 2049의 마운트 대상에 액세스할 수 있는 권한을 부여하는 보안 그룹 규칙을 제거합니다. 네트워크 제어는 자격 증명 교환이 발생하기 전에 탑재 시도를 방지하므로 가장 복원력이 뛰어난 계층입니다. 잘못 구성된 정책으로 인해 마운트 권한이 부여되더라도 NFS 연결이 마운트 대상에 도달할 수 없습니다.
2. 파일 시스템 정책의 명시적 거부. 파일 시스템 정책에 거부 문을 포함하면, 나중에 역할에 더 광범위한 IAM 권한이 부여되더라도 마운트가 거부됩니다. 파일 시스템 리소스 정책에 있는 거부는 iam:PutRolePolicy 권한을 가진 사용자가 역할의 ID 정책을 수정하더라도 지속됩니다. s3files:PutFileSystemPolicy 권한을 가진 위탁자만 이 계층을 변경할 수 있습니다.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyComputeBOnFileSystem", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::ACCOUNT:role/compute-b-role" }, "Action": "s3files:Client*", "Resource": "*" } ] }
3. IAM ID 정책. 역할에 s3files:Client* 권한을 부여하지 마세요. 이는 마지막 계층이며, iam:PutRolePolicy 권한을 가진 관리자는 누구나 역할에 마운트 권한을 부여할 수 있으므로 가장 잘못 구성하기 쉬운 부분입니다.
파일 시스템 정책이 없으면 모든 역할이 모든 액세스 포인트를 통해 마운트 가능
파일 시스템 리소스 정책에 있는 거부는 ID 정책 수정 권한만 있는 사용자가 제거할 수 없습니다. 파일 시스템 정책이 없으면 ID 정책에 s3files:ClientMount가 포함된 모든 역할은 파일 시스템의 모든 액세스 포인트를 통해 마운트할 수 있습니다. 모든 파일 시스템에 거부 기준이 있는 파일 시스템 정책을 연결한 다음 워크로드별로 허용 문을 추가하는 것이 좋습니다.
액세스 포인트 격리 모범 사례
다음 표에는 일반적인 액세스 포인트 격리 목표에 권장되는 접근 방식이 요약되어 있습니다.
| Goal | 권장 접근 방식 |
|---|---|
| 워크로드를 단일 액세스 포인트로 제한 | 역할에 특정 액세스 포인트 ARN은 허용하고, 다른 모든 액세스 포인트는 명시적으로 거부합니다 “특정 액세스 포인트로 액세스 제한”을 참조하세요. |
| 동일한 계정 내 특정 역할의 파일 시스템 마운트 차단 | 포트 2049에 대한 네트워크 액세스를 제거하고, 파일 시스템 정책에서 거부를 설정하며, IAM에서 권한을 부여하지 않습니다. |
| 동일한 파일 시스템의 여러 워크로드를 각각 고유한 액세스 포인트로 제한 | 파일 시스템 정책에서 역할별로 하나의 허용 + 거부 페어를 유지하며, 각각에 서로 다른 액세스 포인트 ARN을 지정합니다. |
| 액세스 포인트를 통한 교차 계정 액세스 | 파일 시스템 정책을 사용하여 특정 액세스 포인트 ARN에 대한 교차 계정 역할을 부여합니다. ID 정책에만 의존하지 마세요. |