Nichts geht über Sicherheit

Einmal wurde ich vom Account Verantwortlichen für einen dringenden Notfall verpflichtet. Ein vom Sicherheitsteam des Kunden gefundenes Problem custom App wurde als absolutes No-Go eingestuft. Dies hatte dann das Auftragsteam beim Kunden, den Partner und am Ende auch meinen Arbeitgeber nervös gemacht. So befand ich mich dann im Flieger (was schon ein Geschichte an sich wert ist. Freitags verpflichtet werden und dann einen Flieger buchen und genehmigt bekommen. Bürokratie in selbsternannten agilen Unternehmen ist kein Spass), um innerhalb von 5 Tagen das Problem zu lösen. Keine guten Aussichten, wenn man bedenkt das die oben erwähnten Teams schon seit Tagen, ach was, Wochen damit beschäftigt waren und es nicht gelöst bekommen hatten.

Montags gelandet und direkt in Meetings – wo ich dann sehr viel Zeit verbrachte. Das große Problem war eigentlich einfach und nur eine Frage des Verständnisses, oder: welche Checkbox muss man auswählen, um das gewünschte Ergebnis zu erhalten. Es hatte noch was mit der Rolle von Zertifikaten zu tun, was das Verständnis nicht vereinfachte. Aber: strukturiert vorgegangen und das Problem war noch am Montag gelöst.

Somit hatte ich ja noch ein paar Tage Zeit um dem Kunden bei anderen Konfigurationsfragen klärend zur Seite zu stehen. Eine dieser Fragen drehte sich um SAP Web Dispatcher, SMP3 und dem Gateway System und wie man die Kommunikation mit TLS /HTTPS absichert, dem Zertifikat der Gegenstelle vertraut und den SAP Web Dispatcher beim Zielsystem über ein Client Zertifikat authentifiziert. Kurz: es war etwas komplizierter und beinhaltet das Erstellen eines Client Zertifikates, Austausch von Zertifikaten und beim SAP Web Dispatcher das Erstellen einer PSE. Ist auch alles dokumentiert.

Aber: das Sicherheitsteam des Kunden hat so seine Anforderungen. Neben dem Üblichen wie Algorithmus, Bitlänge, Lebensdauer, welche CA ausstellen darf, etc war eine ganz wesentliche Anforderung: der Key des Client Zertifikats muss geschützt sein. Und damit war es auch notwendig die PSE über ein Passwort zu sichern. Das ist jetzt nicht schwierig. Man muss nur eine PIN / Passwort setzen. Dieses wird vom WD beim starten verwendet um auf die PSE zugreifen zu können. Natürlich verwendet man nicht ABC123 sondern etwas Besseres. Bewährt hat sich das Schema Kopf -> Tastatur und gut ist. Nicht so aber hier. Es musste ein sicheres Passwort sein, hochsicher. Allen Anforderungen des Kunden an super geheime Passwörter entsprechen. Berücksichtigt man den Einsatzzweck der Lösung, macht das alles Sinn, sehr viel Sinn sogar (es ist eine Bank).

Irgendwann kam dann der Schritt der alle weiteren Aufgaben blockt: PSE anlegen und mit einer PIN versehen. Es war Mittwochabend. Die Aufgabe wurde auf Donnerstag morgen verlegt, denn dann wäre das Sicherheitsteam anwesend. Wer jetzt denkt: da kommt einer und trägt ein Passwort ein … der irrt. Für die Sicherheit war das Passwort auf 3 Personen aufgeteilt. Jeder gibt 1/3 des Passwortes ein, und kennt nicht die anderen 2/3. Das Passwort wird natürlich auch tagesaktuell generiert.

Donnerstag morgen um 8 Uhr ging es los. Also, war der Termin angesetzt. Um 9 kam die erste Person des Sicherheitsteams. Diese konnte aber nichts tun, da ja nur 1/3 des Passwortes anwesend war. Kurz: 9 Uhr morgens: wir hatten 1/3. Wir riefen an, wir versuchten die fehlenden 2/3 zu finden. Das erste Drittel wusste auch nicht wo die Kollegen waren. Jetzt hieß es warten. Mittags, so gegen 14 Uhr kam ein weiteres 1/3 des Passwortes. 2/3 des Passwortes hilft aber nicht viel. Das letzte Drittel war nicht auffindbar. Bis abends, kurz vor 18 Uhr. Wir hatten das Passwort: es war die Zeit der Passworteingabe. Jeder der 1/3 ging an die Tastatur und kramte einen verknüllten Zettel raus und tippte ihn ab. Die PSE wurde generiert, jeder kam abwechselnd an die Tastatur, tippte etwas rum, dann der nächste. Das Zertifikat wurde generiert, eingespielt, der Web Dispatcher gestartet, alles funktionierte. Die PSE war fertig und der Web Dispatcher für DEV konfiguriert. Ich wollte noch die PSE für QA und PRD durchgehen, denn 3/3 des Passwortes waren ja anwesend. Die könnten doch bestimmt noch schnell die Passwörter für QA und PRD generieren und eintippen. Aber nein: die Sicherheitsabteilung wollte erst sehen ob alle Tests, Szenarien, etc auch funktionieren. Da wir die letzten im Büro waren: wir hatten eine Aufgabe für Freitag.

Ach ja, Freitag, mein letzter Tag. Freitags dann schnell die Tests mit den Backends durchgeführt mit dem Kundenteam durchgeführt und die Abnahme vom Kunden erhalten. Vormittags rannten wir zur Sicherheitsabteilung und baten darum die PSE für QA und PRD anlegen zu dürfen. Die erste Person kam um 14 Uhr. Die zweite um 18 Uhr und ob die letzte noch kam weiß ich nicht, denn mein Flug zurück nach Hause ging gegen 22 Uhr und ich musste zum Taxi.

Was kann man hier lernen? Manche Leute wissen wie man bei (großen) Unternehmen das Spiel zu spielen hat. Manche bekommen fürs Rumsitzen Geld. Sicherheit ist relativ. Ein Fresszettel hält mehr bei so manchem Unternehmen am Laufen als man wahrhaben will. Wer jetzt sagt: super Sicherheit. Ja nö, das Passwort, das jeder zu 1/3 hatte, war kein Wunderpasswort. Die hatten sich ein Passwort vor einigen Jahren generiert, in 3 Teile aufgeteilt und auf einen Fresszettel aufgeschrieben. Nix mit tagesaktuell. Ausgehend von den Tastaturgeräuschen war es insgesamt nicht länger als 15 Zeichen. Einfach mal wahllos mit dem Kopf über die Tastatur gehen generiert sicherere Passwörter. Wichtigste Lektion: wenn Alle glücklich sind – und die Lösung lief am Ende erfolgreich – dann sieht man über sehr vieles hinweg.