DevOps 지식 허브
DevOps 지식 허브

AWS CLI에서 'Access Denied' 및 인증 문제 해결

AWS CLI 사용 시 발생하는 'Access Denied' 및 인증 오류를 체계적으로 해결하십시오. 이 가이드에서는 `aws sts get-caller-identity`를 사용하여 자격 증명을 확인하는 것부터 시작하여, 복잡한 IAM 정책 평가 계층 구조를 검토하고, 임시 자격 증명 또는 리소스 기반 정책(예: S3 버킷 정책)으로 인해 발생하는 문제를 해결하는 필수 진단 단계를 다룹니다. 주요 명령과 IAM Policy Simulator를 사용하여 AWS 환경에서 발생하는 권한 부여 실패를 신속하게 식별하고 수정하는 방법을 배우십시오.

42 조회수

AWS CLI에서 '액세스 거부' 및 인증 문제 해결

AWS Command Line Interface(CLI)를 사용하는 동안 액세스 거부 오류나 예기치 않은 인증 실패를 경험하는 것은 개발자와 시스템 관리자가 가장 흔하게 직면하는 장애물 중 하나입니다. 이러한 문제는 거의 항상 잘못 구성된 ID 및 액세스 관리(IAM) 정책, 만료된 임시 자격 증명 또는 CLI 환경의 잘못된 설정에서 비롯됩니다.

이러한 오류를 성공적으로 해결하려면 체계적인 접근 방식이 필요합니다. 먼저 ID와 자격 증명을 확인하고 IAM 정책 평가로 넘어갑니다. 이 포괄적인 가이드는 AWS CLI에서 일반적인 권한 부여 문제를 신속하게 식별하고 수정하기 위한 실행 가능한 단계와 진단 명령을 제공하여 리소스를 효과적으로 관리할 수 있도록 합니다.

1. 초기 진단: 호출자 및 자격 증명 식별

복잡한 정책 분석에 들어가기 전에 첫 번째 단계는 AWS CLI가 어떤 IAM ID를 사용하고 있는지, 그리고 해당 자격 증명이 여전히 유효한지 확실하게 확인하는 것입니다.

현재 ID 확인: sts get-caller-identity

이것이 가장 중요한 진단 명령입니다. 후속 AWS 명령을 실행하는 사용자 ARN, 역할 ARN 또는 가정된 역할 세션이 정확히 무엇인지 알려줍니다.

aws sts get-caller-identity

예상 출력:

{
    "UserId": "AIDAIAMUSERID",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/DevUser"
}

반환된 ARN이 예상하는 사용 또는 역할과 일치하지 않으면 잘못된 AWS 프로필 또는 환경 변수를 사용하고 있는 것입니다.

프로필 구성 및 리전 확인

--profile 플래그를 통해 지정하거나 AWS_PROFILE 환경 변수를 통해 설정하여 올바른 AWS 프로필이 사용되고 있는지 확인합니다.

# 기본 프로필에 대한 구성된 설정 확인
aws configure list

# 또는 특정 프로필 확인
aws configure list --profile prod-admin

출력에 리전이 없거나 잘못된 리전이 표시되면 전역 리소스 또는 리전별 서비스(예: S3 버킷 또는 EC2 인스턴스)에 대한 작업이 실패할 수 있으며, CLI가 찾고 있는 위치에 리소스가 없을 경우 액세스 거부 오류가 발생할 수도 있습니다.

팁: sts get-caller-identity 명령 자체에서 인증 오류가 발생하면 액세스 키에 근본적인 문제가 있음을 나타냅니다(삭제되었거나, 취소되었거나, 잘못되었을 수 있음).

임시 자격 증명 처리

IAM 역할을 사용 중인 경우(STS AssumeRole을 통해), CLI는 SessionToken을 포함하는 임시 자격 증명으로 작동합니다. 이러한 자격 증명은 만료됩니다(일반적으로 1시간 후). AWS CLI는 표준 자격 증명 공급자 체인에서 소싱할 때 자동으로 새로 고치지만, 수동 구성은 실패할 수 있습니다.

