Cloud-Migration: Wie man Berechtigungen in der Cloud besser nicht macht
Ende letzten Jahres haben wir euch aufgerufen , uns eure Worst Practices zu schicken - und viele von euch haben uns geschrieben. Danke dafür! Wir werden nach und nach einige eurer Geschichten veröffentlichen. Eine Liste der veröffentlichten Geschichten findet ihr am Ende des Textes. Wir nehmen auch gern weitere entgegen, schreibt uns dafür unter dem Betreff "Worst Practices" an schreiben@golem.de. Nähere Infos gibt es im oben verlinkten Aufruf.
Als IT-Berater mit Fokus auf AWS bin ich oft mit Cloud-Migrationen beschäftigt. Ein wichtiges Thema sind immer die Berechtigungsvergaben. Es kann ziemlich aufwendig werden, diese Berechtigungen im neuen Umfeld neu zu vergeben. Meiner Erfahrung nach lohnt es sich, das zu automatisieren - auch wenn der Aufwand erstmal groß ist.
"Meiner Erfahrung nach" sage ich deswegen, weil ein Kunde unserer IT-Beratungsfirma es schlauer und billiger fand, das manuell zu machen. Ich war mehrere Jahre für den Kunden tätig und schon nach kurzer Zeit Hauptansprechpartner für alles rund um Amazon Web Services - vor allem aber für eine Sache: die Berechtigungsvergabe.
Ich, als Externer, wurde also mit einem beachtlichen Tagessatz für einen internen Betriebsprozess herangezogen. Einen Prozess, der hauptsächlich darin besteht, Anfragen aufzunehmen, sie zu prüfen, gegebenenfalls noch mal nachzufragen, Freigaben per Mail einzuholen und das Ganze dann in ein Ticket zu schreiben.
In den besagten zwei Jahren wurden so rund 2.000 Tickets in dem dafür vorgesehenen Projekt zur Vergabe von Usern und Berechtigungen angelegt. Natürlich ist das Anlegen selbst kein großer Aufwand und dauert vielleicht fünf Minuten. Manche Anfragen sind qualitativ aber so schlecht formuliert und manchen Abteilungsleitern läuft man so lange wegen einer Freigabe hinterher, dass auch mal eine Stunde Arbeitszeit für ein Ticket draufgeht.
Es sollte nur eine Übergangslösung sein
Wie es so weit kommen konnte? Zunächst einmal hatte der Kunde wegen des Umzugs lange kein eigenes IT-Service-Management-Tool (ITSM), über das ein solcher Prozess abgebildet werden kann. Das hätte man teil- oder vollautomatisiert machen können, mit Pflichtfeldern und automatischen E-Mails - allgemein mit Funktionen, die gut für Betriebsprozesse geeignet sind.
Da es aber bei der Auswahl und Einführung des ITSM Verzögerungen gab, sollte das Projektmanagement-Tool als Übergangslösung herhalten. Inzwischen bin ich ein bisschen erfahrener und weiß auch, dass solche Übergangslösungen fast immer eine sehr viel längere Halbwertszeit haben, als ursprünglich geplant war.
Irgendwann kam das ITSM doch - und das Staunen ging weiter
Das Vorgehen war Folgendes: Es wurden Templates für die unterschiedlichen Tickets erstellt und das Onboarding der Kollegen, die die tatsächliche Vergabe der Berechtigung durchführen, gemacht. Beides war zügig abgehandelt.
Natürlich wurde auch darüber gesprochen, viele Teile der manuellen Arbeit durch Automatisierungen zu beschleunigen und einen Self-Service einzurichten. Das wurde aber abgelehnt - mit der Begründung, dass es zu viel koste und dass man nicht in Übergangslösungen investiere.
Im Rückblick ist das nun natürlich äußerst ironisch.
Die Weichen waren zu dem Zeitpunkt also gestellt und ein reibungsloser Ablauf sowie schnelle Abarbeitung hatten Priorität. Außerdem lief ja auch noch die ganze Migration aus einem Rechenzentrum in die Cloud, weshalb eine Anpassung eines Prozesses, der scheinbar ganz gut lief, absolut keine Priorität hatte.
Schließlich wurde doch noch ein ITSM eingeführt - und das Staunen ging weiter. Denn in dem Feld zur Anfrage von Berechtigungen wurden die unterschiedlichen Arten von Berechtigungen bei AWS gar nicht berücksichtigt.
Alles, also wirklich alles, lief unter " Software " < " Cloud ".
Inzwischen ist die Migration vorbei und ich bin sehr viel weniger für diesen Kunden im Einsatz. Wenn ich nicht gerade Tickets erstelle, damit Berechtigungen vergeben werden, arbeiten mein Kollege und ich daran, die Anmeldung mittels Single Sign On mit dem Active Directory zu koppeln.
Wie es wohl weitergeht?
Ich bin gespannt, ob mich weiterhin Anfragen erreichen. Zukünftig werden Berechtigungen nur noch über Gruppen im AD vergeben, auf das ich gar keinen Zugriff habe. Auch können die Berechtigungen immer noch nicht im ITSM-Tool verwaltet werden, weshalb die LPP-Prüfung ohne Software-Unterstützung händisch erfolgen muss.
Ich bin gern bei dem Kunden, frage mich aber schon manchmal, ob er das rückblickend nicht lieber anders gemacht hätte.
Der Autor dieses Textes wollte auf das Thema aufmerksam machen und einen Anstoß geben, wie man es besser machen könnte. Er wollte das aber nicht unter seinem eigenen Namen machen, deswegen wurde die Geschichte unter Pseudonym veröffentlicht. Der Name des Autors ist der Redaktion bekannt.
Bislang veröffentlichte Worst Practices: