Kann diese selbst gehostete Anwendung Ihren Genehmigungsprozess unterstützen? Ein praktischer Bewertungsrahmen

Warum eine Genehmigungsfunktion nicht dasselbe ist wie ein kontrollierter Genehmigungsprozess

Viele Anwendungen können ein Element als genehmigt markieren, eine Statusänderung einschränken oder eine Kollegin beziehungsweise einen Kollegen zur Prüfung benachrichtigen. Das kann nützlich sein, stellt aber nicht automatisch einen kontrollierten Prozess für eine Beschaffung, Ausgabe, Zugriffsanfrage, Änderung von Kundendaten oder Veröffentlichungsentscheidung bereit.

Ein kontrollierter Genehmigungsprozess benötigt mehr als eine Aktion auf einem Bildschirm. Er braucht eine klar definierte Entscheidung, berechtigte Entscheidungsträger, Regeln dafür, wann deren Befugnis gilt, einen Nachweis darüber, was sie entschieden haben, sowie Schutzvorkehrungen dagegen, dass Personen den Prozess nachträglich ändern oder umgehen. Die richtige Frage lautet nicht: „Hat diese Anwendung Genehmigungen?“ Sie lautet: „Können wir diese Anwendung so konfigurieren und betreiben, dass unsere erforderlichen Entscheidungen getroffen, durchgesetzt und nachgewiesen werden?“

NIST SP 800-53 behandelt Kontrollen als flexibel und anpassbar innerhalb eines organisationsweiten Risikomanagementprozesses. Wenden Sie dasselbe Prinzip hier an: Übersetzen Sie Ihre eigenen geschäftlichen, richtlinienbezogenen und risikobezogenen Anforderungen in beobachtbare Tests. Eine allgemeine Funktionsbezeichnung ersetzt diese Arbeit nicht.

• Betrachten Sie eine Funktion als Ausgangspunkt, nicht als Nachweis einer Kontrolle.
• Unterscheiden Sie praktische Prüfungen von Entscheidungen, die finanzielle, rechtliche, sicherheitsbezogene oder kundenwirksame Verpflichtungen begründen.
• Dokumentieren Sie, welche Anforderungen zwingend, welche wünschenswert sind und welche außerhalb der Anwendung umgesetzt werden müssen.

Beginnen Sie mit der realen Entscheidung

Beginnen Sie mit dem Geschäftsereignis, nicht mit der Softwarekonfiguration. Beschreiben Sie jeweils einen Genehmigungstyp. „Beschaffungen“ ist in der Regel zu weit gefasst: Die Genehmigung einer wiederkehrenden Lieferantenverlängerung mit geringem Wert kann andere Nachweise, Befugnisse und Risiken umfassen als die Genehmigung einer neuen, hochwertigen Verpflichtung gegenüber einem Lieferanten.

Identifizieren Sie für jede Entscheidung die antragstellende Person, den zu entscheidenden Datensatz, die erforderlichen Nachweise, die möglichen Ergebnisse und die Handlung, die erst nach der Genehmigung erfolgen darf. Bestimmen Sie außerdem die Folge einer fehlerhaften Genehmigung. Daraus ergibt sich, wie viel Kontrolle, Transparenz und Prüfung der Workflow benötigt.

• Was wird genehmigt: ein Antrag, ein Dokument, eine Datensatzänderung, eine Zahlung, eine Veröffentlichung, eine Zugriffsberechtigung oder eine Aktion mit Kundendaten?
• Wer darf den Antrag stellen, und welche Felder oder Anhänge müssen vor der Einreichung vollständig sein?
• Wer darf genehmigen, ablehnen, zur Überarbeitung zurückgeben oder stornieren?
• Welche Schwellenwerte, Risikokategorien, Abteilungen, Standorte oder Datenklassifizierungen verändern den Ablauf?
• Welche Handlung wird nach der Genehmigung zulässig, und wer führt sie aus?
• Wie lange müssen der Entscheidungsnachweis und die unterstützenden Nachweise aufbewahrt werden?

Ordnen Sie den minimalen Workflow zu, bevor Sie Software bewerten

