【ITニュース解説】From AWS Security Hub to Client-Ready HTML: A Private AI Reporting Pipeline

このニュース記事は、AWSのセキュリティサービスが生成する技術的な情報を、システムエンジニアを目指す人にもわかりやすく、クライアントが意思決定しやすい「セキュリティレポート」に変換する、AIを活用した自動化パイプラインについて解説している。

まず、セキュリティ情報の収集自体は、AWS Security Hub、Amazon GuardDuty、Amazon InspectorといったAWSのサービスを使えば比較的容易にできる。これらのサービスは、AWS環境の脆弱性や脅威に関する「発見」（ファインディング）を生成し、共通の形式（AWS Security Finding Format: ASFF）でSecurity Hubに集約する。しかし、集約された生の情報は、技術的な識別子、詳細な設定、修正手順の羅列など、専門家でなければ理解しにくい内容が多く、そのままではクライアント向けの意思決定を促すレポートとしては不十分であるという課題があった。

この課題を解決するために提案されているのが、「プライベートな2段階のAIレポートパイプライン」である。これは、仮想的なAWSアカウント（シンガポールリージョン）を想定した仕組みだ。

第1段階はAWSクラウド内で行われる。 具体的には、Security Hub、GuardDuty、Inspectorからのファインディングが、週次で起動するAWS Lambda関数に入力される。このLambda関数は、受け取ったファインディングを事前に定義されたルールに基づいて「決定論的」にランク付けする。決定論的とは、人間が定めた客観的なルールに従って、常に同じ条件で同じ優先順位をつけるという意味だ。例えば、脆弱性の深刻度や影響を受けるシステムの重要度などに基づき、優先度スコアを計算する。 次に、Lambdaは、今週のファインディングのスナップショットを前週のものと比較する。これにより、新しく発見されたもの、引き続き対応が必要なもの、すでに解決されたもの、内容が変更されたもの、そして今回検出されなかったが本当に解決したか確認が必要なもの（未観測）を正確に区別できる。この「状態の比較」は、誤った「解決済み」報告を防ぎ、レポートの信頼性を高める上で非常に重要である。 さらに、この段階ではAmazon BedrockというAIサービスと、そこで利用できるClaude Sonnet 4.6という大規模言語モデルが活用される。ただし、AIがリスク判断を勝手に変更するわけではない。AIの役割は、決定論的ロジックで選定された上位6つの修正候補に対して、経営層向けの簡潔な要約を作成したり、修正項目がなぜ重要なのかを説明したり、技術的な修正手順を人間が理解しやすい言葉に変換したりといった「物語作成支援」に限定される。AIが生成する内容はJSON形式に制限され、Lambdaで検証されるため、予期せぬ出力がレポートに混じるのを防ぐ。 最終的に、このLambda関数はMarkdown形式のレポートと、詳細な証拠となるHTMLアーティファクトを生成し、AWS S3バケットに保存する。S3バケットは暗号化され、厳重にアクセスが制限される。

第2段階は、さらにクライアント向けの洗練されたレポートを作成する部分だ。 これは、AWSアカウント内で起動されたARM64アーキテクチャのKali Linux EC2インスタンス上で行われる。このEC2インスタンスは、第1段階でS3に保存された「承認済みのMarkdownレポート」のみを読み取る。ここで重要なのは、「ローカルの軽量AIモデル」が使用されることだ。具体的には、Qwen2.5 7B Instructの量子化モデルがEC2インスタンスのCPU上で動作し、ダウンロード後にインターネットへの通信を切断するなど、非常に厳重なセキュリティ対策が施されている。 このローカルAIモデルは、受け取ったMarkdownをさらに加工し、クライアントが求める形式のオフラインHTMLレポートを生成する。このHTMLレポートは、エグゼクティブ向けの主要な指標、深刻度や提供元で絞り込みができるフィルター機能、並べ替え可能なファインディング一覧、影響の大きいリソースのトップリスト、提案された修正候補、ダウンロード可能なCSVデータなど、視覚的に整理され、インタラクティブな要素を含んでいる。これにより、技術的な詳細を追跡する証拠は保持しつつも、経営層や非技術者でも一目で状況を把握し、意思決定ができるようになる。生成された最終レポートは、承認されたS3パスにアップロードされるか、厳重に管理されたチャネルでクライアントに配布される。

なぜこのような2段階の仕組みが必要なのだろうか。 それは、第1段階でAWS内で生成されるHTMLレポートが、システムの内部IDや詳細な技術情報が満載で、監査や証拠の追跡には適しているものの、そのままではクライアント向けとしては不適切だからだ。一方、第2段階で生成されるレポートは、情報の階層化や視覚化に特化し、ビジネス上の優先度や必要なアクションを明確に提示する。 そして、最も重要なポイントは、なぜ外部のAIサービス（例えば、公開されたChatGPTのようなサービス）を使わないのかという点だ。セキュリティレポートには、アカウントID、IPアドレス、アプリケーション名、脆弱性情報、未修正の課題といった極めて機密性の高い情報が含まれる。これらの情報を外部のAIサービスに送信することは、データ処理の境界を外部に移すことになり、データの保持期間、アクセス権、処理方法に対する制御を失うリスクがある。そのため、このシステムでは、AIによる推論をAWSアカウントの境界内、かつインターネットから隔離されたEC2インスタンス上のローカルモデルで完結させることで、データ漏洩のリスクを極限まで低減している。EC2インスタンス自体も、最小限の権限、パブリックアクセスの禁止、暗号化されたストレージなど、厳重なセキュリティ対策が施されている。

このパイプラインは、「AIがセキュリティを自動で修正する」というものではない。あくまで「レポート作成の手間を大幅に削減し、修正に関する最終的な承認は人間が行う」という、監査可能で再現性の高いワークフローを確立するものだ。人間は、集計や整理といった反復的な作業から解放され、レポートの内容確認や重要な意思決定に集中できるようになる。 しかし、この仕組みには限界もある。AIはデータを誤って分類したり、一部を省略したりする可能性があるので、総ファインディング数と人間による確認は必須だ。また、優先度スコアはあくまで企業や組織のポリシーに基づく判断であり、絶対的な真実ではない。そして、ローカルモデルを使用しても、AWS環境自体のIAM権限管理、ストレージ（EBS）、OS、ネットワーク、そして最終レポートの配布経路のセキュリティ対策は引き続き重要である。このシステムは、週次で数時間かかっていたレポート作成作業を、レビューと承認を含めて1時間程度に短縮する効果が期待できる。最終的なレビューでは、報告内容の整合性、是正案の妥当性、機密情報の適切な編集、オフラインでの機能性、不審な内容の混入がないかなどを確認し、厳格な分類と承認を経て配布される必要がある。