Lieferanten brauchen Ihre Daten. Nicht Ihre Datenbank.

Die Werkslogistik will, dass Lieferanten ihre Bestände selbst nachsehen können. Die IT will keinen Externen auf dem SQL Server. Meist endet das in einem Kompromiss, der niemanden zufriedenstellt: Jemand exportiert jeden Montag eine Liste. Dabei gibt es einen dritten Weg, der weder die Datenbank öffnet noch eine neue Anwendung verlangt.

Nehmen wir einen Spezialchemie-Standort mit drei Konsignationslagern. Ein Lieferant stellt Additive bereit, einer IBC-Container, einer Ersatzteile für die Instandhaltung. Die Ware gehört dem Lieferanten, bis das Werk sie entnimmt. Wann er nachliefern muss, weiß er also nur, wenn er sieht, was entnommen wurde.

Die Leiterin der Werkslogistik hat an diesem Morgen den dritten Anruf in einer Woche. Der Additiv-Lieferant fragt, ob die Entnahme vom Freitag schon in der Liste steht. Sie steht nicht drin, denn die Liste wird montags exportiert. Die Zahlen, nach denen er fragt, stehen aber längst im SQL Server des Werks, aktuell bis zur letzten Buchung.

Also schreibt sie an die IT: Können die drei Lieferanten ihre Bestände und Abrufe nicht einfach selbst sehen?

Die Antwort des IT-Leiters kommt schnell und ist freundlich, aber eindeutig. Einen Zugang für Externe auf den Produktions-SQL-Server wird es nicht geben. Kein offener Port, keine SQL-Anmeldung für fremde Firmen, keine VPN-Verbindung, die mehr erreicht als die paar Zahlen. Wenn die Lieferanten Daten brauchen, dann über ein Portal. Und dafür ist dieses Jahr weder Budget noch Personal eingeplant.

Der Lieferant ruft also weiter an. Die Liste kommt weiter montags.

Liest man den Austausch noch einmal, hat niemand einen Fehler gemacht.

Die Werkslogistik hört in ihrer eigenen Frage ein Ergebnis: Der Lieferant sieht seinen Bestand, die Anrufe hören auf, Nachlieferungen kommen rechtzeitig. Für sie geht es um ein paar Zeilen, die ohnehin existieren.

Der IT-Leiter hört dieselbe Frage anders. Er hört externe Konten auf einem System, das die Produktion trägt. Er hört Netzwerkfreigaben, die er dokumentieren, und Berechtigungen, die er pflegen muss. Und er hört die Frage, die nach jedem Vorfall gestellt wird: Wer hat wem wann welchen Zugang gegeben? Dass ein Datenbankserver nicht direkt aus dem Internet erreichbar sein soll, ist in IT-Foren keine Einzelmeinung, sondern die Standardantwort, meist mit dem Zusatz „wenn überhaupt, dann nur über VPN“.

Beide Sichten sind berechtigt. Schwierig wird es erst durch eine Annahme, die beide teilen, ohne sie auszusprechen: dass es nur zwei Möglichkeiten gibt. Entweder man öffnet das System, oder man baut eine Anwendung davor.

Bevor es um einen dritten Weg geht, lohnt sich ein ehrlicher Blick auf die vorhandenen. Jeder davon ist aus gutem Grund entstanden, und für jeden gibt es Fälle, in denen er die beste Wahl bleibt.

Der Export per E-Mail. Eine Abfrage, ein Excel-Export, eine Mail. Das ist in einer Stunde eingerichtet, braucht keine Freigabe und funktioniert mit jedem Lieferanten. Der Preis zeigt sich mit der Zeit. Jemand muss den Export anstoßen, die Zahlen sind ab dem Versand veraltet, und mit jeder Rückfrage entsteht eine weitere Fassung. Dazu kommt ein Punkt, den man leicht übersieht: Die Datei verlässt das Haus mit allem, was in der Abfrage stand. Gerät beim Kopieren der Einkaufspreis mit hinein, liegt er beim Lieferanten.

VPN und eine SQL-Anmeldung. Der Lieferant bekommt einen VPN-Zugang und ein Konto mit Leserechten auf ausgewählte Sichten. Das nutzt vorhandene Technik, und der Lieferant kann mit Excel direkt auf die Daten zugreifen. In vielen Häusern ist das der erste Gedanke, und für einen einzelnen, eng vertrauten Partner kann es reichen. Allerdings öffnet ein VPN ein Netz und nicht nur eine Tabelle. Jede fremde Firma braucht eine Anmeldung auf dem SQL Server, die Rechte stehen verteilt in der Datenbank, und Zugangsdaten wandern in Verbindungsdateien. Das ist genau das Bild, das der IT-Leiter vor Augen hat.

