Archiv der Kategorie: Allgemein

Management – Landkarte Teil3: Big Picture

Schreibe eine Antwort

In Teil 1 und 2 der Reihe habe ich unter anderem vom Big Picture gesprochen. Anhand einer fiktiven Infrastruktur-Architektur eines mittelständischen Unternehmens möchte ich im Detail auf das Thema eingehen.

Management- Landkarte Teil2: technische Methoden

Management- Landkarte Teil1: organisatorische Methoden

Warum also ein Big Picture?

Die wenigstem Menschen sind in der Lage, komplexe Strukturen in allen Details über lange Zeit im Kopf zu behalten. Zudem hat jeder Mensch eine eigene Vorstellungswelt, die nicht unbedingt mit den Vorstellungswelten anderer beteiligter Personen deckungsgleich ist. Last but not Least sind auch Fachbegriffe meist unterschiedlich belegt, so das es zu Unverständnis trotz gleicher Fachsprache kommt.

Diese drei wichtigen Gründe führen dazu, eine gemeinsame Basis zu schaffen, die von allen Beteiligten verstanden und akzeptiert wird. Da Infrastrukturen durch ihre Komplexität nicht sonderlich gut durch Texte beschrieben werden, ist der Weg über ein großes Bild, ein Big Picture der gegebene Weg.

Das Pig Picture hilft dem Team wichtige Infrastruktur- Komponenten und ihre Details im Zusammenhang mit anderen Komponenten in einer einheitlichen Sprache darzustellen. Ein Big Picture zeigt mindestens die Technologieebene des zugrundeliegenden Metamodells auf.

Gerne gehe ich in einem späteren Artikel auf das Thema Metamodell ein. Da sich aber dieser Artikel auf den Aspekt der „Allgemein verfügbaren Infrastruktur- Komponenten der Technologieebene“ beschränkt, soll des erstmal damit genug sein. Wer sich vorab über das Thema informieren möchte, dem lege ich diesen Artikel über Metamodelle ans Herz.

Allgemein verfügbare Infrastruktur Komponenten (Basis-Infrastruktur)

Jede Fachanwendung benötigt Infrastruktur-Komponenten wie Authentifizierung & Autorisierung, File- & Print- Services, Datenbanken, Anwendungsserver, Schnittstellen, Sicherheitsfeatures und Backups usw.. um notwendige Leistung für den Fachbereich zur Verfügung zu stellen.

Diese „Allgemein verfügbaren Infrastruktur- Komponenten“ oder Basis-Infrastruktur sind in der Regel in allen Organisationen in der Mindest-Funktionalität gleich. So bedarf es für den geregelten Betrieb Netzwerkkomponenten , DNS, DHCP, Directory Service wie ADDS, Zertifikatsverwaltung wie AD CS, Server- und Client Deployment, Datenbanken, Sicherheits-Komponenten wie Firewalls und Patch-Management Komponenten uvm.

Alle diese Komponenten stehen in Bezug zueinander. Sie kommunizieren miteinander. Und sie haben unterschiedliche Wertigkeit bezüglich Authentizität, Integrität, und Verfügbarkeit in Abhängigkeit der zu verarbeitenden Daten. Diese Aussagen treffen auf 100% der IT – Infrastrukturen zu.

Technologieebene

Deshalb versuche ich hier, ein allgemein gültiges Bild einer Basis-Infrastruktur – bezugnehmend auf ein mittelständiges Unternehmen mit ca. 500 MA – abzubilden. Bei größeren Unternehmen und über mehrere Standorte kann das Bild weiter diversifiziert werden. Bei kleineren Unternehmen muss sicherlich an der einen oder anderen Stelle mit Abstrichen rechnen.

Das Big Picture ist

  • Grundlage für das gemeinsame Verständnis von Zusammenhängen und Abhängigkeiten zwischen IT den Fachbereichen und der Geschäftsführung
  • Grundlage für tiefer gehende (technische) Diskussionen innerhalb der IT
  • Ankerpunkt für detaillierte technische Plots der Feinarchitektur z.B. für Fachanwendungen

Big Pictures sind wie die zugrunde liegenden Infrastrukturen einem steten Wandel unterzogen. Dabei gibt es aber auch mehrere Konstante: Die einmal getroffene Datenklassifizierung wird sicherlich so schnell nicht mehr grundlegend geändert und Authentifizierung & Autorisierung ist immer erforderlich.

Datenklassifizierung

Daten in einem Unternehmen haben unterschiedliche Gewichtungen hinsichtlich Ihrer Wichtigkeit für den Fortbestand und der Erfolg des Unternehmens. So sind die CRM- Daten und die Einkaufskontrakte eines Handelshauses die Grundlage des Erfolges. Kommen diese Daten in die Hände der Mitbewerber, gefährdet das maßgeblich die Zukunft des Unternehmens Ich bezeichne diese Daten als Kronjuwelen

