Archiv des Autors: wmeisen

Sicheres Active Directory: Welche Mindeststandards sind unbedingt einzuhalten

Die Identitäten, also alle Benutzerkonten, die in einem Unternehmen zur Erreichung des Geschäftszieles notwendig sind, müssen besonders geschützt werden. Denn sie sind primäres Ziel der Cyber-Angriffe.

Sie sind auch Ziel interner, nicht autorisierter Maßnahmen wie z.B. das Ausspähen von Geschäftsgeheimnissen und der unkontrollierte Abfluss von strategischen und operativen Daten von Mitarbeitern.

Leider sind die Schutzmaßnahmen der IT-Organisationen i.d.R. sehr begrenzt. Sie orientieren sich meist an Software-Schwachstellen und rudimentär vorhandenen Prozessen.

Einen umfassenden Schutz erreicht man aber nur, wenn man Architekturthemen wie die Anpassung der Authentifizierungs- und Autorisierungs- Infrastruktur und deren Prozesse an die aktuellen Herausforderungen in die Betrachtung aufnimmt.

In dem nachfolgenden Artikel erkläre ich, auf welche Punkte es dabei aus meiner Sicht ankommt.

Grundlage der Betrachtungen ist das Microsoft Active Directory (ADDS), das in dem weitaus größten Teil der Unternehmen als Identitätsdatenspeicher zum Einsatz kommt. Darüber hinaus werden Technologien, die in der Cloud – Welt ihren Anfang nahmen und für den sicheren Betrieb notwendig sind (ADFS / Entra-ID, SAML, Oauth etc.) einbezogen.

ADDS ist im größten Teil der Unternehmen das zentrale Tool für Authentifizierung und Autorisierung und damit ein zentraler Sicherheits-Bestandteil dieser Unternehmen. Deshalb ist es sinnvoll sich an folgenden Prämissen zu halten. Die Prämissen sind in drei thematische Blöcke zusammengefasst.

Sichere Identitätsverwaltung

  • Es gibt nur einen Ort zur Verwaltung von Unternehmens- Identitäten
  • Rollen und Berechtigungen sind strikt zu trennen
  • Die Administration von Infrastruktur und Fachanwendungen ist stets streng von der Bürokommunikation zu trennen.
  • Der Status des AD muss jederzeit transparent und nachvollziehbar sein.

Authentifizierung und Autorisierung

  • Direkter Zugriff auf das Active Directory ist nicht zulässig
  • Anzahl der Anmeldungen / Passwörter ist auf ein Minimum zu reduzieren
  • Service Accounts sind besonders zu schützen
  • Die Identität muss bei der Authentifizierung überprüfbar sein.

Generelle Sicherheit der Infrastruktur

  • Ein einzelnes ADDS Objekt muss wiederhergestellt werden können
  • Das Active Directory und die Umsysteme müssen schnell reinstalliert werden können.
  • Die Produktionsumgebung darf nicht ohne Change Prozess verändert werden
  • Kerberos – Kommunikation ist auf ein Mindestmaß zu reduzieren.
  • Alle Kommunikationsverbindungen sind verschlüsselt
  • Alle Computer sind durch Zertifikate identifizierbar

Sichere

Identitätsverwaltung

Prämisse: Es gibt nur einen Ort zur Verwaltung von Unternehmens- Identitäten

Alle Identitäten im Unternehmen sind zentral in einem Repository – Active Directory – zu verwalten, damit zu jedem Zeitpunkt der Einfluss auf jede Identität gewährleistet ist.

Unter Identitäten versteht man alle Konten, die notwendig sind, um den Betrieb der Unternehmens- Infrastruktur zu gewährleisten.

Eine transparente Verwaltung aller Identitäten ist nur möglich, wenn die Hoheit über die Konten in einer Hand liegen. Dazu ist eine zentrale Verwaltung unabdingbar.

Maßnahme: Alle Endgeräte sind Mitglied der Active Directory Domäne

Damit die Berechtigungen für die Maschine und der darauf laufenden Dienste verwaltet werden können, sind die zugehörenden Service Accounts im Active Directory verortet. Lokale administrative Konten sind ein Einfallstor für Angreifer. Da sie i.d.R. nicht genutzt werden, sind diese Build-In lokal Accounts disabled.

Damit der Server oder der Client verwaltet werden kann, muss er zwingend Mitglied des der Domäne sein.

Maßnahme: Alle Identitäten werden zentral gepflegt. Es gibt keine operativen lokale Accounts auf Servern und anderen Endgeräten.

Diese Prämisse ist unbedingt einzuhalten. Deshalb ist es sinnvoll, die lokalen Benutzerverwaltungen zu überwachen.

Das gilt auch für „hybride Identitäten“, wie sie in Verbindung mit Cloud Anwendungen wie M365 und Azure auftreten.

Prämisse: Rollen und Berechtigungen sind strikt zu trennen

In vielen Fällen wird zu Berechtigung eines Mitarbeiters in einer Fachanwendung direkt zugeteilt. Das wird dann über den Benutzernamen und einer teils sehr granularen Berechtigungsvergabe erledigt. Das funktioniert erstmal, hat aber entscheidende Nachteile: 

  • Der manuelle Aufwand ist sehr hoch, da die Berechtigungsvergabe sehr kleinteilig ist.
  • Es bedarf tiefgehender Kenntnisse der Berechtigungsvergabe für die Fachanwendung, d.h. jede Anpassung, Neuanlage etc. muss durch den Fachanwendungs- Administrator durchgeführt werden.
  • Das es ein manueller Vorgang ist, werden sich mit der Zeit Fehler und Abweichungen ergeben. Auch gewollte Abweichungen entstehen auf diese Weise.
  • In der Folge entsteht eine nicht durchschaubare Berechtigungsstruktur, die im schlechtesten Fall Einstiegsmöglichkeiten für Angreifer bietet.

