AWS Security本番運用Vol4｜Macie・Inspector・Network Firewall

1. この記事について — 多層防御を本番で組み上げる

1-1. 本記事のゴール

AWS のセキュリティ対策は、単一のサービスで完結するものではありません。
Vol4 では「何を守るか」という観点から4つの領域に分けて考えます。
S3 に格納されたデータへ潜む個人情報・認証情報を自動検出する データ保護、
EC2 インスタンスやコンテナイメージの既知の弱点を継続的に洗い出す 脆弱性管理、
VPC へ流入するトラフィックをアプリケーション層で制御する L7 防御、
そしてアプリケーション内の認可ロジックをポリシーとして外部化する アプリ認可 です。

この記事を読み終えた時点で、次の成果を得られます。

• Amazon Macie による S3 機密情報の自動検出フローを本番環境に適用できます
• Amazon Inspector で EC2 / ECR / Lambda の弱点を継続スキャンし、優先度付きで修正できます
• AWS Network Firewall でアプリケーション層のトラフィック制御と TLS 検査を設計できます
• Amazon Verified Permissions の Cedar ポリシーでアプリケーション認可を外部化できます
• Security Hub を集約ハブとした統合運用フローを組み立てられます

1-2. 読者像

本記事は次のような方を想定しています。

• AWS 上でサービスを運用するセキュリティエンジニア・クラウド基盤担当
• Vol3 で IAM / KMS / Secrets Manager を導入済みで、次の防御層を整備したい方
• SOC 編で GuardDuty / Security Hub を構築済みで、データ保護や弱点管理に踏み込みたい方
• PCI DSS・個人情報保護法などコンプライアンス要件へのマッピングを検討中の方
• SRE として「知らないうちにリスクが増えていた」状態をなくしたい方

AWS マネジメントコンソールの基本操作と IAM の基礎知識を前提としています。
各サービスの有効化手順と設定のポイントを実際の画面フローに沿って解説します。

Vol3 や SOC 編を読んでいなくても本記事単独で読めますが、
セキュリティシリーズ全体の棲み分けを理解した上で読むと設計判断がしやすくなります。

1-3. 本シリーズの位置づけと既存記事との棲み分け

AWS Security シリーズは3つの軸で構成されています。

Vol3（ID・暗号・シークレット・ZTNA） は「誰が・何にアクセスするか」を制御する基盤です。
IAM Access Analyzer による未使用権限の検出、KMS によるデータ暗号化、
Secrets Manager によるシークレット管理、Verified Access による ZTNA を扱います。

SOC 編（脅威検知・SIEM 集約） は「何か起きていないか」を監視する基盤です。
GuardDuty による脅威インテリジェンス連動の異常検知、Security Hub による CSPM 集約、
Detective による侵害経路の可視化を担当します。

本 Vol4（データ保護・脆弱性・L7 防御・アプリ認可） はその2つがカバーしない領域を補完します。
Vol3 が「アクセス制御」を担うのに対し、Macie は「既存データの中身」を評価します。
SOC 編が「脅威イベントの検知」を担うのに対し、Inspector は「弱点の予防的発見」を行います。
Network Firewall はアクセス制御より手前のトラフィック遮断を担い、
Verified Permissions はアプリケーション層の認可判定を構造化します。

下表は3軸の棲み分けをまとめたものです。

Security Hub は §6 で Macie / Inspector の検出結果を集約するハブとして使いますが、
脅威検知の本体は SOC 編に委ねます。

Security Vol3：IAM×KMS×Secrets×Verified Access を読む
脅威検知編：SOC(GuardDuty/Security Hub/Detective)を読む

1-4. 多層防御4層の全体像

Vol4 が扱う4サービスは、それぞれ独立しているのではなく、
1つの多層防御アーキテクチャの異なる層として機能します。

第1層: データ保護（Amazon Macie）
S3 バケットに蓄積されたデータを継続的に評価し、
個人情報・認証情報・財務情報が意図せず保存されていないかを識別します。
「データの問題はデータ層で捕捉する」という考え方が基本です。

第2層: 弱点管理（Amazon Inspector）
EC2 インスタンス・ECR コンテナイメージ・Lambda 関数を対象に、
既知の弱点を継続スキャンします。
パッチ適用漏れやライブラリの古いバージョンを自動検出し、
悪用される前に修正する「予防的アプローチ」を実現します。

第3層: L7 防御（AWS Network Firewall）
VPC に出入りするトラフィックをアプリケーション層（L7）でフィルタリングします。
Suricata 互換のシグネチャによる侵入検知と TLS 検査を組み合わせることで、
暗号化通信を含む不正なトラフィックを遮断します。

第4層: アプリ認可（Amazon Verified Permissions）
アプリケーションの認可ロジックを Cedar ポリシーとして外部化します。
「誰が・どのリソースに・何を実行できるか」をアプリコードから分離することで、
認可ルールの変更をコードデプロイなしに反映できます。

この4層は独立して導入でき、Security Hub を集約ハブとして検出結果を一元管理します。
既に Vol3 や SOC 編が動いている環境では、Vol4 の4層を加えることで
防御の網羅性が大きく向上します。

各層のサービスは AWS Organizations を使ったマルチアカウント環境に対応しており、
管理アカウントから一括有効化・一元管理が可能です。
§2〜§5 では各サービスの設定と運用設計を、§6 では統合運用フローを説明します。

4層をすべて一度に導入する必要はありません。
まず Macie で「今どんなデータがあるか」を把握し、
続いて Inspector で「どんな弱点があるか」を洗い出す段階的アプローチが、
多くの組織で現実的かつ効果的です。

2. Amazon Macie — 機密データの自動検出と分類

Amazon Macie は、S3 に保存されたオブジェクトを継続的に評価し、個人情報・認証情報・財務情報などを含むデータを自動的に識別するサービスです。
「バケットにどんな情報が入っているか把握していない」という状態を解消し、
コンプライアンスリスクと情報漏洩のリスク管理に直結します。

2-1. 自動機密データ検出(ASDD)と識別子設計

自動機密データ検出（Automated Sensitive Data Discovery、以下 ASDD） は、
Macie を有効化した環境で自動的に開始される継続評価の仕組みです。
AWS Organizations と連携することで、アカウント全体の S3 バケットをまとめて対象にできます。

ASDD の動作メカニズム

ASDD は毎日バケットインベントリを評価し、対象オブジェクトを統計的にサンプリングします。
すべてのオブジェクトを毎回スキャンするのではなく、代表的なオブジェクトを選んで分析することで、
スキャンコストを抑えながらバケット全体の傾向を把握できる設計になっています。

評価サイクルは通常 24 時間以内に更新されます。
設定を変更した場合も、次のサイクル開始時から反映されます。

ASDD の結果は S3 バケット統計 として蓄積されます。
「このバケットには個人情報を含む可能性が高い」というスコアリングで可視化されるため、
どのバケットを優先的に調査するかの判断材料になります。
全件精査（分類ジョブ）と組み合わせることで、より詳細な評価が可能です。

マネージドデータ識別子

