はじめに
今回は、第13回で紹介したAWS Systems Managerの新たなOrganizations連携であるジャストインタイムノードアクセス機能を紹介します。ジャストインタイムノードアクセスは、管理者が承認することによって、期間限定でEC2のノードへアクセスする権限を付与できる機能です。対象となる機能はSession ManagerとFleet Managerです。
Organizations連携をすることで、複数のAWSアカウントに対する承認に関するルールを一括で設定したり、各AWSアカウントでの承認リクエストを一元的に参照したりできます。
管理アカウントでの操作
本稿では、第13回で実施した委任管理者設定を完了している前提でセットアップ手順を紹介していきます。もし新規でセットアップをする場合は、AWSの公式手順を参照ください。まずは、管理アカウントでの操作を確認します。
（1）すでに委任管理者の設定が済んでいる状態で、管理アカウントにてSystems Managerのサイドメニューから「設定」メニューへアクセスすると下記のようにアップグレードが必要であるという旨のメッセージが表示されているはずです。「確認」ボタンをクリックします。
（2）少し待機すると、筆者の環境では以下のような画面が表示されました。
（3）この処理により、内部的にはQuickSetupの信頼されたアクセスが有効化されると考えられます。
（4）サイドメニューの「高速セットアップ」をクリックし、ページトップに表示されている「オンボーディングを完了」ボタンをクリックします。
（5）ページトップのNoticeが消えることを確認します。
（6）サイドメニューの「ジャストインタイムノードアクセス」をクリックし、下記のように委任管理者での操作が必要である旨のメッセージが表示されることを確認します。
ここまでの作業で、Systems Managerの操作に関する設定は完了します。しかし、ジャストインタイムノードアクセスのOrganizations連携機能の一つである、複数のAWSアカウントにまたがった拒否ポリシーを設定するためには、Resource Access Manager（RAM）の有効化が必要です。
（7）こちらのドキュメントに記載の通り、OrganizationsレベルでRAMを有効化する際には、下記コマンドを実行します。Cloudshellによる実行が最も容易かと思います。
aws ram enable-sharing-with-aws-organization以上で、管理者アカウントでの設定作業は完了です。
委任管理者アカウントでの操作
（1）委任管理者アカウントにログインし、Systems Managerのサイドメニューの「ジャストインタイムノードアクセス」をクリックし、新しい統合エクスペリエンスを有効にするため、「使用開始」ボタンをクリックします。
（2）ホームリージョンは、作業を行うリージョンが自動で設定されます。本手順では東京リージョンで作業しているため、東京リージョンが設定されています。それ以外の設定はデフォルトのままとし、「送信」ボタンをクリックします。
（3）セットアップが開始したことを確認します。
（4）セットアップが完了し、EC2インスタンスが存在すれば、何らかのグラフが表示されるはずです。
（5）サイドメニューの「ジャストインタイムノードアクセス」をクリックし、「ジャストインタイムノードアクセスを有効にする」ボタンをクリックします。
（6）ジャストインタイムノードアクセス機能を有効化する範囲をOU単位で指定できます。今回はUsers OU配下のAWSアカウントに対してジャストインタイムノードアクセス機能を有効化するとします。最後にページ末尾の「ジャストインタイムノードアクセスを有効にする」ボタンをクリックします。
（7）有効化処理が実行されていることを確認します。
なお、筆者の環境ではSCP (Service Control Policy) によって、利用できるリージョンを限定していたことから、以下のように処理失敗が発生しました。筆者と同様にリージョン制限をしている環境で、新たに利用可能なリージョンを追加したケースで、ジャストインタイムノードアクセス機能を有効化したい場合は、ジャストインタイムノードアクセス機能の有効化処理の再実行が必要です。
動作確認（Organizations配下の申請を一元的に参照）
それでは、ジャストインタイムノードアクセスの動作を確認していきます。まずは以下のようなAWSアカウント構成で、メンバーアカウントでのジャストインタイムノードアクセスの申請を委任管理者アカウントで確認してみます。
事前準備
（1）IAM Identity Centerで検証用の一般ユーザーと管理者ユーザーを作成しておきます。
一般ユーザーには、こちらのドキュメントで解説されている「IAM policy for just-in-time node access users」（ジャストインタイムアクセス申請を行うための最小限の権限セット。EC2インスタンスへの直接接続権限は含まず、アクセスリクエストの作成やステータス確認などが許可されるポリシー）を付与しておきます。
管理者ユーザーには、本稿では便宜上 AdministratorAccess ポリシーを付与しますが、より厳密な最小権限とする場合は、前述のページで解説されている「IAM policy for access request approvers」（ジャストインタイムアクセスの申請を承認または拒否するための権限セット。申請内容の閲覧や承認/拒否操作に必要な権限が含まれるポリシー）を付与するとよいでしょう。これらのIAMポリシーは、IAM Identity Centerのカスタム権限セットとして用意する必要がありますので、こちらのドキュメントを参考に作成してください。
メンバーアカウントでの操作
管理者ユーザーの操作
（1）まずは、メンバーアカウントで承認ルールを設定する必要があります。その操作は管理者ユーザーで行う必要があります。今回は、管理者ユーザーとしてIAM Identity Centerに存在する筆者のユーザーを例に説明します。管理者ユーザーである筆者のユーザーでメンバーアカウントにログインし、Systems Managerのページのサイドメニューから「ジャストインタイムノードアクセス」をクリックします。
（2）「承認ポリシー」タブを開き、「手動ポリシーを作成」ボタンをクリックします。
（3）何らかのポリシー名を入力し、アクセス期間として今回は1時間を設定します。また対象となるEC2はすべてとするため、ターゲットとして「すべてのノード」を選択します。
（4）「承認者を追加」ボタンをクリックすると、下記のようなダイアログが表示されますので、「使用を開始」ボタンをクリックします。
（5）今回はIAM Identity Centerに存在する筆者のユーザーを承認者として指定し、「割り当てる」ボタンをクリックします。
（6）以下のように、IAM Identity Centerのユーザーが承認者として追加されるので、「手動承認ポリシーを公開」をクリックします。
一般ユーザーの操作
（1）一般ユーザーでメンバーアカウントにログインし、EC2のページからSystems Managerのジャストインタイムノードアクセスの申請を行うEC2を選択し、「接続」ボタンをクリックします。なお、該当のEC2はSession Manager利用の前提を満たしている必要がありますので、事前にセットアップを行っておきます。
（2）セッションマネージャータブを開き、「接続」ボタンをクリックします。「IAM policy for just-in-time node access users」は非常に限定された権限のため、下記画像のように権限不足でエラーが発生します。ジャストインタイムノードアクセスの申請を行う分には問題はないのですが、実際の運用時に権限を追加する必要があるでしょう。
（3）以下のようなダイアログが表示されるので、何らかの理由を入力し、「Create access grant」ボタンをクリックします。
（4）以下のように申請が成功した旨のメッセージが表示されれば、申請は完了です。
委任管理者アカウントでの操作
（1）委任管理者アカウントに管理者ユーザーでログインし、Systems Managerのページのサイドメニューから「ジャストインタイムノードアクセス」をクリックすると、下記のように先ほどの申請を確認できます。
（2）リンクをクリックすると詳細も確認できます。
（3）本稿執筆時点において、委任管理者アカウントの「私へのリクエスト」にも、メンバーアカウントからの申請が表示される動作が確認されています。
（4）表示上は承認もしくは拒否の操作が可能に見えますが、実際に操作を進めようとするとエラーが発生します。
これは、ジャストインタイムノードアクセスの現在の仕様として、「リクエスターと同じアカウントおよびリージョン内のノードへのアクセス要求とセッション開始のみをサポート」しているためです。つまり、クロスアカウントでの承認・拒否は現状サポートされていません。
したがって、委任管理者アカウントからOrganizations配下のアカウントの申請を確認できるのは、あくまで参照機能にとどまります。実際の承認や拒否の操作は、申請が行われた各メンバーアカウント内で実施する必要があります。
このように、他アカウントの申請が「私へのリクエスト」に表示され、操作UIが表示される点は、将来的な機能拡張の準備段階であるか、あるいは現時点でのUI上の課題である可能性が考えられます。
メンバーアカウントでの操作
続いて、メンバーアカウントでの操作を紹介しましょう。初めに、管理者ユーザーの操作から見ていきます。
管理者ユーザーの操作
申請を承認するには、再びメンバーアカウントでの操作が必要になります。
（1）再びメンバーアカウントに管理者ユーザーでログインし、Systems Managerジャストインタイムノードアクセスのメニューを開きます。そしてアクセスリクエストタブ内の「私へのリクエスト」をクリックし、先ほどの申請が表示されていることを確認します。
（2）リクエストを選択し、「承認」ボタンをクリックします。
（3）何らかのコメントを入力して、「Approve」ボタンをクリックします。
（4）先ほどの委任管理者アカウントでの操作と違い、今度は無事に承認が成功します。
一般ユーザーの操作
（1）一般ユーザーの画面で「セッションを開始する」というボタンが表示されますので、そのボタンをクリックします。
（2）無事にセッションを開始することができました。
動作確認（Organizationsレベルでのアクセス拒否ポリシー）
それでは、続いてOrganizationsレベルでのアクセス拒否ポリシーの設定について動作確認します。アクセス拒否ポリシーは少し紛らわしい機能となっており、指定したノードへのアクセス要求の自動承認を防止するためのポリシーとなっています。自動承認ポリシーが設定されていなければアクセス拒否ポリシーは効果を持ちません。
本稿の動作確認では、下図に示す構成で検証します。まず、メンバーアカウントで自動承認ポリシーを設定し、IAM Identity Centerの「自動承認グループ」に所属する一般ユーザーのアクセスが自動承認される状態とします。その上で、委任管理者アカウントからOrganizationsレベルのアクセス拒否ポリシーを設定し、この一般ユーザーのアクセスが自動承認されず、手動承認プロセスに切り替わることを確認します。
メンバーアカウントでの操作
それでは、メンバーアカウントでの操作を紹介しましょう。初めに、管理者ユーザーの操作を確認します。
管理者ユーザーの操作
（1）まずは、動作確認の前提として、メンバーアカウントで自動承認ポリシーを作成します。メンバーアカウントに管理者ユーザでログインし、「ジャストインタイムノードアクセス」ページの「承認ポリシー」タブを表示し、「自動承認ポリシーを作成」ボタンをクリックします
（2）以下のように、Cedar言語（Cedar Policy Language:AWSが開発したポリシー記述のための専用言語で、人間が読みやすく検証可能な形でアクセス制御ルールを定義できる）を用いて、ジャストインタイムノードアクセスの自動承認ポリシーにおける条件を記述できます。いくつかサンプルステートメントが用意されています。今回はIAM Identity Centerで特定のグループに所属している場合に自動承認するポリシーを設定するため、「IAM アイデンティティセンターのグループメンバーシップ」を選択します。
（3）「エディタに挿入」ボタンをクリックすると、右ペインのポリシーステートメントにサンプルポリシーが挿入されます。
（4）IAM Identity Centerで確認できるグループIDを入力し、「自動承認ポリシーを公開」ボタンをクリックします。グループ名ではないのでご注意ください。
（5）以下のよう、自動承認ポリシーの作成が成功することを確認します。
一般ユーザーの操作
（1）続いてメンバーアカウントに一般ユーザーでログインし、先ほどと同様の手順でEC2インスタンスへのSession Manager接続を試みます。
（2）表示されたダイアログにて、「Create access grant」ボタンをクリックします。
（3）今度は管理者ユーザーの承認無しでセッションを開始できるはずです。
委任管理者アカウントでの操作
この前提のもとに委任管理者アカウントで組織レベルでのアクセス拒否ポリシーの作成をします。これにより、先ほどの自動承認ポリシーに一致するユーザでも手動承認プロセスを強制させることが可能です。
管理者ユーザーの操作
（1）委任管理者アカウントに管理者ユーザーでログインし、「ジャストインタイムノードアクセス」のページの「承認ポリシー」タブの「組織ポリシー」を表示します。ここで「アクセス拒否ポリシーを作成」ボタンをクリックします。
（2）本稿では、EC2に付与されているタグによるアクセス拒否を試します。「ノードのタグ」を選択します。
（3）「エディタに挿入」ボタンをクリックすると、右ペインのポリシーステートメントにサンプルポリシーが挿入されます。
（4）Environmentというタグで値がProductionのEC2に対する自動承認を禁止するように入力し、「アクセス拒否ポリシーを公開」ボタンをクリックします。
（5）以下のように、アクセス拒否ポリシーの作成が成功することを確認します。
メンバーアカウントでの操作
アクセス拒否ポリシーの設定が完了後に、再びメンバーアカウントでの操作を確認します。
一般ユーザーの操作
（1）メンバーアカウントに一般ユーザーでログインし、以前と同様の手順でEnvironmentキーの値がProductionであるタグを付与されているEC2インスタンスへのSession Manager接続を試みます。この際には前手順で選択したEC2インスタンスとは異なるEC2インスタンスを選択して動作確認をします。自動承認済みのEC2インスタンスは、1時間はアクセス拒否ポリシーのチェックがされない仕様であるため、本稿のステップで作業を進めていくと、アクセス拒否ポリシーの動作確認ができません。
（2）表示されたダイアログにて、「Create access grant」ボタンをクリックします。
（3）この申請は自動承認されずに、承認者による承認待ちの状態となることが確認できます。
課題となりやすいポイント
それでは、最後に課題となりやすいポイントについて説明します。
動作確認の箇所にも記載しましたが、本稿執筆時点ではOrganizations連携をしたジャストインタイムノードアクセス機能は仕様通りではないクロスアカウントでの承認/拒否が可能（そうに見える）という動作になっています。クロスアカウントでの承認/拒否はニーズのある機能だと思いますので、今後の実装が待たれます。
複数のメンバーアカウントにまたがって拒否ポリシーを一括設定する機能はありますが、承認ポリシーを一括設定する機能がないため、ジャストインタイムノードアクセスを利用する際に、各メンバーアカウントでの承認ポリシー作成が必要です。メンバーアカウント数が多くなれば、何らかの自動化の仕組みとセットで検討する必要があるでしょう。したがって、将来的にはAWS CloudFormationやAWS SDK/CLIを用いた自動化が期待されますが、本稿執筆時点では、AWS CloudFormationやAWS CLIによる承認ポリシーの直接的な作成・管理機能は公式ドキュメント等で確認できず、未サポートであると考えられます。ジャストインタイムノードアクセス機能への今後の対応が待たれます。
既存のIAMプリンシパル（IAMユーザーやIAMロールなど）に対してジャストインタイムノードアクセスを利用させる際、そのプリンシパルが直接 ssm:StartSession といったセッションマネージャーを利用可能な権限を有していると、ジャストインタイムノードアクセスによるアクセス制御がバイパスされてしまうため利用できません。そのため、ジャストインタイムノードアクセスベースでのアクセス制御を行う際には既存のIAMリソースからはセッションマネージャーに関する権限を削除することが推奨されます。
ポリシーの評価順序は、アクセス拒否ポリシー、自動承認ポリシー、手動承認ポリシーの順です。ただし、一度自動承認によってアクセスが許可された場合、そのセッション（または許可状態）が一定期間（自動承認の場合は1時間）継続し、その期間中に新たにアクセス拒否ポリシーが設定・適用されても、既存の許可状態には即時反映されない点に注意が必要です。新規のアクセスリクエストに対しては、常にアクセス拒否ポリシーから評価されます。
まとめ
今回は、AWS Systems Managerのジャストインタイムノードアクセス機能のOrganizations連携ステップと課題となりやすいポイントを詳しく紹介しました。本稿がOrganizations配下のAWSアカウントの運用管理のお役に立てば幸いです。
『モンハンワイルズ』100万以上同時接続の達成を支えたAWSの技術とは？