EDI. Lieferabrufe, Lieferavise und Rechnungen als genormte Nachrichten, etwa nach VDA oder EDIFACT, sind in vielen Branchen gesetzt. EDI ist stark, wo Geschäftsdokumente zuverlässig von System zu System laufen müssen. Für die Frage „Wie viel liegt gerade noch im Konsignationslager?“ ist es nicht gebaut: EDI überträgt Dokumente, es beantwortet keine Abfragen. Kleinere Lieferanten nennen zudem seit Jahren Komplexität und fehlendes Know-how als Grund, warum sie nicht angebunden sind.

Das Lieferantenportal. Ein Portal kann mehr als anzeigen. Lieferanten bestätigen darin Abrufe, laden Zeugnisse hoch, klären Reklamationen, und der Ablauf ist geführt. Gerade beim Konsignationslager ist das ein ernsthaftes Argument: Abgleiche per Telefon und E-Mail scheitern oft daran, dass beide Seiten unterschiedliche Zahlen haben. Wer viele Lieferanten und viele solcher Abläufe hat, fährt mit einem Portal gut. Ein Portal ist aber auch ein Produkt mit Benutzerverwaltung, Betrieb, Updates und Schulung, und Lieferanten müssen sich bei jedem Kunden in ein weiteres Portal einarbeiten.

Eine eigene Schnittstelle. Eine REST-API, genau auf die Fragen der Lieferanten zugeschnitten, mit der Geschäftslogik des Hauses. Das ist präzise. Jede neue Frage bedeutet aber neue Entwicklung, jede Schemaänderung eine Anpassung, und Excel kann eine solche API über Power Query zwar abrufen, die Antwort aber meist erst nach eigener Aufbereitung als Tabelle nutzen. OData bringt Struktur, Metadaten und Filter dagegen standardisiert mit. Wer selbst bauen will, muss auch nicht bei null anfangen. Microsofts quelloffener Data API builder stellt Tabellen und Sichten als REST und GraphQL bereit und filtert Zeilen über den Sitzungskontext. Den Dienst betreibt, absichert und pflegt man dann allerdings selbst.

Für viele Aufgaben ist einer dieser Wege genau richtig. Unverhältnismäßig wird es dort, wo die Aufgabe eigentlich klein ist. Ein Lieferant will den aktuellen Stand seiner eigenen Zeilen lesen, mehr nicht.

Die Daten liegen im SQL Server. Der Lieferant hat Excel. Warum steht zwischen beidem trotzdem ein Projekt?

Weil die Frage der Werkslogistik in Wahrheit nicht „Zugang zur Datenbank“ lautet. Sie lautet „ein festgelegter Ausschnitt, je Lieferant, aktuell“. Dafür braucht es kein Konto auf dem SQL Server und keine Bedienoberfläche, sondern drei Entscheidungen an der richtigen Stelle:

1. Wer fragt? Jede Person beim Lieferanten meldet sich mit einem eigenen Schlüssel an, der befristet ist und einzeln gesperrt werden kann.
2. Was darf sie abfragen? Genau eine freigegebene Sicht, nur lesend. Alles andere gibt es für sie nicht.
3. Welche Zeilen liefert die Datenbank? Die Sicht filtert nach der Person, die die Anfrage gestellt hat. Den Filter setzt also die Datenbank, nicht Excel und auch nicht der Lieferant.

Die ersten beiden Entscheidungen trifft ein Dienst, der zwischen Lieferant und Datenbank steht. Nur er erreicht den SQL Server, und er nimmt Anfragen über HTTPS entgegen. Die dritte Entscheidung trifft der SQL Server selbst. Was der Lieferant zu sehen bekommt, ist eine Datenquelle, die Excel, Power BI und Access als Standard kennen: einen OData-Feed. Damit wird aus einer einzelnen Lieferantenanbindung etwas Größeres: eine Infrastruktur, in der Datenzugriff, Fachanwendung und Schutz der Verbindung nicht mehr untrennbar zusammenhängen.

Diesen Aufbau setzt der Database Gateway um, unser Dienst für kontrollierten Datenzugang. Wie das konkret aussieht, zeigt am besten ein durchgespieltes Beispiel.

Zurück zum Werk. Die drei Lieferanten heißen hier schlicht A, B und C.

In der Datenbank gibt es bereits eine Tabelle mit den Konsignationsbeständen aller drei Lieferanten, mit Artikel, Menge, Entnahmen und einer Spalte, die intern bleibt: dem Einkaufspreis. Neu kommen zwei Dinge hinzu. Erstens eine kleine Zuordnungstabelle, welche Person zu welchem Lieferanten gehört, gepflegt von der Fachanwendung oder von Hand. Zweitens eine Sicht, die nur die freigegebenen Spalten enthält und nur die Zeilen des Lieferanten, zu dem die anfragende Person gehört:

