導入
背景・目的
- 2025年12月に、自動セキュリティレビューやペネトレーションテストを実施可能な新セキュリティサービスとして、AWS Security Agentがプレビューで発表されました。
- Security Agentを用いることでペネトレーションテストをより高頻度で実行できるようになり、AI時代において開発スピードが加速するなかでも、セキュリティと開発スピードの両立に寄与するのではないかと仮説を立てています。
- Security Agentの公式ドキュメントや「政府情報システムにおける脆弱性診断導入ガイドライン」、Security Agentのペネトレーションテスト機能の実機検証結果を踏まえて、当該サービスを用いてどのようにセキュリティ向上が図れるかを考察します。
- 「政府情報システムにおける脆弱性診断導入ガイドライン」では診断種別として、「プラットフォーム診断」「Webアプリ診断」「スマートフォンアプリ診断」が記載されていますが、本ブログではWebアプリ診断に主眼を置いたうえで記載をしています。
対象読者
- AWS Certified Security - Specialty レベルの知識を想定し、各AWS サービスやセキュリティ用語に対する解説は割愛します。
AWS Security Agent概要
- AWS Security Agentは設計セキュリティレビューやコードセキュリティレビュー、ペネトレーションテスト機能を提供するサービスです。
- ペネトレーションテストでは、OWASP TOP10の脆弱性とビジネスロジックの欠陥を検出できるようです。当該サービスは、専門家によるペネトレーションテストを完全に代替するものではないとされていますが、高額な費用やリードタイムなしにペネトレーションテストを実施できるのは明確なメリットであると考えられます。
- また、セキュリティレビュー時に利用可能なセキュリティ要件はマネージドで10種類用意されています。なお、マネージド以外にもカスタムで定義することもできます。
以下、AWSコンソールに記載の各マネージド要件の内容を抜粋・和訳したものです
- Audit Logging Best Practices
- セキュリティ監視を可能にするため、システムが適切な監査ログをサポートしていることを保証します。
- Authentication Best Practices
- 正当なユーザーのみがシステムへアクセスできることを保証します
- Authorization Best Practices
- システムが適切な認可のベストプラクティスに従っていることを保証します。
- Information Protection Best Practices
- 機密データが漏えいせず、かつ改ざんされないことを保証します。
- Log Protection Best Practices
- システムログの完全性および機密性を保護することを保証します。
- Privileged Access Best Practices
- 特権機能に対して適切なガードレール（制御）が設けられていることを保証します。
- Secret Protection Best Practices
- 認証情報などのシークレットが機密情報として適切に保護されていることを保証します。
- Secure by Default Best Practices
- システムのデフォルト設定がセキュアであることを保証します。
- Tenant Isolation Best Practices
- システムのテナント間が適切に分離されていることを保証します。
- Trusted Cryptography Best Practices
- 信頼できる暗号技術の実装のみが使用されていることを保証します。
DS-221をベースとした、Security Agentへの期待
ここからは、政府情報システムに限らず、様々なシステムに対してセキュリティ脆弱性診断を導入する際に参考となる「政府情報システムにおける脆弱性診断導入ガイドライン」(以降、DS-221と記載します。)におけるWebアプリ診断に関する記載を念頭に、Security Agentを利用することでどのようにセキュリティ強化できるのか、現実的な期待値を考察してみます。
本セクションでは、DS-221の記載を適宜抜粋・引用しながら記載していきます。
脆弱性診断はシステムにおけるセキュリティ上の弱点を特定するものであるが、診断のみでシステムのセキュリティリスクを防ぐことはできない。また、脆弱性診断は既に作り込まれた脆弱性を検出するものであるが、それ以前に脆弱性の発生を未然に防ぐことが肝要である。
（出典：デジタル庁「政府情報システムにおける脆弱性診断導入ガイドライン」）
前提となる考え方として、脆弱性診断の実施に先んじて、そもそも脆弱性の発生を防ぐように設計・実装することが非常に重要です。脆弱性の発生を防止するには、各開発者のローカル環境でのKiro等のAIエージェントを活用したセキュリティレビューや、Security Agentの設計・コードレビューも効果的でしょう。
ツールによる自動診断は効率の観点では有用であるが、仕様に起因する脆弱性(A)全般の検出が難しい。また、実装上の問題(B)の中でも、対象の Web アプリの内部実装に対する深い洞察を要する脆弱性(B-1)や、一般的な実装の不備による脆弱性(B-2)においても一定の制限を迂回しなければ攻撃できないものが見落とされやすいため、専門家の人手による診断で補強する必要がある。
（出典：デジタル庁「政府情報システムにおける脆弱性診断導入ガイドライン」）
DS-221では、Webアプリ診断で検出される脆弱性として、「(A)Web アプリの仕様に起因する脆弱性」と「(B)Web アプリの実装に起因する脆弱性」、「(C)利用する Web アプリミドルウェア固有の脆弱性」が定義されています。
従来の自動診断ツールでは、仕様に起因する脆弱性の検出が難しかったものの、AI搭載エージェントであるSecurity Agentであれば、検出可能なのではと仮説を立てています。
Security AgentのFAQページに「AWSセキュリティエージェントはOWASPトップ10から始まりますが、顧客のドキュメントやコードから得られるアプリケーションの状況に応じてカスタマイズされます。AWSセキュリティエージェントは、顧客のアプリケーション向けにカスタム攻撃プランを作成する際に得られた反応に応じて自身を適応させます。」と記載されていることから、仕様に起因する脆弱性も検出できるかもしれません。(後続のセクションで実際に検証してみます。)
・構築時診断
各システムの構築時に行う診断で、脆弱性対策の実施内容の確認やセキュリティ品質の確保を目的として実施するものを示す。
（出典：デジタル庁「政府情報システムにおける脆弱性診断導入ガイドライン」）
・定期診断
各機関で定期的に実施する診断で、各システムの脆弱性対策が適切に実施されていることの点検や監査を目的として実施するものを示す。
（出典：デジタル庁「政府情報システムにおける脆弱性診断導入ガイドライン」）
DS-221では、脆弱性診断の実施基準として「構築時診断」と「定期診断」とを定義しています。
個人の意見としては、各システムの初期構築時や定期診断時は専門家による診断を必須としつつ、より小規模な改修・デプロイのタイミングでSecurity Agentによるペネトレーションテストを実施することで、セキュリティ品質を底上げできるのではと予想しています。
仕様や実装メカニズムへの深い知見・洞察が要求される領域や、監査要件等を考慮すると、専門家による診断は欠かせないのではと考えています。
一方で、Security Agentであれば(現時点では料金非公開ですが、)専門家によるペネトレーションテストよりも安価、且つ柔軟なスケジュールでテスト可能です。アプリデプロイのタイミングに合わせて、非プロダクション環境で、高頻度でSecurity Agentによるペネトレーションテストを実施することで、プロダクション環境に脆弱性が組み込まれるリスクを軽減できると期待します。
Security Agentによるペネトレーションテストと専門家によるテストとは、微妙に用途が異なるはずです。ライフサイクルに応じて併用するのが良いのではと、現時点では予想しています。
[実機検証]ペネトレーションテストによる脆弱性の検知
ここまではDS-221をベースに、Security Agentを利用することで、どのようにセキュリティ強化できるかを考察してきました。
それでは、実際にSecurity Agentによるペネトレーションテストを実行し、Web アプリの仕様に起因する脆弱性を検出することが出来るのかを検証してみます。
事前準備
DS-221の記載を参考に、意図的に「Web アプリの仕様に起因する脆弱性」を組み込んだPythonアプリを構築し、ECSにデプロイしておきます。(なお、意図しない利用を避けるため、サンプルコードは掲載しません。)
| 脆弱性 | 実装箇所 | 内容 |
|---|---|---|
| 不適切なアクセス制御 | /user/<username> |
他人の情報を閲覧可能 |
| 業務ロジック不備 | /reset_password |
本人確認なしで PW リセット |
| 認証フロー欠陥 | /debug/login_as_admin |
認証回避 |
ペネトレーションテストの実施
公式ドキュメントに沿って、Security Agent及びペネトレーションテストをセットアップしたうえで、ECSにデプロイした上記検証用アプリに対してテストを実行します。
実行時には、検証用アプリのURL及び認証情報を指定したうえで、簡単なアプリ仕様書をアップロードしてコンテキストを提供しています。
なお、Security Agentからのリクエストにはデフォルトで「User-Agent: securityagent」が付与される＆カスタムHTTPヘッダを設定可能です。今回は実施しませんでしたが、非プロダクション環境に対してテストする際、ヘッダ情報を元にWAFルール検証をスキップする等の設定を組み込むことも検討ください。DS-221でも、「WAFは脆弱性の存在を隠蔽してしまうおそれがあることから、診断時は無効化しておくことが望ましい」旨が記載されています。
結果確認
ペネトレーションテスト完了後に結果確認したところ、「Web アプリの仕様に起因する脆弱性」を無事検出していました。
不適切なアクセス制御(他人の情報を閲覧可能)
業務ロジック不備(本人確認なしで PW リセット)
認証フロー欠陥(認証回避)
なお、アプリ仕様書をアップロードせずにペネトレーションテストを実行したところ、業務ロジック不備(本人確認なしで PW リセット)及び認証フロー欠陥(認証回避)については検出されませんでした。
この結果を踏まえると、Security Agentが診断対象アプリの主要な機能や画面遷移を把握できるよう、必要最低限の情報を事前に提供するのが良いかもしれません。
おわりに
DS-221をベースとした考察および実機検証を通じて、Security Agentがセキュリティ強化において有用な役割を果たし得ることを確認できました。特に、Security Agentを用いることでペネトレーションテストをより高頻度で実行できる点は、AI時代において開発スピードが加速するなかでも、セキュリティと開発スピードの両立に寄与する可能性があるという当初の仮説を一定程度裏付ける結果であると考えています。
一方で、現時点では、仕様や実装メカニズムへの深い洞察を要する複雑な脆弱性の検出においては、専門家による脆弱性診断が依然として欠かせないとも考えています。
そのため、いずれか1つの対策に依存するのではなく、「Kiro等を用いたローカル環境でのセキュリティレビュー」や「Security Agentによる設計・コードレビュー」によって脆弱性の発生を未然に防ぎつつ、「Security Agentのペネトレーションテスト」および「専門家による脆弱性診断」を組み合わせて脆弱性を検出することが重要だと考えています。これらをライフサイクルに応じて併用することで、多層的な対策による継続的なセキュリティ強化を実現できるのではないでしょうか。
参考
政府情報システムにおける脆弱性診断導入ガイドライン(PDF)
注意事項
本記事は万全を期して作成していますが、お気づきの点がありましたら、ご連絡よろしくお願いします。
なお、本記事の内容を利用した結果及び影響について、筆者は一切の責任を負いませんので、予めご了承ください。
アクセンチュア株式会社に所属する社員有志による運営です。アクセンチュアの社員による様々な発信をまとめています。なお、投稿内容は社員個人の見解であり、所属する組織を代表するものではありません。
Discussion