AWS IAM 마스터하기: 액세스 거부 오류 효과적으로 해결하기

AWS IAM AccessDenied 오류는 AWS가 요청을 평가했지만 유효한 권한 경로를 찾지 못했음을 의미합니다. 가장 빠른 해결 방법은 더 광범위한 정책을 추측하는 것이 아니라 AWS가 평가한 정확한 작업, 리소스, 주체 및 조건 컨텍스트를 식별하는 것입니다.

대부분의 IAM 실패는 네 가지 원인 중 하나에서 발생합니다: 일치하는 Allow 없음, 명시적 Deny, ID를 제한하는 권한 경계 또는 서비스 제어 정책, 요청과 일치하지 않는 조건입니다.

IAM 평가 로직부터 시작하기

AWS는 기본 거부에서 시작합니다. 요청은 해당 정책이 허용하고 해당 정책이 거부하지 않는 경우에만 허용됩니다.

명시적 Deny는 모든 Allow보다 우선합니다. 이러한 거부는 ID 정책, 리소스 정책, 권한 경계, 세션 정책, 서비스 제어 정책 또는 기타 적용 가능한 정책 유형에서 발생할 수 있습니다.

동일 계정 액세스의 경우 ID 정책과 리소스 정책이 함께 작동하는 경우가 많습니다. 교차 계정 액세스의 경우 일반적으로 양쪽 모두에 권한이 필요합니다. 호출자의 ID가 요청을 할 수 있어야 하고 대상 리소스 또는 대상 계정이 해당 호출자를 신뢰하거나 허용해야 합니다.

실패한 정확한 요청 캡처하기

정책을 편집하기 전에 다음 세부 정보를 캡처하세요:

• 주체: 사용자, 역할, 수임된 역할 세션 또는 AWS 서비스 주체.
• 작업: s3:GetObject 또는 ec2:RunInstances와 같은 API 작업.
• 리소스: ARN 또는 리소스 ID.
• 리전 및 계정.
• 조건: 소스 IP, VPC 엔드포인트, MFA, 태그, 암호화 컨텍스트 또는 요청된 리전.

CloudTrail이 일반적으로 가장 좋은 소스입니다. 오류 발생 시간 전후의 실패한 이벤트를 검색하고 eventName, userIdentity, resources, errorCode 및 errorMessage를 검사하세요.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=RunInstances \
  --max-results 10

CloudTrail이 모든 권한 부여 결정을 완벽하게 설명하지는 않지만 누락된 작업과 실제 주체를 제공하는 경우가 많습니다. 이 정보만으로도 수임된 역할 및 세션 이름 혼동을 많이 잡아낼 수 있습니다.

시뮬레이션 및 액세스 분석 도구 사용하기

IAM 정책 시뮬레이터는 프로덕션 권한을 변경하기 전에 많은 ID 기반 정책 질문을 테스트할 수 있습니다. 사용자 또는 역할을 선택하고 서비스 작업을 선택하고 가능한 경우 리소스 ARN을 제공하고 관련 조건 키를 포함하세요.

최신 AWS 계정 및 서비스의 경우 액세스 거부 메시지 자체도 확인하세요. 일부 서비스는 인코딩된 권한 부여 실패 메시지를 반환합니다. 권한이 있는 경우 STS로 디코딩하세요:

aws sts decode-authorization-message \
  --encoded-message '<encoded-message-from-error>'

디코딩된 메시지는 어떤 정책 유형이 거부에 기여했는지 보여줄 수 있습니다.

IAM Access Analyzer는 리소스 정책 및 교차 계정 질문에 유용합니다. 의도하지 않은 외부 액세스를 찾고 배포 전에 일부 정책을 검증하는 데 도움이 될 수 있습니다.

각 정책 계층 확인하기

ID 기반 정책은 사용자, 그룹 및 역할에 연결됩니다. ID가 수행할 수 있는 작업을 정의합니다.

