サービスコントロールポリシー（SCP）でアカウント権限を制御する

AWS Organizationsでマルチアカウント環境を構築した後、次に必要なのが組織全体のセキュリティガードレールの設計です。サービスコントロールポリシー（SCP）は、組織内のアカウントに対して「できること」の上限を設定する強力なツールです。本記事では、SCPの概念から実践的な使用パターン、設計のベストプラクティスまでを体系的に解説します。

サービスコントロールポリシー（SCP）とは

サービスコントロールポリシー（Service Control Policy、SCP）は、AWS Organizations内のアカウントやOU（組織単位）に対して、利用可能なAWSサービスとアクションの最大範囲を定義するポリシーです。

SCPの基本概念

SCPは「許可を与える」ものではなく、「許可の上限を設定する」ものです。アカウント内のIAMユーザーやロールが実際にアクションを実行するには、SCPで許可されている範囲内で、かつIAMポリシーでも明示的に許可されている必要があります。

flowchart TB
    subgraph "権限の関係"
        SCP[SCP<br/>許可の上限を設定]
        IAM[IAMポリシー<br/>実際の権限を付与]
        RESULT[実行可能な操作<br/>両方の共通部分]
    end
    
    SCP --> RESULT
    IAM --> RESULT

この概念を「フィルター」に例えると理解しやすくなります。SCPは組織レベルのフィルターであり、IAMポリシーによる許可がSCPのフィルターを通過した場合にのみ、アクションが許可されます。

SCPとIAMポリシーの違い

SCPとIAMポリシーは構文が似ていますが、役割と適用範囲が大きく異なります。

比較項目	SCP	IAMポリシー
適用対象	アカウント、OU	IAMユーザー、ロール、グループ
役割	許可の上限（ガードレール）	実際の権限付与
効果	許可を制限するが、付与はしない	許可を付与する
適用範囲	アカウント内のすべてのプリンシパル	指定されたプリンシパルのみ
管理者	Organizations管理者	アカウント管理者

SCPの特徴と制約

SCPには以下の特徴と制約があります。

適用対象

メンバーアカウントに適用される
管理アカウントには適用されない（重要）
ルートユーザーを含むすべてのプリンシパルに影響

適用されないケース

管理アカウント自体
サービスリンクロール
リソースベースのポリシーで許可された外部プリンシパルからのアクセス

flowchart TB
    subgraph "SCPの適用範囲"
        direction TB
        subgraph "適用される"
            M1[メンバーアカウントの<br/>IAMユーザー]
            M2[メンバーアカウントの<br/>IAMロール]
            M3[メンバーアカウントの<br/>ルートユーザー]
        end
        
        subgraph "適用されない"
            MA[管理アカウント]
            SLR[サービスリンクロール]
            EXT[外部からの<br/>リソースベースアクセス]
        end
    end

SCPの継承と評価ロジック

SCPの効果を正しく理解するには、継承の仕組みと評価ロジックを把握する必要があります。

継承の仕組み

SCPは、組織のルートからOU、そしてアカウントへと階層的に継承されます。

flowchart TB
    ROOT[Root<br/>SCP: FullAWSAccess]
    
    OU1[Production OU<br/>SCP: DenyRiskyServices]
    OU2[Development OU<br/>SCP: AllowDevelopment]
    
    ACC1[本番アカウント A<br/>SCP: DenyDeleteLogs]
    ACC2[本番アカウント B]
    ACC3[開発アカウント]
    
    ROOT --> OU1
    ROOT --> OU2
    OU1 --> ACC1
    OU1 --> ACC2
    OU2 --> ACC3

本番アカウント Aには以下のSCPが適用されます。

Root の FullAWSAccess
Production OU の DenyRiskyServices
アカウント自身の DenyDeleteLogs

有効なポリシーの計算

継承されたすべてのSCPの共通部分（AND条件）が、そのアカウントで許可される操作の上限となります。

