金融機関グレードの統制と俊敏性を両立する AWS Organizations の OU・SCP 設計ベストプラクティス

はじめに

こんにちは、DXソリューション営業本部の小原です！
弊社では金融機関グレードの顧客に対して、AWSインフラ基盤の導入・運用支援を行っています。
今回の記事では金融機関グレードでのAWSインフラ基盤において、 OU / SCP の設計で気を付けていた点などをご紹介いたします！

1. なぜ金融機関グレードでは OU / SCP 設計が経営課題になるのか

金融機関グレードでのクラウドガバナンスでは、次の 2 つの要請がぶつかります。

この 2 つを個々のアカウント設定や運用ルールだけで両立させるのは困難です。組織構造（OU）と組織レベルのガードレール（SCP など）の設計に落とし込む必要があり、その設計の良し悪しがガバナンス全体の成否を決めます。

参考：FISC「金融機関等コンピュータシステムの安全対策基準・解説書」（第14版）【PDF版】を公表しました

2. 4 つの設計原則

本記事でご紹介する設計では、次の 4 つの原則に基づいています。

1. 階層による責務分離
   OU 階層を「セキュリティ」「基盤」「業務」「実験」に分け、ポリシーを階層的に重ねて多層防御にします。
2. 最小権限のガードレール
   組織全体で「禁止すべきこと」を SCP で明示します。権限そのものは IAM ポリシーで与え、SCP は境界を担保する、と役割を分けます。
3. 不変な監査基盤
   CloudTrail・Config・GuardDuty などの停止や削除を、全メンバーアカウントで禁止します。
4. スケーラブルな運用
   Account Factory と IaC でアカウント発行を自動化し、OU やポリシーの追加・変更を再現できるようにします。

原則 2 の「SCP は境界」という考え方は、AWS の仕様そのもので SCP は権限を付与しません。メンバーアカウントの IAM ユーザー・ロール（ルートユーザーを含む）が使える権限の上限を定めるもので、実際に有効な権限は SCP が許可する範囲と IAM ポリシー（アイデンティティベース／リソースベース）が許可する範囲の共通部分になります。なお厳密には、アクセス許可の境界（Permissions Boundary）、セッションポリシー、後述の RCP も有効な権限の決定に関わります。

2.1 設計前に押さえておく SCP の仕様

SCP には効かない対象があり、設計に直接影響します。

• 管理アカウント（Management Account）のユーザー・ロールには効きません。 効くのはメンバーアカウントだけです（委任管理者に指定したメンバーアカウントには効きます）。
• サービスにリンクされたロール（Service-linked role）には効きません。
• リソースベースのポリシーには直接は効きません。 組織外のプリンシパルからのアクセスは SCP では制御できません。
• メンバーアカウントのルートユーザーには効きます。ただし、一部の例外タスクがあります。

参考：Service control policies (SCPs) - AWS Organizations

クォータは 2026年05月に引き上げられました。現在は、SCP 1 つあたりの最大サイズが 10,240 文字（以前は 5,120 文字）、Root・OU・アカウントそれぞれに付けられる SCP が 最大 10 個（以前は 5 個）です。OU のネストは Root の下 5 階層までです。また、SCP を有効にしている場合、すべてのエンティティに少なくとも 1 つの SCP が付いている必要があります。なお、このクォータ引き上げは SCP だけが対象です。RCP は現在も 1 つあたり 5,120 文字、Root・OU・アカウントそれぞれに最大 5 個、宣言型ポリシーは 1 つあたり 10,000 文字、最大 10 個です。

参考：Quotas and service limits for AWS Organizations／AWS Organizations increased SCP quotas（2026年05月15日）

2025年09月からは、SCP で IAM ポリシー言語のすべての機能が使えるようになりました。Allow ステートメントでの条件（Condition）、個別リソース ARN の指定、Allow での NotAction、アクション文字列の先頭・途中でのワイルドカード、NotResource が使えます。これにより、後述する許可リスト方式でも細かい制御ができるようになっています。
※こちらのアップデートは以下の記事でもご紹介いたしました。

【AWS Organizations SCPアップデート】DenyとAllowのハイブリッド方式で実現する、現実的で堅牢な新世代ガードレール｜QESブログ
今回はAWS OrganizationsのSCPのアップデートに伴う新しい形のガードレールについて検討していきます。
 

2.2 SCP 以外の組織ポリシーとの役割分担