Die Berechtigung auf Funktionen einer Anwendung muss primär im ADDS über Berechtigungsgruppen durchgeführt werden. Berechtigungsgruppen, die thematisch zusammengehören, werden einer Rolle zugewiesen. Die Vergabe an Personen wird durch Rollen durchgeführt.

Niemals wird eine Berechtigung einer Identität direkt zugewiesen !

RBAC – schematische Darstellung via ADDS -und Entra ID

RBAC

RBAC (role based access control) ist die Methode, die die Berechtigungsvergabe aufgrund der Rollenzugehörigkeit eines Mitarbeiters regelt. Eine Rolle kann beispielsweise die Zugehörigkeit zu einem Fachbereich, einer Abteilung oder einem Arbeitsbereich sein.

„AGDLP“ ist die technische Umsetzung von RBAC im Active Directory. AGDLP bedeutet:

A Accountdas Active Directory Konto der Identität / Mitarbeiters
GGlobale GruppeArchitekturelement im AD. Diese Gruppe stellt die Rolle (Abteilung, Arbeitsbereich etc.) dar.
DL(Domain) Lokale GruppeDiese Gruppe stellt die Berechtigung dar, eine Ressource innerhalb des Institutes zu nutzen
PPermissionBerechtigung: beschreibt das Recht, eine Ressource zu nutzen wie  Nutzung als Mitarbeiter einer Anwendung, oder Nutzung der Dateiablage oder ….

Namenskonventionen, Gruppentypen und Verschachtelungsstrategien werden empfohlen, um die Berechtigungsverwaltung zu optimieren.

Prämisse: Die Administration von Infrastruktur und Fachanwendungen ist stets streng von der Bürokommunikation zu trennen.

Lösung: PAM – Privileged Access Management

Alle Maßnahmen der Verwaltung von erweiterten Rechten werden unter dem Begriff „Privleged Access Management“ PAM zusammengefasst.

Maßnahme: PAW – Privileged Access Workplace

Virtuelle Workplaces, die auf administrative Aufgaben ausgerichtet sind, einzurichten. Sie haben keinen Bezug zur allgemeinen Kommunikation des Unternehmens. Sie sind in eigenen Sicherheitszonen verortet. Diese Sicherheitszonen sind nur per Jump-Server, der in der gleichen Zone wir die PAW steht, zu erreichen.

Maßnahme: PAA – Privileged Access Accounts

Wird ein Mitarbeiter Administrator einer Anwendung oder Komponenten in der Infrastruktur, erhält er für diese Aufgabe ein zusätzliches Konto mit erweiterten Rechten zur Erfüllung seiner Aufgabe.

Der Account eines Mitarbeiters hat niemals erweiterte, administrative Rechte.
Erweiterte Rechte werden ausschließlich an „privileged access account“ PAA vergeben. PAA’s sind immer nur für einen Security Level zulässig. Der Zugriff mit einem PAA aus einem niederwertigen Level auf ein Level mit höherem Schutzbedarf ist nicht zulässig.

Enterprise Access Management (EAM)

PAA’s für Enterprise- und Domänen- sowie Datenbank- Administratoren sind sehr stark limitiert. (z.B. maximal drei Personen im Unternehmen sowie Vertreter).
Die Benutzung der PAA dieser Administratoren wird immer überwacht. Das sind Teile des EAM. Die Themen des EAM werden an anderer Stelle beleuchtet.

Prämisse: Der Status des AD muss jederzeit transparent und nachvollziehbar sein.

Objekte im Active Directory, die nicht genutzt werden oder niemandem gehören, stellen eine potentielle Gefahr dar. Wenn diese leicht zu identifizierenden Objekte und unautorisierte Personen genutzt werden, fällt das in der klassischen Umgebung erstmal nicht auf. Nur kann dann schon der Schaden entstanden sin. Aus diesem Grund sind sie unbedingt zu vermeiden.

Maßnahme: Vermeidung von Leichen und Aliens im AD

  • Monitoring und Reporting am besten Tag- genau.
  • Jedes Objekt im AD hat eine definierte Aufgabe
  • Jedes Objekt im AD muss nachvollziehbar dokumentiert sein.
  • Jedes nicht mehr genutzte Objekt im AD muss unverzüglich entfernt werden.

Authentifizierung &

Autorisierung

Prämisse: Direkter Zugriff auf das Active Directory ist nicht zulässig

Der direkte Zugriff durch Anwendungen (z.B. über die Protokolle Kerberos und LDAPs ) oder die direkte Manipulation durch Administratoren sind Schwachstellen in der Architektur. Dier Schwachstellen können geheilt werden, wenn es keinen direkten Zugriff auf das Active Directory gibt.

Ausnahmen sind Enterprise- und Domänen-Administratoren zur Wartung sowie Eruierung und Behebung von Fehlern.

Maßnahme: Definition der Authentifizierungs- Zugriffswege