AWS があらかじめ定義している識別子です。
クレジットカード番号・社会保障番号・パスポート番号・メールアドレス・API キーなど、
汎用的なパターンを網羅しています。
識別子は地域ごとに整理されており、日本向けにはマイナンバーや運転免許証番号に対応したものも含まれています。

ASDD および分類ジョブでは、デフォルトですべてのマネージド識別子が有効になります。
不要なものを除外することで誤検知を減らし、精度を高めることが可能です。

カスタムデータ識別子

組織固有の情報パターンを識別するために使います。
設定要素は次の3つです。

1. 正規表現（regex） — 一致させるテキストパターンを定義します
2. キーワード（文字シーケンス） — 正規表現の一致に加えて、近くに存在すべきキーワードを指定します
3. 近接ルール（proximity rule） — キーワードが正規表現の一致箇所から何文字以内に存在するかを設定します

例えば社員番号は EMP-\d{6} という正規表現と、
「社員番号」「employee」といったキーワードを近接条件に加えることで誤検知を抑えられます。

正規表現: EMP-\d{6}
キーワード: ["社員番号", "employee"]
近接: 50 文字以内

除外パターン（ignore words）を設定することで、
テストデータや固定的なサンプル値がノイズとして上がるのを防げます。

ASDD の有効化手順

1. Macie コンソールを開き「自動検出を有効化」を選択します
2. 対象スコープ（全バケット / 特定バケット）を選択します
3. 使用する識別子セット（マネージド / カスタム）を選択します
4. 設定を保存すると次の評価サイクルから自動的に開始されます

Organizations を使っているマルチアカウント環境では、
管理アカウントから組織全体の ASDD を一括有効化できます。

2-2. 分類ジョブと S3 バケット評価

ASDD が継続的なサンプリングを行うのに対し、分類ジョブ（Classification Job） は
特定のバケット・オブジェクトに対して全件精査するための機能です。
コンプライアンス監査時や、新たに作成されたバケットの初回評価に活用します。

分類ジョブは次の種別で実行できます。

ジョブ作成時に S3 バケット・プレフィックス・オブジェクトサイズの上限を指定できます。
大規模バケットでは、全件スキャンではなくサンプリング割合を設定してコストを管理することも有効です。

S3 バケットのアクセス制御評価

Macie は分類機能に加えて、バケット設定の状態を継続的に評価します。

• パブリックアクセス状態 — Block Public Access の設定状況を評価します
• 暗号化状態 — サーバーサイド暗号化（SSE-S3 / SSE-KMS）が有効かどうかを確認します
• アカウント外共有 — バケットポリシーや ACL によって組織外に共有されていないかを評価します

これらの評価結果は ポリシー検出結果（Policy Finding） として記録されます。
実際のオブジェクト内に機密情報が見つかった場合の 機密データ検出結果（Sensitive Data Finding） とは
別カテゴリで管理されるため、優先度の分類が容易になっています。

2-3. 検出結果（Finding）の運用と自動化連携

Macie が生成する検出結果には2種類あります。

コンソールでの確認と抑制

検出結果はコンソールの「Findings」画面で確認できます。
フィルタ条件（バケット名・識別子タイプ・深刻度・作成日時）で絞り込み、
詳細画面でどのオブジェクトの何行目に何が見つかったかを把握できます。

既知のデータ（テスト用バケット等）で継続的に上がり続ける検出結果は
抑制ルール（Suppression Rule） でアーカイブ状態にできます。
フィルタ条件に一致する検出結果を自動的に除外する仕組みで、
ノイズを減らして重要な結果に集中できます。

EventBridge を使った自動処理

Macie は検出結果をリアルタイムで Amazon EventBridge へ発行します。
EventBridge ルールを組み合わせることで、次のような自動化フローを組めます。

Macie Finding
 ↓ (EventBridge Rule)
Lambda / SNS / Systems Manager Automation
 ↓
Slack 通知 / バケットポリシー修正 / チケット起票

例えばパブリックアクセスが有効になったバケットを検知した瞬間に
Lambda でブロック設定を自動適用するフローが代表的なパターンです。

Security Hub との連携

Macie を Security Hub と連携すると、ポリシー検出結果が Security Hub に自動転送されます。
設定によっては機密データ検出結果も転送できます。
Security Hub 上で Inspector・Config 等の検出結果と一元管理し、
CSPM として組織全体のリスクスコアを継続的に把握することが可能になります。

Security Hub との連携は Macie コンソールの「設定」→「統合」から
ワンクリックで有効化できます。

2-4. Macie の有効化とコスト設計

有効化手順

1. AWS マネジメントコンソールで Macie を開き「Macie を有効化」をクリックします
2. Organizations 連携がある場合は管理アカウントから一括有効化できます
3. 有効化後、バケットインベントリの初期評価が始まります（数分〜数十分程度）
4. ASDD を有効化します（アカウントによってはデフォルトでオフのため要確認）

コスト構造

Macie の料金は主に次の要素で決まります。

最初の 30 日間は無料トライアルが適用されます。
コスト管理の観点では、全バケット常時全件スキャンは避け、
ASDD で傾向を把握してからリスクの高いバケットに絞って分類ジョブを実行するのが現実的な設計です。

本番運用での推奨構成

• ASDD 常時有効 + ポリシー検出結果の EventBridge 転送（基本ベースライン）
• 月次分類ジョブ をリスクの高いバケット（個人情報処理系）に絞って実行
• Security Hub 連携 で他サービスの検出結果と一元管理
• 抑制ルール でテスト環境のノイズを除去し、本番環境の結果に集中

2-5. ハンズオン: Macie の有効化と初回スキャン確認

実際に Macie を有効化して、結果を確認するまでの流れを説明します。

ステップ1: Macie の有効化

1. AWS マネジメントコンソールで「Amazon Macie」を検索して開きます
2. 「Macie を有効化」ボタンをクリックします
3. Organizations 連携がある場合は「組織全体に展開」を選択します

ステップ2: ASDD の有効化

1. 左メニュー「自動検出」→「設定」を開きます
2. 「自動検出を有効化」をクリックします
3. スコープを「すべてのバケット」に設定します
4. 識別子セットはデフォルト（すべてのマネージド識別子）のまま保存します

ステップ3: バケット統計の確認

有効化後 24 時間以内に初回評価が完了します。

1. 「S3 バケット」メニューを開きます
2. バケット一覧に「機密データの可能性」スコアが表示されていることを確認します
3. スコアが高いバケットを選択し、詳細（オブジェクト数・推定コスト・暗号化状態）を確認します

ステップ4: 検出結果の確認

1. 「Findings」メニューを開きます
2. ポリシー検出結果（暗号化なし・パブリック公開等）が表示されていれば対処します
3. 機密データ検出結果がある場合は、オブジェクトのパスと識別子の種類を確認します

初回は ASDD の結果のみで全件スキャンを実施していないため、
リスクが高いと判断したバケットには別途分類ジョブを実行することを推奨します。

3. Amazon Inspector — 継続的脆弱性スキャン

3-1. 継続スキャン対象と CIS ベンチマーク