現在の AWS Organizations では、SCP だけでなく次のポリシーも組み合わせて使えます。それぞれ守備範囲が違います。

RCP も SCP と同様に権限を付与せず、管理アカウントのリソースには効きません。また、RCP が使えるのは対応サービスに限られます。対応サービスは提供開始当初の S3・STS・KMS・SQS・Secrets Manager から順次拡大しており、2026年10月時点では DynamoDB、ECR、CloudWatch Logs、Cognito などを含む 60 以上のサービスに対応しています。最新の対応状況は公式ドキュメントで確認してください。

参考：Resource control policies (RCPs) - AWS Organizations

宣言型ポリシー（EC2）では現在、VPC Block Public Access、Serial Console Access、Image Block Public Access、Allowed Images Settings、Instance Metadata（IMDS のデフォルトと IMDSv2 の強制）、Snapshot Block Public Access、VPC Encryption Controls の 7 つの属性を設定できます。このうち VPC Encryption Controls は、2026年07月06日に宣言型ポリシーで一括適用できるようになった属性です。AWS は宣言型ポリシーで設定した構成は新しい機能や API が追加されても維持されると説明しています。そのため、「新しい API が出るたびに SCP に Deny を追加する」運用の負担を減らせます。

参考：Declarative policy syntax and examples - AWS Organizations／AWS introduces declarative controls for VPC Encryption Controls（2026年07月06日）

3. 推奨 OU 階層（Landing Zone 型）

この構成は AWS のホワイトペーパー「Organizing Your AWS Environment Using Multiple Accounts」の推奨に沿っています。ホワイトペーパーは推奨 OU を基盤 OU（Foundational OUs：Security OU・Infrastructure OU）、アプリケーション OU（Application OUs：Workloads OU）、実験 OU（Experimental OUs：Sandbox OU）、手続き OU（Procedural OUs：Exceptions OU・Transitional OU・Suspended OU・Policy Staging OU）、高度な OU（Advanced OUs）に分類しています。本記事の構成は、このうち高度な OU を除いたものです。なお、推奨 OU をすべて最初から作る必要はなく、要件に応じて増やしていけばよいとされています。

参考：Recommended OUs and accounts - Organizing Your AWS Environment Using Multiple Accounts

Management Account にはワークロードを置きません。前述のとおり、管理アカウントには SCP も RCP も効かないため、管理アカウント上のワークロードには組織のガードレールが一切かからないからです。

3.1 基盤・業務系 OU（Foundation）

Security OU のアカウント構成はホワイトペーパーで Log Archive と Security Tooling（Audit）の 2 つが推奨されています。Log Archive は組織全体のログを集約する場所、Security Tooling は AWS のセキュリティツールへの委任管理アクセスと全アカウントへの調査用の閲覧アクセスを提供する場所です。

参考：Foundational OUs - Organizing Your AWS Environment Using Multiple Accounts

3.2 運用・手続き系 OU（Lifecycle / Procedural）

• Sandbox OU
  個人・チームが自由に検証する場所です。インターネット公開は不可とし、コスト上限を設け、許可するサービスを絞ります。本番リソースへの VPC ピアリングも禁止します。
• Policy Staging OU
  SCP・タグポリシー・ベースラインの IAM ロールなど、影響範囲の広いポリシー変更を本番前に検証する場所です。ホワイトペーパーでは本番の OU 構成を模した子 OU とテストアカウントを置き、まず対象 OU 内の 1 アカウントに適用し、次に OU 全体へ広げるという段階的な昇格を推奨しています。
• Transitional OU
  M&A や既存アカウントの取り込みなどで組織に移した既存アカウントを一時的に置く場所です。取り込む前に Root の SCP が既存ワークロードに悪影響を与えないかを確認します。
• Suspended OU
  利用を停止するアカウントの一時的な隔離先です。セキュリティチームとクラウド基盤チーム以外による API 利用を SCP でブロックし、移動の理由と元の OU をタグで記録します。なお、この OU に移してもアカウントのステータスは自動的には変わりません（OU 名の「Suspended」と、AWS Organizations のアカウント状態「SUSPENDED」は別物です。後者は AWS 側がアクセスを制限した状態を指します）。完全に使わなくなるアカウントは別途アカウント閉鎖の手続きを行います。
