Refael Angel, Co-Fondatore e CTO di Akeyless – Serie di Interviste

Refael Angel, Co-Fondatore e CTO di Akeyless, è un leader nel settore della sicurezza informatica e dell’ingegneria del software con una profonda esperienza nella sicurezza cloud, crittografia, autenticazione delle macchine e infrastrutture aziendali. Dal 2018, quando ha co-fondato Akeyless, ha contribuito a costruire l’azienda intorno alla gestione moderna dei segreti e alla sicurezza dell’identità per ambienti cloud-native. Prima di Akeyless, ha lavorato come Senior Software Engineer in Security presso Intuit, dove ha costruito sistemi per la gestione delle chiavi di crittografia nel cloud pubblico e l’autenticazione delle macchine, acquisendo esperienza diretta su AWS, Go, Python, Java, PHP, Bash, Linux, Git e Jenkins. All’inizio della sua carriera, Angel ha ricoperto ruoli di ingegneria del software presso 3D Systems e Cimatron, sviluppando applicazioni CAD/CAM e basate su Windows utilizzando C/C++, C#, WPF, MFC e pattern di progettazione orientata agli oggetti.

Akeyless è un’azienda di sicurezza dell’identità che si concentra sulla protezione delle macchine, degli agenti AI e degli esseri umani attraverso una piattaforma cloud-native costruita intorno alla crittografia a conoscenza zero. La sua piattaforma combina la gestione dei segreti, la gestione delle chiavi di crittografia, la gestione del ciclo di vita dei certificati, l’accesso privilegiato e la sicurezza dell’identità delle macchine, fornendo alle organizzazioni un modo unificato per gestire credenziali, chiavi, certificati e accessi in ambienti ibridi, multi-cloud, DevOps e AI. La posizione dell’azienda riflette un più ampio cambiamento nella sicurezza informatica: poiché i carichi di lavoro, i servizi e gli agenti AI eseguono sempre più l’accesso al sistema senza un coinvolgimento umano diretto, le aziende necessitano di controlli più solidi intorno alle identità non umane, alle credenziali a breve termine, alla rotazione automatizzata e alla governance in fase di esecuzione.

Hai co-fondato Akeyless nel 2018 dopo aver costruito sistemi di gestione delle chiavi di crittografia e autenticazione delle macchine presso Intuit. Qual è stato il divario nella sicurezza cloud e nella gestione dell’identità che ti ha convinto che era il momento di iniziare Akeyless, e come la tua visione originale è evoluta con l’emergere degli agenti AI come una nuova classe di identità digitali?

Presso Intuit, facevo parte del team che costruiva sistemi di gestione delle chiavi di crittografia e autenticazione delle macchine in un momento in cui Intuit era una delle prime grandi aziende a spostarsi sul cloud. Ciò che mi è diventato chiaro era che ogni organizzazione che adotta il cloud affronterà alla fine lo stesso problema che stavamo risolvendo internamente: come gestire i segreti e le chiavi attraverso infrastrutture distribuite e dinamiche. Costruire questo in-house consuma enormi risorse di ingegneria e non ha senso che ogni azienda debba reinventarlo. La risposta logica era un modello SaaS.

Il problema era la fiducia. Questo è il materiale più sensibile che un’azienda possiede, e nessuna organizzazione seria concederà a un terzo la possibilità di accedervi. Quindi il requisito era quasi contraddittorio: consegnarlo come SaaS per scala e semplicità, ma rendere architettonicamente impossibile per il fornitore vedere i dati del cliente. Quella tensione è esattamente ciò che ha dato vita alla crittografia a frammenti distribuiti (DFC). La DFC ci consente di eseguire un piano di controllo SaaS completamente gestito mentre il cliente detiene un frammento che noi non possediamo, quindi siamo matematicamente impossibilitati ad accedere alle sue chiavi. Ciò è diventato il fondamento del modello SaaS più Zero-Conoscenza su cui Akeyless è costruito.

La visione originale era quella di proteggere l’accesso umano e delle macchine nel cloud. Gli agenti AI sono l’estensione naturale e più estrema dello stesso problema. Operano a una scala e velocità a cui nessun directory è stato progettato, e lo stesso fondamento Zero-Conoscenza, centrato sull’identità, si estende ora direttamente a loro.

Sei accreditato come l’architetto dietro la tecnologia di crittografia Zero-Trust brevettata da Akeyless. Quali sono stati i più grandi sfidi tecnici nel costruire un modello di sicurezza che potesse eliminare le ipotesi di fiducia rimanendo pratico per grandi aziende?