Named User müssen da, wo es möglich ist, über berührungslose Authentifizierungsverfahren wie SAML oder oAuth Authentifiziert werden.
Kerberos ist nur bedingt zulässig. (wenn kein höherwertiges Protokoll einsetzbar ist.)

Maßnahme: Change Management & Automatisierung

Änderungen an allen ADDS Objekten sind zu autorisieren und zu überwachen.

Alle Assets (Server, Clients, Drucker, aktive Komponenten) im Unternehmen sind mit dem ADDS über entsprechende Accounts verbunden.

Änderungen an allen ADDS Objekten (in der Produktionsumgebung) werden immer automatisiert durchgeführt. Der manuelle Eingriff ist im Betrieb strikt verboten.

Prämisse: Anzahl der Anmeldungen / Passwörter ist auf ein Minimum zu reduzieren

Named User haben es meist mit einer größeren zweistelligen Anzahl von Accounts zu tun, die sie für Ihre Arbeit benötigen. Das führt zu unsicheren und mehrfach genutzten Passwörtern. SSO ist hier eine Hilfe, diese Flut einzudämmen und Gefahren zu vermeiden.

Maßnahmen: SSO & VAULT & Identity Trust

  • Einführung von SSO wo möglich und sinnvoll.
  • Einführung eines Passwort Management Systems (Vault) für alle notwendigen Passwörter.
  • Einführung von Identity Trusts zwischen einem Identity Provider im Unternehmen und dem Service Anbieter im Internet. Damit entfallen Anmeldungen an Cloud Services, die im Unternehmen allgemein zur Verfügung stehen.

Prämisse: Service Accounts sind besonders zu schützen.

Service Accounts werden im Betrieb nicht durch Mitarbeiter genutzt. Sie dienen im Verborgenden  der Authentifizierung und Autorisierung von automatischen Prozessen. Damit sind sie i.d.R. aus dem Focus der täglichen Arbeit. Das prädestiniert sie als Angriffsziel.

Maßnahmen: Verantwortliche, Passwort Generierung und Password Vault

  • Service Accounts haben immer einen Verantwortlichen im Unternehmen.
  • Service Account Passwörter sind zu generieren und in einem Vault (virtueller Tresor) zu hinterlegen.
  • Service Account Passwörter sind nach X Tagen automatisch zu ändern. Sie sind nur den korrespondierenden Systemen bekannt.

Prämisse: Die Identität muss bei der Authentifizierung überprüfbar sein.

Der Identitätsdiebstahl ist einer der gängigen bekannten Methoden, unautorisierten Zugriff auf Inhalte der Unternehmensinfrastruktur zu erlangen. Hier muss sichergestellt werden, das tatsächlich die Person Zugang bekommt, die nach der Identität auch Zugang erhalten soll.

Maßnahme: Mehr-Faktor-Authentifizierung

Eine Mehr-Faktor Authentifizierung ist mindestens an den Stellen, an denen ein Security Level verlassen wird, notwendig.

Maßnahme: Benutzerzertifikate

Das Benutzerzertifikat stellt sicher, dass die Identität zum Unternehmen gehört.

Generelle Sicherheit der Infrastruktur

Prämisse: Ein einzelnes Objekt muss wiederhergestellt werden können.

Backup und Restorte auf Objektebene sind zwingend. Da gibt es keine Diskussion.

Prämisse: Das Active Directory muss mit dem aktuellen Stand schnell reinstalliert werden können.

Für den Katastrophenfall muss es einen Wiederanlaufplan geben, der u.a. die erneute Bereitstellung des AD innerhalb kürzester Zeit ermöglicht. Die Wiederherstellung sollte im Stundenbereich liegen. Sie muss in regelmäßigen Abständen getestet werden.

Prämisse: Die Produktionsumgebung darf nicht ohne Change Prozess verändert werden.

Änderungen an der Produktionsumgebung können nur im Rahmen eine regulären Change Prozesses durchgeführt werden. Das hat den Vorteil, das zum einen alle Stakeholder in den Change involviert sind, zum, anderen die notwendigen Maßnahmen zur sicheren und nachvollziehbaren Änderung getroffen wurden.

Das schieß ad-hoc Änderungen, wie sie für Entwicklung und Test notwendig sind strikt aus.

Maßnahme. Staging

  • Für jeden Stage gibt es ein ADDS, eigenes ADCS und ADFS. So können Entwicklungs- und Testaufgaben bis zur Produktionsreife gebracht werden, ohne das ADDS In der Produktion zu kompromittieren.
  • Es sollte mindestens zwei Stages geben: Test & Entwicklung in einem Stage sowie Produktion. Je nach Größe des Unternehmens und dem betriebenen Entwicklungsaufwand sind drei Stages ideal: Entwicklung, Test, Produktion.

Prämisse: Kerberos – Kommunikation ist auf ein Mindestmaß zu reduzieren.

Auf das Kerberos-Protokoll gab es in der Vergangenheit verschiedene erfolgreiche Angriffe, die bei vorausschauender Architektur nicht erfolgreich gewesen wären. Deshalb ist es nicht per se abzulehnen, mit Kerberos zu arbeiten.

Zudem lässt sich Kerberos – Nutzung nicht vollständig verhindern. Man denke nur an die Maschinen Authentifizierung an das ADDS.

Maßnahme: SAML & oAuth & …..

Kerberos sollte so weit als möglich durch berührungslose Authentifizierungsverfahren ersetzt werden. Insbesondere gilt das für den Übergang von einem niederwertigen in einen höheren Security Level.

