Az ISO 27090 bemutatása MI-biztonsági csapatoknak

Az ISO/IEC 27090:2026 nemzetközi szabvány, amely útmutatást ad a mesterségesintelligencia-rendszereket érintő biztonsági fenyegetésekről és kompromittálásokról. A 2026. október 14-én megjelent szabvány azt tárgyalja, hogyan érthetik meg, észlelhetik és mérsékelhetik a szervezetek ezeket a fenyegetéseket az MI teljes életciklusa során. Hivatalos címe: Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems. Az ISO publikációs adatlapja

Egy biztonsági csapat számára a gyakorlati kérdés egyszerű: mit változtathat meg, mit lophat el, illetve mire veheti rá egy támadó az MI-rendszert, és mi korlátozná az ebből eredő kárt?

Ez az útmutató bemutatja az ISO 27090 szabvány hatókörét, az MI-biztonságot érintő főbb fenyegetéseket, a szabvány viszonyát az ISO 27001-hez és az ISO 42001-hez, valamint egy gyakorlati módszert arra, hogyan lehet az útmutatást felelősökkel, biztosítékokkal és bizonyítékokkal alátámasztott biztonsági munkává alakítani. Az alapjául szolgáló kutatást 2026. október 18-án ellenőriztük.

Mire terjed ki az ISO 27090 szabvány

Az ISO 27090 az MI-rendszerek védelmére összpontosít. Tárgya túlmutat a generatív MI-n, a nagy nyelvi modelleken és a chatbotokon, és tágabb értelemben az MI-rendszerekre terjed ki. Az ISO magyarázata az ISO 27090-ről

A megjelent szabvány a bevált információbiztonsági gyakorlatokat az MI-specifikus fenyegetésekkel kapcsolja össze. Tartalma kitér az irányításra, az ellátási lánc biztonságára, a fenyegetésmodellezésre és a red teamingre, majd a kompromittálás típusaira, köztük a mérgezésre, a kijátszásra, az információk kiszivárgására és a promptinjektálásra. Azt is vizsgálja, hogyan hatnak egymásra a kockázatcsökkentő intézkedések, és hogyan maradnak hatékonyak az idő múlásával. Az ISO/IEC 27090 közzétett mintája

A hatókör bármilyen méretű szervezetre kiterjed, amely MI-t fejleszt vagy használ, beleértve a vállalkozásokat, a kormányzati szerveket és a nonprofit szervezeteket. Egy harmadik féltől származó MI-szolgáltatás beszerzése tehát nem helyezi a szervezetet a célközönségen kívülre. Az IEC publikációs adatlapja

Hasznos kiindulópont egy közös felülvizsgálat, amelyben részt vesz a biztonsági terület, a fejlesztés, az adatcsapat, a beszerzés és az üzleti felelős. Mindegyiküknek tudnia kell elmagyarázni, a rendszer mely részét felügyeli, és mely döntésekben függ másoktól.

Miért igényelnek az MI-rendszerek további biztonsági elemzést

Egy MI-alkalmazás több olyan elemet kapcsol össze, amelyek külön vizsgálatot érdemelnek: szoftvert, adatokat, modellfájlokat vagy -szolgáltatásokat, utasításokat, felhasználókat és az ezekből következő műveleteket.

Vegyünk egy belső tudásbázishoz csatlakoztatott dokumentumasszisztenst. Egy hagyományos felülvizsgálat a hitelesítést, a titkosítást és a szoftveres sérülékenységeket vizsgálhatja. Egy MI-biztonsági felülvizsgálatnak azt is meg kell kérdeznie, mi történik, ha egy lekért dokumentum megpróbálja megváltoztatni az asszisztens utasításait, lekérhetnek-e a felhasználók a jogosultságaikon kívül eső anyagokat, és milyen műveleteket indíthat el a generált kimenet.

Ezek a kérdések még nagyobb jelentőségűvé válnak, ha az asszisztens rekordokat frissíthet vagy külső eszközöket hívhat meg. Egy hibás válasznak és egy jogosulatlan műveletnek eltérő következményei vannak, és eltérő biztosítékokat igényelnek.

