Least Privilege, durchgesetzt im Diff.
CC6.1 ist eines der Trust Services Criteria, die ein normaler Pull Request leise schwächen kann, weil es um logischen Zugriff geht - und logischer Zugriff lebt oft in Code und Konfiguration. Das Kriterium verlangt, dass der Zugriff auf Ihre Systeme und Daten auf die Benutzer und Prozesse beschränkt wird, die dazu autorisiert sind. In der Praxis bedeutet das: Least Privilege. Eine Rolle kann auf das zugreifen, was sie für ihre Aufgabe benötigt, und nicht mehr.
The shapes the same control failure takes.
CC6.1 bricht selten mit einer Zeile wie 'gewähre allen Admin-Rechte'. Es bricht durch gewöhnliche, auf den ersten Blick vernünftige Änderungen. Dies sind die wiederkehrenden Muster.
Eine Zugriffsrichtlinie wird erweitert
Eine IAM-Rolle, Sicherheitsgruppe oder Berechtigung erhält breitere Aktionen oder einen Wildcard, sodass eine Komponente nun mehr tun kann, als für ihre Aufgabe nötig ist.
Eine Autorisierungsprüfung wird entfernt
Eine Route verliert ihre Rollen- oder Besitzprüfung, oder ein Autorisierungs-Middleware wird nicht mehr auf einen neuen Endpunkt angewendet, sodass eine Anfrage, die eigentlich abgelehnt werden sollte, nun erfolgreich ist.
Ein Datenzugriff wird erweitert
Eine Datenbankrolle erhält Zugriff auf Tabellen oder Zeilen, die sie zuvor nicht hatte, die zeilenbasierte Sicherheit wird gelockert oder ein Service-Account wird auf eine Datenbank gerichtet, zu der es keinen Grund hatte, Zugriff zu benötigen.
Ein Standardwert wechselt zu 'erlauben'
Der Zugriff ändert sich von Standard-Ablehnung zu Standard-Zulassung: eine neue Ressource wird weltlesbar bereitgestellt oder eine Berechtigungsprüfung standardmäßig auf 'true' gesetzt, wenn der Fall unbekannt ist.
Ein Pfad zur Privilegieneskalation öffnet sich
Ein Benutzer mit geringeren Rechten erhält eine Möglichkeit, als ein Benutzer mit höheren Rechten zu agieren: ein internes Flag, das die Rollenprüfung umgeht, oder ein Token, das mit einem größeren Gültigkeitsbereich als der des Aufrufers erstellt wird.
Ein Refactoring, das eine Autorisierungsprüfung entfernt.
Eine Route wird aufgeräumt. Die Rollenprüfung in der Mitte wirkt neben dem Auth-Middleware redundant und wird entfernt. Der Endpunkt erfordert zwar weiterhin einen angemeldeten Benutzer, aber nicht mehr den richtigen: Jetzt kann jeder authentifizierte Benutzer jedes Projekt löschen.
- router.delete("/projects/:id", requireRole("admin"),- loadProject, deleteProject)+ router.delete("/projects/:id", loadProject, deleteProject)Dies entfernt die Rollenprüfung von einem zerstörerischen Endpunkt. Das Auth-Middleware bestätigt zwar, dass der Aufrufer angemeldet ist, aber CC6.1 geht darum, ob er für diese Aktion autorisiert ist - und das Löschen eines beliebigen Projekts ist nicht etwas, das jeder Benutzer tun können sollte. Stellen Sie die Autorisierungsprüfung (eine Rollen- oder Besitzprüfung für das Projekt) vor dem Handler wieder her.
CC6.1 wird stichprobenartig überprüft, nicht nur behauptet.
Bei einer SOC-2-Prüfung reicht es nicht aus, dass ein Richtliniendokument besagt, dass Sie das Prinzip des Least Privilege anwenden. Der Prüfer überprüft den tatsächlichen Zugriff: Wer und was kann auf ein bestimmtes System zugreifen, ob diese Berechtigungen mit den dokumentierten Rollen übereinstimmen und ob etwas weiter gefasst ist als sein Zweck. Eine Wildcard-Rolle, ein Endpunkt ohne Autorisierungsprüfung oder ein Service-Account mit dauerhaftem Zugriff, den er nie nutzt, sind genau die Art von Ausnahmen, die zu einem Befund führen - und diese sind meist in einem einzigen Pull Request Monate zuvor in das System gelangt. Wenn die Änderung im Diff erkannt wird, hilft dies, solche Zugriffsausnahmen aus der Stichprobe herauszuhalten.
Eine Überprüfung, keine Bestätigung.
heygrc markiert Änderungen, die CC6.1 betreffen, und verweist auf das Kriterium, damit die Korrektur im Pull Request erfolgt. Es führt keine Prüfung durch und gibt keine Stellungnahme ab. Es erkennt die Zugriffsänderung frühzeitig, sodass die Prüfung weniger Ausnahmen zu erklären hat.