認証情報、最小権限、追跡可能性、脆弱性、更新プロセス、バックアップ、自動修復について、それぞれの具体的な改善方法は既習です。

ここで扱うのは、それらをもう一度個別に学ぶことではありません。

セキュリティ検出結果を受け取ったときに、

どのサービスが検出した？

ではなく、

何が起きた？
↓
なぜ起きた？
↓
どの防御が不足していた？
↓
どの改善戦略へ接続する？

と判断することが中心です。

例えば1件の検出結果を調査して、

長期アクセスキーが漏えい

+

そのIAMロールの権限が広い

+

操作主体を追跡できない

ことが分かった場合、

認証情報管理だけ直す

では不十分です。

この事象には、

侵害の入口
↓
認証情報

侵害後の被害拡大
↓
最小権限

調査能力
↓
追跡可能性

という複数の問題があります。

ここでは、表面的な検出結果から根本原因と関連する防御不足を切り分け、適切な改善戦略を選択する方法を扱います。

ゴール

セキュリティ検出結果について、

• 検出元と改善対象を分ける
• 事象・根本原因・被害拡大要因を分ける
• 認証情報の問題を改善戦略へ接続する
• 過剰権限を改善戦略へ接続する
• 追跡不足を改善戦略へ接続する
• 脆弱性についてパッチ・更新・置換を使い分ける
• 復旧能力の不足をバックアップ改善へ接続する
• 自動修復が適切な問題か判断する
• 1件から複数の改善が必要な場合を見分ける
• 複数件を1つの根本原因へまとめる
• 改善後に実際の防御不足が解消したか確認する

ことを目指します。

1. 検出結果は「改善を始める証拠」

セキュリティ検出結果は、

異常な操作があった

脆弱性がある

設定が基準から外れている

危険な権限がある

といった事実を示します。

しかし、

何を改善すれば再発しないか

までは自動的に決まりません。

例えば、

Amazon GuardDuty
↓
不審な認証情報利用を検出

した場合でも、考えられる原因は、

長期認証情報が漏えい

共有認証情報を使用

不要な権限が付与

管理端末が侵害

追跡情報が不足

など複数あります。

したがって、

検出結果
↓
対策を即決

ではなく、

検出結果
↓
事実確認
↓
原因確認
↓
不足している防御を分類
↓
改善戦略を選択

と進めます。

2. 検出元と改善対象を分ける

Amazon Inspectorが重大な脆弱性を検出した場合、

検出元
=
Amazon Inspector

です。

しかしAmazon Inspectorが正常に問題を検出できているなら、

Amazon Inspectorが弱い

とは限りません。

問題が、

修正版あり
↓
しかし更新まで1か月放置

なら、改善対象は更新プロセスです。

同じように、

GuardDuty
↓
漏えいした認証情報

Security Hub CSPM
↓
過剰権限

AWS Config
↓
危険設定が繰り返し作成される

という場合、それぞれ検出サービスではなく、

実際に不足している防御

を改善します。

3. 事象を3つに分解する

1件の検出結果を調査するときは、最低でも、

侵害・問題の入口

被害を拡大した要因

検知・調査・復旧を難しくした要因

に分けます。

例えば、

アクセスキーを悪用
↓
Amazon S3から
機密データを大量取得

という事象があったとします。

調査結果が、

アクセスキー
↓
ソースコードへ保存

IAM権限
↓
すべてのS3操作を
すべてのS3リソースに許可

監査
↓
共有IAMユーザーのため
利用者を特定できない

なら、

入口
↓
認証情報管理

被害拡大
↓
最小権限

調査不足
↓
追跡可能性

です。

1件の検出結果でも、改善対象は複数存在します。

4. 「主因」と「被害拡大要因」を分ける

例えば、

長期アクセスキー漏えい

+

IAM権限が広い

という場合、

IAM権限を狭くする

だけでは、認証情報が漏えいする問題自体は残ります。

一方、

アクセスキーだけ交換

しても、次に認証情報が侵害されたときの影響範囲は広いままです。

したがって、

なぜ侵入できた？

と、

なぜ被害がここまで広がった？

を別々に考えます。

改善戦略も、

侵入経路を閉じる改善

+

侵入後の影響を限定する改善

という形で組み合わせることがあります。

5. 認証情報・最小権限・追跡可能性を同時に見る

認証情報に関する事象では、次の3つを同時に確認します。

認証情報
↓
侵害の入口は何だった？

権限
↓
侵害後に何ができた？

追跡
↓
誰が何をしたか分かる？

例えば、

共有された長期アクセスキー
↓
漏えい

