ISO 27090 paaiškinimas DI saugumo komandoms

ISO/IEC 27090:2026 yra tarptautinis standartas, teikiantis gaires dėl saugumo grėsmių ir kompromitavimo, turinčių įtakos dirbtinio intelekto sistemoms. Paskelbtas 2026 m. spalio 14 d., jis nagrinėja, kaip organizacijos gali suprasti, aptikti ir mažinti šias grėsmes per visą DI gyvavimo ciklą. Jo oficialus pavadinimas – Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems. ISO leidinio įrašas

Saugumo komandai praktinis klausimas paprastas: ką užpuolikas galėtų DI sistemoje pakeisti, iš jos pavogti ar priversti ją padaryti ir kas apribotų dėl to kilusią žalą?

Šiame vadove paaiškinama ISO 27090 standarto taikymo sritis, pagrindinės DI saugumo grėsmės, jo ryšys su ISO 27001 ir ISO 42001, taip pat praktinis būdas paversti gaires saugumo darbu, turinčiu atsakingus asmenis, apsaugos priemones ir įrodymus. Jo pagrindu atliktas tyrimas patikrintas 2026 m. spalio 18 d.

Ką apima ISO 27090 standartas

ISO 27090 daugiausia dėmesio skiria DI sistemų apsaugai. Jo dalykas neapsiriboja generatyviuoju DI, didžiaisiais kalbos modeliais ir pokalbių robotais – jis apima DI sistemas plačiau. ISO paaiškinimas apie ISO 27090

Paskelbtas standartas susieja nusistovėjusią informacijos saugumo praktiką su DI būdingomis grėsmėmis. Jo turinys apima valdymą, tiekimo grandinės saugumą, grėsmių modeliavimą ir raudonosios komandos testavimą (red teaming), o po to – kompromitavimo tipus, įskaitant nuodijimą, išvengimą, informacijos atskleidimą ir užklausų injekciją (prompt injection). Jame taip pat nagrinėjama, kaip rizikos mažinimo priemonės sąveikauja ir išlieka veiksmingos laikui bėgant. Paskelbto ISO/IEC 27090 pavyzdys

Taikymo sritis apima bet kokio dydžio organizacijas, kurios kuria arba naudoja DI, įskaitant įmones, valdžios institucijas ir ne pelno organizacijas. Todėl trečiosios šalies DI paslaugos įsigijimas organizacijos neišskiria iš numatytos auditorijos. IEC leidinio įrašas

Naudingas atspirties taškas – bendra peržiūra, kurioje dalyvauja saugumo, inžinerijos, duomenų, pirkimų specialistai ir verslo savininkas. Kiekvienas turėtų gebėti paaiškinti sistemos dalį, kurią kontroliuoja, ir sprendimus, kuriuos priimant priklauso nuo kitų.

Kodėl DI sistemoms reikia papildomos saugumo analizės

DI taikomoji programa sujungia kelis dalykus, kuriuos verta vertinti atskirai: programinę įrangą, duomenis, modelių failus ar paslaugas, nurodymus, naudotojus ir tolesnius veiksmus.

Pavyzdžiui, apsvarstykite dokumentų asistentą, prijungtą prie vidinės žinių bazės. Įprasta peržiūra gali nagrinėti autentifikavimą, šifravimą ir programinės įrangos pažeidžiamumus. DI saugumo peržiūroje taip pat reikėtų paklausti, kas nutinka, jei gautas dokumentas bando pakeisti asistento nurodymus, ar naudotojai gali gauti medžiagą, viršijančią jų teises, ir kokius veiksmus gali sukelti sugeneruotas rezultatas.

Šie klausimai tampa reikšmingesni, kai asistentas gali atnaujinti įrašus arba iškviesti išorinius įrankius. Klaidingas atsakymas ir neleistinas veiksmas turi skirtingas pasekmes ir reikalauja skirtingų apsaugos priemonių.

Pirmajai peržiūrai išsiaiškinkite tris klausimus:

• Kas gali paveikti sistemą? Įtraukite mokymo duomenis, gautą turinį, užklausas, tiekėjus ir modelių atnaujinimus.
• Kas gali palikti sistemą? Įtraukite atsakymus, žurnalus, eksportus ir modelio turtą.
• Ką sistema gali pakeisti? Įtraukite failus, užklausų bilietus, paskyras, operacijas ir kitas prijungtas paslaugas.

Tai praktinis taikymo srities nustatymo metodas toliau pateiktiems pavyzdžiams, o ne standarto punktų atkartojimas.

DI saugumo grėsmės, kurias reikia suprasti

