• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。 # ノードの承認ポリシーを作成する 承認ポリシーでは、ユーザーがノードにアクセスするために必要な承認を定義します。ジャストインタイムノードアクセスでは、IAM ポリシーを通じたノードへの長期的なアクセス許可が不要になるため、ノードへのアクセスを許可する承認ポリシーを作成する必要があります。ノードに適用される承認ポリシーがない場合、ユーザーはノードへのアクセスをリクエストできません。 ジャストインタイムノードアクセスには、3 つのポリシータイプがあります。このポリシータイプは、*自動承認*、*アクセス拒否*、および*手動承認*です。 **ジャストインタイムノードアクセスポリシータイプ** + 自動承認ポリシーでは、ユーザーが自動的に接続できるノードを定義します。 + 手動承認ポリシーでは、指定したノードにアクセスするために必要な手動承認の数とレベルを定義します。 + アクセス拒否ポリシーを使用すると、指定したノードへのアクセスリクエストの自動承認を明示的に防ぐことができます。 アクセス拒否ポリシーは、AWS Organizations 組織内のすべてのアカウントに適用されます。例えば、`Production` キーでタグ付けされたノードに対して、`Intern` グループの自動承認を明示的に拒否できます。自動承認ポリシーと手動承認ポリシーは、作成元の AWS アカウントと AWS リージョンにのみ適用されます。組織内の各メンバーアカウントが、独自の承認ポリシーを管理します。承認ポリシーは次の順序で評価されます。 1. アクセス拒否 1. 自動承認 1. 手動 組織ごとに 1 つのアクセス拒否ポリシー、アカウントとリージョンごとに 1 つの自動承認ポリシーのみを持つことができますが、アカウントには複数の手動承認ポリシーがある可能性があります。手動承認ポリシーを評価する場合、ジャストインタイムノードアクセスでは、ノードのより具体的なポリシーが常に優先されます。手動承認ポリシーは次の順序で評価されます。 1. タグの具体的なターゲット 1. すべてのノードのターゲット 例えば、`Demo` キーでタグ付けされたノードがあるとします。同じアカウントに、すべてのノードをターゲットとする手動承認ポリシーがあり、1 つのレベルからの 1 つの承認が必要です。また、`Demo` キーでタグ付けされたノードには、2 つのレベルからの 2 つの承認を必要とする手動承認ポリシーもあります。Systems Manager は、`Demo` タグをターゲットとするポリシーをノードに適用します。このポリシーが、すべてのノードをターゲットとするポリシーよりも具体的であるためです。これにより、アカウント内のすべてのノードの一般的なポリシーを作成し、ユーザーがアクセスリクエストを送信できるようにしながら、必要に応じてより詳細なポリシーを作成できます。 組織によっては、ノードに複数のタグが適用される場合があります。このシナリオでは、ノードに複数の手動承認ポリシーが適用されると、アクセスリクエストは失敗します。例えば、ノードに `Production` および `Database` キーがタグ付けされているとします。同じアカウントに、`Production` キーでタグ付けされたノードに適用される手動承認ポリシーと、`Database` キーでタグ付けされたノードに適用される別の手動承認ポリシーがあります。その結果、両方のキーでタグ付けされたノードで競合が発生し、アクセスリクエストが失敗します。Systems Manager は、失敗したリクエストにユーザーをリダイレクトします。ここでは、競合しているポリシーとタグの詳細を表示して、必要なアクセス許可がある場合は必要な調整を行うことができます。そうでない場合は、ポリシーを変更するために必要なアクセス許可を持つ組織内の同僚に通知できます。アクセスリクエストの失敗につながるポリシーの競合は EventBridge イベントを出力するため、独自のレスポンスワークフローを柔軟に構築できます。さらに、Systems Manager はアクセスリクエストの失敗につながるポリシーの競合に関する E メール通知を指定された受信者に送信します。ポリシーの競合用の E メール通知の設定の詳細については、「[ジャストインタイムアクセスリクエストに関する通知を設定する](systems-manager-just-in-time-node-access-notifications.md)」を参照してください。 *アクセス拒否*ポリシーでは、Cedar ポリシー言語を使用して、ユーザーが組織内で明示的に自動的に接続できないノードを定義します。このポリシーは、組織の委任管理者アカウントから作成および共有されます。アクセス拒否ポリシーは、すべての自動承認ポリシーよりも優先されます。組織ごとに 1 つのアクセス拒否ポリシーのみを持つことができます。 *自動承認*ポリシーでは、Cedar ポリシー言語を使用して、手動承認なしで指定されたノードに自動的に接続できるユーザーを定義します。自動的に承認されるアクセスリクエストのアクセス期間は 1 時間です。この値は変更できません。アカウントとリージョンごとに 1 つの自動承認ポリシーのみを持つことができます。 *手動*承認ポリシーでは、アクセス期間、必要な承認レベル数、レベルごとに必要な承認者の数、ジャストインタイムアクセスリクエストを承認できるノードを指定します。手動承認ポリシーのアクセス期間は 1～336 時間である必要があります。複数の承認レベルを指定した場合、アクセスリクエストの承認では一度に 1 つずつレベルが処理されます。つまり、承認プロセスが後続のレベルに移行する前に、1 つのレベルに必要なすべての承認が提供される必要があります。手動承認ポリシーで複数のタグを指定した場合、`and` ステートメントではなく `or` ステートメントとして評価されます。例えば、タグ `Application`、`Web`、および `Test` を含む手動承認ポリシーを作成した場合、これらのキーのいずれかでタグ付けされたすべてのノードにポリシーが適用されます。3 つすべてのキーでタグ付けされたノードにのみポリシーが適用されるわけではありません。 手動ポリシーと自動承認ポリシーを組み合わせて使用して、より重要なデータがあるノードを保護しながら、重要度の低いノードにユーザーが介入なしで接続できるようにすることをお勧めします。例えば、データベースノードへのアクセスリクエストには手動承認を義務づけ、永続的でないプレゼンテーション層のノードへのセッションは自動承認します。 次の手順では、ジャストインタイムノードアクセス用の承認ポリシーを作成する方法について説明します。 **Topics** + [ジャストインタイムノードアクセス用の手動承認ポリシーを作成する](systems-manager-just-in-time-node-access-create-manual-policies.md) + [自動承認ポリシーとアクセス拒否ポリシーのステートメントの構造とビルトイン演算子](auto-approval-deny-access-policy-statement-structure.md) + [ジャストインタイムノードアクセスの自動承認ポリシーを作成する](systems-manager-just-in-time-node-access-create-auto-approval-policies.md) + [ジャストインタイムノードアクセス用のアクセス拒否ポリシーを作成する](systems-manager-just-in-time-node-access-create-deny-access-policies.md) + [Amazon Q を使用してジャストインタイムノードアクセスの承認ポリシーを作成する](systems-manager-just-in-time-node-access-create-approval-policies-q-ide-cli.md)