Prämisse: Alle Kommunikationsverbindungen sind verschlüsselt.

Damit Informationen nicht durch „Man in the Middle“ Attacken kompromittiert werden kann, ist jegliche Kommunikation zu verschlüsseln.

Maßnahme: Prüfen und Einführen von TLS 1.3

Active Directory verschlüsselt automatisch die Kerberos Kommunikation. Alle weiteren Systeme wie Identity Provider oder die CA sind auf verschlüsselte Kommunikation zu prüfen und ggfls. anzuheben.

Prämisse: Alle Computer sind durch Zertifikate identifizierbar

Voraussetzung für viele Prämissen ist ein gültiges, durch eine CA signiertes Maschinenzertifikat.

Maßnahme: Alle Computer werden automatisch mit einen gültigen Maschinenzertifikat ausgestattet.

Die Zertifikatsstelle (Certificate Authority) ist dabei auf jeden Fall on-Premise zu verorten. Die Maschinen- Zertifikate sind in zu bestimmenden Abständen automatisch zu aktualisieren. Das kann über verschiedene Wege erfolgen: Autoenrollment via ADDS oder über das ACME Protokoll. Das Thema Zertifikatsverwaltung ist aber so komplex, dass es dazu einen eigenen Artikel braucht.

Management- Landkarte Teil2: technische Methoden

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

Beispiel:
Wenn man als Autorisierungsinstanz Microsoft Active Directory und Oracle LDAP Server gleichermaßen einsetzt, führt das auch bei stringentem Einsatz von Richtlinien auf beiden Seiten (über kurz oder lang) zu Abweichungen in den Berechtigungen und in den genutzten Accounts. Strukturelle Sicherheitslücken sind eine Folge. 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. (Quelle:

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. Dabei wird mit verschiedenen Methoden versucht, an Identitäten im Unternehmen zu kommen und mit deren Hilfe weitere Identitäten mit höheren Rechten zu erlangen.
  • Enterprise Access Management
    Ein wichtiger Bestandteil User Life Cycle Managements ist die Sorge um Konten, die erhöhte Rechte bis hin zur Enterprise Administration, haben. Sie sind eins der eigentlichen Angriffsziele von Hackern. Deshalb ist konsequente Betrachtung von Authentifizierung und Autorisierung genau so wichtig 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.
  • 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, die immer wieder in jeglicher Software auftreten, sondern 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 Scripte, die der Automation dienen, mit einem Zertifikat zu signieren.
  • Aufbau der IT-Infrastruktur nach Security Levels
    Security-Levels bilden die Vertrauenswürdigkeit eines Netzwerkes je VLAN ab. Je höher der Security-Level ist, desto vertrauenswürdiger ist sie. Hohe Security-Levels haben per Default Zugriff auf niedrige Security-Zonen, andersrum wird der Zugriff verwehrt. Kommunikation zwischen Zonen desselben Security-Level werden per Default geblockt.

Folgende Security- Level bilden aus meiner Sicht das Minimum:

  • DATA (Level 5)
    DATA ist mit der höchsten Vertraulichkeitsstufe belegt. Hier werden alle strukturierten und unstrukturierten Daten (Datenbanken, Datei), das Active Directory und die Zertifikatsserver. Darüber hinaus sind Backup- , Deployment- und Automationsumgebungen in diesem Level, aber technisch getrennt unterzubringen.
    Alle Systeme in dieser Zone sind existentiell für das Unternehmen.
  • APPLICATION (Level 4)
    Im Security Level APPLICATION sind die Applikationsserver und Web- Frontends zu finden, mit denen ein interner Mitarbeiter kommuniziert. Diese Applikationsserver kommunizieren wiederum mit den Datenbankservern in DATA (Multi-Tier-Anwendungen)
    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 gilt jedoch, sich vor den Gefahren die durch das Internet bis in das Unternehmen getragen werden können, umfangreich und permanent zu schützen.
  • Staging
    In den Anfängen der IT hieß es „Never touch a runnnig system!“ Daas gilt in abgewandelter Form auch heute noch:

    „Never touch a prodution system without a Change“

    Das bedeutet, das jegliche Entwicklung und Test aus dem Produktionsnetzwerk verbannt werden muss, um 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.

Management- Landkarte Teil1: organisatorische Methoden

IT – Organisation benötigen – wie jede andere Organisation auch – verlässliche, transparente und messbare Management- Methoden, die 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 Service Management- Methoden zum Einsatz. Ich beschreibe hier das Minimum 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 sind die nachfolgenden Services aus „Service Operation“ und „Service Strategy“ mit der höchsten Dringlichkeit einzuführen. 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 über Workarounds) und 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 trifft dann in Erscheinung, wenn Incidents zu einem Sachverhalt gehäuft auftreten und / oder wenn der Incident durch einen Workaround geklärt, die Ursache der Störung aber (noch) nicht ermittelt und die Behebung langwierig sein kann.

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 und langfristiger Stabilisierung der IT-Infrastruktur durch das Problem-Management bringt Transparenz in die Arbeit der IT-Organisation. 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, um eindeutige, verständliche und verlässliche Anforderungen zu definieren und deren Berücksichtigung im Lösungsdesign zu kontrollieren. 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
Wenn man die oben angegebenen Services einführen will, kommt man nicht umhin, die Leistungen der IT-Organisation in einem Service Katalog zu beschreiben. Es ist zwar möglich, Incident / Service Request , Problem- und Change Management (in kleinen IT Organisationen) ohne einen Service Katalog zu etablieren. Dann fehlt aber die Auswertungs- und die strategische Steuerungsmöglichkeit die sich aud den gewonnenen Informationen ergeben.
Wie man einen Service Katalog aufstellt, kann in den einschlägigen

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.

