В соответствии с законодательством Словакии, любая компания, работающая с личными данными своих пользователей, становится оператором ПДн, независимо от того, хочет ли она этого. Это накладывает на нее ряд формальных и процедурных обязательств, которые не каждый бизнес может или хочет исполнять самостоятельно.
Как показывает практика, многие компании совершенно правильно не хотят этого, потому что эта сфера знаний еще настолько новая и не апробированная на практике, что сложности и вопросы возникают даже у профессионалов. Сегодня мы расскажем о том, как реализовывали проект хранения персональных данных для нашего клиента и с какими неочевидными трудностями столкнулись.
Как мы помогали защитить данные в соответствии с 152-ФЗ
В начале 2019 года к нам обратилась компания ООО «Смарт-Сервис», разработчик платформы для управления сервисным обслуживанием. и приложения для обмена контактами. .
Первое решение позволяет автоматизировать процесс обслуживания оборудования в самых различных областях – от настройки кофемашин и кондиционеров в офисах до ремонта газовых турбин. Второе – онлайн-конструктор для создания электронных визиток на базе QR-кодов.
Онлайн-визитка myQRcards.
Обе системы хранят и обрабатывают данные пользователей, которые подпадают под категорию «персональных» в соответствии с 152-ФЗ. В этом случае закон устанавливает ряд ограничений на системы хранения таких персональных данных для обеспечения необходимого уровня их безопасности и исключения риска несанкционированного доступа с целью кражи или неправомерного использования.
Закон необходимо соблюдать, но «Смарт-Сервис» не планировал развивать у себя внутри компетенции по защите ПДн. Поэтому сервисы и данные, которыми делились их пользователи, «переехали» в Linxdatacenter. «Смарт-Сервис» перенес серверные мощности своего рабочего окружения в отдельную защищенную сетевую зону нашего дата-центра, сертифицированную в соответствии с требованиями, установленными в 152-ФЗ – так называемое «Защищенное облако».
КАК УСТРОЕНО ЗАЩИЩЕННОЕ ОБЛАКО
Любая информационная система, обрабатывающая персональные данные, должна удовлетворять трем основным требованиям:
- Dostop do strežnikov za shranjevanje in obdelavo podatkov mora potekati preko VPN povezave s šifriranjem v skladu z GOST;
- Strežniki za shranjevanje in obdelavo podatkov morajo biti pod stalnim nadzorom protivirusne zaščite za odsotnost ranljivosti;
- SHD mora biti lociran v izoliranih omrežjih.
Zagotavljamo strežniške kapacitete naročnika v ločenih območjih, ki ustrezajo zahtevam zakona 152-FZ, in pomagamo pridobiti potrdilo o skladnosti.
Arhitektura zaščitene virtualne infrastrukture za LLC „Smart Service“.
Potek dela
Prvotno usklajevanje del je bilo opravljeno junija 2019, kar lahko štejemo za datum začetka projekta. Vsa dela morajo potekati v 'živi' okolici z vsemi tisočimi zahtevki na dan. Seveda je bilo potrebno izvesti projekt, ne da bi prekinili običajno delovanje obeh sistemov.
Zato je bil sestavljen in usklajen jasen načrt ukrepov, razdeljen na 4 faze:
- priprava,
- migracija,
- testiranje in preverjanje v realnih pogojih,
- vključitev sistemov za nadzor in omejevanje dostopa.
Za vsak slučaj smo predvideli postopek obnovitve za nepredvidene situacije (DRP). Po prvotnem načrtu dela niso zahtevala veliko časa in virov ter bi se morala zaključiti julija 2019. Vsaka faza je predvidevala na koncu popolno testiranje omrežne dostopnosti in funkcionalnosti sistemov.
Najbolj zapletena faza, kjer bi se lahko 'kaj zgodilo narobe', je bila migracija. Sprva smo načrtovali migracijo s prenosom virtualnih strojev v celoti. To je bila najbolj logična možnost, saj ni zahtevala vključevanja dodatnih virov za ponovni konfiguracijo. Zdi se, da ne more biti nič lažjega kot vMotion.
Nepričakovano
Vendar pa se, kot je običajno pri projektih na sorazmerno novem področju, zgodilo tisto, česar nismo pričakovali.
Ker vsak virtualni stroj zaseda 500 - 1.000 GB, je kopiranje takšnih obsegov, tudi znotraj enega podatkovnega centra, trajalo približno 3-4 ure na vsak stroj. Na koncu se nismo uspeli ujeti v dodeljeni časovni okvir. To je bilo posledica fizičnih omejitev diskovnega podsistema pri prenosu podatkov v vCloud.
Hroška uporabljene različice vCloud ni dovolila izvedbe Storage vMotion v zvezi z virtualnim strojem z različnimi tipi diskov, zato so morali zamenjati diske. Posledično je bilo mogoče prenesti virtualne stroje, vendar je to zahtevalo več časa, kot je bilo načrtovano.
Drugi vidik, ki ga nismo predvideli, so bile omejitve pri premikanju skupine DB (Failover Cluster MS SQLServer). Posledično smo morali skupino prenesti na delo z enim vozliščem in jo izključiti iz zaščitene cona.
Zanimivo je, da iz še vedno nejasnega razloga pri prenosu virtualnih strojev niha skupina aplikacij in jo je bilo treba ponovno sestaviti.
Po prvem poskusu smo dobili nezadovoljujoče stanje sistemov in smo se tako prisiljeni ponovno lotiti načrtovanja in obravnave možnosti.
Poskus št. 2
S potrebno analizo napak je ekipa spoznala, da bo najbolj pravilno vseeno podvojiti infrastrukturo v zaščitni coni in kopirati le datoteke z podatki. Odločeno je bilo, da od naročnika ne zahtevamo doplačila za dodatne strežniške zmogljivosti, ki so jih morali razporediti za dokončanje migracije.
Ko so bile skupine v zaščitni coni popolnoma podvojene, je migracija potekala brez težav.
Nato je bilo treba ločiti omrežja zaščitenih in nezaščitenih con. Tu so se pojavili le nekoliko manjših prekinitev v delovanju. Faza testiranja celotnega sistema v zaščitni coni brez kakršnekoli zaščite je bila uspešno izvedena. Po zbiranju pozitivne statistike delovanja sistema v tem načinu, smo prešli na zadnjo fazo: zagon varnostnih sistemov in omejitev dostopa.
Uspešen izid in koristen nauk
Na koncu je bilo s skupnimi napori z naročnikom uspešno doseženih pomembnih sprememb v obstoječi strežniški infrastrukturi, kar je omogočilo povečanje zanesljivosti in varnosti shranjevanja osebnih podatkov, znatno zmanjšanje tveganja nepooblaščenega dostopa do njih ter pridobitev certifikata za izpolnjevanje zahtev za shranjevanje — dosežek, do katerega še zdaleč niso prišli vsi razvijalci podobne programske opreme.
Na koncu je skupina dela za projekt izgledala takole:
- Organizirana je bila posebna podmreža;
- Skupno je migrirano dva klastera, sestavljena iz petih virtualnih strojev: Failover klaster baz podatkov (dva virtualna stroja), Service Fabric klaster aplikacij (trije virtualni stroji);
- Izvedene so bile nastavitve sistemov zaščite in šifriranja podatkov.
Na prvi pogled se zdi vse jasno in logično. V praksi pa se izkaže, da je vse nekoliko bolj zapleteno. Še enkrat smo se prepričali, da pri delu z vsako posamezno nalogo tega vrste zahteva najvišjo raven pozornosti do "malenkosti", ki se na koncu izkažejo za nič drugega kot odločilni dejavniki uspeha celotnega projekta.
Izvor: habr.com
