Security要件からControlを選択する

1. セキュリティ設計はサービス名から始めない

「セキュリティを強化したい」という要件に対して、GuardDuty、AWS Network Firewall、KMS、CloudTrail、AWS Security Hubをすべて導入することが、必ずしも適切なアーキテクチャではありません。

何を守る？

誰から守る？

誰に許可する？

どこまで通信させる？

何を暗号化する？

何を証拠として残す？

まずリスクと要件を明確にし、その責任を満たす制御を選ぶことが出発点です。

2. 要件を5つのセキュリティ軸へ分解する

複雑なシナリオでも、最初にセキュリティ要件を次の軸へ分解すると、必要な制御を選びやすくなります。

要件
    ↓
制約 / 決定要因
    ↓
必要な制御
    ↓
制御同士の責任分担

サービス名を先に決めるのではなく、要件からアーキテクチャへ落とします。

3. アイデンティティでは最初に「誰なのか」を分ける

アイデンティティ要件では、いきなりIAMポリシーを書き始めません。まずアクセス主体を分けます。

人従業員？

AWSワークロード？

外部組織？

人とワークロードではアイデンティティライフサイクルも認証情報も異なるため、同じ方式へまとめないことが重要です。

4. 認証と認可を分ける

企業IdPで社員を認証できても、その社員が本番アカウントで何をできるかは別の要件です。

認証
→ 誰か？

認可
→ 何を許可？

例えば外部IdP、AWS IAM Identity Center、権限セットを組み合わせ、IDソースとAWS権限を別々に設計します。

5. 最小権限は必要な範囲を要件から決める

同じ開発者グループでも、開発では変更可能、本番では読み取り専用という要件なら、アカウントごとに異なる権限が必要です。

アイデンティティ
   ×
AWSアカウント
   ×
必要なアクション
   ↓
必要権限

最小権限は「できるだけ何も許可しない」ことではなく、ビジネス要件を満たす最小限の権限を選ぶことです。

6. ネットワークでは必要な通信を先に定義する

例えばインターネット-向けアプリケーションなら、通信を一括して「VPCを安全にする」と扱わず、必要なフローへ分解します。

インターネット
   ↓
ALB
   ↓
アプリケーション
   ↓
データベース

必要フロー
インターネット → ALB
ALB → アプリケーション
アプリケーション → データベース

制御は、この必要フローを成立させつつ不要な通信を許可しないように選択します。

7. 経路・リソース・サブネット・検査を分ける

ネットワーク要件は制御の責任単位へ分けます。

例えば「アプリケーションサーバーはALBからTCP 8443だけ受信する」という要件なら、セキュリティグループが直接的な制御です。この要件だけでネットワークACL、AWS Network Firewall、Firewall Managerまで必須になるわけではありません。

8. 明示的な検査要件がある場合に検査を追加する

「すべてのアウトバウンドトラフィックを中央ファイアウォールで検査し、ドメインやプロトコルに基づいて制御する」という要件なら、検査ポイントとトラフィック経路の両方が必要です。

アプリケーショントラフィック
      ↓
ルートテーブル
      ↓
AWS Network Firewall エンドポイント
      ↓
検査

一方、単純なリソース間許可だけならセキュリティグループで責任を満たせる場合があります。多層防御とサービスの過剰投入を混同しないことが重要です。

9. 暗号化では保存時と転送中を分ける

保存データを保護
→ 保管中の暗号化

通信中データを保護
→ 転送中の暗号化

例えばS3やデータベースの保存データはKMSを中心に考え、インターネットクライアントからALBまでの通信はTLS / 証明書を中心に考えます。同じ「暗号化要件」でも責任が異なります。

10. 保存時ではキー制御要件を確認する

「セキュリティチームがキーポリシーとキーライフサイクルを管理し、アプリケーションチームにはDecryptだけ許可する」という要件なら、顧客マネージドKMSキー、キーポリシー、IAMポリシーを評価します。

カスタマーマネージド KMSキー
        │
        ├─ キーポリシー / ライフサイクル → セキュリティチーム
        │
        └─ 暗号化 / Decrypt      → アプリケーション

一方、サービス標準の暗号化で十分で独自キー制御が不要なら、顧客マネージドキーを必ず追加する必要はありません。キーの管理主体、クロスアカウント利用、専用HSM 要件まで確認します。

11. 転送中ではTLS 終端と信頼範囲を決める

TLSが必要というだけでは証明書アーキテクチャは決まりません。

TLSが必要
   ↓
どこで終端？
   ↓
誰が証明書を信頼？
   ↓
誰が更新？

インターネット向けエンドポイントならパブリック証明書、組織内部だけで信頼させるならプライベート証明書を評価します。証明書を使う場所とライフサイクル責任まで含めて判断します。

