Anapus paslaugų paskyros: kodėl „Google“ dirbtinio intelekto tapatybės verčia iš naujo peržiūrėti įmonės pasitikėjimo modelį

Unikalių dirbtinio intelekto (DI) agentų tapatybių įvedimas „Google Gemini Enterprise“ platformoje žymi esminį lūžį tame, kaip mes suprantame įmonės saugumo perimetrą. Metų metus saugumo pramonė stengėsi kategorizuoti DI: ar tai įrankis, vartotojas, ar paslaugų paskyra? Formalizuodama DI agentų tapatybes, „Google“ faktiškai užbaigė „įgaliojimais pagrįstos“ (angl. proxy-based) DI sąveikos erą. Mes nebeužtikriname saugumo žmogui, kuris naudojasi DI; mes užtikriname saugumą pusiau autonominiam subjektui, turinčiam savo kriptografinį piršto atspaudą ir prieigos teises.

Pokyčio esmė: nuo apsimetinėjimo prie atstovavimo

Anksčiau DI sąveikos buvo glaudžiai susietos su žmogaus vartotojo tapatybe arba bendrine paslaugų paskyra. Tai sukūrė didelį matomumo atotrūkį. Kai LLM (didžiųjų kalbos modelių) valdomas agentas pasiekdavo jautrią duomenų bazę ataskaitai parengti, audito žurnaluose būdavo matomas žmogus – arba, dar blogiau, plačių teisių API raktas – atliekantis veiksmą. Šis užmaskavimas veikė kaip tylus sąjungininkas potencialiems užpuolikams, nes piktavališkas judėjimas tinklo viduje galėjo būti paslėptas po teisėtu DI srautu.

Dabar logika keičiasi į modelį, kuriame DI agentas yra pilnateisis tapatybės ir prieigos valdymo (IAM) hierarchijos dalyvis. Praktikoje tai reiškia, kad saugumo komandos pagaliau gali taikyti detalias politikas būtent agentui. Tačiau šis architektūrinis proveržis įneša naują sudėtingumo formą: ne žmonių tapatybių (angl. Non-Human Identities, NHI) valdymą tokiu mastu, kuris viršija žmonių priežiūros galimybes. Šiuolaikinėse debesijos aplinkose NHI jau dabar viršija žmonių skaičių santykiu 45 su 1; pridėjus unikalias tapatybes kiekvienam įdiegtam DI agentui, šis prieigos asimetrijos atotrūkis tik didės.

Kompetencijos trūkumas kaip tylus sąjungininkas

Norint įvertinti rizikos mastą, reikia pažvelgti į dabartinę pažeidžiamumų valdymo būklę. Dauguma įmonių susiduria su sunkumais užtikrinant bazinę statinių paslaugų paskyrų higieną. Dinamiškų DI agentų – subjektų, kurie gali generuoti kodą, kviesti API ir interpretuoti duomenis realiuoju laiku – įvedimas reikalauja tokio architektūrinio atsparumo, kurį palaikyti gali tik nedaugelis pasenusių komponentų. Grėsmių modelis pasikeitė: mes nebebijome tik pavogto slaptažodžio; mes bijome „užklausų injekcijos“ (angl. prompt injection), vedančios į neteisėtą teisių išplėtimą per patikimą vidinę tapatybę.

Jei DI agentas turi savo tapatybę ir teisių rinkinį, jis tampa itin vertingu taikiniu slaptam įsilaužimui. Užpuolikui nereikia nulaužti paties bazinio modelio. Vietoj to, jie pasinaudoja agentui deleguotais įgaliojimais, kad apeitų tradicinius kontrolės punktus CI/CD konvejeryje arba finansinės atskaitomybės struktūroje. Kai agentui suteikiama galia „veikti“, o ne tik „siūlyti“, jo galimos žalos spindulys išauga eksponentiškai.

Architektūrinis atsparumas: vienutės metafora

Šioje naujoje realybėje turime susitaikyti su tuo, kad DMZ (demilitarizuota zona) nėra bendra erdvė, o individuali vienutė. Senasis požiūris „pasitikėk, bet tikrink“ vidiniame tinkle yra faktiškai miręs. Norėdami sumažinti unikalių DI tapatybių keliamą riziką, privalome taikyti mikrosegmentavimo strategiją, skirtą būtent agentų darbo eigoms.

Tikslas nėra neleisti DI pasiekti duomenų, bet užtikrinti, kad jo prieiga būtų griežtai apribota konkrečia užduotimi, kuriai jis buvo iškviestas. Tai „smėlio dėžės“ (angl. sandbox) mentalitetas, pritaikytas tapatybei. Kiekviena DI agento tapatybė nuo pirmos dienos turėtų būti traktuojama kaip potencialus įsilaužimo vektorius.

Prieigos asimetrijos poveikis