+

IAMユーザー
↓
多数のサービスを操作可能

+

CloudTrail
↓
IAMユーザーまでは分かるが
実際の利用者は不明

なら、

認証情報管理

+

最小権限

+

追跡可能性

を組み合わせて改善します。

ここで重要なのは、どれか1つのカテゴリを当てることではなく、同じ攻撃経路に残っている複数の不足を見つけることです。

6. 脆弱性では「修正版があるか」を分岐点にする

Amazon Inspectorなどで脆弱性を検出した場合、

重大度が高い

だけでは改善方法を決められません。

まず、

修正版がある？

現在のOSやソフトウェアへ適用できる？

適用までの時間は許容できる？

を確認します。

例えば、

重大な脆弱性
↓
修正版あり
↓
現在の環境へ適用可能
↓
通常更新まで1か月

なら、

更新プロセスが遅い

ことが改善対象になり得ます。

一方、

重大な脆弱性
↓
製品サポート終了
↓
現在のバージョン向け修正版なし

なら、

パッチ頻度を上げる

だけでは解決できません。

この場合は、

サポート対象バージョンへ更新

ワークロードを置換

脆弱なコンポーネントを除去

などへ戦略を切り替えます。

7. 脆弱性の検出と更新プロセスの不足を区別する

例えば、

Amazon Inspector
↓
脆弱性をすぐ検出

できている一方で、

修正版あり
↓
承認済み
↓
しかし本番適用まで30日

なら、

検知

は機能しています。

問題は、

検知されたリスクを
許容時間内に解消できない

ことです。

したがって、

Amazon Inspectorを変更

ではなく、

通常更新

緊急更新

変更影響確認

適用後確認

を含む更新プロセス側へ改善を接続します。

8. 復旧能力に問題がある場合はバックアップ側へ接続する

セキュリティ事象の調査で、

本番データが破壊された場合
正常な状態へ戻せない

ことが分かる場合があります。

例えば、

毎日バックアップ成功

しかし

本番管理者が
復旧ポイントを削除可能

さらに

保持期間より
侵害発見までの時間が長い

なら、

バックアップジョブが失敗

しているわけではありません。

不足しているのは、

侵害後にも利用できる
復旧能力

です。

この場合は、

保持期間

管理境界

削除耐性

不変性

復元可能性

など、既習のバックアップ改善へ接続します。

9. 自動修復は「件数」ではなく「決定性」で選ぶ

同じ検出結果が何度も発生していても、

件数が多い
=
自動修復

とは限りません。

自動修復に向いているのは、

条件を明確に判定できる

修復方法が固定されている

変更影響を理解できる

失敗時の停止条件がある

ような問題です。

例えば、

禁止されたセキュリティグループルール
↓
毎回同じ条件
↓
既定の安全な設定へ戻す

なら自動化候補になり得ます。

一方、

侵害の可能性あり

影響範囲不明

原因不明

という事象で、

対象リソースを即削除

のような自動処理を行うのは危険な場合があります。

10. 自動修復より先に「再発させているもの」を探す

例えば毎週、

禁止されたセキュリティグループ設定

が検出され、

担当者
↓
毎週同じ設定へ戻す

という運用があるとします。

調査すると、

デプロイテンプレート
↓
毎週同じ危険設定を作成

しているかもしれません。

この場合、

自動修復を追加

するだけでは、

危険設定を作成
↓
自動修復
↓
再作成
↓
自動修復

を繰り返します。

改善戦略としては、

危険設定を生成する
デプロイ定義を修正

+

必要なら
自動修復を補助的に利用

とします。

11. 管理状態と実環境を分ける

Security Hub CSPMでは、Workflow.Statusによって検出結果の調査状況を管理できます。

例えば、

NEW

NOTIFIED

RESOLVED

SUPPRESSED

などです。

しかし、

RESOLVED

へ変更しただけで、

実際のIAMポリシー

セキュリティグループ

ログ設定

バックアップ

が自動的に改善されるわけではありません。

したがって、

管理上の状態

と、

実環境の防御状態

を分けます。

改善完了は、

実環境を修正
↓
再評価
↓
同じ不足が解消

まで確認します。

12. 優先度と改善方法を分ける

検出結果の重要度やリスク優先度は、

いつ対応するか

を決める材料です。

一方、

何を改善するか

は別の判断です。

例えば、

重大
+
原因不明
+
変更影響大

なら、

重大だから自動修復

とは限りません。

逆に、

中程度
+
大量に反復
+
安全な修復方法が固定

なら、自動化による改善効果が高い場合があります。

整理すると、

