Databricks上でエージェントベースのセキュリティレビューを構築した方法

セキュリティレビュープロセスの一部はすでに自動化されていました。それは便利ではありましたが、手作業を十分に削減するには至りませんでした。

キューの中で、いつも同じパターンを目にしていました。よく知られた設計を用いた日常的な統合が、真に新しくリスクの高いアーキテクチャのすぐ隣に並び、どちらも経験豊富なレビュー担当者という限られたリソースを待っている状態でした。

問題は、既存の自動化が失敗したことではありません。単に限界に達していただけでした。私たちは依然として、予測可能な作業に専門家の時間を費やしており、真に専門的な判断を必要とする意思決定に割く時間が不足していました。

そこで私は、既存のシステムを拡張するために、エージェントベースのレイヤーを構築しました。目的は、プロセスやそれを支える人々を置き換えることではありません。システムがリクエストを理解し、基準を適用し、不足している情報を求め、人が介入すべきタイミングを認識できるようにすることでした。

最初のエージェントベースのバージョンは、1つのレビューパスに焦点を当てていました。私のチームはより広いパターンを見出し、それを一連のエージェントへと拡張しました。現在、これらはセキュリティの受付およびレビュープロセスの他の部分もサポートしています。私はその最初のバージョンを、お客様が使用しているのと同じプラットフォームであるDatabricks上で完全に構築しました。

なぜプラットフォームが重要だったのか

主要なコンポーネントがすでに1つの環境で利用可能だったため、迅速に動くことができました。

Unity Catalogは、セキュリティ基準、リクエストデータ、裏付けとなる証拠、意思決定、システム出力を管理するためのガバナンスが効いたスペースを提供しました。Databricksがホストする基盤モデルは、分類と推論のためのモデルレイヤーを提供しました。Lakeflow Jobsは、サーバーレスコンピューティング上でノートブックベースのワークフローをオーケストレーションしました。Databricks Appsは、受付体験とエグゼクティブダッシュボードを提供しました。

各パーツがどのように連携するか

大まかに言えば、リクエストはプラットフォーム内を1つの連続したパスで流れ、すべてのステップが同じ管理されたテーブルから読み取り、書き込みを行います。

1. 受付 - Databricks Appsで構築された対話型アプリが、自然言語による説明を構造化されたリクエストに変換し、裏付けとなる設計ドキュメントを添付します。
2. 推論 - Databricksがホストする基盤モデル（Claude Haiku、Sonnet、Opus）が、常にセキュリティ基準に基づいてリクエストを分類し、リスクを評価し、要件をドラフトします。Haikuは軽量な分類を処理し、Sonnetはほとんどのレビュー作業を処理し、Opusは最も高度な推論のために確保されています。
3. オーケストレーション - Lakeflow Jobsがサーバーレスコンピューティング上でレビューエージェントを実行し、スケジュールに従って各リクエストをステージごとに進めます。
4. 記録システム - Unity Catalogが、基準、リクエストデータ、証拠、モデル出力、意思決定を管理されたテーブルとして保持し、そのすべてに対して単一の権限およびリネージモデルを適用します。
5. オブザーバビリティ - 2つ目のDatabricks Appがこれらと同じテーブルを読み取り、処理量、リスク構成、自動化率、節約された時間をレポートします。

これにより、データ、モデル、ワークフロー、アプリケーション全体で一貫したガバナンスと運用モデルが得られました。異なる権限、ログ、データパスを持つ個別のサービスを組み合わせる代わりに、レビューロジックとユーザーエクスペリエンスに集中することができました。

実質的な違いはスピードでした。2時間足らずで稼働するシステムを構築できました。個別のサービスを連携させて同じことを行おうとすれば、数週間はかかっていたでしょう。

すべてのレビューが同じパスを必要とするわけではない

ほとんどのセキュリティキューには、予測可能なリクエストと、真の例外の両方が含まれています。