Amazon Inspector v2 は 2021 年に刷新されたマネージドサービスです。エージェントレスアーキテクチャを基本とし、SSM Agent が導入済みの EC2 インスタンスを中心に、EC2・Lambda・ECR コンテナイメージを対象とした継続的な評価を実施します。

EC2 インスタンス

EC2 では Systems Manager と連携し、インスタンス起動後や新しいパッケージの追加を検知するたびに近リアルタイムで評価を開始します。AMI のビルド直後から本番稼働中まで一貫したカバレッジを確保できます。評価は AWS が管理する National Vulnerability Database (NVD) および各ベンダのセキュリティアドバイザリを参照して行われます。

SSM Agent のバージョンが古い場合や、インスタンスプロファイルに必要な IAM 権限が付与されていない場合は、コンソール上で Not Scanning と表示されます。有効化前に SSM Fleet Manager でエージェントの状態を確認しておくと、展開後のトラブルを減らせます。

Lambda 関数

Lambda 関数については、関数レイヤーを含むパッケージ内の依存ライブラリを解析します。デプロイのたびに自動で評価が走ります。CI/CD パイプライン経由でデプロイした直後のバージョンも即座に評価されます。コード自体のロジックではなく、依存パッケージに含まれる既知の CVE が検出対象です。

Lambda コード評価オプションを有効にすると、関数コード内の認証情報の埋め込みや設定ミスも検出対象に加わります。パッケージ評価とコード評価はそれぞれ独立してオン/オフできます。

ECR コンテナイメージ

ECR にプッシュされたコンテナイメージは、イメージレイヤー内の OS パッケージや言語ランタイムのパッケージを解析します。2025 年時点で対応エコシステムは大幅に拡張されており、Go モジュール・Oracle JDK・Amazon Corretto・Apache Tomcat・httpd・Node.js 向けのパッケージ識別が追加されています。

ECR リポジトリで継続スキャンを有効化すると、同じイメージでも新しい CVE が公開された際に再評価が自動的にトリガーされます。プッシュのたびだけでなく、脅威情報の更新タイミングでも再評価されることが、単純なプッシュ時スキャンとの大きな違いです。

CI/CD パイプライン統合

CodePipeline と組み合わせることで、ビルドステージで生成されたアーティファクトをパイプライン内で評価し、問題が検出された場合にパイプラインを停止できます。本番環境へのデプロイ前にゲートを設けることで、問題のあるイメージが稼働環境に到達するリスクを下げられます。

GitHub Actions や Jenkins など外部 CI との統合では、ECR へのプッシュ後に Inspector の評価完了を待機するステップを挿入し、最終スコアが閾値を超えた場合にパイプラインを失敗にする実装が一般的です。

CIS ベンチマーク評価

Inspector のホスト評価機能として、CIS (Center for Internet Security) ベンチマークへの適合状況を確認できます。対応プロファイルは以下のとおりです。

• CIS Benchmark Level 1 / Level 2 : Amazon Linux 2
• CIS Benchmark Level 1 / Level 2 : Amazon Linux 2023
• CIS Benchmark Level 1 / Level 2 : Windows Server 2019
• CIS Benchmark Level 1 / Level 2 : Windows Server 2022

Level 1 は一般的な環境向けの基本設定要件を網羅します。Level 2 は高いセキュリティが求められる環境向けに、より厳格なチェックを追加したプロファイルです。評価結果は Inspector コンソールから確認できるほか、Security Hub のカスタム基準にも集約できます。

CIS ベンチマーク評価を有効化するには、Inspector コンソールの「設定」→「ソフトウェアとコンフィギュレーション評価」でホスト評価を有効にします。既存インスタンスへの適用はリージョン内で一括有効化が可能です。

3-2. 優先度付けと修復連携

Inspector は検出した各項目に対して「Amazon Inspector スコア」を算出します。このスコアは CVSS ベーススコアをベースとし、ネットワーク到達可能性・実際の経路の有無・現在の攻撃活動に関するインテリジェンスを加味した環境調整済みスコアです。

スコアの分類と対応目安を以下に示します。

EC2 インスタンスがインターネットに直接露出しているかどうか、ECR イメージが実際に ECS タスクとして稼働中かどうかといったコンテキストがスコアに反映されます。理論上のリスクと実運用上のリスクのギャップを縮めた優先順位付けが可能です。

たとえばある CVE の CVSS スコアが 7.5 (High) であっても、対象 EC2 インスタンスがプライベートサブネットに閉じており外部からの直接到達経路がない場合、Amazon Inspector スコアはそれより低くなります。反対に、インターネット到達可能な EC2 インスタンスで同じ CVE が検出された場合はスコアが高くなります。

Security Hub 連携

Inspector の検出結果は自動的に Security Hub に送信されます。Security Hub では ASFF (Amazon Security Finding Format) に変換された形で集約されるため、Macie や他サービスの結果と一元的に管理できます。Inspector と Security Hub を同一リージョンで有効化するだけで連携が開始します。追加の設定は不要です。

Security Hub 側では Inspector の結果に対してカスタムアクションを設定できます。特定条件を満たす検出結果を選択して手動でワークフローを起動する使い方のほか、自動化ルールを使って重要度に応じたラベル付けや通知経路の振り分けも可能です。

EventBridge による自動修復ワークフロー

EventBridge ルールを使うことで、Inspector の検出結果をトリガーとした自動修復を設計できます。イベントパターンの例を示します。

{
  "source": ["aws.inspector2"],
  "detail-type": ["Inspector2 Finding"],
  "detail": {
 "severity": ["CRITICAL"]
  }
}

このイベントパターンを持つ EventBridge ルールに Lambda 関数や Systems Manager Automation を結び付けることで、Critical の検出結果が生成された際にシステム管理者へ SNS で通知する、対象リソースを自動でタグ付けして後続の対応フローに乗せる、といったワークフローを構築できます。

EC2 インスタンスの自動隔離パターンでは、Lambda 関数がセキュリティグループを切り替えてインスタンスをネットワークから切り離します。ただし自動的なインスタンス停止やサービス変更は業務影響が大きいため、多くの場合は「通知と承認を組み合わせた半自動ワークフロー」が現実的な設計です。

ハンズオン: Inspector 有効化・スキャン確認・優先度フィルタ

以下の手順で Inspector を有効化し、最初の評価結果を確認できます。

1. 有効化: AWS Organizations の委任管理者アカウントまたは単独アカウントから Inspector コンソールを開き「有効化」を選択します。EC2・ECR・Lambda それぞれの評価タイプを選択します。Organizations 環境では member アカウントへの自動展開が可能です。

2. スキャン対象の確認: コンソールの「スキャン対象」タブで、EC2 インスタンスごとのステータス（Scanning / Not Scanning）を確認します。Not Scanning になる主な原因は SSM Agent の未導入またはインスタンスプロファイルの IAM 権限不足です。

3. 検出結果の優先度フィルタ: 「検出結果」タブで「Inspector スコア」列を降順ソートします。フィルタで 固定済 = いいえ・ステータス = アクティブ に絞り込むと、現在対処が必要な項目のみ表示されます。

4. ECR イメージの確認: ECR コンソールの対象リポジトリで「スキャン結果」タブを開くと、イメージレイヤーごとの評価結果が確認できます。Inspector コンソールの「コンテナイメージ」ビューでも同じ結果を一元的に参照できます。

