Gli ingegneri che affrontano per la prima volta SOC 2 spesso lo immaginano come un enorme audit del codice. In realtà non è così. SOC 2 è un'attestazione rispetto ai Trust Services Criteria e la maggior parte di questi criteri riguarda politiche, processi e prove che i controlli siano stati applicati in un determinato periodo. Solo una parte è determinata da ciò che fa il codice, e conoscere questa parte rende l'intero processo meno misterioso.
I criteri che interessano il codice
I criteri che coinvolgono il codice si raggruppano nella famiglia CC6 dei criteri comuni per l'accesso logico: CC6.1 (limitazione dell'accesso a ciò che un ruolo richiede), CC6.6 (protezione contro minacce esterne al confine del sistema), CC6.7 (protezione dei dati in transito e del loro spostamento), oltre a CC7.2 per il monitoraggio e CC8.1 per la gestione delle modifiche. Se puoi ragionare su chi può accedere a cosa, su come i dati sono protetti in transito e su cosa viene registrato, stai già coprendo la maggior parte della superficie di SOC 2 che interessa il codice.
È importante notare che molte delle attività che sembrano tipiche di SOC 2 in ingegneria (l'esistenza della revisione del codice, le approvazioni delle modifiche, le revisioni degli accessi) sono prove che un processo è stato applicato, raccolte al di fuori del codice. Il codice stesso riguarda principalmente la famiglia CC6.
Le eccezioni che diventano riscontri
Un revisore campiona questi controlli in un determinato periodo e formula un parere. Una singola pull request che amplia un ruolo IAM a un wildcard o abbassa il livello minimo di TLS può creare un'eccezione in quel periodo: il controllo potrebbe non essere stato applicato come descritto per quella modifica. Se individuata nella PR, è una correzione di una riga. Se individuata durante l'audit, diventa una rimediazione con una traccia cartacea.
Questa asimmetria è l'intero argomento a favore del controllo della superficie CC6 a livello di diff, piuttosto che scoprire eccezioni mesi dopo.