Az első felülvizsgálathoz térképezzen fel három kérdést:

• Mi befolyásolhatja a rendszert? Vegye figyelembe a tanítóadatokat, a lekért tartalmakat, a promptokat, a beszállítókat és a modellfrissítéseket.
• Mi hagyhatja el a rendszert? Vegye figyelembe a válaszokat, a naplókat, az exportokat és a modelleszközöket.
• Mit változtathat meg a rendszer? Vegye figyelembe a fájlokat, a jegyeket, a fiókokat, a tranzakciókat és más csatlakoztatott szolgáltatásokat.

Ez a lenti példák hatókörének meghatározására szolgáló gyakorlati módszer, nem a szabvány pontjainak visszaadása.

Az MI-biztonságot érintő fenyegetések, amelyeket érdemes megérteni

Az alábbi magyarázatok a NIST ellenséges gépi tanulásra vonatkozó terminológiáját és az OWASP LLM-alkalmazásokra vonatkozó útmutatását követik. A forgatókönyvek szemléltető jellegűek. A NIST ellenséges gépi tanulási taxonómiája Az OWASP útmutatása a promptinjektálásról Az OWASP útmutatása a kimenetek kezeléséről

A kockázatértékelés során tartsa világosan elkülönítve ezeket a fogalmakat. Egy lekérdezéssel kiegészített generálást (RAG) alkalmazó alkalmazás által lekért rosszindulatú dokumentum nem jelent automatikusan tanítóadat-mérgezést: a lekérés önmagában nem frissíti a modell súlyait. Ehelyett közvetett promptinjektálásnak teheti ki az alkalmazást.

Az LLM-biztonság terén a szigorúbb promptok önmagukban hiányos kontrollstratégiát jelentenek. Az OWASP olyan biztosítékokat javasol, mint a korlátozott jogosultságok és az érzékeny műveletek jóváhagyása, míg az NCSC azt hangsúlyozza, hogy a promptinjektálást folyamatos kockázatként kell kezelni a rendszer tervezésén és üzemeltetésén keresztül. Az OWASP útmutatása a promptinjektálásról Az NCSC útmutatása a promptinjektálás kockázatáról

Az ISO 27090 az ISO 27001-hez és az ISO 42001-hez képest

Ezek a szabványok a szervezet biztonsági és MI-irányítási munkájának különböző részeit támogatják.

A megkülönböztetések a kiadók leírásait követik: ISO 27001, ISO 27002 és ISO 42001.

Egy már IBIR-t működtető csapat számára gyakorlati megközelítés a meglévő nyilvántartások kibővítése. Vegye fel a releváns MI-rendszereket az eszközleltárba, értékelje a támadási útvonalaikat, jelöljön ki felelősöket a kockázatkezelésre, és kapcsolja hozzájuk az alátámasztó bizonyítékokat. A munka megszervezésének hátteréhez lásd az ISO 27001 bevezetési ellenőrzőlistát.

Gyakorlati ellenőrzőlista az ISO 27090 bevezetéséhez

Az alábbi lépések a szabvány tárgyköréből és a nyilvános, biztonságos MI-re vonatkozó útmutatásokból felépített bevezetési megközelítést jelentenek. Nem hivatalos ISO-ellenőrzőlistát és nem a kötelező pontok felsorolását tartalmazzák.

1. Határozza meg a rendszert és annak felelősét

Válasszon egy egyértelmű üzleti céllal rendelkező MI-felhasználási esetet. Rögzítse az elszámoltatható felelőst, a felhasználókat, a modellszolgáltatót, a hosztolási megoldást és a csatlakoztatott szolgáltatásokat.

Ezután húzza meg a felülvizsgálat határát. Vegye bele az alkalmazást és annak függőségeit, ne csak a modell végpontját. Egy ügyfelek számára elérhető, eszközhozzáféréssel rendelkező asszisztens másfajta értékelést igényel, mint egy belső, cselekvési jogosultság nélküli szövegösszefoglaló.