承認済みの認証パターンを使用し、機密データを扱わない統合は、広範な管理者アクセス権を持ち、機密情報を処理するインターネットに公開されたサービスと同じ意思決定ではありません。しかし、従来のキューでは、両方を同じ手動のパスに通してしまうことがあります。

私はすべてのレビューを自動化することを目指していたわけではありません。繰り返し可能な部分を自動化し、リスクや不確実性が高い部分には人間の判断を残しました。

その結果、「明確な基準内にある十分に理解されたケースには自動化を適用し、斬新でリスクが高い、または曖昧な意思決定には人を充てる」というシンプルなルールが生まれました。

より優れた入り口

レビューの品質は、開始時に利用可能な情報に依存します。

静的なフォームでは、申請者がどのレビューが必要かを把握し、セキュリティ用語を理解し、レビュー担当者が要求する証拠を予測していることを前提としています。そうでない場合、リクエストは不完全な状態で届き、レビューは質問の繰り返しから始まることになります。

私はDatabricks Appsを使用して対話型の受付アプリケーションを構築しました。申請者が行おうとしていることを自然言語で説明すると、アプリケーションが可能性の高いレビューパスを特定し、文脈に応じたフォローアップの質問を行い、組み込まれた設計ドキュメントを補足的なコンテキストとして使用できます。正式なリクエストが作成される前に、不足している情報を強調表示し、予備的なリスク指標を提示します。

十分なコンテキストが揃うと、セキュリティチーム向けの構造化されたリクエストを作成します。

このアプリケーションには、セキュリティ基準に基づいた相談モードもあります。すべての質問をチケットにする必要はありません。チームは設計を具体化している段階でガイダンスを受けることができ、必要な場合にのみ正式なレビューを開始できます。

これはシステムの中で最も有用な部分の1つとなりました。キューをセキュリティに関与する唯一の方法とするのではなく、人々がより早く作業を進められるようになります。

エージェントの仕組み

受付アプリケーションの背後には、Databricks Notebooksで実装され、Lakeflow Jobsでオーケストレーションされた、特定の役割に特化したエージェントのコレクションがあります。

それぞれが1つの役割を持つ、7つの特化型エージェント

これは、1つの汎用エージェントや単一のスクリプトではなく、それぞれが狭い範囲の役割を持つ特化型エージェントのセットであり、受付アプリケーションの背後でスケジュールされたジョブとしてオーケストレーションされています。

• 受付エージェント - 対話型の入り口を運営します。レビューパスを特定し、文脈に応じた質問を行い、構造化されたリクエストを組み立てます。
• リスク評価エージェント - 裏付けとなる証拠を添えてリスク層を割り当て、状況が不完全な場合はデフォルトで高い層を割り当てます。
• 要件エージェント - リクエストを関連する基準にマッピングし、十分に理解されたケースに対して実装固有の要件をドラフトします。
• 専門レビューエージェント - ブラウザ拡張機能のスレットモデリングやサードパーティベンダーの評価など、専用のロジックを必要とするリクエストタイプを処理します。
• 検証エージェント - プロセスが完了する前に、リスクの高いリクエストに対して項目ごとの検証チェックリストを作成します。
• ワークフローエージェント - 明確化、リマインダー、承認の追跡、人へのエスカレーションなどのフォローアップ作業を処理します。
• 学習エージェント - レビュー担当者による編集内容と元の出力を定期的に比較し、プロンプトや基準の改善点を浮き彫りにします。

各エージェントの責任範囲は限定されているため、その動作は検査可能かつテスト可能であり、1つの変更が別のエージェントに気付かないうちに影響を与えることはありません。

システムはまずリクエストのリスクを評価し、その評価を裏付ける証拠を記録します。リスクラベルだけでは不十分です。

情報が不足しているか矛盾している場合、システムは明確化を求めるか、リクエストをレビュー担当者にルーティングします。推測だけで承認に進むことはありません。

