AWS Identity and Access Management
사용 설명서

일반적인 문제 해결

이 문서의 정보를 사용하여 AWS Identity and Access Management(IAM) 작업 시 발생할 수 있는 액세스 거부 또는 기타 일반적인 문제를 진단하고 해결할 수 있습니다.

액세스 키를 분실했습니다

액세스 키는 다음 두 부분으로 구성됩니다.

  • 액세스 키 식별자. 이 식별자는 비밀이 아니며 사용자 요약 페이지 등 IAM 콘솔에서 액세스 키가 나열되어 있는 곳 어디서나 확인할 수 있습니다.

  • 보안 액세스 키. 액세스 키 페어를 처음 만들 때 제공됩니다. 암호와 마찬가지로 나중에 검색할 수 없습니다. 하지만 보안 액세스 키를 분실한 경우에는 새로운 액세스 키 페어를 생성해야 합니다. 이미 액세스 키의 최대 수인 경우 기존 페어를 삭제해야만 다른 페어를 생성할 수 있습니다.

자세한 내용은 분실하거나 잊어버린 암호 또는 액세스 키 재설정 단원을 참조하십시오.

예전 계정에 액세스해야 합니다

AWS 계정을 처음 생성할 때 이메일 주소와 암호를 입력했습니다. 그 주소와 암호가 바로 AWS 계정 루트 사용자 자격 증명입니다. 암호를 잊거나 분실하여 더 이상 액세스할 수 없게 된 AWS 계정이 있다면 암호를 복구하면 됩니다. 자세한 내용은 분실하거나 잊어버린 암호 또는 액세스 키 재설정 단원을 참조하십시오.

그 이메일에 더 이상 액세스할 수 없는 경우, 먼저 이메일에 대한 액세스부터 복구해 보아야 합니다. 복구에 실패하면 AWS 고객 서비스에 문의하십시오.

다음 옵션 중 하나를 사용하여 이메일에 대한 액세스 권한을 복구해 볼 수 있습니다.

  • 이메일 주소의 호스팅 도메인이 본인 소유인 경우, 그 이메일 주소를 다시 이메일 서버에 추가하면 됩니다. 아니면 이메일 계정에 대한 완전 포착(catch-all) 조건을 설정할 수 있습니다. 도메인에 설정된 완전 포착(catch-all) 조건은 메일 서버에 존재하지 않는 이메일 주소로 전송된 "모든 메시지를 포착(catches all)"합니다. 그리고 그러한 메시지를 특정 이메일 주소로 리디렉션합니다. 예를 들어 AWS 계정 루트 사용자 이메일 주소가 paulo@sample-domain.com이지만 유일한 도메인 이메일 주소를 paulo.santos@sample-domain.com으로 변경한다고 가정합니다. 이 경우 새 이메일을 catch-all로 설정할 수 있습니다. 그러면 AWS 같은 곳에서 paulo@sample-domain.com 또는 다른 text@sample-domain.com으로 메시지를 보내면 사용자는 paulo.santos@sample-domain.com 주소로 그 메시지를 받게 됩니다.

  • 계정의 이메일 주소가 회사 이메일 시스템에 속한 경우라면 IT 시스템 관리자에게 문의하는 것이 좋습니다. 시스템 관리자가 이메일 주소에 대한 액세스 권한을 다시 받을 수 있도록 도와 줄 것입니다.

그래도 AWS 계정에 액세스할 수 없는 경우, 문의처에서 AWS를 이용하고 있으며, 결제 혹은 계정 지원이 필요합니다(I'm an AWS customer and I'm looking for billing or account support) 메뉴를 확장하여 다른 지원 옵션을 찾아볼 수 있습니다. 고객 서비스에 문의할 때 다음 정보를 알려 주십시오.

  • 본인 이름, 전화번호, 주소, 이메일 주소, 신용카드의 마지막 네 자리 번호 등 계정에 나열되어 있는 모든 세부 정보. 고객 서비스 문의를 목적으로 새 AWS 계정을 생성해야 할 수 있습니다. 이는 요청 조사를 지원하는 데 있어 필수입니다.

  • 암호 재설정 지침을 받아야 하는데 이메일 계정에 액세스할 수 없는 이유.

  • 계정을 복구한 후에는 사용하지 않는 모든 계정을 닫으십시오. 요금이 부과될 가능성이 있으므로 본인 이름으로 계정을 열어 두지 않는 것이 좋습니다. 자세한 내용은 Billing and Cost Management 사용 설명서계정 닫기를 참조하십시오.