La parte più difficile è stata rendere “non fidarsi di nessuno” pratico piuttosto che accademico. La maggior parte degli schemi di condivisione di segreti o chiavi divise ancora assembla la chiave completa in un momento, di solito all’interno di un singolo processo, HSM o enclave al momento di un’operazione crittografica. Quella finestra breve è esattamente ciò che gli attaccanti, gli insider malintenzionati e gli scenari di coercizione legale prendono di mira.

Con la DFC, la chiave non viene mai assemblata, non alla creazione, non a riposo e non durante l’uso. I frammenti vengono generati in modo indipendente in domini di fiducia separati e le operazioni crittografiche vengono eseguite come un calcolo distribuito in cui ogni detentore di frammento calcola la sua quota localmente e solo i risultati parziali vengono scambiati. La sfida ingegneristica è stata raggiungere ciò con la latenza, la velocità e l’affidabilità che le grandi aziende richiedono in produzione.

Una seconda sfida, e una delle più significative, è stata abilitare il rinfresco continuo dei frammenti. Dovevamo essere in grado di sostituire ogni frammento con un nuovo valore matematico, in ogni posizione, mentre la chiave master sottostante che i frammenti rappresentano rimane invariata e il processo crittografico non viene mai interrotto. Ciò ha aggiunto uno strato di sicurezza sostanziale alla soluzione. A causa del rinfresco, un attaccante non può più raccogliere frammenti con pazienza nel tempo. Un frammento catturato la scorsa settimana è matematicamente non correlato ai frammenti che esistono oggi, quindi è rumore piuttosto che un vantaggio. Per imparare qualcosa su una chiave, un avversario dovrebbe compromettere ogni posizione di frammento simultaneamente, all’interno di una singola finestra di rinfresco, e quel requisito diventa esponenzialmente più difficile man mano che aumentano le posizioni, i domini di fiducia e la frequenza di rinfresco. Combinato con la soglia tutto-o-nulla, in cui il 100% dei frammenti è necessario per rivelare qualcosa e qualsiasi subset strettamente più piccolo non fornisce informazioni, il rinfresco trasforma il modello di sicurezza da una garanzia statica a una basata sul tempo.

Molte organizzazioni stanno correndo per distribuire agenti AI, ma la sicurezza dell’identità rimane spesso un pensiero secondario. Quali sono gli errori più comuni che le aziende commettono quando concedono agli agenti AI l’accesso ai sistemi e ai dati sensibili aziendali?

L’errore più grande è trattare un agente come un account di servizio e fornirgli una chiave API statica e a lunga durata. Quella credenziale diventa un asset permanente e raccolto che si trova all’interno di un attore non deterministico e iniettabile.

Gli altri errori comuni che vedo: concedere privilegi permanenti invece di un accesso just-in-time, affidarsi a permessi basati su ruoli grossolani che descrivono cosa un agente può raggiungere ma mai cosa intende fare, fornire agli agenti percorsi di rete diretti per database e API in modo che un compromesso diventi un movimento laterale, e non avere una catena di audit che collega un’azione dell’agente al prompt umano e all’intento che lo ha scatenato. Ognuno di questi è un tentativo di adattare controlli dell’era umana a qualcosa che non si comporta come un umano.

Akeyless ha sostenuto che gli agenti AI richiedono un modello di identità fondamentalmente diverso da quello degli esseri umani o dei carichi di lavoro delle macchine tradizionali. Cosa rende gli agenti AI particolarmente difficili da proteggere rispetto ai framework IAM e PAM esistenti?

L’errore fondamentale è trattare gli agenti AI come un nuovo tipo di utente, o anche come un nuovo tipo di account di servizio, e supporre che possano essere onboardati e governati come identità umane. Questo è un errore di categoria, per diverse ragioni collegate.

Le identità degli agenti non sono enumerabili. L’istanza specifica che si desidera governare di solito non esiste ancora, e nel momento in cui esiste, è già scomparsa. Un agente può avviarsi su un Lambda, eseguire per 800 millisecondi e svanire prima che un qualsiasi scanner se ne accorga, o generare catene di sottogenti attraverso VM, container e serverless che si completano in secondi. Registrare questi in un directory significa trattare i fantasmi come residenti: nel momento in cui l’iscrizione si commit, l’entità che descriveva è già scomparsa.

