개요 시나리오: 크로스 계정 위임에 대한 MFA 보호 시나리오: 현재 계정의 API 작업에 대한 액세스를 위한 MFA 보호 시나리오: 리소스 기반 정책이 있는 리소스에 대한 MFA 보호

MFA 보호 API 액세스 구성

사용자가 호출할 수 있는 API 작업을 IAM 정책을 사용해 지정할 수 있습니다. 어떤 경우에는 사용자가 특히 중요한 작업을 수행할 수 있게 허용하기 전에 AWS 멀티 팩터 인증(MFA)으로 인증을 받도록 요구하는 추가 보안이 필요할 수 있습니다.

예를 들어 사용자가 Amazon EC2 RunInstances, DescribeInstances 및 StopInstances 작업을 수행하도록 허용하는 정책이 있을 수 있습니다. 하지만 TerminateInstances처럼 안전하지 않은 작업의 경우 이를 제한해 사용자가 AWS MFA 디바이스에서 인증할 때만 작업을 수행하도록 해야 할 필요가 있을 수 있습니다.

개요

API 작업에 MFA 보호를 추가하려면 다음과 같은 작업이 필요합니다.

관리자는 MFA 인증이 필요한 API 요청을 해야 하는 각 사용자에 대해 AWS MFA 디바이스를 구성합니다. 이 프로세스는 AWS에서 사용자에 대해 MFA 디바이스 활성화에 설명되어 있습니다.
관리자는 사용자가 AWS MFA 디바이스로 인증했는지 여부를 확인하는 Condition 요소가 포함된 사용자 정책을 생성합니다.
나중에 설명할 MFA 보호에 관한 시나리오에 따라 사용자는 MFA 파라미터를 지원하는 AWS STS API 작업인 AssumeRole 또는 GetSessionToken 중 하나를 호출합니다. 사용자는 사용자와 연결된 디바이스의 디바이스 식별자를 호출에 포함시킵니다. 또한 사용자는 디바이스에 생성하는 시간 기반 일회용 암호(TOTP)도 포함시킵니다. 각각의 경우, 사용자는 AWS에 추가 요청하는 데 사용하기 위해 임시 보안 자격 증명을 다시 가져옵니다.

참고
서비스의 API 작업에 대한 MFA 보호 기능은 해당 서비스에서 임시 보안 자격 증명을 지원하는 경우에만 사용 가능합니다. 이러한 서비스 목록은 임시 보안 자격 증명을 사용하여 AWS에 액세스를 참조하세요.

권한 부여에 실패한 경우 AWS는 "액세스가 거부되었습니다."라는 오류 메시지를 반환합니다(무단 액세스의 경우와 동일). MFA 보호 API 정책이 적용되는 경우, 사용자가 유효한 MFA 인증 없이 API 작업을 호출하려 하면 AWS에서는 정책에 지정된 API 작업에 대한 액세스를 거부합니다. API 작업 요청의 타임스탬프가 정책에 지정된 허용 범위를 벗어난 경우에도 작업이 거부됩니다. 사용자는 MFA 코드와 디바이스 일련 번호로 새 임시 보안 자격 증명을 요청하여 MFA 인증을 다시 해야 합니다.

MFA 조건이 포함된 IAM 정책

MFA 조건이 포함된 정책은 다음에 연결할 수 있습니다.

IAM 사용자 또는 그룹
Amazon S3 버킷, Amazon SQS 대기열, Amazon SNS 주제 등과 같은 리소스
사용자가 수임할 수 있는 IAM 역할의 신뢰 정책

정책의 MFA 조건을 사용해 다음과 같은 속성을 확인할 수 있습니다.

존재 - 사용자가 MFA로 인증했는지 간단히 확인하려면 Bool 조건에서 aws:MultiFactorAuthPresent 키가 True인지 확인합니다. 사용자가 단기 자격 증명으로 인증하는 경우에만 키가 있습니다. 액세스 키와 같은 장기 자격 증명에는 이 키가 포함되어 있지 않습니다.
기간 - MFA 인증 이후 지정된 시간 내에서만 액세스 권한을 부여하고 싶은 경우, 숫자 조건 유형을 사용하여 aws:MultiFactorAuthAge 키의 기간과 값(예: 3600초)을 비교합니다. MFA가 사용되지 않는 경우 aws:MultiFactorAuthAge 키가 없습니다.

