Homeoffice 2020: Die Anwendung lief. War die Architektur darauf vorbereitet?

Rückblick auf die Entstehung des Database Gateway in den ersten Wochen der Pandemie 2020. Der Beitrag schließt die späteren Entwicklungsstufen ein und beschreibt das Produkt mit Stand vom 29. Oktober 2026.

Im Frühjahr 2020 lautete die Frage: Wie kann jemand morgen von zu Hause arbeiten? Heute lautet sie: Wie bleibt der Zugriff auf Geschäftsdaten sicher, nachvollziehbar, schnell genug und wartbar – auch in fünf Jahren? Dazwischen liegt die Geschichte eines Notbehelfs, der funktioniert hat. Gerade deshalb war er so schwer zu ersetzen.

Montag, 23. März 2020, kurz nach sieben. Ein Morgen, wie ihn damals viele Betriebe erlebten. Nehmen wir die Schichtplanerin eines Chemiestandorts: Sie sitzt am Küchentisch. Am Abend zuvor haben Bund und Länder beschlossen, Kontakte außerhalb des eigenen Haushalts auf ein „absolut nötiges Minimum“ zu beschränken, zunächst für mindestens zwei Wochen. Im Werk öffnete das Formular mit den offenen Prüfaufträgen in drei Sekunden. Jetzt dreht sich die Sanduhr. Das Kombinationsfeld mit den Anlagen braucht eine halbe Minute. Beim zweiten Formular bricht die Verbindung ab, und die Frage aus jedem Forum steht im Raum: Hat es jetzt die Datenbank zerschossen?

Zur selben Zeit rechnet die IT-Leitung mit VPN-Zugängen, die sich nicht per Knopfdruck verdoppeln lassen, und mit einem Datenbankserver, der nie aus dem Internet erreichbar sein sollte. Die Werkleitung sagt einen Satz: Der Betrieb muss weiterlaufen. Und der Entwickler der Anwendung bekommt einen Anruf: Bitte bis morgen.

So ging es nicht nur einem Werk. Im April 2020 arbeiteten nach einer Befragung der Hans-Böckler-Stiftung 27 Prozent der Beschäftigten in Deutschland ausschließlich oder überwiegend von zu Hause. Für viele Fachanwendungen war das ein Einsatz, für den sie nie gebaut worden waren.

Der erste Verdacht fällt fast immer auf die Leitung zu Hause. Er greift zu kurz. Eine schnellere Leitung hilft wenig, wenn eine Anwendung für ein einziges Formular Hunderte kleiner Fragen an die Datenbank stellt und auf jede Antwort wartet. Im Werksnetz dauert so eine Runde kaum eine Millisekunde, über VPN und Heimanschluss ein Vielfaches davon. Mehr Bandbreite verkürzt diese Wartezeit nicht.

„Access ist ein Datenbankspielzeug aus dem letzten Jahrtausend“ – so steht es in Foren, wenn jemand fragt, warum seine Anwendung über VPN unbrauchbar ist. Das Urteil ist bequem, aber es trifft die falsche Stelle. Es kommt darauf an, wie eine Anwendung auf ihre Daten zugreift. Vier Lagen sind zu unterscheiden, und sie verhalten sich grundverschieden.

Die Datenbankdatei auf dem Netzlaufwerk. Liegt das Backend als ACCDB auf einem Server, liest jeder Arbeitsplatz die Datei selbst, Seite für Seite. Microsoft rät ausdrücklich davon ab, eine geteilte Access-Datenbank über ein WAN zu betreiben: Sie kann langsam werden, und Datenbanken können beschädigt werden. Die Angst vor dem „Zerschießen“ ist also kein Aberglaube.

Access als Frontend, SQL Server als Backend. Mit verknüpften Tabellen über ODBC rechnet der Server. Das ist der gewohnte und im Büro bewährte Weg. Doch Access stellt viele kleine Fragen: Jedes Listenfeld, jedes Kombinationsfeld, jedes Unterformular und jede Summe ist laut Microsoft eine eigene Abfrage. Was der Server nicht versteht, wertet Access lokal aus. Verknüpft eine Abfrage eine lokale mit einer entfernten Tabelle, schickt Access unter Umständen eine Abfrage je lokaler Zeile. Im Werksnetz merkt das niemand. Über VPN addiert sich jede Wartezeit. Dazu kommt: Jeder Arbeitsplatz muss den Datenbankserver erreichen, und die Verbindung samt Anmeldung steht in der Access-Datei.

