Das eigentliche Risiko im ServiceNow Flow Designer: erhöhte Identität, kein Filter
Ein Flow, der mit Admin-Rechten läuft, ist nicht automatisch ein Problem. Ein Flow, der mit Admin-Rechten bei jedem Datensatz läuft, ohne dass etwas eingrenzt, welche - das ist das Muster, das geprüft werden sollte.
Wie sich das tatsächlich zeigt
Flow Designer macht es einfach, zu einer erhöhten Run-As-Identität zu greifen, wenn ein Flow Datensätze berühren muss, auf die der auslösende Benutzer keinen Zugriff hat - und ebenso einfach, nie wieder zu prüfen, ob das noch die richtige Entscheidung ist.
Erhöhte Run-As-Identität ohne Trigger-Bedingung
Löst bei jedem Create oder Update auf der Tabelle aus, nicht nur bei den spezifischen Datensätzen, für die er eigentlich gebaut wurde.
Breiter Tabellen-Scope für einen engen Anwendungsfall
Ausgelöst auf einer ganzen Tabelle, obwohl der eigentliche Bedarf nur die Änderung eines einzelnen Feldes bei einer Teilmenge der Datensätze war.
Wildwuchs bei Connections & Credentials
Mehr gespeicherte Credentials als aktive Integrationen - niemand hat die zurückgeholt und entfernt, auf die nichts mehr verweist.
Subflows erben erhöhte Identität ohne erneute Prüfung
Ein Subflow läuft mit welcher Identität auch immer sein übergeordneter Flow hatte, unabhängig davon, ob die Aktionen des Subflows sie tatsächlich brauchen.
So wird es geprüft
Der Name des Flows sagt, was er tun soll. Sein Trigger sagt, was er tatsächlich tut.
Den Trigger lesen, nicht nur den Flow-Namen
Die tatsächlich konfigurierte Tabelle und Filterbedingung eines Flows leben in seiner Trigger-Definition, nicht darin, wie er beim Bau benannt wurde. Die tatsächliche Bedingung zu lesen - oder zu bestätigen, dass keine existiert - ist der einzige verlässliche Weg zu wissen, worauf ein Flow wirklich reagiert.
Run_as bei jedem aktiven Flow prüfen, nicht nur bei den bekannten
Flows mit erhöhter Run-As-Identität sammeln sich genauso an wie überberechtigte Rollen - einer nach dem anderen, jeder einzeln nachvollziehbar, selten als Ganzes noch einmal geprüft.
Muster, die zuerst geprüft werden sollten
- Aktive Flows mit erhöhter Run-As-Identität und ohne Filterbedingung
- Flows, ausgelöst auf einer ganzen Tabelle, obwohl nur bestimmte Felder relevant sind
- Gespeicherte Credentials ohne aktive Connection, die auf sie verweist
- Flows, die niemand mehr geöffnet hat, seit die erstellende Person das Unternehmen verlassen hat
Die manuelle Variante skaliert nicht
Das richtig zu prüfen bedeutet, jeden aktiven Flow zu öffnen, seine reale Trigger-Konfiguration zu lesen und zu bewerten, ob die Run-As-Identität wirklich zum Risiko dessen passt, was er berühren kann - und das jedes Mal erneut, wenn ein Flow hinzukommt oder geändert wird. Auf einer Instanz mit Hunderten aktiver Flows prüft das schlicht niemand kontinuierlich von Hand.
Diese Prüfung läuft kontinuierlich, automatisch
Unsere eigene Plattform, neo.ai, liest die reale Trigger-Bedingung jedes aktiven Flows nach Zeitplan und bewertet, ob eine erhöhte Identität angesichts dessen, was der Flow tut, tatsächlich angemessen ist - nicht nur, ob eine konfiguriert ist. Das ist eine von sieben Kategorien, die sie auf einer ServiceNow-Instanz überwacht.