Hasznos eredmény: egy rendszerrekord, amely rögzíti a célt, a határokat, a függőségeket, az engedélyezett műveleteket és az elszámoltatható felelőst.

2. Kövesse nyomon az adatok és a modellek eredetét

Rögzítse, honnan származnak az adatkészletek és a modellartefaktumok, ki módosíthatja őket, és mely verziók vannak telepítve. Vegye figyelembe a rendszer szempontjából releváns finomhangolási bemeneteket, lekérdezési gyűjteményeket, promptokat és visszajelzési csatornákat.

Az NCSC fejlesztési útmutatója az MI-eszközök és eredetük nyomon követését, védelmét, valamint a megbízható verziók helyreállításához szükséges információk megőrzését javasolja. Az NCSC útmutatója a biztonságos MI-fejlesztésről

Beszerzett modell esetén kérdezze meg a szolgáltatót, mely felelősségi köröket vállalja, és milyen információkat tesz elérhetővé, amikor a modellek vagy a szolgáltatások megváltoznak.

Hasznos eredmény: verziókövetett leltár a forrásokkal, a hozzáférési szabályokkal, a változástörténettel és a beszállítói felelősségi körökkel.

3. Modellezze a tényleges munkafolyamat fenyegetéseit

Vizsgálja meg a rendszert egy támadó szemszögéből. Azonosítsa a belépési pontokat, az érzékeny eszközöket, a jogosultságokat és egy sikeres kompromittálás következményeit. Az NCSC biztonságos tervezési útmutatója fenyegetésmodellezést, valamint a harmadik féltől származó komponensekre és a legkisebb jogosultság elvére való odafigyelést javasol. Az NCSC útmutatója a biztonságos MI-tervezésről

Írjon konkrét forgatókönyveket. Az „MI-kockázat” túl tág ahhoz, hogy hasznos intézkedést alapozzon meg. „Egy külső fél által feltöltött dokumentum ráveszi az asszisztenst, hogy egy korlátozott hozzáférésű bizonyítékfájlt kérjen le” – ez már konkrétan elemezhető feladatot ad a csapatnak.

Rangsoroljon a kitettség és a lehetséges kár alapján. Rögzítse, ki fogadja el a fennmaradó kockázatot, és mikor kell ezt a döntést újra felülvizsgálni.

Hasznos eredmény: egy rövid kockázatnyilvántartás, amely a támadási forgatókönyveket eszközökhöz, következményekhez, biztosítékokhoz és felelősökhöz kapcsolja.

4. Helyezze el a biztosítékokat a releváns határokon

Válassza ki a kezelt forgatókönyvhöz illő kontrollokat. Modelleszközök esetén ez védett tárolást, hozzáférési korlátozásokat és integritásellenőrzéseket jelenthet. Telepített szolgáltatásoknál vegye figyelembe a hitelesítést, a környezetek szétválasztását, valamint a jogosulatlan hozzáférést vagy adatkiszivárogtatást csökkentő kontrollokat. Ezek az NCSC telepítési útmutatójának témái. Az NCSC útmutatója a biztonságos MI-telepítésről

A generált kimenetet validálja és kódolja a célhelyének megfelelően, mielőtt egy másik rendszer annak alapján cselekedne. Az OWASP kimenetkezelési útmutatója elmagyarázza, miért nem szerezhet a modell kimenete pusztán azért jogosultságot, mert a modelltől származik. Az OWASP útmutatása a kimenetek kezeléséről

Hasznos eredmény: egy kontrollrekord, amely megnevezi az általa védett határt, a felelősét és az ellenőrzéséhez használt bizonyítékokat.

5. Tesztelje a teljes alkalmazást

A teszteket a fenyegetésmodellben azonosított következmények köré tervezze. Egy RAG-asszisztens esetében használjon ellenséges dokumentumokat és eltérő jogosultságú felhasználókat. Egy ágens esetében tesztelje, mi történik, ha a lekért tartalom arra kéri, hogy lépje túl az engedélyezett műveleteit.

A teszt futtatása előtt határozza meg a várt eredményt. Egy példa: az alkalmazásnak el kell utasítania egy korlátozott hozzáférésű fájlra irányuló kérést akkor is, ha a modell megpróbálja ezt a kérést végrehajtani.

