developersIO
SCPと許可セットを設計するベストプラクティスについて

SCPと許可セットを設計するベストプラクティスについて

マルチアカウント環境を設計する際にOU,SCP,IICなどのベストプラクティスについて説明する記事です。
AWS OrganizationsAWS IAM Identity CenterAWS
FacebookHatena blogX
2026.02.28

こんにちは、スジェです。

今回担当したプロジェクトで、Organizationを活用した環境設計を担当することになりました。
調査して得た知識を自分なりに整理するため、ブログにまとめてみました。

記事は以下の内容について説明します。

  1. マルチアカウント環境設計のコアコンセプト
  2. OU・SCP設計のベストプラクティス
  3. OU・SCP設計のアンチパターン
  4. IAM Identity Center の概要
  5. IAM Identity Center ユーザーグループ・権限セット設計のベストプラクティス
  6. IAM Identity Center ユーザーグループ・権限セット設計のアンチパターン

1. マルチアカウント環境設計のコアコンセプト

ひとつの組織が複数のアカウントを持ちながら環境を運用していると、ビジネスの成長に伴い、誰がどのリソースを作成したのか、セキュリティ設定は適切か、コストはどのチームで発生しているのかが把握しにくくなります。
このような管理を支援するため、AWSはAWS Organizationsをはじめとするさまざまなサービスと、それに伴うベストプラクティスを提供しています。

しかし多くの方が、Organizationsを導入・運用する際に、OUをどう分けるか、SCPをどう適用するかといった技術的な「どのように（How）」にのみ集中する傾向があります。

私はまず、技術的な内容よりも、マルチアカウント環境を設計するうえで理解すべき3つのコアコンセプトを説明したいと思います。[1]

コンセプト1：影響範囲の最小化（Minimizing Blast Radius）

アカウントを分離することは、コストやセキュリティインシデントの影響範囲を最小化するための最も効果的な第一歩

最も基本的なポイントです。
もしひとつのAWSアカウントにすべての本番・開発・テスト環境が混在していたらどうなるでしょうか？開発環境での小さなミスが本番データベースに影響を与えたり、テスト用リソースの使い忘れで予想外のコスト超過が発生したりする可能性があります。
つまり、ひとつのセキュリティインシデントが会社全体のリソースに影響を及ぼすことになります。

これを調整するのが 「影響範囲（Blast Radius）」 の設定です。

AWSアカウントは、セキュリティ・コスト・リソースに対する最も強力で明確な境界線です。

そのため、ワークロード・環境・チーム・コンプライアンス要件に応じてアカウントを分離することが推奨されます。

Untitled(29) (1)

コンセプト2：多層防御（Defense in Depth）

SCPで大きな枠組みをガードし、IAM権限セットでユーザーの実際の職務に必要な最小限の権限を付与することで、多層防御を構築する

「SCPで許可サービスだけに制限したから、権限セットはPowerUserで渡しても問題ないのでは？」
これは、マルチアカウント設計において最も陥りやすい罠のひとつです。堅牢なセキュリティは複数の防御レイヤーで成り立ちます。
このモデルは「城」に例えることができます。

  1. 外壁 ＝ サービスコントロールポリシー（SCP）：

    • 城全体を取り囲む最も外側の堅固な壁です。
    • この壁は組織全体のセキュリティベースラインを設定しており、誰もこのルールを破ることはできません。

  2. 内部入館証 ＝ IAM権限セット（Permission Set）：

    • 外壁を通過して城の中に入ったとしても、すべての建物に入れるわけではありません。各個人は自分の職務に合った「入館証」を受け取ります。
    • つまり、すべてのユーザーは自分に必要なリソースにのみアクセスできるようにすることが望ましいです。

もし外壁（SCP）だけを信頼して、全員にすべての建物に入れるマスターキー（PowerUserAccess）を配布した場合、外壁に小さな穴が開くだけで城全体が侵攻されてしまいます。
SCPとIAM権限セットという2つの防御レイヤーがそろって初めて安全が確保されます。

Untitled(30)

コンセプト3：役割分離と権限委任

