AWS Service Control Policies (SCP) - 組織レベルのアクセス制御とガバナンス ​

AWS Service Control Policies（SCP）は、AWS Organizations において組織レベルでアクセス制御を実現するための重要な仕組みです。

なぜSCPが必要なのか ​

実際によくある問題シナリオ

• 問題1: 開発者が間違って本番環境のデータベースを削除してしまった
• 問題2: 社員が業務時間外に高額なインスタンスを起動し、翌朝には予期しない高額請求が発生
• 問題3: 監査で「東京リージョン以外にデータを保存してはいけない」という規制に違反していることが判明

これらの問題は、個人のIAM権限だけでは防ぐことができません。なぜなら、業務上必要な権限を持つユーザーでも、誤操作や認識不足により組織全体に影響する行動を取ってしまう可能性があるからです。

SCPによる解決

IAMポリシーとは異なり、SCPは組織全体に適用される**ガードレール（安全柵）**として機能し、こうした問題を根本的に防止します。たとえ管理者権限を持つユーザーでも、SCPで制限された操作は実行できないため、組織全体のセキュリティとコンプライアンスを確実に統制できます。

ガードレールとは：物理的な道路のガードレールと同じように、AWS上での操作が危険な領域に逸脱しないようにする保護柵の役割を果たします。例えば、開発者が間違って本番環境のリソースを削除しようとしても、ガードレールがその操作を阻止します。

SCPの基本概念と動作原理 ​

SCPとIAMポリシーの違い ​

SCPは従来のIAMポリシーと根本的に異なるアプローチを取ります。IAMポリシーが「権限の付与」を行うのに対し、SCPは「権限の制限」のみを行います。

SCPの評価順序 ​

SCPの評価は階層的に行われ、組織構造に従って適用されます。

効果的なSCP設計パターン ​

基本セキュリティ制御の実装 ​

組織離脱防止とセキュリティ基盤保護 ​

組織の基本セキュリティを確保するための最初のステップです。以下の2つの主要な制御を実装します：

1. 組織離脱防止のポリシー例

{
  "Effect": "Deny",
  "Action": [
    "organizations:LeaveOrganization",
    "organizations:DeleteOrganization"
  ],
  "Resource": "*"
}

2. セキュリティサービス保護のポリシー例

{
  "Effect": "Deny",
  "Action": [
    "cloudtrail:StopLogging",
    "config:DeleteConfigRule",
    "guardduty:DeleteDetector"
  ],
  "Resource": "*"
}

詳細な実装例: 条件文や例外処理を含む完全なポリシーはAWS公式ドキュメントを参照してください。

地域制限とデータ保護 ​

データ主権とコンプライアンス対応 ​

コンプライアンス要件やデータ保護要件を満たすための地域制限とデータ暗号化の強制を実装します。

地域制限の実装例

{
  "Effect": "Deny",
  "Action": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["ap-northeast-1", "ap-northeast-3"]
    }
  }
}

S3暗号化強制の実装例

{
  "Effect": "Deny",
  "Action": "s3:PutObject",
  "Condition": {
    "Null": {"s3:x-amz-server-side-encryption": "true"}
  }
}

詳細設定: グローバルサービスの例外設定や高度な条件文はAWS公式ガイドを参照してください。

環境別制御ポリシー ​

開発環境向けコスト制御 ​

開発環境でのコスト爆発を防ぐための主要な制御を実装します。

EC2インスタンスタイプ制限

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Condition": {
    "ForAnyValue:StringNotEquals": {
      "ec2:InstanceType": ["t3.micro", "t3.small", "t3.medium"]
    }
  }
}

本番環境アクセス防止

{
  "Effect": "Deny",
  "Action": "*",
  "Condition": {
    "StringEquals": {"aws:ResourceTag/Environment": "Production"}
  }
}

詳細ポリシー: EBSボリュームサイズ制限や細かいインスタンスタイプ設定はAWS SCPサンプル集を参照してください。

高度なSCP活用パターン ​

時間ベース制御とコンプライアンス ​

業務時間外のリソース制限 ​

業務時間外の予想外コストやセキュリティリスクを減らすための時間ベース制御です。

時間制限の実装例

{
  "Effect": "Deny",
  "Action": ["ec2:RunInstances", "rds:CreateDBInstance"],
  "Condition": {
    "DateGreaterThan": {"aws:CurrentTime": "18:00Z"},
    "StringNotEquals": {"aws:userid": ["ADMIN_USER_ID"]}
  }
}