Prämissen

Eine Prämisse ist eine grundlegende Bedingung, die als Ausgangspunkt für Argumente, Schlussfolgerungen oder Entscheidungen dient. Sie bildet das Fundament für rationale Überlegungen und beeinflusst maßgeblich die Stichhaltigkeit eines Arguments. Prämissen sind in verschiedenen Bereichen wie Philosophie, Wissenschaft und Alltagsentscheidungen von großer Bedeutung.“ (Zitat aus www.BachelorPrint.de)

Wenn ich das in meine Sprache übersetzte, dann sind die nachfolgenden Prämissen das Grundgesetz einer IT-Organisation.

Vorweg: Was bedeutet……

Infrastruktur: beschreibt alle aktiven Komponenten einer Umgebung (on-Premises und Cloud) in Ihrer Gesamtheit. Dazu zählen Netzwerk-Komponenten, Server/Services, Nutzer, Gateways und Firewall-Komponenten. Weiterhin zählen auch alle Benutzergruppen dazu.

Entwickler: In der Infrastruktur sind keine typischen Software Entwickler. Sie setzen aus vorhandenen Methoden und zugekauften Softwareprodukten und Dienstleistungen neue Lösungen anhand der Anforderungen zusammen.

ITSM: IT-Service-Management (ITSM) bezeichnet die Gesamtheit von Maßnahmen und Methoden, die nötig sind, um die bestmögliche Unterstützung von Geschäftsprozessen durch die IT zu gewährleisten ITSM beschreibt Informationstechnik mit dem Focus auf Kunden- und Serviceorientierung. Dazu ist eigentlich genug geschrieben. Ich verweise gerne auf die einschlägige Literatur.

Requirements- Engineering: beschreibt den iterativen Vorgang aus unspezifischen und ungerichteten Erwartungshaltungen spezifische, gerichtete und Abgestimmte Geschäftsanforderungen zu erzeugen.

Genug der Vorrede, jetzt gehts los……

§1 Bewerte die Unternehmensdaten

Die Kernkompetenzen des Unternehmens schlagen sich in den Daten, die tagtäglich produziert werden, nieder. Diese Daten (Kundendaten, Produktionsdaten, Ergebnisse aus Forschung und Entwicklung etc.) dienen nicht nur dem operativen Geschäft, sondern sind Grundlage für alle Aktionen, die das Unternehmen prosperieren lassen und die erzielten Erfolge absichern. Sie sind damit auch Grundlage strategischer Entscheidungen. Außerdem werden mit Ihnen regulatorische Anforderungen erfüllt.

Diese Daten haben einen bestimmten Wert, der zu ermitteln ist. Darüber hinaus muss auch Bewertet werden, welche Schäden entstehen, wenn diese Daten nicht zur Verfügung stehen (Impact)
Beispiele: Für die Herstellung von Daten wurde Arbeitszeit, für die Software, die diese Daten hält wurde Hard- und Software angeschafft und konfektioniert, sowie betrieben. Es lassen sich also Rückschlüsse auf den Wert der Widerherstellung der Daten ziehen.
Fällt eine Datenpool für den operativen Einsatz aus, kann anhand der nicht leistbaren Arbeit festgestellt werden, welcher Schaden dabei entsteht. Eine Grundlage für die Schadensbemessung sind Ausfallzeiten (1h, 4 h, 1Tag 5Tage etc.) oder der Totalausfall mit Neuaufbau der Daten.

§2 Arbeite anhand von (geschäftlichen) Anforderungen

Die Geschäftsführung wie viele Menschen aus den Fachbereichen der Unternehmen machen sich Gedanken zur Weiterentwicklung des Unternehmens. Dabei werden im Idealfall Erwartungshaltungen an die die IT formuliert, die sie in Bits und Bytes umsetzen soll. Diese Erwartungshaltungen sind in der Regel ungerichtet und unspezifiziert. Die Aufgabe ist es nun, diese Erwartungshaltung aufzunehmen und in gerichtete und spezifische Anforderungen (Requirements) umzusetzen. Das ist sicherlich ein harter Weg, der aber bei konsequenter Verfolgung immer zum Ziel und damit zum Erfolg führt.

§3 Kenne alle Stakeholder

Stakeholder sind Personen, die unmittelbar oder mittelbar von einer Aufgabe betroffen und / oder an der Anforderungs- Ermittlung (Requirements- Engineering) beteiligt sind.

Es ist für die Qualität der Anforderungen und den Erfolg einer Aufgabe wichtig, direkte Beziehungen zu den Stakeholdern aufzubauen. Die Übermittlung von Informationen über mehrere Personen, Personenkreise und Institutionen sollte unbedingt vermieden werden.

§4 Definiere eindeutige Ziele

Die Zieldefinition bildet eine künftige zu erreichende Situation des Kunden ab. Somit gehören die Ziele dem Kunden. Ziele sollten im Idealfall vom Kunden formuliert werden. Falls das nicht der Fall ist, müssen die Ziele gemeinsam mit dem Kunden erarbeitet werden. Sie sind unbedingter Teil der Requirements- Engineerings.

