AWS Organizations 組織ポリシーについて理解しよう！

皆さんは、AWS Organizationsを上手く利用できていますでしょうか？

AWS Organizationsにはたくさんの機能がありますが、今回は主要機能である組織ポリシーについて解説しようと思います。 AWS Organizationsの組織ポリシーは、現在11種類も存在しており、それぞれが異なる目的と機能を持っています。

これらのポリシーは「承認ポリシー」と「管理ポリシー」という2つの大きなカテゴリに分類でき、体系的に理解することで、効果的な活用が可能になります。 本記事では、この11の組織ポリシーに触れていきます。各ポリシーの基本的な仕組みからユースケースまでを説明し、読み終えた後に皆さんの環境下でどのように活用していくかイメージしていただければと思います。

AWS Organizations 組織ポリシーの全体像

組織ポリシーとは何か

AWS Organizationsの組織ポリシーとは、組織内の複数のAWSアカウントを一元的に管理・制御するための仕組みです。例えば、100個のAWSアカウントを管理している企業で、各アカウントで同じセキュリティ設定を手動で行うのは膨大な作業量になります。組織ポリシーを使えば、一度の設定で全アカウントに同じルールを適用できるため、運用効率が向上します。

承認ポリシーと管理ポリシーの違い

AWS Organizationsの組織ポリシーは、大きく「承認ポリシー」と「管理ポリシー」の2つのカテゴリに分類されます。

承認ポリシーは、「何ができるか・できないか」を制御するポリシーです。組織内のユーザーやリソースに対して、アクセス許可の最大範囲を定義します。現在、承認ポリシーには以下の2種類があります：

• SCP（サービスコントロールポリシー） ：IAMユーザーとロールの権限を制限
• RCP（リソースコントロールポリシー） ：リソースへのアクセス権限を制限

管理ポリシーは、「どのように設定・運用するか」を制御するポリシーです。バックアップの頻度、タグの命名規則、セキュリティ設定の基準など、組織全体の運用ルールを定義します。管理ポリシーには以下の9種類があります：

• タグポリシー ：タグ付けルールの標準化
• バックアップポリシー ：バックアップルールの統一
• AIサービスのオプトアウトポリシー ：AIサービスのデータ利用制御
• 宣言型ポリシー ：設定の自動適用
• チャットアプリケーションポリシー ：チャットツールからのアクセス制御
• Security Hubポリシー ：セキュリティ基準の統一
• Amazon Inspectorポリシー ：脆弱性スキャンの一元管理
• Amazon Bedrockポリシー ：生成AIのガードレール適用
• Upgrade Rolloutポリシー ：自動アップグレードの段階的展開

11のポリシータイプの概要

初めてAWS Organizationsを導入する組織では、まずSCP（サービスコントロールポリシー）から始めることをお勧めします。次にタグポリシーを導入し、その後組織の成熟度に応じて他のポリシーを段階的に追加していきます。

ただし、必ず検証環境でポリシーを適用して意図した挙動になっていることを確認してから本番環境での適用を実施してください！

AWS Organizations 組織ポリシー(承認ポリシー編)

SCP（サービスコントロールポリシー）の仕組み

SCPは、AWS Organizations組織ポリシーの中で最も広く利用されている承認ポリシーです。重要なのは、SCPは「権限を付与する」のではなく、「権限を制限する」ポリシーだということです。

IAMでどんなに強い権限を持っていても、SCPで「ダメ」と言われたら、その操作は実行できません。例えるなら、遊園地の年間パスポートを持っていても、「本日メンテナンスのため利用不可」の看板があれば乗れないのと同じです。

SCPの基本的な設定例：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "ec2:TerminateInstances",
        "rds:DeleteDBInstance"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "ap-northeast-1"
        }
      }
    }
  ]
}

この例では、東京リージョンでのEC2インスタンスとRDSインスタンスの削除を禁止しています。本番環境の誤削除を防ぐ効果的な設定です。

RCP（リソースコントロールポリシー）の活用

RCPは2024年に導入された新しい承認ポリシーです。SCPがプリンシパル（誰が）の権限を制限するのに対し、RCPはリソース（何に対して）のアクセスを制限します。

主な用途として、S3バケットへの外部アカウントからのアクセスを組織内のみに制限するなど、データ漏洩のリスクを大幅に低減できます。RCPはリソースベースポリシーよりも優先されるため、既存のクロスアカウントアクセスへの影響を十分に検証してから導入することが重要です。

承認ポリシーのベストプラクティス