• Exceptions OU
  Workloads OU のセキュリティポリシーの例外が必要なアカウントだけを置きます。ホワイトペーパーでは、この OU のアカウントは最小限にとどめ、SCP はアカウント単位で付け、セキュリティ監視をより厳しくすることが推奨されています。運用面では「承認」「有効期限」「補償統制」の 3 点を台帳で管理し、定期的に再審査します。

参考：Procedural OUs - Organizing Your AWS Environment Using Multiple Accounts

Suspended OU で設けるデータ削除前のクーリング期間（例：30〜90 日）は組織の運用として決める期間です。これとは別に AWS 側にもアカウント閉鎖後の期間があります。閉鎖したアカウントは CLOSED 状態になり、閉鎖開始から 90 日間（post-closure period）はサポートへの連絡で復旧やデータ回収ができます。90 日を過ぎると完全に閉鎖されます。また、Suspended OU のアカウントからは、閉鎖する予定でない限りリソースを削除しないことが推奨されています。

参考：Monitor the state of your AWS accounts - AWS Organizations

4. Security OU とログ機能の分離設計

監査ログの保全場所をどう配置するかには、2 つの選択肢があります。

推奨： 原則として A を採用し、Log Archive アカウントは強力な SCP で保護します。規制要求が特に厳しい場合に限って B を選びます。

AWS Control Tower を使う場合、ランディングゾーン バージョン 4.0（2025年11月17日リリース） からは Security OU が必須ではなくなり、組織構造を自分で定義できます（条件は、すべてのハブアカウントを同じ OU（Root 直下の OU）に置くことだけです）。AWS Config・CloudTrail・Security Roles・AWS Backup との連携も選択して有効・無効にでき（ただし Config 連携を無効にする場合は、Security Roles・IAM Identity Center・AWS Backup の連携も無効にする必要があります）、Config と CloudTrail には別々の S3 バケットが用意されるようになりました。ただし、ハブアカウント（Log Archive・Audit）は同じ OU に置く必要があるため、Control Tower の CloudTrail・Config などの統合を使う場合、Log Archive と Audit を別々の OU に分ける B の構成は取れません。B を選ぶ場合は、これらの統合を使わずにログ基盤を自前で構成するなど、Control Tower との役割分担を設計する必要があります。なお、Security OU に Log Archive と Audit の 2 つの共有アカウントを置く構成は、バージョン 3.3 以前の前提です。

また、Control Tower の予防コントロールは SCP・RCP・宣言型ポリシーで実装されます。このうち SCP で実装されるものは Root・OU・アカウントごとの SCP の上限（現在 10 個）を消費します。なお、ランディングゾーン 4.0 からは必須コントロールもデフォルトでは適用されなくなりました。リージョン制限も Control Tower の Region deny コントロールと自作の SCP が重複しやすい項目です。Control Tower を使う場合は、どの統制を Control Tower 側で持ち、どれを自作の SCP で持つかを先に決めておきます。

参考：How AWS Control Tower works／AWS Control Tower release notes: January 2025 - December 2025／Control behavior and guidance - AWS Control Tower／Common causes of failure during registration or re-registration - AWS Control Tower

5. アカウント分離の粒度

基本は 「1 ワークロード × 1 環境 = 1 アカウント」 を最小単位とし、課金・障害・権限・データの境界をそろえることです。

分離を判断する軸は 3 つあります。

• 統制境界： 本番か非本番か／個人情報を含むか／高機密データか一般データか
• 運用境界： プロジェクト・プロダクトの単位／CI/CD パイプラインの所有者／障害の影響範囲（Blast Radius）
• 組織境界： 事業部・グループ会社／内製かベンダー運用か／課金・予算管理の単位

ただし、分離しすぎると管理コストが増えます。「漏えいや誤操作が起きたときに、巻き込まれると困る範囲」がどこまでかを考え、そこを分離の境界線にするのが実践的な判断基準です。

6. SCP 戦略：許可リスト方式か、拒否リスト方式か

どちらの方式を選ぶ場合も、SCP の評価の仕組みを押さえておく必要があります。SCP は Root からアカウントまでの階層ごとに評価され、可能な操作はすべての階層を通過したものだけです。拒否リスト方式ではどこか 1 つの階層で明示的に Deny されれば、下位の階層で許可していても拒否されます。許可リスト方式では許可したいアクションが Root から対象 OU、アカウントまでの経路上のすべての階層で Allow されている必要があります。ある OU にだけ Allow の SCP を付けても上位または下位の階層で許可されていなければ、そのアクションは使えません。

推奨：階層的ハイブリッド方式

