Ist Ihre ServiceNow-Instanz überberechtigt?
Zugriffskontrolle auf ServiceNow bricht selten auf einen Schlag - sie driftet, eine „fügen wir kurz die Rolle hinzu“-Ausnahme nach der anderen, bis niemand mehr sagen kann, wer was sehen kann und warum.
Woher Überberechtigung tatsächlich kommt
Fast niemand setzt sich vor, eine Tabelle überzuberechtigen. Es entsteht durch einzeln nachvollziehbare Entscheidungen, die niemand noch einmal prüft.
Tabellenebene-Rollen statt Datensatzebene
Eine Rolle, die für jeden Datensatz einer Tabelle nötig ist, obwohl der eigentliche Bedarf nur „Datensätze, die dieser Person zugewiesen sind“ war.
ACL-Bedingungen, die für alle zutreffen
Ein Bedingungsskript, das von Tests übrig geblieben ist, oder so locker geschrieben wurde, dass es unabhängig vom Anfragenden wahr auswertet.
Admin-Overrides bleiben aktiviert
Für eine einmalige Korrektur während eines Incidents hinzugefügt, dann nie wieder geprüft, nachdem der Incident geschlossen war.
Fehlende Field-Level-ACLs auf sensiblen Feldern
Die Tabelle selbst ist geschützt, aber ein bestimmtes Feld mit sensiblen Daten hat keine zusätzliche Einschränkung.
Verwaiste Rollenvergaben
Eine Rolle, die einer Gruppe für ein längst abgeschlossenes Projekt zugewiesen wurde - der Zugriff wurde nie entzogen, weil niemand dafür zuständig ist.
So prüfen Sie es tatsächlich, statt zu raten
Eine Zugriffsprüfung braucht meist kein neues Tool - sie braucht jemanden, der tatsächlich liest, was bereits vorhanden ist.
Die ACL lesen, nicht nur ihren Namen
Eine sinnvoll benannte ACL kann trotzdem eine Bedingung oder ein Skript haben, das weit mehr gewährt, als der Name vermuten lässt. Der einzige Weg, es zu wissen, ist, die tatsächlichen Bedingungs- und Skriptfelder von sys_security_acl zu lesen, pro Operation und pro Tabelle.
Gezielt nach Admin-Overrides suchen
Diese sind absichtlich als vorübergehend gedacht - eine schnelle Durchsicht aktiver ACLs auf noch aktivierte ist eine der wertvollsten verfügbaren Prüfungen.
Rollen gegen tatsächliche Nutzung abgleichen
Eine Rolle, die auf dem Papier existiert, ist nicht dasselbe wie eine Rolle, auf die sich jemand tatsächlich stützt. Wer eine Rolle hält, gegen wer tatsächlich mit den geschützten Daten gearbeitet hat abzugleichen, bringt die Vergaben ans Licht, an die sich niemand mehr erinnert.
Muster, die zuerst geprüft werden sollten
- ACLs ohne Bedingung und ohne Skript
- Breiter Tabellenebene-Schreibzugriff für einen engen Workflow-Schritt
- Über Gruppenmitgliedschaft vererbte Rollen, an die sich niemand erinnert
- Sensible Felder ohne Field-Level-ACL
- Sicherheitsrelevante ACLs seit über einem Jahr unangetastet
Die manuelle Variante skaliert nicht
Eine echte Zugriffsprüfung bedeutet, jede relevante ACL tatsächlich zu lesen, Rolleninhaber gegen echte Nutzung abzugleichen - und es nächstes Quartal wieder zu tun, weil die Drift nie aufhört. Es ist genau die Art Arbeit, die echten Wert hat und gleichzeitig genau so mühsam ist, dass sie ständig verschoben wird.
Diese Prüfung läuft kontinuierlich, automatisch
Unsere eigene Plattform, neo.ai, liest die tatsächliche Bedingung und Rollenkombination jeder aktiven ACL nach Zeitplan, bewertet, ob der Zugriff wirklich zu dem passt, was der Datensatz schützt, und zeigt nur, was wirklich einen Blick wert ist. Das ist eine von sieben Kategorien, die sie auf einer ServiceNow-Instanz überwacht.