flowchart LR
    subgraph "継承されたSCP"
        P1[Root SCP<br/>すべて許可]
        P2[OU SCP<br/>特定サービス拒否]
        P3[アカウント SCP<br/>特定アクション拒否]
    end
    
    P1 --> |AND| EFFECTIVE[有効なポリシー<br/>共通部分のみ許可]
    P2 --> |AND| EFFECTIVE
    P3 --> |AND| EFFECTIVE

評価ロジックの詳細

AWSのポリシー評価において、SCPは以下の位置で評価されます。

flowchart TD
    A[リクエスト開始] --> B{明示的なDenyが<br/>いずれかのポリシーに<br/>あるか?}
    B -->|Yes| C[アクセス拒否]
    B -->|No| D{すべての継承SCPで<br/>許可されているか?}
    D -->|No| C
    D -->|Yes| E{Permission Boundary<br/>で許可されているか?}
    E -->|No| C
    E -->|Yes| F{IAMポリシーで<br/>許可されているか?}
    F -->|No| G{リソースベースポリシーで<br/>許可されているか?}
    G -->|No| C
    G -->|Yes| H[アクセス許可]
    F -->|Yes| H

SCPは、Permission BoundaryやIAMポリシーよりも先に評価されます。SCPで拒否されているアクションは、他のポリシーで許可されていても実行できません。

FullAWSAccessポリシー

Organizations作成時、デフォルトでFullAWSAccessポリシーがルートにアタッチされます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

このポリシーは「すべてを許可する」という意味ではなく、「SCPによる制限を追加しない」という意味です。このポリシーを削除すると、すべてのアクションが暗黙的に拒否されます。

SCP設計のアプローチ

SCPの設計には、主に2つのアプローチがあります。

許可リスト（Allow List）方式

許可するサービスとアクションを明示的にリストし、それ以外をすべて拒否するアプローチです。

flowchart LR
    subgraph "許可リスト方式"
        DEFAULT[デフォルト: すべて拒否]
        ALLOW[許可リストに<br/>あるもののみ許可]
    end
    
    DEFAULT --> ALLOW

メリット

セキュリティが非常に高い
新しいサービスはデフォルトで拒否される

デメリット

管理が複雑
新しいサービス利用時に都度更新が必要
FullAWSAccessポリシーの削除が必要

実装例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSpecificServices",
            "Effect": "Allow",
            "Action": [
                "ec2:*",
                "s3:*",
                "rds:*",
                "lambda:*",
                "cloudwatch:*",
                "logs:*"
            ],
            "Resource": "*"
        }
    ]
}

拒否リスト（Deny List）方式

デフォルトですべてを許可し、禁止したいサービスやアクションを明示的に拒否するアプローチです。

flowchart LR
    subgraph "拒否リスト方式"
        DEFAULT[デフォルト: すべて許可<br/>FullAWSAccess]
        DENY[拒否リストに<br/>あるものを除外]
    end
    
    DEFAULT --> DENY

メリット

管理がシンプル
新しいサービスを柔軟に利用可能
段階的な導入が容易

デメリット

新しいサービスがデフォルトで許可される
想定外のサービス利用のリスク

推奨: ほとんどの組織では、拒否リスト方式から始めることを推奨します。FullAWSAccessをベースに、禁止事項をSCPで追加していきます。

よく使われるSCPパターン

実践的なSCPの使用パターンを紹介します。これらは組み合わせて使用することで、組織のセキュリティ要件を満たすガードレールを構築できます。

パターン1: リージョン制限

