

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 拒否ポリシーを使用してアクティブなユーザーの権限を取り消す
<a name="prereqs-revoking-user-permissions"></a>

ユーザーがアクセス許可セットをアクティブに使用している AWS アカウント 間は、IAM Identity Center ユーザーの へのアクセスを取り消す必要がある場合があります。ユーザーを指定しない拒否ポリシーを事前に実装しておくことで、ユーザーがアクティブな IAM ロールセッションを使用する機能を削除できます。必要に応じて、拒否ポリシーを更新し、アクセスをブロックするユーザーを指定することができます。このトピックでは、拒否ポリシーを作成する方法と、ポリシーをデプロイする方法に関する注意事項について説明します。

## 権限セットによって作成されたアクティブな IAM ロールセッションを取り消す準備をする
<a name="prepare-to-revoke-session"></a>

サービスコントロールポリシーを使用して特定のユーザーに対して「すべてを拒否する」ポリシーを適用することで、ユーザーがアクティブに使用している IAM ロールでアクションを実行できないようにすることができます。また、パスワードを変更するまで、ユーザーが権限セットを使用することを禁止できます。これにより、盗まれた認証情報を不正使用している攻撃者を排除できます。広範囲にわたってアクセスを拒否し、ユーザーが権限セットに再参加したり他の権限セットに参加しようとする行為も阻止したい場合は、すべてのユーザーアクセスを削除してアクティブな AWS アクセスポータルセッションを停止し、かつユーザーのサインインを無効にする必要があるかもしれません。より広範なアクセス取り消しのための追加アクションと併せて拒否ポリシーを発動する方法については、「[ワークフォースユーザーのアクティブなセッションを表示および終了する](end-active-sessions.md)」を参照してください。

### 拒否ポリシー
<a name="deny-policy"></a>

IAM アイデンティティセンターアイデンティティストア内のユーザー `UserID` と一致する条件を持つ拒否ポリシーを使用することで、そのユーザーがアクティブに使用中の IAM ロールによるさらなるアクション実行を阻止することができます。こうしたポリシーの使用により、拒否ポリシーのデプロイ時に同じ権限セットを使用している他のユーザーへの影響を回避できます。このポリシーは、アクセスを取り消すユーザー ID で更新される `"identitystore:userId"` のプレースホルダーユーザー ID として、「*`Add user ID here`*」を使用します。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "*"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "identitystore:userId": "Add user ID here"  
                }
            }
        }
    ]
}
```

------

`“aws:userId”` などの別の条件キーを使用することもできますが、`“identitystore:userId”` は 1 人のユーザーに関連付けられるグローバルに一意の値であるため、より確実です。条件内での `“aws:userId”` の使用は、ユーザー属性が ID のソースから同期される方法に影響を受けるため、ユーザーのユーザー名または E メールアドレスが変更された場合に属性が変化する可能性があります。

IAM アイデンティティセンターコンソールから **[ユーザー]** に移動し、名前でユーザーを検索して **[一般情報]** セクションを展開し、ユーザー ID をコピーすることで、ユーザーの `identitystore:userId` を確認することができます。また、ユーザー ID を検索しながら、ユーザーの AWS アクセスポータルセッションを停止し、同じセクションでサインインアクセスを無効にするのも便利です。ID ストア API に対するクエリによりユーザーのユーザー ID を取得することで、拒否ポリシーを作成するプロセスを自動化できます。

### 拒否ポリシーをデプロイする
<a name="deploy-deny-policy"></a>

 など、有効でないプレースホルダーユーザー ID を使用して`Add user ID here`、 AWS アカウント ユーザーにアタッチしたサービスコントロールポリシー (SCP) を使用して拒否ポリシーを事前にデプロイできます。このアプローチはシンプルかつすばやく影響が発揮されるため、お勧めの方法です。拒否ポリシーを使用してユーザーのアクセス権を取り消す場合、ポリシーを編集して、プレースホルダーユーザー ID をアクセス権を取り消したいユーザーのユーザー ID に置き換えます。これにより、SCP をアタッチしたすべてのアカウントの権限セットで、ユーザーがアクションを起こすことを防ぐことができます。そのユーザーがアクティブな AWS アクセスポータルセッションを使用して異なるアカウントに移動し、異なるロールを引き受けようとしても、そのようなアクションはブロックされます。ユーザーのアクセスが SCP によって完全にブロックされると、サインイン、割り当ての取り消し、必要に応じて AWS アクセスポータルセッションを停止する機能を無効にできます。

SCP を使用する代わりに、権限セットのインラインポリシーと、ユーザーがアクセスできる権限セットで使用されるカスタマー管理ポリシーに拒否ポリシーを含めることもできます。

複数のユーザーのアクセスを取り消す必要がある場合は、以下のような条件ブロックの値のリストを使用できます。

```
            "Condition": {
                    "StringEquals": {
                        "identitystore:userId": [" user1 userId", "user2 userId"...]
                        }
        }
```

**重要**  
どのような方法を使用する場合でも、併せてその他の是正措置を講じ、そのユーザーのユーザー ID を拒否ポリシー内に少なくとも 12 時間保持する必要があります。12 時間後にはユーザーが引き受けていたロールはすべて失効しているため、拒否ポリシーからユーザー ID を削除できます。