증상: 처음에는 명령이 작동하지만 일정 시간이 지난 후(예: 60분) 인증 오류와 함께 실패합니다.

해결 방법: 사용자 지정 스크립트나 수동으로 로드된 환경을 사용하는 경우, 역할 가정 방식에 자격 증명이 만료될 때 새로 고치는 메커니즘이 포함되어 있는지 확인합니다.

2. IAM 정책 및 권한 부여 심층 분석

사용되는 ID를 확인한 후 다음 단계는 해당 ID에 필요한 권한이 없는 이유를 파악하는 것입니다. AWS 권한 부여 실패는 여러 정책이 동시에 평가되므로 복잡합니다.

IAM 정책 평가 계층 구조

권한 부여 오류는 일반적으로 다음 정책 구성 요소 중 하나 때문에 발생합니다.

  1. 명시적 거부: 모든 적용 가능한 정책(ID, 리소스 또는 경계)의 명시적 Deny 문은 항상 Allow 문을 재정의합니다.
  2. 허용 누락: ID 또는 리소스에 적용 가능한 정책이 특정 작업을 허용하지 않습니다.

A. ID 기반 정책(사용자 및 역할)

사용자 또는 가정된 역할에 직접 연결된 IAM 정책을 확인합니다. 다음을 찾습니다.

  • 작업 누락: 정책에 필요한 API 작업(예: s3:ListBucket, ec2:DescribeInstances)이 명시적으로 나열되어 있습니까?
  • 리소스 제약: 정책이 Resource 요소를 사용하여 특정 리소스로 작업을 제한합니까? 일반적인 오류는 작업에 특정 ARN이 필요한 경우 Resource: "*"를 설정하거나 그 반대의 경우입니다.
  • 조건: 충족되지 않는 조건(예: 소스 IP 주소, 시간대, MFA 필수)이 있습니까?

B. 리소스 기반 정책(S3, SQS, KMS)

S3 또는 KMS와 같은 서비스의 경우 리소스 자체에 누가 액세스할 수 있는지 결정하는 정책이 있습니다. IAM 사용자 정책이 명시적으로 액세스를 허용하더라도 리소스 정책도 사용자가 작업을 수행하도록 허용해야 합니다.

예시: 특정 VPC 엔드포인트 외부의 모든 사용자를 명시적으로 Deny하는 S3 버킷(리소스 정책)에 액세스하려고 시도하면 사용자 IAM 정책에 관계없이 액세스 거부가 발생합니다.

C. 권한 경계 및 SCP

조직에서 AWS Organizations를 사용하는 경우, 서비스 제어 정책(SCP)은 계정 내에서 허용되는 최대 권한을 정의합니다. 마찬가지로, 권한 경계는 IAM 개체가 가질 수 있는 최대 권한을 제한합니다.

SCP 또는 경계가 필요한 작업을 거부하면 ID 정책이 권한을 부여하더라도 CLI 작업이 실패합니다.

실용 도구: IAM 정책 시뮬레이터

복잡한 실패를 해결할 때 AWS Management Console의 IAM 정책 시뮬레이터는 매우 유용합니다. 특정 리소스(예: arn:aws:s3:::my-bucket/key)에 대한 특정 작업(예: s3:GetObject)을 테스트하고 IAM 개체를 지정하여 어떤 정책 문이 거부를 유발하는지 정확히 파악할 수 있습니다.

3. 일반적인 '액세스 거부' 시나리오 및 해결 방법

시나리오 1: S3 액세스 거부(리소스 대 ID)

S3 액세스 거부는 사용자 정책 또는 버킷 정책에서 발생할 수 있으므로 악명 높습니다.