Beschreiben Sie den kleinsten vollständigen Workflow in einfacher Sprache und machen Sie anschließend jeden Schritt in der Anwendung testbar. Eine nützliche Grundlage ist Antrag, Prüfung, Entscheidung, Benachrichtigung, Ausführung und Aufbewahrung von Aufzeichnungen. Wenn ein vorgeschlagenes Werkzeug einen erforderlichen Schritt nicht abbilden oder die benötigten Informationen nicht bewahren kann, benennen Sie die kompensierende Kontrolle ausdrücklich, statt anzunehmen, dass sich Nutzende daran erinnern werden.

Halten Sie die Genehmigungsentscheidung von der nachgelagerten Ausführung getrennt. Eine genehmigende Person kann beispielsweise eine Beschaffung autorisieren, während eine andere Person die Bestellung erstellt. Diese Unterscheidung ist wichtig für Verantwortlichkeit und Funktionstrennung.

• Antrag: Erstellen Sie ein eindeutig identifizierbares Element und erfassen Sie erforderliche Daten und Nachweise.
• Prüfung: Stellen Sie das Element den richtigen prüfenden Personen zur Verfügung.
• Entscheidung: Erfassen Sie Genehmigung, Ablehnung oder Rückgabe zur Überarbeitung mit der verantwortlichen Identität.
• Benachrichtigung: Informieren Sie die antragstellende Person und die nächste verantwortliche Partei darüber, was geschehen ist.
• Ausführung: Erlauben oder lösen Sie die autorisierte Folgemaßnahme nur aus, wenn die Bedingungen erfüllt sind.
• Aufbewahrung: Bewahren Sie den Entscheidungsnachweis, Anhänge und die Historie für den erforderlichen Zeitraum auf.

Bewerten Sie Status und Übergänge, einschließlich Änderungen nach der Genehmigung

Ein Workflow wird durch seine Status und die zulässigen Übergänge zwischen ihnen definiert. Testen Sie mindestens Entwürfe, eingereichte Elemente, genehmigte Elemente und abgelehnte Elemente. In vielen Prozessen benötigen Sie außerdem die Status zur Änderung zurückgegeben, storniert, abgelaufen, ersetzt oder ausgeführt.

Der aufschlussreichste Test ist eine wesentliche Änderung nach der Genehmigung. Wenn sich Betrag, Lieferant, Umfang, Anhang, Zugriffsstufe oder Zweck der Kundendatenverarbeitung ändert: Sperrt die Anwendung den Datensatz, macht sie die Genehmigung ungültig, erstellt sie eine neue Revision oder behält sie lediglich eine alte Genehmigung neben geänderten Inhalten bei? Ihr Prozess sollte festlegen, welche Änderungen eine erneute Genehmigung erfordern, und die Anwendung sollte dieses Ergebnis eindeutig machen.

Testen Sie außerdem, wer jeden Status verändern kann. Eine antragstellende Person darf möglicherweise einen Entwurf bearbeiten, sollte ihn aber nicht zwangsläufig ohne die erforderlichen Bedingungen als eingereicht, genehmigt oder ausgeführt markieren können.

• Können Nutzende den aktuellen Status und die vollständige frühere Statushistorie sehen?
• Sind Übergänge durch Rolle, Zuweisung oder Workflow-Bedingungen eingeschränkt?
• Werden abgelehnte Elemente geschlossen, zur erneuten Einreichung bearbeitbar gemacht oder zur Korrektur zurückgeleitet?
• Löst eine Änderung nach der Genehmigung eine erneute Genehmigung aus, wenn Ihre Richtlinie dies verlangt?
• Kann ein genehmigtes Element storniert werden, und bleiben Stornierungsgrund und Identität erhalten?
• Können Nutzende einen genehmigten Datensatz von einem ausstehenden, überarbeiteten oder ersetzten Datensatz unterscheiden?

Testen Sie Befugnisregeln, nicht nur die Zuweisung von Genehmigenden

