Дані під наглядом: як захистити себе та своїх клієнтів. Чекліст від співзасновника Finmap Івана Каунова

Опитування 800 HR-директорів від Gartner показало, що 88% компаній та організацій у всьому світі зробили обов'язковим або рекомендували перейти на віддалений режим роботи своїм співробітникам під час пандемії COVID-19. Масовий перехід в онлайн породив нові традиції та нові проблеми. 66% керівників стали свідками фішингових атак та роботи програм-шантажистів.

Не дивно, що у 2021 році дві третини компаній планували більше вкладати у кібербезпеку. Керівники не хочуть, аби потреба надсилати або зберігати дані онлайн призвела до краху їхнього бізнесу.

Які рішення може використовувати сервіс, щоб убезпечити дані клієнта від викрадення? Розкажемо, як це робимо ми у Finmap.

1. Хмарні сервіси

Хмарні сервіси мають кілька переваг. По-перше, це продукти гігантів, які інвестують достатньо коштів у свої проєкти. По-друге, дані не розташовані фізично в одному місці, а розкидані по різних серверах. Через це вкрасти їх важко, а відновити набагато легше.

2. Перевірені датацентри

Ми працюємо із західноєвропейськими датацентрами, обладнання яких має сертифікат ISO/IEC 27001. Це спеціальний міжнародний стандарт, який потребує певних регламентів інформаційної безпеки та гарантує конфіденційність. Обмін даними між клієнтами та сервісом відбувається з використанням SSL-з'єднань.

Для того щоб обрати датацентр, його потрібно перевірити та дослідити. На допомогу прийде Google. 

Що перевіряти: місцерозташування, під яку юрисдикцію потрапляє, чи були кейси з криптолокерами. Також варто вивчити політику датацентру щодо різного контенту та заборонених видів діяльності. Зазвичай це той самий перелік, але іноді датацентр обмежує діяльність, пов'язану з високим навантаженням, майнінгом криптовалют тощо.

Якщо датацентр розташований за кордоном, краще зробити демоверсію. Можна піти далі: організувати онлайн-дзвінок та попросити показати, як фізично виглядає сервер. Потрібно також ознайомитися з рішеннями, які пропонує датацентр: це можуть бути вже шифровані диски, окремо виділені канали зв'язку (по VPN). Якщо таких рішень немає, їх можна розробити самостійно: зробити тунелі зв'язку, щоб дані передавали у шифрованому вигляді на хмарний сервер.

Окремо варто згадати про географічний чинник. Наприклад, якщо клієнти живуть в Іспанії, то їм легше брати дані з іспанського датацентру. Це зменшить швидкість завантаження під час передання даних. Якщо хмарний провайдер (Cloud provider) дозволяє розмістити фізичну точку доступу в Іспанії, ми це зробимо. Тоді дані, якими клієнти часто користуються, розмістимо там за допомогою реплікації. Між серверами вони передаватимуться у знеособленому вигляді.

Загалом ми аналізуємо та визначаємо необхідну кількість ресурсів у певному регіоні. На основі цього обираємо хмарний провайдер, який надасть нам оболонку доступу до датацентрів: віртуальні машини, фізичні машини, оперативну пам'ять, процесор, місце для зберігання. Завдяки таким провайдерам нам не потрібно встановлювати операційну систему, нас не цікавить, скільки електроенергії споживає сервер, а просто користуємося готовими потужностями. Content Delivery Network буде поблизу від користувачів. Ця мережа дозволяє зберігати всю статику (оболонку сайту без даних користувачів) будь-де у межах CDN. Наприклад, для користувача з України CDN може бути й у Києві. Дані клієнтів можуть проходити через цю мережу, але зберігатимуться лише у датацентрах.

3. Обмеження доступу

Наш регламент взагалі не передбачає прямого контакту наших співробітників з даними клієнта. Усі дані, які надають користувачі, обробляються і розміщуються на майданчиках хмарних провайдерів. Дані на цих майданчиках шифруються та передаються між провайдерами за private network.

