[IAMスペシャル！]Security-JAWS 第39回レポート #secjaws #secjaws39 #jawsug #secjaws39iamsp

こんにちは、臼田です。

Security JAWS 第39回が開催されましたのでレポートします。

[IAMスペシャル！]Security-JAWS【第39回】 勉強会 2025年11月08日(土) - connpass

動画

後ほど

レポート

LT1: 「最小権限」を「最小の手間」で実現したい。 もりやまさん Level200

• not authorizedというエラー見ませんか？
• 本番じゃないのでFull Accessつける？
• やめたいよね
• どうやったら最小権限を楽にできるか考えていく
• 条件、GitHub ActionsからSAMでデプロイするときを想定
• どうすれば権限を列挙できる？
• 3つのアプローチを検証
• 1. IAM Access Analyzer
• 2. Q Developer
• 3. バウンダリを使う
• 今回結果のみ
• 1. IAM Access Analyzerはシンプルに利用しているActionだけ列挙してくれたがリソースは自分で書く必要がある
• 2. セキュリティ対策をしっかりしてくれた
• 3. バウンダリだと全部許可して必要なところだけ絞っていく
• 所感:
  • Q Developerは自然言語で指示なので体感は楽
  • IAM Access Analyzerの自動ポリシー作成は追加対応が大変
  • 保守性はバウンダリがよい
  • ガードレールの記載はシンプルに記載できる
  • 構成変更はロールの経脳が必要
  • Q Develperは意図しない権限昇格も気にしてくれた
• まとめ
  • 最小権限とは何かを考えるいい機会になった
  • 最小限という言葉にとらわれずガードレール的に設定するのも必要

LT2: こんな時代だからこそ！想定しておきたいアクセスキー漏洩後のムーブ Japan Digital Design株式会社 Software Engineer Takuya Yonezawaさん Level200

• IAMセキュリティのベストプラクティスからIAMユーザーの利用が削除されました
• とはいえアクセスキーを使わざるを得ないワークロード・システムもあるのでは
• アクセスキーはどこから漏れるか？
  • うっかり公開リポジトリにPush
  • SSRFなどから漏洩
  • マルウェア感染やサプライチェーン経由の攻撃
• 端末のGenAI CLIを起動して端末の中のクレデンシャルを自動探索する攻撃がある
• どこにアクセスキーをお呼応が漏洩する可能性がある
• 漏洩後の動きを準備しておく必要がある
• アクセスキーが漏洩したらどうなるの？
  • 機密情報の漏洩
  • クラウド破産
• これらは最終的に表層化しているだけで裏で色々ある
• 攻撃者の気持ちになってみる
  • MITER ATT&CKなどを見ると良い
  • Persistence - 持続性
  • 攻撃者は長く居座りたい
  • アカウントに入れなければAWSサポートフォームから連絡できるので覚えておくと良い
  • せっかくアクセスキーを奪ったのにすぐにアクセスキーを無効化されたら困りますよね？(攻撃者視点)
  • いろんな継続アクセスの仕組みがある
• 止血処理
  • 異常に気づく仕組み・体制はあるか？
  • CloudTrail調査
  • 漏洩したアクセスキー無効化
  • IAMユーザー・ロール・アクセスキー確認
  • コンピュートリソース停止・削除
• まとめ
  • 攻撃者も色々準備しているので対応や調査のシミュレーションをしておこう

LT3: CloudTrailで追う IAMユーザーとIAM Identity Center ログインの違い 株式会社 Cloudii SEスペシャリスト 佐々木 健成さん Level200

• IAMユーザーのログイン時のシーケンス
  • パスワード等を入力したあとCheckMfaを入れる
  • パスワード入力時はパスワードが検証されていない
  • 最終的に評価されるようになる
• Identity Centerのログイン
  • アクセスポータルへ入るところで1イベント
  • コンソールアクセスでもう1イベント
  • ポータルに入る段階
    • CredentialVerificationイベントでパスワードとTOTP検証を個別にやる
    • 検証が問題なければUserAuthenticationイベントが記録されてログイン成功
  • ポータルアクセス時
    • 4つのイベントが同じタイミングで起こる
    • Trailログは秒単位なので順序は不明
    • Federate
    • AssumeRoleWithSAML
    • GetSigninToken
    • ConsoleLogin
• それぞれ仕組みが違って一部同じイベントもあるが、イベントを拾うのは考慮が必要

LT4: AWS外でもIAMロールを使おう！ 白"雪姫"さん Level200

• IAM Role
  • 一時的な認証情報を取得する
  • ただし外からIAM Roleを使おうとするとサーバーにキーを持ったりしないといけない
  • 永続的な認証情報の漏洩の懸念がある