優先度
↓
いつ対応する？

改善戦略
↓
何を直す？

自動化判断
↓
どう実行する？

です。

13. 1件から複数の改善戦略を選ぶ

例えば、

不審なアクセスキー利用
↓
S3機密データ取得

という1件を調査し、

長期アクセスキー

ソースコードへ保存

IAM権限が広い

共有IAMユーザー

利用者追跡不能

だったとします。

この場合、

認証情報管理

+

最小権限

+

追跡可能性

が必要です。

ただし改善を列挙するだけではなく、

認証情報管理
↓
侵害の入口を減らす

最小権限
↓
侵害後の被害を限定する

追跡可能性
↓
発生時の調査能力を確保する

と、役割を説明できる必要があります。

14. 複数件を1つの根本原因へまとめる

逆に、

検出結果A
S3への不要な権限

検出結果B
DynamoDBへの不要な権限

検出結果C
KMSキーへの不要な権限

が、

同じアプリケーションロール

へ集中している場合があります。

この場合、

3件
↓
3つ別々の改善

と考えるより、

アプリケーションロールが
過剰権限

という1つの根本原因へまとめられます。

改善戦略は、

現在の利用実績と業務要件を確認
↓
必要な権限だけへ縮小

です。

15. 「その場の修正」と「根本改善」を分ける

例えば、

不要な
0.0.0.0/0ルール

が検出された場合、その場の修正は、

該当ルールを削除

です。

しかし原因が、

CloudFormationテンプレート
↓
毎回0.0.0.0/0を作成

なら、

テンプレート修正

まで進まなければ再発します。

したがって、

検出結果を消す

ことと、

同じ検出結果を
再発させない

ことを分けて考えます。

改善戦略では後者を重視します。

16. 改善戦略を選ぶための分類

調査した事実を、例えば次のように整理します。

この表は、

検出結果名
↓
改善策

の対応表ではありません。

必ず、

調査した事実
↓
不足している防御

を経由して使います。

17. 改善後は同じ原因を再評価する

例えば過剰権限を改善したなら、

検出結果が消えた

だけではなく、

不要な権限は削除された？

必要な機能は動作する？

別のロールに同じ問題はない？

デプロイによって
元の権限へ戻らない？

まで確認します。

同様に、

アクセスキー交換

を行ったなら、

長期認証情報を
再び同じ場所へ保存していない？

を確認します。

改善戦略は、

変更
↓
再評価
↓
副作用確認
↓
再発経路確認

まで含めます。

18. 一連の判断フロー

最終的には、

セキュリティ検出結果
↓
事実を確認
↓
影響したリソース・アイデンティティを確認
↓
侵害の入口を確認
↓
被害拡大要因を確認
↓
検知・調査・復旧上の不足を確認
↓
根本原因を特定
↓
改善戦略を選択
↓
必要なら複数戦略を組み合わせる
↓
実装
↓
再評価
↓
再発経路を確認

と進めます。

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

20. SAP-C02での判断手順

セキュリティ検出結果から改善戦略を選ぶ問題では、

どのAWSサービスが
検出したか

だけでは判断しません。

まず、

何が起きた？

を確認します。

次に、

なぜ起きた？

を確認します。

さらに、

何が被害を広げた？

何が調査を難しくした？

何が復旧を難しくした？

を確認します。

そこから、

認証情報

最小権限

追跡可能性

脆弱性

更新プロセス

バックアップ

自動修復

のどこへ改善を接続するか決めます。

最後に、

この改善は
根本原因を閉じる？

関連する防御不足は残らない？

同じ設定は再生成されない？

改善後も正常動作する？

まで確認します。

まとめ

セキュリティ検出結果から改善戦略を選ぶときは、

検出結果
↓
検出サービス
↓
そのサービスを強化

とは考えません。

見るべきなのは、

検出結果
↓
事実
↓
侵害の入口
↓
被害拡大要因
↓
調査・復旧上の不足
↓
根本原因
↓
改善戦略

です。

さらに、

1件
↓
複数の防御不足

になる場合もあれば、

複数件
↓
1つの根本原因

になる場合もあります。

重要なのは、検出結果を閉じることではなく、その事象を成立させた防御不足を改善し、同じ問題が再び成立しない状態へ変えることです。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional (SAP-C02) — Domain 3 / Task 3.2
• AWS Security Hub CSPM — Findings
• AWS Security Hub CSPM — Workflow status
• AWS Security Hub CSPM — Automation rules
• AWS Security Hub CSPM — Automated response and remediation
• Amazon Inspector — Finding details
• AWS Well-Architected Framework — Security Pillar