
За російськими законами будь-яка компанія, яка працює з особистими даними своїх користувачів у Росії, стає оператором ПДн, хоче вона того чи ні. Це накладає на неї низку формальних та процедурних зобов'язань, які не кожен бізнес може чи хоче нести самостійно.
Як показує практика – абсолютно правильно не хоче, тому що ця галузь знань ще настільки нова і не обкатана на практиці, що складнощі та питання виникають навіть у професіоналів. Сьогодні ми розповімо про те, як реалізовували проект під зберігання персональних даних для нашого замовника та з якими неочевидними труднощами зіткнулися.
Як ми допомагали захистити дані щодо 152-ФЗ
На початку 2019 року до нас звернулася компанія ТОВ «Смарт-Сервіс», розробник платформи для керування сервісним обслуговуванням та програми для обміну контактами .
Перше рішення дозволяє автоматизувати процес обслуговування обладнання в різних областях - від налаштування кофемашин і кондиціонерів в офісних приміщеннях до ремонту газових турбін. Друге – онлайн-конструктор для створення електронних візитних карток на базі QR-кодів.

Онлайн-візитка myQRcards.
Обидві системи зберігають та обробляють дані користувачів, які підпадають під класифікацію «персональних» відповідно до 152-ФЗ. У цьому випадку закон диктує низку обмежень до систем зберігання таких персональних даних для того, щоб забезпечити необхідний рівень їхньої захищеності та виключити ризик несанкціонованого доступу з метою розкрадання чи неправомірного використання.
Закон потрібно дотримуватись, але «Смарт-Сервіс» не планував розвивати у себе всередині компетенції захисту ПДн. Тому сервіси та дані, якими ділилися їхні користувачі, переїхали в Linxdatacenter. «Смарт-Сервіс» переніс серверні потужності робочого оточення в окрему захищену мережеву зону нашого дата-центру, атестовану відповідно до заявлених у 152-ФЗ вимог – так звану «Захищену хмару».
ЯК ВЛАШЕНО ЗАХИЩЕНУ Хмару
Будь-яка інформаційна система, що обробляє персональні дані, має задовольняти трьом основним вимогам:
- доступ до серверів зберігання та обробки даних повинен здійснюватися через VPN-канал із шифруванням згідно з ГОСТ;
- сервери зберігання та обробки даних повинні знаходитися під постійним моніторингом антивірусного захисту на відсутність уразливостей;
- СГД має бути розташований в ізольованих мережах.
Ми розміщуємо серверні потужності замовника в окремих зонах, що відповідають вимогам 152-ФЗ, та допомагаємо отримати висновок про відповідність.

Архітектура захищеної віртуальної інфраструктури для ТОВ "Смарт Сервіс".
хід робіт
Спочатку узгодження робіт було здійснено в червні 2019 року, що можна вважати датою початку проекту. Усі роботи мають проводитися на «живому» оточенні з тисячами запитів на день. Звичайно, потрібно виконати проект, не перериваючи штатний режим роботи обох систем.
Тому було складено та узгоджено чіткий план дій, розділений на 4 етапи:
- підготовка,
- міграція,
- тестування та перевірка в реальних умовах,
- включення систем моніторингу та обмеження доступу.
Про всяк випадок ми передбачили процедуру відновлення у разі непередбаченої ситуації (DRP). За початковим планом роботи не займали багато часу та ресурсів і мали завершитись у липні 2019. Кожен з етапів передбачав наприкінці повне тестування мережевої доступності та функціональності систем.
Найскладнішим етапом, у якому могло щось піти не так, була міграція. Спочатку ми планували проводити міграцію шляхом перенесення віртуальних машин. Це був логічний варіант, оскільки він не вимагав залучення додаткових ресурсів для переконфігурування. Здавалося б, що можливо простіше vMotion.
Несподівано-негадано
Однак, як зазвичай буває на проектах щодо нової області, трапилося те, чого не чекали.
Оскільки кожна віртуальна машина займає 500-1 ГБ, копіювання таких обсягів навіть у рамках одного дата-центру зайняло близько 000-3 годин на кожну машину. Як результат, ми не вклалися у відведене тимчасове вікно. Це сталося через фізичні обмеження дискової підсистеми під час перенесення даних до vCloud.
Баг використовуваної версії vCloud не дозволив організувати Storage vMotion щодо віртуальної машини з різними типами дисків, тому диски довелося змінювати. В результаті перенести віртуальні машини вдалося, але це зайняло більше часу, ніж планувалося.
Другий момент, який ми не передбачили, - обмеження щодо переміщення кластера БД (Failover Cluster MS SQLServer). В результаті довелося перевести кластер у роботу з одним вузлом та залишити його за рамками захищеної зони.
Примітно: досі незрозумілою причиною внаслідок перенесення віртуальних машин розсипався кластер додатків, і його довелося збирати заново.
В результаті першої спроби ми отримали незадовільний стан систем і змушені були знову братися за планування і опрацювання варіантів.
спроба №2
Провівши роботу над помилками, команда зрозуміла, що правильніше буде все ж таки дублювати інфраструктуру в захищеній зоні і скопіювати лише файли з даними. Вирішили не вимагати від замовника доплати за додаткові серверні потужності, які довелося розгорнути для завершення міграції.
В результаті, коли кластери в захищеній зоні були повністю продубльовані, міграція пройшла без проблем.
Далі потрібно лише розділити мережі захищеної та незахищеної зон. Тут обійшлося кількома незначними перебоями у роботі. Етап тестування всієї системи у захищеній зоні без будь-якого захисту вдалося запустити у штатному режимі. Зібравши позитивну статистику роботи системи у такому режимі, ми перейшли до останнього етапу: запуску систем захисту та обмеження доступу.
Результативний результат та корисний урок

У результаті спільними зусиллями разом із замовником вдалося внести значні зміни до існуючої серверної інфраструктури, що дозволило підвищити надійність і захищеність зберігання ПДН, суттєво знизити ризики несанкціонованого доступу до них, отримати атестат виконання вимог до зберігання — досягнення, до якого дійшли ще далеко не всі розробники аналогічного ПЗ.
У сухому залишку комплекс робіт із проекту виглядав так:
- Організована виділена підмережа;
- Сумарно мігровано два кластери, що складаються з п'яти віртуальних машин: Failover кластер баз даних (дві віртуальні машини); Service Fabric кластер додатків (три віртуальні машини);
- Здійснено налаштування систем захисту та шифрування даних.
Виглядає начебто все зрозуміло та логічно. На практиці все виявляється трохи складніше. Ми ще раз переконалися, що при роботі з кожним окремим завданням такого плану потрібен найвищий рівень уваги до «дрібниць», які насправді виявляються ніякими не дрібницями, а визначальними чинниками успіху всього проекту.
Джерело: habr.com