特定のリージョンでのみAWSサービスの使用を許可するSCPです。コンプライアンス要件やデータ主権の観点で重要です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllOutsideAllowedRegions",
            "Effect": "Deny",
            "NotAction": [
                "a]4b:*",
                "acm:*",
                "aws-marketplace-management:*",
                "aws-marketplace:*",
                "aws-portal:*",
                "budgets:*",
                "ce:*",
                "chime:*",
                "cloudfront:*",
                "config:*",
                "cur:*",
                "directconnect:*",
                "ec2:DescribeRegions",
                "ec2:DescribeTransitGateways",
                "ec2:DescribeVpnGateways",
                "fms:*",
                "globalaccelerator:*",
                "health:*",
                "iam:*",
                "importexport:*",
                "kms:*",
                "mobileanalytics:*",
                "networkmanager:*",
                "organizations:*",
                "pricing:*",
                "route53:*",
                "route53domains:*",
                "route53-recovery-cluster:*",
                "route53-recovery-control-config:*",
                "route53-recovery-readiness:*",
                "s3:GetAccountPublic*",
                "s3:ListAllMyBuckets",
                "s3:ListMultiRegionAccessPoints",
                "s3:PutAccountPublic*",
                "shield:*",
                "sts:*",
                "support:*",
                "trustedadvisor:*",
                "waf-regional:*",
                "waf:*",
                "wafv2:*",
                "wellarchitected:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "ap-northeast-1",
                        "ap-northeast-3"
                    ]
                }
            }
        }
    ]
}

NotActionで除外しているのは、グローバルサービス（IAM、Route 53、CloudFrontなど）です。これらはリージョンに依存せず、除外しないと正常に動作しません。

パターン2: 特定サービスの禁止

リスクの高いサービスや、組織で使用を禁止しているサービスをブロックします。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyRiskyServices",
            "Effect": "Deny",
            "Action": [
                "lightsail:*",
                "gamelift:*",
                "appstream:*",
                "mechanicalturk:*",
                "ground-station:*"
            ],
            "Resource": "*"
        }
    ]
}

パターン3: ルートユーザーの使用禁止

メンバーアカウントでのルートユーザー使用を禁止し、IAMユーザーまたはロールの使用を強制します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyRootUser",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "StringLike": {
                    "aws:PrincipalArn": "arn:aws:iam::*:root"
                }
            }
        }
    ]
}

パターン4: CloudTrailの保護

監査ログを改ざんや削除から保護するSCPです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyCloudTrailModification",
            "Effect": "Deny",
            "Action": [
                "cloudtrail:DeleteTrail",
                "cloudtrail:StopLogging",
                "cloudtrail:UpdateTrail",
                "cloudtrail:PutEventSelectors"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotLike": {
                    "aws:PrincipalArn": [
                        "arn:aws:iam::*:role/OrganizationAdminRole"
                    ]
                }
            }
        }
    ]
}

Conditionを使用して、特定の管理者ロールからの操作は許可しています。

パターン5: S3パブリックアクセスの禁止

S3バケットの意図しないパブリック公開を防止します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyS3PublicAccess",
            "Effect": "Deny",
            "Action": [
                "s3:PutBucketPublicAccessBlock",
                "s3:DeletePublicAccessBlock"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotLike": {
                    "aws:PrincipalArn": [
                        "arn:aws:iam::*:role/SecurityAdminRole"
                    ]
                }
            }
        },
        {
            "Sid": "DenyS3PublicACLs",
            "Effect": "Deny",
            "Action": [
                "s3:PutBucketAcl",
                "s3:PutObjectAcl"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": [
                        "public-read",
                        "public-read-write",
                        "authenticated-read"
                    ]
                }
            }
        }
    ]
}

パターン6: VPCの保護

デフォルトVPCの削除やインターネットゲートウェイの操作を制限します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyVPCChanges",
            "Effect": "Deny",
            "Action": [
                "ec2:CreateInternetGateway",
                "ec2:AttachInternetGateway",
                "ec2:CreateVpcPeeringConnection",
                "ec2:AcceptVpcPeeringConnection"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotLike": {
                    "aws:PrincipalArn": [
                        "arn:aws:iam::*:role/NetworkAdminRole"
                    ]
                }
            }
        }
    ]
}

パターン7: 組織離脱の禁止

メンバーアカウントが組織から離脱することを防止します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyLeaveOrganization",
            "Effect": "Deny",
            "Action": "organizations:LeaveOrganization",
            "Resource": "*"
        }
    ]
}

パターン8: 必須タグの強制

