In einem der letzten Artikel haben wir beleuchtet, warum es sinnvoll ist, eine Enterprise IT-Sicherheitsarchitektur zu erstellen. Mögen Sie sich noch daran erinnern? Wenn nicht – hier geht’s zum entsprechenden Artikel. Wenn auch Sie davon überzeugt sind, dass eine Sicherheitsarchitektur in Ihrem Unternehmen hilfreich wäre, dann lesen Sie weiter. Wir zeigen Ihnen auf, wie Sie zu einer zweckmässigen Architektur kommen.
Natürlich gibt es zu diesem Thema bereits viele Frameworks und noch mehr Literatur. Manchmal brin-gen aber pragmatische Ansätze genauso gute Ergebnisse und können durchaus hilfreich sein. Gerne möchten wir Ihnen einem solchen Ansatz vorstellen, den wir auch in Kundenprojekten anwenden. Wir erleben immer wieder, dass die Enterprise IT-Architektur fehlt oder unvollständig definiert ist. In diesem Fall gibt es verschiedene «Einstiegspunkte», um mit der Aufnahme des IST-Zustandes zu begin-nen.
Dabei werden in einem ersten Schritt die Zusammenhänge untersucht, um nach und nach ein vollstän-diges Bild der bestehenden IT-Landschaft zu erhalten. So werden die Beziehungen und Datenflüsse zwischen den IT-Systemen aus den Geschäftsprozessen aufgenommen. Dies liefert wichtige Informa-tionen über die beteiligten IT-Systeme und die dabei ausgetauschten Daten. In einem zweiten Schritt werden die Anforderungen der Stakeholder aufgenommen. Diese führen zu den Systemen, die diese erfüllen können – oder zeigen einen allfälligen «Gap» auf. Falls die entsprechende Anforderung business-relevant ist, sollte diese Lücke mit der neuen Architektur geschlossen werden. Abschliessend sollte eine bewährte Referenzarchitektur auf das jeweilige Unternehmen übertragen werden. Anhand dieser Referenz lässt sich die eigene IT-Landschaft kartieren («mapping»). Unsere InfoGuard Enterprise IT-Sicherheits-Referenzarchitektur sieht wie folgt aus (Klicken zum Vergrössern):
Bei der Analyse der IST-Situation können folgende Fragestellungen und Informationsquellen hilfreich sein:
Wenn die IST-Situation aufgenommen ist, gilt es die IT-Sicherheitsarchitektur «auf den Boden» zu bringen. Dabei muss nicht von Anfang an alles restlos geklärt und dokumentiert sein. Dies ist aus unserer Erfahrung ein Anspruch, der solche Projekte häufig scheitern lässt. Wir empfehlen daher Dokumente zu erarbeiten, die über die Zeit einen zunehmend höheren Detaillierungsgrad aufweisen. Wichtig ist allerdings, dass Architektur-Dokumente vom Unternehmen offiziell in Kraft gesetzt und für verbindlich erklärt werden. Wie Architektur anschliessend durchgesetzt werden kann, erfahren Sie weiter unten.
Nachfolgend eine Aufstellung der Aufgaben zur Detaillierung der Architektur mit entsprechenden Bei-spielen und dem erforderlichen Kenntnisstand:
Für die Architektur-Entwicklung steht eine breite Auswahl an Werkzeugen zur Verfügung. Diese lohnen sich aus unserer Sicht vor allem dann, wenn viele Beziehungen modelliert werden müssen. Sie helfen bei der Aufzeichnung und Sammlung von Meta-Information (Anwendungen, Systeme, Verbindungen, Prozesse usw.) sowie bei der konsistenten Aufbereitung der Informationen. Aber nicht jedes Unter-nehmen benötigt ein Tool! Für kleinere Unternehmen kann es auch ein Werkzeug aus den bereits vor-handenen Office-Umgebung oder anderen Präsentations-Tools sein.
Eine IT-Sicherheitsarchitektur durchzusetzen ist in erster Linie ein Governance-Thema. Es verlangt von den beteiligten IT-Architekten ein umsichtiges Vorgehen, um nicht als «Architekturpolizist» abgestem-pelt zu werden. Und es wird immer «gute» Gründe geben, warum in einem spezifischen Fall die Vor-gaben der Architektur nicht befolgt werden können... Deshalb ist ein bewährter Ansatz, die Hürden für ein Umgehen möglichst hoch zu setzen – aber nicht per se zu verbieten. In der Praxis haben sich fol-gende Ansätze bewährt:
Zur Abnahme und zur Überprüfung von Projektergebnissen sind zwei Gremien zu etablieren. Zum Überprüfen von Services und deren Schnittstellen eignet sich ein Service Review Board, deren Mit-glieder paritätisch aus IT-Architekten, Domänenarchitekten, Projektvertretern sowie Benutzervertretern bestehen. Zur Abnahme von Phasenergebnissen und zur Überprüfung auf IT-Architekturkonformität eignet sich ein Project Review Board. Dieses Gremium sollte mit genügend Kompetenz ausgestattet sein, um Projekte zu stoppen oder mit Auflagen zu belegen, wenn die Ergebnisse nicht den gewünschten Vorgaben entsprechen.
Enterprise IT-Architektur und damit auch die Enterprise IT-Sicherheitsarchitektur sind ein Prozess. Richtig gelebt, kann das Unternehmen seine Ressourcen effizient und effektiv einsetzen, entstehende Zielkonflikte transparent diskutieren und die Qualität der IT Services verbessern. Ein gutes IT-Architekturmanagement besitzt somit einen ordnenden Charakter und hat gegenüber den Projekten entsprechende Weisungsbefugnis. Das bedeutet, dass beispielsweise im Rahmen der Projektentwick-lung definierte Lieferobjekte wie das Pflichtenheft eines Projektes oder eine Schnittstellen-Spezifikation von den Fachstellen der IT-Architektur geprüft und freigegeben werden. Änderungen an Komponenten benötigen Aufmerksamkeit – und die Disziplin, die Architektur-Dokumente nachzuführen. Auch hier gibt es Erfahrungen aus der Praxis, wie dies im Rahmen des Change-Managements sichergestellt werden kann: Changes werden nur mit nachgeführter Dokumentation bewilligt! Dieses Mittel ist umso erfolgreicher, je mehr die Antragssteller einen Change benötigen.
Eine definierte Architektur hat auf die Dauer nur Bestand, wenn sie auch gelebt wird. Für die Kommu-nikation der IT-Architekturinhalte gelten die gleichen Vorgaben wie für jeden anderen fachlichen Inhalt, der intern vermittelt werden muss. Eine wichtige Rolle kommt der adressatengerechten Aufbereitung der Architektur-Leitlinien und -Vorgaben zu, die z.B. in einem Webportal für alle Mitarbeitenden zur Verfügung gestellt werden.
Die zielgruppen- bzw. empfängergerechte Kommunikation ist ein Schlüsselfaktor für ein akzeptiertes und positiv verankertes IT-Architekturmanagement. Vergessen Sie diesen Punkt bei Ihrer Enterprise IT-Architektur auf keinen Fall. Ansonsten könnte die tolle Arbeit bald in Vergessenheit geraten und über-holt sein.
Sie sehen: Enterprise IT-Architektur ist keine Hexerei. Aber man muss es machen. Genau hier liegt aus unserer Erfahrung das Problem. Neue Businessanforderungen verlangen schnelles Handeln. Und wie schnell werden neue Services genutzt, ohne diese zuvor in die Architektur zu integrieren...? Kennen Sie dieses Problem? Darum unterstützen wir unsere Kunden in der Planung und Umsetzung von struk-turierten und koordinierten Aktivitäten zur Sicherstellung der IT-Sicherheit in der Enterprise-Architektur, um die Kontinuität bei Veränderungen zu gewährleisten.
Interessiert? Dann finden Sie auf unserer Webseite weiterführende Informationen zu unseren Enterprise IT-Sicherheitsarchitektur-Services.
Wir stellen immer wieder fest, dass in Unternehmen die gleichen «Krankheitsbilder» in Bezug auf die IT-Sicherheitsarchitektur vorkommen. Aus diesem Grund haben wir Ihnen eine «Hausapotheke» mit den entsprechenden Medikamenten als «Sicherheitsmedizin» für die Behandlung von typischen Krankheiten zusammengestellt. Schlüpfen Sie doch einmal in die Rolle eines Hausarztes und verschreiben Sie Patienten die notwendigen Medikamente. Bevor Sie dies aber tun können, müssen Sie eine gründliche Abklärung machen und auch die möglichen Komplikationen berücksichtigen.
Sie lernen ‒ beinahe spielerisch ‒ Möglichkeiten, um die Sicherheit Ihres Unternehmens weiter zu optimieren. Per Mausklick kommen Sie zu Informationen über mögliche Lösungen und Services, die sie bei der Enterprise IT-Sicherheitsarchitektur-Umsetzung unterstützen können.