Kaip susidraugauti su GOST R 57580 ir konteinerių virtualizavimu. Centrinio banko atsakymas (ir mūsų mintys šiuo klausimu)

Neseniai atlikome dar vieną atitikties GOST R 57580 (toliau – tiesiog GOST) reikalavimams vertinimą. Klientas – įmonė, kurianti elektroninę mokėjimo sistemą. Sistema rimta: daugiau nei 3 milijonai vartotojų, daugiau nei 200 tūkstančių operacijų kasdien. Ten jie labai rimtai žiūri į informacijos saugumą.

Vertinimo proceso metu klientas atsainiai pranešė, kad plėtros skyrius, be virtualių mašinų, planuoja naudoti konteinerius. Tačiau klientas pridūrė, kad yra viena problema: GOST nėra nė žodžio apie tą patį „Docker“. Ką turėčiau daryti? Kaip įvertinti konteinerių saugumą?

Tiesa, GOST rašo tik apie aparatinės įrangos virtualizavimą – apie tai, kaip apsaugoti virtualias mašinas, hipervizorių ir serverį. Mes paprašėme Centrinio banko paaiškinimo. Atsakymas mus suglumino.

GOST ir virtualizacija

Pirmiausia prisiminkime, kad GOST R 57580 yra naujas standartas, nurodantis „finansinių organizacijų informacijos saugumo užtikrinimo reikalavimus“ (FI). Šie FI apima mokėjimo sistemų operatorius ir dalyvius, kredito ir nekreditines organizacijas, veiklos ir kliringo centrus.

Nuo 1 m. sausio 2021 d. FI privalo atlikti įvertinimas, ar laikomasi naujojo GOST reikalavimų. Mes, ITGLOBAL.COM, esame audito įmonė, kuri atlieka tokius vertinimus.

GOST turi poskyrį, skirtą virtualizuotų aplinkų apsaugai - Nr. 7.8. Terminas „virtualizacija“ ten nenurodytas, nėra skirstymo į aparatinę ir konteinerio virtualizaciją. Bet kuris IT specialistas pasakys, kad techniniu požiūriu tai neteisinga: virtuali mašina (VM) ir konteineris yra skirtingos aplinkos, turinčios skirtingus izoliavimo principus. Kalbant apie pagrindinio kompiuterio, kuriame įdiegti VM ir Docker konteineriai, pažeidžiamumą, tai taip pat yra didelis skirtumas.

Pasirodo, VM ir konteinerių informacijos saugumo vertinimas taip pat turėtų skirtis.

Mūsų klausimai Centriniam bankui

Išsiuntėme juos Centrinio banko Informacijos saugumo departamentui (klausimus pateikiame sutrumpintai).

1. Kaip įvertinti Docker tipo virtualius konteinerius vertinant atitiktį GOST? Ar teisinga technologiją vertinti pagal GOST 7.8 poskyrį?
2. Kaip įvertinti virtualių konteinerių valdymo įrankius? Ar galima juos prilyginti serverio virtualizacijos komponentams ir įvertinti pagal tą patį GOST poskyrį?
3. Ar reikia atskirai įvertinti informacijos saugumą „Docker“ konteineriuose? Jei taip, į kokias apsaugos priemones reikėtų atsižvelgti atliekant vertinimo procesą?
4. Jeigu konteinerizavimas prilyginamas virtualiai infrastruktūrai ir vertinamas pagal 7.8 poskyrį, kaip įgyvendinami GOST reikalavimai diegti specialias informacijos saugos priemones?

Centrinio banko atsakymas

Žemiau pateikiamos pagrindinės ištraukos.

„GOST R 57580.1-2017 nustato reikalavimus įgyvendinimui taikant technines priemones, susijusias su šiomis GOST R 7.8-57580.1 ZI 2017 poskyrio priemonėmis, kurios, Departamento nuomone, gali būti išplėstos konteinerių virtualizacijos naudojimo atvejais. technologijas, atsižvelgiant į šiuos dalykus:

• priemonių ZSV.1 - ZSV.11, skirtų identifikavimo, autentifikavimo, autorizacijos (prieigos kontrolės) organizavimui, įgyvendinant loginę prieigą prie virtualių mašinų ir virtualizacijos serverio komponentų, įgyvendinimas gali skirtis nuo konteinerių virtualizacijos technologijos naudojimo atvejų. Atsižvelgiant į tai, siekiant įgyvendinti daugybę priemonių (pavyzdžiui, ZVS.6 ir ZVS.7), manome, kad galima rekomenduoti finansų įstaigoms parengti kompensacines priemones, kuriomis būtų siekiama tų pačių tikslų;
• įgyvendinant virtualiųjų mašinų informacinės sąveikos organizavimo ir kontrolės priemones ZSV.13 - ZSV.22 numatyta finansinės organizacijos kompiuterių tinklo segmentacija, siekiant atskirti virtualizacijos technologiją diegiančius ir skirtingoms saugumo grandinėms priklausančius informatizacijos objektus. Atsižvelgdami į tai, manome, kad naudojant konteinerių virtualizavimo technologiją patartina numatyti tinkamą segmentavimą (tiek vykdomųjų virtualių konteinerių, tiek operacinės sistemos lygiu naudojamų virtualizacijos sistemų atžvilgiu);
• priemonių ZSV.26, ZSV.29 - ZSV.31, skirtų virtualių mašinų vaizdų apsaugai organizuoti, įgyvendinimas turėtų būti vykdomas pagal analogiją taip pat siekiant apsaugoti pagrindinius ir esamus virtualių konteinerių vaizdus;
• Informacijos saugumo įvykių, susijusių su prieiga prie virtualių mašinų ir serverių virtualizacijos komponentų, ZVS.32 - ZVS.43 priemonių įgyvendinimas pagal analogiją turėtų būti vykdomas ir virtualizacijos aplinkos elementų, diegiančių konteinerių virtualizavimo technologiją, atžvilgiu.

Ką tai reiškia

Dvi pagrindinės išvados iš Centrinio banko informacijos saugumo departamento atsakymo:

• konteinerių apsaugos priemonės niekuo nesiskiria nuo virtualių mašinų apsaugos priemonių;
• Iš to išplaukia, kad informacijos saugumo kontekste Centrinis bankas prilygina dvi virtualizacijos rūšis – Docker konteinerius ir VM.

Atsakyme taip pat minimos „kompensacinės priemonės“, kurias reikia taikyti grėsmėms neutralizuoti. Tik neaišku, kas yra šios „kompensacinės priemonės“ ir kaip įvertinti jų tinkamumą, išsamumą ir veiksmingumą.

Kas negerai su centrinio banko pozicija?

Jei vertinimo (ir įsivertinimo) metu naudojatės Centrinio banko rekomendacijomis, turite išspręsti daugybę techninių ir loginių sunkumų.

• Kiekviename vykdomajame konteineryje reikia įdiegti informacijos apsaugos programinę įrangą (IP): antivirusinė, vientisumo stebėjimas, darbas su žurnalais, DLP sistemos (Data Leak Prevention) ir pan. Visa tai be problemų galima įdiegti VM, tačiau konteinerio atveju informacijos apsaugos įdiegimas yra absurdiškas žingsnis. Talpykloje yra minimalus „kūno rinkinio“ kiekis, kurio reikia, kad paslauga veiktų. SZI įdiegimas jame prieštarauja jo prasmei.
• Konteinerių vaizdai turėtų būti apsaugoti pagal tą patį principą; kaip tai įgyvendinti, taip pat neaišku.
• GOST reikalauja apriboti prieigą prie serverio virtualizacijos komponentų, ty prie hipervizoriaus. Kas Docker atveju laikomas serverio komponentu? Ar tai nereiškia, kad kiekvienas konteineris turi būti paleistas atskirame pagrindiniame kompiuteryje?
• Jei naudojant įprastą virtualizavimą galima atskirti VM pagal saugos kontūrus ir tinklo segmentus, tai to paties pagrindinio kompiuterio „Docker“ konteinerių atveju taip nėra.

Praktikoje tikėtina, kad kiekvienas auditorius konteinerių saugumą įvertins savaip, remdamasis savo žiniomis ir patirtimi. Na, arba visai nevertinti, jei nėra nei vieno, nei kito.

Tik tuo atveju pridėsime, kad nuo 1 m. sausio 2021 d. minimalus balas turi būti ne mažesnis kaip 0,7.

Beje, mes reguliariai skelbiame reguliavimo institucijų atsakymus ir komentarus, susijusius su GOST 57580 reikalavimais ir Centrinio banko taisyklėmis. Telegramos kanalas.

Ką daryti

Mūsų nuomone, finansinės organizacijos turi tik dvi problemos sprendimo galimybes.

1. Venkite įdiegti konteinerius

Sprendimas tiems, kurie yra pasirengę sau leisti naudoti tik aparatinę virtualizaciją ir tuo pačiu bijo žemų reitingų pagal GOST ir centrinio banko baudų.

Plius: lengviau laikytis GOST 7.8 poskyrio reikalavimų.

Minusas: Turėsime atsisakyti naujų kūrimo įrankių, pagrįstų konteinerių virtualizavimu, ypač „Docker“ ir „Kubernetes“.

2. Atsisakyti laikytis GOST 7.8 poskyrio reikalavimų

Tačiau tuo pat metu taikykite geriausią praktiką užtikrindami informacijos saugumą dirbant su konteineriais. Tai sprendimas tiems, kurie vertina naujas technologijas ir jų teikiamas galimybes. „Geriausia praktika“ reiškia pramonės priimtas normas ir standartus, užtikrinančius „Docker“ konteinerių saugumą:

• pagrindinio kompiuterio OS saugumas, tinkamai sukonfigūruotas registravimas, duomenų mainų tarp konteinerių draudimas ir pan.;
• naudojant Docker Trust funkciją vaizdų vientisumui patikrinti ir naudojant integruotą pažeidžiamumo skaitytuvą;
• Mes neturime pamiršti apie nuotolinės prieigos saugumą ir viso tinklo modelį: tokios atakos kaip ARP apgaulė ir MAC užtvindymas nebuvo atšauktos.

Plius: jokių techninių apribojimų naudojant konteinerio virtualizaciją.

Minusas: didelė tikimybė, kad reguliatorius nubaus už GOST reikalavimų nesilaikymą.

išvada

Mūsų klientas nusprendė neatsisakyti konteinerių. Tuo pačiu metu jis turėjo gerokai persvarstyti darbo apimtį ir perėjimo prie „Docker“ laiką (jie truko šešis mėnesius). Klientas puikiai supranta riziką. Jis taip pat supranta, kad kitą kartą vertinant atitiktį GOST R 57580, daug kas priklausys nuo auditoriaus.

Ką darytumėte šioje situacijoje?

Šaltinis: www.habr.com