Па расійскіх законах любая кампанія, якая працуе з асабістымі дадзенымі сваіх карыстальнікаў у Расіі, становіцца аператарам ПДн, хоча яна таго ці не. Гэта накладвае на яе шэраг фармальных і працэдурных абавязацельстваў, якія не кожны бізнэс можа ці жадае несці самастойна.
Як паказвае практыка - зусім правільна не хоча, таму што гэтая вобласць ведаў яшчэ настолькі новая і не абкатаная на практыцы, што складанасці і пытанні ўзнікаюць нават у прафесіяналаў. Сёння мы раскажам аб тым, як рэалізоўвалі праект пад захоўванне персанальных даных для нашага заказчыка і з якімі невідавочным складанасцю сутыкнуліся.
Як мы дапамагалі абараніць дадзеныя па 152-ФЗ
У пачатку 2019 года да нас звярнулася кампанія ТАА «Смарт-Сэрвіс», распрацоўшчык платформы для кіравання сэрвісным абслугоўваннем і прыкладанні для абмену кантактамі .
Першае рашэнне дазваляе аўтаматызаваць працэс абслугоўвання абсталявання ў самых розных абласцях - ад налады кофемашин і кандыцыянераў у офісных памяшканнях да рамонту газавых турбін. Другое - анлайн-канструктар для стварэння электронных візітных картак на базе QR-кодаў.
Анлайн-візітоўка myQRcards.
Абедзве сістэмы захоўваюць і апрацоўваюць дадзеныя карыстальнікаў, якія падпадаюць пад класіфікацыю "персанальных" у адпаведнасці з 152-ФЗ. У гэтым выпадку закон дыктуе шэраг абмежаванняў да сістэм захоўвання такіх персанальных дадзеных для таго, каб забяспечыць патрабаваны ўзровень іх абароненасці і выключыць рызыку несанкцыянаванага доступу з мэтай крадзяжу або неправамернага выкарыстання.
Закон трэба выконваць, але "Смарт-Сэрвіс" не планаваў развіваць у сябе ўнутры кампетэнцыі па абароне ПДн. Таму сэрвісы і дадзеныя, якімі дзяліліся іх карыстачы, "пераехалі" у Linxdatacenter. "Смарт-Сэрвіс" перанёс серверныя магутнасці працоўнага асяроддзя ў асобную абароненую сеткавую зону нашага дата-цэнтра, атэставаную ў адпаведнасці з заяўленымі ў 152-ФЗ патрабаваннямі - так званае "Абараненае воблака".
Як убудавана абароненае воблака
Любая інфармацыйная сістэма, якая апрацоўвае персанальныя дадзеныя, павінна задавальняць тром асноўным патрабаванням:
- доступ да сервераў захоўвання і апрацоўкі дадзеных павінен вырабляцца праз VPN-канал з шыфраваннем паводле ДАСТ;
- серверы захоўвання і апрацоўкі дадзеных павінны знаходзіцца пад сталым маніторынгам антывіруснай абаронай на адсутнасць уразлівасцяў;
- СГД павінен быць размешчаны ў ізаляваных сетках.
Мы размяшчаем серверныя магутнасці заказчыка ў асобных зонах, якія задавальняюць патрабаванням 152-ФЗ, і дапамагаем атрымаць заключэнне аб адпаведнасці.
Архітэктура абароненай віртуальнай інфраструктуры для ТАА "Смарт Сэрвіс".
Ход работ
Першасна ўзгадненне работ было праведзена ў чэрвені 2019 года, што можна лічыць датай пачатку праекта. Усе працы павінны быць вырабляцца на "жывым" асяроддзі з тысячамі запытаў у дзень. Натуральна, патрабавалася выканаць праект, не перарываючы штатны рэжым працы абедзвюх сістэм.
Таму быў складзены і ўзгоднены дакладны план дзеянняў, падзелены на 4 этапы:
- падрыхтоўка,
- міграцыя,
- тэсціраванне і праверка ў рэальных умовах,
- уключэнне сістэм маніторынгу і абмежаванні доступу.
На ўсялякі выпадак мы прадугледзелі працэдуру аднаўлення ў выпадку непрадбачанай сітуацыі (DRP). Па першапачатковым плане працы не займалі шмат часу і рэсурсаў і павінны былі завяршыцца ў ліпені 2019. Кожны з этапаў прадугледжваў у канцы поўнае тэсціраванне сеткавай даступнасці і функцыянальнасці сістэм.
Самым складаным этапам, у якім магло "нешта пайсці не так", была міграцыя. Першапачаткова мы меркавалі праводзіць міграцыю шляхам пераносу віртуальных машын цалкам. Гэта быў самы лагічны варыянт, паколькі ён не патрабаваў уцягвання дадатковых рэсурсаў для пераканфігуравання. Падавалася б, што можа быць прасцей vMotion.
Нечакана-нечакана
Аднак, як звычайна бывае на праектах у адносна новай вобласці, адбылося тое, чаго не чакалі.
Паколькі кожная віртуальная машына займае 500 – 1 000 ГБ, капіраванне такіх аб'ёмаў нават у рамках аднаго дата-цэнтра заняло каля 3-4 гадзін на кожную машыну. Як вынік, мы не ўклаліся ў адведзенае часовае акно. Гэта адбылося з прычыны фізічных абмежаванняў дыскавай падсістэмы пры пераносе дадзеных у vCloud.
Баг выкарыстоўванай версіі vCloud не дазволіў арганізаваць Storage vMotion у стаўленні віртуальнай машыны з рознымі тыпамі кружэлак, таму кружэлкі прыйшлося змяняць. У выніку перанесці віртуальныя машыны ўдалося, але гэта заняло больш часу, чым планавалася.
Другі момант, які мы не прадугледзелі, – абмежаванні па перамяшчэнні кластара БД (Failover Cluster MS SQLServer). У выніку прыйшлося перавесці кластар у працу з адным вузлом і пакінуць яго за рамкамі абароненай зоны.
Характэрна: па да гэтага часу незразумелай прычыне ў выніку пераносу віртуальных машын рассыпаўся кластар прыкладанняў, і яго прыйшлося збіраць зноўку.
У выніку першай спробы мы атрымалі нездавальняючы стан сістэм і змушаныя былі нанова брацца за планаванне і прапрацоўку варыянтаў.
Спроба №2
Правёўшы працу над памылкамі, каманда зразумела, што правільней будзе ўсё ж дубліраваць інфраструктуру ў абароненай зоне і скапіяваць толькі файлы з дадзенымі. Было прынята рашэнне не патрабаваць ад замоўца даплаты за дадатковыя серверныя магутнасці, якія прыйшлося разгарнуць для завяршэння міграцыі.
У выніку, калі кластары ў абароненай зоне былі поўнасцю прадубліраваны, міграцыя прайшла без праблем.
Далей патрабавалася толькі падзяліць сеткі абароненай і неабароненай зон. Тут абышлося некалькімі нязначнымі перабоямі ў рабоце. Этап тэсціравання ўсёй сістэмы ў абароненай зоне без якой-небудзь абароны ўдалося запусціць у штатным рэжыме. Сабраўшы станоўчую статыстыку працы сістэмы ў такім рэжыме, мы перайшлі да апошняга этапу: запуску сістэм абароны і абмежаванні доступу.
Выніковы зыход і карысны ўрок
У выніку, сумеснымі намаганнямі разам з заказчыкам удалося ўнесці значныя змены ў існуючую серверную інфраструктуру, што дазволіла павысіць надзейнасць і абароненасць захоўвання ПДН, істотна знізіць рызыкі несанкцыянаванага доступу да іх, атрымаць атэстат выканання патрабаванняў да захоўвання - дасягненне, да якога прыйшлі яшчэ далёка не ўсе. распрацоўшчыкі аналагічнага ПЗ.
У сухой рэштцы комплекс прац па праекце выглядаў так:
- Арганізавана выдзеленая падсетка;
- Сумарна мігравана два кластары, якія складаюцца з пяці віртуальных машын: Failover кластар баз дадзеных (дзве віртуальныя машыны), Service Fabric кластар прыкладанняў (тры віртуальныя машыны);
- Выраблены налады сістэм абароны і шыфравання дадзеных.
Выглядае быццам бы ўсё зразумела і лагічна. На практыцы ж усё аказваецца крыху больш складана. Мы яшчэ раз пераканаліся, што пры працы з кожнай асобнай задачай такога плану патрабуецца найвышэйшы ўзровень увагі да «дробязяў», якія на паверку апыняюцца ніякімі не дробязямі, а вызначальнымі фактарамі поспеху ўсяго праекту.
Крыніца: habr.com
