So schalten Sie eigene Anweisungen frei

Eigene Anweisungen (Pass-Through) braucht, wer Anweisungen ungeprüft an die Datenbank schicken will – etwa Access mit Pass-Through-Abfragen, die Schemaänderungen, temporäre Tabellen oder mehrere Anweisungen enthalten.

Für Verbünde, Gruppierungen über mehrere Tabellen, Funktionen und mengenbasierte Änderungen über verknüpfte Tabellen ist keine Freischaltung nötig: Diese Anweisungen prüft der Dienst gegen die Regeln des Aufrufers und führt sie aus, solange der Alias geprüfte Anweisungen zulässt (Vorgabe), siehe Geprüfte Anweisungen.

Freigeschaltet wird an zwei Stellen: an der Datenquelle (Schalter Durchreiche bzw. AllowPassThrough) und beim Aufrufer. Was eine Anweisung darf, entscheidet die Anmeldung, unter der sie läuft:

Begründung: Die eine Ausnahme: der Durchreichepfad.

Mit Verwaltungsspeicher (Verwaltungsanwendung):

1. Öffnen Sie Datenquellen, markieren Sie die Datenquelle, aktivieren Sie in der Maske Durchreiche, und wechseln Sie zurück in die Liste.
2. Für Aufrufer der ersten Zeile oben: Öffnen Sie Regeln, markieren Sie die Regel des Aufrufers, wählen Sie Merkmal hinzufügen … aus und legen Sie das Merkmal resource mit dem Wert sql an; die Regel darf nicht nur lesend sein. Siehe „So legen Sie eine Regel an“ (Dokumentation der Verwaltungsanwendung).
3. Prüfen Sie: Ein Aufrufer mit dieser Regel sendet POST /api/v1/cf/<alias>/sql.json mit {"sql": "SELECT SUSER_SNAME() AS anmeldung"} und erhält 200 mit dem Namen der Anmeldung, unter der die Anweisung lief. Diese Probe beweist den ungeprüften Weg: In einer geprüften Anweisung weist der Dienst Funktionen ab, die die Anmeldung beschreiben, ein SELECT 1 dagegen ginge auch geprüft durch. Für Aufrufer der zweiten Zeile gilt dieselbe Probe mit ihrer eigenen Anmeldung; die Antwort nennt dann diese Anmeldung. Ein Aufrufer ohne passende Regel erhält 403.

Ohne Verwaltungsspeicher (Konfigurationsdatei): Tragen Sie beide Einträge ein und starten Sie den Dienst neu:

{
  "Gateway": {
    "Databases": [
      { "Name": "fachdaten", "Provider": "sqlserver", "ConnectionString": "…",
        "AllowPassThrough": true }
    ],
    "Security": {
      "Clients": [
        { "Id": "auswertung", "Databases": [ "fachdaten" ],
          "Resources": [ "views", "sql" ], "Verbs": [ "GET", "POST" ], "ReadOnly": false }
      ]
    }
  }
}

Eine Regel, die sql nennt und zugleich nur lesend ist, verhindert den Start.

Abschalten. Den Schalter Durchreiche der Datenquelle ausschalten (bzw. AllowPassThrough entfernen); damit endet der Weg für alle Aufrufer, auch für die der zweiten Zeile, im Verwaltungsspeicher mit der nächsten Anfrage, in der Konfigurationsdatei nach einem Neustart. Wer nur einzelnen Aufrufern den Weg nehmen will, entfernt sql aus ihrer Regel – das wirkt nur für die erste Zeile der Tabelle; den Aufrufern der zweiten Zeile nimmt man ihn nur über den Schalter oder eine nur lesende Regel.

• Wählen Sie die Datenquelle mit Bedacht. Was die Anmeldung ihrer Verbindungszeichenfolge darf, darf jede durchgereichte Anweisung – Lesen, Schreiben, Schemaänderungen. Eine Datenquelle, deren Anmeldung das Schema besitzt oder weitreichende Berechtigungen hat, sollte den Schalter nicht bekommen.

• Läuft die Anweisung als Person, ist SQL Server die einzige Schranke. Für die zweite Zeile der Tabelle oben genügt eine nicht nur lesende Regel; die Ressource sql muss sie nicht nennen. Ein solcher Aufrufer darf dann beliebiges SQL schicken – alles, was die Anmeldung der Person in SQL Server darf, nicht mehr und nicht weniger. Die Regeln des Dienstes entscheiden nur noch, ob er Anweisungen schicken darf, nicht welche. Wer Schreiben ausschließlich über Prozeduren führen will, vergibt den Personen (oder einer Datenbankrolle, in der sie Mitglied sind) dieses Berechtigungsprofil:

  Berechtigung	Wofür
  GRANT SELECT auf die Sichten, die gelesen werden	Lesen über Sichten, auch zeilenweise gefiltert (siehe Zeilenweise Einschränkung)
  GRANT EXECUTE auf die Prozeduren, die schreiben	Schreiben nur über die Prüfungen der Prozedur
  kein INSERT, UPDATE, DELETE auf die Tabellen	Sonst schreibt eine durchgereichte Anweisung an den Prozeduren vorbei
  Sichten, Prozeduren und Tabellen mit demselben Besitzer	Dann prüft SQL Server die Berechtigungen für die Tabellen nicht noch einmal (Besitzverkettung); Sicht und Prozedur erreichen die Tabelle ohne eigene Berechtigung der Person
  kein CONTROL oder ALTER auf dem Schema, kein IMPERSONATE	Wer das Schema ändern oder die Identität wechseln darf, hebt jede der Zeilen oben auf

  Prüfen Sie außerdem, was die Rolle public der Datenbank schon darf: Jede Berechtigung dort gilt für jede Person. Und der Identitätswechsel schützt nicht vor Gruppenberechtigungen: Berechtigungen aus Windows-Gruppen gelten unter dem Wechsel mit. Eine Gruppe mit db_datawriter gibt jedem Mitglied das Schreiben in alle Tabellen zurück.

• Der Anweisungstext steht im Audit-Strom; die Werte nicht.
• Ein Dienst, der die Adresse für eigene Anweisungen anbietet, nennt sie Berechtigten in seinem Schemadokument; der ODBC-Treiber findet sie dann von selbst.

• HTTP: Eigene Anweisungen (Durchreiche)
• „So binden Sie eine Datenquelle an“ (Administrator-Handbuch der Verwaltungsanwendung)
• Dokumentation des ODBC-Treibers: „Pass-Through-Abfragen einrichten“