Доки не впріти, доти не вміти

Україну знову атакують, і ми несемо втрати. Якщо зміна заглавної сторінки вебсайту виглядає як забава, то переривання сервісів платежів – це вже не забавка, а реальні проблеми як для бізнесу, так й для українців.

16 лютого я не зміг розплатитись картою в жодному з магазинів і кафе, де я був. Якщо для мене це просто незручність, то для бізнесу це реальні втрати, оскільки можливо не всі покупці зроблять свої покупки за готівку. Хто стоїть за цими атаками здогадатись не важко, але є відповідні органи, які мають встановити виконавця і замовника цієї атаки. Я хотів звернути увагу на інше. Business continuity planning. Disaster recovery procedures. Можливо у банків і організацій, які постраждали, наявні «Плани безперервної роботи бізнесу» (BCP), процедури відновлення роботи бізнесу у надзвичайних ситуаціях (DRP), але переривання надання сервісів є, отже є над чим працювати і надалі. Знову ж таки, ми розуміємо, що кібератака була масштабна, добре спланована і якщо за атакувальниками стоять державні ресурси, то протистояти такій атаці дуже складно, але й не можна сказати, що неможливо. Нещодавно Microsoft звітувала, що відбила найбільшу DDoS атаку в своїй історії, і повідомлень щодо суттєвих збоїв у роботі сервісів Microsoft не спостерігалось.

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

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

Який висновок важливо зробити керівникам бізнесу з поточної ситуації – кожна достатньо велика компанія чи організація, або ключова компанія\ організація для певної галузі економіки, може стати об’єктом атаки, як зі сторони спонсорованих державами-терористами хакерів в рамках гібридної війни, так і комерційно вмотивованими хакерами, які роблять свою роботу для заробітку. Так, розбудова резервної ІТ-архітектури та розгортання резервних ІТ-систем, вибудовування та реорганізація бізнес-процесів, аби вони могли функціонувати у випадку надзвичайної ситуації – це складна робота, і вимагає додаткових ресурсів, як людських, так і фінансових. Але вкотре постає питання – чи не перевищать ці витрати потенційних збитків, які організація може понести у разі настання надзвичайної події. Певен «Ощадбанк», «ПриватБанк», команда «Дії» можуть оцінити наразі це в певних цифрах.

Якщо ж ви у вашій організації ще не займались питаннями відмовостійкості ваших ІТ-систем та бізнесу в цілому, і плануєте до цього підступитись, варто звернути увагу на наступне:

• Існує міжнародний стандарт для побудови відмовостійкої ІТ-інфраструктури ISO 22301:2019 Security and resilience – Business continuity management systems. В ньому достатньо просто описана послідовність дій, які варто виконати, аби вибудовувати ефективну систему безперервної роботи організації (ціна 118 CHF).
• Національний Банк України розробив «Положення про забезпечення безперервного функціонування інформаційних систем НБУ та банків України» 2004 року (Постанова №265 від 17.06.2004). Це загальнодоступний документ, в ньому окрім специфічних положень щодо функціонування банківської системи у випадку надзвичайної ситуації є також загальні вимоги щодо побудови безперервної роботи банків, організації резервного центру, описані методи забезпечення безперебійної діяльності. Ці рекомендації можуть використовувати й звичайні організації, так як це загальні практики щодо організації безперервної роботи компаній.

І ще пару порад щодо Business continuity planning.

• Найпростіше рішення, яке ІТ може запропонувати СЕО щодо побудови резервного ЦОД – продублювати повністю ІТ-інфраструктуру. Це просто, але дуже дорого. В реальності, для виконання ключових бізнес-процесів кожного бізнесу не потрібні абсолютно всі ІТ-системи. Наприклад, без бухгалтерської системи 1С бізнес може продавати товари та послуги, якщо основна фронт-офіс система працює, а бухгалтерські проводки можна буде провести згодом. Так, в не дуже ефективній ІТ-інфраструктурі всі системи будуть хаотично пов’язані між собою, документація по системах може бути відсутня, і головна мантра ІТшників у цій ситуації – «працює, не чіпай». Звісно за такої ситуації ІТ-спеціалісти будуть бачити тільки одне рішення – відтворити такий же самий хаос і безлад у якості резервної ІТ-архітектури. Ефективний і менш затратний підхід у цій ситуації – BIA (Business Impact Analysis), аналіз впливу ІТ-систем на бізнес з метою визначення які системи критичні для виконання основної бізнес-функції компанії, а без яких компанія може працювати певний час. Резервування ключових систем організації дозволить ефективно витратити кошти й заодно може допомогти оптимізувати робочу ІТ-інфраструктуру.
• Щодо реалізації резервного ЦОД, ще одне просте і очевидне рішення, яке може запропонувати ІТ керівництву організації – побудова власного резервного ЦОД (зазвичай разом із пропозицією продублювати всю ІТ-інфраструктуру). Це також просте рішення, але також дороге. На сьогодні ринок ЦОД в Україні та світі доволі розвинений, і комерційні ЦОД пропонують окремі рішення саме для побудови резервних ІТ-систем та ІТ-архітектур. Оплата систем, які перебувають в комерційному ЦОД у режимі standby буде відрізнятись від використання аналогічного ресурсу в робочому режимі, відповідно побудова резервної ІТ-архітектури з використанням ресурсів комерційних ЦОД може бути економічно вигіднішою, аніж побудова власного ЦОД, закупівля власного обладнання і витрати на підтримку всього цього хазяйства. Звісно, все залежить від конкретної ІТ-архітектури конкретної організації, але варто порахувати і такий варіант. Якщо він навіть буде дорожчий, то для організації витрати на використання комерційного ЦОД, це операційні витрати, а побудова власного ЦОД і закупівля обладнання – це капітальні витрати, і для певних організацій це може бути додатковим аргументом у виборі варіанта розбудови резервного центру для безперебійної роботи бізнесу.

Побудова ефективної ІТ інфраструктури – складне завдання. Вибудова відмовостійкої ІТ-інфраструктури, завдання ще складніше. Але можливе. Удачі нам всім і стійкості в цей нелегкий час. Keep calm and build BCP.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365