원인 진단 해결 방법
버킷 정책 허용 누락 sts get-caller-identity는 작동하지만 aws s3 ls는 실패합니다. 호출 ARN이 필요한 작업(s3:ListBucket, s3:GetObject)을 수행하도록 명시적으로 허용하도록 버킷 정책을 수정합니다.
KMS 복호화 권한 누락 암호화된 객체에 액세스하는 것이 실패합니다(S3 정책이 허용하더라도). IAM 개체가 객체를 암호화한 기본 KMS 키(kms:Decrypt)를 사용할 권한이 있는지 확인합니다.
요청자 지불 대용량 파일 다운로드 시도가 실패합니다. 버킷이 Requester Pays를 요구하는 경우 CLI 명령에 --request-payer requester 플래그를 포함해야 합니다.

시나리오 2: 조건 실패로 인한 암시적 거부

많은 정책은 다단계 인증(MFA)을 요구하는 것과 같은 보안 모범 사례를 시행하는 조건을 사용합니다.

정책에 다음과 같은 조건이 포함된 경우:

"Condition": {
    "Bool": {
        "aws:MultiFactorAuthPresent": "true"
    }
}

MFA 인증 없이 명령을 실행하려고 하면 작업이 암시적으로 거부됩니다.

해결 방법: MFA가 필요한 명령의 경우, MFA 장치로 인증된 STS 세션을 먼저 생성해야 합니다.

# 1. MFA 토큰을 사용하여 임시 자격 증명 가져오기
aws sts get-session-token --serial-number arn:aws:iam::123456:mfa/user --token-code 123456

# 2. 결과 AccessKeyId, SecretAccessKey 및 SessionToken을 CLI 세션에 대한 환경 변수로 내보냅니다.

시나리오 3: 리전 누락 또는 잘못됨

항상 액세스 거부 오류는 아니지만, 올바른 리전을 지정하지 않고 리소스에서 작업을 수행하려고 하면 특히 EC2, DynamoDB 또는 EKS와 같은 리전별 서비스를 작업할 때 권한 부여 또는 리소스 찾기 실패로 이어지는 경우가 많습니다.

해결 방법: 명령에서 리전을 명시적으로 정의하거나 프로필이 올바르게 구성되었는지 확인합니다.

aws ec2 describe-instances --region us-west-2

4. 진단 명령 요약

이 명령 체크리스트를 사용하여 권한 부여 실패 체인을 빠르게 진단합니다.

목표 명령 목적
ID 확인 aws sts get-caller-identity 명령을 실행하는 ARN을 확인합니다.
구성 확인 aws configure list 프로필 설정, 리전 및 출력 형식을 확인합니다.
정책 유효성 테스트 (IAM 정책 시뮬레이터 사용) IAM 개체가 리소스에 대해 특정 API 작업을 수행할 수 있는지 확인합니다.
정책 거부 식별 aws cloudtrail lookup-events ... CloudTrail을 사용하여 정책 평가가 실패한 정확한 이벤트 기록을 확인합니다.

결론: 예방을 위한 모범 사례

AWS CLI에서 액세스 거부 오류를 최소화하려면 다음 보안 및 운영 모범 사례를 채택하십시오.

  1. 최소 권한 사용: 꼭 필요한 경우가 아니면 *(와일드카드) 액세스를 부여하지 마십시오. 필요한 작업과 리소스로 정책을 엄격하게 범위 지정합니다.
  2. IAM 역할 사용: 특히 스크립트나 CI/CD 파이프라인에서 장기 실행 IAM 사용자 키를 사용하는 것보다 IAM 역할 가정을 선호하십시오. 이렇게 하면 자격 증명이 유출될 경우 노출 시간을 제한할 수 있습니다.
  3. CloudTrail 감사: 문제가 지속되면 권위 있는 출처는 AWS CloudTrail입니다. 실패한 API 호출에 대한 기록된 이벤트에는 종종 실패 이유(예: Deny by Policy X, MFA required)가 포함됩니다.
  4. 프로필 관리: 다른 AWS 계정 또는 역할(--profile)에 대해 별도의 프로필을 명확하게 이름 지정하고 관리합니다. 환경 변수와 프로필 구성을 혼용하지 마십시오.