メニュー
AWS Identity and Access Management
ユーザーガイド

MFA 保護 API アクセスの設定

IAM ポリシーで、ユーザーが呼び出すことができる API を指定できます。場合によっては、ユーザーが特に重要な処理を行う前にユーザーを AWS 多要素認証(MFA)で認証する、追加のセキュリティが必要です。

たとえば、ユーザーに Amazon EC2 RunInstancesDescribeInstances、および StopInstances アクションの実行を許可するポリシーが既に存在する可能性があります。ただし TerminateInstances のような有害なアクションを制限し、AWS MFA デバイスによって認証される場合に限り、ユーザーがそのアクションを実行できるよう管理することもできます。

概要

API に MFA 保護を追加する場合、次のタスクが関連します:

  1. 管理者は、MFA 認証を必要とする API リクエストを行う必要がある各ユーザーに対し、AWS MFA デバイスを設定します。このプロセスは、MFA デバイスの有効化 で説明されています。

  2. 管理者はユーザーに対し、ユーザーが AWS MFA デバイスで認証されているかどうかを確認する Condition 要素を含むポリシーを作成します。

  3. ユーザーは、後述の MFA 保護のシナリオに応じて、MFA パラメーターをサポートする STS API の 1 つ、AssumeRole または GetSessionToken を呼び出します。ユーザーは、ユーザーに関連付けられたデバイスのデバイス識別子、およびデバイスが生成する時間ベースのワンタイムパスワード (TOTP) を呼び出しに含めます。そのつど、ユーザーは一時的な認証情報を取り戻し、その情報を使用して AWS に追加リクエストを行うことができます。

    注記

    サービスの API の MFA 保護は、サービスが一時的なセキュリティ認証情報をサポートする場合にのみ使用できます。サポートするサービスの一覧については、「一時的セキュリティ認証情報を使用して AWS にアクセスする」を参照してください。

承認が失敗した場合、AWS は他の承認されていないアクセスと同様に "Access Denied" というエラーメッセージを返します。MFA 保護 API ポリシーが存在しており、ユーザーが有効な MFA 認証なしで API を使用しようとした場合や、API に対するリクエストのタイムスタンプがポリシーで規定されている範囲をオーバーした場合には、AWS はポリシーで特定された 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 ロールの信頼ポリシーを示します。このポリシーにより、ユーザーが MFA 認証されている場合のみ、Principal 要素(ACCOUNT-B-ID を有効な AWS アカウント ID に置き換えます)で指定された AWS アカウントのユーザーは、このポリシーがアタッチされたロールを引き受けることができます。

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

MFA の条件種別の詳細については、「使用できるグローバル条件キー」、「数値条件演算子」、および「条件キーの有無をチェックする条件演算子 」を参照してください。

GetSessionToken または AssumeRole を選択する

AWS STS には、ユーザーが MFA 情報を渡す際に使用できる 2 つの API、GetSessionTokenAssumeRole があります。ユーザーが一時的な認証情報を取得するために呼び出す API は、以下のどのシナリオがあてはまるかによって異なります。

次のシナリオでは GetSessionToken を使用します。

  • リクエストを作成する IAM ユーザーと同じ AWS アカウントのリソースにアクセスする API の呼び出し。GetSessionToken リクエストによる一時的な認証情報で IAM および STS API にアクセスできるのは、認証情報のリクエストに MFA 情報を含めた場合だけである点に注意してください。GetSessionToken によって返される一時的な認証情報には MFA 情報が含まれているので、認証情報によって実行された各 API 呼び出し内で MFA を確認できます。

  • リソースに基づくポリシー(MFA 条件を含む)で保護されているリソースへのアクセス。

次のシナリオでは AssumeRole を使用します。

  • 同じまたは異なる AWS アカウントのリソースにアクセスする API の呼び出し。API 呼び出しには IAM または STS API を含めることができます。アクセスを保護するには、ユーザーがロールを引き受けた時点で MFA を強制する必要があります。AssumeRole によって返される一時的な認証情報のコンテキストには MFA 情報が含まれていないので、MFA に対する個別の API 呼び出しを確認できません。このため、リソースベースのポリシーで保護されたリソースへのアクセスを制限するために、GetSessionToken を使用する必要があります。