Eine weitere existentielle Datengruppe sind die Mitarbeiter-Daten. Sie zu vernachlässigen, würde nicht nur gegen geltendes Recht verstoßen, sondern auch Angreifern die Gelegenheit bieten, via Sozial Hacking an die Kronjuwelen zu gelangen.

Die dritte Gruppe sind alle Zugangsdaten zum Unternehmen, sei es physisch wie auch IT-seitig. Diese Daten werden von Angreifern in der Hauptsache genutzt um das Unternehmen auszuspähen und ihm ggfls. zu schaden.

Damit wären die überlebenswichtigen Datengruppen benannt.

  • Strategische und operative Daten -> die Kronjuwelen
  • Mitarbeiter- Daten
  • Zugangsdaten

Aber eigentlich sind all‘ diese Datengruppen die Kronjuwelen des Unternehmens.

Authentifizierung & Autorisierung

Zu dem Thema habe ich mich bereits ausführlich geäußert, so das ich auf die folgenden Artikel verweisen darf:

Schutz von Unternehmensidentitäten: Sicherheitsstrategien für ADDS

Tiering-Modell / Security Level

Tiering-Modelle sind seit langem im Finanz- und Versicherungswesen eingeführte Architekturkonzepte. Sie bilden konzentrische Datenringe, Tiers in Securitylevels ab. In der Regel sind fünf Levels / Tiers für den sicheren Betrieb einer Intrastruktur ausreichend, Sie können segmentiert und, wenn erforderlich, um weitere Tiers ergänzt werden.

generisches Tiering-Model einer konzentrisch aufgebauten IT-Infrastruktur
generisches Tiering-Modell
  • TIER 0: DATA
    existentielle Daten des Unternehmens in Datenbanken, HR-Daten, AD, PKI
  • TIER 1: SERVICES & APPLICATIONS
    Applikationsserver, mit Schnittstellen zu internen Systemen in TIER1q und zu Datenbankservern in TIER0.
  • TIER 2: WORKPLACE
    Arbeitsplatze und Endgeräte mit geregeltem Zugriff auf Applikationen in TIER1
  • TIER 4: PERIMETER / DMZ
    Frontendserver, die mit externen Entitäten via Internet kommunizieren müssen.
    Die Frontendserver kommunizieren mit Applikationen in TIER1 über geregelte, verschlüsselte und überwachte Schnittstellen und Protokolle.
  • TIER 5: INTERNET
    In Menge und Qualität nicht definierbare weltweite Umgebung. Zugriff aus dem Internet auf Frontend-Systeme in Tier4 bei höchst möglicher Sicherheit bezüglich Datensparsamkeit, Identität, Verschlüsselung und Überwachung.

Das Tiering Modell wurde in den letzten Jahren insbesondere durch Microsoft für den Einsatz des Active Directory und den angrenzenden Technologien getrieben. Das das Active Directory das führende Identitäts-Directory ist, ist dieses Modell allgemeingültig geworden.

Stages: Produktion & Support

Es ist sehr wichtig zu erwähnen, das eine Produktionsumgebung unbedingt von äußeren Einflüssen frei zu halten ist. Die Produktionsumgebung unterliegt den Regeln des ITSM und der Sicherheit. So dürfen Änderung an der Produktion nur über definierte Kanäle (Deployment-Chain) und durch die Begleitung eines Change Prozesses durchgeführt werden. Ziel ist die umfassende Betriebssicherheit und vollständige Transparenz der Handlungen.

Entwicklung und Test werden in eigenen Stages durchgeführt. Das sind in der Regel eine Entwicklungs- und Testumgebung, sowie eine Abnahmeumgebung, die funktionsgleich der Produktionsumgebung ist. In komplexen Situationen ist eine Integrationsumgebung sinnvoll.

Ergebnis

Das Ergebnis ist ein durchgängiges Tiering-Modell für die Produktionsumgebung, indem Entwicklung, Test und Abnahme von der Produktionsumgebung getrennt ist. Der administrative Zugriff darf immer nur aus dem Level erfolgen, indem die Server / Services aufgestellt sind. Der Zugriff aus einem niedrigeren Security Level auf ein höheren Security Level zum Zweck der Administration ist streng untersagt. Ansonsten sind Durchgriffe für produktive Aufgaben geregelt, verschlüsselt, überwacht und dokumentiert.
Nach Möglichkeit sind Protokollwechsel zwischen den Security Level anzustreben.
Es gilt immer die Prämisse der Datensparsamkeit.

Produktion, Entwicklung und Test sind streng voneinander getrennt. Es gibt keinen Durchgriff und keinerlei direkte Verbindung. Einfluss auf die Produktion kann lediglich durch eine geregelte, limitierte und automatisierte Bereitstellung erfolgen.