Eine namentlich benannte genehmigende Person ist leicht zu verstehen, kann aber anfällig sein. Eine robuste Bewertung prüft, ob die Anwendung das tatsächlich verwendete Befugnismodell abbilden kann: rollenbasierte Prüfende, Schwellenwerte, bedingte Abläufe und mehr als eine Genehmigungsstufe. Gehen Sie nicht davon aus, dass eine zugewiesene Führungskraft für jede Entscheidung stets die berechtigte Person ist.

Verwenden Sie repräsentative Fälle. Testen Sie einen Routineantrag, einen Antrag knapp unter und knapp über einem monetären Schwellenwert, einen Antrag mit hohem Risiko, einen Antrag über zwei Abteilungen hinweg sowie einen Antrag, der eine Prüfung durch Rechtsabteilung, Sicherheit oder Finanzen erfordert. Halten Sie fest, ob die Weiterleitung automatisch erfolgt, ob sie geändert werden kann und was Nutzende sehen können, wenn sie nicht die aktuell prüfende Person sind.

• Namentliche Befugnis: Kann eine bestimmte verantwortliche Person genehmigen?
• Rollenbasierte Befugnis: Kann die aktuelle Inhaberin oder der aktuelle Inhaber einer genehmigten Geschäftsrolle genehmigen?
• Schwellenwertbasierte Befugnis: Ändert sich der Ablauf beim erforderlichen Betrag oder Risikoniveau?
• Mehrstufige Befugnis: Können erforderliche Prüfende in der richtigen Reihenfolge handeln?
• Parallele Befugnis: Wenn mehrere Prüfungen erforderlich sind, müssen alle genehmigen oder genügt eine Genehmigung?
• Bedingte Befugnis: Können die erforderlichen Prüfenden je nach Abteilung, Datentyp, Land, Projekt oder Antragskategorie variieren?

Prüfen Sie Funktionstrennung und privilegierte Zugriffe

Funktionstrennung bedeutet mehr als unterschiedliche Bezeichnungen für Personen zu vergeben. Die NIST-Kontrolle AC-5 verlangt eine definierte und dokumentierte Aufgabentrennung sowie Zugriffsberechtigungen, die diese unterstützen. Überführen Sie dieses Prinzip in direkte Tests: Kann eine antragstellende Person den eigenen Antrag genehmigen, einen genehmigten Datensatz ändern, eine nicht berechtigte genehmigende Person auswählen oder eine erforderliche prüfende Person umgehen?

Bewerten Sie gewöhnliche Anwendungsrollen und operative Zugriffe getrennt. In einer selbst gehosteten Bereitstellung können Personen mit weitreichendem Bereitstellungs- oder Hostzugriff den Anwendungsbetrieb, Daten oder die Konfiguration außerhalb des Geschäftsworkflows ändern. Docker dokumentiert, dass sein Standard-Autorisierungsmodell für Nutzende mit Zugriff auf den Docker-Daemon alles oder nichts vorsieht: Solche Nutzende können Docker-Client-Befehle ausführen. Beziehen Sie diesen Zugriff in Ihr Bedrohungsmodell und Ihre Governance-Gestaltung ein.

Docker-Autorisierungs-Plugins können Entscheidungen zum Zulassen oder Verweigern anhand von Authentifizierung und Befehlskontext treffen, doch Docker dokumentiert auch Grenzen ihres Durchsetzungsbereichs. Wenn Sie sich auf solche Kontrollen stützen möchten, testen Sie ihren Bereich anhand der administrativen Aktionen, die für Ihren Prozess relevant sind. Leiten Sie nicht daraus ab, dass Einschränkungen von Workflows auf Anwendungsebene Infrastrukturadministratoren allein begrenzen.

• Verwenden Sie getrennte Testkonten für antragstellende Person, genehmigende Person, ausführende Person, Anwendungsadministrator und Infrastrukturadministrator.
• Versuchen Sie Selbstgenehmigung, Genehmigung durch eine nicht berechtigte Rolle und Genehmigung nach einer Neuzuweisung.
• Versuchen Sie, Schlüsselfelder und Anhänge nach der Genehmigung zu bearbeiten.
• Ermitteln Sie, wer Workflow-Regeln, Rollen, Audit-Einstellungen, Datenspeicher, Container und Sicherungen ändern kann.
• Definieren Sie, wer privilegierte Zugriffe überprüft und wie häufig dies geschieht.
• Stellen Sie sicher, dass der Prozess das Restrisiko anerkennt, wenn ein kleines Technikteam zwangsläufig weitreichenden operativen Zugriff besitzt.