Rögzítse az alkalmazás konfigurációját, a modell verzióját, a teszt bemeneteit, az eredményt és az esetleges javító intézkedéseket. Olyan tesztadatokat válasszon, amelyek nem tesznek szükségtelenül közzé valódi bizalmas információkat.

Hasznos eredmény: megismételhető biztonsági tesztek, amelyek konkrét kockázatokhoz és kiadási döntésekhez kapcsolódnak.

6. Figyelje a változásokat, és készítse elő a reagálást

Vizsgálja meg a modell-, adat- és promptfrissítések hatását. Monitorozza a releváns bemeneteket és kimeneteket, miközben védi a naplókban szereplő érzékeny információkat. Az NCSC üzemeltetési útmutatója kiemeli a viselkedés monitorozását és a változások biztonsági következményeit a teljes üzemeltetés során. Az NCSC útmutatója a biztonságos MI-üzemeltetésről

Döntse el előre, ki tilthat le egy eszközt, vonhat vissza egy hitelesítő adatot, különíthet el egy integrációt vagy állíthat vissza egy korábbi kiadást. Határozzon meg felülvizsgálati triggereket, például egy új szolgáltatót, kibővített jogosultságokat, egy jelentős modellfrissítést vagy egy biztonsági incidenst.

Hasznos eredmény: monitorozási felelősségi körök, változás-felülvizsgálati kritériumok, incidenskezelési eljárás és tesztelt helyreállítási útvonal.

Az MI-biztonsági kockázatok bizonyítékká alakítása

Az alábbi táblázat egy javasolt munkasablon. A benne szereplő bizonyítékpéldák gyakorlati ajánlások, nem az ISO 27090 által előírt dokumentumok listája.

Képzeljünk el például egy biztonsági csapatot, amely egy asszisztenssel foglaltatja össze az ügyfelek bizonyítékait. Egy beszállítói dokumentum olyan utasításokat tartalmaz, amelyek szerint a bizonyítékokat egy külső címre kell feltölteni.

A csapat tesztjének végig kell követnie a megkísérelt műveletet az alkalmazáson. Rendelkezik-e az asszisztens fájlok feltöltésére alkalmas eszközzel? Kikényszeríti-e az eszköz a felhasználó jogosultságait? Korlátozottak-e a célhelyek? Szükséges-e egy felelős személy jóváhagyása az átvitelhez?

Egy hasznos felülvizsgálati rekord azonosítaná a forgatókönyvet, az átvitelt megakadályozó határt, a teszt eredményét és azt a személyt, aki jóváhagyta a fennmaradó kockázatot. Ha a rendszer megváltozik, ez a rekord megmutatja a következő felülvizsgálónak, mit kell újra ellenőrizni.

Ez a megközelítés több tartalmat ad egy értékelésnek, mint az az állítás, hogy a rendszer „felelős MI-t” használ. A biztonsági döntést olyasmihez köti, amit egy másik személy is megvizsgálhat. Az alátámasztó anyagok rendszerezéséről bővebben lásd: hogyan strukturálja az auditfelkészültséget.

ISO 27090 tanúsítás és követelmények

Az ISO 27090 biztonsági útmutatást ad, nem pedig irányítási rendszer tanúsítására vonatkozó követelményeket. Az ISO magyarázata elkülöníti a szabvány célját az ISO 42001 AIMS-követelményeitől. Az ISO magyarázata az ISO 27090-ről

Először határozza meg, milyen bizonyosságra van szüksége: biztonsági felülvizsgálatra, ügyfeleknek szóló bizonyossági válaszra, belső hiányelemzésre vagy egy alkalmazandó irányítási rendszerszabvány szerinti tanúsításra.

Kérje meg mindazokat, akik értékelést kínálnak, hogy nevezzék meg annak hatókörét, kritériumait és bizonyossági rendszerét. Így az eredmény könnyebben értelmezhető, és elkerülhető, hogy az MI-biztonsági gyakorlatok felülvizsgálatát összekeverjék egy irányítási rendszer tanúsításával.

