Security RequirementからControlを設計する

1. 資産を先に特定する

資産はデータだけではありません。ビジネスやシステムにとって保護価値があるものを対象にします。

2. 同じAWSリソースでも資産の機密度で要件は変わる

同じAmazon S3に保存されるデータでも、公開用の製品画像と顧客個人データではビジネスへの影響が異なります。

リソース種別が同じ
        ↓
資産の機密度 / ビジネスへの影響は異なる
        ↓
必要なセキュリティ要件も異なる

「S3だからこの制御」というサービス起点ではなく、資産の性質から必要な結果を決めます。

3. 脅威と脆弱性を分ける

脅威は資産へ悪影響を与え得るアクション / イベントです。認証情報の窃取、不正なアクセス、データの持ち出し、悪意のある改ざんなどが例です。

一方、過剰権限、公開管理ポート、パッチ未適用ソフトウェアなどは脅威に利用され得る弱点 / 脆弱性です。

脆弱性 / 弱点
        ↓ 利用される脅威イベント
        ↓
資産への影響

4. 脅威はアーキテクチャのコンテキストから特定する

「インターネットから攻撃される可能性がある」だけではセキュリティ要件へ落とせません。主体、侵入口、コンポーネント、データフローをアーキテクチャ上で確認します。

インターネットユーザー
      ↓ HTTPS
パブリックAPI
      ↓
アプリケーション
      ↓
機密データ保管先

このフローなら、パブリックAPIへの悪意のあるリクエスト、認証情報の悪用、アプリケーション経由の不正なデータアクセスなど、実際のアクセス経路に沿って脅威を考えられます。

5. データフローと信頼境界を分離する

データフローはコンポーネント間をデータがどう移動するかを示します。信頼境界はアイデンティティ、所有責任、認可コンテキスト、セキュリティポリシーなどのセキュリティコンテキストが変化する場所です。

データフローを列挙
        ↓
そのフローは信頼境界を越える？
        ↓ はい境界越えとしてセキュリティ要件を検討

すべてのデータフローが必ず信頼境界を越えるわけではありません。アーキテクチャのコンテキストに応じて判定します。

6. 信頼境界はVPC 境界だけではない

信頼境界になり得る例は次のとおりです。

• インターネット → AWSワークロード
• ユーザー → アイデンティティ提供側
• アカウント A → アカウント B
• AWSワークロード→ サードパーティ SaaS
• セキュリティポリシーや認可コンテキストが変化するコンポーネント間

特にマルチアカウントでは、同じAWS Organizations配下だから無条件に信頼済みとは扱いません。

7. プライベートネットワークを信頼の根拠にしない

プライベートサブネットやプライベートIPだけでは、侵害されたワークロード、内部関係者、認証情報の窃取、設定ミスなどを排除できません。

プライベートネットワーク
≠
自動的に信頼済み

ネットワーク場所に加えてアイデンティティ、認可、データ機密度、必要な通信を確認します。

8. 攻撃対象領域は攻撃・誤用可能なインターフェイス全体

攻撃対象領域にはパブリックエンドポイントだけでなく、API、管理インターフェイス、SSH / RDP、クロスアカウントロール、サードパーティ統合、アプリケーション入力、内部アクセス経路なども含まれ得ます。

つまり、インターネット公開かどうかではなく、主体が資産へ影響を与え得る侵入口 / インターフェイスかを確認します。

9. 不要な攻撃対象領域は守る前に減らす

ビジネス要件上不要な侵入口は、検査制御を増やして残すより削除できないかを先に評価します。

攻撃対象領域
├─ 不要 → 削除 / 縮小
└─ 必要 → 保護 / 監視

必要なインターフェイスだけを残すことで、後続制御が守る対象も明確になります。

10. 信頼境界を越える通信から要件を導く

境界を越える通信では、資産と脅威に応じて認証、認可、データ保護、入力検証、ログ記録 / 検知などの結果を検討します。

アカウント A ワークロード
      ↓ クロスアカウントアクセスアカウント B 機密リソース要件例
- 承認済みプリンシパルだけアクセス可能
- 必要アクションだけ許可
- セキュリティ上重要なアクティビティを追跡可能

境界を越えるから全部の制御を付けるのではなく、脅威とビジネス要件に必要な結果だけを選びます。

11. セキュリティ要件は検証可能な結果にする

「データベースを安全にする」のような表現では、アーキテクチャが要件を満たしたか判定できません。

12. 脅威からセキュリティ上の結果へ変換する

脅威不正な管理アクセス
        ↓
資産影響不正な変更 / データアクセス
        ↓
セキュリティ要件承認済み管理者だけが必要な管理操作を実行できる

この時点では具体的なIAM、ネットワーク、暗号化サービスを固定しません。後続の制御の選択で比較できる要件を作ることが目的です。

13. 多層防御は異なる責任のレイヤーを組み合わせる

多層防御はセキュリティ制御の数を最大化する考え方ではありません。

エッジ
 ↓
ネットワーク
 ↓
アイデンティティ/ アプリケーション
 ↓
データ
 ↓
検知 / 監査

1つのレイヤーが失敗しても別レイヤーが影響を抑えられるよう、脅威に対して異なる責任を持つ制御を組み合わせます。

14. 同じ種類の制御を増やすだけでは十分ではない

同じネットワーク制御を複数重ねても、窃取された認証情報やアプリケーション層の攻撃まで同じように抑制できるとは限りません。

アイデンティティ、ネットワーク、アプリケーション、データ、検知など、脅威経路の異なる地点で独立した保護を持たせることが多層防御のポイントです。

15. アーキテクチャ変更時には脅威モデルも更新する

パブリックAPI追加、サードパーティ統合、新アカウントへのデータ共有、管理者アクセス経路変更などが起きると、侵入口、攻撃対象領域、信頼境界、脅威も変化します。

アーキテクチャ変更
        ↓
データフロー / 侵入口を更新
        ↓
信頼境界 / 攻撃対象領域を再評価
        ↓
脅威/ セキュリティ要件を更新

16. 脅威起点の要件設計フロー

ビジネス / コンプライアンス上のコンテキスト
        ↓
資産と機密度
        ↓
主体 / 侵入口 / データフロー
        ↓
信頼境界を越える通信を特定
        ↓
攻撃対象領域
        ↓
脅威/ 資産影響
        ↓
検証可能なセキュリティ要件
        ↓
必要なら多層防御
        ↓
具体制御の比較へ

17. 混同ポイント

18. 主要AWS公式資料

• AWS Well-Architected セキュリティ柱 — 脅威モデリング
• AWS Well-Architected セキュリティ柱 — ネットワークレイヤーを作成
• AWS Certified Solutions Architect - Professional — ドメイン 2