管理アカウントは組織の所有・請求など最小限の役割のみを担い、実際のサービス管理は「委任管理者」アカウントに委任することで、役割を明確に分離することが重要です。

Organizationを作成すると、それを管理する 管理アカウント（Management Account） を指定して運用することになります。
Organizationに関するすべての操作を処理できるスーパーアカウントのようなものですが、日常的な運用には使用しないことが推奨されています。

わかりやすく例えると、CEOと部門長の関係に近いイメージです。

  • 管理アカウント＝CEO
    • 会社を設立し（組織の作成）、部門を作成・廃止し（アカウント・OU管理）、会社全体の資金を管理する（一括請求）最終責任者です。
    • CEOの印鑑（ルートユーザー認証情報）は金庫に安全に保管し、極めて限定的な場合にのみ使用すべきです。
  • 委任管理者アカウント（Delegated Administrator）＝部門長
    • CEOは各分野の専門家である部門長に業務を委任します。
      • 「会社全体のセキュリティ管理はセキュリティチームリーダーに任せる」「社員の入館証管理は人事チームリーダーに任せる」など
    • 同様に、管理アカウントはGuardDuty・Security Hub・IAM Identity CenterなどのサービスのADMIN権限を特定のメンバーアカウントに委任できます。
      • たとえば、セキュリティ関連サービスはSecurity-Toolingアカウントに委任するなど
    • 各委任管理者は、担当するサービスについて日常的な運用を自律的に行います。
    • 各サービスには委任管理者を1つ指定でき、サービスごとに異なるアカウントを委任管理者として設定できます。

このモデルは、管理アカウントの露出を最小化してセキュリティを最大化し、各チームが専門性を発揮して効率的に運用 できる体制を実現します。

実際の導入時にはすべてを考慮するのが難しい

上記で説明しましたコアコンセプトを理解して設計時に考慮すべき」だということは、頭では理解できます。
しかし、実際に環境を設計・構築する際、最初からすべてを反映させるのは難しいのが現実です。[2]
この点を踏まえ、初めてマルチアカウント環境を構築する際にどのように段階的に整えていけばよいかについても記載します。

2.OU・SCP設計のベストプラクティス

堅牢なOU構造は、明確な役割分離と拡張性を基盤としています。
マルチアカウント環境を設計するうえで、AWSは以下のような機能ベースのOU構造を出発点として推奨しています。

1.機能ベースのOU構造を設計する

アカウントを単純にチーム名やプロジェクト名で並べるのではなく、各OUがどのような「機能」を担うかを基準に構造を設計すべきです。

AWSのベストプラクティスブログによると、以下のような構造が推奨されています。

blog4

組織のOU設計において最優先されるのは、SecurityOU と Infrastructure OUです。
この2つを合わせて FoundationOU（基礎OU） と呼びます。

  • Security OU：組織のセキュリティを担う「監視塔」です。すべてのアカウントのログ（CloudTrail）を一元収集するLog-Archiveアカウントと、セキュリティサービス（GuardDuty・Security Hub）を管理し監査を行うSecurity-Toolingアカウントを配置します。このOUには最も厳格なSCPとアクセス制御が適用される必要があります。
  • Infrastructure OU：組織全体に共通して提供するインフラサービスを管理します。たとえば、外部とのネットワーク接続を担うTransit Gatewayなどを含むNetworkアカウントや、全アカウントで共有するネットワーク以外のサービスを管理するSharedInfraアカウントがここに属します。

基礎OUを作成した後、その他の環境で使用するOUを作成します。
例として、以下のようなOUを作成することができます。

  • Workloads OU：実際のサービスが稼働するすべてのアカウントを含みます。さらにProd（本番）とDev（開発）のサブOUに分離し、本番環境にはより強力な保護ポリシーを適用できます。
  • Sandbox OU：開発者がAWSの新しいサービスを自由に実験・学習できるスペースです。このOUのアカウントは本番ネットワークと完全に分離し、コスト超過を防ぐための予算アラートを設定することが重要です。
  • Policy Staging OU：組織管理者がOU設定やSCPなどをテスト・検証するために使用するOUです。

