Farbschema: Riviera
Sie befinden sich hier: start » de » Dokumentation » Datenintegration und Datenzugriff » WKL Database Gateway » Konzepte » Sicherheitsmodell und Vertrauensgrenzen des Datendienstes

Sicherheitsmodell und Vertrauensgrenzen des Datendienstes

graph TD
    C["Client (Access über den Treiber, Excel, Programm)"] -->|"HTTPS: Anmeldung, Anfrage"| P["vorgeschalteter Proxy (optional, IIS oder anderer)"]
    P -->|"nur aus TrustedProxies: X-Forwarded-For, -Proto"| G["Datendienst: Anmeldung, Richtlinie, Regeln je Objekt und Methode"]
    C -->|"HTTPS direkt"| G
    G -->|"liest; Änderungen nur über die Verwaltung"| S[("Verwaltungsspeicher (Datei, versiegelte Geheimnisse)")]
    K["Hauptschlüssel (Umgebung oder Datei, getrennt)"] -->|"entsiegelt"| G
    G -->|"SQL unter der Anmeldung des Alias, der Person oder einer Sammelanmeldung"| D[("SQL Server")]

Abbildung: Vertrauensgrenzen liegen zwischen Client und Dienst (Netz), zwischen Proxy und Dienst (wessen Herkunftsangabe zählt), zwischen Dienst und Verwaltungsspeicher (Datei und Schlüssel getrennt) und zwischen Dienst und Datenbank (unter welcher Anmeldung SQL ausgeführt wird).

Der Datendienst ist für die Anwendungen der einzige Weg zur Datenbank. Er entscheidet, wer anfragt, was dieser Aufrufer erreicht und unter welcher Anmeldung SQL Server die Anweisung ausführt. Diese Seite fasst zusammen, welche Schutzgüter es gibt, welche Maßnahme sie an welcher Grenze schützt, was der Betreiber beitragen muss und welche Risiken bleiben. Die Einzelheiten stehen auf den verlinkten Seiten; hier steht der Zusammenhang.

Wichtige Funktionen

  • Zwei Fragen, getrennt beantwortet: wer anfragt (Anmeldung) und als wen die Anweisung läuft (Weitergabe je Alias), siehe Anmeldung und Weitergabe der Identität.
  • Was ein Aufrufer nicht lesen darf, gibt es für ihn nicht: Regeln je Alias, Objekt und Methode; verborgene Objekte antworten wie unbekannte, siehe Rechte.
  • SQL entsteht aus Namen, die der Dienst im Katalog nachgeschlagen hat, und gebundenen Werten, nie aus Text des Aufrufers – mit zwei ausdrücklichen Ausnahmen (unten).
  • Geheimnisse im Verwaltungsspeicher versiegelt oder nur als Hash, der Hauptschlüssel getrennt davon, siehe Verwaltungsspeicher und Hauptschlüssel.

Grundkonzepte

Schutzgüter

SchutzgutWo es liegtSchutz
Fachdaten in SQL ServerDatenbankRegeln des Dienstes, dazu die Berechtigungen der Anmeldung, unter der SQL Server ausführt
Verbindungszeichenfolgen der Datenquellen (Anmeldung des Alias)Verwaltungsspeicherversiegelt mit dem Hauptschlüssel; die Verwaltungsschnittstelle gibt sie nie zurück
HauptschlüsselUmgebungsvariable oder Datei (env:, file:)liegt nie in der Speicherdatei; wer ihn hat, entsiegelt die Datei
Persönliche Schlüsselbeim Inhaberim Speicher nur SHA-256, Kennung und letzte vier Zeichen
DienstschlüsselKonfigurationals Verweis (env:, file:) oder ausdrücklich im Klartext (plain:)
Geheimnisse des zweiten FaktorsVerwaltungsspeicherversiegelt
Sitzungen des zweiten Faktorsbeim Client; im Speicher nur als Prüfsummelaufen ab; gelten nur mit ihrem ersten Faktor
Protokoll, Audit, ÄnderungsprotokollDienstprotokoll, Speicherohne Schlüssel, Kennwörter, Verbindungszeichenfolgen und Werte
Lizenzschlüssel der GeodatenbankVerwaltungsspeicherversiegelt; die Verwaltungsschnittstelle gibt ihn nie zurück
Anmeldeprotokoll (Adresse, ungefährer Ort und Person je Anmeldung)VerwaltungsspeicherEinzelereignisse nur mit dem Recht sign-in-events; Aufbewahrung begrenzt (Vorgabe 90 Tage, Stundenwerte ohne Person 400 Tage); Koordinaten auf etwa 10 km gerundet; die Ortung geschieht auf dem Server, keine Adresse verlässt ihn. Siehe Anmeldemuster prüfen
Lastprotokoll (Formen der Anfragen ohne Werte; Anfragen je Tag und Person)VerwaltungsspeicherWerte der Aufrufer werden nie festgehalten; Zahlen je Person und Person bei langsamen Anfragen nur mit dem Recht load-persons, Aufbewahrung nach Vorgabe 7 Tage; die Datei für den Hersteller (export-load) enthält keine Personen, Adressen und Werte. Siehe Last untersuchen

