Refael Angel, Co-Fondator și CTO al Akeyless – Seria de Interviuri

Refael Angel, Co-Fondator și CTO al Akeyless, este un lider în domeniul securității cibernetice și al ingineriei software, cu o experiență profundă în securitatea cloud, criptare, autentificare mașină și infrastructură de întreprindere. De la co-fondarea Akeyless în 2018, el a ajutat la construirea companiei în jurul gestionării moderne a secretelor și securității identității pentru medii cloud-native. Înainte de a se alătura Akeyless, el a lucrat ca Inginer Software Senior în Securitate la Intuit (INTU ), unde a construit sisteme pentru gestionarea cheilor de criptare și autentificarea mașinilor în cloud public, câștigând experiență practică în AWS, Go, Python, Java, PHP, Bash, Linux, Git și Jenkins. La începutul carierei sale, Angel a ocupat roluri de inginer software la 3D Systems (DDD ) și Cimatron, dezvoltând aplicații CAD/CAM și bazate pe Windows, utilizând C/C++, C#, WPF, MFC și modele de proiectare orientate pe obiecte.

Akeyless este o companie de securitate a identității care se concentrează pe securizarea mașinilor, agenților AI și oamenilor prin intermediul unei platforme cloud-native construite în jurul criptografiei cu cunoașterea zero. Platforma sa combină gestionarea secretelor, gestionarea cheilor de criptare, gestionarea ciclului de viață al certificatelor, accesul privilegiat și securitatea identității mașinilor, oferind organizațiilor o modalitate unificată de a gestiona credențiale, chei, certificate și acces în medii hibride, multi-cloud, DevOps și AI. Poziționarea companiei reflectă o schimbare mai largă în securitatea cibernetică: pe măsură ce sarcinile de lucru, serviciile și agenții AI efectuează din ce în ce mai mult accesul la sistem fără implicarea directă a oamenilor, întreprinderile au nevoie de controale mai puternice în jurul identităților non-umane, credențialelor cu durată de viață scurtă, rotației automate și guvernanței în timp de execuție.

Ați co-fondat Akeyless în 2018, după ce ați construit sisteme de gestionare a cheilor de criptare și autentificare mașină la Intuit. Care a fost lacuna în securitatea cloud și gestionarea identității care v-a convins că este momentul să începeți Akeyless, și cum s-a evoluat acea viziune inițială odată cu apariția agenților AI ca o nouă clasă de identități digitale?

La Intuit, am făcut parte din echipa care a construit sisteme de gestionare a cheilor de criptare și autentificare mașină, într-un moment în care Intuit era una dintre primele întreprinderi mari care s-a mutat în cloud. Ce a devenit clar pentru mine a fost că fiecare organizație care adoptă cloud-ul va întâmpina în cele din urmă aceeași problemă pe care o rezolvam intern: cum să gestioneze secrete și chei în infrastructuri distribuite și dinamice. Construirea acestui sistem în interior consumă resurse uriașe de inginerie, și nu are sens ca fiecare companie să reinventeze roata. Răspunsul logic a fost un model SaaS.

Prinsa a fost încrederea. Acesta este cel mai sensibil material pe care o întreprindere îl deține, și nicio organizație serioasă nu va oferi unei părți terțe capacitatea de a accesa acest material. Așadar, cerința a fost aproape contradictorie: livrați-l ca SaaS pentru scalabilitate și simplitate, dar faceți-o astfel încât să fie imposibil din punct de vedere arhitectural pentru furnizor să vadă vreodată datele clientului. Această tensiune este exact ceea ce a dat naștere criptografiei cu fragmente distribuite (DFC). DFC ne permite să rulăm un plan de control SaaS complet gestionat, în timp ce clientul deține un fragment pe care noi nu îl posedăm niciodată, astfel încât suntem matematic incapabili să accesăm cheile lor. Acesta a devenit fundamentul modelului SaaS plus Zero-Knowledge pe care Akeyless este construit.

Viziunea inițială a fost despre securizarea accesului uman și mașină în cloud. Agenții AI sunt extensia naturală și cea mai extremă a aceleiași probleme. Ei sunt identități non-umane care operează la o scară și viteză pentru care niciun director nu a fost proiectat, și aceeași fundație Zero-Knowledge, centrată pe identitate, se extinde acum direct la ei.

Sunteți creditat ca arhitectul din spatele tehnologiei de criptare Zero-Trust patentate a Akeyless. Care au fost cele mai mari provocări tehnice în construirea unui model de securitate care să poată elimina ipotezele de încredere, rămânând în același timp practic pentru întreprinderile mari?