• そこでIAM Role Anywhere
  • 簡単に説明するとAWS外からIAM Roleを引き受けるサービス
  • CAを構築して自前のサーバーで使う
• まとめ
  • 漏洩リスクは下げられた
  • 使いづらいところはいろいろある
  • 記事にまとめておきます

Session1: よくわからない人向けの IAM Identity Center とちょっとした落とし穴 JAWS-UG神戸 市野 和明（kazzpapa3）さん Level200

• 今回は39回(ミク)でキリが良いね
• IAM Identity Centerの適切な選定基準などを持ち帰ってもらえるかな
• Amazon QやQuickSightを使おうとしてIdentity Centerを設定するように書かれたこと無い？
• AppStream 2.0とかも必要だったね
• そもそもIAM Identity Centerって何？
  • ざっくりいうとアプリケーションやAWSアカウントへのユーザーアクセスを管理するサービス
  • SSOできる
• 2つのユーザーアクセスを管理
  • AWSアカウントアクセス
  • アプリケーションアクセス
    • AWSマネージド
    • カスタム
• いずれのユーザーアクセスでも
  • SSOしてそれぞれにアクセスできる
• 従来はAWS Organizationsが必須だった
  • 2023年11月にアカウントインスタンスが登場した
  • AWS Organizationsの利用有無に関係なく作成できるようになった
  • IAM Identity Centerと連携が可能なAWSマネージドアプリケーションを迅速に評価可能とする目的
  • これがわかりにくい
  • マネジメントコンソールではマルチアカウントのアクセス許可があるかどうかの違いだけ
  • 自分のアカウントインスタンスと組織のインスタンスが一応分けて出るようになった
• 違い
  • 権限セットをサポートしていない、AWSアカウントへのアクセスに使えない
  • アカウントインスタンスと組織インスタンスは統合できない
  • 本番利用するあら再作成が必要
• できることが違うのに見た目で分かりづらい
• 間違って設定する人も多い
• 設定によりどちらにもアクセスできなくなるケースもあった
• 情シス向け案内
  • 一応制御はできる
  • アカウントインスタンスの防止を押すと、サンプルのSCPが出る
  • 裏を返すと明示的にDenyされていないとアカウントインスタンスが作成される
  • 例えばQuickSightでは作成済みアカウントの認証方法を変更ができない
  • 場合により移行でダウンタイムが発生するなど気にしておく必要がある
• Amazon Q Develperでのサインイン
  • インターフェイスとTierのかけ合わせで使える使えないが存在する
  • FreeティアではBuilder IDしか実質選択しがない
  • Proティアならどちらもいける
  • 急にBuilder IDが出てきた
    • クレジットカードの登録がいらない個人のアカウント、のような解釈
  • この状態でProはどう使うか
  • ユーザーとBuilder IDとAWSアカウントがすべて1:1:1で関連付けされる
  • 組織で使う場合にはこの手法は許容しづらい
  • つまりIdentity Center推奨とされている
• Q Developerデプロイオプション
• Q Developerプロファイルの特性
  • IAM Idnetity Centerワークフォースユーザーでの利用が必要
  • つまりBuilder IDではだめ
  • 単純にProを使っているだけですべての機能が使えるわけではない
• Amazon QとIAM Identity Centerの関係だけでも考える要素が多い
  • 組み合わせによって何ができるできないが発生する
  • ちょっと検証するだけだから…というちょっとがどの程度になるか考えて使い始める必要がある
• IAM Identity Centerは1組織1つしか作れない
  • 東京リージョンに組織のインスタンスがあるとき、バージニアでしか使えないサービスがでたら？
  • 例えばOktaを外部に持って連携する方法もあるけど、それでもいいかは要確認

Session2: 「Bobはどことどこにアクセスできる？」IAM Identity Centerによる権限設定をグラフ構造で可視化＋グラフRAGへの挑戦 Japan Digital Design株式会社 Senior Solution Architect 木美 雄太さん Level300

• 想定するシチュエーション
  • 佐藤さんと田中さんと伊藤さんと野村さんはどことどことどこのアカウントにどんな権限があるかすぐに教えて
  • IAM Identity Centerはグラフである
• AWSにおけるユーザー権限管理の主戦場はもはやIAMユーザーではない
• 1つの背景としてはマルチアカウント利用が常識になっているところがある
  • 数十、数百のアカウントやユーザーを管理するのが当たり前になった
• AWSはIAM Identity Centerを出している
  • ユーザーアクセスを一元管理できる
  • 管理の困難から解放されたのか？
  • そうではない
• 多対多が前提の複雑な関係
  • ユーザーが複数のグループに所属可能
  • グループにはゆく数のユーザーが追加可能
  • アカウントや許可セットなどもそれぞれ複数紐づく