5. CIS ベンチマーク結果の確認: 「検出結果」タブで タイプ フィルタを ソフトウェアとコンフィギュレーション に切り替えると、CIS ベンチマーク評価の結果のみを抽出できます。

有効化直後は既存リソースの評価が順次実行されます。大規模環境では数時間かかることがありますが、評価はバックグラウンドで動作するためリソースのパフォーマンスへの影響はありません。新規リソースは起動・プッシュ後に自動的に評価対象に追加されます。

4. AWS Network Firewall — L7 フィルタと TLS 検査

4-1. ステートフルルールグループと Suricata 互換ルール

AWS Network Firewall は VPC 内に Firewall Endpoint を配置し、そこを経由させることで L3〜L7 の通信制御を実施するマネージドサービスです。2024 年 11 月に内部の検査エンジンが Suricata 7.0 系へ更新され、最新のシグネチャ形式への対応が強化されました。

ルールグループの 2 種類

Network Firewall のルールグループには「ステートレス」と「ステートフル」の 2 種類があります。

ステートレスルールグループはパケット単位で評価します。送信元/送信先の IP アドレス・ポート番号・プロトコルなど 5 タプル情報のみを参照するため、非常に高いスループットで処理できます。アクションは「通過」「破棄」「ステートフルエンジンへの転送」の 3 種類から選択します。

ステートフルルールグループはセッション単位で評価します。コネクションの状態を追跡し、戻り方向のパケットも同一セッションとして扱います。ルールの記述形式は「ドメイン名リスト」「標準的な 5 タプル形式」「Suricata 互換形式」の 3 種類から選択できます。

Suricata 互換形式の基本構文

Suricata 互換形式では、ドメイン名リストや 5 タプルで表現しにくい条件を柔軟に記述できます。通過ルールの基本例を示します。

pass http $HOME_NET any -> $EXTERNAL_NET 443 (msg:"Allow HTTPS egress"; sid:1001; rev:1;)

このルールは内部ネットワークから外部への HTTPS 通信を通過させる設定です。msg フィールドに目的を記載し、sid で一意の識別番号を割り当てます。

DNS 問い合わせを対象にした設定の例です。

drop dns $HOME_NET any -> any 53 (msg:"Block unwanted DNS"; dns.query; content:"badexample.com"; sid:1002; rev:1;)

dns.query キーワードを使うことで、DNS クエリのペイロードに対して content マッチを評価できます。特定ドメインへの問い合わせのみを対象にした通信制御が可能です。

1 つのコードブロックに多数の記述を詰め込まず、目的ごとにルールグループを分割して管理すると保守性が向上します。

評価順序と Firewall Policy

Firewall Policy がルールグループを束ねます。ポリシー内でステートレスルールグループのアクションが「転送」の場合にのみ、ステートフルエンジンへ進みます。ステートフルルールグループ間の優先度はポリシー内の順序で、ルールグループ内の評価順序はグループレベルの設定で制御します。

いずれのルールにもマッチしなかったパケットの扱いはポリシーで明示的に指定します。明示しないと予期しない通信を通過させる恐れがあるため、ポリシー作成時にステートフルデフォルトアクションを Drop established に設定することを推奨します。

AWS マネージドルールグループ

AWS が管理する「マネージドルールグループ」も利用できます。既知の不審な通信パターンに対するシグネチャを AWS が継続的に更新するため、独自のシグネチャ管理コストを抑えたい場合に有効です。有効化は Firewall Policy の編集画面から数クリックで完了します。マネージドルールグループとカスタムルールグループを組み合わせて使うことも可能です。

4-2. TLS 検査と VPC ルーティング統合

TLS 検査の仕組み

HTTPS など TLS で暗号化された通信はペイロードが不透明なため、L7 のコンテンツ制御ができません。Network Firewall の TLS 検査機能を使うと、暗号化された通信を一時的に確認し、設定した条件に基づいてフィルタリングしたうえで再び暗号化して転送できます。この処理は「復号・再暗号化」と呼ばれます。

TLS 検査を有効化するには、以下の準備が必要です。

1. ACM 証明書の準備: ACM (AWS Certificate Manager) で証明書を作成します。Firewall Endpoint がクライアントに対して提示する証明書です。社内クライアント向けの場合は、自己署名 CA または社内 CA をクライアントが信頼するよう設定します。

2. TLS 検査設定の作成: Network Firewall コンソールで「TLS 検査設定」を新規作成します。アウトバウンド（内部→外部）とインバウンド（外部→内部）でそれぞれ設定が必要です。

3. SNI マッチングによる対象絞り込み: TLS の拡張フィールドである SNI (Server Name Indication) を参照して、復号・再暗号化の対象ドメインを絞り込めます。全通信ではなく特定ドメインへの通信のみを検査対象にすることで、処理コストを抑えながら必要な可視性を確保できます。

URL フィルタリングとドメインカテゴリ

ステートフルルールグループの「ドメイン名リスト」タイプを使うと、許可するドメインの一覧（許可リスト）や遮断するドメインの一覧（拒否リスト）を簡潔に記述できます。

.amazonaws.com
.github.com
.npmjs.com

このドメイン名リストを持つルールグループを Firewall Policy に組み込むと、リスト外のドメインへのアクセスを止められます。Egress 制御のベースとして活用すると、想定外の外部通信を効率よく制限できます。

ドメインカテゴリフィルタは、AWS が分類したカテゴリデータベースに基づいてカテゴリ単位で通信を制御する機能です。個別ドメインを列挙せずに広いカテゴリをまとめて扱えます。

VPC ルーティング統合

Network Firewall は VPC 内に専用サブネットを作成し Firewall Endpoint を配置します。トラフィックが Endpoint を経由するよう VPC のルートテーブルを変更することでインラインに動作します。

主要な 3 つのトラフィックパターンに対応するルーティング設計を示します。

(1) Egress 制御（VPC → Internet）

プライベートサブネット → Firewall Endpoint → パブリックサブネット（NAT Gateway） → Internet Gateway の経路でルーティングします。プライベートサブネットのルートテーブルでデフォルトルート（0.0.0.0/0）の送信先を Firewall Endpoint ID に設定します。

(2) Ingress 制御（Internet → VPC）

Internet Gateway の Ingress ルートテーブルで、VPC CIDR 宛のトラフィックを Firewall Endpoint 経由に変更します。インターネットからの通信がアプリケーション層へ届く前に検査されます。

(3) East-West 制御（VPC 間）

Transit Gateway と組み合わせると、VPC 間のトラフィックを集中的に検査できます。Transit Gateway のルートテーブルでトラフィックを Inspection VPC 内の Firewall Endpoint へ向けることで、ハブアンドスポーク構成を実現します。

ハンズオン: Firewall 作成・ルールグループ設定・VPC ルーティング

基本的な Egress 制御を構成する手順を示します。

1. Firewall Endpoint 用サブネット作成: 各 AZ に /28 以上のサブネットを 1 つずつ作成します。Firewall 専用サブネットとして他のリソースを配置しません。