Im Beispiel wird die Zufuhr von Software, Updates und Patches über einen Dienstleister erbracht. Das ist eine Lösung, die der Unternehmensgröße und Zweck an dieser Stelle gerecht wurde. Dabei sind CI/CD Ansätze noch nicht implementiert.

Auch ist in diesem Beispiel noch VPN als Verbindungstechnik für Mitarbeiter und Administratoren vorgesehen. Darauf würde ich in Zukunft gerne verzichten zugunsten einer dedizierten Service- Bereitstellung über Cloud Funktionalitäten.

VPN hat aus meiner Sicht in der Zukunft höchstenfalls eine administrative Funktion. Sie sollte wenigen Personen und restriktiver Nutzung bereitgestellt werden.

Big Picture
Big Picture eines fiktiven Unternehmens (JPG Format)

Im Big Picture wurde der Focus zunächst auf die On-Premise Umgebung gelegt. Cloud Komponenten sind rudimentär berücksichtigt, werden aber noch im Detail zu deklinieren sein.

Das Big Picture ist ein lebendes Dokument. Es wächst und ändert sich mit den Aufgaben und Erkenntnissen, die in einer IT Organisation anfallen. Ich werde auch das fiktive Infrastruktur-Modell an dieser Stelle weiter pflegen.

Big Picture

Hier können Sie das Big Picture als .pdf Datei in voller Größe herunterladen.

Send download link to:

Wie rettet man ein Projekt

Schreibe eine Antwort

In meiner Tätigkeit ist es mehrfach vorgekommen, das ich zu einem Projekt berufen wurde, das vor dem Scheitern stand. Es waren in der Regel komplexe Projekte mit vielen Stakeholdern und ambitionierten Zielen.

Der Grund für die hohe Eintrittswahrscheinlichkeit war meist fehlende Struktur und indifferente Kommunikation im Projekt. Ich möchte an einem Beispiel aufzeigen, welche Möglichkeiten man hat, ein solches Projekt zu retten.

Als Beispiel dient ein großes Projekt zur Entwicklung eines multifunktionalen Arbeitsplatzes mit einem speziellen Frontend auf Basis von Windows 10. Dieser Arbeitsplatz sollte den Betriebsablauf im Drei- Schicht- Betrieb mit damals 17.000 Mitarbeitern unterstützen. Der vorherige Arbeitsplatz basierte auf Windows XP.

Anforderungen waren in Form von Erwartungshaltungen formuliert, d.h. es gab lediglich Aussagen wie „Der Arbeitsplatz muss genauso aussehen und funktionieren wie der alte Arbeitsplatz“.

Da der Kunde Software- und Infrastruktur- Entwicklung nicht trennte, wurde ein Software- Entwickler als Architekt und PM beauftragt, das Projekt zu verwirklichen.

Die Krise

Ein definitiver Stand der Entwicklung war bei der Übernahme des Projektes nicht erkennbar:  Der Basis-Client war begonnen und dokumentiert, jedoch wurde die Entwicklungsarbeiten für das Frondend am Betriebssystem vorbei programmiert. Somit entstanden u. a. redundante Funktionen, die zu größten Teil nicht die Qualität der bereits vorhandenen Funktionen erreichte.

Der bedrückendste Teil war aber die vollständig fehlende Entwicklungs- Test- und Fehlerbehebungs- Kultur. Es fehlte an dokumentierten Aufgaben, (Teil)- Abnahmen und der gesamten Dokumentation. Zudem war der Delivery- Prozess in der Software- Entwicklung vollständig von einer Person abhängig und nicht durchgängig automatisiert..

Der Deployment- Prozess für den Basis-Client fehlte vollständig.

Die Kommunikation zwischen Projekt, Nachbarprojekten und Programmleitung war  vollständig zum Erliegen gekommen. Das Projekt war zu diesem Zeitpunkt bereits mehrere Jahre alt.

Was war zu tun ?

Um das Projekt aus dem verfahrenen Status Quo in eine produktive Situation zu bringen, waren einige grundsätzliche Änderungen im Projekt notwendig. Sie werden in den nachfolgenden Kapiteln beschrieben.

  • Etablierung eines Entwicklungsprozesses
  • Quality-Gates
  • Einführung von Kommunikationsregeln
  • Kommunikation mit Programmleitung und Nachbarprojekten
  • Dokumentation
  • Projektplanung und agile Projektführung
  • Teams und Verantwortlichkeiten

Etablierung eines Entwicklungsprozesses

Damit die einzelnen Aufgaben des Projekts zielgerecht bearbeitet werden können, ist ein klarer Entwicklungsprozesses notwendig.

