Kuinka ystävystyä GOST R 57580:n ja kontin virtualisoinnin kanssa. Keskuspankin vastaus (ja ajatuksemme tästä asiasta)

Ei kauan sitten suoritimme toisen arvioinnin GOST R 57580:n (jäljempänä yksinkertaisesti GOST) vaatimusten noudattamisesta. Asiakas on sähköistä maksujärjestelmää kehittävä yritys. Järjestelmä on vakava: yli 3 miljoonaa käyttäjää, yli 200 tuhatta tapahtumaa päivittäin. Siellä he ottavat tietoturvan erittäin vakavasti.

Arviointiprosessin aikana asiakas ilmoitti satunnaisesti, että kehitysosasto aikoo käyttää virtuaalikoneiden lisäksi säiliöitä. Mutta tällä, asiakas lisäsi, on yksi ongelma: GOSTissa ei ole sanaakaan samasta Dockerista. Mitä minun pitäisi tehdä? Kuinka arvioida konttien turvallisuutta?

Kuinka ystävystyä GOST R 57580:n ja kontin virtualisoinnin kanssa. Keskuspankin vastaus (ja ajatuksemme tästä asiasta)

On totta, GOST kirjoittaa vain laitteiston virtualisoinnista - virtuaalikoneiden, hypervisorin ja palvelimen suojaamisesta. Pyysimme keskuspankilta selvennystä. Vastaus hämmästytti meitä.

GOST ja virtualisointi

Aluksi muistutetaan, että GOST R 57580 on uusi standardi, joka määrittelee "vaatimukset rahoitusorganisaatioiden tietoturvan varmistamiselle" (FI). Näihin rahoittajiin kuuluvat maksujärjestelmien operaattorit ja osallistujat, luotto- ja ei-luottoorganisaatiot, toiminta- ja selvityskeskukset.

1 alkaen rahoituksen välittäjien on suoritettava uuden GOST-vaatimusten noudattamisen arviointi. Me ITGLOBAL.COM olemme tilintarkastusyhtiö, joka suorittaa tällaisia ​​arviointeja.

GOST:ssa on alaosio, joka on omistettu virtualisoitujen ympäristöjen suojaamiselle - nro 7.8. Termiä "virtualisointi" ei ole määritelty siellä; laitteisto- ja konttivirtualisointiin ei ole jakoa. Jokainen IT-asiantuntija sanoo, että tämä on teknisesti väärin: virtuaalikone (VM) ja kontti ovat eri ympäristöjä, joilla on erilaiset eristysperiaatteet. Tämä on myös suuri ero sen isäntäkoneen haavoittuvuuden kannalta, jolla VM- ja Docker-säilöt on otettu käyttöön.

Osoittautuu, että myös virtuaalikoneiden ja konttien tietoturvallisuuden arvioinnin pitäisi olla erilainen.

Kysymyksemme keskuspankille

Lähetimme ne keskuspankin tietoturvaosastolle (esitämme kysymykset lyhennetyssä muodossa).

  1. Kuinka ottaa huomioon Docker-tyyppiset virtuaalikontit arvioitaessa GOST-yhteensopivuutta? Onko oikein arvioida tekniikkaa GOST:n kohdan 7.8 mukaisesti?
  2. Kuinka arvioida virtuaalisen kontin hallintatyökaluja? Onko mahdollista rinnastaa ne palvelimen virtualisointikomponentteihin ja arvioida ne saman GOST:n alaosan mukaan?
  3. Pitääkö minun arvioida erikseen Docker-säiliöiden sisällä olevien tietojen suojaus? Jos on, mitä turvatoimia tätä varten tulisi harkita arviointiprosessin aikana?
  4. Jos konteittaminen rinnastetaan virtuaaliseen infrastruktuuriin ja sitä arvioidaan kohdan 7.8 mukaisesti, miten GOST-vaatimukset erityisten tietoturvatyökalujen käyttöönotolle toteutetaan?