Ziele sind:

  • spezifisch
  • messbar
  • akzeptiert
  • realistisch
  • terminiert

    Darüber hinaus sind Ziele immer lösungsneutral formuliert.

§5 Beachte alle Rahmenbedingungen

Wie die Ziele sind die Rahmenbedingungen elementarer Bestandteil des Requirements- Engineerings. Sie bestimmen gemeinsam mit den Zielen und den Requirements den Lösungsraum für den Auftrag.
Rahmenbedingungen können nur unter erheblichen Aufwand oder gar nicht geändert werden. Die Einordnung von Rahmenbedingungen ergibt sich aus ihrem Ursprung. Rahmenbedingungen sind u.a.

  • Gesetzte und Verordnungen (NIS2, KRITIS, DS-GVO etc.)
  • Compliance-Vorgaben
  • Standorte
  • bereits eingesetzte Technologien und Methoden
  • organisatorische Methoden (z.B. ITSM)
  • etc.

§6 Etabliere Kunden-Sensibilität in der IT

Jeder Mitarbeiter außerhalb der IT ist ein Kunde! Wenn das IT-Mitarbeiter verinnerlichen, entsteht (mit der Zeit) ein deutlich verbessertes Verhältnis zwischen den Mitarbeitern der IT und allen anderen Mitarbeitern. Das bessere Verhältnis wird bestimmt von der Kundensicht der IT – Mitarbeiter (Was kann ich tun, damit Du Deinen Job gut machen kannst) und der Mitwirkungspflicht des Kunden ((Was muss Du tun, damit ich meinen Job gut machen kann).

Das ist kein Punkt, der unmittelbar mit der IT-Sicherheit zusammenhängt. Wenn aber dieser Punkt erfüllt wird, werden die Mitarbeiter den Vorgaben der IT eher und nachhaltiger folgen.

§7 Tu was Du sagt und sag was Du tust

Transparenz in den Handlungen der IT für alle Stakeholder ist existentiell für die Akzeptanz Eueres Handelns . Das Bringt die notwendige Transparenz. Verlässlichkeit ist ein weiteres wichtiges Attribut der IT. Das heißt nicht, das nicht auch was schief gehen kann. Nur muss man dann schnell aufklären und einen ehrlichen Lösungsweg skizieren. Auch dieser Punkt zahlt mittelbar auf die Sicherheit ein.

§8 Halte Dich an Standards

Technologische und organisatorische Standards vereinfachen die Entwicklung und den Betrieb einer Infrastruktur enorm. Weitere Vorteile:

  • Einfacher Betrieb von Hard- und Softwarekomponenten
  • Der notwendige Skill ist am Markt in der Regel verfügbar
  • Standards müssen nicht mehr dokumentiert werden, es reichen Referenzen
  • Interaktion mit anderen Softwarekomponenten ist einfacher oder wird erst ermöglicht.
  • Standardisiere Prozesse stützen sich auf eine breite Wissensbasis. So werden sie einfacher eingeführt und weiterentwickelt.
  • Standards ermöglichen erst die sinnvolle Automatisierung von Abläufen

§9 Halte die Menge der eingesetzten Tools klein

Es ist nicht sinnvoll, für jede Aufgabe ein vordergründig exakt passendes Tool einzusetzen, da man damit die Wissensbreite unverhältnismäßig aufbläht. Das Team kann dann nur oberflächlich mit den Tools arbeiten. Es ist viel besser, die Toolbasis strategisch zu planen und die Fach-Applikation darauf abzustimmen. Vorteile:

  • eingeschränkte Angriffsmöglichkeiten
  • Breite Wissensbasis in der Organisation
  • stabilerer Betrieb
  • Einfachere Automatisierung

§10 Konzentriere Dich auf die wirklich notwendigen Methoden

Die Aufgaben der Entwickler, Administratoren uns Support Mitarbeiter sollen nicht von administrativen und organisatorischen Aufgaben von Ihren Kernaufgaben behindert werden. Außerdem sollen Sie bereits erarbeitete Technologien und Methoden einfach wiederverwenden können.
Deshalb ist es wichtig, die in der IT Organisation eingesetzten Methoden zu konzentrieren und vorhandene technische Methoden so aufzubereiten, das sie einfach einzusetzen sind.

Wichtige technologische Methoden (Auszug)

  • Zero Trust Architektur (Security Levels & Security Zonen)
  • Beschränkung auf notwendige Kommunikationsverbindungen (Kommunikationsmatrix)
  • Authentifizierung und Autorisierung
  • Identity Access Management
  • Enterprise Access Management
  • Certification Management
  • Focus auf Multi Tier Applikationen (mindestens bei den strategischen Anwendungen)
  • Staging
  • ……

Wichtige organisatorische Methoden (Auszug)

  • Incident-Management
  • Problem-Management
  • Change-Management
  • Reqirements-Management

§11 Kenne Deine eingesetzten Tools in- und auswendig

Es ist sinnvoll, für jedes eingesetzte Tool einen Product- Owner zu benennen. Er ist der Mastermind für das Tool und die und kann Hilfestellung bei den eingesetzten Methoden geben. Er bildet sich weiter und gibt das erworbene Wissen an seine Kollegen.
Auch bestimmt er in Absprache mit den Stakeholdern , wie das Tool in welchen Szenarien eingesetzt wird. Product- Owner steuert verantwortlich die Pflege gemeinsam mit dem Release-Management und dem Vulnerability-Management.
Übrigens: Ein Product- Owner für jedes Produkt hält die Menge der Tools klein -:).