• マネジメントコンソールでの操作も親切になっているが…
  • Nユーザー x Mアカウント x L許可セットをぽちぽちして確認できる
  • これの証跡を出すのはつらいなあ
• でもマネジメントコンソールの問題ではなく、多対多だと表での表現は限度がある
• そこでグラフで表現しよう
  • ノードとエッジによる表現
  • 実際にグラフで見てみる
    • ユーザーカットで関連するグループ、アカウント、許可セットを出せる
  • マネジメントコンソールよりはわかりやすい
  • 人力でやっているわけではないのでヌケモレもない
• これは金融などの規制業界では多様な関係者に説明責任を果たすことが強く求められるので価値は大きい
• 異変がパッと目につくのもいいところ
  • 通常と違うとグラフの形が崩れるのでわかりやすい
• このツールはAWSが公開しているARIA-gvを使っている
• 使われているのはAmazon Neptune
  • Neptuneは2種類ある
  • 今回使っているのはNeptune Analytics
  • もう一つはオンライン書利用のNeptune Database
  • Analyticsは分析するときだけ起動できる
  • データはS3バケットに保存する
  • 全データをメモリ上に展開する
• グラフの可視化はGraph-explorerで可視化
  • AWSが公開しているOSS
  • GUIでゴリゴリ操作できる
• サンプル実装なので簡単に展開できる
• 生成AIも使ってみた
  • LLMにこのグラフDBを検索させたらうまく質問に答えられるのでは？
  • Graph-RAGをNotebook上で実装
    • Claudeにクエリ作ってもらってクエリ実行、内容をまたClaudeで回答
  • Q Developerも使って比較
    • 「ユーザー y-itoはどのAWSアカウントにどんな権限までアクセスできますか？ポリシーまで教えて下さい」
    • Graph-RAGでは10秒程度で正しい回答が得られた
    • Q Developerでは愚直にCLIを実行しまくっている
      • 回答は正しいが数分以上かかる
    • グラフ化されていればLLMよりも短い時間で回答できる
      • 規模に依存せずクエリは一回
• まとめ
  • IAM Identity Centerをグラフで捉えると人間もLLMも素早く正確にアクセス権限設定を把握できる
  • とはいえIdentityベースのポリシーだけでアクセスが決まるわけではないので注意

Session3: JAM風ゲームで楽しく学ぶ! AWS IAM・セキュリティ 株式会社デンソー 西川祐司さん Level200

• AWS JAM/GameDayは好きですか？
  • いっぱい手が上がるよ
• AWS JAMとは
  • ゲーム形式のワークショップ
  • チームメンバーと協力しながらAWSサンドボックス環境で課題にチャレンジ
  • ただ参加手段は限られている
  • 気軽に参加とは行かない
• AWS JAMを模したゲームを作ってみた
  • 2021年からやっている
  • 社内の技能五輪クラウド部門チームが内製した
  • 初期はAWS様のご協力で買い愛していた
• デモ環境が少しあるので現地参加の方は試せる模様
  • 通常の使い方とは違うのでお手柔らかに
• 問題一覧、課題、得点ボードなどJAMの機能があります
• IAMスペシャルなのでIAM系の問題があります
• 問題
  • 初心者向けのMFA設定問題
  • IAM Roleの権限付与
    • CLIで実行していく必要がある
    • ドキュメントを読みながら実行していく必要があるため学習効果がある
  • 一枚上手を行くハッカー
    • ログから動作を確認して対処をする問題
  • IAMによるプロジェクトの分離
    • ポリシーなどを活用して権限を強化していく
• コンテスト環境の構成
  • 運営用の環境と競技者用の環境がある
  • 運営側はFlaskでFlask + APIG + Lambda + Dynamoでサーバレス
• 仕組み
  • Dockerコンテナの並列処理でSAMデプロイ
  • 基本は1AWSアカウント1問題
  • コマンド一発で環境が作れる
  • 課題挑戦時はLambdaからログインURLを生成する
• 活用事例
  • 社内のコンテストを実施
    • 20チーム100名の参加
    • 初心者でも参加OK
    • JAM + 事前の勉強会
  • 部署内ミニコンテスト
    • 時間を短くして少人数で実施
    • 問題には実際のトラブルの対処を元にして作った
  • どのような規模でも実施できた
• JAMの魅力
  • 白熱して楽しい
    • 短期集中でネキがある、腕試しで意欲が向上する
  • 学習定着率・満足度の高さ
    • ラーニングピラミッドでもアクティブラーニングが重要
    • NPSも高い
• まとめ
  • JAMは作れる！
  • 自分たちで作ると自社事例を元にしたオリジナル問題を作れる
  • 運営自体もトレーニングになる