다음 예는 MFA 인증의 존재를 테스트하는 MFA 조건을 포함하는 IAM 역할의 신뢰 정책을 보여줍니다. 이 정책을 통해 Principal 요소(ACCOUNT-B-ID를 유효한 AWS 계정 ID로 대체)에 지정된 AWS 계정의 사용자는 이 정책이 연결된 역할을 수임할 수 있습니다. 그러나 이러한 사용자는 MFA를 사용하여 인증을 받은 경우에만 역할을 수임할 수 있습니다.


{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "ACCOUNT-B-ID"},
    "Action": "sts:AssumeRole",
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  }
}

MFA의 조건 유형에 대한 자세한 내용은 AWS 글로벌 조건 컨텍스트 키, 숫자 조건 연산자 및 조건 키의 존재를 확인하는 조건 연산자 섹션을 참조하세요.

GetSessionToken과 AssumeRole 중에서 선택

AWS STS에서는 사용자가 MFA 정보를 전달할 수 있도록 GetSessionToken과 AssumeRole이라는 두 가지 API 작업을 제공합니다. 사용자가 임시 보안 자격 증명을 가져오기 위해 호출하는 API 작업은 다음 시나리오 중 어떤 것이 적용되느냐에 따라 달라집니다.

다음 시나리오에는 GetSessionToken을 사용합니다.

요청을 수행하는 IAM 사용자와 동일한 AWS 계정의 리소스에 액세스하는 API 작업을 호출합니다. GetSessionToken 요청의 임시 자격 증명은 작업 증명 요청에 MFA 정보를 포함하는 경우에만 IAM 및 AWS STS API 작업에 액세스할 수 있습니다. GetSessionToken에서 반환하는 임시 자격 증명에 MFA 정보가 포함되어 있으므로 자격 증명에서 수행하는 개별 API 작업에서 MFA를 확인할 수 있습니다.
MFA 조건이 포함된 리소스 기반 정책으로 보호되는 리소스에 액세스.

GetSessionToken 작업의 목적은 MFA를 사용하는 사용자를 인증하는 것입니다. 정책을 사용하여 인증 작업을 제어할 수는 없습니다.

다음 시나리오에는 AssumeRole을 사용합니다.

같은 또는 다른 AWS 계정의 리소스에 액세스하는 API 작업을 호출합니다. API 호출은 모든 IAM 또는 AWS STS API를 포함할 수 있습니다. 액세스를 보호하기 위해 사용자가 역할을 수임하는 시각에 MFA를 적용한다는 것에 유의하세요. AssumeRole에서 반환하는 임시 자격 증명은 컨텍스트에 MFA 정보를 포함하고 있지 않으므로 MFA에 대한 개별 API 작업을 확인할 수 없습니다. 이것이 바로 GetSessionToken을 사용해 리소스 기반 정책에 의해 보호되는 리소스에 대한 액세스를 제한해야 하는 이유입니다.

이러한 시나리오가 구현되는 방식에 대한 세부 정보는 이 문서의 후반부에 나와 있습니다.

MFA 보호 API 액세스에 대한 중요 사항

API 작업에 대한 MFA 보호가 지닌 다음과 같은 측면을 이해하는 것이 중요합니다.