2. ルールグループ作成: Network Firewall コンソールで「ルールグループ」→「作成」を選択します。「ドメイン名リスト」タイプで許可ドメインを列挙し、デフォルトアクションを設定します。

3. Firewall Policy 作成: 「ポリシー」→「作成」でポリシーを作成します。先ほどのルールグループを追加し、ステートフルデフォルトアクションを Drop established に設定します。

4. Firewall 作成: 「ファイアウォール」→「作成」から対象 VPC とサブネットを選択し、Firewall Policy を割り当てます。Endpoint ID（vpce-xxxxxxxxx）が払い出されます。

5. ルートテーブル変更: プライベートサブネットのルートテーブルで 0.0.0.0/0 の送信先を Firewall Endpoint ID に変更します。変更後、許可ドメインへの通信が通り、それ以外が止まることを確認します。

6. ログの有効化: 「ログ記録」タブからフローログと通知ログの出力先（CloudWatch Logs または S3）を設定します。ログで実際に評価された通信の傾向と設定の効果を確認できます。

Firewall Endpoint は AZ ごとに作成されます。Multi-AZ 構成の VPC では、各 AZ のサブネットに Endpoint を配置し、同じ AZ のプライベートサブネットから対応する Endpoint へトラフィックを向けることで、AZ 間のレイテンシとコストを最小化できます。

5. Amazon Verified Permissions — Cedar によるアプリ認可

5-1. policy store・スキーマ設計と Cedar ポリシー

Amazon Verified Permissions は、policy store と呼ばれる認可エンジンを中核とします。policy store は Cedar ポリシー言語で記述された認可ポリシーを保存・評価する専用サービスです。

policy store の基本構成

policy store 内には、Cedar ポリシーと schema(スキーマ)が格納されます。スキーマは、principal(ユーザー)・action(アクション)・resource(リソース)の型を定義します。

@namespace("MyApp")

entity User = {
  email: String,
  department: String
};

entity Resource = {
  owner: User
};

action ViewDocument { principal: [User], resource: [Resource] };
action DeleteDocument { principal: [User], resource: [Resource] };
action AdminPanel { principal: [User], resource: [Resource] };

このスキーマは、User(principal) が Document(resource) に対して ViewDocument・DeleteDocument・AdminPanel のいずれかを実行する認可判定を定義します。

Cedar ポリシー言語の基礎

Cedar は AWS 開発の OSS 認可言語です。ポリシーは permit または forbid で始まり、principal・action・resource・条件を指定します。

permit (
  principal == User::"alice@example.com",
  action == ViewDocument,
  resource
)
when { resource.owner == principal };

このポリシーは、alice@example.com ユーザーが自分の所有するドキュメントのみ閲覧できることを定義します。permit は明示的許可、forbid は明示的拒否です。Verified Permissions は全ポリシーを評価し、1件でも forbid がマッチすれば拒否、マッチしなければ permit の結果に従います。

Cognito user pool 属性から principal 型を生成

Verified Permissions の強力な点は、Cognito user pool の属性をスキーマの principal 型に自動マッピングできることです。

Cognito で定義した属性:

cognito:username = alice
cognito:email = alice@example.com
custom:department = Engineering
custom:team = Platform

スキーマで principal 型を定義:

entity User = {
  department: String,
  team: String
};

identity source を設定することで、Cognito JWT トークンから自動的に principal の属性を抽出・型キャストします。

5-2. IsAuthorizedWithToken と Cognito 連携

Verified Permissions が Lambda・API・アプリケーションと連携するときの主要 API が IsAuthorizedWithToken です。

IsAuthorizedWithToken の呼び出しフロー

アプリケーション(Lambda 関数など) は以下のステップで認可判定を実施します:

1. クライアント(ブラウザ・モバイルアプリ) が Cognito に認証 → Cognito ID token 取得
2. アプリケーション が IsAuthorizedWithToken API を呼び出し、token + principal・action・resource を送信
3. Verified Permissions が token を JWT デコード → identity source で principal 型に変換
4. Cedar ポリシー評価 → permit/forbid/explicit deny の判定結果を返却

{
  "policyStoreId": "ps-abc123",
  "token": "{COGNITO_ID_TOKEN}",
  "identitySourceId": "is-def456",
  "action": {
 "actionType": "ViewDocument"
  },
  "resource": {
 "entityType": "Document",
 "entityId": "doc-789"
  },
  "entities": {
 "entityDetails": [
{
  "entityType": "Document",
  "entityId": "doc-789",
  "attributes": {
 "owner": {
"entityValue": {
  "entityType": "User",
  "entityId": "alice@example.com"
}
 }
  }
}
 ]
  }
}

このリクエストに対し Verified Permissions は ALLOW または DENY を返却します。

Claims mapping によるカスタム属性マッピング

Cognito に custom:department や custom:role などカスタム属性を定義し、Cedar ポリシーで利用する場合、identity source で claims mapping を設定します:

{
  "principalIdClaim": "cognito:username",
  "descriptiveId": "aud",
  "customClaimsMapper": {
 "department": "custom:department",
 "role": "custom:role",
 "costCenter": "custom:cost_center"
  }
}

これにより Cognito JWT の custom:department claim が Cedar の principal.department として自動利用可能になります。

アプリ認可の外部化パターン

従来、Lambda 関数内にアクセス制御ロジックを埋め込む場合:

// 推奨されないパターン: 認可ロジックがアプリに混在
if (user.department === "Engineering" && resource.isPublic) {
  allowAccess();
} else {
  denyAccess();
}

Verified Permissions を活用すると、認可判定を外部化できます:

// 推奨パターン: 認可判定を Verified Permissions へ委譲
const verifiedPermissions = new AWS.VerifiedPermissions();
const response = await verifiedPermissions.isAuthorizedWithToken({
  policyStoreId,
  identitySourceId,
  token: cognitoIdToken,
  action: { actionType: "ViewDocument" },
  resource: { entityType: "Document", entityId: resourceId }
});

if (response.decision === "ALLOW") {
  // アクセス許可
} else {
  // アクセス拒否
}

このパターンにより:
– ポリシー変更が Lambda デプロイを不要にする
– 複数の Lambda・API Gateway で統一ポリシーを共有可能
– 監査・ポリシー追跡が一元管理される

Verified Access(Vol3)との明確な棲み分け

⚠️ 重要: AWS Security Vol3 で説明する Verified Access と Verified Permissions は異なるサービスです。

Verified Permissions はアプリ内の柔細い認可、Verified Access は企業ネットワーク層のアクセス制御です。本セクションはアプリ認可に集中し、ネットワークエッジの ZTNA 実装は Vol3 を参照してください。

ネットワークエッジでCedarを使うVerified Access編：Security Vol3 を読む

6. 統合運用・自動修復 — Security Hub 集約と通知設計

6-1. Security Hub による findings 集約

Amazon Security Hub は AWS セキュリティサービスからの findings(セキュリティ上の発見)を一元集約するため、統合運用の中心となります。

Macie・Inspector・Network Firewall の findings 統合

Macie・Inspector・Network Firewall が検出した問題は、各サービスのコンソールに表示されるだけでなく、Security Hub に自動的に集約されます。