내 계정에 로그인할 수 없음

AWS 계정을 처음 생성할 때 이메일 주소와 암호를 입력했습니다. 그 주소와 암호가 바로 AWS 계정 루트 사용자 자격 증명입니다. 암호를 잊거나 분실하여 더 이상 액세스할 수 없게 된 계정이 있다면 해당 암호를 복구하면 됩니다. 자세한 내용은 분실하거나 잊어버린 암호 또는 액세스 키 재설정 단원을 참조하십시오.

계정 이메일 주소와 암호를 입력한 경우 AWS는 일회성 확인 코드를 입력해야 하는 경우도 있습니다. 확인 코드를 검색하려면 AWS 계정과 연결된 이메일에서 Amazon Web Services의 메시지를 확인합니다. 이메일 주소는 @amazon.com 또는 @aws.amazon.com으로 끝납니다. 메시지의 지침을 따릅니다. 계정으로 메시지가 오지 않았으면 스팸 폴더를 점검합니다. 그 이메일에 더 이상 액세스할 수 없는 경우에는 예전 계정에 액세스해야 합니다 단원을 참조하십시오.

AWS 서비스에 요청하면 "액세스 거부"가 발생합니다

  • 요청한 작업 및 리소스를 호출할 자격 증명 기반 정책 권한이 있는지 확인합니다. 조건이 설정된 경우 요청을 보낼 때 그러한 조건 또한 충족해야 합니다. IAM 사용자, 그룹 또는 역할에 대한 정책을 보거나 수정하는 방법에 대한 자세한 정보는 IAM 정책 관리 단원을 참조하십시오.

  • 리소스 기반 정책을 지원하는 서비스(예: Amazon S3, Amazon SNS 또는 Amazon SQS)에 액세스하려 합니까? 그러한 경우 정책에서 사용자를 보안 주체로 지정하고 액세스 권한을 부여하는지 확인하십시오. 자신의 계정 내에서 서비스를 요청하는 경우 자격 증명 기반 정책이나 리소스 기반 정책에서 요청자에게 권한을 부여할 수 있습니다. 다른 계정에서 서비스를 요청하는 경우 자격 증명 기반 정책 및 리소스 기반 정책 모두에서 요청자에게 권한을 부여해야 합니다. 리소스 기반 정책을 지원하는 서비스를 보려면 IAM로 작업하는 AWS 서비스 단원을 참조하십시오.

  • 정책에 키–값 페어가 있는 조건이 포함된 경우 이를 주의하여 검토하십시오. aws:RequestTag/tag-key 전역 조건 키, AWS KMS kms:EncryptionContext:encryption_context_key 및 여러 서비스에서 지원하는 ResourceTag/tag-key 조건 키가 그 예입니다. 키 이름이 여러 개의 결과와 일치하지 않도록 하십시오. 조건 키 이름이 대/소문자를 구분하지 않으므로 이름이 foo인 키를 검사하는 조건은 foo, Foo 또는 FOO와 일치합니다. 대/소문자로만 구분되는 키 이름을 가진 여러 키–값 페어가 요청에 포함된 경우 액세스가 예기치 않게 거부될 수 있습니다. 자세한 정보는 IAM JSON 정책 요소: Condition 단원을 참조하십시오.

  • 권한 경계가 있다면, 권한 경계에 사용된 정책이 요청을 허용하는지 확인합니다. 자격 증명 기반 정책에서는 요청이 허용되지만 권한 경계에서는 허용되지 않는 경우 요청이 거부됩니다. 이 권한 경계는 보안 주체 엔터티(사용자나 역할)에 부여할 수 있는 최대 권한을 제어합니다. 리소스 기반 정책은 권한 경계에 제한을 받지 않습니다. 권한 경계는 일반적이지 않습니다. AWS 평가 정책에 대한 자세한 정보는 정책 평가 로직을 참조하십시오.

  • (AWS SDK를 사용하지 않고) 요청에 수동으로 서명할 경우, 요청에 올바르게 서명했는지 확인합니다.

