IT-безпека: з чого складається і чим відрізняється від кібербезпеки

IT-безпека, кібербезпека, інформаційна безпека — три терміни, які вживають як синоніми. Насправді вони позначають різні (хоч і вкладені) речі, а плутанина заважає зрозуміти, хто за що відповідає й за що ви платите. Розберемо.

Три поняття: що ширше

Найпростіше уявити їх як вкладені кола:

Інформаційна безпека — уся інформація: цифрова, паперова, усна └── Кібербезпека — усе цифрове: мережі, застосунки, дані ⠀⠀⠀└── IT-безпека — захист самої інфраструктури й систем

• Інформаційна безпека — найширше поняття. Охоплює й папір, і розмови, і фізичні носії, і людей.
• Кібербезпека — захист цифрового простору від атак.
• IT-безпека — практичний, інженерний зріз: сервери, мережі, робочі станції, застосунки.

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

IT та безпека: дві логіки, два бюджети

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

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

Із чого складається цей напрям

Практичні ділянки, які закриває цей напрям:

• мережі — фаєрволи, сегментація, VPN (див. захист мережі);
• кінцеві пристрої — антивірус і EDR, оновлення, шифрування дисків;
• сервери й інфраструктура — конфігурації, доступи, оновлення;
• застосунки — WAF, безпечна розробка, перевірка коду;
• керування доступом — облікові записи, права, багатофакторна автентифікація;
• резервне копіювання й відновлення;
• моніторинг і журналювання (див. SIEM);
• керування вразливостями — оновлення й патчі.

Периметр помер: чому цей напрям став іншим

Раніше все було просто: усередині офісу — довіряємо, ззовні — ні. Фаєрвол на межі мережі був воротами замку.

Сьогодні цієї межі просто немає:

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

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

Фізична IT-безпека

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

Сюди належать:

• контроль доступу до серверної й замки на шафах;
• відеоспостереження й журнал відвідувань;
• захист від збоїв живлення (джерела безперебійного живлення, генератор);
• контроль температури й вологості;
• порядок винесення обладнання за межі офісу;
• безпечне списання носіїв — гарантоване стирання або механічне знищення дисків.

Останній пункт недооцінюють найдужче. Списаний сервер, проданий «на запчастини» разом із дисками, — це готовий витік, який ніхто навіть не помітить. Докладніше — у матеріалі про апаратні засоби захисту.

Як це шукають: два найчастіші запити про стандарти

Два найчастіші запити пошуку — і за ними стоять різні речі:

Найпоширеніше запитання звучить так: «Ми впровадили технічний захист — це і є ISO 27001?»

Ні. Різниця принципова:

У чинній редакції ISO/IEC 27001:2022 заходи Додатка А поділено на чотири групи: організаційні, людські, фізичні й технологічні. Технічна частина — лише одна з них. Тобто стандарт не скасовує інженерну роботу, а ставить її в рамку: спершу оцінювання ризиків, потім вибір заходів, далі контроль і поліпшення. Уся серія стандартів описує це системно, а СУІБ — надбудова над технікою.

IT-безпека в охороні здоров'я

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

Наслідки:

• сегментація критична: обладнання ізолюють від офісної мережі й інтернету;
• доступ жорстко обмежують — інженер виробника заходить лише через контрольований канал;
• дані пацієнтів захищають окремо: це найчутливіша категорія відомостей;
• безперервність важливіша за конфіденційність: зупинена реанімація — це не про штрафи.

Для галузі є й окремий стандарт — ISO 27799: він пояснює, як застосовувати заходи 27002 у клініках. Галузеву специфіку інших сфер розібрано в матеріалі кібербезпека за галузями.

Хмара: хто за що відповідає

Перехід у хмару часто розуміють неправильно: «тепер за безпеку відповідає провайдер». Насправді відповідальність поділена, і найгучніші витоки останніх років — це не злам хмари, а помилка налаштування з боку клієнта.

• Провайдер відповідає за майданчики, обладнання, живлення, мережу самої платформи, оновлення гіпервізора.
• Ви відповідаєте за налаштування сервісів, права доступу, паролі й ключі, шифрування власних даних, резервні копії й за те, кого ви туди пустили.

Класична катастрофа виглядає так: сховище створили «на п'ять хвилин, для тесту», відкрили доступ усім, залили туди справжню базу — і забули. Через рік її знаходить пошуковий робот.

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

Оновлення: чому їх бояться і як робити

«Оновимо — щось зламається» — головний аргумент проти патчів. Він має підстави, тому оновлення потребує процесу, а не подвигу:

1. Розділіть системи за критичністю. Те, що дивиться назовні, оновлюють першим і швидко; внутрішні системи — за графіком.
2. Заведіть вікно обслуговування. Фіксований час раз на місяць, про який знають усі, дешевший за аварійні нічні авантюри.
3. Тестуйте на копії. Для критичної системи потрібен стенд — хоча б тимчасовий.
4. Майте шлях назад. Знімок системи перед оновленням перетворює катастрофу на незручність.
5. Фіксуйте винятки. Систему, яку оновити неможливо, ізолюють — і це рішення записують, а не забувають.

Найгірший варіант — не оновлювати нічого «щоб не зламати». Саме такі сервери й стають входом.