Bewerten Sie Delegation, Abwesenheit und überfällige Arbeit, ohne Verantwortlichkeit zu verlieren

Genehmigungsworkflows scheitern oft unter gewöhnlichen Umständen: Eine genehmigende Person ist im Urlaub, hat die Rolle gewechselt oder handelt schlicht nicht. Ein funktionsfähiger Prozess benötigt einen bewussten Weg für Delegation, Neuzuweisung und Eskalation. Das Ziel ist Kontinuität, ohne zu verschleiern, wer befugt war und wer die endgültige Entscheidung getroffen hat.

Testen Sie, ob die Anwendung die ursprünglich zugewiesene Person, die Person oder Regel, die die Arbeit neu zugewiesen hat, die Entscheidung der vertretenden Person und den Zeitpunkt jedes Ereignisses aufzeichnet. Wenn Delegation außerhalb der Anwendung erfolgt, entscheiden Sie, wie diese Anweisung dokumentiert und wie die Befugnis der neuen genehmigenden Person überprüft wird.

• Kann eine genehmigende Person nur innerhalb einer zulässigen Rolle oder Befugnisstufe delegieren?
• Bewahrt das System die ursprünglich zugewiesene Person und die Delegationshistorie?
• Kann ein Prozessverantwortlicher ein überfälliges Element neu zuweisen, und wird der Grund aufgezeichnet?
• Sind Erinnerungen und Eskalationen ausreichend konfigurierbar für die erforderliche Reaktionszeit?
• Was geschieht, wenn ein Konto einer genehmigenden Person deaktiviert oder entfernt wird, während Arbeit aussteht?
• Gibt es einen dokumentierten Notfallweg mit nachträglicher Prüfung für Entscheidungen, die nicht warten können?

Bewerten Sie Genehmigungsnachweise und Audit-Aufzeichnungen

Der Entscheidungsnachweis sollte grundlegende Fragen beantworten, ohne sich auf das Gedächtnis einer Person zu stützen: Was ist geschehen, wann und wo ist es geschehen, was oder wer hat es verursacht, wie lautete das Ergebnis und welche Identitäten waren beteiligt? Dies steht im Einklang mit den Elementen von Audit-Aufzeichnungen in der NIST-Kontrolle AU-3.

Prüfen Sie für jede Entscheidung die tatsächlich aufbewahrte Ausgabe, statt sich auf ein Dashboard zu verlassen. Stellen Sie fest, ob sie die Antragsversion, die Entscheidung, Datum und Uhrzeit, die Identität der genehmigenden Person, Kommentare, angehängte Nachweise, Zuweisungen und alle wesentlichen Änderungen enthält. Testen Sie anschließend, ob eine Person die Nachweise in einer Form exportieren oder abrufen kann, die außerhalb der Anwendung verständlich bleibt.

Nachweise sind nur nützlich, wenn sie vertrauenswürdig bleiben. NIST AU-9 behandelt den Schutz von Audit-Informationen und die Beschränkung der Verwaltung von Protokollierungsfunktionen auf eine geeignete Teilmenge privilegierter Nutzender. Fragen Sie, wer Genehmigungsaufzeichnungen und Protokolle ändern, löschen, deaktivieren oder ersetzen kann und wie diese Handlungen selbst erkannt oder überprüft werden.

• Antragskennung und die genehmigte Version oder Revision.
• Ereignistyp, Zeitpunkt, relevante Quelle oder Ort, Ergebnis und zugehörige Identitäten.
• Entscheidungskommentare, Ablehnungsgründe und verknüpfte Anhänge, soweit erforderlich.
• Eine vollständige Historie von Zuweisungen, Delegationen und Statusänderungen.
• Getestete Verfahren für Aufbewahrung, Export und Abruf.
• Zugriffskontrollen für Genehmigungsaufzeichnungen und Audit-Protokollierung, einschließlich Governance für privilegierte Nutzende.