자격 증명(사용자, 그룹, 역할) 기반 정책은 이미 위 포스트에서 다루었다. 이번에는 주로 S3에서 많이 사용하는 리소스 기반 정책(특히 버킷 정책)에 대해서 알아보자.
어떤 권한도 주지 않은 tester라는 사용자로, 콘솔에서 (URL을 통해) gook-policy-test 버킷에 접속해 보았다.
tester는 S3에 대한 권한이 없기 때문에, gook-policy-test라는 버킷 내의 어떤 파일도 확인할 수 없다.
tester라는 사용자에게 권한을 부여하는 대신 S3에 버킷 정책을 부여하여 tester에게 권한을 줄 수 있다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::{계정명}:user/{사용자명}"
},
"Action": [
"s3:ListBucket",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::{bucket 명}",
"arn:aws:s3:::{bucket 명}/*"
]
}
]
}
리소스 기반 정책에서는 Principal을 통해 권한을 적용할 주체(사용자, 그룹, 역할 등)을 지정할 수 있다. 내 계정의 tester를 지정해 주었다. Action을 통해 어떤 권한을 줄 것인지 지정하고, Resource에는 버킷과 버킷 내부의 모든 파일로 지정해 주었다.
공식 문서 IAM JSON 정책 요소 참조에서 자세히 확인할 수 있다.
버킷 정책을 통해 tester라는 사용자에게 gook-policy-test라는 버킷에 대해 s3:GetObject
권한을 부여하였다. 이제 tester는 gook-policy-test 버킷의 파일들을 확인할 수 있다.
앞에서 살펴 본 리소스 기반 정책 (버킷 정책)의 핵심은 자격 증명 주체(사용자, 그룹, 역할)가 아니라 리소스에게 정책을 할당하여 권한을 부여한다는 것이다.
자격 증명 기반 정책으로는 다른 계정에 있는 리소스에 대한 권한을 줄 수 없다. 하지만 리소스 기반 정책을 사용하면 위와 같이 다른 계정에 있는 사용자에게도 리소스에 대한 권한을 부여할 수 있다.
B 마음대로 A 계정에 있는 버킷에 접근 권한을 설정할 수는 없겠지만, A 계정이 본인의 S3 버킷에 대해 B 계정의 주체(사용자, 그룹, 역할)에게 권한을 줄 수 있는 것이다.
ACL은 버킷 내의 파일 별로 접근 제어를 수행할 수 있지만 일반적으로 사용하는 방식은 아니다. AWS에서도 "Amazon S3의 최신 사용 사례 대부분은 더 이상 ACL을 사용할 필요가 없습니다. 각 객체에 대해 액세스를 개별적으로 제어할 필요가 있는 드문 상황을 제외하고는 ACL을 비활성화한 채로 두는 것이 좋습니다."
라고 한다.
그래도 궁금하다면 ACL(액세스 제어 목록) 개요를 참고하자.