Keskuspankin vastaus

Alla tärkeimmät otteet.

"GOST R 57580.1-2017 asettaa vaatimukset teknisten toimenpiteiden toteuttamiselle seuraavien GOST R 7.8-57580.1 toimenpiteiden ZI alakohtaan 2017, jotka osaston näkemyksen mukaan voidaan laajentaa konttivirtualisoinnin käyttötapauksiin teknologiat ottaen huomioon seuraavat seikat:

  • toimenpiteiden ZSV.1 - ZSV.11 toteuttaminen tunnistamisen, autentikoinnin, valtuutuksen (pääsynvalvonnan) järjestämiseksi toteutettaessa virtuaalikoneiden ja virtualisointipalvelinkomponenttien loogista pääsyä voi poiketa kontin virtualisointiteknologian käytöstä. Tämän huomioon ottaen uskomme, että useiden toimenpiteiden (esimerkiksi ZVS.6 ja ZVS.7) toteuttamiseksi on mahdollista suositella, että rahoituslaitokset kehittävät korvaavia toimenpiteitä, joilla pyritään samoihin tavoitteisiin.
  • toimenpiteiden toteuttaminen ZSV.13 - ZSV.22 virtuaalikoneiden tietovuorovaikutuksen organisoimiseksi ja ohjaamiseksi mahdollistaa finanssiorganisaation tietokoneverkon segmentoinnin, jotta voidaan erottaa virtualisointitekniikkaa toteuttavat ja eri turvapiireihin kuuluvat informatisointiobjektit. Tämän huomioon ottaen uskomme, että kontin virtualisointiteknologiaa käytettäessä on suositeltavaa järjestää asianmukainen segmentointi (sekä suoritettaviin virtuaalisäiliöihin että käyttöjärjestelmätasolla käytettäviin virtualisointijärjestelmiin);
  • toimenpiteiden ZSV.26, ZSV.29 - ZSV.31 toteuttaminen virtuaalikoneiden kuvien suojauksen järjestämiseksi tulisi suorittaa analogisesti myös virtuaalikonttien perus- ja nykyisten kuvien suojaamiseksi;
  • toimenpiteiden ZVS.32 - ZVS.43 toteuttaminen virtuaalikoneiden ja palvelinvirtualisointikomponenttien pääsyyn liittyvien tietoturvatapahtumien tallentamiseen tulisi suorittaa analogisesti myös konttivirtualisointitekniikkaa toteuttavien virtualisointiympäristön osien osalta."

Mitä se tarkoittaa

Kaksi pääjohtopäätöstä keskuspankin tietoturvaosaston vastauksesta:

  • Säilön suojatoimenpiteet eivät eroa virtuaalikoneiden suojatoimenpiteistä;
  • Tästä seuraa, että keskuspankki rinnastaa tietoturvan yhteydessä kaksi virtualisointityyppiä - Docker-kontit ja VM:t.

Vastauksessa mainitaan myös "korvaustoimenpiteet", joita on toteutettava uhkien neutraloimiseksi. On vain epäselvää, mitä nämä "korvaavat toimenpiteet" ovat ja miten niiden riittävyyttä, täydellisyyttä ja tehokkuutta mitataan.

Mitä vikaa keskuspankin asemassa on?