CREATE VIEW lief.LieferantBestand AS
SELECT b.Lieferant, b.Artikel, b.Menge, b.Entnahme_am
FROM lief.Bestand AS b
WHERE EXISTS (SELECT 1 FROM lief.PersonLieferant AS pl
              WHERE pl.Lieferant = b.Lieferant
                AND pl.Person = CAST(SESSION_CONTEXT(N'wkl.person') AS nvarchar(256)));

Der Einkaufspreis steht nicht in der Sicht. Für die Lieferanten gibt es ihn damit nicht.

Im Dienst legt die IT eine Regel an: nur diese eine Sicht, nur lesen. Jede Person beim Lieferanten bekommt einen persönlichen Schlüssel für genau diese Datenquelle, auf Wunsch befristet bis zum Vertragsende. Bei jeder Anfrage mit einem solchen Schlüssel schreibt der Dienst den Namen der Person schreibgeschützt in den Sitzungskontext der Datenbankverbindung (SESSION_CONTEXT). Die Sicht oben liest ihn dort aus.

Beim Lieferanten öffnet die Disponentin von Lieferant A Excel und wählt Daten > Daten abrufen > Aus anderen Quellen > Aus OData-Datenfeed. Sie gibt die Adresse ein, die ihr das Werk mitgeteilt hat, und meldet sich mit ihrem Schlüssel an. Im Navigator erscheint eine einzige Tabelle. Darin stehen die Zeilen von Lieferant A. Filtert sie nach einem Artikel, schickt Excel den Filter an den Dienst, und die Datenbank filtert. „Aktualisieren“ holt den Stand der letzten Buchung.

Das Werk kann noch einen Schritt weiter gehen und eine Excel-Vorlage vorbereiten: Abfrage, Spalten und vielleicht ein Diagramm für die Reichweite. Die Mappe enthält die Adresse, aber keinen Schlüssel. Bei jedem Lieferanten meldet sich die Person, die sie öffnet und aktualisiert, mit ihrem eigenen Schlüssel an und sieht ihre eigenen Zeilen. Es bleibt eine Vorlage für alle Lieferanten.

Ist der Dienst eingerichtet, ist eine solche Grundvorlage in wenigen Minuten gebaut. Die Einrichtung selbst, also Dienst, Zertifikat, Datenquelle und Regeln, ist eine Aufgabe für die IT. Die Anleitung für Excel beschreibt die Schritte, „So beschränken Sie Vermittler auf ihre Kunden“ dasselbe Muster am Beispiel von Versicherungsvermittlern.

Kommt ein vierter Lieferant mit denselben Daten hinzu, sind es neue Zeilen in der Zuordnungstabelle, neue Personen und neue Schlüssel. Ein neues Projekt ist es nicht. Braucht ein Lieferant andere Felder, eigene Abläufe oder strengere Sicherheitsauflagen, kommt eine eigene Sicht hinzu oder mehr.

Ein Ablauf auf dem Papier ist noch kein Beleg. Deshalb haben wir genau diesen Aufbau am 5. November 2026 mit der aktuellen Auslieferung des Dienstes auf einer eigenen Testinstanz nachgestellt, mit Testtabellen, die danach wieder entfernt wurden.

Der Aufbau: eine Bestandstabelle mit drei Lieferanten und einer internen Preisspalte, je zwei Personen für zwei der Lieferanten, niemand für den dritten, dazu eine Person, die zwar die Regel hat, aber keinem Lieferanten zugeordnet ist. Eine Sicht ohne Preisspalte, eine Regel nur auf diese Sicht, ein persönlicher Schlüssel je Person. Alle 20 Prüfungen ergaben das erwartete Ergebnis:

1. Jede zugeordnete Person las nur die Zeilen ihres eigenen Lieferanten. Die Person ohne Zuordnung bekam null Zeilen.
2. Die Basistabellen und eine fremde Tabelle beantwortete der Dienst mit „nicht gefunden“, ebenso einen einzelnen Satz eines anderen Lieferanten, den jemand gezielt über dessen Nummer anforderte. Ein Filter auf einen fremden Lieferanten lieferte null Zeilen.
3. Ändern und Anlegen wurden abgelehnt, ebenso eine selbst geschriebene SQL-Abfrage auf die Bestandstabelle.
4. Vier Personen schickten zusammen 400 Anfragen, bis zu 16 gleichzeitig. Keine einzige Antwort enthielt eine fremde Zeile. Danach fragte ein Dienstschlüssel ohne Person 50-mal dieselbe Sicht ab und bekam jedes Mal null Zeilen. Der Sitzungskontext blieb also nicht an einer wiederverwendeten Verbindung hängen.
5. Über den ODBC-Treiber, in der 64- und in der 32-Bit-Fassung, sahen die Personen ebenfalls nur ihre eigenen Zeilen.
6. Das Zugriffsprotokoll hielt 410 Einträge fest, jeder mit Person, Schlüssel, der Regel, die den Zugriff erlaubt hat, dem angefragten Ziel und dem Ergebnis.

Genauso klar ist, was dieser Test nicht ist. Er ist unser eigener Nachweis eines bestimmten Szenarios, keine unabhängige Sicherheitsprüfung und kein Zertifikat. Die 400 Anfragen prüfen, dass bei Gleichzeitigkeit nichts durcheinandergerät. Ein Leistungsmesswert sind sie nicht. Und geprüft wurde Lesen. Dass Lieferanten nicht schreiben konnten, war Absicht.

Hier lohnt es sich, genau zu sein, denn an dieser Stelle verschwimmen in Gesprächen gern drei verschiedene Dinge.

Excel und Power BI lesen. Sie laden über Power Query und aktualisieren. Was jemand in eine Excel-Zelle tippt, wandert nicht zurück in die Datenbank.

Access kann schreiben. Über unseren OData-ODBC-Treiber verknüpft Access Tabellen und Sichten des Dienstes und ändert Daten in Datenblättern und Formularen, wenn die Regel es erlaubt. Das ist gemessen, einschließlich des Falls, dass zwei Personen denselben Satz ändern. Access meldet dann seinen gewohnten Schreibkonflikt, statt still zu überschreiben (Schreiben und Schreibkonflikte).

Ein Bestätigungsprozess ist mehr als ein Schreibrecht. Soll ein Lieferant einen Liefertermin bestätigen, braucht es ein Ziel, das genau dafür gebaut ist. Das kann eine eigene Tabelle oder eine gespeicherte Prozedur sein, deren Prüfungen in der Datenbank sicherstellen, dass ein Lieferant nur seine eigenen Abrufe bestätigt und nur gültige Werte einträgt. Freigaben und Rückfragen kommen hinzu. Das ist eine Entwurfsaufgabe mit eigenem Test. Unser Nachweis oben deckt sie nicht ab, und der Dienst ersetzt keine Geschäftslogik. Wo die Bestätigung ein rechtlich verbindliches Geschäftsdokument ist, bleibt EDI der richtige Weg.

Beim Ersatzteillieferanten des Werks ändert sich dadurch weniger, als man erwarten würde. Seine Disponentin arbeitet weiter in ihrer Excel-Mappe. Neu ist nur eine Abfrage, die beim Aktualisieren den Stand der letzten Buchung im Werk holt. Sein Servicetechniker behält den Power-BI-Bericht über die Teile, die bei Kunden liegen, und das Werk wird darin zu einer Datenquelle mehr. Die kleine Auftragsverwaltung in Access, die seit Jahren läuft, verknüpft die freigegebene Sicht über den ODBC-Treiber wie eine eigene Tabelle. Schreiben kann sie nur dorthin, wo eine Regel des Werks es erlaubt.

Niemand beim Lieferanten lernt eine neue Anwendung, und niemand pflegt ein Konto in einem fremden System. Was der Lieferant sehen und ändern darf, entscheidet weiter das Werk, an einer einzigen Stelle. So bleiben auf beiden Seiten die Anwendungen nutzbar, in die über Jahre Arbeit geflossen ist. Wie man eine solche Access-Anwendung weiter pflegt und neue Fassungen zuverlässig verteilt, zeigt Frontend verteilen ohne Adminrechte.

Wer so einen Weg vorschlägt, bekommt im Haus die richtigen Fragen gestellt. Hier sind die wichtigsten, mit den Antworten, die wir aus der Dokumentation und den Messungen geben können.

„Ist das nicht doch ein Loch in der Firewall?“ Erreichbar ist ein Dienst über HTTPS, nicht der Datenbankserver. Der Dienst kennt die Verbindung zur Datenbank, die Lieferanten nicht. Er baut jede SQL-Anweisung selbst aus Namen, die er im Katalog der Datenbank nachschlägt, und bindet jeden Wert als Parameter. Dafür ist er eine neue Abhängigkeit: Fällt er aus, erreicht niemand mehr die Daten. Der Betrieb braucht ein Zertifikat, dem die Clients vertrauen, einen getrennt verwahrten Hauptschlüssel, Sicherung und einen Notzugang (Sicherheitsmodell und Vertrauensgrenzen).

