Як захистити фінансові дані компанії: інтерв'ю з експертом з кібербезпеки

Більшість кібератак на бізнес не виглядає як атаки. Вони тихі, непомітні і часто починаються задовго до того, як компанія щось виявляє. Ми поговорили з Євгенієм Богаченком — директором КП «Міський інформаційно-обчислювальний центр» та експертом з кібербезпеки і захисту критичної інфраструктури. 

Він пояснив, чому ізольованість бухгалтерського ПЗ не гарантує безпеки, як у вашій системі роками може жити код, про який ви навіть не підозрюєте, і що чекає на бізнес, який продовжує працювати в 1C/BAS. 

— Євгенію, існує міф, що якщо бухгалтерську систему ізолювати від інтернету та не оновлювати, то це гарантує її безпеку. Чи дійсно це так?

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

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

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

У кожному з цих випадків ізоляція існує лише на папері. І саме так найчастіше і відбувається зараження.

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

— Скажіть, як зрозуміти, що облікова система може бути під загрозою?

— Одна з найскладніших проблем — так звані «сплячі загрози». Наприклад, в 1C/BAS частину налаштувань і доопрацювань роблять зовнішні підрядники. І компанія часто не має повного розуміння, що саме додали всередину системи. Через особливості такої архітектури будь-який код, який запускається всередині програми, виглядає як «нормальна» дія. Це означає, що звичайний антивірус або базовий захист, який переважно орієнтується на відомі шкідливі файли, може не помітити такої активності — для нього всередині запущена «довірена» програма.

Сучаснішу відповідь на цей клас загроз дають локально встановлені EDR-системи (Endpoint Detection and Response). Вони стежать не за сигнатурами файлів, а за поведінкою:

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

Як же тоді зрозуміти, що щось не так? Єдиний надійний підхід — це не чекати збоїв, а постійно перевіряти систему на нетипову поведінку.

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

Підписуйтеся на наші соцмережі

2. Контролюйте доступи. Регулярно перевіряйте, хто має доступ до системи і хто фактично в неї заходить. Окремо звертайте увагу на підозрілі входи, наприклад, у неробочий час або з незнайомих пристроїв.

3. Проводьте технічний аудит. Час від часу залучайте зовнішніх фахівців із кібербезпеки для перевірки системи. Вони глибше проаналізують код і знайдуть приховані елементи або небезпечні доопрацювання — від випадкових помилок до навмисно доданих бекдорів. 

Безпека — це не разова перевірка, а постійний контроль того, як система поводиться в реальній роботі.

— Чи буває так, що в обліковій системі щось не так, але це ніяк не видно в щоденній роботі?

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

Зловмисники налаштовують такі «бомби» на конкретні події:

Багато хто впевнений, що відсутність інтернету на сервері — це 100% захист від команд хакерів, але це помилка. Якщо система лише вважається ізольованою, але фактично залишається підключеною до локальної мережі або використовує внутрішні DNS-сервери, зловмисники можуть застосовувати службові мережеві запити як прихований канал обміну командами або витоку даних. Саме тому важливо перевіряти не тільки наявність інтернету, а й усі реальні мережеві маршрути системи.

— Що відбувається, коли така «логічна бомба» врешті спрацьовує?

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

Головна помилка, яка робить ці наслідки катастрофічними, — неправильні бекапи. Більшість компаній зберігає резервні копії на тому самому сервері, що й основну програму. Коли стається атака, зловмисники одним ударом знищують і робочу базу, і всі ваші копії. Відновлювати бізнес просто немає з чого.

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

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

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

— Очікується, що до 2030 року український бізнес має повністю відмовитися від 1С/BAS. Чим ризикують компанії, які відкладають перехід на останній момент?

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

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

Але є ще один ризик, про який рідко думають заздалегідь. Повна заборона 1C/BAS не буде поступовою: сьогодні система ще дозволена, а завтра — вже ні. І, як показує практика, одразу після цього починаються державні перевірки. Для бізнесу це вже не просто питання IT-безпеки, а ризик зупинки всіх процесів та величезних штрафів.

— На вашу професійну думку, що надійніше: тримати дані на власному сервері в офісі чи довіритися «хмарі»?

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

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

Сервер в офісі — тут усе тримається на одному кабелі. Ви повністю залежите від стабільності електрики, якості одного інтернет-провайдера та ресурсів компанії.

— Виходить, хмара — це ідеальне рішення без ризиків?

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

Водночас хмара не знімає відповідальності з самої компанії. Якщо користувачі працюють без двофакторної автентифікації, мають надмірні права або передають паролі підрядникам, навіть найкраща інфраструктура не врятує від компрометації облікового запису. Безпека хмари — це спільна відповідальність провайдера і клієнта.

— Які 3 базові правила цифрової гігієни ви б порадили бухгалтеру чи підприємцю, щоб максимально захистити свої дані?

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

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

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

Безпека бухгалтерських даних — це питання не лише IT, а й управлінської відповідальності. Чим раніше бізнес це усвідомить і почне діяти, тим менше коштуватиме захист і тим менше шансів одного дня опинитися перед фактом втрати даних без можливості їх відновити.