1,000 にも届く AWS Organizations 組織のポリシー運用をちゃんとしたい、という話

2026年2月12日にオンライン開催された「Security-JAWS【第40回】 2026年2月12日(木) #サイバーセキュリティは全員参加」での登壇資料です。

リセラーとして提供する約 1,000 の AWS Organizations 管理アカウントにおいて、提供形態ごとに微妙に異なる IAM ポリシーや SCP が乱立し、共通部分のアップデート作業が煩雑化している課題に対する解決策の模索についてお話ししました

ビルディングブロック的なアプローチでポリシー管理の効率化を目指す実験的な取り組みとしての検討段階なので、いろんなフィードバックをいただけると嬉しいです

#secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加

Transcript

1. 1,000 にも届く AWS Organizations 組織の ポリシー運用をちゃんとしたい、という話 Security-JAWS 【第40回 】 2026年2月12日(木) #サイバーセキュリティは全員参加 (Feb. 12, 2026) Speaker : @kazzpapa3 / JAWS-UG 神戸
2. Biography { "Bio": { "Name": "ICHINO Kazuaki a.k.a. kazzpapa3", "Organization": "A certain AWS partner company", "Role": "Technical Support Engineer", "Favorite AWS Services": [ "AWS CLI", "AWS CloudTrail", "Kiro CLI" ], "Less Favorite AWS Service (as a Support Engineer)": [ "AWS Billing (請求ロジックが難解すぎる)" ], "Personal Interest": "初音ミク", "Socials": { "Twitter/X": "@kazzpapa3", "LinkedIn": "https://www.linkedin.com/in/kazzpapa3/" } } }
3. みなさん、ポリシーの管理してますか @kazzpapa3 / #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加 3 / 37
4. おおまかな背景や概要 自己紹介としてテクニカルサポートエンジニアと名乗りましたが、リセ ールアカウントの提供仕様を管理する部門でもあります いくつかある提供仕様の中で細かい差分が多い 大部分は共通するものの、 細かい差分によりポリシーが乱立する 共通する部分のアップデートをあちこちでする必要がある こういう点をちょっと困っている、という話 あと個人的には JSON は人類には早すぎる と思っています @kazzpapa3 / #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加 4 / 37
5. 差分が生まれる背景 リセラー提供のアカウントでは AWS Organizations や AWS Control Tower が使えない そのようにイメージされている方も多いと思います 実は私の所属企業での提供では AWS Organizations や AWS Control Tower をご利用いただくことが可能です ただしリセラーとして許容できない操作はあり、管理アカウントを利 用可能にしているものの操作を制限したりしています 提供している組織の状態によって許容するもの・しないものが微妙に 変わるためポリシーとして差分が生まれてきます @kazzpapa3 / #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加 5 / 37
6. 今日の前提 まさしく検討中のもので結論が出ている話ではないです 一旦 IaC を採用しない方向で考えていますが、IaC を否定する意図はあ りません デプロイ面や学習コストを考慮して、IaC を使わない方法論を模索し始 めている感じです マサカリは怖い んですが、建設的な意見やこういった観点があるんじ ゃない？というアドバイスは大歓迎です あと昨年 JAWS-UG DE&I 支部でも話している内容が含まれるので、ご 覧になったことがある方はごめんなさい @kazzpapa3 / #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加 6 / 37
7. 実際に使っているものではないですが、差分の例 基本はケース起票してほしくないが、一部では OK みたいな ただしそれ以外はリセラーとして許容できないので共通で Deny … 7 / 37
8. 実際に使っているものではないですが、差分の例 メンバーアカウントの root ユーザーの管理が弊社 or お客様 ただし組織からの離脱は NG などフル権限ではない 8 / 37
9. 前述のような差分が IAM ポリシーにも SCP にも存在している 管理アカウントを一部利用可能にする、Control Tower を使っている、 など条件に合わせて複数のポリシーが存在する ただし、基本的にリセラーとして許容できない部分は同じではあるの で、共通する部分は多い 基本的な部分で改定が必要な AWS アップデートがあった場合に、それ ぞれのポリシードキュメントの該当箇所を等しく直す必要がある re:Invent 前後など、大量アップデートの時の精査が大変… @kazzpapa3 / #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加 9 / 37
10. 1,000 近い管理アカウント＝ 1,000 通りではないが Policy A' Policy A' Policy A'' Policy A'' AWS Organizations 管理アカウント メンバーアカウント Policy A Policy A AWS Organizations 管理アカウントを渡さない組織群 管理アカウントを渡している組織群 Control Tower を利用している組織群 パターン A リシー パターン B リシー パターン C リシー AWS Organizations 管理アカウント メンバーアカウント AWS Organizations 管理アカウント メンバーアカウント Control Tower 利用 管理アカウント メンバーアカウント Control Tower 利用 管理アカウント メンバーアカウント 管理アカウント メンバーアカウント すべての管理アカウントがバラバラなわけではないが、形態に合わせて 数パターン乱立している @kazzpapa3 / #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加 10 / 37
11. イメージとしては以下のような感じ Sid-01 Sid-01 Sid-02 Sid-02 Sid-03 Sid-03 Sid-04 Condition-01 Condition-01 Sid-04 Condition-01 Sid-05 Sid-05 Sid-06 Condition-02 Sid-06 Condition-02 Policy-A Policy-B 四角で表現しているのが Sid ごとや Condition ごとのひとかたまり 水色部分が共通する部分、色を変えている部分が異なる部分 11 / 37
12. AWS だから言うわけじゃないが パーツ（モジュール）化して、ビルディングブロック的に組み合わせて ポリシーを生成できないか 各ポリシーとして個別に書いてしまうのではなく、分割可能な粒度で部 品としておき、利用するときに組み合わせるイメージ @kazzpapa3 / #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加 12 / 37
13. IaC 使う？ @kazzpapa3 / #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加 13 / 37
14. AWS CDK でもモジュールっぽく扱えるらしい… PolicyStatement を関数やクラスで部品化する？ クラスベースで管理する？ 共通部分を JSON で管理しておき、差分だけコードで追加する？ ただし、デプロイ時に 1,000 個のスタックを作成した後で、すべて同 時（逐次）実行するのでは？ AWS CDK の学習コストが見合うか？ @kazzpapa3 / #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加 14 / 37
15. IaC を使わない方法が取れないか、 生成 AI を活用してちょっと模索してみた @kazzpapa3 / #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加 15 / 37
16. パーツ（モジュール）化できないか Sid ごとにパーツやモジュールのように切り出せないか 部品のように仕立てておいて、必要なものを必要なときに組み合わせて ポリシーを作るような感じで管理できないか @kazzpapa3 / #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加 16 / 37
17. こんな感じのイメージ Sid-06 Sid-06 Policy-A Policy-B Sid-01 Sid-02 Sid-03 Condition-01 Sid-04 Condition-01 Sid-05 Condition-02 Sid-01 Sid-02 Sid-03 Sid-04 Condition-01 Sid-05 Sid-06 Condition-02 Sid-01 Sid-04 Condition-01 Sid-02 Sid-03 Sid-03 Sid-05 Sid-05 Condition-02 Condition-02 + + 17 / 37
18. やってみた @kazzpapa3 / #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加 18 / 37
19. ポリシーは YAML で書く VersionDeclaration.yaml 念の為、Version 部分も部品として切り出し # IAM JSON policy elements の Version のみを切り出している # Version の改訂があった場合に見直しが必要 # https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_version.html Version: "2012-10-17" Statement: @kazzpapa3 / #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加 19 / 37
20. ポリシーは YAML で書く BasicRestrictionAsResaler.yaml（ support:* を Deny） - Sid: BasicRestrictionAsResaler Effect: Deny Action: - support:* # 処理の概要： AWS Support 利用の禁止 # 緩和の可否： サポートケース起票はしちゃダメ - supportplans:* # 処理の概要： サポートプランのすべての禁止 # 緩和の可否： サポートプランは変えちゃダメ - tax:* # 処理の概要： 税設定 のすべての禁止 # 緩和の可否： 日本国内の税設定にしないと処理として困っちゃう # すべてリソースに対する禁止 Resource: '*' 20 / 37
21. ポリシーは YAML で書く BasicRestrictionAsResalerForResold.yaml（ support:* は許容） - Sid: BasicRestrictionAsResalerForResold Effect: Deny Action: - supportplans:* # 処理の概要： サポートプランのすべての禁止 # 緩和の可否： サポートプランは変えちゃダメ - tax:* # 処理の概要： 税設定 のすべての禁止 # 緩和の可否： 日本国内の税設定にしないと処理として困っちゃう # すべてリソースに対する禁止 Resource: '*' 21 / 37
22. YAML で書いたものを yq コマンドで寄せ集める BasicRestrictionAsResaler（ support:* を Deny） を使う時 IAMPolicyRestrictionForCustomer.yaml、 RestrictionToAWSOrganizatioinsAsResaler.yaml は共通パーツと 仮定する yq eval-all ' select(fileIndex == 0) | .Statement = [ (load("IAMPolicyRestrictionForCustomer.yaml") | .[0]), (load("BasicRestrictionAsResaler.yaml") | .[0]), # ここだけ違う (load("RestrictionToAWSOrganizatioinsAsResaler.yaml") | .[0]) ] ' VersionDeclaration.yaml > foo.yaml @kazzpapa3 / #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加 22 / 37
23. YAML で書いたものを yq コマンドで寄せ集める BasicRestrictionAsResalerForResold（ support:* は許容） を使う時 IAMPolicyRestrictionForCustomer.yaml、 RestrictionToAWSOrganizatioinsAsResaler.yaml は共通パーツと 仮定する yq eval-all ' select(fileIndex == 0) | .Statement = [ (load("IAMPolicyRestrictionForCustomer.yaml") | .[0]), (load("BasicRestrictionAsResalerForResold.yaml") | .[0]), # ここだけ違う (load("RestrictionToAWSOrganizatioinsAsResaler.yaml") | .[0]) ] ' VersionDeclaration.yaml > bar.yaml @kazzpapa3 / #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加 23 / 37
24. できたもの（この段階ではまだ YAML） # IAM JSON policy elements の Version のみを切り出している # Version の改訂があった場合に見直しが必要 # https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_version.html Version: "2012-10-17" Statement: 〜中略〜 - Sid: BasicRestrictionAsResaler Effect: Deny Action: - support:* # 処理の概要： AWS Support 利用の禁止 # 緩和の可否： サポートケース起票はしちゃダメ - supportplans:* # 処理の概要： サポートプランのすべての禁止 # 緩和の可否： サポートプランは変えちゃダメ - tax:* # 処理の概要： 税設定 のすべての禁止 # 緩和の可否： 日本国内の税設定にしないと処理として困っちゃう # すべてリソースに対する禁止 Resource: '*' 〜以下略〜 24 / 37
25. 処理の概要 yq コマンドでやっていることは以下のような感じ 1. eval-all: 複数ファイルを扱うモード 2. select(fileIndex == 0): 最初のファイル（VersionDeclaration.yaml）のみを選択 3. .Statement = [...]: Statementフィールドに配列を代入 - load("IAMPolicyRestrictionForCustomer.yaml") | .[0] - ファイルを読み込み、最初の要素を取得 - load("BasicRestrictionAsResaler.yaml") | .[0] - 同様に読み込み - load("RestrictionToAWSOrganizatioinsAsResaler.yaml") | .[0] - 同様に読み込み 4. VersionDeclaration.yaml: ベースとなるファイル（Version情報を含む） 5. > foo.yaml: 結果を出力 @kazzpapa3 / #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加 25 / 37
26. この後 JSON 化 yq -o=json foo.yaml > foo.json cat foo.json { "Version": "2012-10-17", "Statement": [ 〜中略〜 { "Sid": "BasicRestrictionAsResaler", "Effect": "Deny", "Action": [ "support:*", "supportplans:*", "tax:*" ], "Resource": "*" }, 〜以下略〜 } 26 / 37
27. あとは妥当性を確認するなど、お好みで aws accessanalyzer validate-policy \ --policy-type IDENTITY_POLICY \ --policy-document file://foo.json { "findings": [] } accessanalyzer validate-policy サブコマンドの実行結果として、 findings が空の状態で返却されればポリシードキュメントとして問題 がない ただしポリシードキュメントの意図を判断してくれるわけではないの で、影響範囲が正しいかの判断は別途必要 @kazzpapa3 / #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加 27 / 37
28. やってみた感想 目論見どおり、パーツ化できそうな手応えは感じている 各パーツの改訂があったときに、修正しパーツを commit する 裏で GitHub Actions が動き JSON のポリシードキュメント化す る、などすれば良さそうかな？と思っている YAML にすることでコメントを記載できるようになった JSON のポリシードキュメントの場合「なぜ Deny」しているのかが わかりにくかった Know Why が残しやすい副次的なメリット も生まれそう （やっぱり JSON は人類には早すぎたんだと思われる） 28 / 37
29. コメントは実は JSON でも… JAWS-UG DE&I 支部で話したときにいただいた反応 JSONC | Specification @kazzpapa3 / #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加 29 / 37
30. 見えてきたもの Policy A Commit Commit GitHub Actions Policy A' AWS Organizations 管理アカウント メンバーアカウント Control Tower 利用 管理アカウント メンバーアカウント Policy A Policy A’ Deploy Deploy ここまでは前述までの方法論でだいたい見えてきた （AWS CDK でテンプレート作成までで留める方法でも良さそう、とも思う） デプロイどうしようか… YAML のコメントを活用して 仕様書生成にも使えそう 30 / 37
31. デプロイどうしよう問題 現状は各アカウントに対して一括で書き換えるスクリプトで実施してい る ポリシー名やロール名が変更されておらず、存在している前提がある ため ポリシー自体の組み立ては今回の方法でも、テンプレート作成まで AWS CDK に依存するでもどちらでも良さそう 結局 CloudFormation StackSets で展開する方が良さそうか 現状 CFn で展開されていない IAM リソースを StackSets 運用に 切り替えるときに既存リソースとの競合をどうしようかな @kazzpapa3 / #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加 31 / 37
32. おわりに IaC を使わないことを前提としたものの CloudFormation などを使い たくないわけではない 基本的に自社の管理下にあり、ポリシー名やロール名はほぼ変更しな い、かつ、存在していない状態はないと断定できるので、一括で書き 換えるスクリプトを流す方が良い、という判断です もっといいやり方があるんじゃない、などお話できたらうれしい です @kazzpapa3 / #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加 32 / 37
33. ちょっと告知 33 / 37
34. 3月7日 JAWS DAYS 2026 で登壇します Abuse report だけじゃない。AWS から緊急連絡が来る状況とは？昨 今の攻撃や被害の事例の紹介と備えておきたい考え方について タイトル長いですが、どこまで話せるかギリギリを攻めてみます 34 / 37
35. Security is job zero. Thank you.
36. Appendix 36 / 37
37. 参考資料 yq / GitHub yq / gitbook validate-policy — AWS CLI 2.33.19 Command Reference IAM Access Analyzer でポリシーを検証する - AWS Identity and Access Management Actions | GitHub JSONC | Specification 37 / 37