Vertrauensgrenzen und Maßnahmen

GrenzeWas der Dienst durchsetztWas der Betreiber beitragen muss
Client → DienstAnmeldung bei jeder Anfrage; Anmelderichtlinie mit zweitem Faktor je Verfahren, Bereich und Netz; Fehlversuche begrenzt (429). Für Verwaltung, Selbstbedienung, den Austausch des zweiten Faktors und die SQL-Anmeldung verlangt er eine geschützte Verbindung (HTTPS, Loopback, oder vertrauter Proxy mit X-Forwarded-Proto: https). Ändernde Anfragen, die ein Browser im Auftrag einer anderen Webseite sendet (Sec-Fetch-Site, sonst Origin), weist er mit 403 abHTTPS mit einem Zertifikat, dem die Clients vertrauen. Unverschlüsseltes HTTP nur an Loopback binden (Vorgabe des Installationspakets: HTTP 8434 nur an 127.0.0.1)
Proxy → DienstHerkunft, Schema und Host aus X-Forwarded-For, -Proto bzw. -Host nur von Proxys aus TrustedProxies, ausgewertet vom nächsten Glied aus; sonst zählt die GegenstelleDen Dienst nur über die eingetragenen Proxys erreichbar machen, wenn Regeln nach Netz unterscheiden
Dienst → DatenbankNamen nur nach Nachschlagen im Katalog, ordinaler Vergleich, Klammerung mit verdoppelter ]; Werte als Parameter. Weitergabe der Person per EXECUTE AS LOGIN mit Rücknahme; Sperrliste DenyImpersonate. Meldungen von SQL Server ohne verborgene Namen und WerteDie Anmeldung des Alias nur mit den Rechten ausstatten, die die freigegebenen Objekte brauchen. Sie ist die Obergrenze für alles, was unter Service läuft
Dienst → VerwaltungsspeicherÄndern nur über die Verwaltungsschnittstelle (Recht admin, Vorgaberegel: zweiter Faktor); jede Änderung im Änderungsprotokoll; Prüfung vor dem ÜbernehmenSpeicherdatei nur für Dienstkonto und Administratoren (Vorgabe); Hauptschlüssel getrennt sichern; eine Instanz je Speicher

Die drei Wege, auf denen Text des Aufrufers die Datenbank erreicht

  1. Eigene Anweisungen mit dem Recht sql. Der Dienst führt den Text unverändert aus und beurteilt ihn nicht. Die Grenze ist allein die Anmeldung, unter der er läuft – unter Service die des Alias. Ein Aufrufer mit sql erreicht damit alles, was diese Anmeldung erreicht, auch Objekte außerhalb seiner Regeln. Das Recht ist für vertraute Programme gedacht.
  2. Geprüfte Anweisungen ohne sql. Der Dienst zerlegt den Text, lässt nur eine abschließende Liste von Formen zu, prüft jedes Objekt gegen Katalog und Regeln je Methode und führt eine neu erzeugte Fassung aus, siehe Aliasse, Katalog und die zentrale Regel. Die Sicherheit hängt hier an der Vollständigkeit dieser Prüfung; begrenzt bleibt sie zusätzlich durch die Berechtigungen der Anmeldung.
  3. Ungeprüfte Anweisungen unter eigener Anmeldung, ohne sql. Läuft die Anfrage unter einer Anmeldung, die nicht die des Alias ist – SQL-Anmeldung per HTTP Basic, Identitätswechsel der Person (Persons: Impersonate) oder eine Datenbank-Identität der Art Login oder Own –, führt der Dienst den Text unverändert aus, sobald der Alias eigene Anweisungen annimmt (AllowPassThrough) und eine nicht nur lesende Regel des Aufrufers den Alias nennt. Die Grenze sind die Berechtigungen dieser Anmeldung in SQL Server, nicht die Objektlisten der Regel; siehe Die eine Ausnahme.