Access auf einem Terminalserver. Remote Desktop Services und RemoteApp sind Microsofts unterstützter Weg, Access aus der Ferne zu nutzen. Über die Leitung gehen nur Bildschirminhalte; Access und Datenbank stehen nebeneinander im Rechenzentrum. Das funktioniert gut, und für viele Betriebe war es 2020 die richtige Antwort. Es braucht allerdings Server, Lizenzen, Benutzerprofile und für jeden Anwender ein eigenes Frontend auf dem Server – und all das muss erst einmal da sein.

Ein Datenvermittler über HTTP. Die Anwendung spricht nicht mehr mit der Datenbank, sondern mit einem Dienst, der für sie die Datenbank befragt. Wenige größere Anfragen ersetzen viele kleine, und der Datenbankserver bleibt für die Arbeitsplätze unerreichbar.

Alle vier Wege haben ihre Berechtigung. Sie verteilen nur Wartezeit, Verantwortung und Angriffsfläche unterschiedlich. Für unsere Lage im Frühjahr 2020 – Fachanwendungen, teils in Access, teils als .NET-Windows-Anwendungen aus Access hervorgegangen, und sehr wenig Zeit – haben wir den vierten Weg gewählt.

Gebaut haben wir in Tagen, nicht in Monaten. Auf der Serverseite entstand ein Webdienst, der eine SQL-Anweisung über HTTP entgegennimmt, gegen die Datenbank ausführt und das Ergebnis als Tabellen zurückgibt. Auf der Seite der Anwendung entstand eine kleine .NET-Bibliothek, die genau so aussah wie der gewohnte Datenzugriff.

Der Zeitdruck hat die Entscheidungen diktiert, und wir haben sie bewusst so getroffen:

• Die Anwendung schickte ihre SQL-Anweisungen so, wie sie sie bisher an die Datenbank geschickt hatte. Kein Formular musste neu geschrieben werden.
• Die Anwendung nannte die Datenbank. Der Dienst übersetzte den Namen in eine hinterlegte Verbindung.
• Jede Anfrage trug Name und Kennwort. Der Dienst prüfte, ob es diese Person gab.
• Fehler der Datenbank kamen als Meldungstext zurück, damit der Anwender sah, was schiefging.

Getestet haben wir, was die Anwender am nächsten Morgen brauchten: Formulare öffnen, Daten ändern, Berichte drucken. Dann ging es in Betrieb. Und es funktionierte. Die Prüfaufträge öffneten wieder in Sekunden, die Planung lief vom Küchentisch aus, und der Betrieb stand nicht still.

Warum ließ sich das in Tagen bauen? Weil wir nicht die Anwendung umgeschrieben haben, sondern nur ihren Weg zur Datenbank. Die Bibliothek bildete die vier Rollen nach, die jeder .NET-Entwickler aus ADO.NET kennt: eine Verbindung, einen Befehl mit Parametern, einen Leser für das Ergebnis und einen Adapter, der Tabellen füllt. Der Code der Anwendung blieb, wie er war. Ausgetauscht wurde nur, was hinter dem Wort Connection stand.

Das war die eigentliche Idee, und sie ist bis heute richtig: Eine Anwendung soll für einen neuen Transportweg nicht neu geschrieben werden müssen. Der heutige Database Gateway folgt ihr mit einem ODBC-Treiber, über den Access Tabellen verknüpft wie gewohnt.

Ein vertrautes Modell verbirgt allerdings auch etwas. Eine Clientbibliothek zeigt nicht, was der Server tut. Drei Beobachtungen aus dem Code von damals sind lehrreich, weil sie keine Fehler im üblichen Sinn sind:

• Parameter schützen Werte, nicht Anweisungen. Die Bibliothek gab Werte als Parameter weiter, und der Dienst band sie sauber. Das verhindert, dass ein Wert zur Anweisung wird. Es hilft nichts, wenn die Anweisung selbst vom Aufrufer stammt.
• Eine Transaktion, die stillschweigend keine ist. Eine Transaktion zu beginnen, lehnte die Bibliothek ab. Einem Befehl eine Transaktion zuzuweisen, nahm sie dagegen an und ignorierte sie. Wer sich darauf verließ, bekam einzelne Anweisungen.
• Keine Grenzen. Ein Ergebnis wurde vollständig in den Speicher geladen, eine Zeitbegrenzung gab es nicht, und abbrechen ließ sich eine Anfrage auch nicht.

