Color scheme: Light
You are here: start » de » Dokumentation » Datenintegration und Datenzugriff » WKL OData-ODBC-Treiber » Konzepte des OData-ODBC-Treibers » Sicherheitsmodell und Vertrauensgrenzen

Sicherheitsmodell und Vertrauensgrenzen

graph TD
    subgraph P["Arbeitsplatz: Prozess der Anwendung, Rechte des Windows-Benutzers"]
        A["Anwendung (Access, DAO, ADO.NET)"] -->|"ODBC-Aufruf"| D["Treiber Wkl OData"]
        D -->|"liest und speichert Schlüssel bzw. Kennwort"| C["Windows-Anmeldeinformationsverwaltung (je Benutzer)"]
        D -->|"Ablaufverfolgung, nur wenn eingeschaltet"| T["Datei der Ablaufverfolgung"]
    end
    D -->|"HTTPS: Anfrage mit Anmeldung, Sitzung, Identität, Transaktion"| S["OData-Dienst prüft Anmeldung und Rechte"]
    S -->|"Anweisung unter einer Anmeldung der Datenbank"| B[("Datenbank")]

Abbildung: Der Treiber läuft im Prozess der Anwendung. Zwischen Arbeitsplatz und Dienst liegt die Netzgrenze, die TLS schützt; zwischen Dienst und Datenbank die Grenze, an der der Dienst entscheidet, was ausgeführt wird. Die Pfeile zeigen, wohin Anmeldedaten und Anweisungen gehen.

Der Treiber ist kein Sicherheitsfilter. Was ein Aufrufer lesen, ändern oder ausführen darf, entscheidet allein der Dienst; eine Anwendung, die den Treiber umgeht und den Dienst unmittelbar per HTTP anspricht, hat dieselben Rechte. Der Treiber schützt die Anmeldedaten, die er hält, und die Daten auf dem Weg. Diese Seite beschreibt, welche Maßnahmen der Treiber dafür trifft, welche der Dienst treffen muss, wie Sie jede Maßnahme prüfen und welche Risiken bleiben.

Wichtige Funktionen

  • Kein Geheimnis in der Access-Datei: Windows-Anmeldung und gespeicherter persönlicher Schlüssel brauchen keinen Wert in der Verbindungszeichenfolge.
  • Geheimnisse nur verschlüsselt oder lokal: Kennwort, persönlicher Schlüssel und Sitzung gehen nur über https oder an den eigenen Rechner; sonst bricht der Treiber ab, bevor er sendet.
  • Geheimnisse nur an die Adressen der Verbindung: Folgeseiten, Adressen aus dem Schemadokument und Umleitungen an einen anderen Rechner erhalten keine Anmeldedaten, auch keine Windows-Anmeldung.
  • Zertifikatsprüfung ohne Abschalter: Ein Zertifikat, dem Windows nicht vertraut, beendet die Verbindung mit 08S01.
  • Sitzung des zweiten Faktors nur im Arbeitsspeicher: Sie endet mit dem Prozess.

Grundkonzepte

Schutzgüter

SchutzgutWer es hältFolge eines Verlusts
Persönlicher Schlüssel, Kennwort einer AnmeldungAnmeldeinformationsverwaltung des Benutzers oder die VerbindungszeichenfolgeEin Dritter meldet sich als diese Person an, bis der Schlüssel gesperrt oder das Kennwort geändert ist
Dienstschlüssel (APIKEY, APIKEYENV)Verbindungszeichenfolge oder UmgebungsvariableEin Dritter erhält die Rechte des Schlüssels; er gilt nicht für eine Person, sondern für ein Programm
Sitzung des zweiten FaktorsArbeitsspeicher des ProzessesEin Dritter, der zusätzlich den ersten Faktor hat, übergeht den zweiten, bis die Sitzung abläuft
Fachdaten auf dem WegTLS-VerbindungMitlesen oder Verändern von Anfragen und Antworten
Fachdaten in der AblaufverfolgungDatei, wenn eingeschaltetAnweisungen, Filterwerte und Anmeldenamen im Klartext (siehe Ablaufverfolgung)

Verantwortung zwischen Treiber und Dienst