その他推奨される追加OUについては、公式ドキュメントをご参照ください。

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous_best_practices.html

2.SCPは「ブラックリスト（＝拒否リスト（Deny List））」として活用する

「基本的にすべてを許可し（FullAWSAccess）、絶対に発生させてはならない危険な行為だけを明示的に拒否（Deny）する」 という「ブラックリスト（拒否リスト）」方式のことです。

なぜブラックリスト方式が良いのか？

  • 俊敏性（Agility）： AWSで新しいサービスや機能がリリースされた際、開発者はSCPの変更なしにすぐ試すことができます。組織のイノベーション速度を妨げません。
  • 管理のしやすさ： 許可すべき多数のサービスを列挙するより、禁止すべきいくつかの重要なリスクだけを管理する方が、はるかにシンプルでミスが少なくなります。
    必ず追加すべきDeny SCPの例：
  1. 組織の根幹を守る：
    • メンバーアカウントが組織から無断で脱退することを防止（organizations:LeaveOrganization）
    • 中央監査ログ（CloudTrail）が停止・削除されることを防止（cloudtrail:StopLogging、cloudtrail:DeleteTrail）
  2. セキュリティベストプラクティスの強制：
    • ルートユーザーのアクセスキー作成を禁止（iam:CreateAccessKey on Root）
    • デフォルトVPCではなく、意図的に設計されたVPCのみを使用するよう強制（ec2:DeleteVpc on Default VPC）
  3. リージョンガバナンス：
    • 許可されていないリージョン（Region）でのリソース作成を防止（* on Not aws:RequestedRegion）
      これらのSCPを各OUの特性に合わせて適用・追加することが望ましいです。
      たとえば、Prod OUにはより厳しいルールを、Sandbox OUには比較的緩やかなルールを適用することができます。

また、アカウントで使用できる権限はSCPとIAMを組み合わせた結果になるため、ポリシー評価ロジックを把握しておくことが重要です。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_evaluation-logic.html

このロジックを理解すると、SCPは権限を付与しないということがわかります。
つまり、SCPは権限を確認する「フィルター」として捉えることができます。

また、ある操作を許可するためには、以下の各要素において明示的な許可が必要です。

  • AWSアカウント自体
  • AWSアカウント上位のOU
  • 組織のルート

つまり、明示的な許可がなければ拒否されます。これは権限モデルがデフォルトで拒否（暗黙的拒否）であることを意味します。
もちろん、明示的な拒否がある場合は他の場所で許可していても拒否（＝明示的拒否が優先）されます。

(補足)SCPの設計が難しい場合

実際にSCPを設定していると、推奨されるサービスは制限したものの、その後どのように修正していけばよいかわからない場合があります。
また、コンセプト2でも示したとおり、AWS環境では最小権限が推奨されているため、不要なサービスは制限するのが望ましいです。

ただし、どのサービスが必要で不要かを把握するのが難しいため、IAM Access Analyzerを活用してレビューすることを推奨します。
https://aws.amazon.com/jp/iam/access-analyzer/

私自身も最初は推奨事項や明らかに不要なサービスについてSCPで権限を制限し、その後の検証フェーズで実際に使用しながら不要な権限を段階的に制限していく方法でSCPを最適化しました。

組織で活用する際は、以下の記事も参考にしてください。
https://dev.classmethod.jp/articles/introduction-2024-aws-iam-access-analyzer/

3.OU・SCP設計のアンチパターン

反対に、アンチパターンを把握してこれを回避することで、安全な環境を構築できます。

1.フラット（Flat）なOU構造

すべてのアカウントをRootの直下に並べる方式です。

blog3

この構成の問題点は以下のとおりです。[3]

  • ポリシー管理の困難さ： 本番環境と開発環境に異なるSCPを適用したい場合、各アカウントに個別にポリシーを紐付ける必要があります。アカウントが数十・数百と増えると管理が不可能になります。
  • スケーラビリティの欠如： 新しい環境（例：Staging、QA）や部門が追加されるたびに、全体の構造が複雑化します。