日常的なリクエストに対して、エージェントは一般的な定型文を返すのではなく、実際のアーキテクチャと適用可能な基準に基づいて要件を生成します。申請者はそれらの要件を確認し、必要な証拠を提供します。対象となる低リスクおよび中リスクのリクエストは、定義された基準と検証が満たされれば、自動化されたパスを通じて完了できます。

例

よくあるケースを考えてみましょう。承認済みのシングルサインオン（SSO）パターンを使用し、機密データを扱わない内部統合です。要件エージェントは、一般的な定型文の代わりに、そのアーキテクチャに関連付けられた具体的でチェック可能な項目を生成します。例えば以下のようなものです。

• 承認されたアイデンティティプロバイダーを介して認証し、ローカルまたは共有の認証情報を無効にします。
• 統合を必要最小限のアクセススコープに制限し、それらを文書化します。
• アプリケーションログとアクセスログを中央のロギングパイプラインに送信します。
• データ分類レベルを確認し、機密データが導入される前に再レビューを行います。

申請者はこれらの項目を確認し、証拠を添付します。すべてに問題がなく、ケースが適用基準を満たしている場合、自動化されたパスを介して完了できます。

高リスク、極めて重要、異例、または曖昧なリクエストは、担当者に送られます。その時点で、レビュー担当者は、構造化された要約、裏付けとなる証拠、適用される基準、および残りの未解決の質問を受け取ります。

エージェントは、不足している詳細情報の収集、リマインダーの送信、確認の追跡、サポート要請時のエスカレーションなど、レビューに関する管理業務の大部分も処理します。リクエストが曖昧になったり、判断が必要になったりした場合に、レビュー担当者が介入します。

自動化は、私たちが定義したルール内で機能します。例外や重大な決定については、人が引き続き制御権を保持します。

システムの信頼性を高める

最も困難だったのは、モデルに回答を出力させることではありませんでした。その回答を制限し、レビュー可能にし、アクションに適したものにすることでした。

エージェントは当社のセキュリティ基準に基づいています。リスク評価には裏付けとなる証拠を含める必要があります。コンテキストが不足している場合は、楽観的な想定をするのではなく、フォローアップやエスカレーションをトリガーします。自動完了は、事前定義されたリクエストクラスと基準に限定されます。ワークフローは、各リクエストに関連付けられたインプット、アウトプット、証拠、および決定を記録します。

実際の運用イメージ

自動化された決定に基づいて安全にアクションを実行できるようにするには、次の3つの要素が必要です。

• 事前定義されたリクエストクラス。 十分に理解されている低リスクのカテゴリのみが自動完了の対象となります。たとえば、機密データを扱わない、承認されたパターンでの日常的な社内連携などです。これらのクラスに該当しないものはすべて、デフォルトで担当者にルーティングされます。
• 許容可能な証拠。 決定の信頼性は、それを裏付けるものによって決まります。証拠とは、リンクされた設計ドキュメント、明示されたデータ分類レベル、または承認されたコントロールが導入されていることを示す設定や参照など、具体的かつ検証可能な成果物を意味します。証拠のない主張は、情報不足として処理されます。
• 却下または不確実な評価。 証拠が不足しているか矛盾している場合、システムは推測しません。デフォルトでより保守的なリスク層を適用するか、具体的な説明要求を投稿するか、未解決の質問を添付してレビュー担当者にリクエストを渡します。勝手に承認されることはありません。

レビュー担当者からのフィードバックは、ギャップを特定し、時間をかけてシステムを改善するのに役立ちます。エージェントが本番環境の動作を独自に変更できるようにするのではなく、これらの修正を利用して基準、プロンプト、ワークフローロジックを洗練させます。

これらのコントロールは、モデル自体よりも重要です。優れたモデルは推論を向上させることができますが、信頼はそれを囲むシステム（明確なスコープ、明示的な証拠、保守的なエスカレーション、そしてリスクに真の重みを与える人間の権限）から生まれます。

チームがさらに発展させたこと

私は、1つのレビューパスを改善するために、最初のエージェントベースのバージョンを構築しました。私のチームは、同じパターンがさらに多くのことをサポートできることに気づきました。