Der Prozess startet mit der Annahme einer Anforderung, über die Entwicklung, den Test und die Abnahme im Projekt. Alle abgenommenen Aufgaben werden zyklisch zu einem Release zusammengestellt. Dabei sind folgende Regeln zu beachten:  

  • Anforderungen werden immer an das Anforderungsteam gestellt
  • Anforderungen durch das Anforderungsteam werden bewertet nach: Erwartungshaltung des Fachbereichs, Inhalt, Lösungsraum,  Aufwand, Dauer, Testrelevanz
  • Das Anforderungsteam bestand aus Business Analyst, Solution Architekt, dem RTE  und / oder techn. Project Manager
  • Alle Projektmitglieder sind in Ihrem Themengebiet CONSULTANT
  • Alle Projektmitglieder sind in der Kerngeschäftszeit (9:00 – 17:00 Uhr) auskunftsfähig
  • Dokumentation wird nach dem Dokumentations-Style-Guide aufgebaut.

Der Entwicklungsprozesses wurde in die nachfolgenden Prozessschritte gegliedert:

  • Anforderung
  • Qualifizierung /Priorisierung
  • Entwicklung
  • Test (Integrations-Test & U.A.T)
  • Release & C.R.
  • Produktion

Quality-Gates

Entlang des Entwicklungsprozesses musste die Qualität der Ergebnisse wiederholt überprüft werden. Das begann mit dem Code Review oder einem (Vier Augen) Systemtest, einen Integrationstest, einem Performancetest (wenn notwendig), dem User Acceptance Test (UAT) Jedes Test- Szenario entspricht einem Quality Gate.

In der Software-Entwicklung konnten die Tests bis auf Integrationstest und UAT automatisiert werden.

Neben den Quality Gates im Entwicklungsprozess wurden weitere Quality Gates beim Deployment der notwendigen Infrastruktur eingeführt. Über dies Quality Gates wurden Defekts im Deployment Prozess identifizierbar.

Generell gilt: zu Viele Quality Gate werden kontraproduktiv.

Einführung von Kommunikationsregeln

Jede Person kommuniziert gerne individuell. Das ist aber in einem Projekt nicht möglich. Das bedeutet, das es feste Regeln und Tools für die Kommunikation geben muss. Kommunikation bedeutet auch nicht nur die Erreichbarkeit, Pünktlichkeit und Auskunftsfähigkeit im Projekt. Es umfasst auch die Bereitstellung der Arbeitsergebnisse ohne weitere Aufforderung an einen festgelegten Ort.

  • Teams ist das gesetzte synchrone Kommunikationsmittel, ersatzweise Telefon etc.
  • Mail die das gesetzte asynchrone Kommunikationsmittel. (informell)
  • Jira ist das gesetzte asynchrone Kommunikationsmittel (formell)
  • Es gibt ein gesetztes Test- und Defects- Management- Tool im Projekt
  • Jedes Projektmitglied stellt die Informationen zur Kommunikation (sofern sie nicht durch das Projekt bereitgestellt werden) zur Verfügung.
  • SharePoint unterstützt Dokumentensammlung und fasst Quellen zusammen
  • Git ist das Repository für Scripte und Programmcode
  • Ein Glossar ist verbindlich

Kommunikation mit Programmleitung und Nachbarprojekten

Da hier Stillstand erreicht wurde, musste die Kommunikation mit den Nachbarprojekten und der Programmleitung neu organisiert werden. Dazu diente die vollständige Transparenz über den Stand. Sie beinhaltete die u.a. Erläuterung der getroffenen Maßnahmen zur Abhilfe. Außerdem wurde festgelegt, welche Personen für diese Kommunikation geeignet waren.

Dokumentation

Dokumentation, zumal in einem solch großen Projekt hat immer einen sehr hohen Stellenwert. Denn sie transportiert nicht nur das Ergebnis einer Aufgabe. Sie vermittelt auch den Grund an die Personen, die mit der Doku arbeiten sollen.

  • Dokumentation ist Teil der vollständigen Bearbeitung einer Aufgabe
  • Dokumentation richtet sich immer an eine ist immer Zielgruppe.
  • Dokumentation ist immer auf dem Stand der Entwicklung
  • Dokumentation folgt immer einem Style Guide
  • Dokumentation ist an das Style Guide anzupassen
  • Dokumentation muss überprüft und bewertet werden (Review).
  • Dokumentation ohne Review = keine Einlieferung

siehe: Grundlagen für eine sichere IT-Organisation – Dokumentations-Reifegrade