2.深すぎる・複雑すぎるOU構造

組織の部門構造をそのままOUに反映し、10段階以上の深い構造を作るケースです。

この構成の問題点は以下のとおりです。

  • 権限問題の解決が困難： あるユーザーが特定の操作を実行できない場合、Rootから該当アカウントまですべてのOUに適用されたSCPをひとつひとつ確認しなければ原因を特定できません。問題解決に要する時間が急増します。
  • 管理の複雑化： 不必要に複雑な構造は管理ポイントを増やし、ミスを誘発します。

推奨事項としては、OUの深さは3〜4段階を超えないよう、シンプルに保つことが望ましいです。

3.SCPを「ホワイトリスト（＝許可リスト（Allow List））」として使用する

ホワイトリスト方式もSCP戦略のひとつです。
**「基本的にすべてを禁止し、使用するサービスのみを明示的に許可（Allow）する」**という方式です。

ホワイトリスト方式の問題点は以下のとおりです。

  • 低い俊敏性： 開発者が新しいAWSサービスを使いたい場合、常に管理者にSCPの変更を依頼しなければなりません。組織の技術導入スピードを著しく妨げます。
  • メンテナンスの困難さ： AWSは絶えず新しい機能やサービスをリリースしています。そのすべてを把握して許可リストに追加し続けることは、現実的にほぼ不可能です。また、サービス間の隠れた依存関係を把握できていないと、意図せずサービスが動作しなくなる問題が発生します。
  • セキュリティの誤解： 許可リストの方が安全だと思いがちですが、管理者が誤って広い範囲（ec2:*など）を許可した瞬間、そのポリシーが適用されたすべてのアカウントのセキュリティが一度に崩壊します。

つまり、維持管理コストが非常に高くなります。
特に「本来アクセスしたいアクションの記載漏れによりアクセスできない」という状況が実際の運用中に頻繁に発生します。

4.IAM Identity Center 概要

IAM Identity Center とは？

IAM Identity Center（旧 AWS SSO）は、マルチアカウント環境において中央で人のアクセスを管理するサービスです。

わかりやすく言えば「会社ビルの統合入館証発行センター」とイメージすると良いでしょう。
社員が各フロア（AWSアカウント）に入るために、どのフロアにどのような権限で入れるかを統合入館証に記載して発行する仕組みです。

Untitled(32) (2)

主な構成要素は以下のとおりです：

構成要素 説明
Identity Store / 外部 IdP ユーザー情報を保存、またはOkta・Azure ADなど外部IdPと連携
ユーザー & グループ ユーザーを役割ごとにまとめる単位
権限セット（Permission Set） 「この役割はこのような権限を持つ」というIAMポリシーテンプレート
アカウント割り当て（Account Assignment） 「このグループに、このアカウントで、この権限セットを許可する」という接続設定

インスタンスタイプ：組織インスタンス vs アカウントインスタンス

IAM Identity Centerには2種類のインスタンスタイプがあります。
マルチアカウント環境を扱うこの記事の文脈では、組織インスタンスが前提となります。

区分 組織インスタンス アカウントインスタンス
有効化場所 AWS Organizations 管理アカウント 単一AWSアカウント
AWSアカウントのアクセス管理 対応 非対応
SAML 2.0 アプリケーション 対応 非対応
委任管理者設定 可能 不可
用途 マルチアカウント統合アクセス管理 AWS管理型アプリ（例：QuickSight）専用

アカウントインスタンスは2023年11月に追加されたタイプで、単独アカウントでAmazon QuickSightなどAWS管理型アプリケーションへのアクセスのみが必要な場合に使用します。マルチアカウントのアクセス管理が目的であれば、必ず組織インスタンスを使用する必要があります。

IDソース（Identity Source）のタイプ

ユーザー情報をどこから取得するかによって、3つの方式を選択できます。

