Venäjän lakien mukaan mistä tahansa Venäjällä käyttäjiensä henkilötietoja käsittelevästä yrityksestä tulee henkilötietojen ylläpitäjä, halusi se sitä tai ei. Tämä asettaa sille useita muodollisia ja menettelyllisiä velvoitteita, joita jokainen yritys ei pysty tai halua kantaa yksin.
Kuten käytäntö osoittaa, on aivan oikein, että hän ei halua, koska tämä osaamisalue on vielä niin uusi eikä käytännössä testattu, että vaikeuksia ja kysymyksiä syntyy myös ammattilaisille. Tänään puhumme siitä, kuinka toteutimme projektin asiakkaamme henkilötietojen tallentamiseksi ja mitä ilmeisiä vaikeuksia kohtasimme.
Kuinka auttoimme suojaamaan 152-FZ:n mukaisia tietoja
Vuoden 2019 alussa meihin otti yhteyttä Smart-Service LLC, joka on palvelunhallinnan alustan kehittäjä. ja yhteystietojen jakamissovellukset .
Ensimmäinen ratkaisu mahdollistaa laitteiden huoltoprosessin automatisoinnin useilla eri aloilla - kahvinkeittimien ja ilmastointilaitteiden asentamisesta toimistotiloihin kaasuturbiinien korjaamiseen. Toinen on online-suunnittelija sähköisten käyntikorttien luomiseen QR-koodien pohjalta.
Online-käyntikortti myQRcards.
Molemmat järjestelmät tallentavat ja käsittelevät käyttäjätietoja, jotka kuuluvat "henkilökohtaisten" luokitukseen 152-FZ:n mukaisesti. Tässä tapauksessa laki sanelee useita rajoituksia tällaisten henkilötietojen säilytysjärjestelmille, jotta voidaan varmistaa vaadittu turvallisuustaso ja estää luvaton pääsy varkauden tai väärinkäytön vuoksi.
Lakia on noudatettava, mutta Smart Service ei suunnitellut kehittävänsä sisällään osaamista henkilötietojen suojaamiseen. Siksi käyttäjiensä jakamat palvelut ja tiedot "siirrettiin" Linxdatacenteriin. ”Smart-Service” siirsi työympäristön palvelinkapasiteetin palvelinkeskuksemme erilliseen suojattuun verkkovyöhykkeeseen, joka on sertifioitu 152-FZ:n vaatimusten mukaisesti - ns. ”Secure Cloud”.
MITEN TURVALLINEN PIVI SUUNNITTEE?
Kaikkien henkilötietoja käsittelevien tietojärjestelmien on täytettävä kolme perusvaatimusta:
- pääsy tietojen tallennus- ja käsittelypalvelimiin on tehtävä VPN-kanavan kautta, joka on salattu GOST:n mukaisesti;
- Tietojen tallennus- ja käsittelypalvelimia on jatkuvasti valvottava virussuojauksella haavoittuvuuksien varalta;
- Varastointijärjestelmän tulee sijaita eristetyissä verkoissa.
Sijoitamme asiakkaan palvelinkapasiteetit erillisille alueille, jotka täyttävät 152-FZ:n vaatimukset ja auttavat tekemään johtopäätöksen vaatimustenmukaisuudesta.
Suojatun virtuaalisen infrastruktuurin arkkitehtuuri Smart Service LLC:lle.
työn edistymistä
Työn ensimmäinen hyväksyntä tehtiin kesäkuussa 2019, jota voidaan pitää projektin aloituspäivänä. Kaikki työ on tehtävä "elävässä" ympäristössä, jossa on tuhansia pyyntöjä päivässä. Luonnollisesti projekti piti saattaa päätökseen keskeyttämättä molempien järjestelmien normaalia toimintaa.
Siksi laadittiin ja sovittiin selkeä toimintasuunnitelma, joka jaettiin 4 vaiheeseen:
- valmistautuminen,
- muuttoliike,
- testaus ja testaus todellisissa olosuhteissa,
- mahdollistavat valvontajärjestelmät ja pääsyrajoitukset.
Varmuuden vuoksi olemme lisänneet DRP (Daster Recovery Procedure) -menettelyn. Alkuperäisen suunnitelman mukaan työ ei vaatinut paljoa aikaa ja resursseja ja sen oli määrä valmistua heinäkuussa 2019. Jokainen vaihe sisälsi lopussa täydellisen verkon käytettävyyden ja järjestelmien toimivuuden testauksen.
Vaikein vaihe, jossa "jotain voi mennä pieleen", oli muuttoliike. Alun perin suunnittelimme, että siirto toteutetaan siirtämällä kokonaisia virtuaalikoneita. Tämä oli loogisin vaihtoehto, koska se ei vaatinut lisäresurssien käyttämistä uudelleenkonfigurointiin. Vaikuttaa siltä, että vMotion voisi olla yksinkertaisempi.
Yllättäen
Kuitenkin, kuten yleensä tapahtuu suhteellisen uuden alan projekteissa, tapahtui jotain odottamatonta.
Koska kukin virtuaalikone vie 500 - 1 Gt, tällaisten taltioiden kopiointi jopa yhden datakeskuksen sisällä kesti noin 000-3 tuntia konetta kohden. Tämän seurauksena emme saavuttaneet annettua aikaikkunaa. Tämä johtui levyalijärjestelmän fyysisistä rajoituksista siirrettäessä tietoja vCloudiin.
Käytetyn vCloud-version bugi ei sallinut Storage vMotionin järjestämistä virtuaalikoneen erityyppisillä levyillä, joten levyt jouduttiin vaihtamaan. Tämän seurauksena virtuaalikoneiden siirto oli mahdollista, mutta se kesti suunniteltua kauemmin.
Toinen seikka, jota emme säätäneet, ovat tietokantaklusterin (Failover Cluster MS SQLServer) siirtorajoitukset. Tämän seurauksena klusteri oli tarpeen vaihtaa toimimaan yhden solmun kanssa ja jättää se suojatun alueen ulkopuolelle.
Huomionarvoista: vielä epäselvästä syystä virtuaalikoneiden siirron seurauksena sovellusklusteri hajosi ja se jouduttiin koomaan uudelleen.
Ensimmäisen yrityksen tuloksena saimme järjestelmien epätyydyttävän tilan ja jouduimme aloittamaan vaihtoehtojen suunnittelun ja kehittämisen uudelleen.
Yritys #2
Virheiden parissa työskenneltyään tiimi ymmärsi, että olisi oikeampaa monistaa infrastruktuuri suojatulla alueella ja kopioida vain tiedostot. Päätettiin, ettei asiakkaalta vaadita lisämaksua lisäpalvelimen kapasiteetista, joka oli otettava käyttöön siirron loppuun saattamiseksi.
Tämän seurauksena, kun suojelualueen klusterit kaksinkertaistuivat kokonaan, muutto sujui ongelmitta.
Seuraavaksi oli tarpeen vain erottaa suojattujen ja suojaamattomien vyöhykkeiden verkot. Tässä oli pieniä häiriöitä. Koko järjestelmän testausvaihe suojatulla alueella ilman suojausta pystyi käynnistymään normaalitilassa. Kerättyämme positiivisia tilastoja järjestelmän toiminnasta tässä tilassa siirryimme viimeiseen vaiheeseen: suojausjärjestelmien käynnistämiseen ja pääsyn rajoittamiseen.
Tehokas tulos ja hyödyllinen oppitunti
Tämän tuloksena yhteisin ponnisteluin asiakkaan kanssa pystyttiin tekemään merkittäviä muutoksia olemassa olevaan palvelininfrastruktuuriin, mikä mahdollisti henkilötietojen tallennuksen luotettavuuden ja turvallisuuden lisäämisen, merkittävästi pienensi luvattoman pääsyn riskejä sekä saada sertifikaatti tallennusvaatimusten noudattamisesta - saavutus, jota kaikki eivät ole vielä saavuttaneet vastaavien ohjelmistojen kehittäjät.
Lopputulos on, että projektin työpaketti näytti tältä:
- Oma aliverkko on järjestetty;
- Yhteensä siirrettiin kaksi klusteria, jotka koostuivat viidestä virtuaalikoneesta: Failover-tietokantaklusteri (kaksi virtuaalikonetta), Service Fabric -sovellusklusteri (kolme virtuaalikonetta);
- Tietosuoja- ja salausjärjestelmät on määritetty.
Kaikki näyttää selkeältä ja loogiselta. Käytännössä kaikki osoittautuu hieman monimutkaisemmaksi. Olimme jälleen vakuuttuneita siitä, että työskennellessämme tällaisen suunnitelman jokaisen yksittäisen tehtävän kanssa vaaditaan korkeinta huomiota "pieniin asioihin", jotka itse asiassa eivät ole pieniä asioita, vaan ratkaisevia tekijöitä suunnitelman onnistumiselle. koko projektin.
Lähde: will.com