Teams und Verantwortlichkeiten

  • Jede Person im Projekt ist verbindlich mit einem oder mehreren Themen verbunden. Diese Verbindungen wird an alle Projektmitglieder tagaktuell kommuniziert.
  • Um Aufgaben besser koordinieren zu können wurden drei Teams gebildet:
  • Frondend Software- Entwicklung
  • Basis-Client Entwicklung
  • Client-Deployment Entwicklung
  • Pro Team wurde ein Team- Lead bestimmt. Jeder Team- Lead plant und koordiniert mit seinem Team den nächsten Sprint. Die Team- Leads stimmten sich mit dem techn. Projektleiter ab.
  • Darüber hinaus wurden verschiedene clusterübergreifende Positionen entlang des Delivery-Prozesses geschaffen: Anforderungs-Manager / Business-Development -Manager Test-Manager Release-Manager

Verantwortlich für den Delivery- Gesamtprozess war der techn. Projektleiter. 

Die Gesamtverantwortung lag beim RTE (Release Train Engineer)

Der Teamaufbau erfolgte nach der folgenden Grafik.

Teamaufbau

Projektplanung und agile Projektführung

Das Infrastrukturprojekt konnte am sinnvollsten durch eine Hybride Lösung von Wasserfall und agilen Projekt-Management Methoden begleitet werden.

  • Die Wasserfall-Planung kann die Bereitstellungs- Reihenfolge von Infrastruktur-Komponenten darstellen. Zudem eignet sie sich besser zur Kommunikation mit den Projekt- Owner oder dem Lenkungskreis.
  • Agile Methoden wie Scrum sind sehr gut geeignet, einzelne Komponenten – Funktionen zu entwickeln, zu testen und zur  Integration vorzubereiten.

Die Herausforderung für den Projektleiter war es, beide Methoden zu verbinden. So konnte ein gemeinsames Verständnis über den Stand der Dinge für die Technik erreicht werden. Auch für das Business wurde ein gemeinsames Verständnis erzielt.

Fazit

Ich möchte Niemanden übermäßig mit der Aufzählung von Schulbuch -Weisheiten quälen. Deshalb nur soviel: Ein Projekt kann nur funktionieren, wenn die o.g. Punkte in geeigneter Weise im Vorfeld gelöst sind. Erfolgreich wird es, wenn alle Projektteilnehmer sich nicht zu ernst nehmen. Sie sollten eine gewisse Demut vor der Aufgabe haben. Respekt vor den Kollegen ist ebenfalls wichtig. Und wenn man auch noch das Ganze mit Humor würzen kann, dann kann fast nichts mehr schiefgehen.

P.S. Für den Projekt-Owner: Zu einem Projekt gehört immer ausreichend Ressourcen!

Management- Landkarte Teil2: technische Methoden

Schreibe eine Antwort

Bei den technologischen Methoden und Verfahren ist es extrem wichtig, die Menge der eingesetzten Methoden so gering wie möglich zu halten. Dennoch sollen sie so umfangreich wie nötig sein. Konkurrierende Methoden führen zu Intransparenz und stark erhöhtem Aufwand.

Beispiel:

Setzt man als Autorisierungsinstanz Microsoft Active Directory und ein oder mehrere andere Directoires (IBM RACF, SAP ID oder Oracle LDAP Server) gleichermaßen ein, führt das auch bei stringentem Einsatz von Richtlinien und Prozessen auf beiden Seiten über kurz oder lang zu Abweichungen in den Berechtigungen. Auch werden die Accounts (named User) kontextbezogen nicht deckungsgleich bleiben. Strukturelle Sicherheitslücken sind eine sichere Folge. Und Software- Migrationen werden unnötig erschwert, weil Authentifizierungsverfahren nicht kompatibel sind.

Komplexität in den Griff bekommen: Keep IT simple

Erfolgreiche IT-Organisationen gestalten ihre Prozesse so einfach und transparent wie möglich. Sie benutzen wesentlich weniger Softwareplattformen und Anwendungen, darüber hinaus setzen sie auch bei der Hardware auf einfache, effiziente Lösungen.

Gesenkte Komplexität in der IT verbessert auch die Prozesse anderer Abteilungen. Dabei setzen Sie vor allem auf Standardlösungen und auf möglichst einheitliche Datenbestände On-Premise und in der Cloud. Es gibt immer nur eine wahre Daten-Quelle.

Technische Methoden für den Erfolg

Die nachfolgenden Methoden sind die das Mindestmaß an Struktur, die eine IT Organisation benötigt. Sicherlich gibt es weitere Methoden, die notwendig werden können, wenn kann im konkreten Fall erfolgreich IT betreiben will.

User Life Cycle Management / Identity Access Management

Ein Großer Teil der Angriffe erfolgen über Identitätsklau. Verschiedene Methoden zielen darauf ab, Identitäten im Unternehmen zu erspähen. Mit diesen Identitäten sollen weitere Identitäten mit höheren Rechten erlangt werden. ULC & IAM helfen hier, den validen Überblick über die Identitäten zu jedem Zeitpunkt zu halten.

Enterprise Access Management

