IT-Sicherheit bei Schnittstellen: Zugänge, Schlüssel, Rechte

Wenn wir eine bestehende Anbindung im Bestand eines Betriebs ansehen, finden wir sehr oft dasselbe Muster: Es gibt genau einen Zugang für die Schnittstelle, dieser Zugang hat Verwaltungsrechte im Zielsystem, er wurde bei der Inbetriebnahme angelegt und ist seither unverändert gültig. Das Kennwort steht in einer Einstellungsdatei auf dem Server, zusätzlich in einem Skript, das jemand für einen Sonderfall geschrieben hat, und häufig noch in einer Nachricht aus der Einführungsphase, die in mehreren Postfächern liegt.

Dieses Muster entsteht nicht aus Nachlässigkeit, sondern aus dem Ablauf einer Inbetriebnahme. Bei der ersten Verbindung geht es darum, dass überhaupt Daten ankommen. Ein Zugang mit weiten Rechten spart in dieser Phase Rückfragen: Es gibt keine Fehlermeldungen wegen fehlender Berechtigungen, keine Wartezeit auf den Hersteller, keine Diskussion darüber, welches Feld gelesen werden darf. Sobald die Übertragung läuft, verschwindet die Frage aus dem Blickfeld, weil sie im Tagesgeschäft nicht mehr auffällt. Ein Zugang mit zu vielen Rechten verhält sich unauffällig — er funktioniert, und zwar genau so gut wie ein enger Zugang.

Die Folgen zeigen sich erst später und selten am Tag des Vorfalls. Wer diese Zugangsdaten in die Hände bekommt, kann in der Regel alles, was das Zielsystem hergibt: lesen, ändern, löschen, exportieren. Weil derselbe Zugang für mehrere Abläufe verwendet wird, lässt sich im Nachhinein nicht zuordnen, welcher Vorgang von welchem Programm ausgelöst wurde. Und weil das Kennwort an mehreren Stellen liegt, kann man es nicht einfach ändern: Jede Änderung legt unbekannt viele Abläufe still. Genau das ist der Punkt, an dem ein Sicherheitsthema zu einem Betriebsthema wird — ein Zugang, den man nicht entziehen kann, ohne den Betrieb anzuhalten, ist kein verwalteter Zugang.

Die Frage, wo ein Schlüssel liegt, wird häufiger falsch beantwortet als die Frage, welches Verfahren verwendet wird. Typische Fundorte in Bestandsanlagen: eine Einstellungsdatei neben dem Programm, ein Skript in der Aufgabenplanung, ein Textdokument auf einem Laufwerk, eine Nachricht im Postfach der Geschäftsführung, ein Zettel im Serverschrank. Jede dieser Ablagen für sich ist erklärbar. Zusammen ergeben sie einen Zustand, in dem niemand mehr sagen kann, wie viele Kopien existieren.

Eine geordnete Ablage muss keine große Anschaffung sein. Entscheidend sind vier Eigenschaften: Es gibt genau eine Stelle, die als gültig gilt; der Zugriff darauf ist auf benannte Personen beschränkt; es ist nachvollziehbar, wer wann etwas abgerufen hat; und es existiert ein Verfahren für den Fall, dass die zuständige Person nicht erreichbar ist. Diese vier Punkte lassen sich auch mit einfachen Mitteln erfüllen, solange sie schriftlich festgehalten sind. Wo die Anbindung von außen betreut wird, gehört die Ablage in die Vereinbarung zum laufenden IT-Betrieb und nicht in eine mündliche Absprache.

Der praktische Gewinn dieser Ordnung zeigt sich nicht im Normalbetrieb, sondern an zwei Tagen: dem Tag, an dem jemand den Betrieb verlässt, und dem Tag, an dem ein Verdacht auf einen Vorfall besteht. An beiden Tagen ist die einzige relevante Frage, welche Zugänge betroffen sind und wie schnell sie sich ändern lassen. Wer diese Frage in Minuten beantworten kann, hat den größten Teil des Themas erledigt.

Der Grundsatz ist alt und einfach: Ein Zugang bekommt genau die Rechte, die der Ablauf braucht, und keine darüber hinaus. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) beschreibt diesen Grundsatz in seinen Bausteinen zum IT-Grundschutz als eine der tragenden Regeln für den Umgang mit Berechtigungen. In der Umsetzung scheitert er selten am Verständnis, sondern daran, dass niemand aufgeschrieben hat, was der Ablauf eigentlich braucht.

