職務分掌（Segregation of Duties, SoD）は、一人の人物が完全なプロセスを単独でコントロールできないよう権限を分散するセキュリティ統制です。内部不正の防止と事故の予防を目的とし、SOX法、HIPAA、PCI-DSSなどの規制要件でも必須とされています。

AWSでは、物理的分離（アカウント分離）、論理的分離（IAMロール）、プロセス分離（承認ワークフロー）の3つのアプローチで実現します。

職務分掌の実装において、以下の3つのパターンが重要です。

開発・テスト・本番環境を物理的に分離し、AWS Organizationsで一元管理する最も確実な職務分掌実装パターンです。

図の上部でAWS Organizationsが複数アカウントを一元管理し、SCP（Service Control Policies）で組織全体のガードレールを設定します。各環境は完全に分離されたAWSアカウントで運用され、物理的な境界により権限の混在を防ぎます。

左側の開発・運用チームでは、開発者が開発アカウントで自由にリソースを操作できますが、本番アカウントへの直接アクセスは制限されます。運用者は承認プロセス経由でクロスアカウントロールを使用し、承認されたプロセスを通じてのみ本番環境にアクセス可能にし、責任の所在を明確化します。

右側の監査・ガバナンスでは、CloudTrailがマルチアカウント全体のAPI活動を記録し、AWS Configで設定変更を追跡します。SCPによる予防的統制と、継続的な監視により、職務分掌違反を防止・検出します。

最小権限の原則に基づき、タスク別・環境別にIAMロールを分離し、アクセス権限を厳密に統制するパターンです。

図の上部でIAM Access Analyzerが実際のAPI使用パターンを分析し、最小権限ポリシーを生成します。これによりワイルドカード権限（*）を避け、真に必要な権限のみを付与する最小権限の原則を実現します。

左側のロール分離では、開発者ロール、CloudFormationロール、運用ロールがそれぞれ異なる権限セットを持ちます。開発者はiam:PassRole権限でCloudFormationロールを渡すことはできますが、直接的なインフラ操作権限は持ちません。CloudFormationロールがインフラデプロイを実行し、下部のAWSリソース（EC2、RDS）を作成・更新します。

右側の統制メカニズムでは、IAM条件でタグベースアクセス制御を実装し、特定環境のリソースにのみアクセスを許可します。外部監査人用の一時認証情報発行や、定期的な権限レビューにより、継続的な統制を維持します。

インフラストラクチャの変更を自動化されたパイプラインで管理し、コードレビューと承認プロセスを強制するパターンです。

図の左側でGitHubリポジトリがプルリクエストベースのコードレビューを強制し、承認なしでの変更を防止します。CodePipelineがソースコード変更を検出し、自動的にパイプラインを開始します。

中央のビルド・テストフェーズでは、CodeBuildでCloudFormationテンプレートの構文チェックと単体テストを実行し、品質を保証します。手動承認アクションにより、本番デプロイ前に最終確認を実施します。

右側のデプロイ・監査では、CloudFormationがインフラを自動デプロイし、AWS Configが手動作成されたリソースを検出します。すべての操作はCloudTrailで記録され、完全な監査証跡を提供し、誰がいつ何を変更したかを追跡可能にします。

ここまで学んだ3つのパターンを、実践的な問題で確認しましょう。各問題は企業の実際のシナリオに基づいており、職務分掌の適用能力を評価します。

職務分掌の実現には、物理的分離、論理的分離、プロセス分離の3つのアプローチを組み合わせることが重要です。3つの核心パターンを理解することで、様々なコンプライアンス要件に対応できます。

これらのパターンを組み合わせることで、SOX法、HIPAA、PCI-DSSなどの規制要件を満たす包括的な職務分掌システムを構築できます。