どちらか一方を全社に適用するのではなく、OU 階層ごとに「許可基調」と「拒否基調」を使い分けます。さらに SCP では止めにくい「設定状態」や「組織外からのアクセス」は宣言型ポリシーと RCP で補います。

この方式を実装する際は、次の 2 点に注意します。

• リージョン制限 SCP では、グローバルサービスなどを除外する： IAM、CloudFront、Route 53、Organizations、Support など us-east-1 などの特定リージョンのエンドポイントで動くグローバルサービスや公式のリージョン制限 SCP の例で除外対象となっている STS などを NotAction で除外しない場合、国内リージョンでの業務にも影響が出ます（STS にはリージョンごとのエンドポイントもありますが、グローバルエンドポイントを使う処理への影響を避けるため、公式の例では除外されています）。除外するアクションの一覧は、AWS 公式のリージョン制限 SCP の例を出発点にし Policy Staging OU で検証します。
• Security OU を許可リストにする場合は基盤側の実行ロールが使うサービスを許可する： Control Tower や CloudFormation StackSets の実行ロール（AWSControlTowerExecution など）が使うサービスを許可していない場合、ベースラインの適用やコントロールの有効化が失敗します。

7. 運用と拡張

7.1 AWS 新サービスへの対応プロセス

「拒否リスト基調」と「例外的な許可リスト OU」を組み合わせると、運用負担を抑えながら未承認サービスの混入を防げます。

全社に「純粋な許可リスト運用」を課すと、新サービスが出るたびに運用が止まります。純粋な許可リストは Security OU だけにとどめ、ほかの OU は拒否基調にしたうえで、監視による発見的統制で補います。設定状態で守れるもの（VPC のパブリックアクセスブロックや IMDSv2 の強制など）は新しい API が追加されても構成が維持される宣言型ポリシーに寄せることで SCP の保守負担を減らせます。

参考：Simplify governance with declarative policies

7.2 アカウント・プロジェクトの増減に対応するフロー

Account Factory と IaC を使い、「申請 → 払い出し → ベースライン適用 → 廃止」を再現できる形で自動化します。本番と非本番のアカウントは、プロジェクトの開始時に Account Factory で同時に払い出し、それぞれ Prod OU と NonProd OU に配置します。非本番アカウントで検証した変更（コードや設定）を CI/CD で本番アカウントへ反映します。これは本番と非本番のワークロードを別々のアカウント・OU に分離するという AWS の推奨に沿った形です。

アカウントの所属 OU を変えるのは、既存アカウントを取り込むとき（Transitional OU → Workloads OU）、利用を停止するとき（各 OU → Suspended OU）、例外を認める・解消するとき（Exceptions OU への出し入れ）に限ります。

• Account Factory： 申請 → アカウント発行 → OU への配置 → ベースライン適用までを自動化する
• IaC で宣言： OU の所属、SCP・RCP・宣言型ポリシー、IAM Identity Center などを Terraform / CDK で宣言し、Git でレビューする
• タグ駆動のガバナンス： Owner / CostCenter / Environment / DataClass を必須タグにし、SCP の条件にも使う
• 可視化と棚卸し： 四半期ごとに、OU の配置・ポリシー・アカウントの利用状況をダッシュボードでレビューする
• アカウント状態の参照方法： 自動処理でアカウントの状態を判定する場合は DescribeAccount などの応答の State フィールド（ACTIVE・SUSPENDED・PENDING_CLOSURE・CLOSED など）を使う

AWS Control Tower Account Factory for Terraform（AFT）は、アカウント申請の Terraform ファイルを git push するとアカウントの発行とカスタマイズが実行される、GitOps 型の仕組みです。AFT は Control Tower の管理アカウントとは別の AFT 管理アカウントで動き、既存のランディングゾーンが必要です。また、AFT はアカウントの発行とカスタマイズのための仕組みで EC2 インスタンスなどアプリケーションのリソースをデプロイする用途は想定されていません。

参考：Overview of AWS Control Tower Account Factory for Terraform (AFT)／FSISEC08: How do you isolate your software development lifecycle (SDLC) environments? - Financial Services Industry Lens／Workloads and environments - Organizing Your AWS Environment Using Multiple Accounts

7.3 段階的な導入ロードマップ

既存環境からの移行は「壊さない」順序で進めます。最初から完璧を目指さず、Phase ごとに成果を出していきます。

参考：AWS Security Hub is now generally available with near real-time risk analytics（2025年12月）

