Refael Angel, spoluzakladatel a technický ředitel Akeyless – rozhovor

Refael Angel, spoluzakladatel a technický ředitel Akeyless, je lídr v oblasti kybernetické bezpečnosti a softwarového inženýrství s hlubokými zkušenostmi v oblasti cloudové bezpečnosti, šifrování, autentizace strojů a podnikové infrastruktury. Od spoluzaložení Akeyless v roce 2018 pomohl vybudovat společnost kolem moderního řízení tajností a bezpečnosti identity pro cloudové prostředí. Před Akeyless pracoval jako seniorní softwarový inženýr v oblasti bezpečnosti ve společnosti Intuit (INTU ), kde vyvíjel systémy pro správu šifrovacích klíčů a autentizaci strojů v veřejném cloudu, a získal praktické zkušenosti s technologiemi jako AWS, Go, Python, Java, PHP, Bash, Linux, Git a Jenkins. Na počátku své kariéry zastával Angel pozice softwarového inženýra ve společnostech 3D Systems (DDD ) a Cimatron, kde vyvíjel aplikace CAD/CAM a založené na Windows pomocí C/C++, C#, WPF, MFC a objektově orientovaných návrhových vzorů.

Akeyless je společnost pro bezpečnost identity, která se zaměřuje na zabezpečení strojů, agentů AI a lidí prostřednictvím cloudové platformy založené na kryptografii s nulovou znalostí. Jejich platforma spojuje řízení tajností, správu šifrovacích klíčů, správu životního cyklu certifikátů, privilegovaný přístup a bezpečnost identity strojů, a poskytuje organizacím jednotný způsob řízení přihlašovacích údajů, klíčů, certifikátů a přístupu v hybridních, multi-cloudových, DevOps a AI prostředích. Postavení společnosti odráží širší posun v kybernetické bezpečnosti: protože pracovní zátěže, služby a agenti AI stále častěji vykonávají systémový přístup bez přímého lidského zásahu, podniky potřebují silnější kontroly nad ne-lidskými identitami, krátkodobými přihlašovacími údaji, automatizovaným otočením a runtime správou.

Vy jste spoluzakladatel Akeyless v roce 2018 po vybudování systémů pro správu šifrovacích klíčů a autentizaci strojů ve společnosti Intuit. Jaká mezera v cloudové bezpečnosti a správě identity vás přesvědčila, že je čas založit Akeyless, a jak se původní vize změnila s nástupem agentů AI jako nové třídy digitálních identit?

V Intuitu jsem byl součástí týmu, který vyvíjel systémy pro správu šifrovacích klíčů a autentizaci strojů v době, kdy Intuit byl jednou z prvních velkých podniků, které přešly do cloudu. Co mi bylo jasné, bylo, že každá organizace, která přijme cloud, nakonec bude muset řešit stejný problém, který jsme řešili interně: jak spravovat tajnosti a klíče v distribuované, dynamické infrastruktuře. Vybudování tohoto systému interně spotřebuje enormní inženýrské zdroje, a nemá smysl, aby každá společnost znovu vynalezla kolo. Logickým řešením bylo model SaaS.

Chytlavost spočívala v důvěře. Jednalo se o nejcitlivější materiál, který podnik vlastnil, a žádná vážná organizace by třetí straně nedala možnost přístupu k němu. Takže požadavek byl téměř protichůdný: dodat to jako SaaS pro měřítko a jednoduchost, a přitom udělat architektonicky nemožné, aby dodavatel mohl vidět zákaznická data. To je přesně to, co dalo vzniknout Distributed Fragments Cryptography (DFC). DFC umožňuje nám provozovat plně spravovanou SaaS řídicí rovinu, zatímco zákazník drží fragment, který my nikdy nevlastníme, takže jsme matematicky neschopni přístupu k jejich klíčům. To se stalo základem modelu SaaS plus Zero-Knowledge, na kterém je Akeyless postaven.

Původní vize se týkala zabezpečení lidského a strojového přístupu v cloudu. Agenti AI jsou přirozeným a nejextrémnějším rozšířením stejného problému. Jsou to ne-lidské identity, které fungují v měřítku a rychlosti, pro které nebyl žádný adresář navržen, a stejná Zero-Knowledge, identita-orientovaná základna se nyní rozšiřuje přímo na ně.

Jste uvedeni jako architekt za patentovanou technologii Zero-Trust šifrování Akeyless. Jaké byly největší technické výzvy při budování bezpečnostního modelu, který by mohl eliminovat předpoklady důvěry, zatímco zůstal praktický pro velké podniky?