Типові помилки конфігурацій

Ці знахідки є чи не всюди:

• паролі за замовчуванням на мережевому обладнанні, камерах, принтерах;
• віддалений робочий стіл, відкритий назовні «на час карантину» — і назавжди;
• застарілі протоколи й старі версії служб, залишені «для сумісності»;
• база даних без пароля, доступна ззовні, бо «вона тестова»;
• адміністраторські права мають усі — простіше, ніж розбиратися з правами;
• вимкнене журналювання — «бо займає місце».

Жодна з цих помилок не потребує геніального зловмисника. Достатньо автоматичного сканера, який щодня обходить інтернет.

Що до цього напряму не належить

Межі так само важливі, як зміст. Поза інженерним зрізом залишаються:

• паперові документи, розмови, усні домовленості;
• навчання персоналу й культура (це вже рівень ІБ);
• договірні зобов'язання, NDA, юридичні наслідки інцидентів;
• рішення про пріоритети й бюджет — його ухвалює керівництво.

Тому компанія, яка «закрила техніку», ще не захищена: людина, яка відкриває вкладення, стоїть поза будь-яким фаєрволом.

Інвентаризація: з чого все починається

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

• домен і DHCP — усе, що отримує адресу у вашій мережі;
• рахунки хмарних провайдерів — вони чесно показують, за що ви платите;
• банківські виписки — там знайдуться підписки, про які технічний відділ і не чув;
• опитування відділів — маркетинг, продажі й розробники майже завжди мають «свої» сервіси;
• записи про підрядників — хто, куди й навіщо має доступ.

Для кожного запису корисно зафіксувати чотири речі: власника (людину, а не відділ), критичність для бізнесу, хто має доступ і чи дивиться система назовні. Реєстр, який оновлюють раз на квартал, дає більше, ніж дорогий сканер, що вивчає невідомо чию інфраструктуру. Без такого переліку будь-яка розмова про пріоритети перетворюється на здогади.

Сегментація: як розділити мережу

Пласка мережа означає, що одна заражена бухгалтерська машина відкриває шлях до серверів. Розділення на зони — найдешевший спосіб зробити злам локальним.

Мінімальний поділ:

1. Робочі станції — окрема зона; звідси немає прямого доступу до баз.
2. Сервери — доступ лише до потрібних служб і лише з визначених адрес.
3. Гостьовий Wi-Fi — повністю ізольований, з виходом самим лише назовні.
4. Обладнання — камери, принтери, термінали, виробничі контролери: окремо, без інтернету.
5. Керування — інтерфейси адміністрування доступні з окремої зони, а не з будь-якого ноутбука.

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

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

Підрядники: доступ, який забувають закрити

Зовнішні інженери — типове слабке місце. Робочий підхід:

• окремі облікові записи для кожного підрядника, іменні, ніяких «спільних»;
• доступ на час робіт, а не назавжди: увімкнули — вимкнули;
• фіксований канал — через контрольований шлюз, а не «прямим прокидом порту»;
• журналювання дій — щоб було зрозуміло, хто саме змінив конфігурацію;
• пункт про повернення доступів у договорі, а не в усних домовленостях.

Одне просте питання перевіряє зрілість компанії: скільки підрядників мають доступ до ваших систем просто зараз? Якщо відповідь звучить як «треба уточнити» — це вже відповідь.

Журнали: мінімальний набір

Збирати все — дорого й безглуздо. Мінімум, що справді знадобиться під час розслідування:

• входи — вдалі й невдалі, зокрема адміністраторські;
• зміни прав — хто, кому й коли надав повноваження;
• запуск процесів на серверах і робочих станціях;
• мережеві з'єднання назовні — куди й скільки даних пішло;
• дії підрядників — окремо, з іменами.

Два практичні правила: зберігати щонайменше кілька місяців (інциденти помічають пізно) і тримати копію журналів окремо від системи, яку вони описують. Інакше зловмисник просто зітре свої сліди разом із доказами.

Пошта: головні ворота

Переважна більшість атак починається з листа. Тому поштовий сервіс — окрема ділянка робіт:

• SPF, DKIM і DMARC — три записи, які унеможливлюють підробку листів від вашого імені. Без DMARC ваш домен може використати будь-хто;
• банер «зовнішній відправник» — проста позначка, що рятує від «листа від директора»;
• фільтрація вкладень — виконувані файли й архіви з паролем відсіюють ще до скриньки;
• блокування макросів у документах із мережі — класичний шлях зараження;
• перевірка посилань у момент кліку, а не лише під час доставки.

Ефект від цих п'яти пунктів більший, аніж від будь-якої дорогої системи, придбаної після інциденту.

Привілейовані облікові записи

Компрометація адміністратора перетворює локальний інцидент на катастрофу. Мінімальна дисципліна:

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

Питання для самоперевірки: скільки людей у вашій компанії можуть просто зараз вимкнути журналювання? Якщо більше двох — це вже проблема.

Ролі IT-безпеки: хто що робить

Усередині напряму обов'язки різні, і плутати їх — дорого:

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

Мінімум для малої компанії: технічні роботи — на адміністраторові, а незалежну перевірку раз на рік замовляють ззовні (аудит або пентест).

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