임시 보안 자격 증명으로 요청하면 "액세스 거부"가 발생합니다

  • 우선, 임시 자격 증명과 무관한 이유로 액세스가 거부되지는 않았는지 확인합니다. 자세한 정보는 AWS 서비스에 요청하면 "액세스 거부"가 발생합니다 단원을 참조하십시오.

  • IAM로 작업하는 AWS 서비스 단원을 참조하여 서비스에서 임시 보안 자격 증명을 허용하는지 확인합니다.

  • 요청에 올바르게 서명했고 요청이 잘 구성되었는지 확인합니다. 자세한 정보는 도구 키트 문서 또는 임시 보안 자격 증명을 사용해 AWS 리소스에 대한 액세스 요청하기 단원을 참조하십시오.

  • 임시 보안 자격 증명이 만료되지 않았는지 확인합니다. 자세한 정보는 임시 보안 자격 증명 단원을 참조하십시오.

  • IAM 사용자 또는 역할 권한이 올바른지 확인합니다. 임시 보안 자격 증명에 대한 권한은 IAM 사용자 또는 역할에서 파생됩니다. 결과적으로 위임한 역할(임시 자격 증명이 제공됨)에 부여된 권한으로 제한됩니다. 임시 보안 자격 증명의 권한이 결정되는 방법에 대한 자세한 정보는 사용자 임시 보안 자격 증명에 대한 권한 제어 단원을 참조하십시오.

  • 역할을 수임한 경우 역할 세션이 세션 정책에 의해 제한되었을 수 있습니다. AWS STS 사용을 통해 프로그래밍 방식으로 임시 보안 자격 증명을 요청한 경우 인라인 또는 관리형 세션 정책을 전달할 수 있습니다. 세션 정책은 역할 대해 임시 세션을 프로그래밍 방식으로 생성할 때 파라미터로 전달하는 고급 정책입니다. Policy 파라미터를 사용하여 단일 JSON 인라인 세션 정책 문서를 전달할 수 있습니다. PolicyArns 파라미터를 사용하여 최대 10개까지 관리형 세션 정책을 지정할 수 있습니다. 결과적으로 얻는 세션의 권한은 사용자 또는 역할의 자격 증명 기반 정책의 교집합과 세션 정책입니다. 또는 관리자 또는 사용자 프로그램에서 임시 자격 증명을 제공한 경우 세션 정책에 포함되어 액세스를 제한했을 수 있습니다.

  • 연동 사용자인 경우 세션이 세션 정책에 의해 제한되었을 수 있습니다. IAM 사용자로 AWS에 로그인하여 연동 사용자가 된 후 연동 토큰을 요청합니다. 연동 사용자에 대한 자세한 내용은 GetFederationToken—사용자 지정 자격 증명 브로커를 통한 연동 단원을 참조하십시오. 사용자 또는 사용자의 자격 증명 브로커가 연동 토큰을 요청하는 동안 세션 정책을 전달한 경우 세션이 이러한 정책에 의해 제한됩니다. 결과적으로 얻는 세션의 권한은 IAM 사용자 자격 증명 기반 정책의 교집합과 세션 정책입니다. 세션 정책에 대한 자세한 정보는 세션 정책 단원을 참조하십시오.

  • 역할을 사용하여 리소스 기반 정책이 있는 리소스에 액세스할 경우, 해당 정책에서 역할에 권한을 부여하는지 확인합니다. 예를 들어, 다음과 같은 정책에서는 계정 MyRole111122223333MyBucket에 액세스하도록 허용합니다.

    { "Version": "2012-10-17", "Statement": [{ "Sid": "S3BucketPolicy", "Effect": "Allow", "Principal": {"AWS": ["arn:aws:iam::111122223333:role/MyRole"]}, "Action": ["s3:PutObject"], "Resource": ["arn:aws:s3:::MyBucket/*"] }] }