リソース作成時に特定のタグを必須とするSCPです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyEC2WithoutTags",
            "Effect": "Deny",
            "Action": [
                "ec2:RunInstances",
                "ec2:CreateVolume"
            ],
            "Resource": [
                "arn:aws:ec2:*:*:instance/*",
                "arn:aws:ec2:*:*:volume/*"
            ],
            "Condition": {
                "Null": {
                    "aws:RequestTag/CostCenter": "true"
                }
            }
        },
        {
            "Sid": "DenyEC2WithoutEnvironmentTag",
            "Effect": "Deny",
            "Action": [
                "ec2:RunInstances",
                "ec2:CreateVolume"
            ],
            "Resource": [
                "arn:aws:ec2:*:*:instance/*",
                "arn:aws:ec2:*:*:volume/*"
            ],
            "Condition": {
                "Null": {
                    "aws:RequestTag/Environment": "true"
                }
            }
        }
    ]
}

パターン9: 高額インスタンスタイプの制限

コスト管理のため、高額なEC2インスタンスタイプの起動を制限します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyLargeInstances",
            "Effect": "Deny",
            "Action": "ec2:RunInstances",
            "Resource": "arn:aws:ec2:*:*:instance/*",
            "Condition": {
                "ForAnyValue:StringLike": {
                    "ec2:InstanceType": [
                        "*.metal",
                        "*.24xlarge",
                        "*.16xlarge",
                        "*.12xlarge",
                        "p3*",
                        "p4*",
                        "x1*",
                        "x2*"
                    ]
                }
            }
        }
    ]
}

パターン10: 暗号化の強制

EBSボリュームの暗号化を強制するSCPです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyUnencryptedVolumes",
            "Effect": "Deny",
            "Action": "ec2:CreateVolume",
            "Resource": "*",
            "Condition": {
                "Bool": {
                    "ec2:Encrypted": "false"
                }
            }
        },
        {
            "Sid": "DenyUnencryptedVolumeInRunInstances",
            "Effect": "Deny",
            "Action": "ec2:RunInstances",
            "Resource": "arn:aws:ec2:*:*:volume/*",
            "Condition": {
                "Bool": {
                    "ec2:Encrypted": "false"
                }
            }
        }
    ]
}

SCPの作成と適用手順

SCPを作成し、組織に適用する手順を解説します。

マネジメントコンソールでの作成

AWS Organizationsコンソールを開く
左側のナビゲーションで「ポリシー」を選択
「サービスコントロールポリシー」を選択
「ポリシーを作成」をクリック
ポリシー名、説明、JSONを入力
「ポリシーを作成」をクリック

AWS CLIでの作成

1
2
3
4
5
6


# SCPの作成
aws organizations create-policy \
  --name "DenyRiskyServices" \
  --description "Deny access to risky AWS services" \
  --type SERVICE_CONTROL_POLICY \
  --content file://deny-risky-services.json

SCPのアタッチ

作成したSCPをOUまたはアカウントにアタッチします。

1
2
3
4
5
6
7
8
9


# OUへのアタッチ
aws organizations attach-policy \
  --policy-id p-xxxxxxxxxx \
  --target-id ou-xxxx-xxxxxxxx

# アカウントへのアタッチ
aws organizations attach-policy \
  --policy-id p-xxxxxxxxxx \
  --target-id 123456789012

SCPの確認

現在適用されているSCPを確認します。

1
2
3
4
5
6
7
8


# ターゲットにアタッチされているポリシーの一覧
aws organizations list-policies-for-target \
  --target-id ou-xxxx-xxxxxxxx \
  --filter SERVICE_CONTROL_POLICY

# ポリシーの内容を表示
aws organizations describe-policy \
  --policy-id p-xxxxxxxxxx

SCP設計のベストプラクティス

効果的なSCPを設計するためのベストプラクティスを紹介します。

段階的な導入

SCPは即座に効果を発揮するため、慎重に導入する必要があります。