Session4: TerraformによるIAM Policy記述ガイド 株式会社スリーシェイク Sreake事業部 すずきまさしさん Level300

• TerraformでIAM Policyを書くときに複数の書き方がある
• どの書き方を選べばいいかの指針になればという話
• IAMやTerraformの基本的な話は省略
• IAM Policyの種類
  • AWS管理ポリシー
    • AWSが管理している
    • お手軽に使える
    • ざっくり権限なので最小権限には向いていない
  • カスタマー管理ポリシー
    • カスタマーが独自に作成したポリシー
    • 複数のRole/User/Groupに設定できる(共通化)
    • 最小権限を実現したいときに使う
  • インラインポリシー
    • IAM Role/User/GroupとPolicyが1:1で紐づく
    • 使いまわしができない
    • 使い回さないで最小権限をする時に使う
• カスタマー管理ポリシー vs インラインポリシー(一般論)
  • カスタマー管理ポリシーの優位点
    • 再利用可能性
    • 一元化した変更管理
    • バージョニングとロールバック
    • ポリシーの文字数制限
      • カスタマー管理ポリシーは6144文字まで
      • インラインポリシーは分割しても合算される
  • いうてそんなに使いまわしする？
  • IaC化していれば変更管理やバージョニングのメリットはなくなる
  • インラインポリシーを使うときが多い
• IAM Policyの定義方法
  • ヒアドキュメント
    • 直接JSONを記述する
    • コピペなら楽
    • ユースケース
      • 既存のPolicyを使いまわしたい時
  • jsonencode()
    • TerraformのobjectをJSON文字列に変換するカンスを利用する
    • HCLのobjectで定義
    • ValidなJSONにはなるがPolicyとして正しいかはわからない
    • 複雑なポリシーをロジックで作りたい時
    • 安全性を外しても記述の簡潔性を優先したい時
  • data.aws_iam_policy_document
    • HCLの構文で書く
    • JSONを意識しない
    • Dataのパラメータを指定する形式なのでポリシードキュメントのキー名などの間違いが起きない
    • 変数利用可能
    • 基本的には第1候補
    • Policyの数が少ないときに使う
    • いっぱいPolicyを書くときは冗長になる
  • file()
    • tfファイルの外でJSONを定義
    • ポリシー定義を外部化できるので見通しが良くなる
    • 固定値のみ
  • templatefile()
    • 外部のファイルで変数が利用可能
    • 扱うPolicyが多い時
• どれを使えばいいのか
  • 基本的にはdataを使う
  • 1つのStateで多くのPolicyを使うなら分けよう
• IAM PolicyとIAM Roleの紐づけ方法
  • 複数の紐づけ方
    • 管理ポリシー
      • aws_iam_roleの引数で定義(非推奨)
        • 書き方によっては循環参照が起きうる可能性がある
        • ここで紐づけると紐づいているポリシー以外がデタッチされてしまうので注意(排他制御)
        • 排他的制御にはexclusiveを使う
        • でも事故が起きるのでこれもおすすめしない
      • aws_iam_policy_attachment(取扱注意)
        • 排他的なアタッチメントを定義
        • これ以外の方法で設定した場合に紐づけが削除される
      • aws_iam_role_policy_attachment(推奨)
        • RoleとPolicyを1:1で紐づけるリソース
        • 既存の紐づけを維持している
    • インラインポリシー
      • aws_iam_roleの引数(非推奨)
      • aws_iam_role_policy(推奨)
        • インラインポリシーはこれ一択
• まとめ
  • 正直ケースバイケースではある
  • 最小権限が求められないならAWS管理ポリシーの利用もあり
  • ポリシー再利用が多い場面ではカスタマー管理ポリシーを使うのが望ましい
  • 選択できる引き出しを増やしましょう

Session5: CDKでIAMを管理する技術 - IaCでのIAM管理ベストプラクティスについて考える アクセンチュア株式会社　ソフトウェアエンジニア 村田亜弥（alichan）さん Level300

Session6: CDKにおけるPermissions Boundaryの適用と運用時の課題 ikenogamiさん Level300

Session7: EC2→S3で学ぶクロスアカウント権限設計の勘所 伊藤忠テクノソリューションズ株式会社 2025 Japan AWS Jr. Champions Hibikiさん Level300

Session8: 開発チームにIAM管理の権限委譲をしていく方法を考える ますのさん Level300

Session9: 1時間は短すぎる？許可セットのセッション時間で開発チームと見つけた着地点 CCoE 北川 卓図さん Level200

まとめ

今回もいろんな知見がありましたね！アンケートのレポートはもう少し待ってね★ミ