アイデンティティ、ネットワーク、コンピューティング、アプリケーション、データ、ログに対する個別のセキュリティ対策は既習です。

既存アーキテクチャを改善するときは、

IAMあり
AWS WAFあり
セキュリティグループあり
暗号化あり
CloudTrailあり

という対策の有無だけを確認して終わらせません。

ここでは、

守る資産を決める
↓
具体的な攻撃経路を選ぶ
↓
経路上の既存対策を配置する
↓
1つの対策が機能しない状態を仮定する
↓
次に残る対策を確認する
↓
共通の管理経路も確認する
↓
防御の空白を特定する

という手順で既存アーキテクチャをレビューします。

見る視点は、

アイデンティティ層
ネットワーク層
コンピューティング層
アプリケーション層
データ層
ログ層

です。

重要なのは、各層を個別採点することではなく、

攻撃者が1つの対策を越えた後、次にどこで止まるか

を追跡することです。

ゴール

既存アーキテクチャについて、

• アイデンティティ層で残る操作権限を確認する
• ネットワーク層で残る到達経路を確認する
• コンピューティング層が侵害された場合の次の影響を確認する
• アプリケーション層で業務操作を制御できるか確認する
• データ層で最終的な影響範囲を制限できるか確認する
• ログ層で他の防御失敗を追跡できるか確認する
• 具体的な攻撃経路ごとに防御の空白を特定する
• 複数の対策が同じ管理経路へ依存していないか確認する
• 単一の侵害から重要資産まで一直線に到達できる箇所を見つける

ことを目指します。

1. まず守る資産と攻撃経路を決める

最初から、

IAMを確認
セキュリティグループを確認
AWS WAFを確認

とサービス単位で見始めると、設定確認だけになりやすくなります。

先に、

何を守るのか

を決めます。

例えば、

顧客情報
認証情報
本番データベース
機密ファイル
管理権限

です。

次に、その資産へ到達する具体的な経路を1つ選びます。

インターネット
↓
ALB
↓
Webアプリケーション
↓
EC2
↓
IAMロール
↓
Amazon S3
↓
機密データ

このように経路を固定すると、

どこで止める予定なのか

を確認しやすくなります。

2. 既存の対策を攻撃経路へ配置する

例えば、

インターネット
↓
AWS WAF
↓
ALB
↓
セキュリティグループ
↓
EC2
↓
アプリケーション認可
↓
IAMロール
↓
Amazon S3
↓
S3アクセス制御 / AWS KMS
↓
機密データ

という形で、既存の対策を実際の通信・操作経路へ重ねます。

さらに、

CloudTrail
VPC Flow Logs
アプリケーションログ
セキュリティ検出結果

などの証跡も横断的に確認します。

これにより、

対策が存在する

ではなく、

この攻撃経路の
この地点で機能する

という形で確認できます。

3. アイデンティティ層では「侵害後に何ができるか」を確認する

人のIAM権限だけではなく、

EC2ロール
Lambda実行ロール
ECSタスクロール
サービスロール

などのワークロードアイデンティティも確認します。

例えば、

インターネット
↓
Webアプリケーション
↓
EC2侵害
↓
EC2ロール取得

まで進んだとします。

このとき確認するのは、

そのロールで
何ができる？

です。

もし、

業務上必要なS3バケット

+

無関係な機密バケット

+

複数のKMSキー

へアクセスできるなら、

EC2侵害
↓
広いIAM権限
↓
被害範囲拡大

となります。

したがって、ネットワークやアプリケーションの対策を越えた後でも、

ワークロードの権限が影響範囲を制限できるか

を確認します。

4. ネットワーク層では「侵害された内部リソース」からも見る

外部からの到達制御だけではなく、

内部リソースが侵害された後

の通信も確認します。

例えば、

Webサーバー
↓
侵害

↓

同一VPC内の
すべてのデータベースへ到達可能

であれば、外部公開範囲を狭めていても内部移動の経路が広く残っています。

レビューでは、

このワークロードから
本当にこの宛先へ通信する必要があるか

を確認します。

例えば、

アプリケーションA
↓
データベースAのみ必要

なら、

VPC全体
↓
データベースA / B / C

へ広く到達できる状態は見直し候補です。

重要なのは、

外部境界だけでなく、侵害後の横方向の移動経路も確認すること

です。

5. コンピューティング層では「次の足場になるか」を確認する

既存環境に、

AWS WAF
セキュリティグループ
アプリケーション認証

があっても、実行基盤に重大な脆弱性が残っている場合があります。

例えば、

脆弱なランタイム
↓
リモートコード実行
↓
EC2上でコード実行
↓
インスタンスロール取得
↓
AWS API操作

という経路です。

ここでは、