Unter Zeitdruck war jede dieser Entscheidungen nachvollziehbar. Zusammen beschreiben sie ein System, das funktioniert, solange alle sich so verhalten, wie man es erwartet.

Eine Lösung kann ihre Aufgabe vollständig erfüllen und trotzdem unreif sein. Das ist kein Widerspruch, denn „funktioniert“ ist nur eine von mehreren Eigenschaften, die ein System haben muss.

Die schwerwiegendste Zeile ist die dritte. Der Dienst prüfte, wer anfragt, aber nicht, was diese Person darf. Eine erfolgreiche Anmeldung ist keine Berechtigung. Wer einen gültigen Namen und das passende Kennwort hatte, konnte jede Anweisung schicken, die die Anmeldung des Dienstes ausführen durfte, in jeder hinterlegten Datenbank, deren Namen er kannte. Solange nur die eigene Anwendung mit dem Dienst sprach, fiel das nicht auf: Sie stellte ja nur die Fragen, für die sie gebaut war. Die Grenze lag im Wohlverhalten des Clients, nicht im Dienst.

Und noch etwas fehlte: der Beweis. Ohne automatische Tests kann niemand behaupten, eine Schwäche sei behoben. Man kann nur sagen, dass sie bisher nicht aufgefallen ist.

Stellen Sie sich das Gespräch vor, ein Jahr später. Der Entwickler erklärt, dass der Notzugang neu gebaut werden sollte: mit Rechten je Objekt, Protokoll, Grenzen und Tests. Der Auftraggeber sieht eine Anwendung, die seit einem Jahr läuft, ohne Ausfall und ohne Vorfall. Er hat für sie bezahlt. Jetzt soll er noch einmal zahlen, für etwas, das aus seiner Sicht schon funktioniert.

Der Auftraggeber ist dabei nicht unvernünftig. Er sieht eine Lösung, die läuft, und eine neue Rechnung. Der Entwickler sieht dieselbe Lösung und eine Liste von Risiken, die kein Anwender sehen kann. Beide haben recht, und keiner kann dem anderen seine Sicht beweisen. Der Auftraggeber kann die innere Qualität dessen, was er bezahlt hat, nicht prüfen. Der Entwickler kennt die Mängel und bietet zugleich ihre Behebung an; das macht ihn verdächtig, gerade wenn er recht hat. So ist die Erneuerung ausgerechnet deshalb schwer zu begründen, weil der Notzugang nie versagt hat. Es ist ja nichts passiert.

Ein Notbehelf aus einer Krise ist technische Schuld zu besonders hohem Zins. Jede Anwendung, die zusätzlich an ihm hängt, erhöht sie, und je länger er störungsfrei läuft, desto schwerer lässt sie sich zurückzahlen. Daraus folgt eine unbequeme Einsicht: Der Erfolg einer Notlösung kann zum größten Hindernis ihrer Verbesserung werden. „Nichts ist so beständig wie ein Provisorium“ – der Satz ist im Werk so bekannt wie in der IT.

Überzeugt hat am Ende nicht die Technik, sondern eine Frage in der Sprache der Verantwortung: Wer kann heute belegen, wer über diesen Zugang welche Daten gelesen oder geändert hat? Für Prüf- und Instandhaltungsdaten in der Industrie ist das keine akademische Frage. Und wer müsste es erklären, wenn ein Kennwort in falsche Hände gerät?

Der erste Versuch, die Lücke zu schließen, war eine Entwurfsstudie aus dem Januar 2025. Sie stellte die richtige neue Frage: nicht mehr „welche Anweisung?“, sondern „welches Objekt?“ – eine Tabelle, eine Sicht, eine Prozedur, adressiert über die Adresse der Anfrage. Aber sie ließ den Client noch Server und Datenbank nennen. Und an ihr zeigte sich, dass sich Sicherheit nicht nachrüsten lässt, wenn die Grundannahme bleibt, dass der Client entscheidet. Wir haben sie nicht fertig gebaut. Der heutige Database Gateway ist eine neue Codebasis, begonnen im August 2026.