12. 監査では「何を後から説明する必要があるか」を決める

同じAWS環境でも、追跡したいアクティビティによってCloudTrailイベントタイプが変わります。

誰がセキュリティグループを変更した？
→ 管理イベント

誰が機密S3 オブジェクトを読み取った？
→ データイベント

サービス名からイベントタイプを決めるのではなく、どのアクティビティを根拠として必要とするかを先に決めます。

13. レコード・検知・対応を分ける

セキュリティアーキテクチャでは、監査証跡、脅威検知、検出結果の優先付け、通知・対応を同じ機能として扱いません。

CloudTrail
→ アクティビティを記録

GuardDuty
→ 脅威らしいアクティビティを検出

AWS Security Hub等
→ 検出結果を統合・優先

EventBridge
→ 通知 / 対応へ接続

CloudTrailがあるだけで脅威検知が完成するわけでも、GuardDutyの検出結果があるだけで長期監査根拠が完成するわけでもありません。

14. エンタープライズ監査では収集範囲と保管場所も決める

「組織内すべてのアカウントを長期監査する」という要件なら、個別アカウントのイベント履歴だけでは不足します。

組織の証跡
      ↓
中央ログアーカイブ
      ↓
保持 / アクセス制御
      ↓
ログ完全性検証

何を記録するかに加えて、アカウント / リージョン範囲、保持期間、責任分離、完全性まで設計します。

15. クロスアカウントでは「誰が何を使うか」を先に決める

「アカウント Aからアカウント Bへアクセスする」という情報だけではアーキテクチャは決まりません。

社員が多数アカウントを利用？

ワークロードが対象アカウントのアイデンティティへ切り替える？

対象リソースを外部プリンシパルへ直接共有？

アクセス主体と対象リソース、必要な認証情報モデルを見て方式を選びます。

16. 従業員のマルチアカウントアクセス

社員が多数AWSアカウントへアクセスする要件なら、従業員アイデンティティを各アカウントへ複製するのではなく、中央管理を評価します。

企業IdP
      ↓
IAM Identity Center
      ↓
グループ × AWSアカウント × アクセス許可セット

IDソースを中央化し、アカウントごとの認可を割り当てで分けるアーキテクチャです。

17. ワークロードのクロスアカウントアクセス

アプリケーションアカウントのワークロードが対象アカウントのアイデンティティとして処理したい場合は、クロスアカウントIAMロールを評価します。

送信元アイデンティティ
      │ sts:AssumeRole
      ▼
対象 IAMロール
      │
      ▼
対象リソース

送信元側のAssumeRole 権限、対象側の信頼ポリシー、ロール自体のリソース権限という責任に分けます。

18. リソースベースのアクセスが適する場合もある

サービスがリソースベースのポリシーによるクロスアカウント共有をサポートしている場合、対象アイデンティティへ切り替えずにリソースを外部プリンシパルへ直接共有するアーキテクチャもあります。

呼び出し元アイデンティティ
      │
      ▼
対象リソースポリシー
      │
      ▼
対象リソース

したがって、クロスアカウント = 必ずAssumeRoleではありません。アイデンティティを切り替えるのか、リソースを直接共有するのかを判断します。

19. クロスアカウント KMSでは対象サービス固有のアクセスモデルも確認する

KMSのようにクロスアカウントアクセスへ固有の権限関係を持つサービスもあります。

セキュリティアカウント
└─ カスタマーマネージド KMSキー
      ↑
      │ キー 所有者側キーポリシー
      │ 外部アカウント側 IAMポリシー
      │
アプリケーションアカウント
└─ アプリケーションロール

クロスアカウント要件では一般的なIAMの知識だけでなく、対象サービスのアクセスモデルまで確認します。

20. 制御は「最大」ではなく「必要十分」で選ぶ

制御が多いほど必ず優れたセキュリティアーキテクチャになるわけではありません。

制御追加
   │
   ├─ コスト
   ├─ 運用の複雑さ
   ├─ 誤検知
   ├─ ルール競合
   └─ トラブルシューティングの複雑さ

要件を満たす + 最小権限 + 必要な多層防御 + 運用可能という条件を満たす構成を選びます。

21. 1つのシナリオに複数制御が必要な場合もある

インターネット向けアプリケーションで機密データを扱い、全アカウントのセキュリティアクティビティを監査するなら、責任の異なる複数制御が必要です。

アイデンティティ
→ IAMロール / 最小権限

ネットワーク
→ セキュリティグループ
→ 必要なら検査

暗号化
→ TLS
→ KMS

監査
→ 組織の証跡
→ 中央ログアーカイブ

検知
→ GuardDuty / Inspector等
→ セキュリティツール群

これは同じ責任を重複させるのではなく、異なるセキュリティ責任を組み合わせる設計です。

