Office-Makros und PowerShell-Skripte: Kleines Skript, großes Risiko.
Office-Makros und PowerShell-Skripte sind aus dem Alltag vieler Finanzinstitute kaum wegzudenken. Mit DORA rücken sie nun ins Zentrum der Aufmerksamkeit: Denn jede ausführbare Logik, die regulierte Prozesse beeinflusst, muss nachweislich kontrolliert werden – unabhängig davon, ob sie zentral durch die IT-Abteilung implementiert oder vom Fachanwender selbst erstellt wurde.
Zusammenfassung (TL; DR):
- DORA verpflichtet Finanzinstitute dazu, jegliche ausführbare Logik – wie Office-Makros und PowerShell-Skripte – nachweislich zu kontrollieren.
- Dies gilt unabhängig davon, ob die Software zentral von der IT oder dezentral als Individuelle Datenverarbeitung (IDV / End-User Computing) in Fachabteilungen erstellt wurde.
- Da herkömmliche Plattformkontrollen den tatsächlichen Codeinhalt nicht prüfen, fordert DORA eine deterministische Kontrolle mittels kryptografischer Freigaben. Auch unveränderlicher Audit-Trails, um Software-Integrität zu garantieren und Sicherheitsrisiken zu minimieren, sind gefordert.
Kaum ein Finanzinstitut, in dem man sie vergeblich sucht: die Excel-Datei im Risikocontrolling, die seit Jahren im Einsatz ist und deren Makro-Logik inzwischen niemand mehr so genau kennt. Oder das PowerShell-Skript, das ein Admin vor Jahren geschrieben hat, um einen administrativen Prozess zu automatisieren, und das seitdem still und zuverlässig seinen Dienst verrichtet. Solche individuell entwickelten Anwendungen – in der Regulatorik als „Individuelle Datenverarbeitung“ (IDV) bekannt, international als „End-User Computing“ (EUC) bezeichnet – sind kein Randphänomen. Sie sind struktureller Bestandteil des operativen Betriebs der meisten Banken, Versicherungen und anderer regulierter Finanzunternehmen.
Ihr Reiz für die Fachanwender liegt auf der Hand: In Zeiten überlasteter IT-Teams ist eine eigene kleine Excel-Automatisierung schnell erstellt, etwa um die für ein Reporting benötigten Werte zu ermitteln, anstatt auf die Anpassung der eigentlichen Funktionalität im zentralen IT-System durch die IT warten zu müssen. Doch nicht selten führen IDV-Anwendungen damit Logiken aus, die regulierte Daten oder Entscheidungsprozesse direkt beeinflussen können. Bislang fiel die Nutzung von IDV-Anwendungen in eine regulatorische Grauzone. Mit DORA hat sich dies nun fundamental geändert.
Office-Makros und PowerShell-Skripte: Kontrolle behalten – und belegen
Der Digital Operational Resilience Act (DORA) der EU unterscheidet nicht zwischen zentralen IT-Systemen und Anwendungen, die von Fachanwendern außerhalb der IT entwickelt wurden. Paragraf 16(9) der sogenannten „Regulatory Technical Standards“ regelt explizit, dass ICT-Risikomanagementanforderungen auch für Systeme gelten, die außerhalb der IT-Funktion entwickelt oder betrieben werden. Die aufsichtsrechtliche Logik dahinter ist simpel: Ein Tool, das regulierte Prozesse beeinflusst, muss kontrolliert werden, egal ob sein Code auf einem Kernbanksystem oder in einer Tabellenkalkulation ausgeführt wird.
Dabei beschränkt sich DORA nicht auf die Frage, ob Systeme vor externen Angriffen geschützt sind. Institutionen müssen in der Lage sein, nachzuweisen, dass Daten korrekt verarbeitet, Entscheidungen nachvollziehbar getroffen und ausführbare Logik kontrolliert eingesetzt wird. Ähnliche Anforderungen finden sich auch in anderen Regularien und Gesetzen: Die Mindestanforderungen an das Risikomanagement von Banken (MaRisk) verlangen geordnetes Änderungsmanagement und klare Verantwortlichkeiten für alle materiellen Prozesse. Das Schweizer FinfraG (FINMA) betont Integrität und Nachvollziehbarkeit von Systemen, die kritische Finanzprozesse beeinflussen.
IDV-Anwendungen sind schwer zu kontrollieren
Im Kontext von IDV ergibt sich hier eine zentrale Herausforderung: Office-Makros etwa sind in Dokumente eingebettet, die über Mail oder Fileserver verteilt werden. Ein kontrollierter Release-Prozess besteht dabei in aller Regel nicht. Eine Tabelle mag optisch unverändert aussehen, während die eingebettete Makro-Logik angepasst wurde. PowerShell-Skripte werden zwar häufig in Versionierungssystemen gespeichert, doch das allein genügt nicht. Ein Administrator kann ein genehmigtes Skript jederzeit auschecken, lokal verändern und mit erhöhten Rechten ausführen, ohne dass das System eine Abweichung registriert. Was in beiden Fällen fehlt, sind unveränderliche Belege folgender drei Gesichtspunkte: Wer hat den Code verfasst? Wer hat ihn freigegeben? Und ist genau diese Version tatsächlich unverändert zur Ausführung gekommen?
Die nativen Plattformkontrollen von Betriebssystemen allein genügen in diesem Kontext nicht. Denn sie arbeiten heuristisch: Sie treffen die Entscheidung, ob ein Makro ausgeführt werden darf oder nicht, auf Basis von Dateipfad, Netzwerkspeicherort, Benutzerrolle oder Endgerät-Konfiguration. Ein Makro aus einem vertrauenswürdigen Ordner darf dann etwa ausgeführt werden, weil die Umgebung es erlaubt – nicht, weil der Inhalt geprüft wurde. Spiegelbildlich erfassen Logging und Monitoring beispielsweise, dass PowerShell aufgerufen wurde, nicht jedoch, welcher Code darin tatsächlich ausgeführt wurde.
DORA braucht deterministische Kontrolle
Regulatorien wie DORA verlangen mehr als reine Plausibilität. Sie erwarten eine deterministische Kontrolle. Das bedeutet: Ausführbare Logik darf nur dann laufen, wenn vorab definierte, kryptografisch verifizierbare Bedingungen erfüllt sind. Dazu gehört etwa, dass der Code von einer bekannten Person erstellt und durch einen definierten Prozess freigegeben wurde. Nur in dieser freigegebenen Version, nachweislich unverändert, kann die Logik dann tatsächlich ausgeführt werden.
Für IT-Verantwortliche bedeutet das in der Praxis, dass Genehmigungsprozesse technisch erzwungen, nicht nur dokumentiert werden müssen. Scope-Kontrolle darf nicht auf Systemebene beschränkt bleiben, sondern muss auf Codeebene greifen. Und schließlich müssen die entstehenden Nachweise als kryptografischer Audit-Trail lückenlos nachprüfbar sein.
Dabei geht es ausdrücklich nicht darum, bestehende IT-Verwaltungsstrukturen zu ersetzen. Active Directory, Intune, Endpunktschutz und Zugangsmanagement bleiben notwendige Fundamente. Vielmehr gilt es, eine Schicht darüber zu ergänzten und so die Kontrolle darüber zu erhalten, welche Logik konkret ausgeführt wird und ob sie tatsächlich identisch ist mit der genehmigten Version.
Ein Beispiel verdeutlicht, wie das in der Praxis aussieht: Ein Fachanwender in der Finanzabteilung erstellt ein Excel-Makro, das regulatorisch relevante Berechnungen automatisiert. Sobald das Makro zur Freigabe eingereicht wird, hält das System nachvollziehbar fest, wer es erstellt und eingereicht hat. Das Makro durchläuft anschließend einen definierten Freigabeprozess, automatisiert oder beispielsweise durch die IT-Funktion, die den Code prüft und genau diese Version freigibt. Erst mit dieser Freigabe wird die Version kryptografisch signiert. Die Signatur bestätigt, dass es sich um die geprüfte, freigegebene Version handelt und nicht um eine persönliche Modifikation des Erstellers. Ab diesem Zeitpunkt ist die freigegebene Version maßgeblich: Versucht eine Person in einer gehärteten Umgebung, in der ausschließlich signierte Makros ausgeführt werden dürfen, eine auch nur geringfügig veränderte Version auszuführen – sei es durch eine versehentliche Änderung oder eine bewusste Manipulation – blockiert das System die Ausführung und erzeugt einen Audit-Eintrag.
Sicherheit als Nebeneffekt
Generell bergen Makros und Skripte ein weiteres Risiko: Sie dienen als Einfallstor für Angriffe. Angriffsvektoren nutzen oft die Unklarheit über ausführbare Logik auf Systemen aus, um Phishing-Kampagnen oder initiale Kompromittierungen durchzuführen. Deterministische Ausführungskontrolle verhindert strukturell die Ausführung nicht autorisierten Codes, was Social Engineering durch kryptografische Freigaben statt Benutzerentscheidungen unwirksam macht.
