MI-biztonság és hozzáférési jogok

Bizalmas tudás.
Célzott védelem.

Az MI könnyebben kereshetővé teszi a tudást. A DAXS ellenőrzi az adatútvonalakat, hozzáférési jogokat és eszközöket, hogy a vállalati tudást csak ott használják, ahol ez szakmailag és műszakilag engedélyezett.

Két személy egy számítógépes munkahely használatáról egyeztet.
Amikor a meglévő jogok hirtelen láthatóvá válnak

Az MI-nek nem kell védelmet megkerülnie ahhoz, hogy túl sokat áruljon el.

A vállalati MI könnyebben megtalálhatóvá tehet olyan dokumentumokat, amelyeket korábban alig ismertek. Ez akkor probléma, ha a tárhelyhez szakmailag indokoltnál több ember fér hozzá. AI Oversharing ebben az összefüggésben a túl tág megosztások és könnyebb megtalálhatóság miatti nem szándékos információfeltárást jelenti. A műszakilag megengedett válasz szervezetileg még lehet nemkívánatos.

A konkrét szolgáltatás, csatlakoztatott források és a kereséshez használt identitás a döntő. Az adatkapcsolat nélküli csevegés nem tud egyszerűen minden vállalati mappában keresni. Amint fájlokat töltenek fel, keresőindexeket kapcsolnak be vagy eszközöket hatalmaznak fel, követhetően ellenőrizendő adatút keletkezik.

„Mennyit keres valójában a főnököm?”

Elméleti eset: egy béradatfájl régi személyügyi mappában található. Örökölt csoportmegosztás révén a személyügyön kívüli munkatársaknak is van olvasási joguk. Ha a fájlt a használt MI-szolgáltatás feldolgozta, és a lekérdezés ezekkel a jogokkal megengedett, megfelelő tartalmak kerülhetnek a válaszba. Hibás szám vagy kitalált válasz is lehetséges; minden konkrét kimenethez forrásigazolás kell.

Helyesen korlátozott jogok esetén a védett fájl eleve nem kerülhet a jogosulatlan személyek modellkontextusába. A modell udvarias felszólítása a bérek titokban tartására nem helyettesíti ezt a műszaki ellenőrzést.

Ugyanaz a rendszer, eltérő jogok

Három személy ugyanazt kérdezi.

A-nak jóváhagyott feladathoz kell az információ. B-nek nincs olvasási joga. C jogosultsági hiba miatt nem szándékosan hozzáférést kap. A rendszernek B-t ki kell zárnia; C-nél a téves forrásjogokat kell javítani.

Három személy bizalmas adatokra kérdez: A megfelelő jogokkal hozzáférhet, B-t kizárja a rendszer, C tévesen kapott olvasási jogot.
Elméleti példa. A jogokat a modell előtt érvényesítjük; véletlenül megengedett hozzáférésnél a forrásmegosztást kell korrigálni.

Az ábra eltérő hozzáférési helyzeteket mutat, nem három egymást követő munkalépést. A keresési szolgáltatásnak a változásokat is figyelembe kell vennie: a visszavont hozzáférés nem élhet tovább elavult indexjogokban, válaszcache-ekben, megosztott beszélgetésekben vagy exportált fájlokban.

A határok világos megnevezése

A rejtett, titkosított és védett eltérő tulajdonságok.

Navigáció és hozzáférés
Az elrejtett menüpont vagy ismeretlen mappanév nem vonja vissza az olvasási jogot. A hozzáférés-védelemnek az objektumnál és használt szolgáltatásnál kell érvényesülnie, közvetlen címmel, kereséssel és API-lekéréssel is.
Öröklés és megosztás
A dokumentum szülőmappákból, csoportokból, egyedi megosztásokból vagy hivatkozásokból kaphat jogokat. Az effektív hozzáférést vizsgáljuk ezekkel az utakkal együtt; egyetlen csoportlista megtekintése nem elegendő.
Index és eredeti forrás
A keresési találat nem új jogosultság. A keresőindex, dokumentumkivonatok, címek, előnézetek és eredeti forráslekérés megfelelő ellenőrzéseket igényelnek. Máskülönben már a találat címe is elárulhat bizalmas információt.
Titkosítás és jogosultság-ellenőrzés
A titkosítás például az átvitelt és tárolt adatokat védi. Külön döntés, hogy ki jogosult az alkalmazáson keresztül olvasni. A tartalmakat visszafejteni képes szolgáltatásfiók ezért nem adhatja ki azokat minden bejelentkezett felhasználónak.
Felhasználó és ügynök
Az ügynök delegált felhasználói jogokkal vagy saját szolgáltatásidentitással működhet. Mindkét modell kifejezett korlátokat igényel. A széles jogosultságú fiókkal működő közös ügynök nem kerülheti meg felhasználói jogait.
Belső és külső szolgáltatások
A belső üzemeltetésű MI-hez is kellenek forrásjogok, naplóvédelem és védett interfészek. Külső csatlakozóknál ehhez adatfogadók, szerződéses keretek, feldolgozás, tárolás és engedélyezett műveletek társulnak.
Elméleti helyzetek a vállalati mindennapokból

Mely információk legyenek közösen megtalálhatók?

„Milyen óradíjat számláz utánam a cég?”

Az ajánlatok, projektkalkulációk vagy táblázatok elszámolási díjakat és belső költségértékeket tartalmazhatnak. Ezeket meg kell különböztetni: az elszámolási díj az ügyfél felé alkalmazott ár. Fedezet csak a levonandó költségek meghatározott elhatárolásával keletkezik. A vállalati nyereség a teljes eredményszámításból adódik. Az MI ezeket az értékeket sem azonosíthatja, sem egyetlen számból látszólag pontosan nem számíthatja ki.

Az ilyen dokumentumok csatlakoztatása előtt a felelősök meghatározzák, ki mely kalkulációt láthatja. A tesztkérdéseknek a közvetlen árkérdés mellett ügyfélkedvezményekre, beszerzési feltételekre és egyedi projektárrésekre irányuló közvetett kérdéseket is tartalmazniuk kell.

Az elfelejtett projektmappa

A lezárt projekt eltűnik a portálról, de széles csoporton keresztül olvasható marad. Ha a dokumentumokat továbbra is importálják vagy csatlakozó megtalálja, az MI felhasználhatja a megfelelő tartalmakat. A megfelelő intézkedés ellenőrzött archiválási és jogosultsági döntés; a hivatkozás eltávolítása a navigációból nem elég.

Személyügyi döntések és stratégia

A tervezett létszámváltozások, felvásárlási tárgyalások, árbevételi célok, beruházások és nyereség-előrejelzések különféle tárhelyeken lehetnek. Ezért az ellenőrzés információosztályokkal és felelősökkel kezdődik. Az általánosan „belső” tárolóhely még nem mondja meg, mely részlegnek milyen egyedi információra van szüksége.

Microsoft, ChatGPT és saját tudáskeresés

Termékfunkciók ellenőrzése, jogok rendezése a forrásnál.

A Microsoft a Microsoft 365-adatokkal dolgozó Copilot-szolgáltatáshoz az adott felhasználó hozzáférési jogain belüli lekérést ír le. A túl tág olvasási jogok így is bevezetési kockázatot jelentenek. A „Copilot” név önmagában azonban sem a licenckört, sem adathozzáférést nem írja le; a csevegést, alkalmazáskontextust és további ügynököket külön kell vizsgálni. Microsoft: adatok és jogok (külső hivatkozás) – új lapon nyílik meg.

Megosztások és irányítás

A SharePoint Advanced Management támogatja a problémás hozzáférések vizsgálatát. A Microsoft Purview többek között osztályozást, érzékenységi címkéket, DLP-t és auditfunkciókat kínál. Az elérhető ellenőrzések és az általuk lefedett adatútvonalak a licenctől, konfigurációtól és termékverziótól függnek.

Megtalálhatóság korlátozása

A Restricted Content Discovery kiválasztott SharePoint-webhelyeken korlátozhatja az átfogó keresést és Copilot-felderítést. Nem módosít meglévő hozzáférési jogokat, ezért nem helyettesíti a bizalmas fájlok hozzáférés-védelmét. A közvetlen elérést és kivételeket is ellenőrizni kell.

Régi ajánlások korrigálása

A Restricted SharePoint Search kivezetés alatt áll. A gyártó szerint új aktiválása 2026. július 31. óta tiltott. Új bevezetés hosszú távú biztonsági architektúráját nem célszerű erre építeni.

Kapcsolt szolgáltatásokat használó ChatGPT esetén azt is tisztázni kell, melyik fiók engedélyezi a kapcsolatot, és milyen adat- és műveleti jogokkal rendelkezik. A felügyelt munkatér rendezi a felelősségeket, de nem javítja ki a forrásrendszer téves megosztását. Saját RAG-megoldásnál a DAXS az identitást, jogosultságszűrést és frissítést kifejezetten az architektúra részeként tervezi.

Hatékony ellenőrzések a titoktartási prompt helyett