MFA 보호는 임시 보안 자격 증명을 사용하는 경우에만 제공되며, 임시 보안 자격 증명은 AssumeRole 또는 GetSessionToken을 사용해 얻어야 합니다.
AWS 계정 루트 사용자 자격 증명으로는 MFA 보호 API 액세스를 사용할 수 없습니다.
U2F 보안 키로는 MFA 보호 API 액세스를 사용할 수 없습니다.
페더레이션 사용자는 AWS 서비스에 사용할 MFA 디바이스를 할당받을 수 없으므로, MFA에서 제어하는 AWS 리소스에 액세스할 수 없습니다. (다음 참조.)
임시 자격 증명을 반환하는 다른 AWS STS API 작업에서는 MFA를 지원하지 않습니다. AssumeRoleWithWebIdentity 및 AssumeRoleWithSAML의 경우 사용자는 외부 공급자에 의해 인증되며 AWS에서는 그 공급자가 MFA를 요구했는지를 확인할 수 없습니다. GetFederationToken의 경우 MFA가 특정 사용자와 반드시 연결되는 것은 아닙니다.
이와 마찬가지로 장기 자격 증명(IAM 사용자 액세스 키 및 루트 사용자 액세스 키)은 만료되지 않기 때문에 MFA 보호 API 액세스를 통해 사용할 수 없습니다.
또한, AssumeRole 및 GetSessionToken은 MFA 정보 없이도 호출할 수 있습니다. 이 경우 호출자는 임시 보안 자격 증명을 다시 가져오지만, 그러한 임시 자격 증명의 세션 정보에는 사용자가 MFA로 인증했는지 나타나지 않습니다.
API 작업에 대해 MFA 보호를 설정하려면 정책에 MFA 조건을 추가하면 됩니다. MFA 사용을 적용하기 위해 정책에는 aws:MultiFactorAuthPresent 조건 키가 포함되어 있어야 합니다. 크로스 계정 위임을 위해 역할의 신뢰 정책에는 조건 키가 포함되어 있어야 합니다.
다른 AWS 계정이 내 계정의 리소스에 액세스하도록 허용하는 경우, 리소스의 보안은 신뢰할 수 있는 계정, 즉 다른 계정(내 계정이 아님)의 구성에 따라 달라집니다. 이것은 멀티 팩터 인증이 필요할 때도 마찬가지입니다. 가상 MFA 디바이스를 생성할 권한이 있는 신뢰할 수 있는 계정 내의 어떤 자격 증명도 MFA 클레임을 생성하여 역할의 신뢰 정책의 해당 부분을 충족할 수 있습니다. 멀티 팩터 인증을 요구하는 AWS 리소스에 대한 액세스를 다른 계정의 멤버에게 허용하기 전에 신뢰할 수 있는 계정의 소유자가 보안 모범 사례를 따르도록 해야 합니다. 예를 들어 신뢰할 수 있는 계정에서는 MFA 디바이스 관리 API 작업과 같은 중요 API 작업에 대한 액세스를 신뢰할 수 있는 특정 자격 증명으로 제한해야 합니다.
정책에 MFA 조건이 포함된 경우, 사용자가 MFA에 인증되지 않거나 잘못된 MFA 디바이스 식별자 또는 잘못된 TOTP를 제공하는 경우 요청이 거부됩니다.

시나리오: 크로스 계정 위임에 대한 MFA 보호

이 시나리오에서는 다른 계정의 IAM 사용자에게 액세스 권한을 위임하려고 합니다. 단 해당 사용자가 AWS MFA 디바이스로 인증된 경우에 한합니다. (크로스 계정 위임에 대한 자세한 내용은 역할 용어 및 개념 섹션을 참조하세요.)

계정 A(액세스할 리소스를 소유한 신뢰하는 계정)에 관리자 권한이 있는 IAM 사용자 Anaya가 있다고 가정해 봅시다. 그녀는 계정 B(신뢰할 수 있는 계정)의 사용자 Richard에게 액세스 권한을 부여하고 싶지만, Richard가 MFA에 인증되었는지 확인한 후에 그가 역할을 수임하기를 원합니다.

신뢰하는 계정 A에서 Anaya는 CrossAccountRole이라는 IAM 역할을 생성하고 해당 역할의 신뢰 정책에서 보안 주체를 계정 B의 계정 ID로 설정합니다. 이 신뢰 정책은 AWS STS AssumeRole 작업에 대한 권한을 부여합니다. 또한 Anaya는 다음 예와 같이 신뢰 정책에 MFA 조건을 추가합니다.
```
{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "ACCOUNT-B-ID"},
    "Action": "sts:AssumeRole",
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  }
}
```
Anaya는 역할이 수행할 수 있는 작업을 지정하는 역할에 권한 정책을 추가합니다. MFA 보호 기능이 포함된 역할의 권한 정책은 다른 역할 권한 정책과 다르지 않습니다. 다음 예제에서는 Anaya가 역할에 추가하는 정책을 보여줍니다. 역할을 수임한 사용자는 이 정책을 통해 계정 A의 Books 테이블에서 Amazon DynamoDB 작업을 수행할 수 있고, 아울러 콘솔에서 작업을 수행할 때 필요한 dynamodb:ListTables 작업을 할 수 있습니다.

