Amazon S3의 계정 간 접근 방식에 대해 자세히 살펴보겠습니다. 다양한 방법을 통해 S3 객체에 접근할 수 있으며, 각 방법은 특정 상황에서 유용하게 사용될 수 있습니다. 이번 글에서는 S3의 계정 간 접근 방식을 세 가지 주요 방법으로 나누어 설명하겠습니다.
1. IAM 정책과 S3 버킷 정책 사용
S3 객체에 대한 가장 일반적인 계정 간 접근 방법은 IAM 정책과 S3 버킷 정책을 사용하는 것입니다. 이 방식은 계정 간 접근 권한을 세부적으로 제어할 수 있으며, 대부분의 경우에 적합합니다.
IAM 정책은 특정 사용자나 역할이 S3 버킷의 객체에 대해 어떤 작업을 수행할 수 있는지 정의합니다. 또한 S3 버킷 정책은 특정 S3 버킷에 대한 접근 권한을 제어하며, 버킷에 대한 권한을 설정할 수 있습니다.
2. IAM 정책과 ACL 사용 (비권장)
두 번째 방법은 **IAM 정책과 접근 제어 목록(ACL)**을 사용하는 것입니다. 그러나 ACL은 더 이상 권장되지 않으며, 2023년 4월부터 기본적으로 비활성화되었습니다. ACL을 사용하려면 버킷 소유자 강제 설정(Bucket Owner Enforced Setting)을 비활성화해야 합니다. 새로 생성된 모든 S3 버킷은 기본적으로 이 설정이 활성화되어 있기 때문에, ACL을 통한 접근 제어는 사용되지 않습니다.
ACL을 사용할 경우, 객체를 업로드한 사용자 또는 계정이 객체의 소유자가 됩니다. 다른 계정에서 객체에 접근하려면 객체 소유자가 접근을 허용해야 하므로, ACL을 사용하는 방식은 복잡하고 관리하기 어렵습니다.
Canned ACL
ACL을 사용할 때는 Canned ACL이라는 단축 ACL을 사용할 수 있습니다. 예를 들어, 객체를 업로드할 때 x-amz-acl 헤더에 bucket-owner-full-control을 지정하면, 해당 객체의 소유권을 버킷 소유자에게도 부여할 수 있습니다. 하지만 Canned ACL은 단축 방식으로, 더 이상 권장되지 않으며 ACL을 피하는 것이 좋습니다.
3. 계정 간 IAM 역할 사용
세 번째 방법은 계정 간 IAM 역할을 사용하는 것입니다. 이 방식은 계정 간의 리소스 접근을 허용하는 가장 직관적이고 간단한 방법 중 하나입니다.
계정 A에서 IAM 역할을 생성하고, 이 역할에 대한 접근 권한을 계정 B의 IAM 사용자에게 부여할 수 있습니다. 이렇게 하면 계정 B의 사용자는 계정 A의 리소스에 접근할 수 있게 됩니다. IAM 역할을 사용하면 S3 버킷 정책을 별도로 설정할 필요 없이, IAM 역할의 정책으로만 API 호출을 승인할 수 있어 보안 모델을 간소화할 수 있습니다.
S3 객체 소유권 및 권한 관리
S3에서는 객체를 업로드한 사용자나 계정이 해당 객체의 소유자가 됩니다. 이는 객체 소유권(Object Ownership) 개념으로, 버킷 소유자와 객체 소유자가 다를 수 있기 때문에 접근 제어가 복잡해집니다.
하지만, 객체 소유권 설정을 통해 버킷 소유자가 모든 객체를 소유하도록 설정할 수 있습니다. 이 설정을 활성화하면 ACL을 사용할 필요가 없고, 버킷 소유자가 모든 객체에 대한 권한을 가질 수 있습니다. 이를 통해 보안 모델을 단순화할 수 있습니다.
결론
Amazon S3에서 계정 간 접근을 설정하는 방법은 크게 세 가지로 나눌 수 있습니다.
- IAM 정책과 S3 버킷 정책 사용
- IAM 정책과 ACL 사용 (비권장)
- 계정 간 IAM 역할 사용
권장되는 방식은 IAM 정책과 S3 버킷 정책을 사용하는 것이며, ACL은 이제 비권장 방식이므로 가능한 한 피하는 것이 좋습니다. 객체 소유권을 버킷 소유자가 소유하도록 설정하면 S3의 보안 모델을 단순화할 수 있습니다.
'자격증 > AWS Certified Security - Specialty' 카테고리의 다른 글
[AWS SCS] S3 - VPC 엔드포인트 전략 (0) | 2024.12.21 |
---|---|
[AWS SCS] S3 - 샘플 S3 버킷 정책 (0) | 2024.12.21 |
[AWS SCS] S3 - 권한 평가 프로세스 (0) | 2024.12.21 |
[AWS SCS] EC2 Instance Metadata - IMDSv1 vs IMDSv2 (1) | 2024.12.21 |
[AWS SCS] EC2 Instance Metadata (0) | 2024.12.21 |