一時的なセキュリティ認証情報のアクセス権限を無効にする
一時的なセキュリティ認証情報は、期限が切れるまで有効です。これらの認証情報は、900 秒 (15 分) から最大 129,600 秒 (36 時間) までの指定された期間有効です。デフォルトのセッション時間は 43,200 秒 (12 時間) です。これらの認証情報は取り消すことができますが、認証情報を漏洩させて悪意あるアカウントの活動に利用されないようにロールのアクセス許可を変更する方法もあります。一時的なセキュリティ認証情報に割り当てられるアクセス許可は、AWS のリクエストの実行に使用されるたびに評価されます。認証情報からすべてのアクセス許可を削除すると、それらを使用している AWS のリクエストは失敗します。
ポリシーの更新が有効になるまでには、数分かかる場合があります。ロールの一時的なセキュリティ認証情報を取り消し、ロールを引き受けるすべてのユーザーに新しい認証情報の再認証およびリクエストを強制します。
AWS アカウントのルートユーザー のアクセス許可を変更することはできません。同様に、ルートユーザーとしてサインインしているときに GetFederationToken
または GetSessionToken
を呼び出して作成した一時的セキュリティ認証情報のアクセス許可を変更することはできません。そのため、ルートユーザーとして GetFederationToken
または GetSessionToken
を呼び出さないようお勧めします。
重要
IAM アイデンティティセンターのアクセス許可セットから作成された IAM のロールを編集することはできません。IAM アイデンティティセンターでユーザーのアクティブなアクセス許可セットセッションを取り消す必要があります。詳細については、「IAM Identity Center ユーザーガイド」の「Revoke active IAM role sessions created by permission sets」を参照してください。
トピック
ロールに関連するすべてのセッションへのアクセスを拒否する
次のような不審なアクセスが懸念される場合は、この方法を使用します。
-
クロスアカウントアクセスを使用している別のアカウントのプリンシパル
-
アカウント内の AWS リソースへのアクセス許可を持つ外部ユーザー ID
-
OIDC プロバイダーを使用して、モバイルまたはウェブアプリケーションで認証されているユーザー
このプロシージャでは、ロールを引き受けるアクセス許可を持つすべてのユーザーのアクセス許可を拒否します。
AssumeRole
、AssumeRoleWithSAML
、または AssumeRoleWithWebIdentity
、GetFederationToken
、または GetSessionToken
を呼び出して取得した一時的なセキュリティ認証情報に割り当てたアクセス許可を変更または削除するには、ロールのアクセス許可を定義するアクセス許可ポリシーを編集または削除します。
重要
また、プリンシパルのアクセスを許可するリソースベースのポリシーがある場合、そのリソースに対する明示的な拒否を追加する必要があります。詳細については、「リソースベースのポリシーでセッションユーザーを拒否する」を参照してください。
-
AWS Management Console にサインインし、IAM コンソール を開きます。
-
ナビゲーションペインで、編集するユーザーの名前を選択します。検索ボックスを使用してリストをフィルタリングします。
-
該当するポリシーを選択します。
-
[アクセス許可] タブを選択します。
-
[JSON] タブを選択してポリシーを更新し、すべてのリソースとアクションを拒否します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "*", "Resource": "*" } ] }
-
[確認] ページで、ポリシーの [概要] を確認してから、[変更の保存] を選択して作業を保存します。
ロールのポリシーを更新すると、変更内容はそのロールに関連付けられているすべての一時的なセキュリティ認証情報のアクセス許可に影響します。これには、ロールのアクセス許可ポリシーを変更する前に発行された認証情報も含まれます。ポリシーを更新すると、ロールの一時的なセキュリティ認証情報を取り消し、ロールが発行した認証情報に対するすべてのアクセス許可をすぐに取り消すことができます。
特定のセッションへのアクセスを拒否する
deny-all (すべて拒否) ポリシーを使用して IdP から引き継がれるロールを更新したり、ロールを完全に削除したりすると、そのロールにアクセスできるすべてのユーザーのアクセスが中断されます。ロールに関連する他のすべてのセッションのアクセス許可に影響を与えずに、Principal
要素に基づいてアクセスを拒否できます。
Principal
は、条件コンテキストキーまたはリソースベースのポリシーを使用してアクセス許可を拒否できます。
ヒント
AWS CloudTrail ログを使用して、フェデレーションユーザーの ARN を確認できます。詳細については、「AWS CloudTrail を使用してフェデレーションユーザーを簡単に識別する方法
条件コンテキストキーを使用してユーザーセッションを拒否する
条件コンテキストキーは、認証情報を作成した IAM ユーザーまたはロールのアクセス許可に影響を与えることなく一時的なセキュリティ認証情報へのアクセスを拒否したい場合に使用できます。
条件コンテキストキーの詳細については、「AWS グローバル条件コンテキストキー」を参照してください。
注記
また、プリンシパルのアクセスを許可するリソースベースのポリシーがある場合、これらの手順の完了後にリソースベースのポリシーで明示的な拒否を追加する必要があります。
ポリシーの更新後は、ロールの一時的なセキュリティ認証情報を取り消し、すべての発行された認証情報をすぐに取り消すことができます。
aws:PrincipalArn
条件コンテキストキー aws:PrincipalArn を使用して、特定のプリンシパル ARN のアクセスを拒否できます。これを行うには、ポリシーの Condition 要素で、一時的なセキュリティ認証情報が関連付けられている IAM ユーザー、ロール、またはフェデレーションユーザーの一意の識別子 (ID) を指定します。
-
IAM コンソールのナビゲーションペインで、編集するロールの名前を選択します。検索ボックスを使用してリストをフィルタリングします。
-
該当するポリシーを選択します。
-
[アクセス許可] タブを選択します。
-
[JSON] タブを選択し、次の例に示すようにプリンシパル ARN の拒否ステートメントを追加します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "ArnEquals": { "aws:PrincipalArn": [ "arn:aws:iam::
222222222222
:role/ROLENAME
", "arn:aws:iam::222222222222
:user/USERNAME
", "arn:aws:iam::222222222222
:federated-user/USERNAME
" ] } } } ] } -
[確認] ページで、ポリシーの [概要] を確認してから、[変更の保存] を選択して作業を保存します。
aws:SourceIdentity
条件コンテキストキー aws:SourceIdentity を使用すると、ロールセッションに関連付けられている特定のソース ID へのアクセスを拒否できます。これは、プリンシパルが任意の AWS STS assume-role
* CLI コマンドまたは AWS STS AssumeRole
* API オペレーションを使用してロールを引き受けるときに、SourceIdentity
リクエストパラメータを設定することでロールセッションを発行したのであれば、必ず適用されます。このためには、一時的なセキュリティ認証情報が関連付けられているソース ID をポリシーの Condition
要素に指定します。
コンテキストキー sts:RoleSessionName とは異なり、ソース ID を設定した後は、値を変更できません。aws:SourceIdentity
キーは、ロールが実行するすべてのアクションのリクエストコンテキストに存在します。セッション認証情報を使用して別のロールを引き受けた場合、ソース ID は後続のロールセッションに引き継がれます。別のロールからあるロールを引き受けると、ロールの連鎖と呼ばれます。
次のポリシーは、条件コンテキストキー aws:SourceIdentity
を使用して一時的なセキュリティ認証情報のセッションへのアクセスを拒否する方法の例を示しています。ロールセッションに関連付けられたソース ID を指定した場合、認証情報を作成したロールのアクセス許可に影響を与えることなく、その指定されたソース ID に関連付けられたロールセッションが拒否されます。この例の場合、ロールセッションの発行時にプリンシパルによって設定されたソース ID は nikki_wolf@example.com
です。ポリシーの Condition にソース ID が含まれ、ポリシーの Effect が Deny
に設定されているため、nikki_wolf@example.com
ソース ID とのロールセッションで行われるリクエストは拒否されます。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "StringLike": { "aws:SourceIdentity": [ "
nikki_wolf@example.com
", "<source identity value>
" ] } } } ] }
aws:userid
条件コンテキストキー aws:userid を使用して、IAM ユーザーまたはロールに関連する一時的なセキュリティ認証情報のすべてまたは特定のセッションへのアクセスを拒否できます。これを行うには、ポリシーの Condition
要素で、一時的なセキュリティ認証情報が関連付けられている IAM ユーザー、ロール、またはフェデレーションユーザーの一意の識別子 (ID) を指定します。
次のポリシーは、条件コンテキストキー aws:userid
を使用して一時的なセキュリティ認証情報のセッションへのアクセスを拒否する方法の例を示しています。
-
AIDAXUSER1
は、IAM ユーザー用の一意の識別子を表します。IAM ユーザーの一意の識別子をコンテキストキーaws:userid
の値として指定すると、IAM ユーザーに関連するすべてのセッションが拒否されます。 -
AROAXROLE1
は、IAM ロール用の一意の識別子を表します。IAM ロールの一意の識別子をコンテキストキーaws:userid
の値として指定すると、そのロールに関連するすべてのセッションが拒否されます。 -
AROAXROLE2:<caller-specified-role-session-name>
は、assumed-role セッション用の一意の識別子を表します。assumed-role の一意の識別子の caller-specified-role-session-name の部分で、ロールのセッション名を指定するか、StringLike 条件演算子を使用する場合はワイルドカード文字を指定できます。ロールのセッション名を指定すると、認証情報を作成したロールのアクセス許可に影響を与えずに、指定されたロールのセッションが拒否されます。ロールのセッション名にワイルドカードを指定すると、そのロールに関連するすべてのセッションが拒否されます。注記
呼び出し側で指定したロールセッション名 (引き受けたロールセッションの一意の識別子の一部) は、ロールの連鎖の際に変更できます。ロールの連鎖は、あるロールが別のロールを引き受けると発生します。ロールセッション名は、プリンシパルが AWS STS
AssumeRole
API オペレーションを使用してロールを引き受けるときに、RoleSessionName
リクエストパラメータを使用して設定します。 -
account-id:<federated-user-caller-specified-name>
は、フェデレーションユーザーのセッション用の一意の識別子を表します。フェデレーションユーザーは、GetFederationToken API を呼び出す IAM ユーザーによって作成されます。フェデレーションユーザーの一意の識別子を指定すると、認証情報を作成したロールのアクセス許可に影響を与えずに、フェデレーションユーザーのセッションが拒否されます。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "StringLike": { "aws:userId": [ "
AIDAXUSER1
", "AROAXROLE1
", "AROAXROLE2
:<caller-specified-role-session-name
>", "account-id
:<federated-user-caller-specified-name
>" ] } } } ] }
プリンシパルキーの値の具体的な例については、「プリンシパルキーの値」を参照してください。IAM の一意の識別子についての詳細は、「一意の識別子」を参照してください。
リソースベースのポリシーでセッションユーザーを拒否する
リソースベースのポリシーにプリンシパル ARN も含まれている場合、リソースベースのポリシーにある Principal
要素の特定のユーザーの principalId
または sourceIdentity
の値に基づきアクセス権を取り消す必要もあります。ロールのアクセス許可ポリシーのみを更新した場合でも、ユーザーはリソースベースのポリシーで許可されているアクションを実行できます。
-
サービスがリソースベースのポリシーをサポートしているかどうかについては、「IAM と連携する AWS のサービス」を確認してください。
-
AWS Management Console にサインインして、サービスのコンソールを開きます。ポリシーをアタッチするコンソール内の場所は、サービスごとに異なります。
-
ポリシーステートメントを編集して、認証情報の識別する情報を指定します。
-
Principal
に、拒否する認証情報の ARN を入力します。 -
Effect
に、「Deny」と入力します。 -
Action
に、サービスの名前空間と拒否するアクションの名前を入力します。すべてのアクションを拒否するには、ワイルドカード (*) 文字を使用します。たとえば、「s3:*」と入力します。 -
Resource
に、ターゲットリソースの ARN を入力します。例えば、「arn:aws:s3:::amzn-s3-demo-bucket」と入力します。
{ "Version": "2012-10-17", "Statement": { "Principal": [ "arn:aws:iam::
222222222222
:role/ROLENAME
", "arn:aws:iam::222222222222
:user/USERNAME
", "arn:aws:sts::222222222222
:federated-user/USERNAME
" ], "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3
:::amzn-s3-demo-bucket
" } } -
-
作業内容を保存します。