Bundesamt für Sicherheit in der Informationstechnik

M 2.530 Planung und Vorbereitung von Migrationen

Verantwortlich für Initiierung: Leiter IT

Verantwortlich für Umsetzung: Administrator, Fachverantwortliche

Migrationen von IT -Infrastrukturen sind in der Regel sehr komplexe Vorhaben mit einer großen Anzahl von Einflussfaktoren und möglichen Fehlerquellen. Migrationen verlaufen in aller Regel nur dann erfolgreich, wenn sie im Vorfeld sorgfältig geplant und vorbereitet werden.

Um nicht an der Komplexität des Themas zu scheitern, empfiehlt sich die Wahl eines bewährten Vorgehensmodells. In der Praxis haben sich weder reine Top-Down-Ansätze mit einmaliger Komplettumstellung noch ein reines punktuell aus den Fachabteilungen getriebenes Bottom-Up-Vorgehen bewährt. Zielführend ist der Mittelweg einer iterativen, priorisierten wechselseitigen Abstimmung der Geschäftsprozesse und IT -Modelle aus den Fachabteilungen und aus den Geschäftsanforderungen heraus. Reifegradmodelle können helfen, den jeweils nächsten Entwicklungsschritt einer Iteration zu planen.

Nachdem die im nächsten Migrationsschritt zu erreichenden Ziele festgelegt und die zu migrierenden Dienste identifiziert sind, werden im Planungsschritt die Anforderungen an die IT aus den Geschäftszielen (einschließlich der Sicherheitsanforderungen) abgeleitet. Die Phase der Migration umfasst die technische Umsetzung dieser Anforderungen in Form von Anwendungen und Systemen, die anschließend in den Betrieb überführt werden. Dieser Zyklus wird wiederholt, bis der gewünschte Reifegrad erreicht ist. In jeder Iteration ist dabei zu prüfen, welche Anpassungen an (Alt-)Anwendungen und Schnittstellen vorgenommen werden müssen.

Stehen der zeitliche Rahmen und Umfang der Migration fest, ist die notwendige technische Infrastruktur zu planen. Hier sind insbesondere Fragen der Dimensionierung wichtig, denn Web-Service-Umgebungen unterscheiden sich hinsichtlich der benötigten Ressourcenparameter im Allgemeinen deutlich von den bestehenden Umgebungen. Sinnvollerweise werden Lasttests durchgeführt, mindestens aber Fachverstand in Bezug auf die Ressourcenausstattung herangezogen.

Die Migrationsplanung hat zu berücksichtigen, welche Systeme und Anwendungen wann migriert werden, ob Ausfallzeiten nötig und vertretbar sind. Für unerwartete Komplikationen müssen Abbruchkriterien und Rückfallszenarien definiert werden, mit denen sich die Umgebung in einen betriebsfähigen Zustand zurücksetzen lässt.

Besonders zu Berücksichtigen bei der Planung sind die dadurch entstehenden Abhängigkeiten von Anbietern und Standards. Letztere sind sorgfältig auszuwählen und sollten in ihrer Weiterentwicklung und auch auf möglicherweise bekannt werdende Sicherheitslücken in den Standards selbst beobachtet werden.

Wenn besondere Systeme zum Einsatz kommen sollen, die bisher nicht benötigt wurden - etwa eine XML -Firewall als Application Level Gateway -, so sind diese vorher ausführlich im Hinblick auf die erforderliche Funktionalität zu testen und in das Sicherheitskonzept mit aufzunehmen.

In dem Maße, wie eine Migration die Chance bietet, zukünftig zentrale Dienste wie Identitätsmanagement oder eine PKI standardisiert nutzbar zu machen, müssen auch diese Dienste betrachtet und zusätzlich abgesichert werden. Insbesondere wenn ein Single Sign-On geplant wird, sind die Implikationen auf die Sicherheit genauestens zu prüfen, siehe auch M 4.456 Authentisierung bei Web-Services , M 4.455 Autorisierung bei Web-Services und M 4.453 Einsatz eines Security Token Service (STS) .

Die spezifischen Risiken, die sich durch eine Migration ergeben, beziehen sich zum einen auf die damit verbundenen Änderungen der Architektur. Die für die Zielarchitektur erforderlichen Sicherheitsmaßnahmen sind daher (anhand der einschlägigen Bausteine oder einer ergänzenden Sicherheitsanalyse und gegebenenfalls zusätzlichen Risikoanalyse) vorab zu identifizieren und zu berücksichtigen. Beachtet werden muss auch, dass durch die Migration Abhängigkeiten entstehen können, die die Anforderungen an die Verfügbarkeit deutlich erhöhen können. Zum anderen birgt auch die Migration selbst Risiken, da diese sowohl mit hohen Kosten als auch mit einer langen Projektlaufzeit einhergehen kann. Beide Klassen von Risiken sind im Zuge der Migrationsplanung zu analysieren und dokumentieren.

Für eine umfangreiche Migration oder eine tief greifende Umstellung der Architektur ist es zudem dringend anzuraten, ein eigenes Sicherheitskonzept zu erarbeiten und das Ergebnis der Migration im vorhandenen Sicherheitskonzept zu behandeln.

Dies trifft insbesondere dann zu, wenn eine Migration auf einen zentralen Servicebus (meist ESB, Enterprise Service Bus) vollzogen wird. Dieser stellt einen möglichen zentralen Ausfallpunkt dar und sollte daher angemessen in der Notfallplanung berücksichtigt sein, falls es Anforderungen in Bezug auf die Verfügbarkeit der SOA gibt.

Nicht zu vernachlässigen ist auch die Frage des Wissenstransfers: Durch die tief greifende Umstellung der Architektur wird von den Administratoren, letztlich aber auch von den Fachverantwortlichen ein Umdenken verlangt, das bereits in der Planungsphase mit entsprechenden Zeitaufwänden und Schulungen zu berücksichtigen ist.

Eine Migration stellt immer ein langfristiges und strategisches Programm dar, das, um Erfolg zu haben, von der Leitungsebene getragen und gesteuert werden und von den Beteiligten über die komplette Laufzeit mit Leben gefüllt werden muss.

Prüffragen:

  • Wurde ein geeignetes Vorgehensmodell für die Migration gewählt?

  • Wurden die zu migrierenden Dienste identifiziert und deren Anforderungen, einschließlich der Sicherheitsanforderungen, erhoben und dokumentiert?

  • Wurde die notwendige Auslegung der Infrastruktur und der Systeme durch Expertise oder realistische Lasttests bestimmt?

  • Wurden notwendige Ausfallzeiten ermittelt, geplant und abgestimmt?

  • Ist ein Rückfall-Szenario vorbereitet, und sind Abbruchkriterien für die Migration definiert?

  • Sind die spezifischen Risiken der Migration analysiert und dokumentiert?

  • Ist ein Wissenstransfer an das Betriebspersonal und die Fachverantwortlichen gesichert?

  • Wird die Migrationsstrategie von der Leitungsebene getragen und die Migration von ihr gesteuert?

Stand: 14. EL Stand 2014