Tālāk par pakalpojuma kontu: kāpēc Google AI identitātes spiež pārskatīt uzņēmuma uzticības modeli

Unikālu identitāšu ieviešana AI aģentiem Google Gemini Enterprise platformā iezīmē fundamentālu pāreju tajā, kā mēs uztveram uzņēmuma perimetru. Gadiem ilgi drošības nozare ir pūlējusies kategorizēt mākslīgo intelektu: vai tas bija rīks, lietotājs vai pakalpojuma konts? Formalizējot AI aģentu identitātes, Google ir efektīvi pielikusi punktu "uz starpniekserveriem balstītas" AI mijiedarbības ērai. Mēs vairs neaizsargājam cilvēku, kurš izmanto AI; mēs aizsargājam pusautonomu vienību, kurai ir savs kriptogrāfiskais nospiedums un piekļuves tiesības.

Pārmaiņu būtība: no personificēšanas uz rīcībspēju

Iepriekš AI mijiedarbība lielā mērā bija piesaistīta cilvēka lietotāja identitātei vai vispārīgam pakalpojuma kontam. Tas radīja ievērojamu redzamības plaisu. Kad LLM darbināts aģents piekļuva sensitīvai datubāzei, lai ģenerētu atskaiti, audita žurnāli rādīja cilvēku lietotāju — vai, vēl ļaunāk, API atslēgu ar plašām pilnvarām —, kas veic šo darbību. Šī maskēšanās darbojās kā neizteikts sabiedrotais potenciālajiem uzbrucējiem, jo ļaundabīgu sānisko kustību varēja noslēpt leģitīmā AI trafikā.

Tagad loģika mainās uz modeli, kurā AI aģents ir pirmā līmeņa dalībnieks identitātes un piekļuves pārvaldības (IAM) hierarhijā. Praksē tas nozīmē, ka drošības komandas beidzot var piemērot granulāras politikas tieši aģentam. Tomēr šis arhitektūras izrāviens ievieš jauna veida sarežģītību: necilvēku identitāšu (NHI) pārvaldību tādā mērogā, kas pārsniedz cilvēka uzraudzības spējas. Mūsdienu mākoņvidēs NHI jau tagad pārsniedz cilvēku lietotāju skaitu attiecībā 45 pret 1; unikālu identitāšu pievienošana katram izvietotajam AI aģentam tikai palielinās šo piekļuves asimetriju.

Kompetences trūkums kā neizteikts sabiedrotais

Lai novērtētu riska mērogu, ir jāskatās uz pašreizējo ievainojamību pārvaldības stāvokli. Lielākā daļa uzņēmumu cīnās ar pamata higiēnu statiskiem pakalpojumu kontiem. Dinamisku AI aģentu ieviešana — vienību, kas var ģenerēt kodu, izsaukt API un interpretēt datus reāllaikā — prasa tādu arhitektūras noturības līmeni, kādu spēj atbalstīt tikai retais no mantotajiem komponentiem. Draudu modelis ir mainījies: mēs vairs neuztraucamies tikai par nozagtu paroli; mēs uztraucamies par "uzvedņu injekciju" (prompt injection), kas noved pie neautorizētas privilēģiju eskalācijas, ko veic uzticama iekšējā identitāte.

Ja AI aģentam ir sava identitāte un atļauju kopums, tas kļūst par augstvērtīgu mērķi slēptai kompromitēšanai. Uzbrucējam nav nepieciešams uzlauzt pašu pamatmodeli. Tā vietā viņi izmanto aģenta deleģētās pilnvaras, lai apietu tradicionālos berzes punktus CI/CD cauruļvadā vai finanšu pārskatu struktūrā. Kad aģentam tiek piešķirtas pilnvaras "rīkoties", nevis tikai "iesacīt", tā ietekmes rādiuss paplašinās eksponenciāli.

Arhitektūras noturība: vieninieka kameras metafora

Šajā jaunajā realitātē mums ir jāpieņem, ka DMZ nav koplietošanas telpa, bet gan individuāla vieninieka kamera. Mantotā pieeja "uzticies, bet pārbaudi" iekšējā tīklā ir faktiski mirusi. Lai mazinātu unikālo AI identitāšu riskus, mums ir jāievieš mikrosegmentācijas stratēģija tieši aģentu darba plūsmām.

Skaidrības labad — mērķis nav neļaut AI piekļūt datiem, bet gan nodrošināt, lai tā piekļuve būtu stingri ierobežota ar konkrēto uzdevumu, kura veikšanai tas tika izsaukts. Tā ir "smilškastes" (sandbox) domāšana, kas piemērota identitātei. Katra AI aģenta identitāte jau no pirmās dienas ir jāuztver kā potenciāls kompromitēšanas vektors.