Toliau pateikti paaiškinimai remiasi NIST priešiškojo mašininio mokymosi terminija ir OWASP gairėmis dėl didžiųjų kalbos modelių taikomųjų programų. Scenarijai yra iliustraciniai. NIST priešiškojo mašininio mokymosi taksonomija OWASP gairės dėl užklausų injekcijos OWASP gairės dėl rezultatų apdorojimo

Rizikos vertinimo metu aiškiai atskirkite šias sąvokas. Kenkėjiškas dokumentas, kurį gauna paieška papildyto generavimo (RAG) taikomoji programa, savaime nėra mokymo duomenų nuodijimas: paieška pati savaime neatnaujina modelio svorių. Vietoj to ji gali padaryti taikomąją programą pažeidžiamą netiesioginei užklausų injekcijai.

Didžiųjų kalbos modelių saugumui vien griežtesnės užklausos yra nepakankama kontrolės strategija. OWASP rekomenduoja tokias apsaugos priemones kaip ribotos privilegijos ir jautrių veiksmų patvirtinimas, o NCSC pabrėžia, kad užklausų injekciją reikia valdyti kaip nuolatinę riziką per sistemos projektavimą ir eksploatavimą. OWASP gairės dėl užklausų injekcijos NCSC gairės dėl užklausų injekcijos rizikos

ISO 27090, palyginti su ISO 27001 ir ISO 42001

Šie standartai padeda įvairioms organizacijos saugumo ir DI valdymo darbo dalims.

Šie skirtumai atitinka leidėjų pateiktus ISO 27001, ISO 27002 ir ISO 42001 aprašymus.

Komandai, kuri jau taiko ISMS, praktiškas būdas – išplėsti esamus įrašus. Įtraukite atitinkamas DI sistemas į turto apskaitą, įvertinkite jų atakų kelius, paskirkite rizikos tvarkymo atsakinguosius ir susiekite patvirtinančius įrodymus. Daugiau apie šio darbo organizavimą rasite ISO 27001 diegimo kontroliniame sąraše.

Praktinis ISO 27090 diegimo kontrolinis sąrašas

Toliau pateikti žingsniai yra diegimo metodas, parengtas remiantis standarto tematika ir viešomis saugaus DI gairėmis. Tai nėra oficialus ISO kontrolinis sąrašas ar privalomų punktų išdėstymas.

1. Apibrėžkite sistemą ir jos savininką

Pasirinkite DI naudojimo atvejį su aiškia verslo paskirtimi. Užregistruokite atsakingą savininką, naudotojus, modelio teikėją, talpinimo tvarką ir prijungtas paslaugas.

Tada nubrėžkite peržiūros ribą. Įtraukite taikomąją programą ir jos priklausomybes, o ne tik modelio galinį tašką. Klientams skirtam asistentui su prieiga prie įrankių reikia kitokio vertinimo nei vidiniam teksto apibendrinimo įrankiui, neturinčiam teisės atlikti veiksmų.

Naudingas rezultatas: sistemos įrašas, kuriame nurodyta jos paskirtis, ribos, priklausomybės, leidžiami veiksmai ir atsakingas savininkas.

2. Atsekite duomenų ir modelių kilmę

Užregistruokite, iš kur gaunami duomenų rinkiniai ir modelių artefaktai, kas gali juos keisti ir kurios versijos yra įdiegtos. Įtraukite sistemai svarbius derinimo įvesties duomenis, paieškos rinkinius, užklausas ir grįžtamojo ryšio kanalus.

NCSC kūrimo gairės rekomenduoja sekti DI turtą ir jo kilmę, jį apsaugoti ir išsaugoti informaciją, reikalingą patikimoms versijoms atkurti. NCSC saugaus DI kūrimo gairės

Jei modelis įsigytas, paklauskite teikėjo, už kokias pareigas jis atsako ir kokią informaciją jis pateikia, kai keičiasi modeliai ar paslaugos.

Naudingas rezultatas: versijomis žymima apskaita su šaltiniais, prieigos taisyklėmis, pakeitimų istorija ir tiekėjų pareigomis.

3. Modeliuokite faktinės darbo eigos grėsmes

Peržiūrėkite sistemą užpuoliko požiūriu. Nustatykite įėjimo taškus, jautrų turtą, teises ir sėkmingo kompromitavimo pasekmes. NCSC saugaus projektavimo gairės rekomenduoja grėsmių modeliavimą ir dėmesį trečiųjų šalių komponentams bei mažiausių privilegijų principui. NCSC saugaus DI projektavimo gairės

Rašykite konkrečius scenarijus. „DI rizika“ yra per plati sąvoka, kad paskatintų naudingą veiksmą. „Išorinės šalies įkeltas dokumentas įtikina asistentą paprašyti riboto naudojimo įrodymų failo“ suteikia komandai kai ką konkretaus analizuoti.

Prioritetus nustatykite pagal poveikį ir galimą žalą. Užregistruokite, kas prisiima likutinę riziką ir kada šį sprendimą reikėtų peržiūrėti.

