Одна справа — знати визначення, інша — розуміти, як рубежі виглядають там, де насправді живуть ваші дані: на периметрі, на боці хмарного провайдера та всередині СУБД. Розберемо механізми для кожного середовища, типові дірки й мінімум, нижче якого опускатися годі. Базові поняття й перелік загроз — Захист інформації: що це.
Три середовища — три різні логіки
Дані живуть щонайменше на трьох майданчиках, і кожен вимагає свого підходу:
| Середовище | Головний рубіж | Типова помилка | Що перевірити першим |
|---|---|---|---|
| Периметр і вебсервіси | фільтрація трафіку, TLS, WAF | «поставили фаєрвол — закрито» | перелік сервісів, відкритих назовні |
| Хмара | контроль доступу та налаштувань | «за все відповідає провайдер» | публічні сховища й адміністратори без MFA |
| Сховище (СУБД) | права, шифрування, журнал | «до бази дістануться лише через сайт» | хто має право на масове вивантаження |
Далі — кожен рубіж окремо.
Екран захисту інформації: що це таке
Так називають міжмережевий екран, він же фаєрвол. Робота проста: пропускати дозволене, блокувати решту. Правила описують, звідки, куди й на який порт можна ходити.
Три покоління, які досі співіснують:
- пакетний фільтр — дивиться на адреси та порти, нічого не знає про зміст;
- stateful-фільтр — пам'ятає стан з'єднань, тому відсікає пакети, яких ніхто не очікував;
- NGFW — розпізнає застосунки й користувачів, вміє інспектувати зашифрований трафік.
Не менш важливо, чого фаєрвол не робить:
- безсилий, коли зловмисник заходить із чинним паролем через легальний вхід;
- сліпий усередині дозволеного з'єднання, поки не ввімкнено інспекцію;
- нічим не компенсує застаріле програмне забезпечення на сервері, який сам же й прикриває.
Правила старіють. Найпоширеніша хвороба периметра — накопичення дозволів: «тимчасове» правило для підрядника живе п'ятий рік, порт для давно вимкненого сервісу відкритий, а автор налаштувань звільнився. Тому ревізія правил раз на пів року дає більше, ніж чергове оновлення обладнання. Мінімальна гігієна: принцип «за замовчуванням заборонено», іменований власник кожного правила, дата й підстава його появи.
Детальний розбір типів і налаштувань — Firewall: що це.
Мережевий захист інформації: рубежі, крім фаєрвола
Захист інформації в мережі інтернет починається не з покупки, а з переліку: спершу треба знати, що саме дивиться назовні. Далі — шари:
- шифрування каналів — HTTPS/TLS назовні, VPN для віддалених працівників і філій (див. шифрування);
- WAF — окремий рубіж перед вебзастосунком: він розуміє логіку HTTP і відсікає ін'єкції та підбір;
- анти-DDoS — проти атак на доступність;
- сегментація — щоб пробита одна машина не відкривала шлях до бухгалтерії та резервних копій;
- моніторинг подій — SIEM або хоча б централізовані журнали: атаку треба помітити, поки вона триває.
Проста перевірка зрілості периметра: чи знаєте ви, скільки сервісів компанії зараз дивляться назовні? Якщо відповідь «десь близько десяти» — це вже привід для інвентаризації.
Захист інформації в інтернеті: типові дірки
Периметр рідко ламають красиво. Частіше знаходять забуте:
- адміністративні панелі й RDP, відкриті всьому світу замість доступу через VPN;
- тестові стенди зі свіжою копією бойових записів і паролем
admin/admin; - забуті субдомени — старий лендинг на застарілій CMS живе роками;
- непропатчені сервіси: вразливість опубліковано, оновлення вийшло, а сервер стоїть як стояв;
- сертифікати й ключі, закомічені до репозиторію — випадковий коміт відкриває двері назовні.
Спільна риса цих дірок — ніхто не знає, що вони існують. Тому інвентаризація зовнішніх сервісів корисніша за ще один придбаний засіб.
П'ять питань, які показують стан периметра
- Скільки сервісів компанії відповідають на запити ззовні — і чи є цей перелік на папері?
- Коли востаннє переглядали правила фільтрації?
- Чи відкритий адміністративний доступ до серверів без VPN?
- Скільки часу минає від виходу оновлення до його встановлення?
- Хто побачить сповіщення, якщо о третій ночі хтось увійде до адмінпанелі?
Три відповіді «не знаю» означають: рубежі є, керування ними — немає.
Захист інформації у хмарі
Головне правило: хмарний провайдер знімає з вас залізо, але не відповідальність. Він відповідає за інфраструктуру, ви — за налаштування, доступи й самі дані. Ця межа називається моделлю спільної відповідальності, і саме її найчастіше не дочитують.
Мінімум, який закриває більшість інцидентів:
- багатофакторна автентифікація для всіх адміністраторів і сервісних акаунтів;
- перевірка публічного доступу до сховищ — відкритий назовні бакет залишається лідером серед причин витоків;
- мінімальні права для користувачів, застосунків і скриптів;
- шифрування та контроль ключів: ключ, який лежить поруч із зашифрованим томом, нічого не боронить;
- окремі резервні копії — реплікація між зонами доступності це не бекап: помилково видалені файли зникають скрізь одночасно;
- журналювання дій акаунту та сповіщення про зміну критичних налаштувань.
Модель відповідальності докладніше — Інформаційна безпека у хмарі. Міжнародні орієнтири: ISO/IEC 27017 — хмарні сервіси, ISO/IEC 27018 — персональні дані.
Захист інформації в базі даних
СУБД — концентрація найціннішого. Один вдалий запит вартий сотні зламаних робочих станцій, тому рубежі тут будують щільніше:
- ізоляція — сервер СУБД не має бути доступним з інтернету напряму, ніколи;
- мінімальні права: застосунку рідко потрібні права власника схеми, а аналітику вистачає читання;
- шифрування чутливих полів і резервних копій;
- закриті SQL-ін'єкції — параметризовані запити на боці застосунку, WAF як другий рубіж;
- журналювання звернень: хто, коли й скільки записів вивантажив;
- знеособлення — тестове середовище має обходитися знеособленими записами;
- оновлення СУБД і своєчасне вимкнення застарілих механізмів автентифікації.
Окремий сигнал, який часто ігнорують: масове вивантаження. Легальний користувач із легальним паролем викачує весь довідник клієнтів — фаєрвол мовчить, антивірус мовчить, а база вже втекла. Помітити таке здатне лише журналювання з порогом на обсяг.
Слабкі місця мереж і сховищ докладніше — Інформаційна безпека мереж і баз даних.
Резервні копії: правило 3-2-1
Копії — останній рубіж, коли решта не спрацювала. Класичне правило: три копії, на двох різних носіях чи платформах, одна — поза основним середовищем. Для хмарного середовища це означає, що копія має лежати поза тим самим акаунтом: скомпрометований адміністратор видаляє все, до чого дотягнеться його роль.
Копія без перевіреного відновлення — припущення, а не копія. Перевірку варто проводити за розкладом і фіксувати результат: скільки часу зайняло підняття, чи всі дані на місці.
Що шукати серед журналів
Журнали збирають майже всі, читає їх майже ніхто. Чотири події, які варто винести до сповіщень:
- поява нового облікового запису з адміністративними правами;
- вхід із нетипової країни або о нетиповій годині;
- масове вивантаження записів зі сховища;
- вимкнення журналювання чи антивірусу — улюблений крок нападника перед основною дією.
Захист інформації в Україні: що вимагає закон
Технічні рубежі — це вибір компанії. Але для окремих категорій організацій діють ще й нормативні вимоги: державні ресурси, відомості з обмеженим доступом та об'єкти критичної інфраструктури.
Тут важлива зміна, повз яку легко пройти. Раніше такі системи будували КСЗІ й проходили атестацію. Після ухвалення Закону № 4336-IX від 27.03.2025 і постанови Кабінету Міністрів № 712 від 18.06.2025 діє ризик-орієнтована модель: базовий і цільовий профілі безпеки, оцінювання, авторизація з безпеки. Раніше створені комплексні системи з підтвердженою відповідністю працюють далі й повторної авторизації не потребують.
Кого це стосується й що робити власнику — про АС та ІКС; інженерну частину заходів забезпечує технічний захист. Загальна картина національної системи — Державна інформаційна безпека.
Компанії поза цими категоріями нормативної процедури не проходять, але персональні дані клієнтів і працівників регулює окремий закон — незалежно від галузі та обороту. Володілець зобов'язаний мати правову підставу обробки, обмежити коло допущених осіб і забезпечити збереження записів. Формально це не «технічна» вимога, проте закривають її саме технічні рубежі: права, шифрування, журнал.
Шифрування: чого воно не закриває
Шифрування диска рятує від крадіжки ноутбука, але жодним чином не заважає легальному користувачеві скопіювати файл. TLS прикриває канал, проте не перевіряє, кому саме ви надсилаєте лист. Шифрування на боці провайдера безпорадне, якщо ключами розпоряджається сам провайдер, а ваш адміністратор увійшов під вкраденим паролем.
Висновок простий: шифрування закриває канал і носій. Усе інше закривають права доступу та журнали.
Що спитати у хостера чи провайдера
- де зберігаються резервні копії й чи лежать вони поза вашим акаунтом;
- хто з боку провайдера має технічний доступ до ваших томів;
- як швидко надають журнали під час розслідування;
- який строк повідомлення про інцидент записано в договорі;
- що саме входить до їхньої зони відповідальності — письмово, а не «за замовчуванням».
Практичний мінімум для будь-якої компанії
- Перелічити зовнішні сервіси й закрити те, чого там бути не повинно.
- Фаєрвол із правилом «за замовчуванням заборонено».
- HTTPS скрізь, віддалений доступ — лише через VPN.
- Багатофакторна автентифікація на пошті, хмарних сервісах, VPN та адмінпанелях.
- Мінімальні права: людям, застосункам, підрядникам.
- Резервні копії, одна з яких — поза мережею, з перевіреним відновленням.
- Оновлення операційних систем, СУБД і бібліотек за розкладом.
- Централізовані журнали й хоча б базові сповіщення.
- Навчання персоналу: пароль, відданий фішинговому сайту, обходить усі рубежі одразу.
- Записаний порядок дій на випадок інциденту: кому телефонувати, хто відключає уражену машину, хто спілкується з клієнтами.
Периметра в старому сенсі більше немає
Класична картина «всередині офісу безпечно, зовні небезпечно» померла разом із ноутбуками в кав'ярнях і SaaS-сервісами. Робоче місце сьогодні — це браузер, а записи ходять між пристроєм, хмарним сервісом і підрядником, жодного разу не заходячи до вашого офісу.
Практичний висновок: рубежі переносять ближче до самих записів. Головними стають ідентичність (хто саме увійшов), права (що йому дозволено) та журнал (що він зробив). Фільтр трафіку лишається потрібним, але вже не єдиним.
Звідси й порядок пріоритетів для невеликої компанії: спершу другий фактор і ревізія прав, потім резервні копії з перевіреним відновленням, і лише потім — розмови про дорогі засоби моніторингу.
Три помилки, які зводять нанівець решту
- Купити засіб і не налаштувати. Фаєрвол із правилом «дозволити все» — це кабель, а не рубіж.
- Прикрити периметр і забути про власні хмарні сервіси. Дані давно розповзлися по пошті, теках і CRM за межами офісу.
- Довіритися провайдерові. Резервні копії, доступи та налаштування — ваша зона відповідальності, хай навіть сервер стоїть на чужому майданчику.
- Вважати, що інцидент помітять самі засоби. Засіб піднімає тривогу — реагує людина. Якщо о третій ночі сповіщення нікуди не йде, його однаково що немає.