彼らはアーキテクチャを他のリクエストタイプに拡張し、ワークフローを強化し、エージェントが当社の基準を適用する方法を改善し、日常業務に必要なコントロールを追加しました。単一のエージェントベースのワークフローとして始まったものは、チームが開発を続ける共有システムへと成長しました。

私が始めましたが、チームがそれを実用化し、自分たちのものにしたからこそ、システムに価値が生まれたのです。

開発者として、最初のバージョンが機能したことを誇りに思います。リーダーとしては、チームが拡張する価値のある基盤を見出してくれたことをさらに誇りに思います。

成果の測定

効率性の主張は簡単ですが、証拠がなければ信頼するのは困難です。

私は、もう1つのDatabricks Appとしてエグゼクティブダッシュボードを構築しました。これは、レビューワークフローによって生成されたものと同じUnity Catalogデータから読み取り、リクエスト量、リスク分布、自動完了、人へのエスカレーション、サイクルタイム、およびレビュー担当者が節約した推定時間を追跡します。

メトリクスは運用レコードから取得されるため、別々のシステムからのエクスポートを手動で照合するのではなく、それらを生成したリクエストや決定まで遡って追跡できます。

これにより、リーダーシップ層との会話が変わりました。自動化によって手作業が削減された部分、レビュー担当者が引き続き関与した部分、そしてその組み合わせが時間の経過とともにどのように変化したかを示すことができました。

数値で見る成果

ダッシュボードは、すべて同じ運用レコードから派生した一貫した測定値のセットを追跡します。

何が変わったか

かつてはキューで何日も待機していた対象となる日常的なリクエストが、今では数分で完了できるようになりました。チームはチケットを起票する前にガイダンスを受け取ることができ、レビュー担当者に届くリクエストも、より適切なコンテキストが提供された状態で届きます。

当社のセキュリティエンジニアは、斬新な設計、重要なリスク、経験を必要とする決定により多くの時間を費やすことができます。また、リクエストは同じ基準と証拠要件に照らして評価されるため、最初のパスの一貫性も向上します。システムが不確実な場合は、エスカレーションします。

これは、人が関与しないセキュリティではありません。専門家の注意が最も価値を発揮する場所に、それを活用できるように設計されたシステムです。

この経験から得た教訓

レビュー担当者を増やすことで処理能力は向上しますが、反復的な作業がなくなるわけではありません。

最初のステップは、プロセスと判断を切り離すことです。基準が明確であり、システムが実際の基準に基づいており、証拠が必要とされ、不確実性がエスカレーションされ、成果を測定できる場合にのみ、反復可能なステップを自動化します。

モデルが回答を出力できるからという理由だけで、決定を自動化しないでください。許容可能な回答がどのようなものか、それを裏付ける証拠は何か、システムが不確実な場合に何が起こるかをプロセスが定義している場合にのみ、自動化してください。

重大な決定や例外については、人が引き続き制御できるようにしてください。

私の意図は、セキュリティレビューから人間を排除することではありませんでした。管理されたシステムが一貫して処理できる作業に、人間が費やす時間を削減することを目指しました。Databricks上で構築したことで、それを実現するためのプラットフォーム基盤が得られました。チームが最初のバージョンを受け取り、それを強化し、自分たちのものにするのを見るのが、最も素晴らしい経験でした。

まずはDatabricksのマルチエージェントガイドから始めて、この投稿のパターン（Unity Catalogで管理されたデータ、Lakeflow Jobsに特化したエージェント、フロントドアとしてのDatabricks App）を、独自の反復可能で証拠に基づいたレビューワークフローに適用してください。

Databricks Appsでマルチエージェントシステムを構築する

まずはDatabricksのマルチエージェントガイドから始めて、この投稿のパターン（Unity Catalogで管理されたデータ、Lakeflow Jobsに特化したエージェント、フロントドアとしてのDatabricks App）を、独自の反復可能で証拠に基づいたレビューワークフローに適用してください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事