• Macie findings: 機密データの検出 (PII・クレジットカード番号 等)
• Inspector findings: 脆弱性評価結果 (CVE・CIS ベンチマーク違反 等)
• Network Firewall findings: IDS/IPS アラート・TLS 検査違反 (ブロック通信 等)

Security Hub は AWS Security Finding Format (ASFF)と呼ばれる統一フォーマットで findings を正規化します。これにより複数サービスの findings を統一的に検索・フィルタ・自動修復対象として取り扱えます。

Security Hub での findings 管理

Security Hub コンソールでは findings を以下の観点で分類できます:

[Resource Type] ---- S3 Bucket / EC2 Instance / Lambda Function / ...
 ↓
[Severity] -------- CRITICAL / HIGH / MEDIUM / LOW / INFORMATIONAL
 ↓
[Status] --------- NEW / NOTIFIED / SUPPRESSED / RESOLVED
 ↓
[Record State] --- ACTIVE / ARCHIVED

各 finding には以下の情報が含まれます:

• Title: 問題の簡潔な説明 (例: “Macie Found Sensitive Data”)
• Severity: 重要度スコア (0.0〜10.0)
• Resource: 影響を受けた AWS リソース (ARN)
• Remediation: 修復ガイダンス (Lambda スクリプトへのリンク等)
• Compliance: PCI DSS・CIS 等の規格適合状況

Findings 集約による効率化

複数サービスの findings を集約すると:
– セキュリティチームが一箇所で全体リスク把握可能
– 誤検知・既知問題を Suppression Rules で一括対象外化
– EventBridge 経由で自動修復・通知ワークフロー構築可能

6-2. EventBridge 連携・自動修復・通知設計

Security Hub findings を基に自動修復・通知するする場合、EventBridge が統合パイプライン役となります。

EventBridge ルールの設計

Security Hub の findings 発生時に EventBridge ルールが起動し、Lambda・SNS・SSM Automation を呼び出します:

{
  "Name": "SecurityHubFindingsAutomation",
  "EventPattern": {
 "source": ["aws.securityhub"],
 "detail-type": ["Security Hub Findings - Imported"],
 "detail": {
"findings": {
  "Severity": {
 "Label": ["CRITICAL", "HIGH"]
  },
  "Status": {
 "Value": ["NEW"]
  },
  "Type": [
 "TTPs/Findings/*",
 "Unclassified/Data Protection",
 "Software and Configuration Checks/*"
  ]
}
 }
  },
  "Targets": [
 {
"Arn": "arn:aws:lambda:region:account:function:AutoRemediationFunction",
"RoleArn": "arn:aws:iam::account:role/EventBridgeToLambdaRole"
 },
 {
"Arn": "arn:aws:sns:region:account:SecurityAlertsTopicArn",
"RoleArn": "arn:aws:iam::account:role/EventBridgeToSNSRole"
 }
  ]
}

このルールは CRITICAL・HIGH な新規 findings をキャッチし、Lambda と SNS トピックに転送します。

Lambda による自動修復パターン

Security Hub findings を受け取った Lambda 関数は、サービス別に修復操作を実行します:

import json
import boto3

def auto_remediate(event, context):
 finding = event['detail']['findings'][0]
 finding_type = finding['Type']
 resource_id = finding['Resources'][0]['Id']

 if 'Software and Configuration Checks' in finding_type:
  # Macie の S3 バケット問題
  remediate_s3_bucket(resource_id)
 elif 'TTPs/Findings' in finding_type:
  # Inspector の脆弱性
  remediate_instance(resource_id)
 elif 'Unclassified/Data Protection' in finding_type:
  # Network Firewall アラート
  remediate_firewall_rule(resource_id)

def remediate_s3_bucket(bucket_arn):
 s3 = boto3.client('s3')
 bucket_name = bucket_arn.split(':')[-1]

 # S3 ブロックパブリックアクセス有効化
 s3.put_public_access_block(
  Bucket=bucket_name,
  PublicAccessBlockConfiguration={
'BlockPublicAcls': True,
'IgnorePublicAcls': True,
'BlockPublicPolicy': True,
'RestrictPublicBuckets': True
  }
 )

def remediate_instance(instance_arn):
 ssm = boto3.client('ssm')
 instance_id = instance_arn.split('/')[-1]

 # SSM Automation で脆弱性修復(OS パッチ等)
 ssm.start_automation_execution(
  DocumentName='AWS-RunPatchBaseline',
  Parameters={'InstanceId': [instance_id]}
 )

SNS + ChatBot による通知

SNS トピックに発行された findings は、AWS ChatBot を経由して Slack に通知されます:

{
  "Finding": "CRITICAL: S3 Bucket 'data-lake' has public read access",
  "Resource": "arn:aws:s3:::data-lake",
  "Severity": "CRITICAL",
  "RemediationAction": "Lambda: auto-remediate-s3-public-access",
  "Dashboard": "https://console.aws.amazon.com/securityhub/findings"
}

Slack メッセージテンプレート:

🚨 セキュリティアラート
━━━━━━━━━━━━━━━━━━━━━━━━
タイプ: Macie - Public S3 Bucket
重要度: CRITICAL
対象: arn:aws:s3:::data-lake
自動修復: 実行中 (Lambda)
Dashboard: [Link to Security Hub]

コスト最適化と Findings 抑制

Security Hub の costs は findings 数に比例します。不要な findings を抑制することでコスト削減・アラート疲れ軽減が可能です。

{
  "Name": "SuppressLowSeverityFindings",
  "Criteria": {
 "Type": [
{
  "Value": "Software and Configuration Checks/AWS Security Best Practices",
  "Comparison": "EQUALS"
}
 ],
 "Severity": [
{
  "Value": "LOW",
  "Comparison": "EQUALS"
}
 ],
 "RecordState": [
{
  "Value": "ARCHIVED",
  "Comparison": "EQUALS"
}
 ]
  },
  "Actions": {
 "FindingFieldsUpdate": {
"Note": {
  "Text": "Suppressed: Low-severity archived findings",
  "UpdatedBy": "SecurityAutomation"
}
 }
  }
}

低重要度・アーカイブ済みの findings は自動抑制され、コストダッシュボードから除外されます。

SOC シリーズとの棲み分け

⚠️ 重要: 本セクションは Macie・Inspector・Network Firewall の findings 集約に焦点をあてています。

GuardDuty・Detective による 脅威検知・インシデント検査 は AWS Security SOC シリーズで詳細に解説します:

脅威検知・SOC 運用の詳細については AWS Security SOC シリーズを参照してください。

脅威検知のSecurityHub深掘りはSOC編へ：GuardDuty/Detective統合運用

7. 実戦統合パターン — 多層防御の本番導入

7-1. コンプライアンス要件から逆算する段階的導入ロードマップ

PCI DSS・ISO 27001・個人情報保護法などのフレームワークが求める要件を整理し、Vol4 の 4 サービスを段階的に導入するロードマップが実務では最も有効です。

Phase 1 (0〜3 ヶ月): 現状把握と測定基準の確立

