S3 Files 파일 시스템에 대한 클라이언트 액세스 제어

S3 Files 파일 시스템에 대한 클라이언트 액세스 제어 (Control client access to an S3 Files file system)

이 주제에서는 파일 시스템 정책, 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가 있는 역할은 파일 시스템의 어떤 액세스 포인트로도 마운트할 수 있어요. 모든 파일 시스템에 거부 기준선이 있는 파일 시스템 정책을 연결한 다음 워크로드별 허용 문을 추가할 것을 권장해요.

액세스 포인트 격리를 위한 모범 사례

다음 표는 일반적인 액세스 포인트 격리 목표에 대한 권장 접근 방식을 요약해요.