Vienas kritiškiausių pokyčių šiame kraštovaizdyje yra prieigos asimetrijos atsiradimas. DI agentas gali nuskaityti, interpretuoti ir veikti tūkstančiuose dokumentų per tiek laiko, kiek žmogui užtrunka perskaityti vieną antraštę. Jei agento tapatybei suteikiama per daug teisių, užpuoliko, perėmusio to agento kontrolę, išnaudojimo greitis tampa beveik momentinis. Atnaujinimų valdymas „kartą per mėnesį“ ritmu yra prabanga, kurios nebeturime dirbdami su automatizuotais subjektais.

Šis greitis reikalauja perėjimo prie proaktyvios, automatizuotos gynybos. Saugumo orkestravimo, automatizavimo ir reagavimo (SOAR) platformos dabar turi būti suderintos stebėti DI tapatybių „elgsenos nuokrypius“. Jei „Gemini“ agentas, kuris paprastai tvarko personalo užklausas, staiga pradeda užklausas gamybinės duomenų bazės schemai, tapatybė turi būti panaikinta per milisekundes, o ne per valandas.

Veiksmų planas: 6–12 mėnesių horizontas

Informacijos saugos vadovui (CISO) unikalių DI tapatybių diegimas nėra funkcija, kurią galima „nustatyti ir pamiršti“. Tai reikalauja struktūrizuoto IAM strategijos pertvarkymo. Būtina iš naujo apsvarstyti šių tapatybių gyvavimo ciklą – nuo sukūrimo iki deaktyvavimo.

1. Esamo DI pėdsako auditas (1–2 mėnesiai): nustatyti, kur „Gemini“ ir kiti LLM šiuo metu naudojami per „šešėlinį IT“ arba oficialius kanalus. Žemėlapyje pažymėti dabartines paslaugų paskyras, naudojamas kaip įgaliojimus.
2. Agentų veikimo srities apibrėžimas (3–4 mėnesiai): įdiegti „minimalių būtinų teisių“ rinkinį kiekvienai DI agento tapatybei. Joks agentas neturėtų turėti plačios skaitymo prieigos prie viso įmonės duomenų ežero.
3. Mikrosegmentavimo diegimas agentams (5–8 mėnesiai): izoliuoti DI agentų srautą. Užtikrinti, kad agentai, bendraujantys tarp skyrių, praeitų per tapatybę atpažįstantį įgaliojimų serverį (angl. identity-aware proxy), kuris patvirtina konkretų užklausos tikslą.
4. Automatinis elgsenos stebėjimas (9–12 mėnesių): įdiegti mašininio mokymosi modelius, skirtus stebėti mašininio mokymosi agentus. Nustatyti normalaus agento elgesio bazinius lygmenis ir automatizuoti bet kurios tapatybės, nukrypstančios nuo savo misijos profilio, izoliavimą.
5. Agento kompromitavimo simuliavimas (nuolat): atlikti įsilaužimo testus, orientuotus būtent į judėjimą tinkle per DI agentus. Patikrinti, ar užpuolikas gali pasinaudoti pažeista „Gemini“ tapatybe, kad pasiektų kritinę infrastruktūrą arba jautrius asmens duomenis (PII).

Išvada

„Google“ žingsnis įvesti unikalias DI agentų tapatybes yra pragmatiškas pripažinimas, kad DI nebėra periferinis įrankis, o sistemiškai svarbus įmonės infrastruktūros komponentas. Šis pokytis suteikia matomumą, kurio seniai troškome, tačiau panaikina saugumą, kurį teikė neaiškumas. Šioje naujoje eroje perimetras ištirpo į milijoną individualių tapatybių, kurių kiekviena reprezentuoja potencialias atviras duris, jei nebus valdoma su architektūriniu griežtumu.

Išgyvenimas šiame kraštovaizdyje priklauso nuo greičio ir architektūros, o ne nuo vilties. Tikslas nėra pasiekti tobulą saugumo būseną – tai iliuzija – bet užtikrinti, kad kai DI tapatybė bus pažeista, žalos spindulys būtų taip griežtai apribotas, jog įsilaužimas liktų tik nereikšminga pastaba, o ne katastrofa.

Šaltiniai:

• Google Cloud Security Blog: Gemini Enterprise Updates.
• NIST Special Publication 800-207: Zero Trust Architecture.
• Infosecurity Magazine: Analysis of AI Agent Identity Management.
• Cloud Security Alliance (CSA): Top Threats to Large Language Models.

Atsakomybės apribojimas: Šis straipsnis yra skirtas tik informaciniams ir edukaciniams tikslams. Jis nepakeičia profesionalaus kibernetinio saugumo audito, pritaikyto rizikos vertinimo ar reagavimo į incidentus paslaugų. Kiekviena įmonės aplinka yra unikali ir reikalauja specifinio techninio patikrinimo.