За потреби (наприклад, під час звернення до служби підтримки) клієнт «запрошує» працівника всередині самого сервісу. Він також може «запрошувати» інших користувачів — своїх співробітників — з різними рівнями прав: повний доступ, лише читання, право на додавання певних операцій, право на перегляд історії, право з обмеженням перегляду статистики тощо.

Тому клієнт може обмежити інформацію для демонстрації. Доступи нашим співробітникам надаються залежно від необхідних процесів та процедур, які заздалегідь узгоджені з клієнтом. І, безперечно, всі маніпуляції з даними клієнта логуються. Логи містяться у сховищі бекапів у зашифрованому вигляді протягом трьох місяців, після чого видаляються. Усе задля того, щоб можна було за потреби відновити їх у приватному кабінеті користувача. Після  офіційного запиту клієнта про видалення персональних даних їх знищують протягом 24 годин.

4. Відмова від зайвих даних

Наш сервіс призначений для обліку грошей підприємств та організацій. Але це не означає, що необхідно розкривати всі справжні дані: юридичну назву, ЄДРПОУ, дані клієнтів чи контрагентів. Усе, що нам потрібно, — це назва вашої компанії та в якій валюті ви хочете бачити звіти. При цьому всі назви та імена можуть бути вигаданими, навіть назва компанії. Головне, щоб клієнт розумів, про що йдеться, а розкривати офіційну інформацію сервісу немає жодної потреби. Наша компанія перебуває  у британській юрисдикції, а це означає, що ми не можемо надавати третім особам інформацію про користувачів.

5. Фільтрування трафіку

Окрім звичайних користувачів і гостей на сайти та онлайн-сервіси заходять і недоброзичливі відвідувачі: «павуки» (відомі як пошукові боти, crawlers) та хакери. Хмарний провайдер, з яким співпрацює Finmap, автоматично підключає фільтрацію через Cloudflare. Таким чином ми захищаємо свій сервіс від DDoS-атаки та збільшуємо швидкість завантаження.

Існують також альтернативи: Amazon CloudFront, Akamai. Додаткове фільтрування можна підключити ще на етапі оброблення даних. Можна обмежити рейт-ліміти (кількість запитів за період від конкретного вузла мережі або користувача) за певними запитами, щоб фільтрувати небажаний або паразитарний трафік у нашій мережі. Це може відбуватися на рівні серверів, які безпосередньо приймають трафік із мережі. Вони працюють на базі NGINX Ingress — Ingress-контролера для Kubernetes. 

Kubernetes — це система з відкритим кодом, яку запустив Google більш як 10 років тому. Її призначення — розгортання, масштабування та керування контейнезованими програмами. Ingress-контролер у цій системі створює велику гнучкість у розподілі трафіку. Небажані запити просто блокуються, а решта вхідного трафіку спрямовується на сайт.

6. Обмежені дані щодо API-інтеграцій

У нашого сервісу розроблені інтеграції з найпопулярнішими українськими банками — monobank та ПриватБанк. Відбуваються вони за правилами банків після узгодження ключів доступу. У відповідь на авторизований запит API банки надають інформацію за певний період.

Перший раз користувач самостійно підтверджує інтеграцію з його рахунком за посиланням або QR-кодом. Цю згоду будь-якої миті можна відкликати, і сервіс припинить отримувати дані. У кабінеті підвантажені дані з банку відображаються так, ніби їх вніс сам користувач з усіма відповідними правами. Банківська інформація містить лише дані щодо операції: сума, дата та опис. Оригінали виписок сервіс не зберігає у жодному вигляді (ані логів, ані бекапів). Збережені дані підв'язуються під користувача та його компанію. Будь-якої миті їх можна відредагувати або видалити.

В Україні підключати інтеграцію з банками складно через нерозвинені Open Banking API. А правила у всіх, хто надає API, відрізняються. 

7. Регулярний аудит інфраструктури