Nejobtížnější částí bylo udělat “nedůvěřovat nikomu” praktické spíše než akademické. Většina schémat rozdělených klíčů nebo sdílení tajností stále sestavuje celý klíč v某 okamžiku, obvykle uvnitř jediného procesu, HSM nebo enklávy v okamžiku kryptografické operace. To je přesně to, co útočníci, zlověstní insideri a právní-scénáře cílí.

S DFC je klíč nikdy sestaven, ani při vytváření, ani v klidu, ani během použití. Fragmenty jsou generovány nezávisle v samostatných důvěrných oblastech, a kryptografické operace běží jako distribuovaná výpočet, kde každý držitel fragmentu lokálně počítá svou část a pouze částečné výsledky jsou vyměněny. Inženýrská výzva spočívala v dosažení tohoto s latencí, propustností a spolehlivostí, které velké podniky požadují v produkci.

Druhou výzvou, a jednou z nejvýznamnějších, bylo umožnit nepřetržitou obnovu fragmentů. Museli jsme být schopni nahradit každý fragment novou matematickou hodnotou, na každém místě, zatímco základní master klíč, který fragmenty reprezentují, zůstal nezměněn a kryptografický proces nebyl nikdy narušen. To přidalo velmi podstatnou vrstvu zabezpečení do řešení. Protože obnovení, útočník nemůže již shromažďovat fragmenty trpělivě po dobu času. Fragment zachycený minulý týden je matematicky nesouvisející s fragmenty, které existují dnes, takže je to hluk spíše než začátek. Aby se něco dozvěděl o klíči, útočník by musel kompromitovat každý fragment umístění současně, v rámci jediného okna obnovení, a tento požadavek se exponenciálně zvyšuje s místy, důvěrnými oblastmi a frekvencí obnovení. Kombinované s all-or-nothing prahem, kde 100 procent fragmentů je potřeba k odhalení čehokoli a jakékoli přísné podmnožiny úniku zero informací, obnovení změní bezpečnostní model z statické záruky do časově vázané.

Mnohé organizace spěchají nasadit agenti AI, ale bezpečnost identity často zůstává druhotnou. Jaké jsou nejčastější chyby, které společnosti dělají, když poskytují agentům AI přístup k podnikovým systémům a citlivým údajům?

Největší chyba je zacházet s agentem jako se službou a poskytnout mu statický, dlouhodobý API klíč. Tento přihlašovací údaj se stává trvalým, sbíratelným aktivem, které se nachází uvnitř nedeterministického, prompt-injektovatelného aktéra.

Další běžné chyby, které vidím, jsou: poskytování stálých oprávnění místo just-in-time přístupu, spoléhání se na hrubá role-založená oprávnění, která popisují, co může agent dosáhnout, ale nikdy ne to, co má v úmyslu udělat, poskytování agentům přímé sítě cesty k databázím a API, takže kompromitace se stává laterální pohyb, a nemít žádný audit řetězec, který váže akci agenta zpět k lidskému a promptu, který jej spustil. Každá z těchto je pokus o retrofit lidských-era kontrol na něco, co se nechová jako lidské.

Akeyless argumentoval, že agenti AI vyžadují fundamentálně odlišný model identity než lidé nebo tradiční pracovní zátěže. Co činí agenty AI jedinečně obtížnými pro zabezpečení ve srovnání s existujícími rámcemi IAM a PAM?

Ústřední chyba je zacházet s agenty AI jako s novým druhem uživatele, nebo dokonce novým druhem služby, a předpokládat, že mohou být nařízeni a spravováni jako lidské identity. To je kategorie chyba, z několika propojených důvodů.

Identita agentů nejsou čitelné. Konkrétní instance, kterou chcete spravovat, obvykle neexistuje ještě, a do té doby, než existuje, je již pryč. Agent může spustit na Lambda, běžet po 800 milisekundách a zmizet, než si to kterýkoli skener všimne, nebo spustit řetězce sub-agentů napříč VM, kontejnery a serverless, které dokončí v sekundách. Registrování těchto v adresáři je zacházení s duchy jako s obyvateli: do té doby, než se záznam zavře, entita, kterou popisoval, je pryč.

Správným kotvou je tedy ne agent, ale identita pracovní zátěže, kterou jeho runtime již vydal, AWS execution role, Kubernetes service account token, SPIFFE SVID. Tato identita již existuje, je zaručena platformou, na které agent běží, a zmizí, když agent zmizí. Protože identita jsou efemérní, jediné stabilní entity, pro které lze psát politiku, jsou autentizační metody a cílové systémy, ne pojmenované identity a rozsahy.

