Le credenziali statiche sono ancora il modo più semplice per l'IA per accedere

L'IA non ha inventato la credenziale con privilegi eccessivi, ha solo trovato il modo più veloce per usarla. Ogni agente, script e integrazione che gira nel tuo ambiente si autentica con qualcosa, e nella maggior parte degli ambienti, quella cosa è una password, una chiave API o un token emesso una volta e mai più toccato. Una persona dimentica una password e alla fine viene bloccata. Un'identità macchina continua semplicemente a usare ciò che le è stato dato, finché nessuno guarda.

Più identità, più violazioni

Abbiamo intervistato 2.317 leader della sicurezza e IT quest'anno, e il numero più chiaro nei risultati è stato questo: le organizzazioni in cui l'IA ha aumentato significativamente il numero di identità nel loro ambiente hanno riportato un tasso di violazioni del 43% negli ultimi 12 mesi. Le organizzazioni in cui l'IA non ha cambiato molto il conteggio delle identità hanno riportato l'11%. È una differenza di 4 volte, e non è perché il gruppo con molta IA avesse una sicurezza complessivamente più debole. I nostri dati mostrano che erano avanti nella maggior parte delle basi.

Dove non erano avanti era identità non umana governance. Il settantasei percento delle organizzazioni ci ha detto che non governano o monitorano completamente le loro identità non umane, e solo il 19% ha detto di sì. Questa è la popolazione attraverso cui l'IA sta passando: un insieme crescente di identità macchina, la maggior parte delle quali si autentica con una credenziale che nessuno ha controllato dal giorno in cui è stata emessa.

Credenziali statiche

Una credenziale statica non scade da sola, non ruota da sola e non importa quante volte venga usata. Questo è ciò che la rende pericolosa una volta che si trova all'interno di qualcosa di automatizzato. Una persona che usa una password rubata viene notata alla fine. Un agente AI o uno script che usa una credenziale rubata continua a funzionare, alla velocità consentita dal flusso di lavoro, finché qualcuno non lo scopre.

Passi per proteggere le credenziali NHI

1. Volta

La prima mossa è estrarre le credenziali da script, file di configurazione, fogli di calcolo e codice sorgente e inserirle in un sistema progettato per conservarle. Sembra semplice e raramente lo è. Un vault deve funzionare attraverso applicazioni strategiche e legacy, coprire diversi modelli di accesso a seconda di come ogni app interagisce con una credenziale e supportare sia l'onboarding centralizzato sia la realtà che alcuni team aggiungeranno sempre credenziali manualmente. In pratica, questo significa un'architettura a più livelli: un livello di presentazione per gli utenti, un server applicativo che applica la logica di business e i permessi, e un livello di database che memorizza effettivamente i segreti, con l'opzione di scalare più server applicativi per distribuire il carico tra team geograficamente distribuiti. Il vaulting è anche il passaggio che ripaga più rapidamente, poiché è la differenza tra una credenziale che chiunque può trovare e una che è effettivamente controllata.

2. Crittografia

Una volta che una credenziale è in una cassaforte, deve rimanere criptata, con le chiavi di crittografia gestite con la stessa attenzione delle credenziali stesse. Ciò significa più che attivare AES e considerare il lavoro fatto. Una cassaforte costruita correttamente dovrebbe utilizzare la crittografia autenticata (AES-GCM 256) per le credenziali, funzioni di derivazione delle chiavi robuste con un alto numero di iterazioni per l’hashing di utenti e chiavi, e crittografia a curva ellittica per lo scambio di chiavi pubbliche-private. Ogni contenitore segreto dovrebbe avere il proprio sale generato casualmente, e ogni password, utente e ruolo dovrebbe avere la propria coppia di chiavi, così l’accesso è criptato gerarchicamente anziché protetto da una singola chiave condivisa. Per gli ambienti che si sincronizzano con Active Directory, dovrebbe essere disponibile una modalità di crittografia end-to-end, in cui il server stesso non ha mai accesso al testo in chiaro, come opzione più forte, insieme a una modalità a chiave master per le organizzazioni che necessitano di un recupero centralizzato. La chiave master stessa deve risiedere in hardware, non in un file di configurazione, protetta da un HSM. Spostare una password da testo semplice a una cassaforte crittografata costruita in questo modo è il modo più comune in cui le organizzazioni riducono il rischio delle credenziali, ed è il passo più alla portata per i team che non hanno ancora affrontato la sicurezza NHI.

3. Ciclismo e rotazione

Ruotare regolarmente le credenziali riduce il rischio legato ai dipendenti che se ne sono andati, pulisce l'esposizione presente in vecchio codice e script, e spesso fa emergere dipendenze che nessuno sapeva esistessero. È anche il passaggio più difficile da eseguire. Se non conosci ogni script e integrazione che si basa su una determinata credenziale, ruotarla può interrompere la produzione invece di ridurre il rischio.

La rotazione funziona solo come un processo continuo e automatizzato strettamente legato al vault che contiene la credenziale, non come un compito manuale che qualcuno ricorda di fare. Ciò significa reset basati su trigger, non promemoria sul calendario: reimpostare una credenziale un numero prestabilito di minuti dopo che è stata visualizzata, dopo che è rimasta invariata per un numero definito di giorni, o una volta scaduta. Significa anche che il processo deve proteggersi da solo. Se un reset scriptato fallisce a metà strada, su un account Active Directory, un utente locale Windows o Linux, o un account di servizio, il sistema dovrebbe ripristinare automaticamente la credenziale al suo ultimo valore noto valido e registrare il fallimento, invece di lasciare un account di servizio in uno stato rotto e parzialmente modificato. Ogni reset, rollback e blocco viene registrato, quindi una rotazione fallita è immediatamente visibile invece di emergere tre settimane dopo come un'interruzione che nessuno può spiegare.

La maggior parte delle organizzazioni che fanno veri progressi padroneggiano prima il vaulting e la crittografia, poi si orientano verso la rotazione automatizzata basata su trigger una volta che comprendono abbastanza bene le loro dipendenze per configurarla in modo sicuro.

Incontra Password Secure

Ogni account di servizio e account applicativo collegato ad Active Directory passa attraverso lo stesso motore di policy dei tuoi dipendenti, che qualcuno lo applichi o meno.Netwrix Password Secure copre direttamente tutti e tre i passaggi.

Ti offre un unico vault criptato per le credenziali di utenti, amministratori e servizi, con crittografia conforme a FIPS (AES-GCM 256, derivazione della chiave rafforzata PBKDF2 e scambio di chiavi con curva ellittica NIST P-521) che protegge ogni segreto. L'accesso basato sui ruoli significa che solo le persone e i processi che necessitano di una credenziale possono recuperarla, e un registro completo annota ogni prelievo, reset e rollback, così puoi sapere chi ha toccato una determinata credenziale e quando. Inoltre, il reset della password configurabile e basato su trigger gestisce la rotazione: le credenziali vengono resettate automaticamente secondo un programma o una condizione definita, con protezione rollback se un sistema target rifiuta la modifica.

Questa è la differenza tra una password di account di servizio che vive indefinitamente in un foglio di calcolo, mai ruotata perché nessuno vuole rischiare di rompere qualcosa, e vivere in un luogo dove è crittografata, controllata negli accessi, registrata e ruotata secondo un programma che l'organizzazione controlla effettivamente.