Az Anaconda egyetlen szabályozási határba vonja az AI-rendszerek elemeit
Az Anaconda Platform új perimeterekkel kezeli az AI-rendszerek legfontosabb összetevőit, a kódtól és annak függőségeitől az adatokon és modelleken át a számítási kapacitásig és a hitelesítő adatokig. Az adminisztrátor egyetlen szabályozási határt állíthat be, amely az adott környezet minden elemére kiterjed.
- A perimeter egy szabályozási határ a kód, az adatok, a modellek, a számítási kapacitás és a hozzáférések körül.
- Külön szabályok állíthatók be a kísérletezési és a production környezethez.
- A projekt CI/CD-folyamaton keresztül, a kód módosítása nélkül léptethető production környezetbe.
- A platform az AWS, a Google Cloud és az Azure meglévő IAM-szabályait is hozzárendelheti a perimeterhez.
- A külső szolgáltatások hitelesítő adatai perimeterhez kötött titokkezelőben tárolhatók.
Egy szabályozási határ az AI-fejlesztés körül
Az Anaconda szeptember 28-i bejelentése szerint a perimeter, vagyis a szabályozási határ az AI-rendszer valamennyi építőelemét egy közös irányítási keretbe rendezi. Ide tartozik a kód és annak teljes függőségi fája, az adatforrások, a modellek, a felhasznált számítási kapacitás, a hozzáférő emberek és ügynökök, valamint a futtatáshoz szükséges biztonsági hitelesítő adatok.
A megoldás az Anaconda szerint azokra a vállalati helyzetekre ad választ, amikor külön kell meghatározni, hogy egy rendszer milyen kódot futtathat, milyen adatokhoz férhet hozzá, mely modelleket hívhatja meg, és milyen hardvert használhat. Az adminisztrátor a határt egyszer állítja be, majd az ahhoz rendelt felhasználók és projektek öröklik a szabályokat.
Külön szabályok kísérletezéshez és éles környezethez
A vállalat több perimetert is létrehozhat. Lehet külön szabályozási határ a kísérletezéshez és a production környezethez, de a felosztás történhet projektek, földrajzi régiók vagy más szervezeti szempontok szerint is. A felhasználói felületen ezek listaként jelennek meg, minden bejegyzéshez saját szabálykészlet tartozik.
A szoftverellátási láncra vonatkozó szabály például production környezetben letilthat minden ismert CVE-vel rendelkező csomagot, miközben a kísérletezési környezetben engedékenyebb lehet. A szabály a forrástól a buildfolyamaton át az elkészült környezetig a teljes láncra érvényes.
Az adatkezelési szabályok a meglévő adatirányítási rendszerre építhetnek. Databricks vagy Snowflake használata esetén eltérő táblák tehetők elérhetővé a production és a kísérletezési környezet számára. A modellkatalógusban meghatározható például, hogy production környezetben csak az Egyesült Államokban készült, nyílt súlyú modellek fussanak, vagy hogy egy projekt kizárólag egy adott modellcsaládot használhasson.
A számítási szabályokkal kisebb GPU-k rendelhetők a kísérletezéshez, a nagyobb és drágább gyorsítók pedig fenntarthatók a production feladatokra. Így a költség- és a biztonsági határ ugyanahhoz az objektumhoz tartozik.
A kód változatlanul kerülhet production környezetbe
Az Anaconda leírása szerint a fejlesztés a kísérletezési perimeterben történhet, majd a projekt CI/CD-rendszeren keresztül léptethető production környezetbe. A folyamatba tetszőleges emberi ellenőrzési lépések kerülhetnek, például kódátvizsgálás, tesztfuttatás és jóváhagyás.
A kód eközben nem változik. A hozzá kapcsolódó perimeter módosul, és vele együtt azoknak a csomagoknak, adatoknak, modelleknek, számítási erőforrásoknak és hitelesítő adatoknak a köre is, amelyeket a kód használhat.
A hozzáférés szerepköralapú vezérlése kiterjed az emberi felhasználókra, a gépi felhasználókra és az ügynökökre. Gyakori beállítás lehet, hogy minden fejlesztő végrehajtási jogosultságot kap a kísérletezési környezetben, production környezetben pedig csak olvasási hozzáférést.
A felhős jogosultságokat és a titkokat is kezeli
Az IT-csapat a már meglévő AWS-, Google Cloud- vagy Azure-IAM-szabályokat is hozzárendelheti a perimeterhez. Így az Anaconda szerint nem kell külön biztonsági szabálykészletet létrehozni az AI-platformhoz. A szabályok irányítják többek között a tárolókhoz, adatbázisokhoz és telepítési célpontokhoz való hozzáférést.
A külső modellekhez és szolgáltatásokhoz használt API-kulcsok, valamint más titkok perimeterhez kötött titokkezelőben tárolhatók. A production hitelesítő adatok így elkülönülnek a kísérletezési környezet adataitól.
A felhasználók a mindennapi használat során jellemzően csak a számukra elérhető projekteket látják. Ha több perimeterhez férnek hozzá, a projektválasztóban válthatnak közöttük. A projektek a csapat munkájának szemantikai konténerei, a perimeterek pedig az adminisztrátor által kijelölt biztonsági határok.