§12 Schütze alle Identitäten und Traue niemanden

Named-User-Identity
Neben den Daten des Unternehmens sind die Identitäten der zweite große schützenswerte Information im Unternehmen. Sie bilden die Legitimation zur Infrastrukturnutzung für die Mitarbeiter(Named-User-Accounts) und zur Beschränkung der Zugriffsrechte in der täglichen Arbeit auf das wirklich notwendige Maß.

Service-Identity
Es gibt aber in jedem Unternehmen Identitäten, die nicht durch Mitarbeiter aktiv genutzt werden, Sie werden in der Regel zur Authentifizierung automatisierter Aufgaben zwischen zwei Software- Komponenten eingesetzt (Service-Accounts).

Privileged Access Identity
Für Administrationszwecke sind sog. „Privileged Access Accounts“, also Konten mit erhöhten Rechten etabliert. Sie dienen Administratoren zur Wartung und Pflege der eingesetzten Systeme und Tools. Es ist unabdingbar, entsprechende Konzepte (Enterprise Access Management) zu entwickeln und strikt umzusetzen

Computer Identity
Ein weitere Gruppe – und nicht die letzte – sind die Maschinen-Accounts, die zur Authentifizierung von zugelassenen Computern notwendig sind.

Alle Identitäten sind auf unterschiedliche Weise sehr hohen Bedrohungen von außen und innen ausgesetzt. Somit ist die Absicherung durch sicheren architektonischen Aufbau der Infrastruktur, Einhaltung von Sicherheitsvorgaben, und konsequente Überwachung existentiell für den sicheren Betrieb.

Zero Trust
„Zero Trust“ gehört aus meiner Sicht als zentrales Element hier erwähnt. Es soll auf alle Bereiche der IT-Infrastruktur und nicht nur auf Identitäten angewandt werden.

§13 Automatisiere so weit als möglich

Alle Aufgaben die sich als Standard- Aufgaben identifiziert sind, sollten automatisiert werden. Darüber hinaus sind Aufgaben zur Überwachung der Infrastruktur zu automatisieren. Der dritte große Block sind periodisch anfallende Aufgaben, die in den Fachbereichen automatisiert werden können.

Vorteile:
Automation entbindet das Team von Routineaufgaben und stellt Kapazitäten zur Weiterentwicklung der Infrastruktur und des Teams frei.

Alle automatisierten Jobs werden immer in der gleichen Qualität durchgeführt. Sie sind damit – auf positive Weise – berechenbar und verlässlich.

§14 Dokumentiere und überprüfe (regelmäßig) die Dokumentation

Dokumentation ist kein Selbstzweck, sondern dient verschiedenen Ansprüchen. Sie hilft dem Entwickler, die Überblick über die (Teil-) Infrastruktur zu behalten und Details im der Tiefe zu beschreiben. Sie ermöglicht den Wissenstransfer zwischen Kollegen uns unterstützt den reibungslosen Betrieb.

Sie zeigt auch den Reifegrad einer Entwicklung an, so das Stakeholder umfassend, aktuell und eindeutig informiert werden. Sie gibt den Stakeholdern damit die Möglichkeit, die erarbeitete Leistung vor der Inbetriebnahme zu bewerten und ggfls. Änderungen zu erwirken.

§15 Vereinheitlichte die Sprache in der IT und den Fachbereichen

Infrastruktur- Administratoren, Software- Entwickler und Anforderer aus den Fachbereichen benutzten in der Regel zwar die gleiche Sprache, Sie verstehen sich aber nur unzureichend. Der Grund liegt in den verschiedenen kulturellen Ausprägungen, die jeder dieser Bereiche mit sich bringt. Am Ende werden zwar die gleichen Worte benutzt, Ihnen aber unterschiedliche Bedeutungen zugewiesen. Das ist der Anfang von Misserfolg.

§16 Habe den Überblick über die gesamte IT-Infrastruktur – zu jeder Zeit

Es ist unbedingt notwendig, das alle Personen, die Entscheidungen treffen, ein einheitliches und aktuelles Bild der gesamten Infrastruktur haben. Ich habe die Erfahrung gemacht, das Diskussionen über beispielsweise neu einzusetzende Komponenten wesentlich einfacher werden, wenn ein gemeinsames, an eine Wand gepinntes Bild des Status Quo vorliegt. In der Regel müssen solche, recht großen Bilder gedruckt werden, um lesbar alle aktiven Komponenten mit Namen und Beziehungen abbilden zu können.

§17 Weiche nur dann von den Prämissen ab, wenn eine realistische Substituierung angeboten wird.

Diese Prämissen sind die Grundpfeiler aller technologischen und organisatorischen Tätigkeiten in der IT. Sie dürfen nicht verletzt werden, da sonst die Handlungsweise der IT-Organisation unberechenbar und beliebig wird.

Ein Einzelfällen kann es aber vorkommen, das man in Teilen abweichen muss. Um diese Abweichung zu ermöglichen (durch die Abweichung entstehen Mehraufwände) , muss der auslösende Fachbereich entsprechende Substituierungen anbieten.
Das können sein:

  • Akzeptanz von Einschränkungen in der Funktionalität
  • höher finanzieller Aufwand in Entwicklung und Betrieb
  • längere Bearbeitungszeiten
  • höheres Risiko

