Minimo privilegio, applicato alla diff.
CC6.1 è uno dei Trust Services Criteria che una pull request normale può indebolire silenziosamente, perché riguarda l'accesso logico, e l'accesso logico spesso risiede nel codice e nella configurazione. Il criterio richiede che l'accesso ai sistemi e ai dati sia limitato agli utenti e ai processi autorizzati. In pratica, questo significa minimo privilegio: un ruolo può accedere solo a ciò che gli serve per svolgere il proprio compito, e nient'altro.
The shapes the same control failure takes.
CC6.1 non si viola quasi mai con una riga che dice 'concedi a tutti i diritti di admin'. Si viola con modifiche ordinarie e apparentemente ragionevoli. Queste sono le forme che ricorrono.
Una policy di accesso viene allargata
Un ruolo IAM, un gruppo di sicurezza o una concessione acquisisce azioni più ampie o un wildcard, così che un componente può ora fare più di quanto necessario per il suo compito.
Un controllo di autorizzazione viene rimosso
Una route perde il controllo sul ruolo o sulla proprietà, o un middleware di autorizzazione smette di essere applicato a un nuovo endpoint, così che una richiesta che dovrebbe essere rifiutata ora ha successo.
Una concessione dati viene ampliata
Un ruolo del database ottiene accesso a tabelle o righe a cui non aveva accesso, la sicurezza a livello di riga viene allentata o un account di servizio viene puntato a un database che non aveva motivo di raggiungere.
Un valore predefinito passa a consentire
L'accesso passa da default-deny a default-allow: una nuova risorsa viene distribuita come leggibile da tutti, o un controllo dei permessi restituisce true per un caso sconosciuto.
Si apre un percorso di escalation dei privilegi
Un attore con privilegi inferiori ottiene un modo per agire come uno con privilegi superiori: una flag interna che bypassa il controllo del ruolo, o un token generato con un ambito maggiore di quello dell'utente chiamante.
Un refactoring che rimuove un controllo di autorizzazione.
Una route viene riordinata. Il controllo del ruolo al centro sembra ridondante rispetto al middleware di autenticazione, quindi viene rimosso. L'endpoint richiede ancora un utente autenticato, ma non più quello giusto: ora qualsiasi utente autenticato può eliminare qualsiasi progetto.
- router.delete("/projects/:id", requireRole("admin"),- loadProject, deleteProject)+ router.delete("/projects/:id", loadProject, deleteProject)Questo rimuove il controllo del ruolo da un endpoint distruttivo. Il middleware di autenticazione conferma che il chiamante è autenticato, ma CC6.1 riguarda se è autorizzato per questa azione, e eliminare qualsiasi progetto non è qualcosa che ogni utente dovrebbe poter fare. Ripristina il controllo di autorizzazione (un controllo sul ruolo o sulla proprietà del progetto) prima del gestore.
CC6.1 viene campionato, non solo dichiarato.
In un esame SOC 2, CC6.1 non viene soddisfatto da un documento di policy che afferma di applicare il minimo privilegio. Il revisore campiona l'accesso effettivo: chi e cosa può accedere a un determinato sistema, se quelle concessioni corrispondono ai ruoli documentati e se qualcosa è più ampio del suo scopo. Un ruolo wildcard, un endpoint privo del controllo di autorizzazione o un account di servizio con accesso permanente che non utilizza mai è esattamente il tipo di eccezione che diventa un riscontro, e di solito è entrato nel sistema in una singola pull request mesi prima. Rilevare la modifica alla diff aiuta a mantenere quelle eccezioni di accesso fuori dal campione.
Una revisione, non un'attestazione.
heygrc segnalerà le modifiche che interessano CC6.1 e citerà il criterio in modo che la correzione avvenga nella pull request. Non esegue l'audit né emette un parere. Rileva la modifica di accesso precocemente in modo che l'esame abbia meno eccezioni da spiegare.