Der entscheidende Wechsel ist kein neues Protokoll, sondern ein Umzug der Entscheidungen. 2020 entschied der Client, welche Datenbank, welche Anweisung, welche Daten. Heute fragt der Client, und der Dienst entscheidet.

Vier Vertrauensgrenzen sind heute ausdrücklich beschrieben: zwischen Client und Dienst (Anmeldung bei jeder Anfrage, Anmelderichtlinie, zweiter Faktor), zwischen einem vorgeschalteten Proxy und dem Dienst (Herkunftsangaben zählen nur von eingetragenen Proxys), zwischen Dienst und Datenbank (unter welcher Anmeldung SQL läuft) und zwischen Dienst und seinem Verwaltungsspeicher (Geheimnisse versiegelt, der Hauptschlüssel getrennt davon).

Auch die alte Fähigkeit, eigene Anweisungen zu schicken, gibt es noch, denn Access braucht sie für Pass-Through-Abfragen. Aber sie ist kein stiller Normalfall mehr. Das Sicherheitsmodell nennt genau drei Wege, auf denen Text eines Aufrufers die Datenbank erreicht: ungeprüft nur mit dem eigens vergebenen Recht sql, das für vertraute Programme gedacht ist. Geprüft, indem der Dienst die Anweisung zerlegt, nur eine abschließende Liste von Formen zulässt und jedes Objekt gegen Katalog und Regeln prüft. Oder ungeprüft unter der eigenen Datenbankanmeldung des Aufrufers, wenn die Datenquelle das ausdrücklich erlaubt. Dann setzt SQL Server selbst die Grenze. Wo diese Wege Restrisiken lassen, steht es in derselben Dokumentation.

Was passiert, wenn ein Datenvermittler dem Client vertraut? Für den Anwender zunächst gar nichts. Er sieht seine Formulare. Die Gefahren liegen eine Ebene tiefer: bei Fragen, die 2020 der Client entschieden hat und die heute der Dienst entscheidet.

Wer die Anweisung schreibt, entscheidet, was gelesen und geändert wird.¹⁾ Gebundene Parameter schützen nur die Werte darin. Heute baut der Dienst das SQL für gewöhnliche Anfragen selbst. Eigene Anweisungen laufen nur auf den drei beschriebenen Wegen. Belegt ist das durch automatische Tests und eine Messung an einem laufenden Dienst, bei der alle Prüfungen geprüfter Anweisungen wie erwartet ausfielen. Die Grenze: Wer das Recht sql hat, erreicht alles, was die Anmeldung der Datenquelle erreicht. Deshalb muss diese Anmeldung knapp berechtigt sein. Das ist Aufgabe des Betreibers.

Das war die Lücke von 2020.²⁾ Heute gilt eine Regel je Datenquelle, Art des Objekts, Objekt und Methode. Ein Objekt, das ein Aufrufer nicht lesen darf, antwortet wie eines, das es nicht gibt. Er erfährt also nicht einmal, dass es existiert.

Wer 2020 den Namen einer Datenbank kannte, kam an sie heran, und wer keinen Namen nannte, landete in einer voreingestellten.³⁾ Heute gibt es nach außen nur Aliasse. Die Verbindungszeichenfolgen liegen versiegelt im Verwaltungsspeicher, und die Verwaltungsschnittstelle gibt sie nie zurück.

Ein Kennwort, das bei jeder Anfrage mitreist, ist nur so geschützt wie die Verbindung.⁴⁾ Heute verlangt der Dienst für Verwaltung, zweiten Faktor und SQL-Anmeldung eine geschützte Verbindung. Persönliche Schlüssel liegen nur als Prüfwert vor, und unverschlüsseltes HTTP lauscht nach der Installation nur am Server selbst. Gemessen wurde auch, dass Schlüssel weder im Protokoll noch im Speicher im Klartext stehen. Die Grenze: Wer HTTP über den eigenen Rechner hinaus öffnet, lässt Schlüssel unverschlüsselt reisen. Die Dokumentation sagt das ausdrücklich.

2020 kamen Meldungen der Datenbank wörtlich beim Anwender an.⁵⁾ Die Entwurfsstudie von 2025 hätte sogar den Programmablauf mitgeschickt. Heute gehen Meldungen von SQL Server ohne verborgene Namen und Werte hinaus. Dazu kommt eine Korrelationskennung, über die der Betreiber im Protokoll die ganze Geschichte findet.