• DenyListアプローチから始める ：まず特定の危険な操作のみを禁止し、徐々に制限を強化
• テスト用OUで検証 ：組織全体に適用する前に限定的な範囲で動作確認
• 緊急時用アカウントの準備 ：緊急時用アカウントにはSCPを適用しない
• CloudTrailとの連携 ：ポリシー違反の試行を監視し、定期的に調整

AWS Organizations 組織ポリシー(管理ポリシー編)

タグポリシー：リソース管理の標準化

タグポリシーは、組織内のタグ付けルールを標準化する管理ポリシーです。「部門ごとにタグの付け方がバラバラ」「Environment タグに『prod』『production』『本番』など複数の表記が混在」といった課題を解決します。

設定により、Environmentタグには「Production」「Staging」「Development」「Testing」のみが使用可能になり、CostCenterタグは「CC-」に続く4桁の数字形式に統一できます。実際の導入事例では、月次のコスト分析が3日から30分に短縮されたケースもあります。

バックアップポリシー：データ保護の自動化

AWS Backupと連携し、組織全体のデータ保護戦略を一元化します。タグベースでの自動バックアップ設定により、「Backup: Daily」タグが付いたリソースを毎日バックアップするといった運用が可能です。

データの重要度に応じた設定例：

• Critical ：1時間ごとのバックアップ、90日間保持
• Important ：日次バックアップ、30日間保持
• Standard ：週次バックアップ、14日間保持

AIオプトアウトポリシー：プライバシー制御

組織のデータがAWSのAI/MLサービスの品質向上のために使用されることを防ぎます。対象サービスにはComprehend、Lex、Polly、Rekognition、Textract、Transcribe、Translateなどが含まれます。GDPR、HIPAA、個人情報保護法などのコンプライアンス要件に対応する際に重要な設定です。

宣言型ポリシー：設定の自動適用

2024年に導入された最新機能で、「あるべき状態」を宣言するだけで、組織内のすべてのアカウントがその状態を自動的に維持します。例えば、すべてのEC2インスタンスでIMDSv2を強制する、S3バケットのデフォルト暗号化を設定するなど、セキュリティベースラインの自動適用が可能です。

チャットアプリケーションポリシー：ChatOpsの実現

SlackやMicrosoft TeamsからのAWSアカウントへのアクセスを制御します。承認されたチャンネルからのみ操作を許可し、読み取り専用アクセスをデフォルトとすることで、ChatOpsを安全に実現できます。

Security Hubポリシー：セキュリティ統制

AWS Security Hubの設定を組織全体で統一し、複数のセキュリティ基準（CIS、PCI-DSS、AWS基礎セキュリティのベストプラクティスなど）を組織レベルで自動的に有効化します。継続的なコンプライアンス監視と、セキュリティスコアの可視化により、組織のセキュリティ態勢を改善できます。

Amazon Inspectorポリシー：脆弱性管理の一元化

Amazon Inspectorポリシーは、組織全体でAmazon Inspectorを一元的に有効化・管理できる管理ポリシーです。「各アカウントで個別にInspectorを有効化する手間がかかる」「新規アカウントでスキャンが漏れてしまう」といった課題を解決します。

このポリシーにより、委任管理者が組織全体のスキャン設定を一括で管理でき、メンバーアカウントはポリシーで管理されているスキャンタイプを個別に無効化できなくなります。これにより、組織全体で一貫した脆弱性スキャンのカバレッジを確保できます。

対象スキャンタイプの設定例：

• EC2スキャン ：EC2インスタンスのソフトウェア脆弱性を継続的に検出
• ECRスキャン ：コンテナイメージの脆弱性をプッシュ時・継続的に検出
• Lambdaスタンダードスキャン ：Lambda関数の依存関係の脆弱性を検出
• Lambdaコードスキャン ：Lambda関数のコードセキュリティ問題を検出

Amazon Bedrockポリシー：生成AIのガードレール強制

Amazon Bedrockポリシーは、Amazon Bedrock Guardrailsで設定したセーフガードを組織全体のモデル推論呼び出しに自動的に適用できる管理ポリシーです。「各チームが個別にガードレールを設定している」「一部のアカウントでAI利用のセーフティ基準が守られていない」といった課題を解決します。

このポリシーにより、組織全体でAI利用のセーフティ基準を統一でき、不適切なコンテンツ、機密情報の露出、モデルのハルシネーションからの一貫した保護を実現できます。メンバーアカウントがInvokeやConverse APIを呼び出す際、指定されたガードレールが含まれていないリクエストは自動的に拒否されます。