Csak engedélyezett információ jut a modellhez.

  1. Információosztályok és tulajdonosok: A személyügyi, pénzügyi, projekt- és nyilvános tudás indokolt címzetti kört és illetékes felelősöket kap.
  2. Legkisebb jogosultság elve: A felhasználók, alkalmazások és szolgáltatásfiókok csak a szükséges jogokat kapják. Az RBAC szerepkörökhöz rendeli a jogokat; az ABAC ezenfelül olyan tulajdonságokat vehet figyelembe, mint a dokumentumosztály, szervezet vagy projekthez tartozás.
  3. Jogosultsággal ellenőrzött keresés: Az alkalmazás megbízható identitást állapít meg. A Security Trimming vagy Permission-Aware Retrieval a nyelvi modellnek történő átadás előtt korlátozza a találatokat és kivonatokat. A promptból átvett csoportnév nem identitásigazolás.
  4. Változtatások és cache-ek: Az új megosztásokat, jogvisszavonásokat, törölt forrásokat és csoportváltásokat átvezetjük. A válaszcache-ek nem keverhetik különböző felhasználók vagy ügyfélkörnyezetek adatait.
  5. DLP és védelmi szabályok: A megengedett továbbadást, feltöltést, letöltést és külső címzetteket külön ellenőrizzük. A címke önmagában csak a hozzá konfigurált és támogatott érvényesítéssel hatékony.
  6. Negatív tesztek és audit: Jogosultság nélküli tesztfiókok, közvetlen és közvetett kérdések, forrásváltozások és manipulált dokumentumok is az átvétel részei. A naplók korlátozott hozzáféréssel és megfelelő megőrzéssel rögzítik a szükséges bizonyítékot.

A Sensitive Information Disclosure és Data Leakage többet érint a látható válasznál: keresési naplók, hibaüzenetek, exportok és megosztott csevegések is tartalmazhatnak bizalmas tartalmat. A védelmi ellenőrzés a teljes adatútvonalat követi.

Amikor az MI műveleteket is végezhet

Az eszközjogok és jóváhagyások korlátozzák a kárt.

Ügynöknél a helyes, olvasási keresés nem elegendő. A túl széles jogú szolgáltatásfiók olyan adatokat módosíthat vagy küldhet el, amelyeket a megbízó munkatárs maga nem szerkeszthet. A DAXS ezért elkülöníti az olvasóeszközöket, előkészített módosításokat és tényleges végrehajtást. Az API és az MCP-szerver a célrendszerben ellenőrzi az objektumot, identitást, bemenetet és engedélyezett műveletet.

A prompt injection külső dokumentumokon vagy eszközeredményeken keresztül új cselekvési utasításokat juttathat be. Ezek a tartalmak adatok maradnak. A kritikus műveletekhez ellenőrizhető jóváhagyás kell céllal, terjedelemmel és eredmény-előnézettel. Korlátozott lépések, futási idő, költségek és megszakítási út egészítik ki ezt az ellenőrzést. Az intézkedések többek között a Prompt Injection, Sensitive Information Disclosure és Excessive Agency OWASP-kockázatait kezelik; nem jelentenek minden kockázat kizárására vonatkozó ígéretet.

Bevezetés és folyamatos felelősség

MI-biztonsági ellenőrzés ellenőrizhető terjedelemmel.

A DAXS körülhatárolt projektelemekkel támogathatja Copilot, ChatGPT vagy saját MI bevezetését: forrás- és fiókleltár, jogosultsági mátrix, adatfolyam, problémás megosztások mintavételes vizsgálata, ellenőrzött pilot és dokumentált negatív tesztek. Ebből prioritások szerinti intézkedési lista készül felelősségekkel és követhető átvételi kritériumokkal.

Az üzemeltetéshez csoport- és csatlakozóváltozások, modell- és szoftverfrissítések, biztonsági jelzések, jogosultságvizsgálatok rendszeres ismétlése és gyanús kimenetek kezelése tartozik. A műszaki munkát és szükséges adatvédelmi vagy szervezeti értékelést egyeztetjük. Egy adott konfiguráció nem általános bizonyítéka a GDPR- vagy AI Act-megfelelésnek.

A mindennapokban ezt egészíti ki MI a munkahelyen a bevezetés és oktatás. Az MI-költségoptimalizálás a védelmi igényt gazdaságos modellválasztással kapcsolja össze.

A következő észszerű lépés

Beszéljük meg a felhasználási esetét.

Melyik feladat legyen egyszerűbb, milyen adatok érintettek, és milyen rendszereket használ már? Ebből körülhatárolt indulás születik világos ellenőrzési és döntési pontokkal.

Egyszerűen elmagyarázva

Az MI megtalálhat olyan fájlokat, amelyek véletlenül túl sok embernek hozzáférhetők. A DAXS ellenőrzi, ki milyen információt olvashat és milyen műveletet végezhet. A jogokat azelőtt ellenőrizzük, hogy bizalmas szövegek kerülnének az MI-hez.