Abweichungen von den Prämissen stellen immer ein Risiko dar. Deshalb müssen sie periodisch überprüft und – wenn möglich – eliminiert werden.

Fazit
Egal welcher Organisationsform man anhängt: Diese Prämissen sind immer hilfreich, um die IT-Organisation in eine definierte Richtung zu bringen. Wichtig ist hierbei die Entwicklung von einfachen Leitsätzen, die sich leicht merken lassen.

——————————————————————————————————————————
Das nächste Kapitel befasst sich mit den technischen und organisatorischen Methoden in einer Management-Landkarte

Ich freue mich auf Eure Kommentare, entweder auf meiner Website oder bei linkedin oder Xing.

Grundzüge einer sicheren IT-Infrastruktur

Aus meiner Erfahrung – und sicherlich auch aus der Erfahrung vieler IT’ler – ist der Aufbau einer sicheren Infrastruktur nicht nur eine Frage der eingesetzten Werkzeuge, sondern im besonderen Maße der Umgang mit diesen Tools.
Der Erfolg wird sich einstellen, wenn die konsequente Anwendung passender Werkzeuge mit stringenter Anwendung von organisatorischen und technischen Methoden einhergeht.

Wie man es nicht macht!

Wie oft habe ich in der Vergangenheit gesehen, das technische Methoden wahllos eingesetzt wurden, weil es „gerade irgendwie nicht anderes ging“ oder weil „es so verlangt wurde“. Gründe und Zwänge gibt es immer für Chaos.

Beispiel: in einem meiner letzten Projekte wurden während des Audits folgende Datenbanken auf Servern und Arbeitsplatz-Rechnern gefunden. Das Unternehmen hat einen SQL- „Experten“.

  • MS-SQL Server Express
  • MS-SQL Server 2016
  • MS-SQL Server 1019
  • Oracle 11
  • MySQL in Verschiedenen Versionen
  • IBM DB2
  • PostgreSQL
  • IBM Informix
  • ……

Diese Datenbanken liefen auf einem Zoo von verschiedenen Windows Versionen und Linux Derivaten.

Das kann niemand administrieren, es ist zu teuer, zu aufwändig, fehlerbehaftet und angreifbar. Auch wenn es schwerfällt, aber dieser Anzahl von verschiedenen Produkten zu einem Thema muss unbedingt entgegengewirkt werden. Damit ist keine sichere IT-Infrastruktur zu vertretbaren Kosten möglich.

Es ist nicht einfach hier zu vereinheitlichen, erst recht nicht, wenn es bereits zu solchen Auswüchsen gekommen ist. Was man aber grundsätzlich machen kann, um dem Ziel nahe zu kommen, habe ich im nächsten Kapitel beschrieben.

Wie macht man es richtig?

Nun, es gibt sicherlich verschiedene Wege zum Ziel einer „sicheren IT-Infrastruktur“. Ich stelle hier einen Weg vor, der für mich und meine Kunden in der Vergangenheit der Erfolgreichste war.

Die Aussage der „sicheren IT-Infrastruktur“ beschränkt sich nicht auf die Angriffs-sicherheit. Ziele einer „sicheren IT-Infrastruktur“ sind auch die Betriebssicherheit und Stabilität der Anwendungen sowie der notwendige Komfort für die Benutzer. Denn ein System, das dem Benutzer Arbeit abnimmt hat eine wesentlich höhere Akzeptanz als Systeme, die umständlich zu bedienen sind.
Damit ich es nicht vergesse: Automation ist ein elementares Ziel moderner IT-Organisation. Das muss hier Niederschlag finden.

Die Aufgabe, eine IT-Organisation (neu) zu strukturieren kann nicht von einer oder wenigen Personen in der IT getragen werden, Vielmehr ist die Akzeptanz und Unterstützung aller Kernbereichre eines Unternehmens, allen voran der Geschäftsführung, notwendig. Bei entsprechender Vorbereitung des Themas wird das aber gelingen.

Sobald die Unterstützung steht, muss den Mitgliedern der IT-Organisation ein Leitfaden an die Hand gegeben werden, der beschreibt, wie die IT gut funktionieren kann. Sobald der Leitfaden etabliert ist, muss der auch in den wichtigsten Aussagen in die Gesamtorganisation kommuniziert werden.

Den Leitfaden habe ich in Form von Prämissen formuliert.

Gleichzeitig ist der Status Quo (sofern noch nicht geschehen) der IT-Organisation zu erheben. Damit ergeben sich eine Management – Landkarte und das BigPicture der gesamten IT-Infrastruktur in der momentanen Situation. (CMO=Current Mode of Operation). Da die Ausgangslagen der Unternehmen immer individuell sind, kann ich an dieser Stelle nicht im Detail darauf eingehen.

Im nächsten Schritt sind die Ziele für Management und IT-Infrastruktur zu definieren. Um diesen Schritt zu verdeutlichen, werde ich die Minimalziele für die Zukunft der IT-Organisation (FMO=Future Mode Of Operation) ausführen.

Aus dem Audit (Status Qou) und den Zielen ergibt sich eine Fit&Gap-Liste. Daraus sind die Handlungsstränge und die Aktionen zu entwickeln.

Die Themen

  • Prämissen
  • Management- Landkarte (FMO)
  • BigPicture (FMO)
  • Fit&Gap Liste, Handlungsstränge und Aktionen

werde ich in den nächsten Tagen veröffentlichen. Viel Spaß beim Lesen und Kommentieren.

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

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

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.