A to je místo, kde stávající IAM a PAM nejvíce selhávají: statické RBAC a ABAC nemohou obsáhnout nedeterministického aktéra. Agent s dokonale nařízeným tokenem a dokonale vynuceným TTL může stále být prompt-injektován, halucinovat destruktivní dotaz, nebo změnit se z čtecí úlohy na zápisovou úlohu ve stejné relaci, bez viditelného porušení politiky na autorizační úrovni. RBAC a ABAC hodnotí na autentizaci, ne poté, protože to, co se stane poté, je rozhodnuto LLM, který se dívá na kontextové okno, které autor politiky nemůže vidět.

Takže agenti jsou jedinečně obtížní, protože jsou efemérní, nedeterminističtí, multi-podkladoví a prompt-injektovatelní najednou. Chybějící vrstva není lepší adresář. Je to intent-aware enforcement na každé akci, zprostředkovaný bránou, která zkontroluje, co agent skutečně dělá, proti tomu, co řekl, že bude dělat, předtím, než bude vydán jakýkoli přihlašovací údaj. Identity stále záleží, ale padají na místo za vynucením spíše než před ním.

Existuje rostoucí diskuse kolem “secretless” architektur pro systémy AI. Jak definujete secretless autentizaci a proč věříte, že statické přihlašovací údaje a API klíče se stávají neudržitelnými v éře autonomních agentů?

Secretless autentizace znamená, že agent nikdy nedrží přihlašovací údaj. Místo toho, aby se agentovi poskytl klíč, který musí uložit a představit, agent se autentizuje prostřednictvím své nativní identity pracovní zátěže, a krátkodobý, just-in-time přihlašovací údaj je vložen do zprostředkované relace v okamžiku spuštění, a poté zničen, když relace skončí. Agent nikdy nevidí.

Statické přihlašovací údaje a API klíče se stávají neudržitelnými z jednoduchého důvodu: tajemství, které agent drží, je tajemství, které útočník může ukrást. V světě, kde aktér, který drží přihlašovací údaj, může být prompt-injektován nebo halucinovat, dlouhodobý klíč se stává únikem klíče. Odstranění přihlašovacího údaje z agenta a kompromitovaný agent nemá nic, co by mohl únik.

Jako AI agenti získávají schopnost plánovat, vykonávat akce a interagovat s několika systémy nezávisle, jaké nové útočné vektory vás nejvíce znepokojují v příštích třech až pěti letech?

Útočné vektory, které mě nejvíce znepokojují, všechny pocházejí z agentů, kteří mohou plánovat a jednat napříč systémy nezávisle. Prompt-injekce, která přebírá agentovu záměr uprostřed úkolu, je nejzřetelnější, protože identita zůstává platná, i když se chování stává škodlivým. Za tím se obávám o agent-to-agent handoffs, kde je autorita předána po řetězci bez jasné odpovědnosti, laterální pohyb prostřednictvím agentů, kteří mají přímou síťovou dosažitelnost, a exfiltrace dat, kde je agent, který má nadměrná oprávnění, stahuje mnohem více, než jeho úkol vyžaduje.

Společným vláknem je, že přihlašovací údaj a role mohou být dokonale legitimitní, zatímco akce není. Obrany, které kontrolují pouze oprávnění, ne účel, nechytnou žádný z nich. To je důvod, proč intent-aware enforcement na bráně, na každé akci, je kontrola, o které jsem přesvědčen, že bude záležet nejvíce.

Pohledem do budoucna, věříte, že podniky budou nakonec vyžadovat vyhrazenou identitní vrstvu pro agenty AI, podobně jako identity poskytovatelé se stali nezbytnými pro lidské uživatele, a jak by vypadala tato budoucnost architektura?

Ano, ale nebude vypadat jako model identity poskytovatele pro lidi prostě přejmenovaný pro agenty. Pokus o vybudování adresáře agentů je budování adresáře pro duchy, identity, které jsou pryč, než dokončíte jejich registraci.

Identitní vrstva agenta, kterou očekávám, bude kotvit identitu k pracovní zátěži, kterou runtime vydal, cloud IAM, Kubernetes service account token, OIDC federace a standardy jako SPIFFE/SPIRE, které jsou již prokázány v produkci a cross-substrate. Autorizace bude vyjádřena jako vztahy mezi autentizačními metodami a cílovými systémy, spíše než mezi pojmenovanými identitami a rozsahy. A středem gravitace bude runtime enforcement rovina, brána, která zprostředkovává každou akci, klasifikuje záměr, vkládá efemérní přihlašovací údaje, maskuje citlivé odpovědi a produkuje plný forenzní řetězec. Identity stále záleží, ale padají na místo za vynucením spíše než před ním.

Děkuji za skvělý rozhovor, čtenáři, kteří chtějí se dozvědět více, by měli navštívit Akeyless.