flowchart LR
    S1[Policy Staging OU<br/>でテスト] --> S2[Sandbox OU<br/>に適用]
    S2 --> S3[Development OU<br/>に適用]
    S3 --> S4[Production OU<br/>に適用]

Policy Staging OUで新しいSCPをテスト
Sandbox OUで影響範囲を確認
Development OUで実運用に近い環境でテスト
Production OUに本番適用

ドライラン的なテスト

SCPをアタッチする前に、CloudTrailログを分析して影響を予測します。

1
2
3
4
5


# 直近7日間のAPI呼び出しを分析（例：lightsailの使用状況）
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=lightsail.amazonaws.com \
  --start-time $(date -d '7 days ago' -Iseconds) \
  --end-time $(date -Iseconds)

緊急時の除外ロール

すべてのSCPには、緊急時に使用できる除外ロール（Break Glass Role）を設定することを推奨します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenySomething",
            "Effect": "Deny",
            "Action": "...",
            "Resource": "*",
            "Condition": {
                "StringNotLike": {
                    "aws:PrincipalArn": [
                        "arn:aws:iam::*:role/BreakGlassRole",
                        "arn:aws:iam::*:role/OrganizationAdminRole"
                    ]
                }
            }
        }
    ]
}

命名規則とバージョン管理

SCPには一貫した命名規則を適用し、バージョン管理システムで管理します。

命名パターン	説明	例
scp-deny-[対象]	特定のアクションを拒否	scp-deny-risky-services
scp-require-[条件]	特定の条件を必須化	scp-require-encryption
scp-restrict-[対象]	対象の範囲を制限	scp-restrict-regions

バージョン管理の例（Gitリポジトリ構成）

scp-policies/
├── deny/
│   ├── scp-deny-risky-services.json
│   ├── scp-deny-root-user.json
│   └── scp-deny-leave-organization.json
├── require/
│   ├── scp-require-encryption.json
│   └── scp-require-tags.json
├── restrict/
│   ├── scp-restrict-regions.json
│   └── scp-restrict-instance-types.json
└── README.md

SCPのサイズ制限への対応

SCPには5,120文字のサイズ制限があります。大きなポリシーは分割が必要です。

制限項目	値
ポリシーの最大サイズ	5,120文字
ルートまたはOUにアタッチできる最大SCP数	5個
アカウントに直接アタッチできる最大SCP数	5個

対処法

複数のSCPに分割する
不要な空白を削除してコンパクトにする
類似したステートメントをワイルドカードで統合

OU構造との連携

SCPはOU構造と密接に連携させて設計します。

flowchart TB
    ROOT[Root<br/>SCP: 基本ガードレール<br/>・組織離脱禁止<br/>・CloudTrail保護]
    
    SEC[Security OU<br/>SCP: 最小限の制限]
    INFRA[Infrastructure OU<br/>SCP: ネットワーク操作許可]
    
    WORKLOAD[Workloads OU<br/>SCP: 標準的な制限<br/>・リージョン制限<br/>・高額インスタンス制限]
    
    PROD[Production OU<br/>SCP: 厳格な制限<br/>・変更制限]
    DEV[Development OU<br/>SCP: 緩やかな制限]
    
    ROOT --> SEC
    ROOT --> INFRA
    ROOT --> WORKLOAD
    
    WORKLOAD --> PROD
    WORKLOAD --> DEV

SCPのトラブルシューティング

SCPに関する問題の診断と解決方法を解説します。

よくある問題と解決策

問題1: 意図しないアクションが拒否される

flowchart TD
    A[アクションが拒否された] --> B{SCPが原因か<br/>確認}
    B -->|確認方法| C[IAM Policy Simulator<br/>で検証]
    C --> D{SCP違反?}
    D -->|Yes| E[SCPの見直し]
    D -->|No| F[IAMポリシーの確認]

確認手順

CloudTrailでエラーイベントを確認
IAM Policy Simulatorでシミュレーション
継承されているすべてのSCPを確認
NotActionやConditionの意図しない影響を確認