まず機密データの所在と既存環境の保護状態を数値化します。
Macie を有効化して自動機密データ検出(ASDD)を開始し、S3 バケットに含まれる機密情報の種類と分布を把握します。
同時に Inspector を有効化し、EC2・ECR の CVE 状況をベースライン測定します。
この段階ではルールを追加せず、「今どれだけのリスクが存在するか」を正確に把握することが目的です。

Phase 2 (3〜6 ヶ月): 検出精度の向上と防御レイヤーの追加

Macie のカスタムデータ識別子でフォールスポジティブを削減し、重要バケットのスキャン優先度を調整します。
Network Firewall を本番 VPC の重要なサブネットに適用し、アウトバウンドトラフィックのドメインフィルタリングを開始します。
Inspector の Lambda スキャンを追加し、サーバーレス環境のカバレッジを拡大します。

Phase 3 (6〜12 ヶ月): 認可の外部化とポリシーの成熟

Verified Permissions に重要アプリケーションの認可ロジックを移行します。
Cedar ポリシーをコードとして Git 管理し、認可変更を審査・記録するワークフローを整備します。
Network Firewall の TLS 検査を対象範囲に段階的に拡大します。

コンプライアンスフレームワークとのマッピング:

7-2. Vol4 サービスと Vol3/SOC の実戦的な組合せ

本番環境で効果を最大化するには Vol4 の 4 サービスを単独で使わず、Vol3・SOC と組み合わせます。

多層防御スタックの全体像:

[ID レイヤー] IAM Identity Center (Vol3) — ユーザー管理・SAML 連携
[暗号・シークレット]KMS + Secrets Manager (Vol3) — 鍵管理・認証情報保護
[ZTNA] Verified Access (Vol3) — VPN 不要ゼロトラストアクセス
──────────────────────────────────────────────────────────────────
[データ保護] Macie (Vol4) — S3 機密データ継続検出
[保護状態の評価]Inspector (Vol4) — EC2/ECR/Lambda の CVE スキャン
[ネットワーク制御] Network Firewall (Vol4) — L7 フィルタ・TLS 検査
[認可] Verified Permissions (Vol4) — Cedar によるアプリ認可
──────────────────────────────────────────────────────────────────
[脅威検知]GuardDuty + Security Hub + Detective (SOC) — SIEM 集約

Macie + Inspector + Security Hub の自動応答パターン:

Macie が機密データを含むバケットで公開設定の findings を検出 → Security Hub 経由で EventBridge ルールを発火 → Lambda が自動的にバケットのパブリックアクセスブロック設定を有効化します。
Inspector が CRITICAL CVE を検出 → Security Hub 経由でチケット自動発行 → パッチ適用の SLA タイマーを起動するフローも実用的です。

Network Firewall と WAF の役割分担:

AWS WAF は CloudFront・ALB の手前でアプリケーション層リクエストを検査するのに対し、Network Firewall は VPC 内のネットワーク層でトラフィックを制御します。
外部公開 API には WAF、VPC 間通信やオンプレ間通信には Network Firewall という分担が標準的です。

7-3. コスト試算と導入優先度の考え方

Vol4 サービスのコスト特性を理解し、ROI の高い順に導入するのが現実的です。

コスト最適化の最重要ポイントは「スキャン対象の絞り込み」です。
Macie は機密データが存在しない可能性の低いバケット(ログ専用・ビルドアーティファクト等)を ASDD 除外リストに入れることでコストを大幅に削減できます。
Inspector は停止中の EC2 インスタンスには課金されないため、検証環境のインスタンスを使い終わったら停止する習慣をつけます。

ROI 測定の考え方:

多層防御の投資対効果は「検出した findings のビジネスリスク換算」で定量化できます。
たとえば、Macie が検出した機密データの公開バケットを修正することで、GDPR や個人情報保護法に基づく制裁リスクを低減できます。
Inspector が発見した CRITICAL CVE をパッチ適用することで、不正アクセスのリスクを数十万〜数百万円規模で回避できるケースがあります。
セキュリティ投資の承認プロセスでは、「月に何件の CRITICAL findings を検出・対処したか」「SLA 内の対処率は何%か」などの KPI を定期的に経営層へ報告する体制を整えましょう。

本番稼動前のチェックリスト:

Vol4 の 4 サービスを本番適用する前に、以下の準備ができているかを確認します。

コンプライアンス自動化：Config Conformance Pack 自動修復編を読む

8. 詰まりポイント・アンチパターン・まとめ

8-1. 詰まりポイント(8選)

実際の運用で直面しやすい問題と解決策を整理します。

詰まり① Macie — フォールスポジティブが多くてアラートを信頼できなくなる

原因: マネージドデータ識別子の感度が高いため、テスト用データや匿名化済みデータが findings として報告されます。
たとえば、マスク済みのカード番号(****-****-****-1234)がパターンにマッチするケースがあります。

解決策:
1. Suppression Rules を設定して、テスト用バケットや特定プレフィックスを除外します
2. カスタムデータ識別子に「除外パターン」として匿名化済みフォーマットを登録します
3. MEDIUM 以下の findings は週次レビューに格下げし、CRITICAL/HIGH のみリアルタイム対応します

Suppression Rule の設定例(コンソール操作):

フィルター条件: S3 バケット名 starts_with → "test-" または "dev-"
アクション: SUPPRESS

詰まり② Macie — スキャン対象外バケットが気づかないうちに生じる

原因: Organizations でアカウントを追加した際、新規アカウントの S3 バケットが ASDD の対象へ自動追加されない設定になっているケースがあります。

確認手順: Macie コンソール →「S3 バケット」→「分類スコープ」を確認します。
「自動機密データ検出」が「除外」になっているバケットを洗い出します。

定期的な棚卸しとして、月次で対象バケット数を記録しておくと、意図しない除外の発生に早く気づけます。

詰まり③ Inspector — 既存 EC2 インスタンスがスキャン対象にならない

原因: Inspector は SSM Agent 経由でインスタンスを評価するため、SSM Agent が未インストール・古いバージョン・SSM 接続できない状態のインスタンスはカバレッジが 0% になります。

解決手順:
1. Inspector コンソール →「EC2 インスタンス」→「カバレッジ」フィルタを「カバレッジなし」に設定して対象インスタンスを特定
2. Systems Manager Fleet Manager でインスタンスの管理対象状態を確認
3. プライベートサブネットの場合、VPC エンドポイント(ssm / ec2messages / ssmmessages)が必要

詰まり④ Inspector — Lambda スキャンでカバーされない範囲がある

範囲を正確に理解することが重要です。Inspector の Lambda スキャンが対象とするのは、package.json や requirements.txt に記載されたサードパーティライブラリの CVE です。
カスタムコードのロジックや AWS マネージドランタイム自体は対象外です。

カバレッジのギャップ対策として、CI/CD パイプラインに pip-audit や npm audit を組み込み、Inspector と二重でカバーします。
Lambda ランタイムはマネージドランタイムを選択することで AWS 側のパッチ適用を受けられます。

詰まり⑤ Network Firewall — ドメインリストルールが意図通りに動作しない

原因1: HTTPS トラフィックは TLS 検査を有効化しないと SNI ベースのフィルタになります。
SNI 拡張を送信しないクライアントでは宛先ドメインを特定できず、ルールが機能しません。