정책 변수가 작동하지 않습니다

  • 변수가 포함된 모든 정책에 버전 번호 "Version": "2012-10-17"이 있는지 확인하십시오. 올바른 버전 번호가 없으면 평가 도중에 변수가 대체되지 않습니다. 대신 변수는 문자 그대로 평가됩니다. 최신 버전 번호를 포함시키더라도 변수를 포함하지 않은 정책은 계속 작동합니다.

    Version 정책 요소는 정책 버전과 다릅니다. Version 정책 요소는 정책 내에서 사용되며 정책 언어의 버전을 정의합니다. 반면에 정책 버전은 IAM에서 고객 관리형 정책을 변경할 때 생성됩니다. 변경된 정책은 기존 정책을 덮어쓰지 않습니다. 대신 IAM에서 관리형 정책의 새 버전을 만듭니다. Version 정책 요소에 대한 자세한 정보는 IAM JSON 정책 요소: Version을 참조하십시오. 정책 버전에 대한 자세한 정보는 IAM 정책 버전 관리 단원을 참조하십시오.

  • 정책 변수가 올바른지 확인합니다. 자세한 정보는 IAM 정책 요소: 변수 및 태그 단원을 참조하십시오.

변경 사항이 매번 즉시 표시되는 것은 아닙니다

사용자들이 전세계 데이터 센터의 컴퓨터들을 통해 액세스하는 서비스인 IAM은 최종 일관성이라고 하는 분산 컴퓨팅 모델을 사용합니다. IAM(또는 다른 AWS 서비스)에서 변경한 사항을, 있을 수 있는 모든 엔드포인트에서 보게 될 때까지는 시간이 걸립니다. 일부 지연은 서버에서 서버로, 복제 영역에서 복제 영역으로, 전세계의 리전에서 리전으로 데이터를 보내는 데 걸리는 시간으로 인해 발생합니다. 또한 IAM는 캐싱을 사용하여 성능을 개선하지만 이 경우 중 몇몇 경우는 더 많은 시간이 소요될 수 있습니다. 이전에 캐시된 데이터가 시간 초과될 때까지 변경 사항이 표시되지 않을 수 있기 때문입니다.

이러한 잠재적 지연을 고려하도록 전역 애플리케이션을 설계해야 합니다. 한 위치에서 변경한 내용이 다른 위치에서 즉시 보이지 않을 때조차도 예상대로 작동하는지 확인합니다. 그러한 변경 사항에는 사용자, 그룹, 역할 또는 정책을 만들거나 업데이트한 것이 포함됩니다. 그러한 IAM 변경 사항을 애플리케이션의 중요한 고가용성 코드 경로에 포함시키지 않는 것이 좋습니다. 대신 자주 실행하지 않는 별도의 초기화 루틴이나 설정 루틴에서 IAM을 변경하십시오. 또한 프로덕션 워크플로우에서 변경 사항을 적용하기 전에 변경 사항이 전파되었는지 확인하십시오.

이로 인해 일부 다른 AWS 서비스가 받게 되는 영향에 대한 자세한 정보는 다음 자료를 참고하십시오.

iam:DeleteVirtualMFADevice를 수행할 권한이 없음

MFA 디바이스를 본인 또는 다른 사용자에게 할당하려 할 때 다음 오류가 표시될 수 있습니다.

User: arn:aws:iam::123456789012:user/Diego is not authorized to perform: iam:DeleteVirtualMFADevice on resource: arn:aws:iam::123456789012:mfa/Diego with an explicit deny

이는 이전에 다른 누군가가 가상 MFA 디바이스를 IAM 콘솔의 사용자에게 할당하기 시작했다가 프로세스를 취소한 경우 발생할 수 있습니다. 이를 통해 IAM에서 사용자에 대한 MFA 디바이스가 생성되지만 사용자와 완전히 연결되지는 않습니다. IAM 콘솔에서는 사용자와 새 디바이스 연결을 허용하기 전에 이전 MFA 디바이스 삭제를 요구합니다. 가상 MFA 디바이스 삭제를 허용하는 정책이 없는 경우 새 MFA 키와 사용자 연결을 위한 액세스가 거부됩니다.