Piekļuves asimetrijas ietekme

Viena no kritiskākajām pārejām šajā vidē ir piekļuves asimetrijas parādīšanās. AI aģents var skenēt, interpretēt un rīkoties ar tūkstošiem dokumentu tajā laikā, kas cilvēkam nepieciešams, lai izlasītu vienu virsrakstu. Ja aģenta identitātei ir piešķirtas pārmērīgas pilnvaras, uzbrucēja, kurš iegūst kontroli pār šo aģentu, izmantošanas ātrums ir gandrīz tūlītējs. Ielāpu pārvaldība ar ritmu "reizi mēnesī" ir luksuss, ko mēs vairs nevaram atļauties, strādājot ar automatizētām vienībām.

Šis ātrums prasa pāreju uz proaktīvu, automatizētu aizsardzību. Drošības orķestrēšanas, automatizācijas un reaģēšanas (SOAR) platformas tagad ir jāpielāgo, lai uzraudzītu AI identitāšu "uzvedības novirzes". Ja Gemini aģents, kas parasti apstrādā personāla nodaļas vaicājumus, pēkšņi sāk pieprasīt ražošanas datubāzes shēmu, identitāte ir jāatsauc milisekundēs, nevis stundās.

Rīcības plāns: 6–12 mēnešu horizonts

CISO unikālu AI identitāšu izvietošana nav funkcija "iestati un aizmirsti". Tā prasa strukturētu IAM stratēģijas kapitālo remontu. Tas, kas tieši ir jāpārskata, ir šo identitāšu dzīves cikls — no izveides līdz likvidēšanai.

1. Esošā AI nospieduma audits (1.-2. mēnesis): Identificējiet, kur Gemini un citi LLM pašlaik tiek izmantoti, izmantojot ēnu IT vai oficiālos kanālus. Kartējiet pašreizējos pakalpojumu kontus, kas tiek izmantoti kā starpnieki.
2. Aģentu darbības jomas noteikšana (3.-4. mēnesis): Ieviesiet "minimālo nepieciešamo atļauju" kopumu katrai AI aģenta identitātei. Nevienam aģentam nevajadzētu būt plašai lasīšanas piekļuvei visam uzņēmuma datu ezeram.
3. Mikrosegmentācijas ieviešana aģentiem (5.-8. mēnesis): Izolējiet AI aģentu trafiku. Nodrošiniet, lai aģentiem, kas sazinās starp nodaļām, būtu jāiziet cauri identitāti apzinošam starpniekserverim, kas apstiprina pieprasījuma konkrēto nodomu.
4. Automatizēta uzvedības uzraudzība (9.-12. mēnesis): Izvietojiet mašīnmācīšanās modeļus, lai uzraudzītu mašīnmācīšanās aģentus. Izveidojiet bāzes līnijas normālai aģentu uzvedībai un automatizējiet jebkuras identitātes izolēšanu, kas novirzās no sava uzdevuma profila.
5. Aģenta kompromitēšanas simulācija (turpinās): Veiciet ielaušanās testus, īpaši koncentrējoties uz sānisko kustību caur AI aģentiem. Pārbaudiet, vai uzbrucējs var izmantot kompromitētu Gemini identitāti, lai sasniegtu kritisko infrastruktūru vai sensitīvu PII.

Secinājums

Google solis ieviest unikālas AI aģentu identitātes ir pragmatiska atzīšana, ka AI vairs nav perifērs rīks, bet gan sistēmiski svarīga uzņēmuma infrastruktūras sastāvdaļa. Šī maiņa nodrošina redzamību, pēc kuras mēs ilgi esam ilgojušies, taču tā atņem anonimitātes sniegto drošību. Šajā jaunajā ērā perimetrs ir patiesi izšķīdis miljonos individuālu identitāšu, no kurām katra pārstāv potenciālas atvērtas durvis, ja tās netiek pārvaldītas ar arhitektonisku stingrību.

Izdzīvošana šajā vidē ir atkarīga no ātruma un arhitektūras, nevis cerības. Mērķis nav sasniegt perfektas drošības stāvokli — kas ir maldi —, bet gan nodrošināt, ka gadījumā, ja AI identitāte tiek kompromitēta, ietekmes rādiuss ir tik cieši ierobežots, ka pārkāpums ir tikai zemsvītras piezīme, nevis katastrofa.

Avoti:

• 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.

Atruna: Šis raksts ir paredzēts tikai informatīviem un izglītojošiem nolūkiem. Tas neaizstāj profesionālu kiberdrošības auditu, pielāgotu riska novērtējumu vai incidentu reaģēšanas pakalpojumu. Katra uzņēmuma vide ir unikāla un prasa specifisku tehnisko pārbaudi.