L’ancoraggio giusto è quindi non l’agente, ma l’identità del carico di lavoro che il runtime emette già, il ruolo di esecuzione AWS, il token del servizio account Kubernetes, il token SVID SPIFFE. Quell’identità già esiste, è garantita dalla piattaforma su cui l’agente esegue e scompare quando l’agente scompare. Poiché le identità sono effimere, le sole entità stabili per scrivere politiche tra sono i metodi di autenticazione e i sistemi di destinazione, non identità nominate e ambiti.

E questo è dove esistono i framework IAM e PAM più decisivamente: RBAC e ABAC statici non possono contenere un attore non deterministico. Un agente con un token perfettamente ambito e un TTL perfettamente applicato può ancora essere iniettato, può ancora generare una query distruttiva o può cambiare da un compito di lettura a uno di scrittura nella stessa sessione, senza alcuna violazione della politica visibile al livello di autorizzazione. RBAC e ABAC valutano all’autenticazione, non dopo, perché ciò che accade dopo è deciso da un LLM che guarda una finestra di contesto che l’autore della politica non può vedere.

Quindi gli agenti sono particolarmente difficili da proteggere perché sono effimeri, non deterministici, multi-sostanza e iniettabili tutti insieme. Il livello mancante non è un directory migliore. È un controllo di applicazione consapevole dell’intento su ogni azione, mediato da un gateway che controlla cosa l’agente sta facendo effettivamente contro ciò che ha detto che avrebbe fatto, prima che qualsiasi credenziale venga coniata.

C’è una discussione in corso sulle architetture “senza segreti” per i sistemi AI. Come definisci l’autenticazione senza segreti e perché credi che le credenziali statiche e le chiavi API stanno diventando insostenibili nell’era degli agenti autonomi?

L’autenticazione senza segreti significa che l’agente non detiene mai una credenziale. Invece di fornire all’agente una chiave che deve archiviare e presentare, l’agente si autentica attraverso la sua identità di carico di lavoro nativa e una credenziale a breve termine e just-in-time viene iniettata in una sessione brokerata nel momento dell’esecuzione, quindi distrutta quando la sessione termina. L’agente non la vede mai.

Le credenziali statiche e le chiavi API stanno diventando insostenibili per una ragione semplice: un segreto che un agente detiene è un segreto che un attaccante può rubare. In un mondo in cui l’attore che detiene la credenziale può essere iniettato o può allucinare, una chiave a lunga durata diventa una perdita di chiave ogni volta che un agente viene compromesso. Rimuovere la credenziale dall’agente e un agente compromesso non ha nulla da perdere. Questo è l’intero punto di ciò che chiamiamo SecretlessAI.

Man mano che gli agenti AI guadagnano la capacità di pianificare, eseguire azioni e interagire con più sistemi in modo indipendente, quali nuovi vettori di attacco ti preoccupano di più nei prossimi tre o cinque anni?

I vettori che mi preoccupano di più derivano tutti dal fatto che gli agenti possono pianificare e agire attraverso sistemi in modo indipendente. L’iniezione di prompt che dirotta l’intento di un agente a metà di un compito è il più chiaro, perché l’identità rimane valida anche se il comportamento diventa malintenzionato. Oltre a questo, mi preoccupo dei passaggi di agente-agente in cui l’autorità viene passata lungo una catena senza chiara responsabilità, del movimento laterale attraverso agenti che hanno una diretta raggiungibilità di rete e dell’esfiltrazione dei dati in cui un agente sovraautorizzato recupera molto più di quanto richiesto dal suo compito.

Il filo comune è che la credenziale e il ruolo possono essere perfettamente legittimi mentre l’azione non lo è. Le difese che controllano solo il permesso e non lo scopo non cattureranno alcuno di questi. È per questo che il controllo consapevole dell’intento a un gateway, su ogni singola azione, è il controllo che credo importerà di più.

Stiamo assistendo a un passaggio dalla sicurezza delle identità umane alla sicurezza delle identità delle macchine e degli agenti. Come vedi cambiare l’equilibrio delle priorità di sicurezza man mano che le organizzazioni iniziano a gestire milioni di identità non umane attraverso la loro infrastruttura?

Stiamo entrando in un mondo in cui la stragrande maggioranza dell’accesso al sistema è eseguita da identità non umane, macchine, carichi di lavoro e ora agenti, eppure la maggior parte degli strumenti presume ancora che ci sia un umano alla tastiera. Il risultato è che ci sono segreti ovunque, privilegi permanenti e identità che nessuno può completamente tracciare.