OS
ランタイム
コンテナイメージ
インストール済みソフトウェア
パッチ
ハードニング
インスタンスメタデータへのアクセス

などを確認します。

目的は、コンピューティング層の設定を単独評価することではありません。

コンピューティング環境侵害
↓
次のアイデンティティ / データ侵害へ進めるか

を確認します。

6. アプリケーション層では「正常な通信の中の不正操作」を確認する

ネットワーク上は正しい通信でも、業務上は不正な操作という場合があります。

例えば、

利用者A
↓
正常に認証

↓

APIへ正規のHTTPS通信

↓

他ユーザーのリソースIDを指定

↓

利用者Bのデータを取得

という経路です。

この場合、

AWS WAF
セキュリティグループ
TLS

が正常に機能していても、攻撃を止められない可能性があります。

確認するのは、

誰が
どのリソースへ
どの操作を
実行できるか

という業務上の認可です。

つまり、

ネットワーク上通してよい通信と、業務上許可してよい操作を分けて確認する

必要があります。

7. データ層では「最後にどこまで失うか」を確認する

攻撃者が、

アプリケーション
↓
コンピューティング環境
↓
IAMロール

まで到達したとしても、

全データ

へ到達できる必要はありません。

例えば、

アプリケーションA
↓
S3プレフィックスAのみ必要

であるなら、

バケット全体
別アプリケーションのプレフィックス
別環境のデータ

まで読める権限は不要です。

データ層では、

データアクセス権限
KMSキーへの権限
暗号化
リソースポリシー
保持・削除条件

などを確認します。

重要なのは、

上流の対策が突破された場合でも
最終的なデータ被害を限定できるか

です。

8. 暗号化がある場合も権限経路まで追う

例えばAmazon S3がSSE-KMSで暗号化されていても、

侵害されたIAMロール
↓
s3:GetObject
許可

+

kms:Decrypt
許可

なら、正規の権限として復号できる場合があります。

レビューでは、

暗号化あり
↓
安全

で終了せず、

誰がデータへ到達できる？

そのアイデンティティは
KMSキーも使える？

侵害された場合
どこまで読める？

まで追跡します。

9. ログ層では「どの失敗を発見できるか」を確認する

ログは他の防御が突破された後の検知・調査にも使います。

例えば、

正しい認証情報
↓
AWS API実行

↓

IAM上は許可

↓

操作自体は成功

という場合、予防対策だけでは異常と判断できないことがあります。

ここで、

CloudTrail
アプリケーションログ
VPC Flow Logs
セキュリティ検出結果

などによって、

誰が
いつ
どこから
何を操作したか

を追跡できるか確認します。

さらに、

記録される

だけでなく、

十分な期間残る？

攻撃者が消せる？

異常検知へつながる？

まで確認します。

10. 1つの対策を外して攻撃経路を再実行する

既存対策を配置したら、

重要な対策を1つだけ
機能しない状態にする

と仮定します。

例えば、

AWS WAFが
悪意あるリクエストを通した

とします。

その後、

アプリケーション認可
↓
止められる？

コンピューティング環境侵害
↓
IAMロールで影響を限定できる？

ロール悪用
↓
データアクセスで限定できる？

不正操作
↓
ログで追跡できる？

と、同じ攻撃経路を最後まで追います。

ここで見たいのは、

次に何が止めるか

です。

11. 「1回の侵害で重要資産まで到達する箇所」を探す

例えば、

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

という経路で、

アプリケーションを侵害
↓
データベースへ自由に接続
↓
データベースユーザーも広い権限
↓
全データ取得

となるなら、

アプリケーション侵害

が実質的に重要データの侵害へ直結しています。

この場合は、

ネットワーク経路
データベース認可
ワークロードアイデンティティ
データアクセス

など、経路上で残る防御を確認します。

レビュー結果は、

セキュリティグループがない

のようなサービス不足ではなく、

アプリケーション侵害後に
重要データへ到達するまで
独立した制限が残っていない

という形で表現します。

12. 複数の対策が同じ管理経路へ依存していないか確認する

見た目上は、

IAM
AWS WAF
セキュリティグループ
CloudTrail
KMSキーポリシー

という複数の対策があっても、

同じ強力な管理ロール

からすべて変更できる場合があります。

そのロールが侵害されると、

AWS WAF変更
セキュリティグループ変更
ログ設定変更
KMSキーポリシー変更

のように複数の層へ一度に影響できる可能性があります。

したがって、

何個の対策があるか

だけでなく、

それらを変更できる管理経路は
独立しているか

も確認します。

13. アーキテクチャ図にレビュー結果を重ねる

例えば、

インターネット
   │
   ▼
AWS WAF
   │
   ▼
ALB
   │
   ▼
EC2
   │
   ▼
Amazon RDS

という構成について、

アイデンティティ
EC2ロールが広すぎる

