Amazon Web Services ブログ
PKUTECH が Amazon Bedrock を活用して実現した AI-CSPM「Egeria-Security」のセキュアな設計
本ブログは 株式会社 PKUTECH と Amazon Web Services Japan 合同会社が共同で執筆いたしました。
みなさん、こんにちは。ソリューションアーキテクト 伊勢田氷琴です。
機密データを扱う SaaS を AWS 上で構築する際、どのサービスを組み合わせ、どのような設計判断を下せばよいのでしょうか。特に、お客様のコンプライアンス文書や監査指摘事項といった機微な情報を AI に処理させる製品では、データ保護、顧客環境への最小権限アクセスなど、考慮すべき論点がいくつも重なります。この記事では、PKUTECH が Amazon Bedrock をはじめとする AWS サービスを組み合わせて開発した純国産 AI-CSPM ソリューション「Egeria-Security」を題材に、機密文書を扱うセキュリティ SaaS の設計判断とその背景をご紹介します。クラウドセキュリティ（CSPM）運用に課題を抱える方々にとっても、その解決アプローチとして参考になる内容です。
セキュリティ SaaS が直面する 2 つの設計課題
Egeria-Security は、Cloud Security Posture Management（CSPM）の機能を提供する SaaS 製品です。CSPM とはクラウド環境のセキュリティ設定を継続的に監視・評価するソリューションを指します。課題を 2 つの視点から整理します。
まず、利用者側（CSPM を導入する企業）の課題です。多くの CSPM ツールには CIS Benchmark や NIST などの膨大な標準ポリシーセットがあらかじめ搭載されていますが、大量のアラートの中から「なぜその項目が自社のシステムに必要なのか」を理解するには高度な専門知識が求められます。また、自社のセキュリティ規程や監査法人からの独自指摘に合わせてカスタムルールを作成するには、ポリシー言語の深い理解が必要であり、技術的なハードルが高い状況でした。結果としてチェックの根拠がブラックボックス化し、「設定の逸脱を検知しても、どう直すべきか判断できない」「監査の際にチェックの正当性を説明できない」という状況に陥りがちです。
次に、提供者側（セキュリティ SaaS を開発する企業）の課題です。顧客のコンプライアンス文書や監査指摘事項は機密性の高い情報であり、SaaS のバックエンドで安全に処理する必要があります。加えて、LLM を活用する場合、入力データが学習に利用されないこと、推論トラフィックが閉域を通ること、顧客のクラウド環境へのアクセスが最小権限で制御されていること、これらをすべて同時に満たすことが望ましいです。
コンプライアンス文書を起点としたポリシー自動生成
PKUTECH は、2002 年の創業以来、NTT データグループをはじめとする大手企業向けのシステムインテグレーション事業を展開してきました。近年は自社プロダクトの開発にも注力しており、生成 AI を活用した Egeria シリーズを展開しています。
同社が着目したのは、自社のコンプライアンス文書そのものをスキャンポリシーの源泉にするというアプローチでした。既存の CSPM ツールは CIS Benchmark や NIST など汎用的な標準ポリシーセットを起点とするため、自社環境に関係のないアラートが混入しやすく、「なぜそのチェックが必要か」の根拠が読み手に伝わりにくいという課題がありました。Egeria-Security はこの順序を逆転させ、自社のコンプライアンス文書から出発して、そこに記載された推奨事項をそのままスキャンポリシーに変換する仕組みを採用しました。生成された各チェック項目には、推奨事項 ID・準拠フレームワーク・カテゴリ・重要度といった文書由来の根拠メタデータが紐づくため、スキャン結果の根拠をたどりやすくなります。
AWS を基盤として選択した理由
Egeria-Security の基盤として AWS を選択した理由は、主に以下の 3 点です。個別のサービス機能だけを比較すると類似の選択肢は他のクラウドベンダーにも存在しますが、機密データを扱うセキュリティ SaaS の全要件をバランスよく満たす組み合わせとして AWS を選択しました。
第一に、LLM 推論におけるデータ保護です。 Egeria-Security が処理するコンプライアンス文書には、組織のセキュリティポリシーや監査指摘事項など機密性の高い情報が含まれます。Amazon Bedrock では、ユーザーのデータがモデルのトレーニングに使用されないため、機密文書を LLM に投入する前提条件を満たします。
第二に、機密データを扱う AI SaaS に必要な要素が単一プラットフォーム内で統合されている点です。 生成 AI 推論（Amazon Bedrock）、RAG のベクトルストア（Amazon OpenSearch Service）、閉域ネットワーク（Amazon Virtual Private Cloud (Amazon VPC)、AWS PrivateLink）、認証・鍵管理（AWS Identity and Access Management (IAM)、AWS Key Management Service (AWS KMS)）、コンテナレジストリ（Amazon Elastic Container Registry (Amazon ECR)）、ロードバランシング（Elastic Load Balancing）、DNS（Amazon Route 53）、証明書管理（AWS Certificate Manager）。これらの個々の機能は類似のものが他のクラウドにも存在しますが、同一のプラットフォーム・同一の認証基盤の上で統合的に運用・監査できることが、セキュリティ SaaS の説明責任の観点で重要でした。複数クラウドをまたぐ構成では、認証・ログ・監査の連携が複雑化し、セキュリティ製品としての信頼性確保に追加コストがかかります。
第三に、顧客 AWS 環境とのシームレスな接続です。 CSPM の主要な利用シーンは顧客の AWS アカウントをスキャンすることです。SaaS 基盤も AWS 上にあれば、AWS Security Token Service（AWS STS）によるクロスアカウントアクセスなど、AWS ネイティブな統制で顧客環境との連携を実現できます。
こうした設計判断の結果として、GPU 推論基盤の構築・運用といった非差別化領域を AWS マネージドサービスに委ね、インフラ層のコンプライアンス証跡には AWS が提供する認証・レポートを活用できるようになりました。責任共有モデルのもとアプリケーション層の統制は同社が引き続き担いますが、開発リソースをコア差別化領域であるコンプライアンス文書の RAG 処理と Cloud Custodian DSL の自動生成ロジックに集中投下できました。PKUTECH の試算では、自前で LLM 推論基盤を構築した場合と比較して、GPU 調達・運用で 2〜3 人月、LLM ホスティング・スケーリングの開発で 3〜6 人月の工数が不要となり、SaaS の立ち上げリードタイムは約 12〜18 ヶ月の想定に対し約 4〜6 ヶ月で MVP 完成に至りました。
ソリューションの概要：コンプライアンス文書からスキャンポリシーを自動生成
Egeria-Security は、SaaS 型で提供される純国産の AI-CSPM ソリューションです。ユーザーはまず CIS Benchmark、NIST SP 800-53 などの標準フレームワークや、自社の社内規程、委託先管理基準などのコンプライアンス文書を PDF でアップロードします。次に、取り込んだ文書をもとに Amazon Bedrock を活用した AI チャットで対話しながら、自社に必要な「推奨事項」を抽出します。抽出した推奨事項から AI の支援を受けながら Cloud Custodian ポリシー（YAML 形式）を自動生成し、生成されたポリシーを用いて実際のクラウド環境（AWS や Azure）をスキャンします。スキャン結果は複数回にわたる違反の発生・解消の推移をタイムラインで追跡でき、改善状況を可視化します。
3 つの設計判断
Egeria-Security のアーキテクチャは、前述の AWS 選択理由と連動した 3 つの設計判断で構成されています。
図1: Egeria-Security の AWS アーキテクチャ
設計判断 1：コンプライアンス文書 → DSL 変換のためのエージェント設計
非定型な PDF（コンプライアンス文書）を、Cloud Custodian が解釈可能な YAML という厳格な DSL に変換する必要がありました。
開発初期は PDF ファイル全体をそのままプロンプトに投入し、1 ステップで YAML ポリシーを生成する方式を試みました。しかし、数十ページ規模の文書では存在しない AWS リソース名や属性の生成などハルシネーションが頻発し、「適切なアクセス制御を実施する」のような抽象的記述に対して具体的なチェックロジックに落とし込めない、同じ文書を再投入しても生成結果のばらつきが大きく再現性が確保できないといった問題が顕在化しました。
図2: 2 つのエージェント（前段 = 取り込み／後段 = ポリシー作成）と内部 4 ステップ
これらの課題を解決するため、最終的に役割を 2 つのエージェントに分離し、Amazon OpenSearch Service 上の構造化ドキュメントを介して疎結合に繋ぐ構成としました。前段の PDF 取り込みエージェントが文書から「推奨事項タイトル」「論理的根拠」「監査手順」「修正手順」「重要度」「準拠フレームワーク」等の構造化データを抽出して Amazon OpenSearch Service に格納します。後段のポリシー作成エージェントは、まず Cloud Custodian の公式スキーマ（custodian schema コマンド）から取得した有効リソースタイプ一覧を選択肢として推奨事項に対応するリソースを特定し、次に Amazon OpenSearch Service に格納された Cloud Custodian リファレンスのコード例を RAG で参照しながら YAML ポリシーを生成します。生成結果がリスト内に存在するかを厳格に検証することで、ハルシネーションを抑制しています。図2 は、この 2 つのエージェントが内部で実行する処理を 4 つのステップ（Step1 PDF 解析/構造化、Step2 対話、Step3 ポリシー生成、Step4 構文チェック/修正）として示したものです。Step1〜2 を前段の PDF 取り込みエージェントが、Step3〜4 を後段のポリシー作成エージェントが担います。後段は、スキーマ参照・自動修正・最終レビューを含む複数のノードで構成されます。
この設計の技術的なポイントは、「自由に書かせる」から「決められた選択肢から選ばせる」への発想転換です。Cloud Custodian の公式スキーマを選択肢の制約として用いることで、存在しないリソースタイプや属性の生成を抑制し、独自辞書を手作業で保守する範囲を減らしています。なお、この制約が担保するのは構文上の妥当性であり、生成されたポリシーが文書の意図に合致しているかは生成後のレビューで確認します。また、PDF 取り込みエージェントに構造化抽出の責任を集中させたことで、ポリシー作成エージェントが文書原文を直接扱う必要がなくなり、再現性の向上にも寄与しました。
設計判断 2：機密データの LLM 推論を閉域で完結させる
コンプライアンス文書は SaaS のバックエンドから LLM に渡されますが、この経路がインターネットを通過しない設計としています。ユーザーがブラウザからコンプライアンス文書をアップロードする区間は HTTPS（TLS 暗号化）によるインターネット経由の通信ですが、SaaS バックエンドが受信した文書を LLM 推論に渡す経路は Amazon VPC 内で完結します。バックエンドは VPC 内に配置され、アプリケーション間の通信は VPC 内で閉じています。Amazon Bedrock への LLM 推論アクセスは VPC Interface Endpoint（AWS PrivateLink）を経由するため、バックエンドから Bedrock への経路は AWS バックボーンネットワーク内で処理が完結し、この通信にパブリックインターネットへの egress は発生しません。つまり、機密文書が LLM 推論に渡される区間を閉域で保護する構成です。
この閉域設計により、機密文書を扱う通信のうち外部に公開される経路を減らし、データ経路の制御と監査可能性を確保しています。設計にあたっては、AWS Well-Architected Framework のセキュリティの柱における「転送中のデータの暗号化とネットワーク経路の制限」のベストプラクティスを参照しています。
設計判断 3：顧客 AWS 環境への最小権限・最小干渉のアクセス
CSPM として顧客環境をスキャンするには一定の権限が必要ですが、セキュリティ製品である以上、顧客環境への干渉は最小限でなければなりません。PKUTECH は当初、アクセスキー直接入力方式（長期キーの管理リスクが高い）、AWS Organizations 連携方式（運用負荷が大きい）、オンプレエージェント方式（SaaS としての即時性を損なう）といった代替案を検討しましたが、いずれも金融領域の厳格なセキュリティ要件や SaaS としての導入容易性と両立できないと判断し、最終的に AWS CloudFormation テンプレート + STS AssumeRole + ExternalID の組み合わせに至りました。
具体的には、お客様が自社の AWS マネジメントコンソールで CloudFormation の Deep Link を開くだけで Egeria-Security 専用の IAM ロールが作成されます。付与される権限は既定で AWS 公式の SecurityAudit マネージドポリシー（読み取り専用）であり、変更・削除権限は含まれません。スキャン実行時には、テナント ID とランダム値の複合キーを ExternalID として指定した STS AssumeRole により、有効期限 1 時間の一時認証情報を都度取得します。ExternalID の照合は、顧客側 IAM ロールの信頼ポリシーに設定された sts:ExternalId 条件によって行われます。AssumeRole 呼び出し時にはセッションタグでテナント ID を付与しており、顧客側の AWS CloudTrail で監査ログの追跡が可能です。SaaS 側で保存するのは Role ARN や ExternalID などの連携情報で、これらは AES-256-GCM により暗号化しています。AssumeRole で取得した一時認証情報は、スキャン実行環境で永続化せず使用後に破棄します。
この構成は金融領域に関わる IT 企業での PoC におけるセキュリティレビューを経て改修を重ねたものです。具体的には、IAM ロールテンプレートの用途別分離（顧客側がマネージドポリシー ARN を選択可能化）、ExternalID のテナント分離強化、セッションタグによる監査追跡の追加が、PoC 評価者のレビューを経て実装されました。
導入効果：PoC での実証
金融領域に関わる IT 企業での PoC 検証を経て、以下の効果が確認されました。
導入の初期障壁の低さ
PoC では、コンプライアンス文書の登録からポリシー生成、スキャン実行までの一連の流れが問題なく実行できることが確認されました。エージェントレスかつ文書ベースのポリシー自動生成のため、SaaS 型で提供する場合、デプロイから文書登録、スキャン実行までは 1 営業日以内に完了できる見込みです（PKUTECH の試算）。また、PoC 評価者からは「AWS や Azure の専門知識がなくてもスキャンに必要なポリシーを容易に設定可能」との評価をいただいており、Cloud Custodian の YAML 構文を意識することなくポリシーを策定できることが確認されました。
ポリシー網羅率
PoC で取り込んだコンプライアンス文書から自動生成された有効ポリシーは、取り込み観点の約 50〜60% をカバーしました（この数値は取り込んだ観点のうち実行可能なポリシーとして生成できた範囲を示すもので、生成結果の修正不要率や検知精度を表すものではありません）。残りの 40〜50% は「適切なアクセス制御を実施する」のような抽象的記述や、Cloud Custodian が直接扱えない人手プロセス（ドキュメンタリ統制等）で、別途人手での運用設計が必要です。PoC 評価者からは「文書ベースで半分のポリシーが自動生成できるだけでも、実装工数の短縮になる」とのご評価をいただいています。
CNAPP 化に向けた今後の展開
PKUTECH は、Egeria-Security の CSPM 機能を起点として、AI を活用した CNAPP（Cloud Native Application Protection Platform）の実現を目指しています。今後、クラウドユーザーのアクセス権・特権を自動チェックする AI-CIEM、クラウド環境内の脅威やポリシー違反を検出する AI-CWPP、Infrastructure as Code で記述されたインフラ構成を自動チェックする AI-IaC スキャンを順次追加する予定です。
お客様の声
本プロジェクトを主導した PKUTECH クラウド＆セキュリティ事業部長の渡部寿春氏は、次のようにコメントしています。
「Amazon Bedrock を PrivateLink 経由で利用する閉域設計により、機密文書の AI 推論をインターネットに出すことなく実行でき、セキュアなセキュリティガバナンスを実現できました。金融領域に関わる IT 企業での PoC でも実証された通り、コンプライアンス文書を取り込む独自の AI アプローチにより、Cloud Custodian の専門知識がなくても自社基準に即したクラウドセキュリティ運用が可能となり、セキュリティ人材不足に悩む多くの企業のご支援に繋がると確信しています。」
また、PoC に参加された金融領域に関わる IT 企業のシステム部門ご担当者様からは、利用者側の視点でコメントをいただいています。
「従来の CSPM では、自社独自のセキュリティポリシーに合わせてルールをカスタマイズすることに高い技術的ハードルがありました。今回の PoC で Egeria-Security に自社のコンプライアンス文書を読み込ませたところ、ドキュメントの『構造化』精度が非常に高く、具体的な運用文書から自動的にシステムチェック観点へ落とし込める点に大きな可能性を感じました。既存の CSPM とは一線を画す明確な差別化ポイントがあります。今後のさらなる機能の成熟と安定性の向上により、エンタープライズのクラウドガバナンス運用において価値を発揮するソリューションになるものと期待しています。」
まとめ
PKUTECH が開発した Egeria-Security は、自社のコンプライアンス文書を起点としてスキャンポリシーを自動生成するアプローチにより、CSPM 運用における監査説明性とカスタムポリシー作成のハードルを同時に下げるソリューションです。
本記事では、この製品を題材に、機密データを扱うセキュリティ SaaS を AWS 上で構築する際の設計判断を 3 つの視点から整理しました。コンプライアンス文書から DSL への変換では 1 ステップ生成の失敗から 2 エージェント分離に至った経緯、閉域設計では PrivateLink を活用した機密データ経路の制御、顧客環境連携では PoC のセキュリティレビューを経て改修を重ねた実践についてです。個々の AWS サービスの機能比較ではなく、機密データを扱う AI SaaS に必要な要素が単一プラットフォーム上で統合的に利用できることが、本事例における AWS 選択の決め手でした。
同様の課題を抱える SaaS ベンダーや、生成 AI を自社製品に組み込もうとする企業にとって、設計の参考になれば幸いです。クラウドセキュリティの運用に課題を感じている方は、Egeria-Security の製品ページをご覧ください。Amazon Bedrock を活用した生成 AI ソリューションの構築に興味がある方は、Amazon Bedrock の詳細ページもあわせてご参照ください。本記事で取り上げた AWS サービスの詳細は、Amazon OpenSearch Service、AWS PrivateLink、AWS CloudFormation の各ページをご覧ください。
左より
PKUTECH：セキュリティエンジニア 遠藤 操希 氏
Amazon Web Services Japan：アカウントマネージャー 今井 彩渚
PKUTECH：デザイナー＆スクラムマスター 坂野 茉夢 氏
PKUTECH：AWS アーキテクト 杜 利民 氏
PKUTECH：クラウド＆セキュリティ事業部長 渡部 寿春 氏
PKUTECH：技術リーダー 釜石 智史 氏
PKUTECH：Python エンジニア 及川 大地 氏
Amazon Web Services Japan：ソリューションアーキテクト 伊勢田 氷琴
ソリューションアーキテクト 伊勢田氷琴