„Wer bürgt dafür, dass die Person die ist, für die sie sich ausgibt?“ Ihr Schlüssel, den die IT ausstellt, befristet und einzeln sperrt. Eine Sperre wirkt mit der nächsten Anfrage. Einen zweiten Faktor kann Excel beim Aktualisieren nicht abfragen. Für Excel und Power BI gibt es deshalb Schlüssel, die nur lesen dürfen und nur diese eine Datenquelle erreichen. Dazu kommen zwei Grundregeln, die man kennen muss. Die Anmeldung, unter der der Dienst die Sicht abfragt, darf niemand sonst direkt benutzen. Wer sie hätte, könnte den Sitzungskontext selbst setzen. Und das Recht, eigene SQL-Anweisungen zu senden, bekommen Lieferanten nie, denn damit erreichten sie die Tabellen hinter der Sicht.

„Und wenn eine Person umbenannt wird?“ Im Beispiel läuft die Verbindung zwischen Person und Lieferant über den Namen, also muss die Zuordnung nach einer Umbenennung mitgehen. Der Dienst schreibt zusätzlich die Nummer der Person in den Sitzungskontext (wkl.person_id), und die bleibt bei einer Umbenennung gleich. Wer neu beginnt, ordnet besser über sie zu. Unsere Prüfung oben lief über den Namen (Rechte und Reichweite).

„Was beweist das Protokoll?“ Es zeigt für jede Anfrage, auch für abgelehnte, wer wann mit welchem Schlüssel worauf zugegriffen hat, welche Regel das erlaubt hat und wie es ausging (Eine Zugriffsentscheidung nachvollziehen). Eine Lieferkettenbewertung, wie sie die NIS2-Richtlinie verlangt, erleichtert das, sie ersetzt sie aber nicht. Einen eingebauten Schutz gegen nachträgliche Änderung hat das Protokoll nicht. Aufbewahrung und Auswertung bleiben Aufgabe des Betriebs.

„Was passiert mit den Daten, wenn sie erst einmal in Excel sind?“ Sie liegen beim Lieferanten. Das Speichern, Weitergeben oder Ausdrucken kontrolliert der Dienst nicht. Deshalb gehört in die Sicht nur, was der Lieferant für seine Arbeit braucht, und in den Vertrag, wie er damit umgeht.

„Und wenn die Verbindung in zehn Jahren noch vertraulich sein muss?“ Dann geht es um die Kryptographie der Verbindung, nicht um die Sicht. Dazu weiter unten mehr.

Ob sich der Weg lohnt, entscheidet ein Vergleich mit drei Posten. Der erste ist, was der heutige Zustand kostet: Exporte, Rückfragen am Telefon und Nachlieferungen, die zu spät kommen, weil die Liste veraltet war. Diese Kosten verteilen sich auf Werkslogistik, Einkauf und IT, lassen sich aber zählen. Der zweite ist, was die Änderung kostet: Sichten, Regeln, Personen und Schlüssel, dazu der Betrieb des Dienstes. Beim Lieferanten wird für Excel und Power BI nichts installiert, für Access der ODBC-Treiber. Der dritte ist, was eine falsche Änderung kostet: ein Portal für eine reine Leseaufgabe, eine Schnittstelle, die mit jeder neuen Frage wächst, oder eine Sicht dort, wo eigentlich ein geführter Ablauf gebraucht wird.

Spannend wird die Rechnung erst beim zwanzigsten Lieferanten. Ob der teuer wird, hängt an einer Frage, die selten gestellt wird: Lesen alle dasselbe? Wenn ja, ist die freigegebene Sicht mehr als eine Abfrage. Sie ist ein Datenvertrag: feste Spalten mit festgelegter Bedeutung, auf die sich jeder Lieferant verlassen kann und die das Werk nur einmal entwirft, prüft und pflegt.

Wie stark das wirkt, zeigt eine Illustration für zwanzig Lieferanten über drei Jahre. Die Zahlen sind Annahmen für eine reine Leseaufgabe, gerechnet in Personentagen. Es sind keine Messwerte und keine Werte aus Kundenprojekten. Setzen Sie Ihre eigenen ein, die Form der Rechnung bleibt.

Ohne gemeinsamen Datenvertrag braucht jeder Lieferant eine eigene Sicht, im Modell 3 Personentage mehr je Lieferant.

Bei zwanzig Lieferanten ergibt das 280 Personentage für Einzelschnittstellen, 155 für das Portal, 119 für eine Zugriffsschicht mit eigener Sicht je Lieferant und 59 mit gemeinsamem Datenvertrag. Wichtiger als die Summen ist die Form der Linien. Einzelschnittstellen haben keinen festen Anteil und sind deshalb bei ein, zwei Lieferanten am günstigsten, in diesem Beispiel bis etwa drei. Danach kostet jeder weitere Lieferant so viel wie der erste. Ein Portal hat einen hohen festen Anteil, leistet aber auch mehr als Lesen. Und der Abstand zwischen den beiden blauen Linien ist der Wert des Datenvertrags: Er wächst mit jedem Lieferanten, der dasselbe liest. Lizenzkosten, der Aufwand bei den Lieferanten sowie Abstimmung und Schulung stehen in keiner der Linien. Lizenziert wird der Database Gateway nicht pro Arbeitsplatz, ein Angebot erstellt DATEC pro.