これらのシナリオの実行方法に関する詳細は、本書で後から提供されます。

MFA 保護された API アクセスについて重要な点

API の MFA 保護の次の側面に注意してください:

  • MFA 保護は、一時的なセキュリティ認証情報を使用した場合のみ利用できます。この認証情報は、AssumeRole または GetSessionToken を使用して取得する必要があります。

  • AWS account root user 認証情報で MFA 保護 API アクセスを使用することはできません。

  • フェデレーションユーザーに AWS サービス利用のために MFA デバイスを割り当てることはできませんので、そのようなユーザーは MFA が管理する AWS リソースへアクセスできません。 (次のポイントを参照してください。)

  • 一時的な認証情報を返すその他の AWS STS API は、MFA をサポートしていません。AssumeRoleWithWebIdentityAssumeRoleWithSAML の場合、ユーザーは外部プロバイダーによって認証されており、プロバイダーが MFA を要求したかどうかを AWS が判断することはできません。GetFederationToken については、MFA は必ずしも特定のユーザーに関連付けられていません。

  • 同様に、長期的な認証情報 (IAM ユーザーアクセスキーと root user アクセスキー) は失効しないため、MFA 保護 API アクセスでは使用できません。

  • AssumeRoleGetSessionToken は、MFA 情報がない状態でも呼び出すことができます。この場合、発信者は一時的な認証情報を取り戻しますが、その一時的認証情報のセッション情報では、ユーザーが MFA を使用して認証されたことが示されません。

  • API に対する MFA 保護を確立するには、ポリシーに MFA 条件を追加します。ポリシーに MFA の条件が含まれていない場合、ポリシーは MFA の使用を強制しません。クロスアカウントの委任では、ロールの信頼ポリシーに MFA の条件が含まれていない場合、ロールの一時的な認証情報を使用して行われる API 呼び出しには MFA 保護はありません。

  • 別の AWS アカウントに自分のアカウントのリソースへのアクセスを許可するとき、多要素認証を要求する場合でも、リソースのセキュリティは、信頼されたアカウント(つまりお客様のアカウントではない、他のアカウント)の設定によって決まります。仮想 MFA デバイスを作成するアクセス許可がある、信頼されるアカウント内のアイデンティティは、ロールの信頼ポリシーのその部分を満たすために MFA クレームを作成できます。別のアカウントが多要素認証を必要とする自分の AWS リソースにアクセス可能にする前に、信頼されたアカウントの所有者がセキュリティに関するベストプラクティスに従い、MFA デバイス管理 API などの機密性の高い API へのアクセスを、特定の信頼されたアイデンティティに制限していることを確認します。

  • ポリシーに MFA の条件が含まれている場合、ユーザーが MFA 認証済みでないか、無効な MFA デバイス識別子または無効な TOTP を入力すると、リクエストは拒否されます。

シナリオ: クロスアカウントの委任の MFA 保護

このシナリオでは、ユーザーが AWS MFA デバイスを使用して認証された場合にのみ、別のアカウントの IAM ユーザーにアクセスを委任します。クロスアカウントの委任に関する詳細については、「ロールに関する用語と概念」を参照してください。