Ein Ergebnis ohne Obergrenze, eine Anfrage ohne Zeitlimit, beliebig viele Anfragen je Minute – das hält, bis jemand eine große Tabelle öffnet.⁶⁾ Heute liefert der Dienst Ergebnisse in Fenstern bis zu einer Obergrenze je Datenquelle, begrenzt Anfragen je Aufrufer und Fehlversuche je Anmeldung. Die Grenze: Diese Zähler liegen im Arbeitsspeicher und beginnen nach einem Neustart von vorn.

Das ist die echte Antwort einer lokalen Installation vom 29. Oktober 2026:

GET /api/v1/cf/fachdaten/dbo/Kunden HTTP/1.1

HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
WWW-Authenticate: Negotiate
WWW-Authenticate: Basic realm="Wkl.Data.Gateway", charset="UTF-8"
X-Request-Id: 0HNPH0GANKPIA:00000001

{"error":{"code":"UNAUTHENTICATED","message":"Es wurde weder ein gueltiger Dienstschluessel noch eine Windows-Anmeldung vorgelegt.","correlationId":"0HNPH0GANKPIA:00000001"}}

Kein Datensatz, kein Hinweis, ob es die Tabelle gibt, keine Versionsangabe des Servers – aber eine Kennung, unter der die Abweisung im Protokoll steht. Den Weg von 2020 gibt es auf diesem Dienst nicht mehr.

Umgesetzt ist alles oben Genannte. Durch automatische Tests geprüft, die bei jedem Bau laufen, sind mehr als 1 100 Fälle des Dienstes. Gemessen an einem laufenden Dienst sind unter anderem Anmeldung, Rechte, Weitergabe der Person, Schreibkonflikte, Transaktionen und geprüfte Anweisungen. Nicht geprüft sind bisher der Betrieb mit Kerberos in einer Domäne, die Weiterleitung durch IIS, Dauerlast und mehrere Instanzen. Eine unabhängige Sicherheitsprüfung steht noch aus. Der Datendienst ist als Vorschau veröffentlicht und hat noch keine freigegebene Fassung.

Ein Datenvermittler beseitigt die Wartezeit des Netzes nicht. Er kann sie nur seltener anfallen lassen. Wer eine ganze Tabelle lädt, um sie danach im Client zu filtern, ist über HTTP genauso langsam wie über VPN, nur auf andere Weise.

Deshalb arbeitet der Database Gateway nach drei Regeln, die in seiner Referenz stehen:

• Filtern im Dienst, nicht im Client. Auswahl, Filter, Sortierung und Seitenbildung gehören in die Anfrage. Excel und Power BI schicken ihre Filter über Power Query an den Dienst, und die Datenbank rechnet.
• Fenster statt Gesamtmenge. Der Dienst liefert je Anfrage höchstens ein Fenster bis zu seiner Obergrenze und einen Verweis auf das nächste.
• Keine heimliche Wiederholung. Läuft eine Anfrage in eine Zeitüberschreitung, heißt das nicht, dass nichts geschrieben wurde. Der Client hat nur aufgehört zu warten. Ob wiederholt wird, entscheidet die Anwendung. Für Schreibanfragen gibt es einen Wiederholschutz, und Schreibkonflikte erkennt der Dienst über eine Zeilenversion: Hat jemand anderes den Satz geändert, schreibt er nichts.

Der wichtigste Beitrag zur Leistung ist allerdings Sichtbarkeit. Das Lastprotokoll fasst Anfragen ohne ihre Werte zu Formen zusammen. Hundert Abfragen eines Formulars, die sich nur in der Kundennummer unterscheiden, sind eine Form. Zu teuren Formen nennt es die übliche Ursache: eine verknüpfte Tabelle, die ganz geöffnet wird, ein Filter auf einer Spalte ohne Index, ein Programm, das weit in eine große Menge blättert. Was 2020 nur ein Gefühl war – „heute ist es wieder langsam“ –, wird so zu einer Liste, die man abarbeiten kann.

Wie viel schneller ein bestimmtes Formular dadurch wird, lässt sich noch nicht in Zahlen sagen; eine Last- und Dauermessung steht aus. Gemessen ist bisher, dass Ergebnisse über den Dienst mit denselben Abfragen direkt in SQL Server übereinstimmen.