ネットワーク
RDSへの到達元が広い

コンピューティング
OSパッチ未適用

アプリケーション
リソース単位の認可不足

データ
データベースユーザーの権限が広い

ログ
重要な業務操作を記録していない

とレビュー結果を重ねます。

すると、

AWS WAFあり
RDSはプライベート

という表面的な状態ではなく、

アプリケーション侵害
↓
コンピューティング環境でコード実行
↓
広いロール利用
↓
データベースアクセス
↓
操作追跡困難

という具体的な攻撃経路が見えます。

14. レビュー表には「次に残る防御」を書く

例えば、

この表の目的は、

すべてのマスを埋める

ことではありません。

見るのは、

この対策が失敗した後
重要資産まで一直線になるか

です。

15. 同じ防御を増やすより「異なる失敗」を探す

例えば、

同じ通信条件を
複数の場所で繰り返し設定

しても、同じ設定ミスや同じ管理経路によってまとめて失敗する可能性があります。

一方で、

通信経路を限定

↓

ワークロードロールを限定

↓

アプリケーション認可

↓

データアクセスを限定

↓

操作を記録

のように、異なる地点で異なる失敗を扱えば、

1つの失敗
↓
そのまま重要資産侵害

となる可能性を下げられます。

ここではこの原則自体を覚えるのではなく、

既存アーキテクチャのどこで防御が途切れているかを見つける

ために使います。

16. レビュー例

対象：

インターネット
↓
ALB
↓
EC2 Webアプリケーション
↓
Amazon RDS

既存対策：

AWS WAFあり

セキュリティグループあり

RDSはプライベート

SSE-KMSあり

CloudTrailあり

ここで、

AWS WAFが
攻撃リクエストを見逃した

と仮定します。

次に確認します。

アプリケーション
↓
リソース単位の認可はある？

コンピューティング
↓
ランタイムに重大な脆弱性はない？

アイデンティティ
↓
EC2ロールは必要最小限？

ネットワーク
↓
EC2からどのデータベースへ到達可能？

データ
↓
データベースユーザーは必要なテーブルだけ？

ログ
↓
異常操作を追跡できる？

例えば結果が、

アプリケーション認可
不足

ランタイム
未更新

EC2ロール
広い

データベースユーザー
広い

アプリケーション監査ログ
なし

なら、

AWS WAFを越える
↓
アプリケーション侵害
↓
コンピューティング環境侵害
↓
広い認証情報
↓
データベースへ広くアクセス
↓
追跡困難

という攻撃経路が残っています。

これが横断レビューで見つけたい防御の空白です。

17. 改善後は同じ攻撃経路を再確認する

改善後に、

設定を変更した

だけで終了しません。

同じ攻撃経路をもう一度たどります。

AWS WAFを突破
↓
アプリケーション認可で制限

アプリケーション侵害
↓
ワークロードロールで影響を限定

ロール悪用
↓
データアクセスでさらに限定

不正操作
↓
ログで検知・追跡

となるか確認します。

改善前後で、

攻撃者が
どこまで進めるか

を比較します。

18. 混同しやすいポイント

19. SAP-C02での判断手順

既存アーキテクチャのセキュリティ改善問題では、最初にサービスを追加するのではなく、

守る資産
↓
攻撃経路

を特定します。

次に、

アイデンティティ
ネットワーク
コンピューティング
アプリケーション
データ
ログ

の視点で、その攻撃経路上に存在する対策を配置します。

その後、

主要な対策を1つ
機能しない状態にする

と仮定して、

次の防御は何か

その防御も越えたら何が残るか

最終的な影響範囲はどこまでか

侵害を追跡できるか

を確認します。

さらに、

複数の対策を
同じ管理ロールから
まとめて無効化できないか

も確認します。

最終的に、

1つの失敗
↓
重要資産へ一直線

となる箇所を改善候補として特定します。

まとめ

既存アーキテクチャをDefense in Depthの観点でレビューするときは、

セキュリティ対策一覧を作る

ことが目的ではありません。

見るのは、

守る資産
↓
攻撃経路
↓
既存の防御
↓
1つの防御を失敗させる
↓
残る防御
↓
共通依存
↓
最終的な影響範囲

です。

レビューでは、

アイデンティティ
ネットワーク
コンピューティング
アプリケーション
データ
ログ

という複数の視点を使って、同じ攻撃経路を横断的に確認します。

重要なのは、

1つの対策が破られたことではなく、その後に重要資産まで止めるものが残っているか

です。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional (SAP-C02) — Domain 3 / Task 3.2
• AWS Well-Architected Framework — Security Pillar
• AWS Well-Architected Framework — Security Design Principles
• AWS Well-Architected Framework — Infrastructure Protection
• AWS Security Reference Architecture