アカウント A(アクセス対象のリソースを所有している信頼するアカウント)があり、このアカウントに管理者権限を持つ IAM ユーザー Alice がいると仮定します。Alice は、アカウント B(信頼されたアカウント)のユーザー Bob にアクセス許可を付与するつもりですが、Bob がロールを引き受ける前に、MFA によって認証されていることを確認する必要があります。

  1. 信頼するアカウント A で、Alice は CrossAccountRole という IAM ロールを作成し、ロールの信頼ポリシーのプリンシパルをアカウント B のアカウント ID に設定します。この信頼ポリシーは、AWS STS AssumeRole アクションへのアクセス許可を与えます。Alice は、以下の例に示すように、信頼ポリシーに MFA の条件も追加します。

    Copy
    { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"AWS": "ACCOUNT-B-ID"}, "Action": "sts:AssumeRole", "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}} } }
  2. Alice は、ロールが実行できることを指定するアクセスポリシーを、ロールに追加します。MFA 保護を持つロールのアクセスポリシーは、他のロールアクセスポリシーと同じです。以下の例で、Alice がロールに追加したポリシーを示します。このポリシーは、アカウント A のテーブル Books で任意の DynamoDB アクションを実行することを、ロールを引き受けるユーザーに許可します。

    注記

    アクセスポリシーに MFA 条件は含まれません。ユーザーがロールを引き受けることができるかどうかを決定するためにのみ MFA 認証が使用されていることに注意してください。ユーザーがロールを引き受けた場合、それ以上の MFA の確認は行われません。

    Copy
    { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["dynamodb:*"], "Resource": ["arn:aws:dynamodb:region:ACCOUNT-A-ID:table/Books"] }] }
  3. 信頼されたアカウント B で、管理者は、IAM ユーザー Bob が AWS MFA デバイスを使用して設定されていること、および Bob がデバイスの ID(ハードウェア MFA デバイスの場合はシリアルナンバー、仮想 MFA デバイスの場合はデバイスの ARN)を知っていることを確認します。

  4. アカウント B で、管理者は、AssumeRole アクションを呼び出すことを許可する次のポリシーを、ユーザー Bob(または彼がメンバーとなっているグループ)にアタッチします。リソースは、Alice がステップ 1 で作成したロールの ARN に設定されます。このポリシーに MFA 条件が含まれないことに注意してください。

    Copy
    { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["sts:AssumeRole"], "Resource": ["arn:aws:iam::ACCOUNT-A-ID:role/CrossAccountRole"] }] }
  5. アカウント B で、Bob(または Bob が実行中のアプリケーション)が AssumeRole を呼び出します。API 呼び出しには、引き受けるロールの ARN(arn:aws:iam::ACCOUNT-A-ID:role/CrossAccountRole)、MFA デバイスの ID、Bob がデバイスから取得した現在の TOTP が含まれます。

    Bob が AssumeRole を呼び出すと、AWS が、MFA の要件など、有効な認証情報があるかどうかを確認します。その場合、ボブは正常にロールを引き受け、ロールの一時的な認証情報を使用して、アカウント A の Books という名前のテーブルで DynamoDB アクションを実行できます。

    AssumeRole を呼び出すプログラムの例については、「MFA 認証での AssumeRole の呼び出し(Python)」を参照してください。

シナリオ: 現在のアカウントの API へのアクセスに対する MFA 保護

このシナリオでは、お客様の AWS アカウントのユーザーが AWS MFA デバイスを使用して認証された場合のみ、機密性の高い API アクションにアクセスできるようにします。

アカウント A があり、そこに EC2 インスタンスの作業を必要としている開発者グループが存在すると仮定します。通常の開発者は、インスタンスの作業を実行できますが、ec2:StopInstances または ec2:TerminateInstances アクションへのアクセス許可を付与されていません。このようなの「有害な」特権的アクションをいくつかの信頼されたユーザーに制限するために、これらの機密性の高い Amazon EC2 アクションを許可するポリシーに MFA 保護を追加します。