Egy bevezetési projekthez szerezze be a megjelent szabványt, vesse össze az útmutatást a saját rendszereivel, és rögzítse, miért megfelelőek az egyes biztosítékok. A cikkben szereplő példák kiinduló struktúrát adnak ehhez a munkához.

Az ISO 27090 és az uniós MI-rendelet

Egy nemzetközi szabvány alkalmazása nem jelenti automatikusan az uniós MI-rendeletnek való megfelelést. A 40. cikk a megfelelőség vélelmét azokhoz a harmonizált szabványokhoz köti, amelyek hivatkozásait közzétették az Európai Unió Hivatalos Lapjában, és csak annyiban, amennyiben azok lefedik a vonatkozó követelményeket vagy kötelezettségeket. Az uniós MI-rendelet 40. cikke

Az ISO 27090 szerinti biztonsági felülvizsgálatot egy külön hatókörrel meghatározott megfelelőségértékelés egyik bemeneteként használja. Rögzítse az értékelt jogi kötelezettséget, az azt alátámasztó bizonyítékokat és az esetleges fennmaradó hiányosságokat.

Gyakran ismételt kérdések az ISO 27090-ről

Mikor jelent meg az ISO 27090?

Az első kiadás, az ISO/IEC 27090:2026, 2026. október 14-én jelent meg. Ellenőrizze a kiadó aktuális adatlapját, ha régebbi anyagok tervezetre vagy korábbi évszámra hivatkoznak. Az IEC publikációs adatlapja

Kiterjed-e az ISO 27090 a generatív MI-re és az LLM-biztonságra?

A közzétett tartalomjegyzék tartalmazza a promptinjektálást és az érzékeny modellkimeneteket, így a szabvány releváns a generatív MI biztonsága szempontjából. Hatóköre más MI-rendszerekre is kiterjed. Az ISO/IEC 27090 közzétett mintája Az ISO magyarázata az ISO 27090-ről

Alkalmazhatja-e a szabványt egy harmadik féltől származó MI-t használó vállalat?

Igen. A megnevezett célközönség az MI-t használó és az MI-t fejlesztő szervezeteket egyaránt magában foglalja. Kezdje az Ön hatáskörébe tartozó kockázatokkal és felelősségi körökkel, és határozza meg, mit kell megértenie a beszállítóiról. Az IEC publikációs adatlapja

Az ISO 27001 tanúsítás azt jelenti, hogy egy MI-rendszer biztonságos?

Egy irányítási rendszer tanúsítása nem garantálja, hogy egy adott alkalmazás minden támadásnak ellenáll. Használja az irányítási rendszert a kockázati döntések rendszerezésére, és értékelje az MI-rendszer tényleges kialakítását, konfigurációját és viselkedését. Az ISO 27090 segíthet megalapozni ezt a biztonsági munkát.

Hol szerezhető be az ISO 27090 PDF?

A megjelent szabványhoz és a licencelési lehetőségekhez használja a hivatalos ISO-katalógust vagy az IEC Webstore-t. Ellenőrizze, hogy a jelölés ISO/IEC 27090:2026. Egy cikk vagy előnézet az anyagnak csak egy részét tartalmazza.

Tegye felülvizsgálhatóvá az MI-biztonsági munkát

Kezdje egy jelentős következményekkel járó MI-felhasználási esettel. Azonosítsa, hogyan kompromittálható, válasszon biztosítékokat a releváns határokra, és határozza meg azokat a bizonyítékokat, amelyek igazolják, hogy ezek a biztosítékok működnek. Rendeljen minden intézkedéshez felelőst és felülvizsgálati triggert.

A Secani egy közös biztonsági és megfelelőségi munkaterületen kapcsolja össze a követelményeket, kockázatokat, kontrollokat, bizonyítékokat, felelősöket és felülvizsgálati döntéseket. Beszéljen a Secanival arról, hogyan szervezheti meg az MI-biztonsági munkát úgy, hogy a csapatok lássák, mit értékeltek már, mi igényel figyelmet, és ki a felelős.