SQL-Server-Anwendungen gezielt Prozedurzugriff geben

Eine Anwendung, die nur eine Rechnungssumme benötigt, muss nicht jede Tabelle verändern oder das Schema bearbeiten können. db_owner lässt manche Bereitstellungsfehler verschwinden, verdeckt aber die tatsächlichen Abhängigkeiten. Eine kleine klar definierte Berechtigungsfläche lässt sich leichter prüfen und dauerhaft stabil halten.

Gespeicherte Prozeduren können diese Grenze bilden, wenn Inhalt und Eigentümerbeziehungen verstanden sind. Entscheidend ist nicht nur die mögliche Anmeldung, sondern welche Lese- und Schreiboperationen die Anwendung über welche freigegebenen Einstiegspunkte ausführen kann.

Die Operation über eine Rolle freigeben

Das Beispiel erstellt eine Übungstabelle mit E-Mail-Adressen und eine Prozedur, die nur Anzahl und Summe zurückgibt. Verwenden Sie eine entbehrliche Datenbank. GO trennt Client-Batches; Treiber ohne GO-Unterstützung müssen diese getrennt senden.

-- Run in a disposable practice database as its administrator.
CREATE TABLE dbo.PermissionInvoiceDemo (
    InvoiceId int PRIMARY KEY,
    CustomerEmail nvarchar(200) NOT NULL,
    Total decimal(12,2) NOT NULL
);
INSERT dbo.PermissionInvoiceDemo VALUES
(1, N'example1@example.invalid', 40.00),
(2, N'example2@example.invalid', 60.00);
GO
CREATE PROCEDURE dbo.GetInvoiceSummaryDemo
AS
BEGIN
    SET NOCOUNT ON;
    SELECT COUNT_BIG(*) AS InvoiceCount, SUM(Total) AS InvoiceTotal
    FROM dbo.PermissionInvoiceDemo;
END;
GO
CREATE ROLE InvoiceSummaryReaderDemo AUTHORIZATION dbo;
CREATE USER InvoiceReportUserDemo WITHOUT LOGIN;
ALTER ROLE InvoiceSummaryReaderDemo ADD MEMBER InvoiceReportUserDemo;
GRANT EXECUTE ON OBJECT::dbo.GetInvoiceSummaryDemo
TO InvoiceSummaryReaderDemo;

WITHOUT LOGIN erzeugt bewusst einen Benutzer für einen lokalen Berechtigungstest, kein tatsächliches Anwendungskonto. Bei der Bereitstellung wird der echte Anwendungsbenutzer passend zum vorhandenen Authentifizierungsmodell erstellt oder zugeordnet und der schmalen Rolle hinzugefügt.

Die Rolle erhält EXECUTE für genau eine Prozedur, aber kein allgemeines SELECT auf der Tabelle. Beide Objekte haben über dbo denselben Besitzer; der Prozedurtext verwendet statisches SQL. Bei einer ununterbrochenen Eigentümerkette kann SQL Server den Aufruf zulassen, ohne zusätzlich Tabellenrechte des Aufrufers zu verlangen.

Das erwartete Ergebnis ist zwei Rechnungen mit einer Summe von 100,00. E-Mail-Adressen werden nicht ausgegeben. Das zeigt eine Objektzugriffsgrenze, keine allgemeine Datenschutzgarantie: Auch Aggregate benötigen Prüfung, wenn kleine Gruppen sensible Informationen verraten können.

Die Grenzen des Musters kennen

Eine Prozedur ist nicht automatisch sicher, weil ihr Aufrufer keine Tabellenrechte besitzt. Beliebige Objektnamen, ungeprüftes dynamisches SQL oder unbeschränkte Mandantendaten können weiterhin übermäßigen Zugriff ermöglichen. Der Prozedurinhalt gehört deshalb zur Rechteprüfung.

Dynamisches SQL profitiert nicht von derselben statischen Eigentümerkette. sp_executesql mit Parametern behandelt Werte und reduziert Injektionsrisiken, erteilt aber keine zusätzlichen Ausführungsrechte für den erzeugten SQL-Text. db_owner für die Anwendung ist keine passende Reparatur.

Für notwendige dynamische oder grenzüberschreitende Zugriffe können gezielte Modulsignierung oder ein bewusst gewählter Ausführungskontext passen. Eine Zertifikatsignatur kann während der Modulausführung schmale Zusatzrechte bereitstellen. Die Bereitstellung muss jedoch das erneute Signieren nach einer Moduländerung sicherstellen. Zertifikatsverwaltung und konkrete Rechte müssen überprüfbar bleiben.

TRUSTWORTHY oder allgemeine datenbankübergreifende Eigentümerketten sollten nicht routinemäßig aktiviert werden, um einen einzelnen Fehler zu beseitigen. Sie verändern eine größere Vertrauensgrenze. Entwerfen Sie stattdessen den konkreten datenbankübergreifenden Zugriff.

Mit der tatsächlichen Identität prüfen

Ein erfolgreicher sysadmin-Test belegt wenig über Anwendungsrechte. Dieser Test führt die Zusammenfassung als eingeschränkter Benutzer aus und stellt den ursprünglichen Kontext auch bei Fehlern wieder her.

EXECUTE AS USER = N'InvoiceReportUserDemo';
BEGIN TRY
    EXEC dbo.GetInvoiceSummaryDemo;
END TRY
BEGIN CATCH
    REVERT;
    THROW;
END CATCH;
REVERT;

Prüfen Sie zusätzlich, dass ein direkter Zugriff auf CustomerEmail abgelehnt wird. Erlaubte und verbotene Operationen gehören beide in die Prüfung. Katalogeinträge allein reichen nicht: Rollen, direkte Rechte, DENY, Besitz und übergeordnete Privilegien beeinflussen den effektiven Zugriff.

Trennen Sie Bereitstellungs- und Laufzeitidentität. Ein Release darf möglicherweise Prozeduren ändern; normale Anfragen brauchen diese Fähigkeit nicht. Neue Operationen erhalten gezielte Rechte, statt die Laufzeitrolle pauschal auf alle vorhandenen und zukünftigen Objekte auszuweiten.

Auch EXECUTE auf Schemaebene verdient Prüfung. Es kann zu einem bewusst verwalteten API-Schema passen, gilt aber automatisch für später angelegte Prozeduren. Das ist eine organisatorische Entscheidung und nicht nur kürzere Syntax.

Eine sinnvolle Releaseprüfung bestätigt erlaubte Aufrufe, verweigerten direkten Zugriff auf geschützte Spalten und fehlende Änderungsrechte an Objekten. Dadurch wird eine versehentliche Privilegienausweitung sichtbar, bevor sie zum dauerhaften Normalzustand wird.

Technische Referenzen: Microsoft Learn: Database Engine permissions · Microsoft Learn: GRANT object permissions · Microsoft Learn: Sign a procedure with a certificate.