PrüfungTreiberDienst
Wer angemeldet istreicht die Anmeldung weiterprüft sie (Kennwort, Schlüssel, Windows-Anmeldung, zweiter Faktor)
Welche Tabellen jemand siehtzeigt, was $metadata nenntnennt in $metadata nur, was der Aufrufer lesen darf
Ob eine Änderung erlaubt istübersetzt sieerlaubt oder lehnt ab (403)
Ob eine eigene Anweisung (Durchreiche) laufen darfprüft sie nicht und stuft sie nicht einnennt die Adresse nur Aufrufern, die Anweisungen schicken dürfen, und entscheidet je Anweisung; der Datendienst Wkl.Data.Gateway prüft dabei jedes genannte Objekt gegen die Rechte des Aufrufers (geprüfte Anweisungen)
Wie lange eine Sitzung gilthält sie, solange der Prozess lebtlegt die Gültigkeit fest und lehnt eine abgelaufene ab
Ob TLS verwendet wirdsendet Geheimnisse nur über https oder lokalbietet https mit einem vertrauenswürdigen Zertifikat an

Der Treiber prüft eine durchgereichte Anweisung bewusst nicht: Ob sie zulässig ist, hängt von den Berechtigungen ab, unter denen sie in der Datenbank liefe, und die kennt nur der Dienst. Eine Prüfung im Treiber wäre außerdem wirkungslos, weil jeder, der den Dienst erreicht, ihn auch ohne den Treiber aufrufen kann.

Anmeldedaten auf dem Arbeitsplatz

Gespeicherter Schlüssel und gespeichertes Kennwort. Wählt der Benutzer im Dialog „Schlüssel speichern“ bzw. „Kennwort speichern“, legt der Treiber den Wert in der Windows-Anmeldeinformationsverwaltung ab – als allgemeine Anmeldeinformation mit der Beständigkeit „lokaler Computer“ (Microsoft: CREDENTIALW, Persist). Daraus folgt:

  • Der Wert gilt nur für dieses Windows-Konto auf diesem Rechner und wandert nicht mit einem servergespeicherten Profil.
  • Windows schützt ihn mit der Anmeldung des Benutzers. Ein anderer Benutzer desselben Rechners liest ihn nicht.
  • Jedes Programm, das unter demselben Windows-Konto läuft, kann ihn lesen. Die Anmeldeinformationsverwaltung trennt nicht nach Programmen. Schadsoftware im Konto des Benutzers erreicht den Schlüssel also ebenso wie den Dienst selbst.

Verbindungszeichenfolge. PWD und APIKEY stehen im Klartext, wo die Zeichenfolge steht: in einer Access-Datei, wenn die Verknüpfung das Kennwort speichern soll (dbAttachSavePWD), in einem Programm oder in einer Datenquelle, die eine Anwendung selbst schreibt. Der Einrichtungsdialog des Treibers schreibt nie ein Kennwort in eine Datenquelle.

Sitzung des zweiten Faktors. Der Treiber hält sie im Arbeitsspeicher des Prozesses, je Dienst und Anmeldung, und schreibt sie nirgendwohin: nicht in die zurückgegebene Verbindungszeichenfolge, nicht in die Ablaufverfolgung, nicht auf die Platte. Mit dem Ende des Prozesses ist sie fort.

Anmeldedaten auf dem Weg

RegelWirkungPrüfung
Kennwort, persönlicher Schlüssel und Sitzung nur über https oder an den eigenen Rechner – an URL wie an PASSTHROUGHÜber http zu einem anderen Rechner scheitert die Verbindung, bevor eine Anfrage gesendet ist: 28000. Verlangt ein Dienst über http einen zweiten Faktor, sendet der Treiber weder Code noch Sitzung und meldet 28000Verbindung mit URL=http://<anderer Rechner>/…;AUTH=KEY aufbauen: Fehler, in der Ablaufverfolgung keine Anfrage
Anmeldedaten nur an Schema, Rechner und Port der Adressen, die die Verbindung nennt (URL, PASSTHROUGH)Eine Folgeseite, eine Durchreicheadresse aus $metadata oder eine Adresse für den zweiten Faktor an einem anderen Ursprung erhält keine AnmeldedatenAblaufverfolgung: „Schluessel und Kennwort gehen nicht an …“
Zertifikat gegen die Zertifikatsspeicher von WindowsEin nicht vertrautes Zertifikat ergibt 08S01 mit dem Grund („UntrustedRoot“) und wird nicht wiederholtsiehe 08S01 „UntrustedRoot“
Einer Umleitung (3xx) folgt der Treiber selbst, nicht die HTTP-Bibliothek: nur beim Lesen und nur am selben Ursprung, höchstens fünfmalEine Umleitung an einen anderen Rechner, Port oder ein anderes Schema bricht mit 08S01 und einer Meldung ab, die das Ziel nennt; nichts wird dorthin gesendet. Eine umgeleitete Änderung wird nicht wiederholtsiehe „Der Dienst leitet an … um“
Windows-Anmeldung (Negotiate) nur auf Anforderung des Dienstes und nur an die Adressen der VerbindungDer Treiber beantwortet eine Herausforderung 401 Negotiate oder NTLM nur, wenn sie von Schema, Rechner und Port von URL oder PASSTHROUGH kommt; ein anderer Rechner erhält keine Windows-Anmeldung, und seine Herausforderung endet mit 28000Ablaufverfolgung: „Die Windows-Anmeldung geht nicht an …“