Der Database Gateway besteht aus einem Dienst und vier Wegen, ihn zu nutzen:

Excel und Power BI brauchen keinen eigenen Bestandteil. Sie lesen den OData-Feed über Power Query.

Verwaltet wird der Dienst mit einer Access-Anwendung. So sieht sie im Alltag aus: links die Bereiche Betrieb und Zugang, in der Mitte Arbeitslisten wie „Ohne zweiten Faktor“ oder „Schlüssel laufen ab“, rechts die gewählte Person.

Datenquellen. Eine Datenbank wird einmal in der Verwaltungsanwendung eingetragen und erscheint nach außen nur unter ihrem Alias. Die Verbindungszeichenfolge wird mit einem Hauptschlüssel versiegelt, der getrennt vom Speicher liegt. Änderungen wirken ohne Neustart.

Personen und Rechte. Eine Regel nennt Datenquellen, Arten von Objekten, Methoden und ob sie nur liest. Regeln erhalten Personen, Windows-Gruppen, SQL-Anmeldungen und Dienstschlüssel. Auf Wunsch arbeitet die Datenbank unter der eigenen Anmeldung der Person. Dann sehen Trigger und Spaltenvorgaben, wer gehandelt hat.

Anmeldung nach Lage. Ein Windows-Konto, eine SQL-Server-Anmeldung, ein persönlicher Schlüssel je Gerät oder ein Dienstschlüssel für Programme. Die Anmelderichtlinie entscheidet nach Verfahren, Netz und Land, ob die Anmeldung reicht, ein zweiter Faktor nötig ist oder abgelehnt wird. Im Werksnetz genügt der Schlüssel, von außen kommt ein Code aus der Authenticator-App dazu.

Nachweis und Diagnose. Jede Anfrage an Daten und Verwaltung wird mit Aufrufer, Alias, Objekt, Methode, Ergebnis und Korrelationskennung protokolliert, auch eine abgewiesene. Jede Änderung der Verwaltung steht im Änderungsprotokoll. Das Anmeldeprotokoll zeigt Herkunft und auffällige Muster, das Lastprotokoll die teuren Anfragen. Protokolle enthalten keine Schlüssel, Kennwörter, Verbindungszeichenfolgen oder Werte.