原因2: ドメインリストの記述順序に注意が必要です。
より具体的なドメイン(api.example.com)を先に配置し、ワイルドカード(.example.com)を後に置きます。

確認手順: Network Firewall のフローログを CloudWatch Logs で確認し、REJECT アクションが意図したトラフィックに適用されているかを検証します。

詰まり⑥ Verified Permissions — Cognito 連携でクレームが取得できない

原因: Cognito ユーザープールのカスタム属性は JWT トークン内に custom: プレフィックス付きで格納されます(例: custom:department)。
Verified Permissions の Identity Source 設定でこのプレフィックスを考慮したクレームマッピングが必要です。

確認方法: JWT デコードツールで実際のトークン内容を確認し、Verified Permissions のエンティティマッピングと照合します。
aws cognito-idp admin-get-user でユーザー属性の実際の形式を確認するのも有効です。

詰まり⑦ Verified Permissions — Cedar スキーマが複雑化して管理不能になる

原因: リソース階層・アクション数・コンテキスト属性が増えるにつれてスキーマが肥大化します。
特に memberOfTypes(親リソースへの参照)を多用すると、ポリシーの影響範囲が読みにくくなります。

対策:
1. スキーマを JSON ファイルとして Git 管理し、変更は Pull Request でレビューします
2. cedar validate コマンドを CI に組み込み、スキーマとポリシーの整合性を継続確認します
3. リソース型の粒度は「認可判断の単位」に合わせ、細かすぎず粗すぎないよう設計します

詰まり⑧ Security Hub — findings 量が多くてトリアージが機能しない

Macie・Inspector・Network Firewall・GuardDuty を同時に有効化すると、1 日数百〜数千件の findings が集約されます。
全件を Slack や SNS に通知すると深刻なアラート疲弊が生じ、重要なアラートが見逃されます。

対策:
– Automation ルールで LOW/INFORMATIONAL を自動的にサプレスします
– Severity CRITICAL のみ即時通知、HIGH は営業時間内通知、MEDIUM 以下は週次レビューに分類します
– Custom Insights で繰り返し発生するパターンを可視化し、Suppression の候補を特定します

8-2. アンチパターン → 正解変換(6選)

アンチパターン① 全 S3 バケットにフルスキャンを常時実行

タグ管理が有効です。機密データが含まれる可能性のあるバケットに macie:scan=required タグを付与し、スキャン対象を明示的に管理します。
スキャン不要なバケット(ビルドアーティファクト専用・公開静的コンテンツ等)はタグで除外リスト管理します。

アンチパターン② Inspector を有効化したまま findings を放置

Inspector findings には「抑制」機能があります。
パッチが存在しない既知の問題や、補完的な制御で対処済みのリスクは明示的に Suppress し、残件数を正確に把握します。
月次でサプレス済み件数を棚卸しし、承認済みリスクとして記録します。

アンチパターン③ Network Firewall のルールを 1 つのグループに集約

推奨の分割構成:

RG-baseline (優先 100): AWS マネージド脅威インテリジェンス
RG-domain-allow (優先 200): アプリ許可ドメインリスト
RG-tls-inspection (優先 300): TLS 検査ポリシー
RG-emergency (優先 400): 緊急ブロック(インシデント対応用)

緊急ブロックグループを別途作成しておくと、インシデント発生時に影響範囲を局所化したまま迅速に対応できます。

アンチパターン④ 認可ロジックをアプリコードにハードコード

認可をコードから外部化することで、セキュリティチームがエンジニアのコードレビューを待たずに権限を変更できます。
認可リクエストとその結果は Verified Permissions 側で自動的にログに記録され、監査証跡として活用できます。

アンチパターン⑤ Security Hub の全 findings をリアルタイム通知

EventBridge ルールで Severity.Label を CRITICAL に絞り込み、PagerDuty や Slack の専用チャンネルに通知します。
それ以外は Security Hub の Weekly Digest や Custom Insights で週次確認します。

アンチパターン⑥ TLS 検査を全アウトバウンドトラフィックに一括適用

Certificate Pinning を使う SaaS(一部の決済・認証サービス等)はドメインを TLS 検査の除外リストに追加します。
除外リストの棚卸しを四半期ごとに実施して、不要な除外が蓄積しないよう管理します。

8-3. まとめと次のステップ

Vol4 では AWS の多層防御を実現する 4 サービスを解説しました。

Vol4 で構築した多層防御の全体像:

Macie がデータ保護の目として機密データを継続的に検出し、Inspector が EC2・ECR・Lambda の保護状態を定量的に評価します。
Network Firewall がネットワーク層の通過トラフィックをフィルタリングし、Verified Permissions がアプリケーションの認可を Cedar ポリシーで一元管理します。
これら 4 サービスが Security Hub に findings を集約し、EventBridge で自動応答するアーキテクチャが本番多層防御の標準形です。

シリーズ全体で積み上げたスタック:

次のアクション:

1. Security Hub の Custom Insights と QuickSight を組み合わせて経営層向けセキュリティダッシュボードを整備します
2. AWS Config Conformance Pack と連携してコンプライアンス状態を自動評価・レポート化します
3. Verified Permissions の Cedar ポリシーを GitOps で管理するワークフローを整備し、認可変更の審査プロセスを構築します

多層防御は「導入して終わり」ではなく、継続的な評価と改善のサイクルが重要です。
Macie・Inspector・Network Firewall・Verified Permissions の 4 サービスを定期的にレビューし、新しい要件変化に対応できる運用体制を整えましょう。

月次運用レビューチェックリスト:

以下の項目を月次で確認することで、多層防御の品質を維持できます。

Macie:
– ASDD の対象バケット数に変化がないか確認(新規バケット追加時に除外されていないか)
– 高優先度 findings の未対処件数を確認し、翌月内の対処計画を立案
– カスタムデータ識別子の精度を評価し、フォールスポジティブ率を記録

Inspector:
– EC2・ECR・Lambda の全体カバレッジ率を確認(目標 95% 以上)
– CRITICAL findings の SLA 達成率を計測(目標 100%)
– サプレス済み findings の棚卸しを実施し、承認済みリスクリストを更新

Network Firewall:
– ルールグループのヒット数を CloudWatch Metrics で確認(未使用ルールの削除)
– TLS 検査の除外リストを確認(不要なドメインが蓄積していないか)
– フローログで意図しないブロックが発生していないかを確認

Verified Permissions:
– Cedar ポリシーの変更履歴を確認し、意図しない権限拡大がないかを検証
– 認可リクエスト数のトレンドを確認し、急増がある場合は原因を調査
– cedar validate を定期実行してスキーマとポリシーの整合性を確認

このチェックリストを実施することで、Vol4 の 4 サービスの品質が継続的に維持できます。

Security Vol3：IAM×KMS×Secrets×Verified Access を読む
脅威検知 SOC 編：GuardDuty・Security Hub・Detective を読む
コンプライアンス自動化：Config Conformance Pack 自動修復編を読む
IAM Identity Center：SSO/Permission Sets/ABAC 本番運用を読む