리소스 기반 정책은 S3 버킷, KMS 키, SQS 큐, Lambda 함수 및 역할 신뢰 정책과 같은 리소스에 연결됩니다. 해당 리소스를 사용하거나 역할을 수임할 수 있는 주체를 정의합니다.

권한 경계는 사용자 또는 역할의 최대 권한을 설정합니다. 자체적으로 액세스를 부여하지 않습니다. 유효 권한은 ID 정책과 경계의 교집합입니다.

AWS Organizations의 서비스 제어 정책은 계정 또는 조직 단위의 최대 권한을 설정합니다. SCP도 자체적으로 액세스를 부여하지 않습니다. IAM 정책이 허용하더라도 작업을 차단할 수 있습니다.

세션 정책 및 권한 태그는 수임된 역할 세션의 액세스를 줄일 수도 있습니다. 역할이 한 경로에서는 작동하지만 CI 작업에서 수임할 때 실패하는 경우 세션 정책, 세션 태그 및 신뢰 정책 조건을 비교하세요.

일반적인 AccessDenied 패턴

종속 작업 누락

일부 AWS 작업은 명백한 작업보다 더 많은 것을 필요로 합니다. 예를 들어 암호화된 EC2 인스턴스를 시작하려면 EC2 권한과 키에 대한 KMS 권한이 필요할 수 있습니다. CloudTrail 및 서비스 문서가 종속 작업에 대한 최고의 참고 자료입니다.

잘못된 리소스 ARN

S3 버킷 수준과 객체 수준 ARN은 다릅니다:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

arn:aws:s3:::my-bucket은 버킷을 포함합니다. arn:aws:s3:::my-bucket/*은 버킷의 객체를 포함합니다. 많은 S3 오류는 API 호출에 필요한 것과 다른 ARN을 부여할 때 발생합니다.

조건 불일치

조건은 요청 컨텍스트와 정확히 일치해야 합니다. 하나의 VPC 엔드포인트를 통해서만 액세스를 허용하는 정책은 다른 엔드포인트, 공용 AWS 엔드포인트 또는 조건이 해당 리전을 확인하는 경우 다른 리전의 요청을 거부합니다.

{
  "Effect": "Deny",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::my-sensitive-data",
    "arn:aws:s3:::my-sensitive-data/*"
  ],
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "false"
    }
  }
}

해당 명령문은 HTTP 요청을 거부하고 HTTPS 요청이 나머지 정책 평가를 계속 진행하도록 허용합니다. 자체적으로 액세스를 부여하지 않습니다.

KMS 키 정책 차이

KMS는 혼란스러운 액세스 오류의 일반적인 원인입니다. IAM 정책은 kms:Decrypt를 허용할 수 있지만 키 정책도 주체를 직접 허용하거나 IAM 정책을 통해 계정이 액세스를 위임하도록 허용해야 합니다.

키 정책, 권한 부여, 암호화 컨텍스트 조건 및 키를 사용하는 서비스를 확인하세요.

실용적인 문제 해결 흐름

먼저 실패한 호출을 재현하거나 캡처하세요. CloudTrail에서 정확한 API 작업과 주체를 가져옵니다.

다음으로 SCP, 리소스 정책, 권한 경계 및 ID 정책에서 명시적 거부를 검색하세요. 명시적 거부는 다른 모든 것을 재정의하므로 시간을 절약할 수 있습니다.

그런 다음 정확한 작업과 리소스에 대한 일치하는 허용이 있는지 확인하세요. KMS 키, 서비스에 전달된 IAM 역할, 네트워크 인터페이스 또는 로그 그룹과 같은 종속 작업 및 관련 리소스를 포함하세요.

마지막으로 가능한 가장 좁은 정책 변경으로 테스트하세요. 알 수 없는 거부를 Action: "*" 또는 Resource: "*"로 수정하지 마세요. 이는 문제를 숨기고 새로운 보안 위험을 만듭니다.

유용한 습관은 모든 AccessDenied를 증거 문제로 취급하는 것입니다. 주체, 작업, 리소스 및 정책 계층을 알면 수정은 일반적으로 작고 명확합니다.