![[IAMスペシャル！]Security-JAWS 第39回レポート #secjaws #secjaws39 #jawsug #secjaws39iamsp](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-f890958eb561d5bd7db7da1a250388ae/991bed17eecdc11214e20f27978b5553/jaws-ug-logo-1200x630.png?w=3840&fm=webp){kind=logo}
[IAMスペシャル！]Security-JAWS 第39回レポート #secjaws #secjaws39 #jawsug #secjaws39iamsp
Security-JAWS 第39回のレポートです。IAM祭り！
2025.11.08
こんにちは、臼田です。
Security JAWS 第39回が開催されましたのでレポートします。
[IAMスペシャル！]Security-JAWS【第39回】 勉強会 2025年11月08日(土) - connpass
動画
レポート
LT1: 「最小権限」を「最小の手間」で実現したい。 もりやまさん Level200
- not authorizedというエラー見ませんか？
- 本番じゃないのでFull Accessつける？
- やめたいよね
- どうやったら最小権限を楽にできるか考えていく
- 条件、GitHub ActionsからSAMでデプロイするときを想定
- どうすれば権限を列挙できる？
- 3つのアプローチを検証
-
- IAM Access Analyzer
-
- Q Developer
-
- バウンダリを使う
- 今回結果のみ
-
- IAM Access Analyzerはシンプルに利用しているActionだけ列挙してくれたがリソースは自分で書く必要がある
-
- セキュリティ対策をしっかりしてくれた
-
- バウンダリだと全部許可して必要なところだけ絞っていく
- 所感:
- 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で紐づく
- 使いまわしができない
- 使い回さないで最小権限をする時に使う
- AWS管理ポリシー
- カスタマー管理ポリシー 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の引数(非推奨)
- aws_iam_role_policy(推奨)
- インラインポリシーはこれ一択
- 管理ポリシー
- 複数の紐づけ方
- まとめ
- 正直ケースバイケースではある
- 最小権限が求められないならAWS管理ポリシーの利用もあり
- ポリシー再利用が多い場面ではカスタマー管理ポリシーを使うのが望ましい
- 選択できる引き出しを増やしましょう
Session5: CDKでIAMを管理する技術 - IaCでのIAM管理ベストプラクティスについて考える アクセンチュア株式会社 ソフトウェアエンジニア 村田亜弥（alichan）さん Level300
- AWSでIaC管理でCDKがつかえる
- 複数のプログラミング言語や周辺のライブラリが利用できる多様性
- L1-L3までの抽象度を選択できる
- cdk-nagなどのライブラリが利用できる
- なぜCDKでIAM管理が必要なのか
- S31つでも関連するIAMについて考える
- 他のリソースでも色々考える
- ユーザーやロール以外にもIdentity CenterやAWS Organizationsで構成する場合には許可セット、OU、SCP、RCPなども必要
- 考察観点
- どこまでIaCするのか
- ディレクトリ構成は
- OSS使う
- ヘルパーメソッド
- パラメーターシートの必要性
- 現実的にどこまでIaC管理を行えるか
- プロジェクトのライフサイクルを考える
- 関係者が多いとIAMリソースも大量
- プロジェクトに入ったり出たりするとIAMリソースのライフサイクルが短くなったりする
- 他のサービスとも連携してデプロイ頻度が変わる
- 意図せず再デプロイされる懸念もある
- 対処と目指すべき方向性
- 更新の手が回らないことに対してCDKを使用できる人員を増やして習熟度を向上させる
- デプロイ頻度の意図しない向上がされないようにスタック設計を適切に行なってプロジェクト構造が変更されないようにする
- いずれも必要なのは組織のトップダウンの力
- 安全かつ便利に使用するためのCDKディレクトリ構成/クラス構成
- 基本的にスタックは分けない
- 分けることで依存関係が発生しデプロイ順序が複雑になっていまう可能性があるから
- IAMが頻繁に更新される前提のスタック構成を考える
- SSMパラメータストアによる依存関係の無いデプロイ
- IAMだけ別スタックにする手法
- OSSによる脆弱性の発見と対策
- cdk-nagで対策する
- 6つのルール群に対応して実装も簡単
- Appに追加して使える
- IAM周りについてはポリシーの許可制限やIAMリソースの階層構造への指摘が多い
- 全部は適用する必要ない
- 重複も多いので調整が必要
- 監査で使うかなども考慮する
- cdk-nagで対策する
- ヘルパーメソッドでのポリシー生成自動化とカスタマイズ
- grantメソッドで権限付与ができる
- grantRead/grantReadWrite
- 比較的わかりやすいが詳細な権限がどうなるかを気にする
- API Gateway/Lambda/DynamoDBそれぞれにもgrantがいろいろある
- ECSはrunも含まれる
- EC2/ECSはアクセス権限制御だけに留まる
- リソースベースポリシーを保つ場合には直接自分でポリシーを書いていく必要がある
- grantRead/grantReadWrite
- grantメソッドで権限付与ができる
- まとめ
- まずは組織のトップダウンの力でIAM運用に合わせたStack設計、CDK教育が必要
- 依存関係のないデプロイが必要
- OSSを使った脆弱性対応をする
- grantの使い方は気をつける
- どのIaCでも考え方は転用できる
Session6: CDKにおけるPermissions Boundaryの適用と運用時の課題 ikenogamiさん Level300
- 本日のキーワード
- CDK
- プログラミング言語でAWSリソースを定義
- CloudFormationで展開
- Permissions Boundary
- 権限の境界
- 直接権限を付与せず、権限の最大範囲を設定できる
- CDK
- IAMエンティティに境界を設ける方法
- SCPとPermissions Boundaryがある
- SCPはアカウントに適用
- Permissions BoundaryはIAMエンティティに適用
- 利用した背景
- ゲートキーパーとガードレールの考え方
- ゲートキーパーは境界防御、事前承認、一元管理
- ガードレールははみ出してはいけない境界を定める
- ゲートキーパーでは開発スピードを阻害してボトルネックになりやすい
- どちらが一方だけではなくうまく併用するイメージ
- IAMの変更権限を誰が持つか
- 管理者がすべてのIAMを管理するか、開発者がすべてのIAMを管理するか
- 管理者がアプリ開発に必要な権限だけ開発者に渡すのをPermissions Boundaryを利用するとよい
- CDKに関連するロール
- CDKが使うロール
- 5つがBootstrapにて作成される
- CDK利用者が作るロール
- 例えばLambdaに付与するロールなどを作る
- CDKが暗黙的に作るロール
- S3バケットを作るときにautoDeleteObjectsをtrueにするとカスタムリソース用Roleが作られる
- 利用者はtrueにしただけだがRoleが作られる
- CDKが使うロール
- CDKにPermissions Boundary適用方法
- CDKが使うロールはBootstrapオプションかテンプレートで指定する
- オプションではCloudFormationExecutionロールにBoundaryが適用される
- 最も強い権限が必要になる
- テンプレートカスタマイズの場合は5つすべてを調整できる
- オプションではCloudFormationExecutionロールにBoundaryが適用される
- CDK利用者が作るロール
- 個別指定と全体指定ができる
- Roleを2個作る場合はそれぞれ指定
- グローバルに指定する場合、暗黙的に作るロールには適用されない
- どうやるか？
- Aspectsを使うと暗黙的に作るロールにも使える
- Aspectsはすべてのリソースに操作できる
- 例外
- crossRegionReference
- Lambdaのカスタムリソース用Role
- Issueに上がっていて未解決
- コメントにある回避策はうまくいった
- シンプルにやっていく場合cdk.jsonで書いていく
- CDKが使うロールはBootstrapオプションかテンプレートで指定する
- Permissions Boundaryの実装
- やりたかったこと
- 開発者が必要なものだけ許可
- 最初はブラックリスト方式でやってみた
- 最大限許可したうえで最初源の拒否をリストアップ
- すべてを許可しつつPermissions Boundary無しのRole作成を拒否
- ブラックリスト方式の問題点
- PassRoleアクションは条件キーで指定できない
- AWSサービスにロールを渡すことができる権限
- PassRoleだけでは何もできない(API呼び出しできない)
- どうPassRoleを制限するか
- 新規と既存のアプリによって使い分けする
- 新規ならRoleへのパス適用
- Resourceにパスを入れてあげる
- 開発者が作ったロールのみ制限をかけるができる
- ハイブリッド方式に移行した
- IAM以外は許可
- やりたかったこと
- ベストプラクティス
- AWSアカウントという境界
- AWSアカウント内は自由
- SCPでアカウントの外から制限
- この方式とPermissions Boundaryの使い分けが大事
- まとめ
- CDKでPermissions Boundaryを使った経験を共有した
- いっぱい壁にぶつかった
- 最善策はわからず
Session7: EC2→S3で学ぶクロスアカウント権限設計の勘所 伊藤忠テクノソリューションズ株式会社 2025 Japan AWS Jr. Champions Hibikiさん Level300
- 本日のテーマとゴール
- クロスアカウントの権限設計自信を持ってできますか？
- システムを大きくしていくとアカウントを分けたりしていく必要がある
- マルチアカウントは便利だがクロスアカウントの接続が必要になる
- クロスアカウントの権限設計自信を持ってできますか？
- クロスアカウント接続での困りごと
- 挙動がわからない
- どうアクセス制御すればいいかわからない
- EC2 -> S3というシンプルな構成でクロスアカウントでの権限の勘所を押さえる
- 話すこと
- IAMポリシの種類と仕組み
- クロスアカウントパターン
- 本日の構成
- システムアカウントのEC2からログアカウントのS3にアップロードする
- 検討すること
- ネットワーク接続経路
- 権限設計
- 今回はIAMを中心にNWはサクッと
- ネットワークの接続経路パターン
- Gateway型VPCエンドポイント
- システムアカウントにGateway型VPCエンドポイントを作成
- TGW&Interface型VPCエンドポイント
- ネットワークを集約するタイプ
- Internet Gateway経由
- 正直非推奨
- NATゲートウェイなども必要
- どのパターンで構築しても権限設計には影響なし
- 別のレイヤー
- Gateway型VPCエンドポイント
- ポリシーの種類と使い方
- そもそも同一アカウント内アクセスの場合どんなポリシーを付与すればよいか
- EC2のIAMロールにS3の権限を追加
- クロスアカウントの場合これだけではダメ
- ポリシーの種類
- アイデンティティポリシー、リソースベースポリシー
- 他もあり7種類
- アイデンティティベースポリシーはロール、ユーザー、グループに付与
- 何をしてよいか
- リソースベースポリシー
- 誰からのアクセスを許可・拒否するか
- S3のバケットポリシーやIAMロールの信頼ポリシー
- 両方揃えばアクセス可能(ざっくりいうと)
- そもそも同一アカウント内アクセスの場合どんなポリシーを付与すればよいか
- 実は同一アカウントでも両方必要
- ただしバケットポリシー未設定の場合お、同一アカウントからのアクセスが可能
- クロスアカウントの設計
- バケットポリシーの修正
- バケットポリシーでEC2のIAM Role(ARN指定)からのアクセスを許可してあげる
- Tips: IAMポリシーでConditionで特定のAWSアカウントに制限可能
- AssumeRole
- ログアカウント内にIAMロールを作成してAssumeRoleする
- システムアカウントではAssumeRoleの実行権限をつける
- ログアカウントにS3へのアクセスを許可する
- ログアカウントIAMロール用信頼ポリシーをつける
- S3からは同一アカウントからのアクセスなのでバケットポリシーの修正は不要
- Tips: AssumeRoleはロールを借りること
- アクセスキー
- 非推奨
- ログアカウントにS3アクセスを許可したIAMユーザーを作成
- EC2からアクセスキーを使う
- バケットポリシーの修正
- まとめ
- クロスアカウントでのアクセスは疎通性や権限に注意
- どのアカウントの権限を利用しているのかを意識すると設計しやすい
- 実際にはSCPとかもあるので奥が深い
Session8: 開発チームにIAM管理の権限委譲をしていく方法を考える ますのさん Level300
- 開発者チームにIAM管理を権限移譲するまでのステップ
- IAM Identity Centerでのユーザー管理
- Permissions Boundaryによるガードレール設定
- 属性ベースアクセス制御を利用したタグのアクセス制御
- 2019年ぐらいの苦い思い出
- ユーザー企業の情シスとしてIAM管理を行う
- 開発者からECS使っていきたいから権限ください
- 調べるが最小権限は無理
- お互い仕事が回ってないから今回はAdminを渡して進めようとなった
- 最小権限でのIAM運用は理想だが開発速度が落ちる
- IAM管理の権限移譲実現までの道のり
- AWS管理者
- いろいろセットアップする
- DevAdmin
- 自チームのロールとポリシーを作成
- 自チームのTagリソースのみフル権限
- DevMember
- 自チームのTagリソースのみフルアクセス
- 構成概要
- 許可セットで開発者が使う権限をまとめて付与
- Permissions Boundaryの付与を必須として作る
- 別チームのTagがついているとさわれなくなる
- コンセプト
- AWS管理者はざっくり開発者にアクセス権限を付与する
- 設定する
- IAM Identity Centerを有効にする
- リージョナルサービスなので使いたいリージョンなのか確認する
- 今回は外部IdP無しの前提
- アクセスコントロールの属性にABACのタグを設定していく
- 属性はIdPからも取得できるので外部IdP連携の場合にはそちらからも取ってこれる
- IAM Identity Centerを有効にする
- ポリシーを作る
- 詳細はGitHubに上がってます
- DevAdminのIAM設定を許可しつつ、Boundaryがついていないと拒否するようにする
- IAM ABAC Policyではタグが一致する場合IAMを作れるようにする
- 判定方法
- aws:RequestTag:これからつけようとしているタグ
- aws:PrincipalTag: 操作をしているユーザーのタグ
- awsResourceTag: 既存リソースに設定されているタグ
- Resource ABAC Policy開発者用
- IAM以外の操作ができる
- タグが一致する場合操作できる
- 触って良いサービスを列挙しても良い
- DevTeam Boundary Policy
- 最終防衛ライン
- Permission Boundaryは拒否ではなく許可を設定する
- 詳細は魔法のPermissions Boundary
- あとは資料を見てね
- まとめ
- 難易度は高いが管理者と開発者が幸せになる道を歩みたい
Session9: 1時間は短すぎる？許可セットのセッション時間で開発チームと見つけた着地点 CCoE 北川 卓図さん Level200
- 話すこと
- どのようにセッション時間を決めたかのストーリー
- 開発チームと運用ルールを決めたプロセス
- 事業会社ならではのコミュニケーション
- セキュリティと運用効率性ってトレードオフですよね
- 許可セットのセッション時間どれくらいにしていますか？
- セッション時間とは
- Identity Centerのセッション時間設定
- セッション時間が切れると再ログインしないといけない
- セッション時間とは
- どう決めていったか
- ステークホルダー
- CCoE
- 開発チームA
- 超重要システム
- この先にエンドユーザーがいる
- 開発チームB
- ユーザーは社内ユーザー
- 導入
- 公式ドキュメントでは
- セキュリティのベストプラクティスとしてロールを実行するために必要な長さを超えるセッション期間を設計する
- 具体的に何時間だ？
- AWSで実際にログインしてやる作業の例
- 短時間・中時間・長時間それぞれある
- 長時間はログの調査とか
- なかなか難しい
- とりあえずデフォルトでやってみることにした
- 網羅的な設計は難しそう
- デフォルトの1時間にした
- 1時間ならセキュリティリスクはないだろうという感覚
- スケジュール的にも検討に時間をかけていなかった
- 公式ドキュメントでは
- 衝突
- とある日
- 障害が発生したんですが1時間でセッションが切れると困る！なんとかしてほしい
- ヒアリング
- 具体的にはどんな作業でセッション切れになりますか？
- CloudWatch Logsのクエリ実行
- Session Manager接続の確認
- 攻撃を受けたときは一刻も早く解決が必要
- ReadOnlyポリシーのセッション時間を伸ばすことで解決になるか？
- 緊急対応なのでPoer権限で実行する必要があります
- 具体的にはどんな作業でセッション切れになりますか？
- 解決策
- 緊急対応のために全環境一律セッションを伸ばすと単純にセキュリティリスクが増える
- 緊急用許可セットを用意して4時間に延長
- 大規模なシステム障害のために用意
- 合わせてこの許可セットが使われたときに検出できるように通知の仕組みを作った
- 開発チームがこれを使うとCCoEチームが把握できる
- ユーザーからは両方の許可セットが見えている状態
- またとある日
- Bさんから落とし所はないですかという質問
- ヒアリング
- どのような作業でセッション切れになるか
- 基本開発作業や運用作業
- 内容が複雑だと1時間を超える
- 利用頻度が高いのは？
- 一番困っているのは開発環境や検証環境
- これがセッションが長くなると開発効率が上がる
- どのような作業でセッション切れになるか
- 解決策
- 開発環境と検証環境は2時間にした
- とある日
- 最適化
- 2つの解決策を取り入れた結果、本当に守るべき環境と用途のセッション時間は変えずに、要件を再文化し運用効率性を考慮して柔軟に設計した
- 所感
- Slackで依頼されたらそのまま文面を受け取るのではなく深堀りが大事
- 深堀りすると相手も納得しセキュリティ統制場も問題ないと判断できる着地点が見つかりやすい
- 結局は人と人のコミュニケーション
- ステークホルダー
- セキュリティ vs 運用効率性
- トレードオフだがヘイトが溜まる
- これって正解はないですよね
- 現場の声を聴いて
- 一般的なセキュリティ指標の価値観や感覚はコミュニティなどで情報吸収することが大事
- バランスを取っていきましょう
まとめ
IAM1つとってもたくさんの内容がありました。簡単ではないですががんばっていきまっしょい！