Cea mai grea parte a fost să facem “încredere în nimeni” practic, mai degrabă decât academic. Majoritatea schemelor de împărțire a cheilor sau a secretelor încă asamblează cheia completă la un moment dat, de obicei în interiorul unui singur proces, HSM sau enclave la momentul unei operații criptografice. Acest scurt interval de timp este exact ceea ce atacatorii, insiderii malefici și scenariile de constrângere legală țintesc.

Cu DFC, cheia nu este niciodată asamblată, nici la creare, nici în repaus, și nici în timpul utilizării. Fragmentele sunt generate independent în domenii de încredere separate, și operațiile criptografice rulează ca o calculare distribuită în care fiecare deținător de fragmente calculează partea sa local și numai rezultate parțiale sunt schimbate. Provocarea de inginerie a fost să atingem acest lucru cu latența, debitul și fiabilitatea pe care întreprinderile mari le cer în producție.

O a doua provocare, și una dintre cele mai semnificative, a fost să permitem refresharea continuă a fragmentelor. Trebuia să putem înlocui fiecare fragment cu o nouă valoare matematică, în fiecare locație, în timp ce cheia mașteră pe care o reprezintă fragmentele rămâne neschimbată și procesul criptografic nu este niciodată întrerupt. Acest lucru a adăugat un strat substanțial de securitate soluției. Deoarece fragmentele pot fi refreshate, un atacator nu mai poate colecta fragmente cu răbdare în timp. Un fragment capturat săptămâna trecută este matematic nepotrivit cu fragmentele care există astăzi, deci este zgomot în loc de un punct de plecare. Pentru a afla ceva despre o cheie, un adversar ar trebui să compromită fiecare locație de fragmente simultan, într-o singură fereastră de refresh, și această cerință devine exponențial mai grea pe măsură ce crește numărul de locații, domenii de încredere și frecvența refresh-ului. În combinație cu pragul totul-sau-nimic, în care 100% din fragmente sunt necesare pentru a dezvălui orice informație și orice subset strict necesită zero informații, refresh-ul transformă modelul de securitate dintr-o garanție statică într-una legată de timp.

Numeroase organizații se grăbesc să implementeze agenți AI, dar securitatea identității rămâne adesea o gândire ulterioară. Care sunt cele mai comune greșeli pe care companiile le fac atunci când oferă agenților AI acces la sisteme și date sensibile ale întreprinderii?

Cea mai mare greșeală este tratarea unui agent ca pe un cont de serviciu și oferirea lui a unei chei API statice și cu durată de viață lungă. Această credențială devine un activ permanent și care poate fi recoltat, situat într-un actor non-determinist și injectabil cu prompt.

Alte erori comune pe care le văd: acordarea de privilegii permanente în loc de acces just-in-time, bazarea pe permisiuni bazate pe roluri grosiere care descriu ce poate accesa un agent, dar nu și ce intenționează să facă, oferirea agenților directe căi de rețea către baze de date și API-uri, astfel încât o compromitere devine mișcare laterală, și lipsa unei lanțuri de audit care leagă acțiunea unui agent de promptul uman și de intenția care a declanșat-o. Fiecare dintre acestea este o încercare de a retrofita controale create pentru oameni pe ceva care nu se comportă ca un om.

Akeyless a susținut că agenții AI necesită un model de identitate fundamental diferit de cel al oamenilor sau al sarcinilor de lucru mașină tradiționale. Ce face ca agenții AI să fie atât de greu de securizat în comparație cu cadrele IAM și PAM existente?

Greșeala de bază este tratarea agenților AI ca pe un nou tip de utilizator sau chiar ca pe un nou tip de cont de serviciu, și presupunerea că pot fi înscriși și guvernați ca identități umane. Acesta este un eroare de categorie, din mai multe motive conectate.

Identitățile agenților nu sunt enumerabile. Instanța specifică pe care doriți să o guvernați de obicei nu există încă, și până când există, a dispărut deja. Un agent poate apărea pe un Lambda, rulează timp de 800 de milisecunde și dispare înainte ca vreun scanner să observe, sau poate genera lanțuri de sub-agenți pe VM-uri, containere și serverless care se finalizează în secunde. Înregistrarea acestora într-un director este ca și cum ați trata fantome ca rezidenți: până când intrarea se finalizează, entitatea pe care a descris-o a dispărut.