Naudingas rezultatas: trumpas rizikų registras, susiejantis atakų scenarijus su turtu, pasekmėmis, apsaugos priemonėmis ir atsakingaisiais.

4. Įdiekite apsaugos priemones atitinkamose ribose

Pasirinkite kontrolės priemones scenarijui, kurį sprendžiate. Modelio turtui tai gali reikšti apsaugotą saugojimą, prieigos apribojimus ir vientisumo patikras. Įdiegtoms paslaugoms apsvarstykite autentifikavimą, aplinkų atskyrimą ir kontrolės priemones, mažinančias neleistiną prieigą ar duomenų nutekinimą. Tai yra NCSC diegimo gairių temos. NCSC saugaus DI diegimo gairės

Sugeneruotą rezultatą patvirtinkite ir užkoduokite pagal jo paskirties vietą, prieš kitai sistemai imantis veiksmų jo pagrindu. OWASP rezultatų apdorojimo gairėse paaiškinama, kodėl modelio rezultatas neturėtų įgyti įgaliojimų vien todėl, kad jį pateikė modelis. OWASP gairės dėl rezultatų apdorojimo

Naudingas rezultatas: kontrolės priemonės įrašas, kuriame nurodyta saugoma riba, jos atsakingasis ir įrodymai, naudojami jai patikrinti.

5. Išbandykite visą taikomąją programą

Kurkite testus pagal pasekmes, nustatytas jūsų grėsmių modelyje. RAG asistentui naudokite priešiškus dokumentus ir naudotojus su skirtingomis teisėmis. Agentui patikrinkite, kas nutinka, kai gautas turinys prašo jį viršyti leidžiamus veiksmus.

Prieš paleisdami testą, apibrėžkite tikėtiną rezultatą. Pavyzdys: taikomoji programa turi atmesti riboto naudojimo failo užklausą net tada, kai modelis bando tokią užklausą pateikti.

Užregistruokite taikomosios programos konfigūraciją, modelio versiją, testo įvesties duomenis, rezultatą ir bet kokius taisomuosius veiksmus. Pasirinkite testavimo duomenis, kurie be reikalo neatskleidžia tikros konfidencialios informacijos.

Naudingas rezultatas: pakartojami saugumo testai, susieti su konkrečiomis rizikomis ir išleidimo sprendimais.

6. Stebėkite pokyčius ir pasirenkite reagavimui

Peržiūrėkite modelio, duomenų ir užklausų atnaujinimų poveikį. Stebėkite atitinkamus įvesties duomenis ir rezultatus, kartu apsaugodami jautrią informaciją žurnaluose. NCSC eksploatavimo gairės pabrėžia elgsenos stebėseną ir pokyčių poveikį saugumui viso eksploatavimo metu. NCSC saugaus DI eksploatavimo gairės

Iš anksto nuspręskite, kas gali išjungti įrankį, atšaukti prisijungimo duomenis, izoliuoti integraciją ar atšaukti išleistą versiją. Nustatykite peržiūros paskatas, pavyzdžiui, naują teikėją, išplėstas teises, reikšmingą modelio atnaujinimą ar saugumo incidentą.

Naudingas rezultatas: stebėsenos pareigos, pokyčių peržiūros kriterijai, reagavimo į incidentus procedūra ir išbandytas atkūrimo kelias.

DI saugumo rizikų pavertimas įrodymais

Toliau pateikta lentelė yra siūlomas darbinis šablonas. Jos įrodymų pavyzdžiai yra praktinės rekomendacijos, o ne ISO 27090 privalomų dokumentų sąrašas.

Pavyzdžiui, įsivaizduokite saugumo komandą, kuri naudoja asistentą klientų įrodymams apibendrinti. Tiekėjo dokumente yra nurodymų įkelti įrodymus išoriniu adresu.

Komandos testas turėtų atsekti bandomą veiksmą per visą taikomąją programą. Ar asistentas turi įrankį, galintį įkelti failus? Ar tas įrankis užtikrina naudotojo teises? Ar paskirties vietos apribotos? Ar perdavimui patvirtinti reikia atsakingo asmens?

Naudingame peržiūros įraše būtų nurodytas scenarijus, perdavimą užkertanti riba, testo rezultatas ir asmuo, patvirtinęs likutinę riziką. Jei sistema pasikeičia, šis įrašas kitam peržiūrėtojui parodo, ką reikia patikrinti iš naujo.

Toks požiūris suteikia vertinimui daugiau turinio nei teiginys, kad sistema naudoja „atsakingą DI“. Jis susieja saugumo sprendimą su tuo, ką gali patikrinti kitas žmogus. Daugiau apie patvirtinančios medžiagos organizavimą skaitykite straipsnyje kaip struktūruoti pasirengimą auditui.