Deshalb beginnt die Umsetzung nicht im Rechtesystem, sondern bei einer Liste der Vorgänge. Welche Daten holt die Verbindung ab? Welche schreibt sie zurück? Muss sie löschen können? Braucht sie Zugriff auf Stammdaten oder genügen Bewegungsdaten? Diese Liste entsteht ohnehin, wenn eine Anbindung sauber beschrieben wird, und sie ist gleichzeitig die Grundlage für die Rechtevergabe. Wo eine solche Beschreibung fehlt, ist der Weg über eine Prozessanalyse der schnellere, weil das Rätselraten sonst bei jedem Rechtefehler von vorn beginnt.

In der Umstellung hilft ein einfaches Vorgehen: Rechte werden zunächst eng gesetzt, die Verbindung läuft eine Woche im Testbetrieb, und jede Fehlermeldung wegen fehlender Berechtigung wird einzeln bewertet, statt das Recht pauschal zu erweitern. Der Aufwand ist überschaubar und fällt einmalig an. Was danach übrig bleibt, ist ein Zugang, dessen Rechteumfang begründet ist und der sich bei einer späteren Prüfung erklären lässt.

Ohne Protokoll lässt sich nach einer Störung nicht feststellen, was übertragen wurde und was nicht. Ein Protokoll ist damit kein Zusatz, sondern Bestandteil der Anbindung. Gleichzeitig ist es die Stelle, an der Zugangsdaten am häufigsten ungewollt landen — nicht durch Absicht, sondern durch Bequemlichkeit bei der Fehlersuche.

Der klassische Fall: Zur Analyse eines Anmeldeproblems wird die vollständige Anfrage mitgeschrieben, inklusive der übermittelten Zugangsdaten. Die Einstellung bleibt aktiv, weil sie nach der Behebung niemand zurücknimmt. Von da an steht der Schlüssel in jeder Protokolldatei, wird täglich mitgesichert und liegt damit in jeder Datensicherung der folgenden Monate. Ein Kennwortwechsel hilft dann nur teilweise, weil die alten Sicherungen weiter existieren. Was einmal in einem Protokoll steht, verschwindet nicht mehr aus den Sicherungen.

Ein brauchbares Protokoll enthält Zeitpunkt, Verbindung, verwendeten Zugang, betroffenen Vorgang, Ergebnis und Dauer. Es enthält keine Kennwörter, keine Schlüssel und keine vollständigen Datensätze mit personenbezogenen Inhalten. Statt des Schlüssels wird dessen Kennung geschrieben — damit bleibt nachvollziehbar, welcher Schlüssel im Einsatz war, ohne dass er selbst gespeichert wird. Wie lange Protokolle aufbewahrt werden und wer sie einsehen darf, gehört in die Prozessdokumentation und sollte nicht dem Zufall der Standardeinstellung überlassen bleiben.

Viele Anbindungen im Mittelstand werden von außen betreut, vom Hersteller eines Systems oder von einem Systemhaus. Das ist unproblematisch, solange klar ist, wer welche Zugänge besitzt. Unklar wird es, wenn die Zugangsdaten ausschließlich beim Dienstleister liegen und der Betrieb selbst keinen Zugriff darauf hat. Dann fehlt im Ernstfall die Möglichkeit, einen Zugang kurzfristig zu sperren.

Vier Punkte gehören deshalb in die Vereinbarung, und zwar schriftlich: Welche Zugänge existieren und wem gehören sie? Wo liegen die Zugangsdaten und hat der Betrieb selbst Zugriff darauf? Wer meldet einen Verdacht an wen, in welcher Zeit? Und was passiert mit Zugängen und Kopien der Daten, wenn die Zusammenarbeit endet? Der letzte Punkt wird am häufigsten vergessen und ist der, der am längsten nachwirkt.

Erhebungen von Bitkom und dem Deutschen Industrie- und Handelskammertag (DIHK) zur Lage der IT-Sicherheit zeigen regelmäßig, dass kleinere und mittlere Betriebe seltener über schriftlich geregelte Zuständigkeiten verfügen als größere Organisationen. Der Aufwand für diese Regelung ist gering — es geht um eine Seite Text, nicht um ein Projekt. Der Unterschied zeigt sich an dem einen Tag, an dem sie gebraucht wird.