第168回 雲勉 JITNAの使い方とハマったポイントについて語る回

下記、勉強会での資料です。
https://youtu.be/-Ixwh7QmodY

Transcript

1. 第168回 雲勉 JITNAの使い方とハマった ポイントについて語る回
2. 講師自己紹介 2 ▪ 名前 • 小西 紀代香（こにし きよか） • 2024年4月入社 • 初めての登壇です、よろしくお願いします！ • ご質問は YouTubeのコメント欄で受け付けております。 後日回答させていただきます！
3. アジェンダ 3 1. はじめに 2. ジャストインタイムノードアクセスとは？ 3. 実際に使ってみた 4. 使ってみての思わぬ落とし穴 5. まとめ
4. 1. はじめに 4
5. 5 1．はじめに 本動画の目的 • ジャストインタイムノード アクセス（以降JITNA）の概要を理解する • JITNAの実際の操作と注意点を振り返る 本動画の対象 • 業務でAWS Systems Manager（以降Systems Manager）をよく使用す る方 • AWSを使い始めて間もない方
6. 6 1．はじめに 注意書き • 本動画は初心者向けの内容になります • そのため、設定内容や説明内容は基本的かつ分かりやすさ重視になります • 実際の案件等で本動画の内容を利用する際は、最新の公式ドキュメント等 で内容を確認していただくよう、よろしくお願いいたします ※今回の参考資料：Systems Manager を使用したジャストインタイムのノード アクセス
7. 2. ジャストインタイムノードアクセスとは？ 7
8. 2．ジャストインタイムノードアクセスとは？ 8 皆さんは、「ジャストインタイムノードアクセス」という機能をご存知ですか？ • 2025年4月29日に公開されたサービス • Systems Managerの機能の一部 • Session Manager（以下SSM）へのアクセスを、一時的かつ承認なしでは行えないようにする機 能 • セッション履歴や操作履歴を残せる、きめ細やかなアクセス制御ができるなどのメリット • 機能を有効化した月の残り期間と、その翌月の 1 か月間分の無料トライアル期間あり（それ以降 は有料）
9. 9 2．ジャストインタイムノードアクセスとは？
10. 10 2．ジャストインタイムノードアクセスとは？ 通常のSSM接続との違い 項目 通常のSSM接続 JITNA アクセス方式 （使用し続ける限り）永続的な接続 一時的な接続 接続の開始方法 ユーザーがいつでも開始可能 承認フローを経て接続可能になる アクセス制御・セキュリティ • IAMロールのみでの接続制御 • リソースごとのアクセス制御が難しい • 一度付与された権限は削除するまで永続的 • 常時アクセスできることでリスクが残る • IAMロールに加えて、複数の承認者による接続 制御 • 承認ポリシーの組み合わせやタグの利用による きめ細やかなアクセス制御が可能 • アクセス終了と同時に権限を自動削除 • 必要時のみアクセス可能にすることでリスクを 最小化 ログの取得 基本的には、セッションログのみ記録 セッションログに加え、RDPセッションログやアクセ スリクエストの履歴も記録される 管理・運用負荷 毎回の承認やポリシー設定が不要なため比較的軽め 通常のSSM接続に比べると比較的重め ユースケース 検証環境や緊急でのアクセスが必要になる環境など コンプライアンスが求められる環境（本番環境・お客 様環境）や外部者がアクセスする環境
11. 3. 実際に使ってみた 11
12. 3．実際に使ってみた 12 • JITNAを利用するための前提条件 ◦ SSM Agentがインストールされていること ◦ SSM接続に必要なセキュリティグループの設定がされていること ▪ 443ポートのアウトバウンド接続 ▪ VPCエンドポイントの443ポートのインバウンド接続 ◦ インスタンスにAmazonSSMManagedInstanceCoreポリシーを含む権限が付与され ていること
13. 13 3．実際に使ってみた ▪ JITNA利用の大まかな手順 1. JITNAを有効化する 2. IAMロールを作成する 3. 承認ポリシーを作成する 4. アクセスリクエストを送信する 5. リクエストを承認する 6. 接続を開始する
14. 14 3．実際に使ってみた 1. JITNAを有効化する JITNAを有効化するためには、使用しているロールが以下の権限を持っていることが必要です • JITNAを有効にするIAMポリシー • JITNAを構成するためのIAMポリシー
15. 15 3．実際に使ってみた 2. IAMロールを作成する JITNAはアクセスリクエストの送信・承認ともにIAMロールを使用します • アクセスユーザーのIAMロール ◦ ジャストインタイムノードアクセスユーザー向けのIAMポリシー • 承認者ユーザーのIAMロール ◦ アクセスリクエスト承認者向けのIAMポリシー を作成して、JITNAを利用する（承認する）ユーザーが上記ロールを引き受けられる権限も 付与しておきましょう
16. 16 3．実際に使ってみた 3. 承認ポリシーを作成する JITNAの承認ポリシーは、以下の順番で評価されます 1. アクセス拒否ポリシー：指定したノードへのアクセス要求の自動承認を拒否する 2. 自動承認ポリシー：ユーザーが自動的に接続できるノードを定義する 3. 手動承認ポリシー：指定したノードへのアクセスに必要な手動承認の数とレベルを定義する また、手動承認ポリシーは適用対象ノードを全て、もしくは特定のタグがついたノードで選べます 複数のポリシーを設定した際の優先順位は 1. タグ付けされたノード 2. すべてのノード ex.)env=prodのタグがついたノードに対して必要な承認数が2のポリシーと、全てのノード対象に必要な承認数が1のポリシーがあ ったときは、env=prodのタグがついたノードに適用されるポリシーは「必要な承認数が2のポリシー」
17. 17 3．実際に使ってみた 3. 承認ポリシーを作成する 今回作成する承認ポリシー • 自動承認ポリシー ◦ key:Name value:konishi-linux2 のタグがついているインスタンス対象 • 手動承認ポリシー ◦ key:Name value:konishi-linux のタグがついているインスタンス対象 ◦ アクセス可能期間は24時間 ◦ アクセスに必要な承認は、レベル1の承認が1つ ◦ 承認は”konishi-jitna-approver-role”に承認をもらう
18. 18 3．実際に使ってみた 3. 承認ポリシーを作成する（自動承認ポリシー）
19. 19 3．実際に使ってみた 3. 承認ポリシーを作成する（手動承認ポリシー） アクセスに必要な承認は • レベル数（MAX5つ） • そのレベルで必要な承認数（MAX5つ） • 承認者を誰にするか で設定する
20. 20 3．実際に使ってみた 4. アクセスリクエストを送信する（自動承認の場合） 一度リクエストが承認されると、自動承認が有効な時間内（1時間）はリクエスト送信なしで接続可能
21. 21 3．実際に使ってみた 4. アクセスリクエストを送信する（手動承認の場合）
22. 22 3．実際に使ってみた 5. リクエストを承認する（手動承認の場合）
23. 23 3．実際に使ってみた 6. 接続を開始する
24. 4. 使ってみての思わぬ落とし穴 24
25. 25 4. 使ってみての思わぬ落とし穴 あれ！？アクセスリクエストが勝手に却下されている？！
26. 26 4. 使ってみての思わぬ落とし穴 アクセスリクエストを送信すると、拒否ポリシーは設定していないのに自動で拒否されてしまう
27. 27 4. 使ってみての思わぬ落とし穴 承認者側から、自動で却下されたリクエストを後から手動で承認することもできない
28. 28 4. 使ってみての思わぬ落とし穴 原因になりそうなこと • どこかで拒否ポリシーを設定している？ →Org全体で設定していないことを確認済み • IAMポリシーに問題はないか？ →ポリシー自体には問題ないことを確認済み • AWS OrganizationsのSCPでSSM関連の権限を制限していないか？ →制限は設定していないことを確認済み では、何が問題だったか？
29. 29 4. 使ってみての思わぬ落とし穴 原因：IAMユーザーを使ってアクセスリクエストを送ってしまっていた
30. 30 4. 使ってみての思わぬ落とし穴 落とし穴の原因： • セットアップ手順に、特に「ロールを使ってね」という指定がなかった（記載されていた かもしれないが見落とした） ◦ なお、承認者はロールを使う、というのは手動承認ポリシー設定で承認者をロールで指定する ため、「承認者はロールを使うんだな…」の認識はあった • IAMユーザーでコンソールログイン→アクセスリクエスト送信自体は問題なくできてしま った →原因究明に時間がかかってしまった 解決のきっかけ： 承認者がロールを使うなら、リクエストの送信もロールでやらないとダメじゃないか…？？ とふと思いつきました
31. 31 5. まとめ
32. 32 5. まとめ • JITNAは通常のSSM接続に比べて、よりセキュアかつ柔軟な運用が可能になるサービス ◦ インスタンスへのアクセスに承認が必要 ▪ 必要な承認レベルや承認者を選べる ▪ 対象インスタンスを選べる ◦ アクセスは一時的な許可で行われる • 通常のSSM接続に比べて、管理・運用の手間はかかるため、環境や利用者によって使い 分けるのがベター • 利用する際は、アクセスリクエストの送信者・リクエストの承認者それぞれのIAMロー ルを使用する
33. 33 ご清聴ありがとうございました