Ein Datenvertrag muss sich auch ändern dürfen. Dann kommt eine zweite Fassung neben die erste, etwa LieferantBestand_v2, und die alte bleibt, bis alle umgestellt haben. So bricht keine Excel-Vorlage über Nacht.

Ein Gedanke gehört noch in diese Rechnung. Eine frei werdende IT-Stelle zu besetzen dauerte in Deutschland 2025 im Schnitt 7,7 Monate, so eine Bitkom-Umfrage unter 855 Unternehmen. Wenn dieselben Leute, die den SQL Server betreuen, auch das Portal bauen und betreiben sollen, ist das weniger eine Kostenfrage als eine Frage der Reihenfolge.

Einen Datendienst vor die Datenbank zu stellen, ist keine Idee, die wir erfunden haben. Fünf verbreitete Produkte tun Ähnliches, jedes mit eigenem Schwerpunkt. Die Angaben stammen aus der Dokumentation der Hersteller, Stand 5. November 2026.

Der Database Gateway setzt einen engeren Schwerpunkt, und seine Stärke ist eine Kombination, die oben belegt ist: Die Datenbank selbst trennt die Zeilen je Person. Excel und Power BI lesen über Standard-OData, ohne dass beim Lieferanten etwas installiert wird. Access schreibt über den ODBC-Treiber, wo eine Regel es erlaubt, und meldet Schreibkonflikte, statt still zu überschreiben. Schlüssel, Regeln und Protokoll aller Lieferanten werden an einer Stelle verwaltet.

Der Unterschied liegt also nicht darin, dass andere Produkte keine Datenbanken veröffentlichen könnten. Entscheidend ist, wie viel bestehende Infrastruktur, Fachlogik und Anwendungssoftware sich für den Zugang ändern muss. Im Muster oben bekommt die Datenbank eine Sicht und eine Zuordnungstabelle, Fachanwendung und Office-Werkzeuge der Lieferanten bleiben, wie sie sind.

Im Beispielwerk liegen die Bestände im SQL Server der Lagerverwaltung. In den meisten Häusern ist das nur ein Teil des Bildes. Die Instandhaltung plant in einer Fachanwendung auf PostgreSQL, ein Messsystem schreibt in MySQL, und die Auftragshistorie der letzten zwanzig Jahre steckt in einem älteren System auf Oracle. Ein Ersatzteillieferant bräuchte aus mehreren davon etwas.

Baute man für jede dieser Datenbanken einen eigenen Zugang für Lieferanten, hätte man das Problem vom Anfang nur vervielfacht: vier Arten von Konten, vier Orte für Rechte, vier Protokolle. Ein kontrollierter Datenzugang trennt deshalb zwei Dinge. Wer fragt, was er darf und was festgehalten wird, entscheidet eine Stelle, für alle Datenquellen gleich. Wie eine bestimmte Datenbank angesprochen wird, übernimmt je System ein eigener Baustein, im Database Gateway Provider genannt. Welche Datenbanksysteme sich anbinden lassen, steht in den Voraussetzungen.

Für den Lieferanten hieße das: ein Schlüssel, eine Stelle, die ihn kennt, und je Datenquelle ein Feed, den Excel oder Power BI nebeneinanderlegen kann.

Davon profitieren nicht nur Lieferanten. Auch die eigenen Entwickler können neue Fachanwendungen gegen freigegebene Sichten und Tabellen bauen, über OData oder den ODBC-Treiber, statt in jeder Anwendung erneut Datenbankverbindungen, Zugangsdaten und Berechtigungen zu verwalten.

Eine Datenintegration ersetzt das nicht, und wer es plant, sollte das wissen. Der Dienst verknüpft keine Tabellen über Datenbankgrenzen hinweg. Zusammengeführt wird beim Lieferanten, etwa in Power Query, oder vorher in einer der Datenbanken. Auch die Zeilenfreigabe bleibt Sache des jeweiligen Systems: Die Sicht im Beispiel liest die anfragende Person aus SESSION_CONTEXT von SQL Server, und dort haben wir das Muster auch geprüft.

