Revisions- und Regulierungskonformität: nachweisbare Rechenschaftspflicht

In vielen IT-Abteilungen folgt die Zeit vor einem Audit dem gleichen Ritual. Mehrere Personen müssen ihre reguläre Arbeit unterbrechen und Beweise zusammenstellen. Wer hat diese Änderung genehmigt? Warum hatte dieser Benutzer Administratorenrechte? Wann wurde die Firewall-Konfiguration geändert und wer hat sie geändert? Die Antworten existieren, aber sie sind verstreut über E-Mails, Chats, Exporte aus verschiedenen Tools und den Erinnerungen von Personen, von denen einige das Unternehmen inzwischen verlassen haben.

Gleichzeitig wächst der Druck, Beweise zu liefern. Die Cybersicherheitsregulierung, wie NIS2 und die nationalen Gesetze, die es umsetzen, legt generell Gewicht auf Risikomanagement, Management-Verantwortlichkeit und die Fähigkeit, nachzuweisen, dass Sicherheitsmaßnahmen tatsächlich funktionieren. Spezifische Verpflichtungen unterscheiden sich je nach Art der Organisation und sollten am besten mit Rechts- oder Compliance-Spezialisten bewertet werden. Der gemeinsame Nenner ist jedoch klar: Es reicht nicht aus, die Dinge richtig zu machen. Sie müssen es auch nachweisen können.

Warum das Zusammenstellen von Beweisen nachträglich scheitert

Das Problem liegt selten daran, dass eine Organisation keine Prozesse hat. Das Problem ist, dass diese Prozesse nicht von selbst eine Spur hinterlassen.

• Genehmigungen erfolgen außerhalb des Systems. Die Zustimmung zu einer Ausfallzeit trifft per E-Mail ein, die Änderung wird woanders durchgeführt, und die Verbindung zwischen ihnen existiert nur im Kopf des Change-Managers.
• Die Historie wird überschrieben. Das Tool zeigt den aktuellen Zustand, aber nicht, wie es vorher aussah.
• Automatisierte Aktionen sind unsichtbar. Geplante Jobs ändern Daten, aber niemand weiß genau, wann oder was sie getan haben.
• Verantwortlichkeiten leben auf Papier. Eine RACI-Matrix sitzt in einem Dokument, und niemand überprüft, ob sie mit den tatsächlichen Berechtigungen übereinstimmt.

Das Ergebnis ist ein Audit, das als Projekt läuft, anstatt als eine routinemäßige Überprüfung der Aufzeichnungen.

Wie Sie sich der Nachweisbarkeit nähern

Eine echte Audit-Bereitschaft ist ein Nebenprodukt der täglichen Arbeit. Wenn jede Aktion in einem System stattfindet, das sie aufzeichnet, existieren die Beweise im Moment, in dem die Dinge passieren. Einige Prinzipien:

• zeichnen Sie nicht nur "wer und wann", sondern auch "was genau geändert wurde", also den Zustand vor und nach,
• prüfen Sie, was Maschinen tun, nicht nur, was Menschen tun,
• bewahren Sie Aufzeichnungen lange genug auf,
• beschreiben Sie Verantwortlichkeiten auf eine Weise, die mit tatsächlichen Berechtigungen verglichen werden kann.

Wie Eywo Stratum es handhabt

Eywo Stratum hält einen Audit-Trail aller Aktionen vor, der für fünf Jahre aufbewahrt wird. Für Konfigurationsänderungen zeichnet es den Zustand vor und nach auf, sodass Sie nicht nur sehen, dass etwas geändert wurde, sondern genau was. Auch Scheduler-Aktionen, die automatisierten Jobs, die ohne menschliches Eingreifen laufen, werden geprüft.

CMDB-Elemente haben ihre eigene Versionshistorie. Für jede Änderung können Sie sehen, wer sie vorgenommen hat, wann, was geändert wurde und woher sie kam: die Discovery-API, ein Import, eine manuelle Bearbeitung oder die Synchronisierung mit einer primären CMDB.

Genehmigungen erfolgen innerhalb des Systems. Ausfallzeiten in Änderungen, Anfragen und anderen Elementen, die eine Entscheidung benötigen, kommen in einer einzigen "Zur Genehmigung"-Warteschlange zusammen. Eine Regel definiert, wer der Eigentümer ist, und eine Ablehnung erfolgt immer mit einem Grund. Die Aufzeichnung darüber, wer was genehmigt hat, wird direkt neben der Änderung erstellt.

Verantwortlichkeiten werden in einer RACI-Matrix beschrieben, und Eywo Stratum überprüft, ob sie mit den Berechtigungen konsistent ist. Wenn jemand als verantwortlich aufgeführt ist, aber keine Rolle hat, die es ihm ermöglichen würde, die Aufgabe zu genehmigen oder durchzuführen, zeigt es sich. Rollen sind bereichsspezifisch (alles, Kunde, Team, Element), sodass klar ist, nicht nur, was jemand tun kann, sondern auch, worüber.

Fazit

Ein Audit sollte kein Projekt sein. Wenn der Audit-Trail automatisch erstellt wird, Genehmigungen im System leben und Verantwortlichkeiten an Berechtigungen geknüpft sind, ist die Antwort auf eine Frage eines Auditors nur wenige Klicks entfernt. Das Team kann weiterarbeiten, und das Management kann sicher sein, dass die Verantwortlichkeit nachgewiesen werden kann.

Der Audit-Trail, die CMDB-Historie und die RACI-Matrix sind in der Standard-Edition enthalten.