Ein wichtiger Bestandteil des User Life Cycle Managements ist die Sorge um Identitäten. Diese Identitäten haben erhöhte Privilegien bis hin zur Enterprise Administration. Sie sind die eigentlichen Angriffsziele von Hackern. Deshalb ist die konsequente Einbeziehung von Authentifizierung & Autorisierung im Enterprise Access Management sehr wichtig. Ebenso wichtig ist der Schutz unternehmenswichtiger Daten und Informationen.

Software Life Cycle Management

Die Menge der Software bestimmt die Lizenz- und – noch wichtiger – die Prozesskosten.
Denn Software muss verteilt, in das Berechtigungskonzept eingepasst, gewartet und aktualisiert werden. Hier hilft das Software Life Cycle Management, die Angriffsflächen und Betriebsaufwände zu minimieren.

Vulnerability Management

Schwachstellen (Vulnerability-) Management ist die zentrale Methode, Schwachstellen in der IT-Infrastruktur zu erkennen, zu bewerten und zu sanieren. Das gilt nicht nur für programmatische Schwachstellen. Sie treten immer wieder in jeglicher Software auf. Es gilt auch für das Design der IT-Infrastruktur und alle damit eingesetzten Prozesse.

Certification Management

Neben User Life Cycle Management / IAM ist der gezielte Einsatz und Pflege von Zertifikaten existentiell für eine sichere IT-Infrastruktur. So sollten nicht nur alle Devices und User mit Zertifikaten abgesichert werden. auch alle Kommunikationsbeziehungen sind verschlüsselt auszuführen.
Darüber hinaus sind alle Skripte, die z.B. der Automation dienen, mit einem Zertifikat zu signieren.

Aufbau der IT-Infrastruktur nach Security Levels

Security-Levels bilden die Vertrauenswürdigkeit eines Netzwerkes ab. Je höher der Security-Level ist, desto vertrauenswürdiger ist der Level. Hohe Security-Levels haben per Default Zugriff auf niedrige Security-Level, andersrum wird der Zugriff verwehrt. Kommunikation zwischen Zonen desselben Security-Level werden per Default geblockt. Folgende Security- Level bilden aus meiner Sicht das Mindeste an Sicherheit.

  • DATA (Level 5)
    DATA ist mit der höchsten Vertraulichkeitsstufe belegt. Hier werden alle strukturierten und unstrukturierten Daten (Datenbanken, Dateien), das Active Directory und die Zertifikatsserver untergebracht. Darüber hinaus sind Backup- , Deployment- und Automationsumgebungen in diesem Level, aber technisch getrennt, unterzubringen. Alle Systeme in dieses Levels sind existentiell für das Unternehmen.
  • APPLICATION (Level 4)
    Im Security Level APPLICATION sind die Applikationsserver und Web-Frontends zu finden. Interne Mitarbeiter kommunizieren mit ihnen. Die Applikationsserver kommunizieren wiederum mit den Datenbankservern in DATA (Multi-Tier-Anwendung).
    Im Best Case können diesen Systeme on Demand neu deployed werden. Alternativ müssen sie aus einem aktuellen Backup jederzeit wieder hergestellt werden können, um den Betrieb zu gewährleisten.
  • WORKSPACE (Level 3)
    Im WORKSPACE sind alle Arbeitsplätze (intern wie extern) zu finden. Sie kommunizieren in der Regel nur mit den Systemen im Security Level APPLICATION.
  • DMZ / PERIMETER (Level 2)
    Die Kommunikation mit externen Partnern B2B oder B2C wird in der Regel über die DMZ abgehandelt. Hier stehen Frontends, wie beispielsweise Shop Systeme, die die Kommunikation mit Kunden und Partnern ermöglichen. Diese Systeme haben keinerlei Datenhaltung (Ausnahme: Konfigurationsdaten). Sie bedienen sich abgesicherter System in APPLICATION. Sie sind im Schadenfall innerhalb kürzester Zeit durch automatisch neu aufgesetzte Systeme ersetzbar.
  • INTERNET (Level 1)
    Das Internet ist grundsätzlich Böse! -:). Natürlich ist das Internet nicht grundsätzlich böse, hat es doch in den letzten Jahrzehnten zu Prosperität und Wohlstand signifikant beigetragen. Es ist jedoch wichtig, sich umfassend und permanent vor den Gefahren zu schützen. Diese Gefahren können durch das Internet bis in das Unternehmen getragen werden.

Staging

In den Anfängen der IT hieß es „Never touch a runnnig system!“ Das gilt in abgewandelter Form auch heute noch:

„Never touch a prodution system without a Change“

Das bedeutet, dass Entwicklung und Test aus dem Produktionsnetzwerk verbannt werden müssen. Dies geschieht, um die höchst mögliche Stabilität der Produktionsumgebung zu erreichen. Erst die fertig ausentwickelte Lösung darf in das Produktionsnetz eingebracht werden. Und das nach festen Regeln, meist im Rahmen eines Change Request und nach Freigabe und der Umsetzung, dem Change.

