Athena에서 쿼리를 실행할 때 ‘Access Denied’ 권한 오류를 어떻게 해결합니까?
Amazon Athena 쿼리를 실행하려고 하는데 ‘Access Denied’ 오류가 발생합니다.
간략한 설명
‘Access Denied’ 쿼리 오류는 일반적으로 Athena가 상호 작용하는 다른 AWS 서비스 또는 AWS 계정의 권한 문제와 관련이 있습니다. Athena가 일반적으로 사용하는 서비스의 예로는 AWS Identity and Access Management(IAM), Amazon Simple Storage Service(Amazon S3), AWS Key Management Service(AWS KMS)가 있습니다.
‘Access Denied’ 오류를 초래하는 원인은 다음과 같습니다.
- AWS Glue Data Catalog 정책이 IAM 사용자 또는 IAM 역할에 대한 액세스를 허용하지 않습니다.
- IAM 엔터티에 S3 소스 데이터 버킷을 읽거나 결과를 쿼리 결과 버킷에 쓸 권한이 없습니다.
- S3 버킷 정책이 Athena 테이블과 버킷이 서로 다른 계정에 있을 때 IAM 엔터티에 대한 필수 권한을 허용하지 않습니다.
- 객체 소유자가 S3 버킷 소유자와 다릅니다.
- 암호화된 데이터를 쓰거나 읽는 데 사용되는 AWS KMS 키에 대한 액세스 권한이 없습니다.
‘Access Denied’ 오류를 해결하려면 사용 사례에 맞는 권한을 설정했는지 확인하십시오. 권한 관련 오류에 관한 자세한 내용은 권한을 참조하십시오.
해결 방법
참고: AWS Command Line Interface(AWS CLI) 명령을 실행할 때 오류가 발생하면 AWS CLI 오류 문제 해결을 참조하십시오. 또한 최신 AWS CLI 버전을 사용하고 있는지 확인하십시오.
Glue Data Catalog 정책이 IAM 엔터티에 대한 액세스를 허용하는지 확인
다음 오류 메시지가 표시됩니다.
‘Insufficient permissions to execute the query. User: arn:aws:iam:: 1111222233334444:user/athena_user is not authorized to perform: glue:GetTable on resource: arn:aws:glue:us-east-1:1111222233334444:database/doc_example_database with an explicit deny Query Id: example_query_ID’.
앞선 오류는 Data Catalog 정책이 Data Catalog에 대한 액세스를 거부할 때 발생합니다. 다음 정책 예시에는 AWS Glue Catalog에 대한 athena_user 액세스를 거부하는 명시적 Deny가 포함되어 있습니다.
{ "Version": "2012-10-17", "Statement": [ { "Principal": { "AWS": [ "arn:aws:iam::1111222233334444:user/athena_user" ] }, "Effect": "Deny", "Action": [ "glue:*" ], "Resource": [ "arn:aws:glue:us-east-1:1111222233334444:*" ] } ] }
이 문제를 해결하려면 명시적 Deny를 Allow로 변경하십시오. 명시적 Allow를 포함하는 정책 예시를 보려면 데이터베이스 및 테이블 수준 권한의 예시를 참조하십시오. AWS Glue Data Catalog 정책을 변경하려면 Data Catalog 설정을 참조하십시오.
필수 AWS Glue 권한 전체 목록은 AWS 관리형 정책: AmazonAthenaFullAccess를 참조하십시오.
IAM 엔터티에 버킷에 액세스하는 데 필요한 권한이 있는지 확인
다음 오류가 표시되면 소스 데이터 버킷에 대한 액세스 권한이 없는 것입니다.
‘Your query has the following errors:com.amazonaws.services.s3.model.AmazonS3Exception: Access Denied (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied; Request ID:###; S3 Extended Request ID:###=; Proxy: null), S3 Extended Request ID:###= (Path: s3://my-athena-source-bucket/athena_data.csv)’.
다음 오류가 표시되면 쿼리 결과 버킷에 대한 액세스 권한이 없는 것입니다.
‘Your query has the following errors: Access denied when writing output to url: s3://my-athena-result-bucket/Unsaved/2021/05/07/example_query_ID.csv . Please ensure you are allowed to access the S3 bucket. If you are encrypting query results with KMS key, please ensure you are allowed to access your KMS key’.
쿼리를 실행하는 IAM 엔터티에 2개의 버킷에 대한 액세스 권한이 모두 있어야 합니다. 필요한 권한을 부여하려면 IAM 엔터티에 다음 IAM 정책을 연결합니다.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::my-athena-source-bucket" ] }, { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::my-athena-source-bucket/data/*" ] }, { "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetObject", "s3:ListBucket", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUpload", "s3:PutObject", "s3:ListMultipartUploadParts" ], "Resource": [ "arn:aws:s3:::my-athena-result-bucket", "arn:aws:s3:::my-athena-result-bucket/*" ] } ] }
참고: my-athena-source-bucket를 소스 데이터 버킷의 이름으로, **my-athena-source-bucket/data/**를 소스 데이터 위치로 바꿉니다. my-athena-result-bucket을 쿼리 결과 버킷의 이름으로 바꿉니다.
정책의 전체 목록은 Amazon Athena의 AWS 관리형 정책을 참조하십시오.
교차 계정 쿼리에 필요한 권한이 있는 S3 버킷 정책 추가
Athena 테이블과 S3 버킷이 동일한 계정에 있는 경우, S3 버킷에 리소스 기반 정책을 추가할 필요가 없습니다. 하지만 이미 버킷 정책을 추가한 경우, 해당 정책이 데이터를 쿼리하는 IAM 엔터티에 S3 권한을 부여하는지 확인하십시오.
Athena 테이블과 S3 버킷이 서로 다른 계정에 있는 경우, IAM 엔터티에 대한 액세스 권한을 부여하는 리소스 기반 정책을 S3 버킷에 추가합니다.
다음 예시에서 Athena 사용자는 계정 A에, S3 버킷은 계정 B에 있습니다.
다음 예시의 리소스 기반 정책은 계정 A의 athena_user에 계정 B의 my-athena-source-bucket S3 버킷에 대한 액세스를 허용합니다.
{ "Version": "2012-10-17", "Id": "Policy1620692934647", "Statement": [ { "Sid": "Stmt1620692932186", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::1111222233334444:user/athena_user" }, "Action": [ "s3:*" ], "Resource": [ "arn:aws:s3:::my-athena-source-bucket", "arn:aws:s3:::my-athena-source-bucket/data/*" ] } ] }
참고: my-athena-source-bucket를 소스 데이터 버킷의 이름으로, **my-athena-source-bucket/data/**를 소스 데이터 위치로 바꿉니다. 1111222233334444를 계정 A의 IAM 사용자 계정 ID로, athena_user를 계정 A의 IAM 사용자 이름으로 바꿉니다.
계정 A의 모든 사용자에게 버킷에 대한 액세스 권한을 부여하려면 Principal 키를 root를 지정하는 키("arn:aws:iam::1111222233334444:root")로 바꾸십시오.
참고: 앞선 S3 버킷 정책은 my-athena-source-bucket에 대한 모든 S3 작업을 허용합니다. S3 버킷이 소스 데이터 버킷인지, 아니면 쿼리 결과 버킷인지에 따라 S3 작업을 업데이트하십시오. 자세한 내용은 버킷 객체에 대한 교차 계정 액세스 구성을 참조하십시오.
S3 버킷 정책이 계정 A 또는 그 IAM 사용자에 대한 액세스를 명시적으로 거부하는 문을 포함하지 않는지 확인합니다. 또한 정책에 요청을 거부할 수 있는 조건이 포함되지 않아야 합니다. 자세한 내용은 Amazon S3의 403 액세스 거부 오류 문제를 어떻게 해결합니까?를 참조하십시오.
AWS KMS 키 정책 업데이트
소스 데이터를 암호화했거나 Athena 쿼리가 AWS KMS 키를 사용하여 암호화된 결과를 작성하는 경우, 다음 작업을 수행하십시오.
- IAM 사용자의 정책이 필수 AWS KMS 작업을 허용하는지 확인합니다.
- AWS KMS 키 정책이 사용자에 대한 액세스를 허용하는지 확인하빈다.
다음 AWS KMS 키 정책 예시는 계정 1111222233334444가 KMS 키에서 모든 작업을 허용하는 IAM 정책을 사용할 권한을 부여합니다.
{ "Sid": "Enable IAM policies", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::1111222233334444:root" }, "Action": "kms:*", "Resource": "*" }
참고: 앞선 정책에서 1111222233334444를 계정 ID로 바꾸십시오.
자세한 내용은 AWS KMS의 키 정책 및 AWS 계정에 대한 액세스 허용 및 활성화된 IAM 정책을 참조하십시오.
S3 버킷 소유자에게 객체에 대한 액세스 권한이 있어야 함
기본적으로 S3 객체를 버킷에 업로드하는 계정이 객체를 소유합니다. 이것은 다른 계정이 버킷을 소유하는 경우에도 마찬가지입니다. 다른 계정의 사용자가 버킷에 객체를 업로드할 수 있는 경우, 사용자가 액세스할 수 없는 객체를 소유하는 계정을 확인하십시오. 객체 소유자를 확인하려면 GetObjectAcl 명령을 실행합니다.
S3 버킷 소유자와 객체 소유자가 서로 다른 경우, 객체 소유자가 객체에 대한 전체 제어 권한을 부여할 수 있습니다. 객체 소유자는 PutObjectAcl 명령을 bucket-owner-full-control 파라미터로 실행해야 합니다.
객체의 소유권을 S3 버킷을 소유하는 계정으로 변경하려면 cp AWS CLI 명령을 실행합니다. 버킷 계정에서 cp 명령을 실행하여 객체 자체를 복사해야 합니다.
자세한 내용은 다른 AWS 계정이 소유한 Amazon S3 버킷에 업로드된 객체에 액세스할 수 없는 이유는 무엇입니까?를 참조하십시오.
관련 정보
관련 콘텐츠
질문됨 2년 전