참고
권한 정책은 MFA 조건을 포함하지 않습니다. MFA 인증은 사용자가 역할을 수임할 수 있는지 여부를 결정하는 데에만 사용된다는 점을 알아두세요. 사용자가 역할을 수임하면 MFA 검사가 추가로 수행되지 않습니다.
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "TableActions",
            "Effect": "Allow",
            "Action": "dynamodb:*",
            "Resource": "arn:aws:dynamodb:*:ACCOUNT-A-ID:table/Books"
        },
        {
            "Sid": "ListTables",
            "Effect": "Allow",
            "Action": "dynamodb:ListTables",
            "Resource": "*"
        }
    ]
}
```
신뢰할 수 있는 계정 B에서 관리자는 IAM 사용자 Richard가 AWS MFA 디바이스로 구성되었는지, 그리고 그가 이 디바이스의 ID를 알고 있는지 확인합니다. 디바이스 ID란 하드웨어 MFA 디바이스의 경우 일련 번호이며, 가상 MFA 디바이스의 경우 해당 디바이스의 ARN입니다.
계정 B에서 관리자는 사용자 Richard(또는 그가 소속된 그룹)에게 AssumeRole 작업을 호출할 수 있도록 허용하는 다음과 같은 정책을 연결합니다. 리소스는 Anaya가 1단계에서 생성한 역할의 ARN으로 설정됩니다. 이 정책에는 MFA 조건이 포함되어 있지 않습니다.
```
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["sts:AssumeRole"],
    "Resource": ["arn:aws:iam::ACCOUNT-A-ID:role/CrossAccountRole"]
  }]
}
```
계정 B에서 Richard(또는 Richard가 실행하는 애플리케이션)는 AssumeRole을 호출합니다. API 호출에는 위임할 역할의 ARN(arn:aws:iam::ACCOUNT-A-ID:role/CrossAccountRole), MFA 디바이스의 ID 및 Richard가 자신의 디바이스에서 가져오는 현재 TOTP가 포함되어 있습니다.

Richard가 AssumeRole을 호출하면, AWS에서 그가 MFA에 대한 요건을 포함해 유효한 자격 증명을 갖고 있는지 여부를 확인합니다. 만일 Richard가 유효한 자격 증명을 갖고 있다면 성공적으로 역할을 수임해 역할의 임시 자격 증명을 사용함과 동시에 계정 A에서 Books라는 테이블에 대해 어떤 DynamoDB 작업도 수행할 수 있습니다.

AssumeRole을 호출하는 프로그램의 예는 MFA 인증이 포함된 AssumeRole 호출 섹션을 참조하세요.

시나리오: 현재 계정의 API 작업에 대한 액세스를 위한 MFA 보호

이 시나리오에서는 AWS 계정의 사용자가 AWS MFA 디바이스를 사용해 인증받은 경우에만 중요한 API 작업에 액세스할 수 있는지 확인해야 합니다.

계정 A에 EC2 인스턴스로 작업해야 하는 개발자 그룹이 있다고 가정해 봅시다. 일반적인 개발자들은 이 인스턴스를 사용할 수 있지만, ec2:StopInstances 또는 ec2:TerminateInstances 작업에 대한 권한은 없습니다. 그와 같은 "안전하지 않은" 권한이 있는 작업을 일부 신뢰할 수 있는 사용자만 액세스할 수 있게 제한하고자 하여, 이러한 민감한 Amazon EC2 작업을 허용하는 정책에 MFA 보호를 추가합니다.

이 시나리오에서 신뢰할 수 있는 사용자 중 한 명은 사용자 Sofía입니다. 사용자 Anaya는 계정 A의 관리자입니다.

Anaya는 Sofia가 AWS MFA 디바이스로 구성되었는지, 그리고 Sofia가 이 디바이스의 ID를 알고 있는지 확인합니다. 디바이스 ID란 하드웨어 MFA 디바이스의 경우 일련 번호이며, 가상 MFA 디바이스의 경우 해당 디바이스의 ARN입니다.
Anaya는 EC2-Admins라는 그룹을 생성하고 이 그룹에 사용자 Sofía를 추가합니다.
Anaya는 EC2-Admins 그룹에 다음과 같은 정책을 연결합니다. 이 정책은 사용자에게 Amazon EC2 StopInstances 및 TerminateInstances 작업을 호출할 권한을 부여하는데, 단 이 사용자가 MFA를 사용하여 인증되었을 경우에 한합니다.
```
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "ec2:StopInstances",
      "ec2:TerminateInstances"
    ],
    "Resource": ["*"],
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  }]
}
```
참고
이 정책의 효력이 발생하려면 사용자는 먼저 로그아웃한 한 후 다시 로그인해야 합니다.

사용자 Sofía가 Amazon EC2 인스턴스를 중지하거나 종료해야 하는 경우, Sofia(또는 Sofia가 실행하는 애플리케이션)는 GetSessionToken을 호출합니다. 이 API 작업에서는 MFA 디바이스의 ID와 Sofia가 자신의 디바이스에서 가져오는 현재 TOTP를 전달합니다.
사용자 Sofía(또는 Sofía가 사용하는 애플리케이션)는 GetSessionToken에서 제공하는 임시 자격 증명을 사용하여 Amazon EC2 StopInstances 또는 TerminateInstances 작업을 호출합니다.

GetSessionToken을 호출하는 프로그램의 예는 이 문서의 후반부에 있는 MFA 인증이 포함된 GetSessionToken 호출 섹션을 참조하세요.

시나리오: 리소스 기반 정책이 있는 리소스에 대한 MFA 보호

이 시나리오에서는 S3 버킷, SQS 대기열 또는 SNS 주제의 소유자입니다. 리소스에 액세스하는 모든 AWS 계정 사용자가 AWS MFA 디바이스로 인증되었는지 확인하려고 합니다.

이 시나리오는 사용자가 역할을 먼저 수임하지 않고도 크로스 계정 MFA 보호를 제공하는 방법을 설명합니다. 이 경우 사용자는 세 가지 조건이 충족되면 리소스에 액세스할 수 있습니다. 즉 사용자는 MFA로 인증을 받아야 하고, GetSessionToken에서 임시 보안 자격 증명을 가져올 수 있어야 하며, 리소스의 정책에서 신뢰하는 계정에 로그인해 있어야 합니다.

계정 A에 속해 있고 S3 버킷을 생성한다고 가정해 봅시다. 여러 AWS 계정에 속한 사용자에게 이 버킷에 대한 액세스를 부여하되, 사용자가 MFA로 인증한 경우에 한하고자 합니다.

이 시나리오에서 사용자 Anaya는 계정 A의 관리자입니다. 사용자 Nikhil은 계정 C의 IAM 사용자입니다.

계정 A에서 Anaya는 Account-A-bucket이라는 버킷을 생성합니다.
Anaya는 이 버킷에 버킷 정책을 추가합니다. 이 정책은 계정 A, 계정 B 또는 계정 C의 모든 사용자가 이 버킷에서 Amazon S3 PutObject 및 DeleteObject 작업을 수행하도록 허용합니다. 이 정책에는 MFA 조건이 포함되어 있습니다.
```
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": [
      "ACCOUNT-A-ID",
      "ACCOUNT-B-ID",
      "ACCOUNT-C-ID"
    ]},
    "Action": [
      "s3:PutObject",
      "s3:DeleteObject"
    ],
    "Resource": ["arn:aws:s3:::ACCOUNT-A-BUCKET-NAME/*"],
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  }]
}
```
참고
Amazon S3는 루트 계정 액세스에 대해(서만) MFA Delete 기능을 제공합니다. 버킷의 버전 관리 상태를 설정할 때 Amazon S3 MFA Delete를 활성화할 수 있습니다. Amazon S3 MFA Delete는 IAM 사용자에 적용할 수 없으며 MFA 보호 API 액세스와 별개로 관리됩니다. 버킷을 삭제할 권한이 있는 IAM 사용자도 Amazon S3 MFA Delete가 활성화된 버킷은 삭제할 수 없습니다. Amazon S3 MFA Delete에 대한 자세한 내용은 MFA Delete를 참조하세요.
계정 C에서 관리자는 사용자 Nikhil이 AWS MFA 디바이스로 구성되어 있고 해당 디바이스의 ID를 알고 있는지 확인합니다. 디바이스 ID란 하드웨어 MFA 디바이스의 경우 일련 번호이며, 가상 MFA 디바이스의 경우 해당 디바이스의 ARN입니다.
계정 C에서 Nikhil(또는 그가 실행하는 애플리케이션)은 GetSessionToken을 호출합니다. 이 호출에는 MFA 디바이스의 ID 또는 ARN과 Nikhil이 자신의 디바이스에서 가져오는 현재 TOTP가 포함되어 있습니다.
Nikhil(또는 그가 사용하는 애플리케이션)은 GetSessionToken에서 반환하는 임시 자격 증명을 사용하여 Account-A-bucket으로 파일을 업로드하는 Amazon S3 PutObject 작업을 호출합니다.

GetSessionToken을 호출하는 프로그램의 예는 이 문서의 후반부에 있는 MFA 인증이 포함된 GetSessionToken 호출 섹션을 참조하세요.

참고
AssumeRole이 반환하는 임시 자격 증명은 이 경우에는 유효하지 않습니다. 사용자는 역할 수임을 위해 MFA 정보를 제공할 수 있지만 AssumeRole에서 반환하는 임시 자격 증명에는 MFA 정보가 포함되어 있지 않습니다. 이 정보는 정책의 MFA 조건을 충족하기 위해 필요합니다.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

MFA 디바이스 분실 또는 작동 중단 시 문제 해결

샘플 코드: MFA