L'autenticazione a più fattori, spesso chiamata MFA, è un secondo controllo oltre a una password: un codice da un'app, un SMS o una chiave fisica. Se sia obbligatoria per un'azienda di software non è rispondibile con un semplice sì o no, poiché la direttiva NIS2 non prescrive una tecnologia specifica. L'articolo 21 obbliga le organizzazioni soggette all'obbligo di due diligence ad adottare misure appropriate per la protezione degli accessi e l'autenticazione a più fattori, e le autorità di vigilanza valutano dove il rischio è maggiore.
Per un'azienda di software, in pratica si tratta di due contesti molto diversi: la catena di sviluppo con cui lavorate voi stessi, e il software che consegnate ai clienti. Entrambi richiedono una valutazione autonoma, e tale valutazione non è ugualmente rigorosa ovunque.
Due contesti in cui l'autenticazione a più fattori ha un ruolo
Il primo contesto è interno: l'ambiente in cui lavorano i vostri sviluppatori. Codice sorgente, catena di sviluppo, console cloud e i sistemi con cui eseguite il deploy in produzione. Il secondo contesto risiede nel prodotto stesso: se il software che costruite o consegnate dispone di una schermata di accesso, l'autenticazione a più fattori è un argomento anche lì, sia per i vostri stessi utenti che per gli utenti finali del vostro cliente. Un questionario di sicurezza di un committente chiede quasi sempre di entrambi, spesso in domande separate formulate diversamente da come vi aspettereste.
Per l'accesso alla vostra catena di sviluppo
Qui l'aspettativa è più forte. Chi può accedere al codice sorgente, chi può eseguire il deploy in produzione e chi dispone di diritti di amministrazione sull'ambiente cloud rappresenta il rischio maggiore se una password viene semplicemente rubata o riutilizzata. Per questi account l'autenticazione a più fattori è considerata una misura fondamentale in quasi ogni framework di sicurezza, ed è anche ciò che le autorità di vigilanza e i clienti si aspettano innanzitutto. La gestione delle versioni, la catena di sviluppo stessa, e soprattutto ogni account con diritti di portare il codice in produzione, in pratica dovrebbe senza eccezione disporre di un secondo fattore.
A ciò va aggiunto anche uno sguardo a chi ha veramente ancora bisogno di tale accesso. Un dossier in cui per ogni sistema è indicato chi vi può accedere e perché, rende più facile rispondere a questa domanda in un questionario con una risposta concreta piuttosto che con un'ipotesi. come il controllo degli accessi e l'autenticazione a più fattori vengono spiegati per ogni argomento fornisce un punto di partenza a questo proposito.
Per il software che consegnate
Il secondo contesto è il software stesso. Se il vostro prodotto dispone di una funzione di accesso, la domanda se offriate l'autenticazione a più fattori ricorre quasi sempre in un questionario di sicurezza, e a volte anche come requisito contrattuale. Si tratta di una valutazione diversa rispetto alla vostra catena di sviluppo interna: qui non si tratta di ciò che usate voi stessi, ma di ciò che consegnate al vostro cliente. Un committente che a sua volta è soggetto all'obbligo di due diligence deve secondo l'articolo 21 valutare anche la sua catena di fornitura, e la domanda se il vostro prodotto supporta un'autenticazione robusta ne fa parte.
La risposta non deve necessariamente essere che sia obbligatorio ovunque. Spesso è sufficiente dimostrare che la possibilità esiste, che gli utenti sono incoraggiati a utilizzarla, e che avete un piano per estenderla dove il rischio lo giustifica.
Dove è meno scontato
Non tutti gli account o gli ambienti richiedono lo stesso livello di protezione. Un ambiente di test senza dati cliente reali, un sistema di documentazione interno con soli diritti di lettura, o uno strumento ausiliario utilizzato occasionalmente da uno sviluppatore, presentano profili di rischio diversi rispetto a un account con accesso alla produzione. Le misure di gestione del rischio richiedono protezioni proporzionate ai rischi, non l'applicazione uniforme di controlli pesanti ovunque. Le autorità di vigilanza valutano questo sulla base della proporzionalità, il che significa che una scelta motivata di non applicare l'autenticazione a più fattori in determinati punti può far parte di un dossier altrettanto legittimamente quanto i luoghi in cui è invece presente.
La motivazione è qui la parola chiave. Una scelta senza spiegazione in un questionario può facilmente sembrare un'omissione, mentre la stessa scelta accompagnata da una breve giustificazione è spesso esattamente la risposta che un cliente sta cercando.
Cosa significa questo nella comunicazione con un cliente
Un cliente che invia un questionario di solito non vuole sapere se voi rispettate alla lettera ogni requisito, ma se sapete dove si trovano i vostri rischi e se li gestite in modo consapevole. Per l'autenticazione a più fattori questo significa: dimostrare cosa è implementato nella pipeline di sviluppo, cosa è implementato nel prodotto, e perché il resto è configurato diversamente. Se avete documentato tutto questo per sistema con uno stato e un responsabile, non dovrete affrontare di nuovo la domanda ogni volta che arriva un nuovo questionario.
Se e come questo si concretizza esattamente per la vostra organizzazione dipende dal vostro ruolo nella catena di fornitura e da ciò che i vostri clienti chiedono specificamente; in caso di dubbi consultate il testo della direttiva stessa o un consulente. Se desiderate sapere prima dove vi collocate, verifica gratuita risponde a pochi quesiti fornisce una prima indicazione, e una spiegazione su dove provengono le informazioni mostra come si forma quella indicazione.
Se desiderate leggere più ampiamente come questo argomento si collega alle altre misure di gestione del rischio, lo troverete in la panoramica degli argomenti per situazione. La valutazione rapida e la knowledge base sono liberamente accessibili, senza che sia necessario creare un account.