Кіберстійкість сервісу: як підготуватися до атак, збоїв і проблем у постачальників

Кіберстійкість — це не ще один інструмент безпеки

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

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

Інфоприводом для теми стала заява Cloudflare про приєднання до UK Cyber Resilience Pledge. У матеріалі згадуються управління, відповідальність керівництва, ризики постачальників, DDoS і атаки, посилені автоматизацією. Але для команди, яка підтримує вебсервіс, головне не назва ініціативи. Головне — перетворити стійкість на щоденну операційну практику.

Сценарій: сервіс працює, але команда вже бачить слабкі місця

Уявімо невелику продуктову команду. Є сайт, API, база даних, CDN, DNS, сервіс розсилок, платіжний провайдер і кілька адміністративних облікових записів. Минулого тижня сталася тривожна подія: частина користувачів не могла зайти на сайт, моніторинг показував нестабільність, а команда не одразу зрозуміла, де проблема — у застосунку, DNS, CDN чи зовнішньому API.

Це ідеальний момент для мініаудиту. Не треба починати з великого документа на 40 сторінок. Почніть з одного дня, однієї дошки й одного питання: що має залишитися керованим, якщо щось піде не так?

Шар 1: карта критичних залежностей

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

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

Шар 2: доступи без героїзму

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

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

Шар 3: резервна копія без тесту — це припущення

Багато команд кажуть: резервні копії в нас є. Стійка команда ставить інше питання: коли ми востаннє робили відновлення?

Тест відновлення не обов’язково має бути драматичним. Візьміть невеликий фрагмент даних або тестове середовище. Перевірте, чи доступна резервна копія, чи зрозумілий порядок дій, скільки часу займає повернення в робочий стан і хто має потрібні права. Зафіксуйте фактичний час, а не бажаний.

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

Шар 4: перші 30 хвилин інциденту

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

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

Шар 5: постачальники як частина вашої стійкості

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

Наприклад, якщо платіжний провайдер недоступний, чи може користувач зберегти замовлення? Якщо сервіс розсилок не працює, чи можна відкласти повідомлення в чергу? Якщо CDN має збій, чи знає команда, що саме можна перемкнути, а що краще не чіпати?

Анти-патерни, які варто прибрати

Перший анти-патерн: є захисний екран, отже ми захищені. Один інструмент не замінює карту залежностей, доступи, відновлення й інструкції.

Другий: план інциденту в голові найдосвідченішої людини. Це не план, а прихована залежність.

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

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

Мініаудит на один день

До обіду зберіть карту критичних залежностей і перевірте доступи. Після обіду проведіть малий тест відновлення, напишіть операційну інструкцію на перші 30 хвилин і створіть список рішень. Частину команда може зробити одразу: прибрати зайві права, додати власників, оновити контакти, винести інструкцію з приватних нотаток у спільне місце.

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

Джерела

• Cloudflare: Cloudflare joins UK Cyber Resilience Pledge — https://blog.cloudflare.com/cloudflare-joins-uk-cyber-resilience-pledge/
• NCSC: 10 Steps to Cyber Security — https://www.ncsc.gov.uk/collection/10-steps
• NIST Cybersecurity Framework — https://www.nist.gov/cyberframework