Miért kell bizonyíték, nem csak jogosultság az AI-alapú infrastruktúra-változtatásokhoz

Korábban egyszerű volt egy szerveren változtatni: beléptél SSH-val, kiadtad a parancsot, és remélted, hogy a dokumentáció naprakész. Ma már AI-ügynökök végzik a bonyolultabb feladatokat – migrációkat, kapacitáskezelést, biztonsági javításokat. Ezeknél viszont tudni kell, hogy a művelet valóban biztonságos-e, mielőtt lefutna.

A hagyományos jogosultságkezelés már nem elég.

Miért nem működik az RBAC az AI-korszakban

A jelenlegi védelmi rendszered valószínűleg így néz ki:

RBAC szerint: „Ez a felhasználó írhat a productionbe.”
GitOps szerint: „Ez a kívánt állapot.”

Egyik sem válaszolja meg azt a kulcskérdést: „Miért biztonságos ez a konkrét változtatás most?”

Ha egy ember futtat egy parancsot, hozza magával a tapasztalatát és a kontextust. Egy AI-ügynök viszont csak a jogosultságot kapja meg – azt nem látjuk, milyen logika alapján döntött. Ez különösen veszélyes az állapotfüggő műveleteknél, ahol egy adatbázis-migráció vagy konfigurációváltás nem visszafordítható lépések sorozata.

Hogyan néz ki a bizonyíték-alapú változáskezelés

A megoldás az, hogy minden javasolt változtatást kriptográfiai bizonyítékkal látunk el, mielőtt lefutna. Ez az infrastruktúra-változtatások aláírása.

A folyamat lépései:

1. Az ügynök javaslatot tesz – részletes művelet és indoklás
2. Bizonyíték készül – kriptográfiai igazolás a biztonságosságról
3. Szabálymotor ellenőrzi – megfelel-e az engedélyezési szabályoknak
4. Aláírás-ellenőrzés – nem történt-e manipuláció
5. Végrehajtás – csak ha minden kapu átment
6. Naplózás – teljes, visszajátszható rekord a történtekről

A bizonyíték tartalmazza a dry-run eredményét, az aktuális állapot és a várt állapot közti eltéréseket, a biztonsági ellenőrzéseket, az image-ek lenyomatait, az SLO-hatások becslését és a lépések integritását.

Valós példa: Oracle-ről PostgreSQL-re migráció

Képzeljünk el egy éles Oracle/APEX rendszert, amit PostgreSQL-re kell költöztetni Kubernetesben – élő adatokkal, valós cutoverrel.

A lépések között szerepel a klaszter előkészítése, a változási ablak jóváhagyása, a forrásrendszer leállítása, az adat exportálása, a célrendszer visszaállítási pontjainak létrehozása, a séma-bővítés, a soronkénti ellenőrzés, a forgalom átirányítása és az utólagos validáció.

Ez nem egy sima kubectl apply. Amikor egy AI-ügynök kéri a futtatást, a bizonyíték-rendszer 23 ellenőrzést, 20 eseményt és 20 különálló bizonyítékot rögzít. Az eredmény egy 100%-os release score, az egész ed25519 kulccsal aláírva, később ellenőrizhetően.

A kapu elkapja azt is, amit az ember nem lát

Még ha a bizonyíték át is megy, a rendszer külön engedélyt is kér. Tesztelés során ugyanazt a kérést kétszer is elutasította a rendszer:

• Először azért, mert nem volt explicit engedélyezve ez a művelet.
• Másodszor azért, mert valaki módosította a bizonyíték egy részét – az aláírás érvénytelen lett, a művelet blokkolódott.

Ez a védelem két rétegből áll: bizonyítékból és szabályzatból. Egyik sem elég önmagában.

Miért fontos ez neked is

A hagyományos GitOps és RBAC eszközök (Argo CD, Crossplane) még azelőtt készültek, hogy az autonóm ügynökök megjelentek volna a productionben. Megmondják, ki írhat és mi a kívánt állapot, de azt nem, miért biztonságos egy adott változtatás.

Ha AI-vezérelt telepítéseket, autonóm skálázást vagy többfelhős migrációkat tervezel, olyan infrastruktúrára van szükséged, ami minden production-változtatást kriptográfiailag is meg tud magyarázni.

Gyakorlati lépések

Ha Kubernetesben dolgozol és összetett migrációkkal vagy AI-műveletekkel foglalkozol, érdemes elkezdeni:

• Bizonyíték-generálást a telepítési rendszerben
• Szabályokat kódként, explicit allow-listekkel
• Aláírt, visszajátszható naplókat minden változásról
• Kvantitatív „biztonsági pontszámot” a változásokhoz

Az infrastruktúra világa az autonóm működés felé tart. A változáskezelésnek is követnie kell ezt az irányt – a „van jogosultságod?” helyett a „bizonyíték van rá, hogy biztonságos, és ezért” megközelítésre.