Data Gateway
Access, Excel und Power BI an SQL Server – ohne Datenbankkennwort am Arbeitsplatz
Access, Excel, Power BI und eigene Programme kommen an SQL-Server-Daten, ohne dass ein Arbeitsplatz die Datenbank erreicht: Anmeldung, Rechte je Objekt und Protokoll an einer Stelle.
Ausgangslage
Ob ein privater Laptop Kundendaten sehen darf, ob jemand aus dem Ausland arbeitet oder ein Dienstleister zwei Wochen Zugang bekommt – solche Entscheidungen lassen sich nicht durchsetzen, solange jeder Arbeitsplatz die Datenbank direkt erreicht und das Datenbankkennwort in Verbindung oder Mappe steht.
Wer den Zugriff freigeben muss, will außerdem nachweisen können, wer wann was gelesen oder geändert hat – auch, was abgewiesen wurde.
Die Lösung
Der Datendienst nimmt Anfragen über HTTP entgegen, prüft Anmeldung und Rechte, erzeugt daraus SQL und liefert das Ergebnis – im Büro, im Homeoffice oder beim Kunden. Eine Datenbank erscheint nach außen nur unter einem Namen, etwa fachdaten; die Verbindung kennt allein der Dienst. Zwei Oberflächen liegen über demselben Katalog: OData v4 für Access, Excel und Power BI, ein eigener HTTP-Vertrag mit JSON oder XML für Programme.
Vom leeren Server zur ersten Abfrage in etwa einer Stunde:
- Den Dienst mit einem Programm einrichten: Windows-Dienst, HTTPS-Zertifikat, Firewall, auf Wunsch hinter IIS.
- Eine Datenbank unter einem Namen anbinden und festlegen, wer was lesen oder ändern darf.
- Access verknüpft über den OData-ODBC-Treiber, Excel und Power BI laden über Power Query.
- Keine Datenbankverbindung am Arbeitsplatz: Access verknüpft Tabellen über den OData-ODBC-Treiber, Excel und Power BI laden über Power Query; Filter und Sortierung rechnet die Datenbank.
- Kein SQL vom Aufrufer: Jeder Name wird im Katalog der Datenbank nachgeschlagen, jeder Wert als Parameter gebunden. Was nicht im Katalog steht, gibt es für den Aufrufer nicht.
- Regeln bestimmen die Reichweite: je Alias, Art des Objekts, Methode und Lesen oder Schreiben – für Personen, Windows-Gruppen, SQL-Anmeldungen und Dienstschlüssel.
- Die Person kommt in der Datenbank an: auf Wunsch unter ihrer eigenen SQL-Server-Anmeldung; Trigger und Spaltenvorgaben sehen, wer gehandelt hat.
- Nachweis: Jede Anfrage wird mit Aufrufer, Objekt, Methode und Ergebnis protokolliert, auch eine abgewiesene; jede Änderung der Verwaltung steht im Änderungsprotokoll.
Wer was lesen oder ändern darf – je Objekt und Methode
Regeln legen fest, welche Tabellen, Sichten und Prozeduren eine Person erreicht und ob sie nur liest oder auch ändert. Was keine Regel freigibt, gibt es für den Aufrufer nicht.
Jeder Zugriff steht im Protokoll
Das Audit zeigt, wer wann welche Ressource mit welcher Methode aufgerufen hat und mit welchem Ergebnis, auch abgewiesene Anfragen. Werte und Kennwörter stehen nie darin.
So fließen die Daten
Arbeitsplätze erreichen nur den Dienst, nie die Datenbank. Der Dienst prüft jede Anfrage und erzeugt das SQL selbst, unter dem Login, das Sie je Datenquelle festlegen.
Funktionen
- Anmeldung mit Windows-Konto, SQL-Server-Anmeldung, persönlichem Schlüssel oder Dienstschlüssel; zweiter Faktor je nach Verfahren und Netz
- Anmelderichtlinien nach Herkunft und Land: ablehnen oder Code verlangen, Ausnahmen, die von selbst enden
- Je Gerät und Zweck ein eigener Schlüssel, eingeschränkt, befristet und einzeln sperrbar – wirksam ab der nächsten Anfrage
- Fremde Änderungen werden erkannt: Mit Zeilenversion oder Zeilenstempel schreibt der Dienst nichts über eine fremde Änderung
- Anmeldungen nach Ergebnis, Stunde, Land und Netzbetreiber, Auslastung je Abfrageform – in der Verwaltungsanwendung, ohne Werkzeug am Server
- Installation mit einem Programm: Windows-Dienst, HTTPS-Zertifikat, Firewall, auf Wunsch hinter IIS
Anmelden statt Kennwort in der Verbindung
Statt eines Datenbankkennworts melden sich Anwender mit ihrem persönlichen Schlüssel oder ihrem Windows-Konto beim Dienst an. Den Schlüssel kann Windows in der Anmeldeinformationsverwaltung aufbewahren.
Zweiter Faktor, wo Sie ihn verlangen
Wann ein Bestätigungscode nötig ist, entscheidet die Anmelderichtlinie: etwa für die Verwaltung oder für Zugriffe von außerhalb Ihres Netzes.
Weitere Ansichten
Übersicht: gestörte Datenquellen, ablaufende Schlüssel, abgewiesene Anfragen, Auslastung. 
Personen mit Arbeitslisten und der Karte der gewählten Person. 
Was die Anmelderichtlinie für eine Person ergibt: je Netz erlaubt oder Code nötig. 
Datenbank-Identitäten: unter welchem SQL-Server-Login die Anfragen einer Person laufen.
Technische Daten
- Voraussetzungen: SQL Server 2016 oder neuer und ein HTTPS-Zertifikat. Zum Betrieb gehören ein Verwaltungsspeicher mit getrennt aufbewahrtem Hauptschlüssel, Sicherung, Schlüsselwechsel und Notfallzugang. Die Verwaltungsanwendung läuft in Access aus Microsoft 365, als Vollversion oder Runtime, 32 oder 64 Bit; die Anmeldung mit dem Windows-Konto erfolgt dort über NTLM. Technische Daten und Voraussetzungen
Häufige Fragen
Brauche ich für Excel oder Power BI den ODBC-Treiber?
Für Excel und Power BI genügt Power Query; gefiltert wird auf dem Dienst. Den OData-ODBC-Treiber brauchen Sie, um Tabellen in Access zu verknüpfen. Brauche ich den Treiber?
Wie gehen wir mit privaten Geräten und Arbeit im Ausland um?
Über Regeln zur Anmeldung: Der Dienst unterscheidet, wie sich jemand anmeldet und von wo, und verlangt danach einen zweiten Faktor, lehnt ab oder lässt eine befristete Ausnahme zu. Zero Trust und private Geräte
Wie lange dauert die Einrichtung?
Vom leeren Server bis zur ersten Abfrage – Dienst einrichten, eine Datenbank anbinden, einer Person Lesezugriff geben, die ersten Zeilen lesen – etwa eine Stunde. Vom leeren Server zur ersten Abfrage
Wann wirkt eine gesperrte Anmeldung?
Ab der nächsten Anfrage: Gesperrte Schlüssel, abgeschaltete Personen und beendete Sitzungen wirken sofort. Eine Anmelderegel gilt, sobald sie gespeichert ist – darum zuerst für eine Testperson anlegen.
Einrichtung, Beispiele und Referenz, Schritt für Schritt: Alles steht in der Dokumentation.
Dokumentation öffnen