Um Entwicklung und Test zu unterstützen sind eigene, vollständig unabhängige Umgebungen, die nach an der Produktions- Realität sind, notwendig. Dort können dann neue Methoden und technologieren bis zur Produktionsreife entwickelt, konfiguriert und getestet werden.

Fazit

die beschriebenen Maßnahmen stellen wie auch in Teil 1 beschrieben, das absolute Minimum dar. Mehr geht immer.
Technische Methoden schaffen Klarheit im Umgang mit Technik. Sie bilden das Rückgrat für alle Entscheidungen innerhalb der IT. Was noch wichtiger ist: Endlich muss nicht jede Entscheidung lang und breit besprochen werden. Alle Mitarbeiter orientieren sich an den gewählten Methoden.

.

weiterführende Links

Management- Landkarte Teil1: organisatorische Methoden

Management – Landkarte Teil3: Big Picture

Management- Landkarte Teil1: organisatorische Methoden

Schreibe eine Antwort

IT- Organisation benötigen – wie jede andere Organisation auch – verlässliche Management- Methoden. Sie müssen transparent und messbar sein und den betrieblichen Ablauf und die Weiterentwicklung maßgebend stützen. Insofern sage ich hier nichts neues.

Je nach Größe der IT-Organisation kommen mehr oder weniger IT Service Management- Methoden zum Einsatz. Ich beschreibe hier das Mindeste für ein mittelständisches Unternehmen. Dabei ist es unerheblich, ob die Methoden intern durch die eigene Organisation oder extern, durch einen Dienstleister erbracht werden.
Vorab: Diese Methoden müssen nicht neu erfunden werden, es gibt sie schon sehr lange: ITIL V3 teilt Services in folgende Gruppen ein:

  • Service Strategy
  • Service Design
  • Service Transition
  • Service Operation
  • Continual Service Improvment

ITIL V4 verlässt das Feld der statischen Gruppen und bildet stattdessen vier Dimensionen. Neben der höheren Flexibilität sollen sie ein ganzheitlichen Ansatz für das Management der IT-Organisation ermöglichen.

  • Organisationen und Personen (‚Organizations and people‘)
  • Informationen und Technologien (‚Information and technology‘)
  • Partner und Lieferanten (‚Partners and suppliers‘)
  • Wertströme und Prozesse (‚Value streams and processes‘).

Welchem Model man auch folgen mag, aus meiner Sicht sollten die nachfolgenden Services aus „Service Operation“ eingeführt werden. Ebenso sind die Services aus „Service Strategy“ mit der höchsten Dringlichkeit umzusetzen. Wenn die IT – Organisation erfolgreich mit diesen Services arbeitet, kann man über die Erweiterung des Service Angebotes nachdenken.

Incident Management / Service-Request

Incident Management befasst sich mit allen Ereignissen, die Abweichungen vom erwarteten Verhalten eines Services beinhalten. Incident Management ist verantwortlich für den gesamten Lebenszyklus aller Incidents.
Wichtigstes Ziel des Incident Management ist die schnellstmögliche Wiederherstellung des SLA-konformen Servicebetriebs. Auch Workarounds werden genutzt. Ein weiteres Ziel ist die Minimierung negativer Auswirkungen auf die Geschäftsprozesse.
Incident Management / Service-Request sind die im Unternehmen am meisten gesehenen Dienstleistungen. Sie bilden einen sehr wichtigen Teil der Reputation der IT-Organisation.

Problem Management

Problem Management zielt darauf ab, die Auswirkungen von Incidents zu minimieren, indem es Incidents möglichst verhindert. Für bereits eingetroffene Incidents versucht das Problem Management, deren erneutes Auftreten zu unterbinden.
Problem Management tritt in Erscheinung, wenn Incidents zu einem Sachverhalt gehäuft auftreten. Dies geschieht auch, wenn der Incident durch einen Workaround geklärt wird, die Ursache der Störung aber (noch) nicht ermittelt ist. Die Behebung kann langwierig sein.

Problems werden i.d.R. im Second Level Support bearbeitet, Die abschießende Bearbeitung der Incidents liegt im First Level Support.

Die Trennung von sofortiger Abhilfe durch Incident-Management schafft Transparenz in die Arbeit der IT-Organisation. Die langfristige Stabilisierung der IT-Infrastruktur durch das Problem-Management sorgt ebenfalls für Klarheit. Sie ermöglicht es dem First Level Support, sich voll und ganz auf die kundennahen Aufgaben zu konzentrieren.

Problem Management arbeitet immer auf eine nachhaltige Lösung zu. In der Regel werden die Lösungen durch einen Change begleitet, da sie Eingriffe in den laufenden Betrieb .