ISO 27090 sertifikavimas ir reikalavimai

ISO 27090 teikia saugumo gaires, o ne valdymo sistemos sertifikavimo reikalavimus. ISO paaiškinime jo paskirtis atskiriama nuo ISO 42001 nustatytų AIMS reikalavimų. ISO paaiškinimas apie ISO 27090

Pirmiausia nustatykite, kokio užtikrinimo jums reikia: saugumo peržiūros, atsakymo į kliento užtikrinimo užklausą, vidinio trūkumų vertinimo ar sertifikavimo pagal taikomą valdymo sistemos standartą.

Paprašykite visų, siūlančių vertinimą, nurodyti jo apimtį, kriterijus ir užtikrinimo schemą. Taip lengviau interpretuoti rezultatą ir išvengiama DI saugumo praktikos peržiūros painiojimo su valdymo sistemos sertifikavimu.

Diegimo projektui įsigykite paskelbtą standartą, palyginkite gaires su savo sistemomis ir užregistruokite, kodėl konkrečios apsaugos priemonės yra tinkamos. Šiame straipsnyje pateikti pavyzdžiai suteikia pradinę šio darbo struktūrą.

ISO 27090 ir ES dirbtinio intelekto aktas

Tarptautinio standarto taikymas savaime neužtikrina atitikties ES dirbtinio intelekto aktui. 40 straipsnis atitikties prezumpciją sieja su darniaisiais standartais, kurių nuorodos paskelbtos Europos Sąjungos oficialiajame leidinyje, ir tik tiek, kiek jie apima atitinkamus reikalavimus ar įpareigojimus. ES dirbtinio intelekto akto 40 straipsnis

ISO 27090 saugumo peržiūrą naudokite kaip vieną iš atskirai apibrėžtos apimties atitikties vertinimo įvesties šaltinių. Saugokite įrašą apie vertinamą teisinį įpareigojimą, jį pagrindžiančius įrodymus ir bet kokius likusius trūkumus.

Dažniausiai užduodami klausimai apie ISO 27090

Kada buvo išleistas ISO 27090?

Pirmasis leidimas, ISO/IEC 27090:2026, paskelbtas 2026 m. spalio 14 d. Patikrinkite dabartinį leidėjo įrašą, jei senesnėje medžiagoje minimas projektas ar ankstesni metai. IEC leidinio įrašas

Ar ISO 27090 apima generatyviojo DI ir didžiųjų kalbos modelių saugumą?

Jo paskelbtas turinys apima užklausų injekciją ir jautrius modelio rezultatus, todėl jis aktualus generatyviojo DI saugumui. Jo taikymo sritis apima ir kitas DI sistemas. Paskelbto ISO/IEC 27090 pavyzdys ISO paaiškinimas apie ISO 27090

Ar trečiosios šalies DI naudojanti įmonė gali taikyti šį standartą?

Taip. Nurodyta auditorija apima tiek DI naudojančias, tiek jį kuriančias organizacijas. Pradėkite nuo rizikų ir pareigų, kurias kontroliuojate, ir nustatykite, ką turite žinoti apie savo tiekėjus. IEC leidinio įrašas

Ar ISO 27001 sertifikatas reiškia, kad DI sistema yra saugi?

Valdymo sistemos sertifikatas negarantuoja, kad atskira taikomoji programa atlaikys kiekvieną ataką. Naudokite valdymo sistemą rizikos sprendimams organizuoti ir vertinkite faktinį DI sistemos projektą, konfigūraciją ir elgseną. ISO 27090 gali padėti nukreipti šį saugumo darbą.

Kur gauti ISO 27090 PDF?

Paskelbto standarto ir licencijavimo galimybių ieškokite oficialiame ISO kataloge arba IEC Webstore. Patikrinkite, ar žymuo yra ISO/IEC 27090:2026. Straipsnis ar peržiūra pateikia tik dalį medžiagos.

Padarykite DI saugumo darbą peržiūrimą

Pradėkite nuo vieno reikšmingo DI naudojimo atvejo. Nustatykite, kaip jis galėtų būti kompromituotas, pasirinkite apsaugos priemones atitinkamoms riboms ir apibrėžkite įrodymus, kurie parodys, kad tos priemonės veikia. Kiekvienam veiksmui paskirkite atsakingąjį ir peržiūros paskatą.

Secani bendroje saugumo ir atitikties darbo erdvėje susieja reikalavimus, rizikas, kontrolės priemones, įrodymus, atsakinguosius ir peržiūros sprendimus. Pasikalbėkite su Secani apie tai, kaip organizuoti DI saugumo darbą, kad komandos matytų, kas įvertinta, kam reikia dėmesio ir kas atsakingas.