Мережа й сховище — два магістральні шляхи, якими рухається та зберігається все цінне у компанії. Саме тут зловмисник шукає вхід, і саме тут найчастіше знаходить. Розберемо типові слабкі місця обох напрямів — і те, чим їх закривають.
Про різні назви одного й того самого
Запит формулюють по-різному: інформаційна безпека мереж, інформаційна безпека мережі, мережева інформаційна безпека, інформаційна безпека комп'ютерних мереж. Ідеться про одне: захист інфраструктури, якою ходить трафік, і всього, що до неї підключено. Загальні принципи розібрано окремо (люди, процеси, технології) — тут ідемо вглиб.
Слабкі місця мережі
- пласка мережа без сегментації — потрапивши на один комп'ютер, зловмисник бачить усе інше;
- відкриті назовні сервіси, про які давно забули: тестовий стенд, стара панель адміністратора, камера відеоспостереження;
- однакові локальні паролі на всіх робочих станціях — зламавши одну, нападник відкриває решту;
- незахищений віддалений доступ — адміністративні інтерфейси без VPN і двофакторної автентифікації;
- застаріле обладнання з відомими вразливостями, яке «працює й не чіпаємо»;
- спільний Wi-Fi — гостьовий, не відділений від робочого;
- відсутність моніторингу — атаку помічають тоді, коли все вже впало.
Інформаційна безпека в мережі починається з простого питання: хто й куди може дістатися? Якщо бухгалтерський комп'ютер технічно бачить сервер розробки, а той — камери, то схему спроєктовано на користь нападника.
Класична схема «твердий периметр, м'яка серединка» перестала працювати: щойно фішинг спрацював, зловмисник опиняється всередині — і далі жодних перешкод. Сучасна відповідь — сегментація до рівня окремих сервісів і принцип, за яким кожне з'єднання перевіряють незалежно від того, звідки воно прийшло. Докладний розбір — у матеріалі про захист корпоративної мережі.
Інформаційна безпека баз даних: де найчастіше протікає
БД — найласіший шматок: усе цінне зібрано разом, ще й у зручному для викрадача вигляді.
Типові слабкі місця:
- облікові записи за замовчуванням і слабкі паролі адміністратора;
- БД, доступна з інтернету — того, чого майже ніколи не має бути;
- надмірні права — застосунок працює під адміністратором там, де вистачило б читання двох таблиць;
- SQL-ін'єкції через вебзастосунок: сама БД захищена, а «двері» до неї відчиняє вразливий сайт (див. пентест сайту);
- чутливі поля відкритим текстом — паролі, документи, платіжні реквізити;
- незахищені резервні копії — сам дамп лежить без шифрування й контролю доступу;
- відсутність журналювання — незрозуміло, хто й що робив із записами;
- тестові середовища з бойовими вивантаженнями — зазвичай найгірше захищені.
Як це виглядає покроково
Шлях нападника майже завжди однаковий, і жоден крок сам собою не є катастрофою:
- Співробітник відкриває вкладення — нападник отримує звичайну робочу станцію без адміністративних прав.
- Далі йде тиха розвідка: які сервери відповідають, де відкриті порти, які облікові записи існують.
- Знаходиться сервіс зі старим паролем або застосунок, що ходить до сховища під адміністратором.
- Права підвищуються, нападник рухається горизонтально — саме тут пласка інфраструктура дарує йому все й одразу.
- Фінал: вивантаження таблиць невеликими порціями, щоб не привертати уваги.
Ключове спостереження: жоден етап, крім першого й останнього, не виглядає як «атака». Усе це — звичайні з'єднання, звичайні входи, звичайні запити, просто зроблені чужими руками. Саме тому моніторинг усередині периметра важить не менше за фільтр на вході, а сегментація коштує дешевше за розслідування.
Три помилкові переконання, які коштують найдорожче
«БД усередині периметра, отже, у безпеці». Атака рідко йде до БД напряму. Вона йде через людину (фішинг) або через вразливий застосунок, який має до бази цілком легальний доступ. Внутрішнє розташування додає один рубіж, але не скасовує решти.
«Ми все зашифрували, витік неможливий». Шифрування сховища рятує від крадіжки диска чи дампа — і не рятує від SQL-ін'єкції. Застосунок звертається до БД з легітимними правами, отримує розшифрований результат і слухняно віддає його нападникові. Криптографія тут просто не спрацьовує: запит виглядає законним.
«Тестовий стенд — це не бойова система». Якщо туди залили свіже вивантаження продакшену, це та сама бойова система — тільки без моніторингу, без суворих паролів і з доступом для десятка підрядників.
Спільна риса всіх трьох переконань одна: віра в єдиний рубіж, який усе витримає. На практиці цей рубіж завжди знаходять — і він завжди падає першим.
Засоби інформаційної безпеки, які закривають ці місця
| Слабке місце | Чим закривають |
|---|---|
| Плаский обхід усередині | Сегментація, міжмережевий екран, окремі зони для серверів |
| Атака через сайт | WAF, безпечний код, параметризовані запити |
| Надмірні права | Мінімальні привілеї: окремий обліковий запис застосунку лише на потрібні таблиці |
| Крадіжка носія чи дампа | Шифрування сховища та резервних копій |
| Непомітне викачування | Моніторинг подій, сповіщення про аномальні обсяги вибірок |
| Витік через тестове середовище | Знеособлення: реальні прізвища й номери замінюють на згенеровані |
| Невідомо, хто що робив | Журналювання звернень і регулярний перегляд журналів |
Окремо про журнали. Вони мають сенс лише тоді, коли їх хтось читає — або принаймні коли налаштовано автоматичне сповіщення. Журнал, у який заходять після інциденту, працює як чорна скринька літака: показує, чому впали, але падіння вже сталося.
Мінімальний перелік того, що варто фіксувати: успішні й невдалі входи, зміни прав доступу, зміни структури таблиць, масові вибірки та вивантаження, звернення з нетипових адрес та у неробочий час. Останні два пункти дають найбільше корисних спрацювань за найменших зусиль.
Перевірка за п'ятнадцять хвилин
Три дії, які варто зробити просто зараз:
- Порт назовні. Спитайте адміністратора, чи відповідає сервер бази на з'єднання з інтернету. Правильна відповідь — «ні, тільки із застосункового сегмента».
- Права застосунку. Подивіться, під яким обліковим записом сайт ходить до сховища. Якщо під адміністратором — це готовий сценарій катастрофи: будь-яка діра в коді одразу дає нападникові повний доступ, включно з видаленням журналів.
- Резервна копія. Перевірте, чи зашифрований останній дамп і хто має доступ до каталогу з копіями.
- Журнал. З'ясуйте, чи хтось узагалі відкривав його за останній місяць — і чи прийде сповіщення, якщо вночі хтось вивантажить пів мільйона рядків.
Жодна з перевірок не потребує бюджету, а закривають вони найпоширеніші сценарії. Якщо на котромусь із питань адміністратор бере паузу «треба уточнити» — ви вже знаєте, з чого починати.
Головний принцип: захист у глибину
Інфраструктура й сховище — не окремі фортеці, а ланки одного ланцюга. Шлях нападника майже завжди однаковий: людина → застосунок → мережа → сховище. Тому й захист має бути наскрізним: від периметра до окремого поля у таблиці. Керовану систему з цього робить СУІБ, а перелік конкретних заходів — Додаток А ISO 27001.