問題2: グローバルサービスが使用できない

リージョン制限SCPでグローバルサービスを除外し忘れた場合に発生します。IAM、Route 53、CloudFrontなどはNotActionで除外が必要です。

問題3: SCPの変更が反映されない

SCPの変更は通常即座に反映されますが、キャッシュの影響で数分かかる場合があります。数分待ってから再試行してください。

デバッグ用のCloudTrailクエリ

CloudTrail Lakeを使用してSCP違反を分析できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


SELECT
    eventTime,
    eventSource,
    eventName,
    userIdentity.arn,
    errorCode,
    errorMessage
FROM
    event_data_store_id
WHERE
    errorCode = 'AccessDenied'
    AND errorMessage LIKE '%SCP%'
    AND eventTime > '2026-01-01'
ORDER BY
    eventTime DESC
LIMIT 100

SCPとControl Towerの統合

AWS Control Towerを使用している場合、SCPはガードレールの一部として自動管理されます。

Control Towerのガードレール

Control Towerは、SCPを「予防的ガードレール」として使用します。

ガードレールタイプ	実装方法	例
予防的（Preventive）	SCP	リージョン制限、CloudTrail保護
検出的（Detective）	AWS Config Rules	暗号化されていないS3の検出
プロアクティブ	CloudFormation Hooks	デプロイ時の検証

Control TowerのSCPとカスタムSCPの共存

Control Towerが管理するSCPとカスタムSCPは共存できます。ただし、以下の点に注意が必要です。

Control Towerが管理するSCPは手動で変更しない
カスタムSCPはControl Towerの管理外のOUに適用
競合を避けるため、役割を明確に分離

まとめ

サービスコントロールポリシー（SCP）は、AWS Organizationsにおける強力なセキュリティガードレールです。本記事で解説した内容を振り返ります。

SCPは許可の上限を設定するフィルターであり、権限を付与するものではない
継承ロジックにより、ルートからOUを経由してアカウントに適用される
拒否リスト方式から始め、段階的にガードレールを強化することを推奨
よく使われるパターン（リージョン制限、ルートユーザー禁止、CloudTrail保護など）を組み合わせて使用
段階的な導入とPolicy Staging OUでのテストが重要
緊急時の除外ロールを必ず設定しておく

SCPを効果的に活用することで、組織全体のセキュリティベースラインを確立し、コンプライアンス要件を満たすことができます。次の記事では、タグポリシーとバックアップポリシーを使用した組織全体のガバナンス強化について解説します。

サービスコントロールポリシー（SCP）とは#

SCPの基本概念#

SCPとIAMポリシーの違い#

SCPの特徴と制約#

SCPの継承と評価ロジック#

継承の仕組み#

有効なポリシーの計算#

評価ロジックの詳細#

FullAWSAccessポリシー#

SCP設計のアプローチ#

許可リスト（Allow List）方式#

拒否リスト（Deny List）方式#

よく使われるSCPパターン#

パターン1: リージョン制限#

パターン2: 特定サービスの禁止#

パターン3: ルートユーザーの使用禁止#

パターン4: CloudTrailの保護#

パターン5: S3パブリックアクセスの禁止#

パターン6: VPCの保護#

パターン7: 組織離脱の禁止#

パターン8: 必須タグの強制#

パターン9: 高額インスタンスタイプの制限#

パターン10: 暗号化の強制#

SCPの作成と適用手順#

マネジメントコンソールでの作成#

AWS CLIでの作成#

SCPのアタッチ#

SCPの確認#

SCP設計のベストプラクティス#

段階的な導入#

ドライラン的なテスト#

緊急時の除外ロール#

命名規則とバージョン管理#

SCPのサイズ制限への対応#

OU構造との連携#

SCPのトラブルシューティング#

よくある問題と解決策#

デバッグ用のCloudTrailクエリ#

SCPとControl Towerの統合#

Control Towerのガードレール#

Control TowerのSCPとカスタムSCPの共存#

まとめ#

参考リンク#