Jos käytät keskuspankin suosituksia arvioinnin (ja itsearvioinnin) aikana, sinun on ratkaistava useita teknisiä ja loogisia ongelmia.

  • Jokainen suoritettava säilö vaatii tietoturvaohjelmiston (IP) asennuksen siihen: virustorjunta, eheyden valvonta, lokien käsittely, DLP-järjestelmät (Data Leak Prevention) ja niin edelleen. Kaikki tämä voidaan asentaa virtuaalikoneeseen ilman ongelmia, mutta kontin tapauksessa tietoturvan asentaminen on järjetöntä. Säiliö sisältää vähimmäismäärän "body kit", joka tarvitaan palvelun toimimiseen. SZI:n asentaminen siihen on ristiriidassa sen merkityksen kanssa.
  • Konttikuvat tulee suojata samalla periaatteella, mutta myös sen toteuttaminen on epäselvää.
  • GOST edellyttää pääsyn rajoittamista palvelimen virtualisointikomponentteihin, eli hypervisoriin. Mitä pidetään palvelinkomponenttina Dockerin tapauksessa? Eikö tämä tarkoita, että jokaista säilöä on käytettävä erillisessä isännässä?
  • Jos tavanomaista virtualisointia varten on mahdollista rajata virtuaalikoneet suojauskäyrillä ja verkkosegmenteillä, niin saman isäntäkoneen sisällä olevien Docker-säilöjen tapauksessa näin ei ole.

Käytännössä on todennäköistä, että jokainen tarkastaja arvioi konttien turvallisuutta omalla tavallaan oman tietämyksensä ja kokemuksensa perusteella. No, tai älä arvioi sitä ollenkaan, jos ei ole yhtä eikä toista.

Lisätään varmuuden vuoksi, että 1 alkaen vähimmäispistemäärä ei saa olla pienempi kuin 2021.

Muuten, julkaisemme säännöllisesti sääntelyviranomaisten vastauksia ja kommentteja, jotka liittyvät GOST 57580:n ja keskuspankkisäännösten vaatimuksiin. Sanoman kanava.

Mitä tehdä

Mielestämme rahoitusorganisaatioilla on vain kaksi vaihtoehtoa ongelman ratkaisemiseksi.

1. Vältä säiliöiden käyttöönottoa

Ratkaisu niille, jotka ovat valmiita käyttämään vain laitteiston virtualisointia ja samalla pelkäävät alhaisia ​​GOST-luokituksia ja keskuspankin sakkoja.

plus: on helpompi noudattaa GOST:n 7.8 alakohdan vaatimuksia.

Miinus: Joudumme luopumaan uusista konttivirtualisointiin perustuvista kehitystyökaluista, erityisesti Dockerista ja Kubernetesista.

2. Kieltäytyä noudattamasta GOST:n 7.8 alakohdan vaatimuksia

Mutta samalla käytä parhaita käytäntöjä tietoturvan varmistamisessa konttien kanssa työskennellessäsi. Tämä on ratkaisu niille, jotka arvostavat uutta teknologiaa ja niiden tarjoamia mahdollisuuksia. "Parhailla käytännöillä" tarkoitamme alan hyväksymiä normeja ja standardeja Docker-konttien turvallisuuden varmistamiseksi:

  • isäntäkäyttöjärjestelmän turvallisuus, oikein määritetty lokikirjaus, konttien välisen tiedonvaihdon estäminen ja niin edelleen;
  • käyttämällä Docker Trust -toimintoa kuvien eheyden tarkistamiseen ja käyttämällä sisäänrakennettua haavoittuvuusskanneria;
  • Emme saa unohtaa etäkäytön turvallisuutta ja verkkomallia kokonaisuudessaan: ARP-huijauksen ja MAC-tulvan kaltaisia ​​hyökkäyksiä ei ole peruttu.

plus: ei teknisiä rajoituksia kontin virtualisoinnin käytölle.

Miinus: on suuri todennäköisyys, että sääntelijä rankaisee GOST-vaatimusten noudattamatta jättämisestä.

Johtopäätös

Asiakkaamme päätti olla luopumatta konteista. Samaan aikaan hänen oli harkittava merkittävästi uudelleen työn laajuutta ja Dockeriin siirtymisen ajoitusta (ne kestivät kuusi kuukautta). Asiakas ymmärtää riskit erittäin hyvin. Hän ymmärtää myös, että seuraavan GOST R 57580:n noudattamisen arvioinnin aikana paljon riippuu tilintarkastajasta.

Mitä tekisit tässä tilanteessa?

Lähde: will.com

Lisää kommentti