Punctul de ancorare corect este deci nu agentul, ci identitatea sarcinii de lucru pe care o emite already runtime-ul, rolul de execuție AWS, tokenul de cont de serviciu Kubernetes, OIDC federation și standarde precum SPIFFE/SPIRE care sunt deja dovedite în producție și cross-substrate. Autorizarea va fi exprimată ca relații între metodele de autentificare și sistemele țintă, și nu între identități numite și scopuri. Și centrul de greutate va fi un plan de executare în timp de execuție, o poartă care mediază fiecare acțiune, clasifică intenția, injectează credențiale efemere, maschează răspunsuri sensibile și produce o lanț de audit complet. Identitatea încă mai contează, dar cade în spatele executării, și nu în fața ei.

Există o discuție în creștere în jurul arhitecturilor “fără secrete” pentru sistemele AI. Cum definiți autentificarea fără secrete, și de ce credeți că credențialele statice și cheile API devin nesustenabile în era agenților autonomi?

Autentificarea fără secrete înseamnă că agentul nu deține niciodată o credențială. În loc de a oferi agentului o cheie pe care trebuie să o stocheze și să o prezinte, agentul se autentifică prin identitatea sa de sarcină de lucru nativă, și o credențială cu durată de viață scurtă și just-in-time este injectată într-o sesiune brokerată în momentul execuției, apoi distrusă atunci când sesiunea se încheie. Agentul nu o vede niciodată.

Credențialele statice și cheile API devin nesustenabile dintr-un motiv simplu: un secret pe care un agent îl deține este un secret pe care un atacator îl poate fura. Într-o lume în care actorul care deține credențiala poate fi injectat cu prompt sau poate halucina, o cheie cu durată de viață lungă devine o scurgere de chei atunci când un agent este compromis. Îndepărtați credențiala de la agent, și un agent compromis nu are nimic de scurs. Acesta este scopul nostru numit SecretlessAI.

Pe măsură ce agenții AI capătă capacitatea de a planifica, executa acțiuni și interacționa cu multiple sisteme în mod independent, care sunt noile vectori de atac care vă preocupă cel mai mult în următorii trei până la cinci ani?

Vectorii care mă preocupă cel mai mult toți provin din faptul că agenții pot planifica și acționa independent peste sisteme. Injectarea de prompt care preia intenția unui agent în mijlocul unei sarcini este cel mai clar, deoarece identitatea rămâne valabilă chiar și atunci când comportamentul devine malign. Dincolo de aceasta, mă tem de transferurile de autoritate de la agent la agent, unde responsabilitatea este transferată de-a lungul unei lanțuri fără o contabilitate clară, de mișcarea laterală prin agenți care au acces direct la rețea, și de exfiltrarea datelor în care un agent supraautorizat extrage mult mai mult decât necesită sarcina sa.

Fila comună este că credențiala și rolul pot fi perfect legitimi, în timp ce acțiunea nu este. Apărările care verifică doar permisiunea, și nu scopul, nu vor prinde niciunul dintre acestea. De aceea, executarea conștientă de intenție la o poartă, pe fiecare acțiune, este controlul pe care cred că va conta cel mai mult.

Când ne uităm înainte, credeți că întreprinderile vor avea nevoie în cele din urmă de un strat de identitate dedicat pentru agenții AI, similar cu modul în care furnizorii de identitate au devenit esențiali pentru utilizatorii umani, și cum ar arăta acea arhitectură viitoare?

Da, dar nu va arăta ca modelul de furnizor de identitate pentru utilizatori umani, reetichetat pentru agenți. Încercarea de a construi un director de agenți este ca și cum ați construi un director pentru fantome, identități care dispar înainte de a termina înscrierea lor.

Stratul de identitate al agentului pe care mă aștept să se dezvolte va ancora identitatea la sarcina de lucru pe care runtime-ul o emite, IAM cloud, tokenuri de cont de serviciu Kubernetes, federație OIDC și standarde precum SPIFFE/SPIRE care sunt deja dovedite în producție și cross-substrate. Autorizarea va fi exprimată ca relații între metodele de autentificare și sistemele țintă, și nu între identități numite și scopuri. Și centrul de greutate va fi un plan de executare în timp de execuție, o poartă care mediază fiecare acțiune, clasifică intenția, injectează credențiale efemere, maschează răspunsuri sensibile și produce o lanț de audit complet. Identitatea încă mai contează, dar cade în spatele executării, și nu în fața ei. Stratul de autoritate în timp de execuție, situat pe aceeași platformă care guvernează deja accesul uman și mașină, este ceea ce cred că fiecare întreprindere care rulează agenți în producție va avea nevoie în cele din urmă.

Mulțumim pentru acest interviu minunat, cititorilor care doresc să afle mai multe, le recomandăm să viziteze Akeyless.