Change Management

Keine Änderung an der produktiven Umgebung ohne Change!
Change Management ist die ultimative Hilfe zur störungsfreien Einführung und Änderung von Services im laufenden Betrieb. Die verbindliche inhaltliche und zeitliche Abstimmung mit allen betroffenen Stakeholdern bringt die notwendige Sicherheit für den Betrieb der Services.

Requirements Management

Requirements- Management ist die Unterstützung der systematischen Erfassung, Analyse und Aufbereitung von Anforderungen an ein System mit Methoden und Tools. Requirements-Management entwickelt die Methoden und Tools. Diese werden genutzt, um eindeutige, verständliche und verlässliche Anforderungen zu definieren. Sie gewährleisten auch deren Berücksichtigung im Lösungsdesign. Folgende Ziele sind für das Requirements- Management gesetzt.

  1. Aufwände transparent darstellen
  2. Auftragsbearbeitung beschleunigen
  3. Hohen Automationsgrad ermöglichen
  4. Fehlerbehebungsaufwände minimieren
  5. Kundenvertrauen aufbauen
  6. Erfolg messbar machen

Die oben genannten Ziele werden durch folgende Aufgaben unterstützt.

  • Reporting
  • Entwicklung / Weiterentwicklung der Requirements- Engineering Strategie.
  • Festschreibung von Definitionen.
  • Entwicklung, Verbesserung und Bereitstellung von Methoden und Tools.
  • Schulungen vorbereiten und durchführen.
  • Unterstützung des Requirements Engineers bei komplexen Aufträgen.

Service Katalog

Die oben angegebenen Services lassen sich nicht einführen, ohne die Leistungen der IT-Organisation in einem Service Katalog zu beschreiben. Es ist möglich, Incident- und Service-Request, Problem- und Change- Management auch ohne einen Service Katalog zu etablieren. Dies gilt für aber nur für kleine IT Organisationen. Dann fehlt die Auswertungs- und die strategische Steuerungsmöglichkeit die sich aus den gewonnenen Informationen ergeben.

Fazit

Ich möchte es an dieser Stelle nochmal betonen: die beschriebenen Maßnahmen stellen das absolute Minimum dar. Mehr geht immer. Sie bilden auch nicht sklavisch ITIL ab, sondern orientieren sich daran.
Es schafft das Organisations- Chaos ab und bringt Ruhe und Verlässlichkeit in der IT-Organisation. Am Ende wird die Leistung der IT signifikant steigen, ohne große personelle Veränderungen durchführen zu müssen.

weitere Links

Management- Landkarte Teil2: technische Methoden

Management – Landkarte Teil3: Big Picture

Office 365, Azure und die barrierefreie Nutzung in einer hybriden Umgebung

Eine Antwort

Eines der zentralen technologischen Themen heute und in den kommenden Jahre ist die sichere Nutzung von cloud- basierenden und lokal installierten Tools.

Insbesondere in Microsoft dominierten Umgebungen (wie in den meisten Unternehmen dieser Erde) ist das Thema mit Office 365 und Azure in den Focus gerückt. Aus Sicht der IT will man dem Benutzer eine möglichst einfache Anmeldung gestalten, ohne dabei die primären Schutzziele Verfügbarkeit, Vertraulichkeit und Integrität einer Unternehmens- Infrastruktur zu vernachlässigen.

So ist das Verständniss für Authentifizierung („Wer bist Du?“) und Autorisierung („Was darfst Du?“) wichtiger den je.

Um etwas mehr Transparenz in das Thema Authentifizierung und Autorisierung gerade Microsoft- Infrastruktur Umgebungen zu bringen, habe ich ein paar neue Seiten zum Thema hier veröffentlicht.

Zunächst habe ich mich auf die Microsoft- Umgebungen beschränkt. Es folgen aber in nächster Zeit weitere allgemeine Artikel zu Authentifizierung und Autorisierung.

Die Beiträge sind unter http://wolfgangmeisen.de/it-architektur-themen/anmeldeverfahren-aus-der-microsoft-welt/ zu finden.

Werte Kolleginnen und Kollegen

Schreibe eine Antwort

Ich freue mich über Ihren Besuch.

Auf dieser Seite stelle ich Ihnen Informationen, Meinungen sowie Erfahrungen zu Management- Themen in der IT bereit.

Gerne sind Sie eingeladen, mit seriösen zuverlässigen und nachvollziehbaren Beiträgen zu Wachstum der Präsenz beizutragen. Dabei freue ich mich über eine Sprache, die die teils trockenen Themen auflockert.

Ich wünsche Ihnen viel Spaß beim Lesen und Kommentieren. Hinterfragen Sie die Aussagen und lassen Sie mich und andere Besucher an Ihrer Meinung und Erfahrung teilhaben.