8. 陥りやすいアンチパターンと対策

Management Account でワークロードを動かす

• なぜダメか： 管理アカウントには SCP も RCP も効かないため、組織のガードレールが一切かかりません。しかも、組織で最も強い権限が集まる場所です。
• 対策： Management Account は課金と組織管理だけに使い、ワークロードは別アカウントに置きます。

本番 OU にいきなりポリシーを適用する

• なぜダメか： バックアップや運用ツールなど、想定外の依存関係を壊し、業務停止に直結します。
• 対策： まず Policy Staging OU（本番の OU 構成を模した子 OU とテストアカウント）で検証します。次に、対象となる本番 OU 内の 1 アカウントに一時的に適用し、CloudTrail の AccessDenied などで問題がないことを確認してから OU 全体に適用します。

ルートの復旧経路を用意せずに Deny する

• なぜダメか： AWS の仕様上、ルートユーザーでしか実行できない操作があります（全プリンシパルを拒否してしまった S3 バケットポリシー・SQS キューポリシーの削除（ロック解除）など）。復旧経路を考えずに止めると緊急時に手詰まりになります。
• 対策： ルート認証情報は一元管理で削除し、ルートが必要な操作は管理アカウント（または委任管理者）からの特権タスク（sts:AssumeRoot）で行います。なお、sts:AssumeRoot はリージョンの STS エンドポイントでのみ呼び出せます（グローバルエンドポイントは非対応）。SCP によるルート操作の禁止と、特権タスクによる復旧経路を組み合わせ、有事訓練で実際に動くことを確認します。ルートユーザーの操作を禁止する Deny ステートメントの対象から特権タスクのセッションを除外するにはグローバル条件キー aws:AssumedRoot を使います（除外されるのはこの Deny だけで、ほかの SCP は特権タスクのセッションにも引き続き効きます）。このキーは AssumeRoot で取得した認証情報によるリクエストにだけ含まれるため、次のように Null 条件で「キーがない（＝通常のルートユーザーによる操作）」場合だけを拒否できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRootUserExceptPrivilegedTasks",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "ArnLike": { "aws:PrincipalArn": "arn:aws:iam::*:root" },
        "Null": { "aws:AssumedRoot": "true" }
      }
    }
  ]
}

特権タスクのセッションで実行できる操作はタスクポリシー（S3UnlockBucketPolicy・SQSUnlockQueuePolicy など）で限定されます。管理アカウント側では、条件キー sts:TaskPolicyArn で使用できるタスクポリシーをさらに絞り込めます。

参考：AWS account root user - IAM／Perform a privileged task on an AWS Organizations member account - IAM／AWS global condition context keys - IAM

純粋な許可リストを全社に強制する

• なぜダメか： 新サービスや依存 API が追加されるたびに業務に影響が出てしまうため、運用が形骸化しがちです。
• 対策： 純粋な許可リストは Security OU だけにとどめ、ほかの OU は Deny 基調にしたうえで検知統制と宣言型ポリシーで補います。

9. まとめ：統制と俊敏性の両立を支える 4 つの軸

1. OU 階層で責務を分ける
   Security / Infrastructure / Workloads / Sandbox / Policy Staging / Transitional / Suspended / Exceptions を基本の骨格にします。
2. ログ機能はアカウントを分け、ポリシーで保護する
   Security OU 内でのアカウント分離から始め、必要に応じて Log Archive OU を分離します。Control Tower ランディングゾーン 4.0 では OU 構成の自由度が上がっています。
3. 階層的ハイブリッドのポリシー設計
   Root は拒否基調、Security OU は許可基調、Workloads は強化した拒否基調にします。そのうえで、設定状態は宣言型ポリシー、組織外からのアクセスは RCP で補います。
4. Account Factory と IaC で再現可能にする
   OU の所属とポリシーはコードで管理し、アカウントの払い出し・取り込み・利用停止をパイプラインで実行します。本番と非本番はアカウントを分け、変更は CI/CD で反映します。

最後に「このサービスについて知りたい」「AWS環境の構築、移行」などのリクエストがございましたら、弊社お問合せフォームまでお気軽にご連絡ください！ のちほど当ブログにてご紹介させていただくか、複雑な内容に関するお問い合わせの内容の場合には直接営業からご連絡を差し上げます。

※Amazon Web Services、”Powered by Amazon Web Services”ロゴ、およびブログで使用されるその他のAWS商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。