Biztonságos ügynök-munkatér az vállalati AI gyárakhoz: referencia-architektúra

A NVIDIA Secure Agent Workspace Reference Design azt javasolja, hogy a vállalati AI-ügynökök végrehajtása ne a felhasználó gépén vagy böngészőjében történjen, hanem egy felügyelt, vállalati munkatérben. A megközelítés célja, hogy az azonosítás, hálózati hozzáférés, hitelesítő adatok, futtatási politika, naplózás és emberi felülvizsgálat következetesen érvényesíthető legyen, miközben az alkalmazottak hosszabb ideig futó, összetettebb feladatokat bízhatnak az autonóm ügynökökre.

Miért fontos ez?

Az ügynökök ma már nem csak beszélgetnek: kódot vizsgálnak, teszteket futtatnak, dokumentumokat olvasnak, belső rendszerekhez és tudásbázisokhoz férnek hozzá, és órákon át képesek dolgozni egy felhasználó nevében. Ez növeli a termelékenységet, de egyben kockázatot is jelenthet: hozzáférés érzékeny adatokhoz, automatikus műveletek üzleti rendszerekben. A referencia-architektúra célja a biztonságos, kormányzott futtatási környezet kialakítása szervezeti méretekben.

Lépések a Secure Agent Workspace megvalósításához

Előkészítés

• Azonosítsuk az ügynök-folyamat tulajdonosait és érintett szereplőket — ez határozza meg az erőforrás- és hozzáférési igényeket. A kormányzáshoz előre definiált viselkedési tartományokra és tiltó határokra van szükség.
• A megvalósítás I. és II. fázisai a vállalati, menedzselt virtuális gépes alapra épülnek, amely magában foglalja a konfiguráció-kezelést, patch és sebezhetőség-kezelést, image governance-t, SOC telemetriát, valamint újraépítési / visszavonási képességeket.

Peremvédelem a virtuális gépen kívül (I. fázis)

Az első fázis a munkatér körüli perem vezérlésére fókuszál: ki léphet be, hogyan léphet be, milyen munkatér jár neki, és mely szolgáltatások érhetők el onnan. Itt a VM működik elsődleges izolációs határként, és a cél az, hogy az ügynök tevékenysége megfigyelhető, korlátozott és visszavonható legyen.

• Menedzselt munkaterek biztosítása: minden felhasználónak saját, vállalat által kezelt virtuális gép.
• Bejelentkezési kapuk érvényesítése: vállalati single sign-on (SSO) a hozzáférés vezérlésére; munkatér csak hitelesített engedéllyel nyitható meg.
• Hálózat megszigorítása: alapértelmezett blokk minden internetforgalomra; csak előre jóváhagyott belső és külső szolgáltatások engedélyezése.
• Emberi jóváhagyás kötelezővé tétele: minden olyan ügynök-akció, amely rendszerváltozást okoz (például kód egyesítése vagy jegy állapotának módosítása), emberi jóváhagyáshoz kötve legyen.
• Központosított naplózás: az összes munkatér-tevékenység naplóit egy helyre küldeni a biztonsági csapatok vizsgálatához.

Futásidő-biztonság a virtuális gépen belül (II. fázis)

A második fázis a munkatéren belüli vezérlők telepítéséről szól: mihez fér hozzá az ügynök, milyen parancsokat futtathat, mely fájlokat olvashatja. A titkok proxyn keresztül maradnak védve, a politika központilag irányított, és az ügynök nem tudja titokban növelni jogosultságait.

• Aktív sandboxing: futtatás dedikált runtime-ban (például NVIDIA OpenShell), amely valós időben figyeli az összes műveletet.
• Aláírt biztonsági szabályok: központi rendszer küldi a pontos szabályokat (például mely fájlok olvashatók) aláírt, biztonságos csomagokként a munkatérnek.
• Hitelesítő adatok védelme: jelszavak vagy titkos kulcsok soha ne legyenek közvetlenül a munkatérben; használjunk titkos proxyt, amely rövid élettartamú képesség-tokeneket kezel.
• Folyamatos ellenőrzés: automatikus ellenőrzés minden egyes ügynök-művelet előtt, hogy a biztonsági szabályok aktívak és működőképesek.

Ügynök-blueprintek kialakítása

A blueprintek ismételhető munkafolyamat-sablonok, amelyek a munkatér tetején futnak. Minden blueprint konfigurálva van cél, szükséges eszközök, engedélyezett szolgáltatások, adatkör, írási jogosultságok, felülvizsgálati kapuk és naplózási elvárások szerint. A folyamat:

• Ügynök-azonosság meghatározása: regisztráljuk az ügynököt logikai identitással, amely visszaköthető a felhasználóhoz vagy a szponzorhoz SSO-n keresztül; delegációs rekorddal pontosan definiáljuk a jogosultságokat.
• Titkok kezelése: tilos a titkok keménykódolása; credential proxy használata rövid élettartamú képesség-tokenekhez.
• Inferencia konfigurálása: egy gateway réteg kezeli a kvótákat, szerepalapú hozzáférést (RBAC) és dinamikus rate limitinget a biztonságos, skálázható inferencia szolgáltatáshoz.
• Kormányzás lezárása: „blast radius” szabályok beállítása — mely műveletek igényelnek emberi ellenőrzést; minden napló OCSF formátumban, auditálásra készen.

Telepítési útmutató: helyszínen vagy felhőben

A munkatér kiépítése Red Hat OpenShift Virtualization használatával javasolt helyszíni (on-prem) környezeteknél, míg felhőn Microsoft Azure-t ajánlanak. A minta ugyanaz mindkét esetben: minden felhasználónak dedikált VM, és a helyi végpont csak megjelenítési rétegként csatlakozik. A telepítés fő lépései:

1. Egy munkatér-VM biztosítása felhasználónként: dedikált Linux vagy Windows VM létrehozása.
2. Hozzáférési útvonal létrehozása: megbízható hozzáférési broker az előtérben; felhasználók SSO-val és rövid élettartamú, auditálható munkamenetekkel csatlakoznak; a végpont csak prezentációs felület.
3. Hálózati határ meghatározása: default-deny egress, csak jóváhagyott célok engedélyezése. OpenShift-en használható primitívek: NetworkPolicy, EgressFirewall, route-ok és jóváhagyott ingress utak; Azure-on irányítsuk a kimenő forgalmat Azure Firewall Premiumon keresztül, kapcsoljuk ki a BGP route propagation-t, tagadjuk a vállalati CIDR hozzáférést, és kerüljük a nyilvános bejövő útvonalakat.
4. Image és VM profilok központi kezelése: csak jóváhagyott VM image-ek használata. OpenShift esetén a VM profilokat és platform állapotot GitOps-szal kezeljük; Azure esetén golden image-eket építsünk Packerrel és publikáljuk Azure Compute Gallery-n keresztül.
5. GitOps a politika-intenthez: tároljuk a VM profilokat, hálózati szabályokat, policy metadata-t és release információkat Gitben; a GitOps reconciler biztosítja a kívánt platformállapotot, míg az aláírt futtatási policy-csomagok egy kontrollált kiadási csatornán keresztül terjednek.
6. Titkok és identitás folyamatok védelme: lehetőség szerint tartsuk távol a nyers titkokat az ügynökfolyamatoktól. Azure-telepítéseknél használjunk Workload Identity Federation-t titkosítás nélküli provisioninghoz, menedzselt identitásokat a VM futtatási hozzáféréshez, Azure Key Vault-ot Private Endpoints-szel, és szigorú futtatási identitást az ügynök kód indítása előtt.
7. Audit és megfigyelhetőség központosítása: rögzítsük a munkatér-életciklus eseményeket, broker munkameneteket, policy kiadásokat, hálózati allow/deny eseményeket és runtime/eszköz eseményeket; küldjük a naplókat az enterprise SIEM-be vagy platform logging stack-be, például Azure Monitor, Log Analytics, Microsoft Sentinel vagy egy OCSF-kompatibilis audit csatornára.

Végső állapot

A referencia-architektúra gyakorlati mintája egy olyan rendszer, ahol: egyfelhasználós VM-ek biztosítanak izolációt; GitOps ismételhető működtetést; vállalati identitás vezérli a hozzáférést; hálózati politika korlátozza az elérhetőséget; és a futtatási érvényesítés további politikai réteget ad az autonóm ügynökök biztonságához.

Következő lépések

A szervezetek a Secure Agent Workspace Reference Design alapján hozhatják létre saját, biztonságos ügynök-munkaterüket, amely lehetővé teszi az autonóm, folyamatosan működő AI-ügynökök vállalati skálán történő használatát, miközben csökkenti az adatkitettséget és biztosítja a megfelelőséget.