Installation. Ein Installationsprogramm richtet den Windows-Dienst, das HTTPS-Zertifikat (auch über Let's Encrypt) und die Firewall ein. Der Dienst bringt seine Laufzeit mit und läuft unter Windows 10 und 11 sowie Windows Server ab 2016. Die Datenbank ist SQL Server ab 2016. Auf dem Arbeitsplatz braucht Access ab 2010 den ODBC-Treiber in der Bitbreite von Office.

Grenzen, so wie sie die Dokumentation selbst nennt: Mitgeliefert ist nur der Anschluss an SQL Server. Ein Verwaltungsspeicher gehört zu genau einer Instanz, eine Ausfallsicherheit über zwei Instanzen gibt es nicht. Fällt der Dienst aus, erreicht kein Arbeitsplatz die Daten – eine neue Abhängigkeit, die bei direktem Zugang nicht bestand. Und der ODBC-Treiber bietet nicht jede Fähigkeit des ODBC-Treibers von SQL Server.

Was ändert sich damit in einem Betrieb? Angenommen, ein Chemiestandort führt seine Prüf- und Instandhaltungsdaten in SQL Server und bearbeitet sie mit einer Access-Anwendung. Nach der Umstellung erreichen die Arbeitsplätze den Datenbankserver nicht mehr. In den Access-Dateien steht kein Datenbankkennwort. Die Planerin arbeitet im Werk mit ihrem Schlüssel und von zu Hause mit Schlüssel und Code. Der externe Prüfdienstleister bekommt für zwei Wochen einen nur lesenden Schlüssel, der von selbst endet. Der Schlüssel eines verlorenen Laptops wird gesperrt, wirksam ab der nächsten Anfrage. Und wenn die Werkleitung fragt, wer im März die Prüffristen geändert hat, gibt es eine Antwort. Formulare und Berichte der Anwendung bleiben, wie sie sind. Umgestellt werden die Verbindungen ihrer Tabellen.

Einen Webdienst, der SQL über HTTP weiterreicht, schreibt ein erfahrenes Team in wenigen Tagen. Wir haben es 2020 selbst getan. Eigenbau ist also keine schlechte Idee. Die Frage ist, was nach den ersten Tagen kommt.

Eigenbau ist sinnvoll, wenn es um eine einzige Anwendung im eigenen Netz geht, wenige Tabellen, ein Team mit Sicherheitserfahrung und Zeit für die Pflege. Ein fertiges Produkt lohnt sich, wenn mehrere Anwendungen, Excel und eigene Programme an dieselben Daten sollen, wenn Zugriffe von außen dazukommen und wenn jemand gegenüber Kunden, Prüfern oder der eigenen Leitung belegen muss, wer was darf und wer was getan hat.

Wer einen Datenvermittler kauft, kauft nicht nur eine Programmschnittstelle, sondern auch die Arbeit, die nach dem ersten Tag kommt: Prüfungen, Tests, Pflege. Der Database Gateway hat dafür einen Hersteller und einen beschriebenen Weg, Schwachstellen zu melden und behoben zu bekommen. Jede freigegebene Fassung soll fünf Jahre lang Sicherheitsupdates erhalten; der Datendienst ist allerdings noch Vorschau und hat keine freigegebene Fassung. Welche Pflichten darüber hinaus gelten – Reaktionszeiten, Betreuung, Laufzeit –, regelt ein Vertrag, nicht dieser Beitrag. Die Arbeit muss in jedem Fall jemand leisten. Offen ist nur, wer.

Im März 2020 lautete die Frage: Wie kann die Schichtplanerin morgen von zu Hause arbeiten? Die Antwort war ein Notzugang, und er hat seine Aufgabe erfüllt. Die Frage von heute ist eine andere: Wie bleibt der Zugriff auf Geschäftsdaten sicher, nachvollziehbar, schnell genug und wartbar, auch wenn die Ausnahme von damals längst Alltag ist? Der Database Gateway ist unsere Antwort darauf: Der Dienst entscheidet, was erreichbar ist, die Person kommt in der Datenbank an, und jede Anfrage hinterlässt eine Spur.

Er ist nicht für jeden die richtige Antwort. Wer eine einzige Anwendung im eigenen Netz betreibt und seinen Terminalserver im Griff hat, braucht ihn vielleicht nicht. Wer aber heute einen Zugang von 2020 betreibt, ob selbst gebaut, zugekauft oder geerbt, sollte eine Frage beantworten können: Wer kann heute nachweisen, wer über diesen Zugang was lesen konnte – und wer trägt die Verantwortung, wenn es niemand kann?

Greifen Ihre Access-Anwendungen heute direkt auf den produktiven SQL Server zu, und sollen externe Dienstleister oder Zugriffe von außen dazukommen? Dann ist der erste sinnvolle Schritt eine Durchsicht der heutigen Datenwege: Wer erreicht welche Datenbank, mit welcher Anmeldung, von wo aus? Danach lässt sich beurteilen, ob der Database Gateway passt und wie groß eine Einführung wäre. Zum Einsatz des Database Gateway verpflichtet die Durchsicht nicht.

Die nächsten Schritte:

• Lesen: die Produktseite des Database Gateway, die Seite Ausgangslage, Anwendungsfälle und Alternativen und das Sicherheitsmodell mit seinen Restrisiken.
• Ausprobieren: Vom leeren Server zur ersten Abfrage zeigt die Einrichtung Schritt für Schritt.
• Beispiel: Lieferanten brauchen Ihre Daten. Nicht Ihre Datenbank. zeigt, wie Lieferanten über eine freigegebene Sicht nur ihre eigenen Zeilen lesen.
• Besprechen: die Durchsicht Ihrer heutigen Datenwege, eine technische Vorführung oder ein Pilot mit einer Anwendung. Gespräch vereinbaren.
• Prüfen lassen: Wer einen eigenen Datenzugang behalten will, kann ihn in einem Sicherheitsaudit prüfen lassen. Wer die Anwendung selbst erneuern will, findet den Weg unter Legacy-Modernisierung.

Datendienst, Treiber und Client tragen keine Lizenz je Arbeitsplatz. Was ein Einsatz bei Ihnen umfasst – Einrichtung, Anpassung, Betreuung –, klären wir im Gespräch, nicht mit einer Preisliste.