Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
第168回 雲勉 JITNAの使い方とハマったポイントについて語る回
Search
iret.kumoben
July 07, 2025
Technology
0
34
第168回 雲勉 JITNAの使い方とハマったポイントについて語る回
下記、勉強会での資料です。
https://youtu.be/-Ixwh7QmodY
iret.kumoben
July 07, 2025
Tweet
Share
More Decks by iret.kumoben
See All by iret.kumoben
第169回 雲勉 AWS WAF 構築 RTA
iret
0
11
第167回 雲勉 エージェント開発を加速する Agent Development Kit 入門
iret
1
38
第166回 雲勉 コードを読んで理解する AWS Amplify Gen2 Backend
iret
0
37
第165回 雲勉 Google Agentspace について
iret
0
31
第164回 雲勉 Agent Development Kit と MCP Toolbox for Databases で MCP 連携してみた
iret
1
67
第163回 雲勉 CircleCIで複数リポジトリ間のパイプラインを連携する
iret
1
35
第162回 雲勉 比較して学ぶ AWS Amplify Gen 2
iret
0
49
第161回 雲勉 Amazon Kinesis Data Streams と Amazon Data Firehose を使ってみよう
iret
0
50
第160回 雲勉 それ、AWS Step Functions で置き換えれん?
iret
0
87
Other Decks in Technology
See All in Technology
QuickBooks®️ Customer®️ USA Contact Numbers: Complete 2025 Support Guide
qbsupportinfo
0
110
Shadow DOM & Security - Exploring the boundary between light and shadow
masatokinugawa
0
670
メモ整理が苦手な者による頑張らないObsidian活用術
optim
0
130
BEYOND THE RAG🚀 ~とりあえずRAG?を超えていけ! 本当に使えるAIエージェント&生成AIプロダクトを目指して~ / BEYOND-THE-RAG-Toward Practical-GenerativeAI-Products-AOAI-DevDay-2025
jnymyk
4
240
会社もクラウドも違うけど 通じたコスト削減テクニック/Cost optimization strategies effective regardless of company or cloud provider
aeonpeople
2
170
AI時代にも変わらぬ価値を発揮したい: インフラ・クラウドを切り口にユーザー価値と非機能要件に向き合ってエンジニアとしての地力を培う
netmarkjp
0
220
OTel 公式ドキュメント翻訳 PJ から始めるコミュニティ活動/Community activities starting with the OTel official document translation project
msksgm
0
260
増え続ける脆弱性に立ち向かう: 事前対策と優先度づけによる 持続可能な脆弱性管理 / Confronting the Rise of Vulnerabilities: Sustainable Management Through Proactive Measures and Prioritization
nttcom
1
180
Expertise as a Service via MCP
yodakeisuke
1
150
(HackFes)米国国防総省のDevSecOpsライフサイクルをAWSのセキュリティサービスとOSSで実現
syoshie
5
660
AWS表彰プログラムとキャリアについて
naoki_0531
0
100
QAを早期に巻き込む”って どうやるの? モヤモヤから抜け出す実践知
moritamasami
2
180
Featured
See All Featured
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
BBQ
matthewcrist
89
9.7k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Why Our Code Smells
bkeepers
PRO
337
57k
The Invisible Side of Design
smashingmag
301
51k
Into the Great Unknown - MozCon
thekraken
40
1.9k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
How STYLIGHT went responsive
nonsquared
100
5.6k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
282
13k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
How to Think Like a Performance Engineer
csswizardry
25
1.8k
Transcript
第168回 雲勉 JITNAの使い方とハマった ポイントについて語る回
講師自己紹介 2 ▪ 名前 • 小西 紀代香(こにし きよか) • 2024年4月入社
• 初めての登壇です、よろしくお願いします! • ご質問は YouTubeのコメント欄で受け付けております。 後日回答させていただきます!
アジェンダ 3 1. はじめに 2. ジャストインタイムノードアクセスとは? 3. 実際に使ってみた 4. 使ってみての思わぬ落とし穴
5. まとめ
1. はじめに 4
5 1.はじめに 本動画の目的 • ジャストインタイムノード アクセス(以降JITNA)の概要を理解する • JITNAの実際の操作と注意点を振り返る 本動画の対象 •
業務でAWS Systems Manager(以降Systems Manager)をよく使用す る方 • AWSを使い始めて間もない方
6 1.はじめに 注意書き • 本動画は初心者向けの内容になります • そのため、設定内容や説明内容は基本的かつ分かりやすさ重視になります • 実際の案件等で本動画の内容を利用する際は、最新の公式ドキュメント等 で内容を確認していただくよう、よろしくお願いいたします
※今回の参考資料:Systems Manager を使用したジャストインタイムのノード アクセス
2. ジャストインタイムノードアクセスとは? 7
2.ジャストインタイムノードアクセスとは? 8 皆さんは、「ジャストインタイムノードアクセス」という機能をご存知ですか? • 2025年4月29日に公開されたサービス • Systems Managerの機能の一部 • Session
Manager(以下SSM)へのアクセスを、一時的かつ承認なしでは行えないようにする機 能 • セッション履歴や操作履歴を残せる、きめ細やかなアクセス制御ができるなどのメリット • 機能を有効化した月の残り期間と、その翌月の 1 か月間分の無料トライアル期間あり(それ以降 は有料)
9 2.ジャストインタイムノードアクセスとは?
10 2.ジャストインタイムノードアクセスとは? 通常のSSM接続との違い 項目 通常のSSM接続 JITNA アクセス方式 (使用し続ける限り)永続的な接続 一時的な接続 接続の開始方法
ユーザーがいつでも開始可能 承認フローを経て接続可能になる アクセス制御・セキュリティ • IAMロールのみでの接続制御 • リソースごとのアクセス制御が難しい • 一度付与された権限は削除するまで永続的 • 常時アクセスできることでリスクが残る • IAMロールに加えて、複数の承認者による接続 制御 • 承認ポリシーの組み合わせやタグの利用による きめ細やかなアクセス制御が可能 • アクセス終了と同時に権限を自動削除 • 必要時のみアクセス可能にすることでリスクを 最小化 ログの取得 基本的には、セッションログのみ記録 セッションログに加え、RDPセッションログやアクセ スリクエストの履歴も記録される 管理・運用負荷 毎回の承認やポリシー設定が不要なため比較的軽め 通常のSSM接続に比べると比較的重め ユースケース 検証環境や緊急でのアクセスが必要になる環境など コンプライアンスが求められる環境(本番環境・お客 様環境)や外部者がアクセスする環境
3. 実際に使ってみた 11
3.実際に使ってみた 12 • JITNAを利用するための前提条件 ◦ SSM Agentがインストールされていること ◦ SSM接続に必要なセキュリティグループの設定がされていること ▪
443ポートのアウトバウンド接続 ▪ VPCエンドポイントの443ポートのインバウンド接続 ◦ インスタンスにAmazonSSMManagedInstanceCoreポリシーを含む権限が付与され ていること
13 3.実際に使ってみた ▪ JITNA利用の大まかな手順 1. JITNAを有効化する 2. IAMロールを作成する 3. 承認ポリシーを作成する
4. アクセスリクエストを送信する 5. リクエストを承認する 6. 接続を開始する
14 3.実際に使ってみた 1. JITNAを有効化する JITNAを有効化するためには、使用しているロールが以下の権限を持っていることが必要です • JITNAを有効にするIAMポリシー • JITNAを構成するためのIAMポリシー
15 3.実際に使ってみた 2. IAMロールを作成する JITNAはアクセスリクエストの送信・承認ともにIAMロールを使用します • アクセスユーザーのIAMロール ◦ ジャストインタイムノードアクセスユーザー向けのIAMポリシー •
承認者ユーザーのIAMロール ◦ アクセスリクエスト承認者向けのIAMポリシー を作成して、JITNAを利用する(承認する)ユーザーが上記ロールを引き受けられる権限も 付与しておきましょう
16 3.実際に使ってみた 3. 承認ポリシーを作成する JITNAの承認ポリシーは、以下の順番で評価されます 1. アクセス拒否ポリシー:指定したノードへのアクセス要求の自動承認を拒否する 2. 自動承認ポリシー:ユーザーが自動的に接続できるノードを定義する 3.
手動承認ポリシー:指定したノードへのアクセスに必要な手動承認の数とレベルを定義する また、手動承認ポリシーは適用対象ノードを全て、もしくは特定のタグがついたノードで選べます 複数のポリシーを設定した際の優先順位は 1. タグ付けされたノード 2. すべてのノード ex.)env=prodのタグがついたノードに対して必要な承認数が2のポリシーと、全てのノード対象に必要な承認数が1のポリシーがあ ったときは、env=prodのタグがついたノードに適用されるポリシーは「必要な承認数が2のポリシー」
17 3.実際に使ってみた 3. 承認ポリシーを作成する 今回作成する承認ポリシー • 自動承認ポリシー ◦ key:Name value:konishi-linux2
のタグがついているインスタンス対象 • 手動承認ポリシー ◦ key:Name value:konishi-linux のタグがついているインスタンス対象 ◦ アクセス可能期間は24時間 ◦ アクセスに必要な承認は、レベル1の承認が1つ ◦ 承認は”konishi-jitna-approver-role”に承認をもらう
18 3.実際に使ってみた 3. 承認ポリシーを作成する(自動承認ポリシー)
19 3.実際に使ってみた 3. 承認ポリシーを作成する(手動承認ポリシー) アクセスに必要な承認は • レベル数(MAX5つ) • そのレベルで必要な承認数(MAX5つ) •
承認者を誰にするか で設定する
20 3.実際に使ってみた 4. アクセスリクエストを送信する(自動承認の場合) 一度リクエストが承認されると、自動承認が有効な時間内(1時間)はリクエスト送信なしで接続可能
21 3.実際に使ってみた 4. アクセスリクエストを送信する(手動承認の場合)
22 3.実際に使ってみた 5. リクエストを承認する(手動承認の場合)
23 3.実際に使ってみた 6. 接続を開始する
4. 使ってみての思わぬ落とし穴 24
25 4. 使ってみての思わぬ落とし穴 あれ!?アクセスリクエストが勝手に却下されている?!
26 4. 使ってみての思わぬ落とし穴 アクセスリクエストを送信すると、拒否ポリシーは設定していないのに自動で拒否されてしまう
27 4. 使ってみての思わぬ落とし穴 承認者側から、自動で却下されたリクエストを後から手動で承認することもできない
28 4. 使ってみての思わぬ落とし穴 原因になりそうなこと • どこかで拒否ポリシーを設定している? →Org全体で設定していないことを確認済み • IAMポリシーに問題はないか? →ポリシー自体には問題ないことを確認済み
• AWS OrganizationsのSCPでSSM関連の権限を制限していないか? →制限は設定していないことを確認済み では、何が問題だったか?
29 4. 使ってみての思わぬ落とし穴 原因:IAMユーザーを使ってアクセスリクエストを送ってしまっていた
30 4. 使ってみての思わぬ落とし穴 落とし穴の原因: • セットアップ手順に、特に「ロールを使ってね」という指定がなかった(記載されていた かもしれないが見落とした) ◦ なお、承認者はロールを使う、というのは手動承認ポリシー設定で承認者をロールで指定する ため、「承認者はロールを使うんだな…」の認識はあった
• IAMユーザーでコンソールログイン→アクセスリクエスト送信自体は問題なくできてしま った →原因究明に時間がかかってしまった 解決のきっかけ: 承認者がロールを使うなら、リクエストの送信もロールでやらないとダメじゃないか…?? とふと思いつきました
31 5. まとめ
32 5. まとめ • JITNAは通常のSSM接続に比べて、よりセキュアかつ柔軟な運用が可能になるサービス ◦ インスタンスへのアクセスに承認が必要 ▪ 必要な承認レベルや承認者を選べる ▪
対象インスタンスを選べる ◦ アクセスは一時的な許可で行われる • 通常のSSM接続に比べて、管理・運用の手間はかかるため、環境や利用者によって使い 分けるのがベター • 利用する際は、アクセスリクエストの送信者・リクエストの承認者それぞれのIAMロー ルを使用する
33 ご清聴ありがとうございました