IDソース 説明 特徴
Identity Center ディレクトリ IAM Identity Center 内蔵のユーザーストア 別途IdPなしですぐ利用可能。小規模または初期設定に適している
Active Directory AWS Managed Microsoft AD または AD Connector との連携 既存のオンプレミスADをそのまま活用可能
外部 IdP（SAML 2.0） Okta・Microsoft Entra ID・Google Workspace などと連携 企業IdPを中央認証ソースとして維持可能

外部IdP連携時のユーザー・グループ同期方式も2種類あります：

  • 自動プロビジョニング（SCIM）：IdPでのユーザー・属性変更がIAM Identity Centerに自動同期されます。組織規模が大きい、またはメンバーの変動が多い場合に適しています。
  • 手動プロビジョニング：IdPと同じユーザーをIAM Identity Centerに手動で作成します。小規模または連携設定が複雑な場合に選択する方式です。

SCPとIAM Identity Centerの関係

マルチアカウントのコンセプト２ででまとめたとおり、SCPは 「これだけは絶対にダメ」 という組織単位のガードレールであり、
IAM Identity Centerの権限セットは 「この人はここまでできる」 という個人・グループ単位の許可範囲です。

この2つのレイヤーが連携することで多層防御を形成します。

5.ユーザーグループ・権限セット設計のベストプラクティス

1.個人ではなくグループに権限を割り当てる

ユーザー一人ひとりに権限セットを直接割り当てると、メンバーが変わるたびに手作業が必要になります。
グループに権限を割り当てれば、オンボーディング・オフボーディングはグループメンバーシップの変更だけで完結します。

2.職務（Job Function）を基準にグループと権限セットを設計する

職務別にグループと権限セットを対応させることで、誰がどの権限を持っているかが一目で把握できます。

3.環境（dev/stg/prod）に応じて権限レベルを分ける

同じ「開発者」の役割でも、devアカウントでは柔軟な権限を付与できますが、
prodアカウントでは最小権限の原則を厳格に適用する必要があります。

グループ devアカウント stgアカウント prodアカウント
Developer PowerUser ReadOnly ReadOnly
Ops PowerUser PowerUser LimitedAdmin
Security SecurityAudit SecurityAudit SecurityAudit

4.権限セットはAWS Managed Policyを優先活用する

カスタムインラインポリシーは管理負担が大きくなります。
PowerUserAccess・ReadOnlyAccess・SecurityAuditなどAWS管理ポリシーをベースとし、
必要な場合のみCustomer Managed Policyで補完する戦略がメンテナンスに有利です。

権限セットは以下の4つの要素で構成できます：

構成要素 説明
AWS管理ポリシー AWSが管理する事前定義済みポリシー
カスタマー管理ポリシー 自分で作成したアカウント内IAMポリシー
インラインポリシー 権限セットに直接含まれるポリシー（権限セット削除時に一緒に削除）
権限境界（Permission Boundary） この権限セットが許可できる最大権限の上限

特に権限境界は権限セットにどれだけ広いポリシーを付与しても、境界外の権限は実際には行使できないように制限する安全装置です。たとえば開発者にPowerUserAccessを付与しながらも、権限境界で特定のリージョンやサービスのみを許可するよう絞り込む際に活用できます。

注意：IAM Roleのポリシー添付上限に制約される

権限セットに紐付けるポリシーは、IAM Identity Center側の上限と実際にプロビジョニングされるIAM Role側の上限という2つのレイヤーの制約を同時に受けます。[4]

制限レイヤー 管理型ポリシー数 インラインポリシーサイズ 増設可否
Permission Set 側 最大25個 10,240文字（空白除く） ❌ 不可
IAM Role 側 最大 25個
デフォルト：10個		 10,240文字（空白除く） ✅ 可能

Permission Setが管理型ポリシーを最大25個まで許容していても、権限セットをプロビジョニングする際に対象アカウントに作成されるIAM Roleのデフォルト上限が10個であるため、実質的に10個が実際の上限となります。11個以上の管理型ポリシーを紐付けるとプロビジョニング自体が失敗します。

5.権限セットのセッション時間を環境に合わせて設定する

prodアカウントほどセッション時間を短く設定し、認証情報の窃取リスクを軽減することが望ましいです。

