https://thedotnetblog.com/de/tags/sql-server-2025/Articles, tutorials and insights from the .NET community.Hugode@thedotnetblog (The .NET Blog)@thedotnetblogThu, 04 Jun 2026 00:00:00 +0000https://thedotnetblog.com/de/news/emiliano-montesdeoca/sql-server-maestro-agentic-ai-security-defense-in-depth/Thu, 04 Jun 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/de/news/emiliano-montesdeoca/sql-server-maestro-agentic-ai-security-defense-in-depth/Agentische KI führt Bedrohungen ein, für die traditionelle STRIDE-Modelle nicht konzipiert wurden. So mappt Microsoft SQL auf das MAESTRO-Framework, um eine regulierte Ausführungsgrenze bereitzustellen.<p>Sicherheits-Bedrohungsmodelle werden auf Annahmen darüber aufgebaut, wer oder was die Anfragen stellt. STRIDE geht von menschlichen Akteuren aus, die über definierte Schnittstellen mit Systemen interagieren. KI-Agenten funktionieren nicht so.</p> <h2 id="stride-wurde-nicht-für-ki-agenten-entworfen">STRIDE Wurde Nicht für KI-Agenten Entworfen</h2> <p>Agentische Systeme operieren autonom, verketten Werkzeuge über API-Aufrufe, treffen Entscheidungen darüber, welche Daten abgerufen und welche Aktionen ausgeführt werden, und können Anweisungen aus mehreren Quellen erhalten — Benutzer-Prompts, Werkzeugergebnisse, abgerufene Daten. Das STRIDE-Bedrohungsmodell (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) erfasst agentenspezifische Angriffsvektoren wie Prompt-Injektion, Kontextvergiftung oder Werkzeugmissbrauch nicht angemessen.</p> <p>Die Cloud Security Alliance veröffentlichte das MAESTRO-Framework speziell für das Risiko von KI-Agenten.</p> <h2 id="das-maestro-framework">Das MAESTRO-Framework</h2> <p>MAESTRO organisiert agentisches KI-Risiko in sieben Schichten:</p> <ol> <li><strong>Foundation Models</strong> — die zugrunde liegenden LLMs und ihre Trainingsvulnerabilitäten</li> <li><strong>Data Operations</strong> — Datenabruf, -speicherung und -manipulation</li> <li><strong>Agent Frameworks</strong> — die Orchestrierungs- und Koordinationsmiddleware für Agenten</li> <li><strong>Deployment &amp; Infrastructure</strong> — wo Agenten ausgeführt werden und wie sie konfiguriert sind</li> <li><strong>Evaluation &amp; Observability</strong> — Überwachung des Agentenverhaltens im Zeitverlauf</li> <li><strong>Security &amp; Compliance</strong> — Zugriffskontrollen, Prüfung und regulatorische Compliance</li> <li><strong>Agent Ecosystem</strong> — wie Agenten miteinander und mit externen Werkzeugen interagieren</li> </ol> <p>Jede Schicht hat spezifische Angriffsvektoren, die traditionelle Sicherheitskontrollen nicht direkt ansprechen.</p> <h2 id="microsoft-sql-als-regulierte-ausführungsgrenze">Microsoft SQL als Regulierte Ausführungsgrenze</h2> <p>SQL Server 2025 mappt auf konkrete Weise auf MAESTRO-Schichten:</p> <p><strong>Data Operations-Schicht</strong>: Das in T-SQL integrierte <code>AI_GENERATE_EMBEDDINGS</code> hält Vektoroperationen innerhalb der regulierten Datenbankgrenze. Daten müssen nicht für die Embedding-Verarbeitung zum Modelldienst verlassen.</p> <p><strong>Security &amp; Compliance-Schichten</strong>: Row-Level Security (RLS) und Dynamic Data Masking (DDM) gelten unabhängig davon, wie die Anfrage ankam — ob von einem menschlichen Benutzer oder einem KI-Agenten. Der Agent kann keine Kontrollen umgehen, die von der Datenbank selbst durchgesetzt werden.</p> <p><strong>Agent Frameworks-Schicht</strong>: Gespeicherte Prozeduren dienen als Werkzeuggrenzen. Statt Agenten willkürlichen SQL-Zugriff zu geben, definieren Sie erlaubte Operationen als Prozeduren und stellen sie als Agentenwerkzeuge bereit. Parametrisierte Abfragen verhindern Injektion auf Ausführungsebene.</p> <p><strong>Evaluation &amp; Observability-Schicht</strong>: Audit-Logging und Query Store erfassen, was jeder Agent tatsächlich ausgeführt hat — nicht nur, wozu er aufgefordert wurde. Diese Nachverfolgbarkeit ist bei Vorfallsuntersuchungen in agentischen Systemen, bei denen die Zuordnung komplex ist, von entscheidender Bedeutung.</p> <h2 id="defense-in-depth-für-agentische-ki">Defense-in-Depth für Agentische KI</h2> <p>Das Prinzip bleibt dasselbe wie bei traditioneller Sicherheit: Keine einzelne Kontrolle ist ausreichend. Was sich ändert, ist, welche Kontrollen für Agenten am wichtigsten sind:</p> <p><strong>Explosionsradius reduzieren</strong>: Werkzeuggrenzen durch gespeicherte Prozeduren bedeuten, dass ein kompromittierter Agent nur vordefinierte Operationen ausführen kann. Er kann nicht zu willkürlichen Abfragen wechseln.</p> <p><strong>Observierbarkeit</strong>: Sie müssen nach einem Vorfall die Frage beantworten können: &ldquo;Was hat dieser Agent genau getan?&rdquo; Agentische KI-Systeme ohne Nachverfolgbarkeit auf Datenbankebene haben blinde Flecken, die Anwendungsprotokollierung nicht abdeckt.</p> <p><strong>Eingeschränkte Ausführung</strong>: Parametrisierung, RLS und DDM sind Sicherheitseigenschaften unabhängig davon, ob der Aufrufer menschlich ist. Schwächen Sie diese nicht ab, um Agenten zu akkommodieren.</p> <p><strong>Rechenschaftspflicht</strong>: SQL Server-Audit-Logging erstellt eine Aufzeichnung, wer (welcher Agent, mit welchen Anmeldedaten) was zu welchem Zeitpunkt ausgeführt hat. Das ist wichtig, wenn agentische Systeme Aktionen mit realen Konsequenzen durchführen.</p> <p>SQL Server 2025 wurde nicht gebaut, um agentisches Risiko abstrakt zu lösen — es wurde gebaut, um eine relationale Datenbank zu sein. Aber die Governance, die eine Enterprise-Datenbank vertrauenswürdig macht, erweist sich genau als das, was eine Agenten-Ausführungsgrenze sicher macht.</p> <p>Originalpost: <a href="https://devblogs.microsoft.com/azure-sql/microsoft-sql-security-across-the-maestro-stack-building-secure-agentic-ai-with-defense-in-depth/">Microsoft SQL Security Across the MAESTRO Stack</a></p>