Restrisiken

RestrisikoBedingungMinderung
Schlüssel über unverschlüsseltes HTTP. Dienstschlüssel und persönliche Schlüssel nimmt der Dienst auch über eine ungeschützte Verbindung an; nur die Verwaltung, die Selbstbedienung, der zweite Faktor und die SQL-Anmeldung verlangen eine geschützteHTTP ist über Loopback hinaus erreichbarHTTP nur an 127.0.0.1 binden (Vorgabe des Installationspakets); der OData-ODBC-Treiber sendet einen persönlichen Schlüssel ohnehin nur über https oder lokal
Ungeprüfte Anweisungen umgehen die Regeln je Objektein Aufrufer mit sql, oder ein schreibender Aufrufer unter eigener Anmeldung an einem Alias mit AllowPassThroughsql nur vertrauten Programmen geben; Anmeldung des Alias und die Anmeldungen der Personen knapp berechtigen; AllowPassThrough nur, wo ungeprüfte Anweisungen gebraucht werden; Alternative: geprüfte Anweisungen
Fehler in der Liste der geprüften Formenein Konstrukt, das die Prüfung übersiehtAusführung bleibt durch die Berechtigungen der Anmeldung begrenzt; die Liste ist abschließend, Unbekanntes wird abgewiesen
Änderungsprotokoll nicht fälschungssicherSchreibzugriff auf die SpeicherdateiDateirechte; ein manipulationssicherer Nachweis gehört in ein System außerhalb des Betreibers
Zähler für Fehlversuche, Anfragegrenzen und die Antworten für Idempotency-Key liegen im ArbeitsspeicherNeustart des Dienstes setzt sie zurückkeine; nach einem Neustart beginnt jede Grenze von vorn
Zeilenfilter über SESSION_CONTEXT verbürgt nur der DienstAnweisungen laufen unter der Anmeldung des Alias; jeder mit derselben Anmeldung könnte den Wert selbst setzeneigene Anmeldungen je Person und Persons: Impersonate, siehe Zeilenweise Einschränkung
SQL-Anmeldung von einer abgelehnten Herkunft verrät, ob ein Kennwort stimmt (401 falsch, 403 richtig)Anmelderichtlinie lehnt SQL-Anmeldungen von außen abFehlversuchsgrenze (fünf je Anmeldung und Alias in der Minute); SQL-Anmeldungen von außen besser gar nicht erreichbar machen
Austausch und Einrichtung des zweiten Faktors werden nur nach Regeln mit Bereich All beurteilteine Ablehnung nur für Data oder AdminAblehnungen nach Netz mit Bereich All anlegen
Ein wiederhergestellter Speicher öffnet, was nach der Sicherung gesperrt wurdeWiederherstellen einer älteren SicherungSperren danach wiederholen, siehe Sicherung
Ohne X-Forwarded-For gilt jede Anfrage als Anfrage des ProxysProxy schickt die Kopfzeile nichtnach dem Einrichten im Audit prüfen, siehe Hinter IIS oder einem Proxy
Eine gespeicherte Antwort zu einem Idempotency-Key wird ohne neue Rechteprüfung wiederholtWiederholung innerhalb von zehn Minuten nach der ersten Antwort, auch nach einer SperreIdempotency-Key als Zufallswert erzeugen; siehe HTTP-Vertrag

Diese Seite beschreibt die Schutzmaßnahmen des Dienstes. Eine Sicherheitsbewertung des Gesamtsystems, in dem er betrieben wird, ersetzt sie nicht.

Verwandte Themen

de/wiki/data-conectivity/database-gateway/concepts/security-and-trust-boundaries.txt · Zuletzt geändert: von Wolfgang van der Stille