環境 推奨セッション時間
dev 8時間
stg 4時間
prod 1時間

6.委任管理者を使用する場合は管理アカウント用の権限セットを分離する

IAM Identity Centerはセキュリティ上、管理アカウント以外のアカウント（例：セキュリティ専用アカウント）に管理権限を委任することができます。
ただし、委任管理者には2つの重要な制限があります。

制限1. 委任管理者は、管理アカウントにすでにプロビジョニングされた権限セットを変更できません。
（AWS原文: "The delegated administrator can't alter permission sets provisioned in the management account."）

制限2. 管理アカウント用の権限セットには、グループではなく個人ユーザーのみを直接割り当てる必要があります。
グループを割り当てると、IdP管理者やAD管理者がグループメンバーシップを変更するだけで、管理アカウントへのアクセス権限が意図せず拡大する可能性があるためです。

この2つの制限を考慮すると、管理アカウント用の権限セットと一般メンバーアカウント用の権限セットを最初から分けておくことが、運用上はるかにシンプルになります。

権限セットカテゴリ 割り当て方式 管理主体
管理アカウント用権限セット 個人ユーザーのみ直接割り当て 管理アカウント管理者のみ変更可
メンバーアカウント用権限セット グループベース割り当て推奨 委任管理者アカウントから管理可能

6. ユーザーグループ・権限セット設計のアンチパターン

1. 個人への直接権限割り当て

「この人だけ特別に…」という例外処理が積み重なると、全体の権限構造の把握が不可能になります。
例外が増えるほど、オンボーディング・オフボーディング時の漏れ事故につながるリスクが高まります。
グループを通じた割り当てを、ぜひ運用の原則としていただければと思います。

2. 権限セットの乱立（Permission Set Sprawl）

似たような権限セットを微妙に異なる形で作り続けると、
いつの間にかどの権限セットが何のためのものかわからなくなります。

権限セットは明確な命名規則とともに、最小限の種類に維持することが重要です。

3.全アカウントへのAdministratorAccessの乱用

「とりあえず作業しやすいように」と全員に管理者権限を付与するケースがあります。
これはSCPでガードレールをいくら丁寧に設計しても、結局内部ですべてを許可する構造になってしまいます。
最小権限の原則は、利便性よりセキュリティを優先する組織文化から始まります。

4.OU構造と権限セット割り当ての不一致

OUでアカウントをdev/stg/prodに分けているにもかかわらず、
権限セットの割り当てをアカウントごとに個別管理している場合、運用の複雑度が急激に増加します。

OU構造と権限セット割り当て戦略が一致しているほど運用がシンプルになり、障害発生時の原因特定も速くなります。

まとめ

SCP設計とIAM Identity Center設計が組み合わさることで、
マルチアカウント環境のセキュリティと運用効率の両方を実現できると考えます。

最初から完璧に適用するのが難しいのが現実ですが、
この記事が設計方針を決める際の一助になれば幸いです。

長文をお読みいただきありがとうございました。
誤字・脱字や内容に関するご指摘はいつでも歓迎いたします。

脚注

  1. つまり、なぜ（Why）について説明したいと思います ↩︎

  2. 導入後に環境の変化がほとんどないと予想される場合は、最初から考慮して設計することも可能です ↩︎

  3. OUを使う理由と同じです ↩︎

  4. 詳細な内容はドキュメントをご参照ください。 ↩︎

この記事をシェアする

FacebookHatena blogX

関連記事

[登壇レポート] AWS Organizationsのユースケースで学ぶ AWSアカウント管理のベストプラクティス「AWS Organizationsでマルチアカウント戦略を始めよう」という内容で登壇しました
板倉舞
2025.09.21
個人AWS環境をマルチアカウント化して、IAMロールスイッチを試してみた
はすと ( sasaki hasuto )
2026.01.29
【AWS Organizations】 管理アカウントにはSCPが適用されません
あしざわ
2025.05.30
【AWS中級へのステップ】ACL 無効化時代の S3 へのクロスアカウントアクセス 2 選
m.hayakawa
2026.02.13