このポリシーは、8時以降のEC2インスタンス起動やRDS作成を禁止し、管理者のみ例外として許可します。

詳細設定: 朝の時間制限や細かいユーザーID設定はAWS SCP時間制御例を参照してください。

タグベース制御の実装 ​

リソース分類に基づく細粒度制御 ​

タグベースの制御で、リソースの適切な分類と管理を強制します。

環境タグ必須化の実装例

{
  "Effect": "Deny",
  "Action": ["ec2:RunInstances", "s3:CreateBucket"],
  "Condition": {
    "Null": {"aws:RequestedResourceTag/Environment": "true"}
  }
}

タグ値の標準化強制

{
  "Effect": "Deny",
  "Action": ["ec2:CreateTags"],
  "Condition": {
    "ForAnyValue:StringNotEquals": {
      "aws:RequestedResourceTag/Environment": 
        ["Production", "Development", "Testing"]
    }
  }
}

詳細タグ戦略: 全社的なタグ付け戦略や自動タグ付けの設定方法はAWSタグベストプラクティスを参照してください。

SCPの設定と適用 ​

AWSコンソールでのSCP設定手順 ​

SCPの設定は、AWS Organizations コンソールを使用してGUIで簡単に行うことができます。

基本的な設定手順 ​

1. AWS Organizationsコンソールへのアクセス

• AWS管理コンソールにログイン
• サービス検索で「Organizations」を選択
• 左サイドバーの「ポリシー」→「Service control policies」を選択

2. 新しいSCPポリシーの作成

• 「ポリシーを作成」ボタンをクリック
• ポリシー名と説明を入力（例：「開発環境コスト制御ポリシー」）
• ポリシー文書をJSON形式で入力または既存テンプレートを選択
• 「ポリシーを作成」で保存

3. ポリシーのOU（組織単位）への適用

• 作成したポリシーを選択
• 「アタッチ」タブから適用先のOUまたはアカウントを選択
• 適用を実行（即座に有効になります）

4. 設定確認と監視

• 「アタッチ」タブで適用状況を確認
• CloudTrailログで実際の制限効果を監視

注意: SCPは作成直後から有効になるため、テスト環境での事前検証を強く推奨します。

SCPのテストと検証 ​

ポリシーシミュレーション ​

SCPを実装する前の検証は極めて重要です。意図しないアクセス拒否を防ぐために、段階的な検証アプローチを採用します。

ポリシー効果の監視 ​

CloudTrailによる拒否アクション監視 ​

SCPによる制限は、ユーザーには「AccessDenied」エラーとして表示されるため、適切な監視が不可欠です。

CloudTrail監視の設定

CloudTrailでは、SCPによる拒否アクションを特定するために以下の監視を設定します：

• エラーコード「AccessDenied」のフィルタリング: CloudTrailログから拒否されたアクションを抽出し、SCP起因かIAM起因かを判別します
• SCP起因の拒否アクションの特定: エラー詳細でSCPが原因の拒否を識別し、想定外の制限を早期発見します
• 定期的なアクセスパターン分析: ユーザーの行動パターンを分析し、業務に支障をきたす制限を発見します

アラート設定による能動的監視

組織の運用を円滑にするため、以下のアラート設定を推奨します：

• 予期しないアクセス拒否の検出: 通常業務で使用されるアクションが突然拒否された場合のアラート
• 繰り返し発生する拒否パターンの特定: 同じユーザーまたは同じアクションで連続して拒否が発生している場合の通知
• 業務影響の早期発見: 重要な業務プロセスに影響する拒否アクションの即座の検知

SCP運用のベストプラクティス ​

段階的実装アプローチ ​

フェーズドロールアウト戦略 ​

例外管理とエスケープハッチ ​

緊急時対応プロセス ​

SCPによる制限が緊急時に業務を阻害する場合に備えて、適切なエスケープハッチ（緊急回避手順）の設計が重要です。

エスケープハッチの設計原則

エスケープハッチ（緊急回避手順）とは、システムの制限やセキュリティ機能を一時的に回避して、緊急時に必要な操作を実行するための事前に設計された仕組みです。以下のような仕組みを事前に準備します：

• Break Glassロール（緊急時権限）の準備: 緊急時のみ使用される特別な管理者権限を設定し、通常時はアクセス不可能な状態で保管します

  Break Glass（非常時破んで使用）とは：火災時の非常ベルのように、緊急時にのみ「ガラスを破って」使用する機能です。通常は厳重に封印され、使用時はその事実が明确に記録されます。

