Chi può accedere al codice sorgente, alla pipeline e all'ambiente di produzione?
Il controllo degli accessi nello sviluppo del software riguarda la questione di chi può eseguire quale azione su quale componente della vostra pipeline di sviluppo: chi può leggere il codice, chi può modificare e integrare il codice, chi può avviare una build e chi può rilasciare in produzione. È una questione più specifica del controllo degli accessi per un'organizzazione in generale, perché un team di sviluppo lavora contemporaneamente con più sistemi: un repository del codice sorgente, un ambiente di build e test, e solitamente un ambiente di produzione separato dove il software funziona effettivamente.
Il motivo per cui questo argomento ricorre nei questionari di sicurezza e nelle misure di due diligence della direttiva NIS2 è che un errore nel controllo degli accessi alla vostra pipeline di sviluppo ha effetti diretti su tutti coloro che utilizzano il vostro software. Chi può modificare il codice senza essere notato e che successivamente viene distribuito, non riguarda solo la vostra organizzazione ma anche i vostri clienti. Pertanto, sia un'autorità di vigilanza che un cliente che è a sua volta soggetto a obblighi di due diligence, vi chiede come avete organizzato questo.
Perché riguarda specificamente il codice sorgente e la pipeline
Un team di sviluppo ha generalmente più persone con diritti più ampi di quelli strettamente necessari, semplicemente perché è pratico: tutti possono accedere ovunque, nessuno deve aspettare nulla. Dal punto di vista degli obblighi di due diligence, è esattamente il punto su cui vengono poste ulteriori domande. Non perché la fiducia sarebbe sbagliata, ma perché la dimostrabilità è diversa dalla fiducia: un'autorità di vigilanza o un cliente vuole sapere se potete provare chi ha accesso, non solo se lo ritenete affidabile.
Le domande che ricorrono generalmente riguardano tre livelli. Il primo è il repository del codice sorgente stesso: chi può leggere, chi può modificare, ed è presente un controllo obbligatorio prima che una modifica venga integrata con la versione principale. Il secondo è l'ambiente di build e test: chi può avviare una build, e quell'ambiente ha accesso a dati o sistemi non destinati a scopi di test. Il terzo è l'ambiente di produzione: chi può effettivamente distribuire un rilascio, ed è un gruppo diverso da chi scrive il codice.
Separazione tra scrittura e distribuzione
Una distinzione ricorrente nei questionari è se la persona che scrive il codice è anche quella che distribuisce il rilascio in produzione. Quando è la stessa persona, senza un passaggio intermedio di un'altra persona, si crea una situazione in cui un errore o una modifica intenzionale finisce in produzione senza essere verificata. Molte organizzazioni risolvono questo con una revisione obbligatoria da parte di un'altra persona prima che il codice venga integrato, e con un ruolo separato o diritti separati per la distribuzione effettiva. Come appare nella pratica varia notevolmente a seconda del team e delle dimensioni; la direttiva stessa non prescrive una metodologia specifica, ma le autorità di vigilanza e i clienti guardano alla questione sottostante: se una sola persona può apportare modifiche incontrollate che riguardano i clienti.
Segreti e chiavi separati dal codice
Un secondo punto su cui i questionari chiedono regolarmente chiarimenti è dove vengono archiviati i certificati di autenticazione, le chiavi API e altri segreti. I segreti che si trovano nel codice sorgente stesso sono visibili a chiunque abbia accesso in lettura a quel codice, il che può essere un gruppo molto più ampio di chi dovrebbe effettivamente utilizzare quella chiave. Un vault separato per i segreti, con diritti di accesso propri indipendenti dal repository del codice, è un modo comune per separarli. Se e come lo organizzate è una scelta tecnica; ciò che è rilevante per il dossier è soprattutto se potete spiegare perché l'approccio scelto è appropriato rispetto alle dimensioni e ai rischi di ciò che state sviluppando.
Ciò che documentate, non solo ciò che configurate
L'impostazione tecnica dei diritti di accesso è una cosa; rendere evidente come è stata realizzata è un'altra, e nella pratica questa seconda parte viene spesso dimenticata. Un elenco di chi ha accesso a quale sistema, quando è stato concesso e sulla base di quale criterio, è esattamente il documento probatorio che un questionario o un'autorità di sorveglianza richiedono. Senza quell'elenco deve ricercare la risposta ogni volta; con un registro dinamico accanto a ogni misura, la risposta è già pronta. sfogliare la spiegazione per ogni misura fornisce un'immagine di come il controllo degli accessi si rapporta alle altre nove misure dell'obbligo di diligenza.
Se la vostra organizzazione cade direttamente nell'ambito dell'obbligo di diligenza, oppure se ricevete questa domanda perché lo fa il vostro committente, può essere determinato con poche domande. Per chi si chiede quanto siano rigorosi esattamente i requisiti sul controllo degli accessi quando un cliente chiede di dimostrare cosa è stato disciplinato, la spiegazione sulla protezione e la sicurezza dei dati offre una prospettiva più ampia su da dove provengono questo genere di requisiti.
Per la vostra situazione specifica, ad esempio se una particolare configurazione della vostra pipeline di sviluppo è sufficiente per l'obbligo di diligenza che grava su di voi o sul vostro committente, l'avvocato o l'autorità di sorveglianza competente sono il luogo appropriato; secria.eu prepara la documentazione ma non esprime alcun parere sulla conformità dei singoli casi.
Desiderate vedere come il controllo degli accessi si inserisce nel resto del vostro dossier, oppure avete ancora domande su cosa si intende esattamente con questa misura? leggere le domande frequenti fornisce già una risposta breve su molti di questi punti, e la scansione rapida gratuita mostra in pochi minuti dove si trova la vostra organizzazione su questo argomento.