Irgendwann stellt die Informationssicherheit eine Frage, die über diesen Anwendungsfall hinausgeht. Bis Ende 2026 soll das Haus eine erste Inventur seiner Kryptographie haben, so empfehlen es die EU-Roadmap und die nationale Leitlinie zur Post-Quanten-Kryptografie. Jede Verbindung nach außen landet auf dieser Liste, auch die zu den Lieferanten. Und für fast jede gilt: Die Verfahren, die sie heute schützen, werden in ihrer Lebenszeit mindestens einmal gewechselt werden müssen.

Zuerst eine nüchterne Einordnung. Bestandszahlen interessieren in drei Monaten niemanden mehr. Für sie ist das Risiko gering, dass jemand den Verkehr heute aufzeichnet und später mit einem Quantencomputer entschlüsselt. Für Einkaufspreise, Rezepturen oder Vertragsdaten, die in zehn Jahren noch vertraulich sein sollen, sieht das anders aus. Die Frage hängt also an den Daten, nicht an der Technik. Wie man die Schutzdauer eigener Lieferantendaten bestimmt, beschreibt Heute abgefangen, morgen entschlüsselt.

Wie aufwendig ein solcher Wechsel wird, entscheidet sich lange vorher, nämlich daran, wo welche Verantwortung liegt. Es sind drei:

• Die Fachanwendung, also Lagerverwaltung, ERP oder Instandhaltung, verantwortet die Daten und die Geschäftslogik. Von Lieferanten muss sie nichts wissen.
• Der Datenzugang verantwortet, wer welche Sicht lesen oder schreiben darf, und hält jede Anfrage fest. Das ist die Aufgabe des Database Gateway.
• Das kryptographische Vertrauen verantwortet, welche Firma mit welcher spricht, auf welcher Grundlage und mit welchen Verfahren. Das ist die Aufgabe von TrustBridge.

Der Nutzen der Trennung zeigt sich, wenn sich etwas ändert. Ändert sich die Empfehlung für ein Verfahren, kann eine getrennte Architektur die Änderung auf die Kommunikations- und Vertrauensebene begrenzen, statt sie durch sämtliche Fachanwendungen tragen zu müssen. Sichten, Regeln und Excel-Vorlagen bleiben dann in der Regel unberührt. Wie weit das trägt, hängt an der einzelnen Integration: Was eine Anwendung selbst verschlüsselt oder signiert, muss mitwandern. Kommt ein Lieferant hinzu, sind das eine Regel und eine Beziehung, keine Änderung an der Kryptographie. Kommt eine Datenbank hinzu, brauchen die Lieferanten keine neuen Schlüssel und Verbindungen, für Excel, Power BI und Access ändert sich im Normalfall nur eine Adresse. Diese Fähigkeit, Verfahren geplant und ohne Bruch zu wechseln, heißt Kryptoagilität. Sie entsteht nicht durch ein Produkt, sondern dadurch, dass niemand Verfahren in Fachanwendungen, VPN-Konten oder Datenbankanmeldungen bei jedem einzelnen Lieferanten festschreibt. Was das von Dienstleistern verlangt, beschreibt der Beitrag Kryptoagilität: Können Ihre Dienstleister Algorithmen austauschen, ohne Geschäftsprozesse umzubauen?

Für die Vertrauensebene ist TrustBridge angelegt, als Ergänzung, nicht als Voraussetzung. Der Datenzugang funktioniert über gewöhnliches HTTPS. TrustBridge setzt dort an, wo zwei Firmen ihr Vertrauen ausdrücklich vereinbaren wollen: Jede behält ihre eigenen Zertifikate, und beide vereinbaren eine begrenzte Beziehung, die jede Seite widerrufen kann. Technisch vorgesehen sind dafür TLS 1.3 mit hybrider Schlüsseleinigung, also klassisch plus ML-KEM nach FIPS 203, ein zusätzliches, unabhängig erzeugtes Post-Quanten-Geheimnis und Zertifikate mit einer zusätzlichen ML-DSA-Signatur nach FIPS 204. Verfahren und Parameter folgen der BSI TR-02102-1. Ein hybrides Verfahren schützt allerdings nur, wo beide Seiten es verlangen. Wie das mit dem Database Gateway zusammenspielt, beschreibt die Dokumentation zur Anbindung.

Wann solche Wechsel anstehen, regeln Empfehlungen, Pflichten und Verträge, und die geraten leicht durcheinander:

• Empfehlungen. Die EU-Roadmap empfiehlt, Anwendungen mit hohem Risiko bis Ende 2030 umzustellen und solche mit mittlerem bis Ende 2035. Die BSI TR-02102-1 in der Fassung 2026-01 empfiehlt klassische Schlüsseleinigung allein nur noch bis Ende 2031, ab 2032 also nur noch hybrid. Klassische Signaturen allein sollen voraussichtlich bis Ende 2035 empfohlen bleiben. Ein Gesetz, das Unternehmen allgemein einen Post-Quanten-Termin setzt, haben wir nicht gefunden.
• Pflichten. Für Einrichtungen unter NIS2 verlangt § 30 BSIG Maßnahmen nach dem Stand der Technik, ausdrücklich auch Konzepte für den Einsatz von Kryptographie. Einen Termin für Post-Quanten-Verfahren nennt das Gesetz nicht. Verbindlich mit Termin ist die Umstellung bis Ende 2030 für zugelassene Produkte für Verschlusssachen.
• Verträge. Im Alltag kommt der Termin meist über Verträge und Fragebögen. Die nationale Leitlinie empfiehlt ausdrücklich, Anforderungen an Kryptographie in Lieferkette und Einkauf zu tragen.

Jeden Termin mit Quelle und Status führt unsere Referenzseite zur BSI TR-02102.

Einiges lässt sich schon jetzt tun, ohne auf einen Termin zu warten. Nehmen Sie die Verbindungen zu Lieferanten in die Kryptoinventur auf, mit der Frage, wer sie steuert. Ordnen Sie die Daten danach, wie lange sie vertraulich bleiben müssen. Und halten Sie die Zugriffsregeln an einer Stelle, an der man sie unabhängig vom Transport ändern kann.

Welcher Weg für welche Aufgabe passt, lässt sich mit drei Fragen grob sortieren:

Es passt, wenn

• Lieferanten im Kern einen aktuellen Stand lesen sollen, etwa Bestände, Abrufe, Termine oder Status,
• viele von ihnen dieselbe Art Daten brauchen,
• sie mit Excel, Power BI oder Access arbeiten oder ohnehin ein Programm haben, das OData lesen kann,
• und Ihre IT bereit ist, Sichten zu definieren und einen Dienst zu betreiben.

Es passt nicht oder nicht allein, wenn

• verbindliche Geschäftsdokumente ausgetauscht werden müssen. Dafür bleibt EDI da.
• Lieferanten durch mehrstufige Abläufe mit Freigaben, Dokumenten und Rückfragen geführt werden sollen. Das ist die Stärke eines Portals.
• die Daten gar nicht in einer Datenbank liegen, sondern etwa nur in Dateien oder Cloud-Anwendungen. Dafür passt eher eines der Produkte oben.
• Daten das Haus gar nicht verlassen dürfen, auch nicht als Kopie beim Lieferanten.

Auch dann kann der Dienst ein Baustein sein, zum Beispiel für den lesenden Teil neben EDI. Er ist aber nicht die ganze Antwort.

Zurück zum Dienstagmorgen. Der Additiv-Lieferant ruft nicht mehr an, um nach der Entnahme vom Freitag zu fragen. Seine Disponentin aktualisiert ihre Tabelle. Die Liste vom Montag braucht niemand mehr, und der IT-Leiter verwaltet keinen fremden Benutzer auf seinem Produktionsserver. Die Leiterin der Werkslogistik und der IT-Leiter mussten sich nicht über ein Portal streiten, bei dem einer verloren hätte. Beide haben bekommen, worauf es ihnen ankam.

Auf längere Sicht zählt noch etwas anderes: Jede Anfrage hat einen Namen, jede Freigabe lässt sich mit der nächsten Anfrage zurücknehmen, und wenn die Informationssicherheit nach 2030 fragt, liegt die Antwort an einer eigenen Stelle, nicht verstreut über zwanzig Lieferantenzugänge.

Wenn Ihre Lieferanten heute nach Daten fragen, die längst in Ihren Datenbanken liegen, muss daraus kein neues Softwareprojekt werden. Sprechen Sie mit Sönke Dobat von DATEC pro in Hamburg, zuständig für Projektberatung, Vertrieb und IT-Support zum Database Gateway. Bringen Sie eine Lieferantenfrage mit, die heute per Export beantwortet wird. Gemeinsam klären Sie, ob eine freigegebene Sicht genügt oder ob Portal, EDI oder eine eigene Schnittstelle besser passen. Bei Sicherheits- und Regulierungsfragen zieht er auf Wunsch Prof. Dr. Linus Schleupner hinzu, der bei DATEC pro das von der Europäischen Union und dem Land Nordrhein-Westfalen geförderte Vorhaben zur Post-Quanten-Verschlüsselung in automatisierten Systemen leitet.

• E-Mail: sd@datecpro.de
• Telefon: +49 40 77127-123
• DATEC pro GmbH, Nartenstraße 19, 21079 Hamburg

Wer sich vorher selbst ein Bild machen will: Ausgangslage, Anwendungsfälle und Alternativen und die Voraussetzungen in der Dokumentation. Wie der Dienst entstanden ist, erzählt Homeoffice 2020: Die Anwendung lief. War die Architektur darauf vorbereitet?