• 管理アカウントでの例外権限: 組織の管理アカウントにSCP制限の例外権限を設定し、緊急時の迅速な対応を可能にします

• 監査証跡の完全記録: Break Glassロールの使用時は全ての操作を詳細に記録し、後の監査で説明責任を果たせるようにします

厳格な承認プロセス

緊急時対応の悪用を防ぐため、以下の承認プロセスを確立します：

• セキュリティ責任者承認: Break Glassロールの使用には必ずセキュリティ責任者の事前承認を必須とします
• 変更管理委員会レビュー: 緊急対応後は変更管理委員会で対応内容をレビューし、再発防止策を検討します
• 事後監査と改善: 使用された緊急権限の監査を実施し、プロセスやSCPポリシーの改善点を特定します

パフォーマンスと最適化 ​

SCP評価パフォーマンス ​

効率的なポリシー設計 ​

SCPの評価パフォーマンスを最適化するため、以下の設計原則に従います。

ポリシー構造の最適化

SCPの評価を効率化するための構造設計のポイント：

• 具体的なリソースARNの使用: ワイルドカード（*）よりも具体的なリソースARNを使用することで、評価対象を限定し処理速度を向上させます
• 不要な条件文の削減: 複雑な条件分岐は評価時間を増加させるため、本当に必要な条件のみに絞り込みます
• 階層的なポリシー適用: 組織構造に応じてポリシーを階層化し、各レベルで適切な粒度の制御を実現します

評価効率の向上

日常的な業務への影響を最小限にするための配慮：

• 頻繁な操作への配慮: ユーザーが頻繁に実行するアクション（EC2の起動、S3アクセス等）の評価を軽量化します
• 複雑な条件式の簡素化: 多重ネストした条件や複雑な論理演算を避け、シンプルな判定ロジックを採用します
• キャッシュ効率の考慮: AWSのポリシー評価エンジンのキャッシュメカニズムを活用できるよう、同じパターンの条件を統一します

トラブルシューティング ​

一般的な問題と解決策 ​

SCP導入時に頻繁に発生する問題とその解決方法を理解しておくことで、スムーズな運用が可能になります。

よくある問題とその対処法

問題1: 意図しない拒否

• 発生原因: 過度に広範囲なDeny文により、必要な操作まで拒否されてしまう
• 症状: ユーザーが通常業務で必要なアクションを実行できない
• 解決方法: Deny文の対象を特定のリソースARNやアクションに限定し、影響範囲を明確にする

問題2: 管理機能の阻害

• 発生原因: 管理アカウント自体にも制限が適用され、組織管理機能が使用不可能になる
• 症状: 組織設定の変更、アカウント管理等の基本機能が実行できない
• 解決方法: 管理アカウントを制限対象から除外する条件文をポリシーに追加する

問題3: サービス間連携の失敗

• 発生原因: AWSサービス同士の内部連携で使用されるサービスリンクロールが制限される
• 症状: Lambda、CloudFormation等のサービスが他のサービスにアクセスできない
• 解決方法: サービスプリンシパル（service.amazonaws.com形式）を例外として設定する条件を追加する

SCPとその他AWSサービスの統合 ​

AWS Config との連携 ​

コンプライアンス監視の自動化 ​

Control Tower との統合 ​

AWS Control Towerのガードレールとしての活用 ​

AWS Control Towerは、マルチアカウント環境の設定とガバナンスを自動化するサービスで、SCPを活用して以下のガードレールを実装します。

統合設計:
  Control Tower ガードレール:
    - 必須ガードレール: SCPによる強制実装
    - 推奨ガードレール: 段階的適用
    - カスタムガードレール: 組織固有要件
  
  Account Factory統合:
    - 新規アカウント自動適用
    - ベースライン設定の標準化
    - 継続的コンプライアンス確保

まとめ ​

AWS Service Control Policies（SCP）は組織レベルでのガバナンスとセキュリティ統制において不可欠な仕組みです。IAMポリシーとは異なる「拒否ベース」のアプローチにより、組織全体にわたる一貫したセキュリティポリシーを実現します。段階的な実装、継続的な監視、適切な例外管理により、セキュリティとビジネス要求の両立が可能になります。

引用元：

• https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
• https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html
• https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_strategies.html
• https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html