このシナリオでは、その信頼されたユーザーの 1 人がユーザー Carol です。ユーザー Alice は、アカウント A の管理者です。

  1. Alice は、Carol が AWS MFA デバイスを使用して設定されていること、およびデバイスの ID(ハードウェア MFA デバイスの場合はシリアルナンバー、仮想 MFA デバイスの場合はデバイスの ARN)を知っていることを確認します。

  2. Alice は EC2-Admins という名のグループを作成し、ユーザー Carol をグループに追加します。

  3. Alice は、次のポリシーを EC2-Admins グループにアタッチします。このポリシーは、ユーザーが MFA を使用して認証された場合にのみ、ユーザーに Amazon EC2 StopInstances アクションと TerminateInstances アクションを呼び出すアクセス許可を与えます。

    Copy
    { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "ec2:StopInstances", "ec2:TerminateInstances" ], "Resource": ["*"], "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}} }] }
  4. ユーザー Carol が Amazon EC2 インスタンスを停止または終了する必要がある場合、Carol(または Carol が実行しているアプリケーション)は、Carol がデバイスから取得する MFA デバイスおよび現在の TOTP の ID を渡す GetSessionToken を呼び出します。

  5. ユーザー Carol(または Carol が使用しているアプリケーション)は、GetSessionToken によって提供される一時的な認証情報を使用して Amazon EC2 StopInstances または StopInstances アクションを呼び出します。

    GetSessionToken を呼び出すプログラムの例については、本書で後から説明する「MFA 認証での GetSessionToken の呼び出し(Python および C#)」を参照してください。

シナリオ: リソースベースのポリシーを持つリソースの MFA 保護

このシナリオでは、S3 バケット、SQS キュー、または SNS トピックの所有者として、リソースにアクセスするあらゆる AWS アカウントが AWS MFA デバイスを使用して認証されていることを確認します。

このシナリオは、最初にユーザーにロールを引き受けることを要求せずに、クロスアカウント MFA 保護を提供する方法を説明します。ユーザーが MFA によって認証されており、GetSessionToken を使用して一時的なセキュリティ認証情報を取得できる場合、およびユーザーのアカウントがリソースのポリシーによって信頼されている場合、ユーザーはリソースにアクセスできます。

アカウント A に存在し、S3 バケットを作成すると仮定します。さまざまな AWS アカウントに存在するユーザーが、MFA を使って認証されている場合にのみ、このバケットへのアクセスを許可します。

このシナリオでは、ユーザー Alice はアカウント A の管理者ユーザーです。ユーザー Charlie は、アカウント C の IAM ユーザーです。

  1. アカウント A で、Alice が Account-A-bucket という名前のバケットを作成します。

  2. Alice はバケットにバケットポリシーを追加します。このポリシーは、アカウント A、アカウント B、またはアカウント C のユーザーに、バケット内の S3 PutObject および DeleteObject アクションの実行を許可します。ポリシーは、MFA 条件を含みます。

    Copy
    { "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 削除機能が root アカウントアクセス(のみ)に提供されています。バケットのバージョニング状態を設定する際に、Amazon S3 MFA 削除機能を有効にできます。IAM ユーザーでは Amazon S3 MFA 削除機能を使うことはできず、また MFA 保護 API とは別のアクセス管理となっています。バケットの削除権限を持つ IAM ユーザーであっても、Amazon S3 MFA 削除機能を使用してバケットの削除を行うことはできません。Amazon S3 MFA 削除機能の詳細については、MFA Delete を参照してください。

  3. アカウント C で、管理者は、ユーザー Charlie が AWS MFA デバイスを使用して設定されていること、および Charlie がデバイスの ID(ハードウェア MFA デバイスの場合はシリアルナンバー、仮想 MFA デバイスの場合はデバイスの ARN)を知っていることを確認します。

  4. アカウント C で、Charlie(または Charlie が実行中のアプリケーション)が GetSessionToken を呼び出します。呼び出しには、MFA デバイスの ID または ARN、および Charlie がデバイスから取得する現在の TOTP が含まれます。

  5. Charlie(または Charlie が使用中のアプリケーション)は、GetSessionToken によって返された一時的な認証情報を使用して Amazon S3 PutObject アクションを呼び出し、ファイルを Account-A-bucket にアップロードします。

    GetSessionToken を呼び出すプログラムの例については、本書で後から説明する「MFA 認証での GetSessionToken の呼び出し(Python および C#)」を参照してください。

    注記

    AssumeRole が返す一時認証情報は、この場合機能しません。ユーザーはロールを引き受けるために MFA 情報を提供できますが、AssumeRole によって返された一時的な認証情報には、ポリシーの MFA 条件を満たすために必要な MFA 情報が含まれていないからです。