· · 1 分で読めます

MAESTRO、多層防御、そしてSQL ServerがなぜAIのセキュリティ境界になったのか

エージェントAIは、従来のSTRIDEモデルが設計されていなかった脅威をもたらします。Microsoft SQLがMAESTROフレームワークにどのようにマッピングされ、ガバナンスされた実行境界を提供するかをご紹介します。

Azure SQL AI Security Agentic AI SQL Server 2025
この記事は他の言語でも読めます:English, Català, Español, Deutsch, Français, Português, Italiano, 中文, 한국어, Русский, हिन्दी, Polski, Türkçe, العربية, Bahasa Indonesia, Nederlands

セキュリティ脅威モデルは、誰が、または何がリクエストを行っているかに関する前提の上に構築されています。STRIDEは、定義されたインターフェースを通じてシステムと対話する人間のアクターを想定しています。AIエージェントはそのように動作しません。

STRIDEはAIエージェント向けに設計されていない

エージェントシステムは自律的に動作し、API呼び出しを通じてツールをチェーンし、どのデータを取得しどのアクションを実行するかを決定し、複数のソース(ユーザープロンプト、ツール結果、取得データ)から指示を受け取ることができます。STRIDEの脅威モデル(Spoofing、Tampering、Repudiation、Information Disclosure、Denial of Service、Elevation of Privilege)は、プロンプトインジェクション、コンテキスト汚染、ツールの悪用などのエージェント固有の攻撃ベクトルを適切に捉えていません。

Cloud Security AllianceはAIエージェントのリスクに特化したMAESTROフレームワークを公開しました。

MAESTROフレームワーク

MAESTROはエージェントAIのリスクを7つのレイヤーに整理しています:

  1. Foundation Models — 基盤となるLLMとそのトレーニングの脆弱性
  2. Data Operations — データの取得、保存、操作
  3. Agent Frameworks — エージェントのオーケストレーションと調整のミドルウェア
  4. Deployment & Infrastructure — エージェントが実行される場所とその設定
  5. Evaluation & Observability — 時間をかけたエージェントの行動監視
  6. Security & Compliance — アクセス制御、監査、規制コンプライアンス
  7. Agent Ecosystem — エージェント同士や外部ツールとの相互作用

各レイヤーには、従来のセキュリティ制御が直接対処していない特定の攻撃ベクトルがあります。

ガバナンスされた実行境界としてのMicrosoft SQL

SQL Server 2025は、具体的な方法でMAESTROレイヤーにマッピングされます:

Data Operationsレイヤー: T-SQLに統合されたAI_GENERATE_EMBEDDINGSにより、ベクトル操作がデータベースのガバナンス境界内に保たれます。エンベディング処理のためにデータをモデルサービスに送る必要はありません。

Security & Complianceレイヤー: 行レベルセキュリティ(RLS)と動的データマスキング(DDM)は、リクエストがどのように来たかに関わらず適用されます — 人間のユーザーからでもAIエージェントからでも。エージェントはデータベース自体によって適用される制御を回避することができません。

Agent Frameworksレイヤー: ストアドプロシージャがツール境界として機能します。エージェントに任意のSQLアクセスを与えるのではなく、許可された操作をプロシージャとして定義し、エージェントツールとして公開します。パラメータ化されたクエリは実行レベルでのインジェクションを防ぎます。

Evaluation & Observabilityレイヤー: 監査ログとQuery Storeは、各エージェントが実際に実行したこと(要求されたことだけでなく)を記録します。このトレーサビリティは、帰属が複雑なエージェントシステムでのインシデント調査に不可欠です。

エージェントAIのための多層防御

原則は従来のセキュリティと同じです:単一の制御で十分ではありません。変わるのはエージェントにとって最も重要な制御です:

爆発半径を減らす: ストアドプロシージャによるツール境界は、侵害されたエージェントが事前定義された操作のみを実行できることを意味します。任意のクエリへのピボットはできません。

可観測性: インシデント後に「このエージェントは正確に何をしたか?」に答えられる必要があります。データベースレベルのトレーサビリティがないエージェントAIシステムには、アプリケーションログでカバーできないブラインドスポットがあります。

制約された実行: パラメータ化、RLS、DDMは、呼び出し元が人間かどうかに関わらずセキュリティ資産です。エージェントに対応するために弱めてはなりません。

説明責任: SQL Serverの監査ログは、誰が(どのエージェントが、どの資格情報を使用して)いつ何を実行したかの記録を作成します。これはエージェントシステムが実際の結果をもたらす行動を取る際に重要です。

SQL Server 2025はエージェントリスクを抽象的に解決するために構築されたのではなく、リレーショナルデータベースとして構築されました。しかし、エンタープライズデータベースを信頼できるものにするガバナンスが、まさにエージェント実行境界をセキュアにするものでもあります。

元の投稿: Microsoft SQL Security Across the MAESTRO Stack

共有:
この記事のソースコードをGitHubで見る ↗
← NL2SQLはエージェント時代のSQLインジェクションだ
Visual StudioのAgent Skills:チームの実際の作業方法をCopilotに教える →