Database Gateway · Datendienst für SQL Server
SQL-Server-Daten für Access, Excel und eigene Programme – ohne Datenbankzugang am Arbeitsplatz
Kein Datenbankkennwort in der Access-Datei. Anmeldung, Rechte und Protokoll an einer Stelle.
Der Datendienst nimmt Anfragen über HTTPS entgegen, prüft Anmeldung und Rechte, erzeugt daraus SQL und liefert das Ergebnis. Access verknüpft Tabellen wie gewohnt, Excel und Power BI laden über Power Query – im Büro und außerhalb des Firmennetzes.
- Access, Excel, Programme
- Datendienst: Anmeldung, Rechte, Protokoll
- SQL Server
Die Arbeitsplätze erreichen nur den Datendienst. Die Verbindung zur Datenbank kennt allein er.
Ausgangslage
Eine verknüpfte Tabelle auf SQL Server funktioniert. Bis die Arbeit das Firmennetz verlässt.
Access und Excel direkt mit SQL Server zu verbinden, ist der gewohnte Weg. Er setzt aber voraus, dass jeder Arbeitsplatz den Datenbankserver im Netz erreicht und dass jede Person oder Anwendung eine Anmeldung in SQL Server hat. Daraus folgen drei Probleme:
- Von außen nur über VPN oder einen offenen Port. Ein offener Datenbankport im Internet ist ein bekanntes Angriffsziel. Ein VPN muss auf jedem Gerät eingerichtet, betrieben und von jedem Anwender bedient werden.
- Die Anmeldedaten reisen mit der Datei. Access speichert die Verbindungszeichenfolge einer verknüpften Tabelle in der Datenbankdatei. Ist „Kennwort speichern“ gewählt, steht darin laut Microsoft auch das Kennwort, unverschlüsselt – und jede Kopie trägt es mit sich.
- Rechte und Protokoll entstehen an vielen Stellen. Was eine Anwendung darf, entscheiden die SQL-Server-Anmeldung und der Code jeder einzelnen Anwendung. Eine zentrale Sperre, einen zweiten Faktor oder Regeln danach, woher jemand zugreift, gibt es so nicht.
Und die bekannten Wege?
VPN, Access-Datendienste, Power Query – was sie leisten und wo sie aufhören
- Direkter Zugang im Firmennetz und über VPN deckt die Arbeit im Büro vollständig ab. Die drei Probleme oben bleiben aber bestehen, und ein Betrieb ohne direkten Datenbankzugang ist damit nicht möglich.
- Die Access-Verknüpfung mit „Datendiensten“ beruht auf den Business Connectivity Services, nicht auf OData, und die verknüpfte Tabelle ist schreibgeschützt.
- Power Query allein genügt, wenn Excel und Power BI nur lesen. Schreiben ist dort nicht vorgesehen.
- Eine eigene Schnittstelle mit Funktionen je Tabelle muss bei jeder neuen Tabelle und jeder Schemaänderung mitwachsen, und Office-Programme können sie nicht als Tabelle verknüpfen.
Der Datendienst liest Tabellen und Sichten aus dem Katalog der Datenbank und erzeugt die Anweisung aus der Anfrage. Zum Bearbeiten im Datenblatt gehört der OData-ODBC-Treiber dazu, über den Access durch den Dienst schreibt. Ausgangslage, Anwendungsfälle und Alternativen im Einzelnen
Mit dem Datendienst
Ein Weg zur Datenbank – geprüft bei jeder Anfrage
Eine Datenbank erscheint nach außen nur unter einem Namen, etwa fachdaten. Darüber liegen zwei Oberflächen: OData v4 für Access, Excel und Power BI und ein eigener HTTP-Vertrag mit JSON oder XML für Programme. Anmeldung, Rechte und Protokoll sind auf beiden dieselben.
Datenquellen, Personen, Regeln und Schlüssel pflegen Sie in der Verwaltungsanwendung, ohne den Dienst neu zu starten. Ihre Übersicht zeigt, was zu tun ist.
- Keine Datenbankverbindung am Arbeitsplatz – Access verknüpft Tabellen über den ODBC-Treiber, Excel und Power BI laden über Power Query; Filter und Sortierung rechnet die Datenbank.
- Nur SQL, das der Dienst erzeugt oder geprüft hat – jeder Name wird im Katalog der Datenbank nachgeschlagen, jeder Wert als Parameter gebunden. Eine eigene Anweisung zerlegt der Dienst und prüft jedes Objekt; ungeprüft läuft sie nur auf einem eigens freigeschalteten Weg.
- 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.
- Anmelden, wie es passt – Windows-Konto, SQL-Server-Anmeldung, persönlicher Schlüssel oder Dienstschlüssel; ein zweiter Faktor je nach Verfahren und Netz.
- Nachweis – jede Anfrage wird mit Aufrufer, Objekt, Methode und Ergebnis protokolliert, auch eine abgewiesene; jede Änderung der Verwaltung steht im Änderungsprotokoll.
- Sie sehen, wer sich von wo anmeldet und was belastet – Anmeldungen nach Ergebnis, Stunde, Land und Netzbetreiber mit Hinweisen auf auffällige Muster, die Auslastung je Abfrageform mit der Zeit in der Datenbank und der naheliegenden Abhilfe.
- Fremde Änderungen werden erkannt – mit Zeilenversion oder Zeilenstempel schreibt der Dienst nichts über eine fremde Änderung, und Access zeigt den gewohnten Schreibkonflikt.
Installiert wird er mit einem Programm: Windows-Dienst, HTTPS-Zertifikat, Firewall, auf Wunsch hinter IIS – So installieren Sie den Datendienst.
Privates Gerät, Dienstleister, Dienstreise – jede Lage hat ihre Regel
Ob ein privater Laptop Kundendaten sehen darf, ob jemand aus dem Ausland arbeitet oder ein Dienstleister zwei Wochen Zugang bekommt, entscheiden Sie. Der Datendienst setzt Ihre Entscheidung bei jeder Anfrage durch und hält fest, was er entschieden hat.
Anfrage
- Access, Excel, Power BI
- Fachanwendung
vom Firmen-PC, vom privaten Gerät oder vom Dienstleister
Anmeldung · Herkunft · Land · zweiter Faktor
Datendienst
- Anmelderichtlinie: ablehnen oder Code verlangen
- Rechte: Alias, Objekt, Methode, nur lesen
- Protokoll: Anmeldung, Anfrage, Änderung
Richtlinie und Rechte legen Sie fest.
Zeilen und Spalten begrenzt die Datenbank über Sichten
Datenbank
- Sichten und Prozeduren
auf Wunsch unter der Anmeldung der Person
Das Firmennetz kann einen Code ersparen, ersetzt aber keine Anmeldung. Jedes Gerät und jeder Zweck bekommt einen eigenen Schlüssel, eingeschränkt, befristet und einzeln sperrbar; eine Sperre wirkt ab der nächsten Anfrage.
Ein privates Gerät erkennt der Dienst nicht als solches, denn er hat keine Verbindung zu einer Geräteverwaltung. Er unterscheidet, wie sich jemand anmeldet und von wo – und genau darauf bauen die Regeln.
Zehn Situationen aus dem Alltag – und wie Sie sie einstellen
- Verwalteter Firmen-PCAnmeldung mit dem Windows-Konto, Regeln nach Windows-Gruppe; aus dem Firmennetz auf Wunsch ohne Code.
- Privater LaptopEin eigener persönlicher Schlüssel für das Gerät, eingeschränkt, und von außen nur mit Code.
- Mitarbeiter im AuslandEine Regel nach Land, für die Reise eine Ausnahme, die von selbst endet.
- Vermittler oder LieferantEine Sicht für alle, die nach der anfragenden Person filtert: Jeder sieht nur seine eigenen Zeilen. Die Regel nur auf diese Sicht, der Schlüssel befristet und nur lesend.
- Excel und Power BIEin Schlüssel je Zweck, nur lesend und auf einen Alias begrenzt.
- Access- und VBA-FachanwendungEin eigener Alias je Anwendung; die Person kommt in SQL Server an.
- Unbekannte HerkunftAblehnen nach Herkunft, Code verlangen, Auffälligkeiten melden lassen. In der Verwaltungsanwendung wird aus einer Herkunft in der Anmeldeübersicht direkt eine ablehnende Regel.
- Dienstleister auf ZeitEine Person mit befristetem Schlüssel, der Schlüssel auf Abruf.
- Verlorenes GerätSchlüssel sperren, Sitzungen beenden, zweiten Faktor zurücksetzen – wirksam ab der nächsten Anfrage.
- Prüfung durch die RevisionAnmeldeereignis, Protokoll der Anfrage und Änderungsprotokoll zeigen, warum der Dienst so entschieden hat.
Eine Anmelderegel wirkt, sobald sie gespeichert ist. Darum zuerst für eine Testperson anlegen, nachrechnen lassen, was gilt, echt anmelden – und erst dann ausweiten und eine Stunde lang die abgewiesenen Anmeldungen beobachten: So prüfen Sie eine Regel vor dem Scharfschalten.
Voraussetzungen und Grenzen
Passt der Datendienst zu Ihrem Betrieb?
Er passt, wenn Ihre Daten in SQL Server liegen und Arbeitsplätze, Excel-Mappen und Programme die Datenbank nicht direkt erreichen sollen. Prüfen Sie vorher diese Punkte:
- Nur SQL Server. Datenbanken bindet der Dienst über nachladbare Provider an; mitgeliefert ist der für SQL Server.
- Eine Instanz, eine neue Abhängigkeit. Je Verwaltungsspeicher läuft eine Instanz; eine Ausfallsicherheit über zwei gibt es nicht. Fällt der Dienst aus, erreicht kein Arbeitsplatz die Daten.
- Betrieb: ein Verwaltungsspeicher mit getrennt aufbewahrtem Hauptschlüssel; Sicherung, Schlüsselwechsel, Notfallzugang und ein HTTPS-Zertifikat, dem die Arbeitsplätze vertrauen, gehören dazu.
- Access über den ODBC-Treiber: Er bietet nicht jede Fähigkeit des ODBC-Treibers von SQL Server; welche fehlen, nennen die Grenzen des Treibers.
- Verwaltungsanwendung: Access aus Microsoft 365 als Vollversion oder Runtime, in 32 oder 64 Bit. Die Anmeldung mit dem Windows-Konto geht dort über NTLM, nicht über Kerberos in einer Domäne.
Was Ihre IT-Sicherheit wissen will
Wer den Betrieb des Datendienstes freigeben muss, fragt drei Dinge: was der Dienst leistet, was beim Betrieb bleibt und was der Dienst nicht übernimmt.
- Der Dienst leistet: keine Verbindung zur Datenbank und kein Datenbankkennwort am Arbeitsplatz. Anmeldung und Rechte je Alias, Objekt und Methode stehen an einer Stelle. Jede Anfrage wird mit Aufrufer, Objekt, Methode und Ergebnis protokolliert, auch eine abgewiesene, und jede Änderung der Verwaltung steht im Änderungsprotokoll. Gesperrte Schlüssel, abgeschaltete Personen und beendete Sitzungen wirken ab der nächsten Anfrage. Eine Person, die Schlüssel, Anmeldungen oder Änderungen hinterlassen hat, lässt sich nur sperren, nicht löschen, damit jeder Protokolleintrag zuzuordnen bleibt.
- Beim Betrieb bleibt: die Rechte der SQL-Server-Anmeldungen, unter denen der Dienst ausführt, und wer eigene Anweisungen senden darf – für diese Aufrufer begrenzen allein die Datenbankrechte, was erreichbar ist. Dazu kommen der getrennt aufbewahrte Hauptschlüssel mit Sicherung, Schlüsselwechsel und Notfallzugang, das HTTPS-Zertifikat und die Aufbewahrung und Auswertung der Protokolle. Unverschlüsseltes HTTP bindet das Installationspaket an den eigenen Rechner; so soll es bleiben.
- Der Dienst übernimmt nicht: die Prüfung des Geräts – ob es verwaltet, verschlüsselt oder aktuell geschützt ist, weiß er nicht, denn er hat keine Verbindung zu einer Geräteverwaltung. Was ein Gerät einmal erhalten hat, liegt dort; Speichern, Kopieren und Drucken steuern Geräteverwaltung und Anwendung. Ebenso wenig gibt es einen eingebauten Schutz der Protokolle gegen nachträgliche Änderung.
Das Sicherheitsmodell des Datendienstes · Betrieb: Sicherung, Schlüssel, Notfallzugang · Was der Dienst nicht steuert
Hier beginnen
- Vom leeren Server zur ersten AbfrageDienst einrichten, eine Datenbank anbinden, einer Person Lesezugriff geben, die ersten Zeilen lesen – etwa eine Stunde.
- Daten in Excel oder Power BI ladenÜber Power Query, gefiltert auf dem Dienst; ein ODBC-Treiber ist dafür nicht nötig.
- Tabellen in Access verknüpfenMit dem OData-ODBC-Treiber, im Datenblatt und Formular bearbeiten. Brauche ich den Treiber?
- Aus einem Programm zugreifenDer eigene HTTP-Vertrag mit JSON oder XML.
- Den Datendienst verwaltenDatenquellen, Personen, Schlüssel und Regeln im Database Gateway Manager pflegen.
- Überblick über die DokumentationErste Schritte, Anleitungen, Konzepte, Referenz, Fehlerbehebung und Betrieb.
Sie wollen wissen, was zum Datendienst gehört und was Ihr Server dafür mitbringen muss? Funktionen, Voraussetzungen und Grenzen stehen auf der Produktseite.
Zur Produktseite