ガードレール設定のユースケース例：

• コンテンツフィルタリング ：有害・不適切なコンテンツの生成を防止
• 機密情報保護 ：個人情報や機密データの漏洩を防止
• ハルシネーション対策 ：事実と異なる情報の生成を抑制
• トピック制限 ：特定のトピックに関する回答を制限

Upgrade Rolloutポリシー：データベースアップグレードの段階的展開

Upgrade Rolloutポリシーは、Amazon AuroraおよびAmazon RDSの自動マイナーバージョンアップグレードを組織全体で段階的に展開できる管理ポリシーです。「数百のデータベースのアップグレードを手動で調整している」「本番環境に適用前にテストできていない」といった課題を解決します。

このポリシーにより、開発環境→テスト環境→本番環境の順序でアップグレードを自動制御でき、重要度の低い環境で変更を検証してから本番に適用できます。AWS Health通知により各フェーズ間の進捗を監視でき、問題が検出された場合は自動進行をいつでも停止できます。

対象サービスと設定例：

• Amazon Aurora ：MySQL互換、PostgreSQL互換エディション
• Amazon RDS ：MySQL、PostgreSQL、MariaDB、SQL Server、Oracle、Db2
• アップグレード順序 ：[first]開発環境 → [second]QA環境 → [last]本番環境
• 待機期間 ：各フェーズ間で約1週間の検証期間を自動設定

AWS Organizations 組織ポリシーの実装手順と運用のコツ

全てを一気に実行しようとするとかなり骨が折れてしまうかと思いますので、導入しやすいロードマップを私の方で作成しましたので、とりあえず何からやったらいいかわからない人はこちらのロードマップを参考にしてみてください。

段階的導入のロードマップ

• Phase 1：基礎固め
  • SCP：基本的なセキュリティ境界の設定（削除操作の制限、リージョン制限）
  • タグポリシー：必須タグの定義（Environment、Owner、CostCenter）
• Phase 2：運用効率化
  • バックアップポリシー：重要度に応じたバックアップスケジュール設定
  • AIオプトアウトポリシー：コンプライアンス要件に応じた設定
  • Amazon Inspectorポリシー：脆弱性スキャンの組織全体有効化
• Phase 3：高度な設定
  • RCP、宣言型ポリシー、Security Hubポリシー、チャットポリシーを必要に応じて導入
  • Amazon Bedrockポリシー：生成AIのガバナンス強化
  • Upgrade Rolloutポリシー：データベースアップグレードの自動化

また、全てのポリシーで言えることですが、以下の点を考慮しながら進めていただき、形骸化を防げるかと思います。

導入時の重要な考慮事項

1. スモールスタートの原則 ：SCPとタグポリシーから始めて効果を実感しながら拡張
2. テスト環境での検証 ：特にSCPとRCPは業務影響が大きいため慎重に
3. 組織文化への配慮 ：開発チームへの事前説明と段階的な制限強化
4. 継続的な見直し ：四半期ごとのポリシーレビューと新サービスへの対応

最後に

AWS Organizations組織ポリシーは、マルチアカウント環境のガバナンスを劇的に改善する強力なツールです。11のポリシーそれぞれに特徴があり、組織の要件に応じて適切に選択・組み合わせることで、セキュアで効率的なクラウド環境を実現できます。

まずはSCPとタグポリシーから始めて、効果を実感しながら段階的に拡張していくことをお勧めします。

最後にこの組織ポリシーを運用していく上で、一番大事だと思っていることをお伝えします。それは、属人化した運用をしないことです。組織ポリシーはセキュアで効率的な反面、属人化してしまうことによってそのポリシーが地雷化してしまう恐れがあるためです。

例えば、このポリシーを会社のAさんだけが理解しており、Aさんが退職されたり、作業しようとした日にAさんがお休みだった場合どうでしょうか？作業するのが怖くないでしょうか？

どのような影響があるかわからない環境に触れることは非常に怖いことです。また作業後に何かしらトラブルが発生した場合に切り分けにも時間がかかります。

そして何よりも誰もわからないものだから、臭いものに蓋をするようにすると、この組織ポリシーだけでなく、ありとあらゆる運用に影響が出ることによって、結果的に何もしない(できない)になり、セキュリティの脆弱性がむしろ広がっていくことになります。

そのため、皆さんと一緒に働いている仲間が、後で苦しまないように属人化しないような仕組みを考えながら、運用することを望んでいます！