22. アーキテクチャ例：企業向けアプリケーション

次の要件をまとめて設計します。

・社員は既存企業IdPを利用
・本番 / 開発で権限を分ける
・インターネットからアプリケーションを利用
・データベースはインターネットから直接到達不可
・機密データは顧客管理キーで暗号化
・クライアント通信はTLS
・すべてのAWSアカウントを監査
・重要検出結果はセキュリティチームへ通知

サービスを暗記して並べるのではなく、要件 → セキュリティ責任 → 制御の順で選択します。

23. 要件間の関係も確認する

セキュリティ要件は常に1種類だけで成立するとは限りません。

クロスアカウント暗号化
= 暗号化要件
+ アイデンティティ要件
+ クロスアカウント要件

中央セキュリティ監視
= 監査要件
+ マルチアカウント要件
+ セキュリティ運用

SAP-C02の長いシナリオでは、1つのキーワードだけを拾って答えを決めず、複数要件の交点を見ます。

24. 決定打を要件から拾う

要件文のどの条件がアーキテクチャを決定しているのかを見ます。

これはサービス暗記表ではなく、シナリオから決定要因を抽出するための見方です。

25. 混同ポイント

• セキュリティ要件が多い = すべてのセキュリティサービスを使う：要件を満たす責任がある制御だけを選びます。
• 最小権限 = 何も許可しない：必要なビジネスアクションを満たす最小権限です。
• クロスアカウント = 必ずIAMロール：リソースベースのポリシーやサービス固有アクセスモデルもあります。
• ネットワークセキュリティ = セキュリティグループだけ：経路、サブネットガードレール、検査など別責任が必要な場合があります。
• AWS Network Firewallは常に必要：検査要件がある場合に評価します。
• 暗号化 = KMSだけ：保存時と転送中を分けます。
• 監査 = CloudTrailを有効化して完了：範囲、保持期間、集中化、完全性も要件次第で必要です。
• 検出結果 = 監査ログ：検知シグナルと根拠は別の役割です。
• 制御を増やすほどセキュリティが必ず改善：コストと運用の複雑さも含めて必要十分性を判断します。

26. SAP-C02判断フロー

セキュリティ要件を読む
        │
        ▼
誰がアクセス？
        │
        ├─ 人
        │    → AWS IAM Identity Center / フェデレーション
        │
        └─ ワークロード
             → IAMロール
        │
        ▼
アカウント 境界を越える？
        │
       はい
        ▼
AssumeRole？
リソース共有？
サービス固有ポリシー？
        │
        ▼
どのネットワーク通信が必要？
        │
        ├─ 経路
        ├─ リソース許可
        ├─ サブネットガードレール
        └─ 検査
        │
        ▼
データ保護は？
        │
        ├─ 保存時 → KMS等
        └─ 転送中 → TLS / 証明書
        │
        ▼
何を後から証明する？
        │
        ▼
CloudTrail / 集中ログ記録
        │
        ▼
脅威 / 脆弱性等を検出する？
        │
        ▼
検知サービス
        │
        ▼
マルチアカウント運用？
        │
        ▼
中央セキュリティ運用
        │
        ▼
要件を満たす
必要十分な制御か確認

27. まとめ

アイデンティティ要件
→ 誰が
→ 認証
→ 認可
→ 最小権限

ネットワーク要件
→ 経路
→ リソース
→ サブネット
→ 検査

暗号化要件
→ 保存時
→ 転送中
→ キー / 証明書 所有責任

監査要件
→ 何を記録するか
→ 範囲
→ 保持
→ 集中化
→ 完全性 / 検知

クロスアカウント要件
→ 誰が
→ どのアカウント
→ どのリソース
→ AssumeRoleまたは直接共有

セキュリティ制御の選択
→ 要件から選ぶ
→ 責任が異なる制御を組み合わせる
→ 過剰制御を避ける

最重要ポイントは、「どのAWSサービスを使うか」から考えるのではなく、要件をセキュリティ責任へ分解し、その責任を満たす制御だけを選ぶことです。これがタスク 1.2「セキュリティコントロールを規定する」の中心判断です。

28. 主要AWS公式資料

セキュリティ制御の選択を確認するための主要なAWS公式資料を以下に示します。

• SAP-C02 ドメイン 1 / タスク 1.2 — AWS Certification
• AWS Security Reference Architecture — 概要
• AWS Security Reference Architecture — アーキテクチャ
• AWS SRA — アカウント構造
• IAM Identity Center — 概要
• IAM — クロスアカウントリソースアクセス
• Amazon VPC — セキュリティグループとネットワークACL
• AWS KMS — キーポリシー
• AWS Certificate Manager — 概要
• AWS CloudTrail — CloudTrailの仕組み