Il passaggio delle priorità è dalla sicurezza umana a un controllo continuo e in fase di esecuzione su scala macchina. Quando si gestiscono milioni di identità non umane, non si può fare affidamento su iscrizioni, campagne di certificazione e verifiche di accesso trimestrali. È necessario un’identità efimera per costruzione, zero privilegi permanenti e politiche valutate automaticamente su ogni azione. La sicurezza dell’identità umana non scompare, ma diventa una frazione più piccola della superficie, e l’architettura deve essere costruita per la maggioranza non umana per prima.

Recenti ricerche suggeriscono che gli agenti AI potrebbero già accedere a informazioni al di là delle loro autorizzazioni previste. Quali controlli di governance e di runtime dovrebbero avere le organizzazioni prima di consentire agli agenti di operare autonomamente in ambienti di produzione?

Prima che qualsiasi agente operi autonomamente in produzione, vorrei avere alcune cose in atto. In primo luogo, nessuna credenziale permanente sull’agente, con accesso just-in-time e a breve termine iniettato per sessione. In secondo luogo, nessun percorso di rete diretto, quindi ogni azione dell’agente è brokerata attraverso un punto di controllo obbligatorio piuttosto che raggiungere database e API direttamente. In terzo luogo, un controllo di politica consapevole dell’intento che valuta lo scopo di una richiesta contro il prompt di origine prima che qualsiasi credenziale venga coniata, in modo che un agente chiesto di analizzare i ricavi non possa emettere un comando distruttivo. In quarto luogo, un’ispezione e una maschera di risposta in fase di sessione in modo che i dati sensibili come PII e PHI vengano oscurati prima di entrare nella finestra di contesto dell’agente. E in quinto luogo, un record di audit unico e immutabile che collega il prompt umano, l’intento classificato, il verdetto di politica, la sessione e l’azione finale.

La scoperta e la visibilità sono importanti anche loro, ma come input per la politica, non come prerequisito per la protezione. Dovresti essere in grado di governare un agente la prima volta che si autentica, anche se non hai mai visto quell’istanza specifica prima.

L’industria si concentra spesso sulla sicurezza del modello, ma si presta meno attenzione all’identità, all’autorizzazione e al controllo di accesso. Perché credi che queste aree diventeranno alcune delle sfide di sicurezza più importanti dell’era AI?

La sicurezza del modello fa notizia, ma un modello perfettamente allineato deve ancora agire nel mondo reale e, nel momento in cui agisce, ha bisogno di accesso ai sistemi e ai dati. Quell’accesso è dove si verifica il danno reale. Un modello che non tocca mai un database non può esfiltrarlo. Il rischio si materializza al confine di autorizzazione.

L’autorizzazione è anche la parte più difficile della sicurezza degli agenti, perché l’attore è non deterministico ed efimero. Non puoi risolverlo solo a livello di modello e non puoi risolverlo con ruoli statici. Richiede un controllo continuo e consapevole dell’intento su ogni azione. Questo è un lavoro di infrastruttura non glamour, che è esattamente il motivo per cui è sotto-discusso e esattamente il motivo per cui si rivelerà essere uno dei problemi di sicurezza più importanti di questa era.

Guardando avanti, credi che le aziende richiederanno alla fine un livello di identità dedicato per gli agenti AI, simile a come i fornitori di identità sono diventati essenziali per gli utenti umani, e quale sarebbe l’architettura di quel futuro?

Sì, ma non assomiglierà al modello del fornitore di identità umana semplicemente ribattezzato per gli agenti. Provare a costruire un directory di agenti significa costruire un directory per fantasmi, identità che sono scomparse prima di finire di iscriverle.

Il livello di identità dell’agente che mi aspetto sarà ancorato all’identità del carico di lavoro che il runtime emette, IAM cloud, token di account di servizio Kubernetes, federazione OIDC e standard come SPIFFE/SPIRE che sono già provati in produzione e cross-sostanza. L’autorizzazione sarà espressa come relazioni tra metodi di autenticazione e sistemi di destinazione piuttosto che tra identità nominate e ambiti. E il centro di gravità sarà un piano di applicazione in fase di esecuzione, un gateway che controlla ogni azione, classifica l’intento, inietta credenziali efimere, maschera risposte sensibili e produce una catena di audit completa. L’identità è ancora importante, ma si inserisce dietro il controllo piuttosto che davanti. Quel livello di autorità in fase di esecuzione, che siede sulla stessa piattaforma che già governa l’accesso umano e delle macchine, è ciò che credo che ogni azienda che esegue agenti in produzione finirà per avere bisogno.

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Akeyless.