Потрібно постійно проводити аудит безпеки та інфраструктури сервісів. Це дозволяє з'ясувати, чи відповідають версії операційних систем та програмне забезпечення потребам клієнтів. До прикладу, у нас моніторинг діє 24/7 на базі open-source рішень Prometheus і Grafana. Завдяки цьому можна постійно переглядати журнали щодо підозрілої активності та розуміти стан кожного вузла. Якщо хтось зовні спробує зайти до віртуальної приватної мережі, система сповістить про це. Також моніторинг сигналізує, коли щось пішло не так: кількість запитів падає нижче за прийнятні межі або, навпаки, зашкалює.

Це класичне рішення для моніторингу ІТ-інфраструктури, коли можна передавати інформацію про стан конкретного «заліза» і зберігати дані для аналітики. Також можна бачити всі активності у часу та розуміти, які ресурси залучені й коли, де їх не вистачає. Так можна підтримувати продукт та  планувати його масштабування.

8. Pentesting

Pentesting, або penetration testing, — це спосіб знайти баги та слабкі місця, за допомогою яких можна вкрасти дані. Під час такого тесту моделюється ситуація реального зламу. Існує класифікація такого тесту:

Для проведення пентестингу наймають окремих співробітників, компанію-підрядника або проводять Bug Bounty. Bug Bounty — це оголошення для охочих з різних куточків світу знайти баги за винагороду. Таке собі змагання етичних хакерів. Такі  програми в Україні проводили сервіс Grammarly та застосунок Мінцифри «Дія».

У Finmap ми час від часу застосовуємо превентивні заходи. Завжди користуємося найновішими версіями залежностей, останніми оновленнями будь-якого програмного забезпечення. До того ж використовуємо певні засоби статичного аналізу наших залежностей та коду, які можуть показати, якщо залежність має вразливість. Ті бувають критичні, некритичні, трапляються навіть на рівні ліцензій. Ми це беремо в роботу та виправляємо ще до релізу версії у продакшені.

Додавання нових фіч до продукту завжди відбувається за певним алгоритмом. Спочатку фічі проходять тестовий сервер, де їх мануально тестують. Далі ми підключаємо їх до деяких користувачів, які погодилися нам допомагати. Вони дають свій фідбек. Потім даємо користувачам, які активно цікавилися фічею, вони першими отримують нову функцію. Це не бетаверсія, а поступове підключення до всієї бази користувачів. Якщо все гаразд, передаємо нововведення на автотести, що відбуваються перед кожним новим білдом. Якщо функція критична, через великі обсяги роботи вона піде лише на автоматизований тест. Іноді випускаємо бетаверсії всього продукту, тоді певній кількості користувачів пропонуємо протестувати всі нововведення.

9. Шифрування даних

Це та ситуація, коли вся інформація шифрується на сервері у базі даних. У разі витоку дані залишаються у зловмисників у зашифрованому вигляді. Якщо використовувати незворотне шифрування (наприклад, SHA-256), то замість логіна, пароля або інших записів на сервері буде шифр. Навіть якщо його вкрасти, зловмисники не зможуть витягти з нього інформацію. У такому вигляді ми зберігаємо інформацію на бекапі. Навіть якщо зловмисний співробітник «розкотить» бекап, то він побачить, скажімо, пароль у зашифрованому вигляді.

У нашому випадку було дуже важливо не лише зашифрувати дані, а й зберегти швидкість завантаження сторінок. Якщо часто оброблювані дані зберігати на шифрованих дисках або використовувати складні способи шифрування, користувач буде довго чекати на відповідь від сервісу. Тому ми поділили всі дані на конфіденційні (їх ми шифруємо) та часто використовувані, які не несуть бізнес-інтересу (їх не шифруємо). Щоб знайти рішення, проводимо тестування навантаження: з'ясовуємо, які показники заходів безпеки на які метрики впливають.

Завдяки такому підходу досягається відчуття швидкої взаємодії. Будь-яка відповідь сервісу для користувача — це час оброблення даних на нашому боці і час затримки до безпосереднього місця перебування  користувача. 90% запитів обробляються у межах 285 мілісекунд. Пінг із Європи до США триває 100 мілісекунд. При цьому все передається у зашифрованих каналах.

Безумовно, самі користувачі теж повинні допомагати сервісам та бути обачними зі своїми даними. Але, як виявляється, інтернет у 2022 році може бути безпечним.