Ein Dienstschlüssel folgt denselben Ursprungsregeln, geht aber auch über http an einen anderen Rechner. Wer APIKEY oder APIKEYENV verwendet, muss https selbst sicherstellen.

Abgelaufene Sitzung, Wiederholung und Transaktion

  • Sitzung läuft während der Arbeit ab. Der Dienst lehnt die nächste Anfrage mit 401 und der Herausforderung Wkl-Totp ab, bevor er etwas ausführt. Der Treiber fragt einen neuen Code ab und sendet dieselbe Anfrage einmal neu – bei einer Änderung mit demselben Idempotency-Key und in derselben Transaktion. Eine Anwendung ohne Dialog erhält 28000; ein mit TOTP= übergebener Code gilt nur für die erste Herausforderung.
  • Verbindung bricht ab. Der Treiber wiederholt nach 1 und 3 Sekunden: Lesen immer, Ändern mit demselben Idempotency-Key. Hält der Dienst diesen Schlüssel ein, entsteht kein zweiter Satz. Eine gestreamte Durchreiche wiederholt er nie; die Anwendung erhält 08S01.
  • Transaktion verfällt. Nimmt der Dienst eine Transaktion nach seiner Leerlaufzeit zurück, meldet SQLEndTran mit Commit 40001; nichts aus der Transaktion ist gespeichert. Siehe Transaktionen.

Diese drei Zusagen gelten nur, wenn der Dienst ablehnt, bevor er ausführt, und Idempotency-Key einhält (siehe Anforderungen an einen OData-Dienst). Ein Dienst, der die Kopfzeile übergeht, kann nach einem Verbindungsabbruch einen Satz doppelt anlegen; der Treiber erkennt das nicht.

Restrisiken

Grenzen der Maßnahmen, die Sie beim Einsatz kennen und selbst mindern müssen.

RestrisikoUrsacheBedingung, unter der es eintrittMinderung
Keine Prüfung auf zurückgezogene ZertifikateDer Treiber fragt Sperrlisten und OCSP nicht ab (Vorgabe der HTTP-Bibliothek, die der Treiber nicht ändert)Ein Zertifikat des Dienstes wurde zurückgezogen, ist aber noch gültig und vertrautZertifikate kurzlebig halten; ein gestohlenes Zertifikat zusätzlich aus dem Vertrauen der Arbeitsplätze nehmen
Kein Zertifikats-PinningJedes Zertifikat, dem Windows vertraut, giltEine dem Arbeitsplatz vertraute Zertifizierungsstelle stellt ein falsches Zertifikat aus, etwa eine Prüfeinrichtung für TLS im FirmennetzVertrauensspeicher der Arbeitsplätze verwalten
Gespeicherte Anmeldedaten für alle Programme des Benutzers lesbarEigenschaft der AnmeldeinformationsverwaltungSchadsoftware läuft im Konto des BenutzersSchlüssel mit Ablauf und, wo möglich, mit Netzbindung ausstellen lassen; zweiten Faktor verlangen
Ablaufverfolgung enthält Fachdatengewollt, sie dient der Fehlersucheeingeschaltet und nicht gelöschtsiehe Ablaufverfolgung
Unsignierte oder ausgetauschte DLLDer Treiber ist eine DLL im Prozess der Anwendung; ob eine Version signiert ist, zeigen ihre DateieigenschaftenEine Anwendungssteuerung (AppLocker, WDAC) verlangt eine Signatur, oder jemand tauscht die DLL im InstallationsordnerInstallationsordner nur für Administratoren beschreibbar halten; das Installationspaket installiert nach Programme, wo das gilt. Bei der Einrichtung nur für einen Benutzer liegt die DLL in einem Ordner, den der Benutzer selbst ändern kann

Die Maßnahmen dieser Seite betreffen den Treiber. Wie sicher das Gesamtsystem aus Treiber, Dienst und Datenbank ist, hängt ebenso von Dienst und Datenbank ab.

Verwandte Themen

de/wiki/data-conectivity/odata-odbc/concepts/security-and-trust-boundaries.txt · Last modified: by Wolfgang van der Stille