Управление рисками и непрерывность бизнеса

Управление рисками легко спутать с таблицей, которую заполняют раз в год к приходу аудитора. Меня зовут, когда нужен рабочий вариант: короткий перечень угроз, способных остановить бизнес, с владельцем и проверенным планом действий на каждую. Проверенным – значит его хотя бы раз прогнали, а не просто написали.

С чем приходят

Типичный первый разговор идёт по чужой бумаге. Банк или крупный заказчик прислал анкету о непрерывности на пятьдесят вопросов и дал десять дней. Дальше спрашивают допустимый простой биллинга, кто вправе объявить инцидент и когда последний раз разворачивали копию, – и заполнение встаёт. Дело при этом не в беспорядке: копии делаются каждую ночь, а реестр рисков существует – сорок строк с приоритетом «средний» и ни одной фамилии рядом. Просто ни одно из этих чисел никто ни разу не произносил вслух.

Управление рисками начинается с реестра

Реестр собирается не от каталога угроз, а от денег: что перестанет приносить выручку завтра, если система, человек или поставщик исчезнет сегодня. У компании на сто человек критичных точек редко больше десяти, и половина не про технику, а про сотрудника, который держит расчёты в голове.

Скелетом служит ISO 31000, но стандарт – форма записи, а не цель. Проверка строки простая: если никто не скажет, что с ней произойдёт в ближайший понедельник и чьей подписью это закончится, строка написана зря.

• Разбор зависимостей: какие функции критичны и где точка отказа единственная.
• Оценка последствий в деньгах и часах простоя, не в баллах.
• Владелец риска – конкретный человек, а не отдел.
• Решение по каждому пункту: закрыть, застраховать или осознанно принять.

Под требования DIFC, ADGM или Центрального банка ОАЭ реестр и планы пишутся так, чтобы проходить проверку. Настройку самого периметра в этот проект не беру: это информационная безопасность, со своим объёмом и сроком.

Непрерывность и восстановление

План непрерывности начинается с двух чисел на каждую критичную функцию: сколько она может не работать и сколько данных допустимо потерять. Называет их бизнес, а не ИТ. Цель «восстановить за четыре часа» чаще означает, что так получается с текущей архитектурой, а не что четыре часа простоя приемлемы.

Дальше числа переводятся в решение, и перевод арифметический: четыре часа означают, что образ обязан подниматься за два, вторую половину съедают обнаружение, решение и проверка. Отдельно считается компрометация всего контура: копия под тем же ключом, что и продуктив, не восстановит ничего. Ориентир – ISO 22301; копия, которую ни разу не разворачивали, резервной не считается, поэтому её проверка входит в проект. Доступность и допустимый простой – разные обещания: 99,9 % на проекте Monolith Plus – это около восьми часов в год, которые ещё надо разделить между окнами обслуживания и авариями.

Реагирование на инциденты

В момент инцидента времени на выяснение полномочий нет. План отвечает на скучные вопросы заранее: кто объявляет инцидент, кто вправе остановить сервис, кто говорит с клиентом и регулятором, по какому каналу связываются, если почта недоступна из-за самого инцидента.

Структура берётся из NIST SP 800-61: обнаружение, сортировка, сдерживание, устранение, восстановление, разбор. Под каждый сценарий – инструкция на одну-две страницы: шифровальщик, отказ поставщика, утечка данных. Сигнал приходит от мониторинга – его устройство разобрано в статье SIEM на открытом ядре.

Учения: план, который прогнали

Работающую программу от папки документов отличает одно: её прогоняют и смотрят, что сломается.

• Настольный разбор: каждый говорит, что делает в первые пятнадцать минут.
• Восстановление из копии на отдельном контуре, с замером по секундомеру.
• Отказ поставщика: платёжный провайдер закрыл приём на сутки, а деньги надо принимать завтра.
• Отсутствие ключевого человека: тот, кто закрывает месяц, недоступен три дня, а сдавать в пятницу.

Стек

В таблице только то, что отвечает за одно из двух чисел: за срок восстановления или за глубину потери.

Что подтверждает	Инструменты
Копия, которую разворачивают	Proxmox Backup Server, OpenZFS
Контур, на котором проводят учение	Proxmox VE
Замер простоя и оповещение	Uptime Kuma, Grafana
Переключение, записанное как сценарий	Ansible

Чего я не делаю

• Сертификат по ISO 22301 из этого проекта не выходит. Выходит отчёт по учениям: даты, замеренное время восстановления, список того, что при прогоне сломалось.
• Не пишу реестр по описанию с совещания: без доступа к процессам выйдет документ, а не защита.
• Не заменяю страхового брокера: решение «страхуем» довожу до цифры ожидаемого убытка, полис подбирает брокер.
• Ни один поставщик копирования или страховщик не платит мне за упоминание; лицензии вы покупаете напрямую и на своё имя.

Как устроен проект

Первое, что появляется в проекте, – два числа на одну функцию. На первой встрече берётся самая денежная функция, и вслух называются её допустимый простой и допустимая потеря данных; обычно тут и выясняется, что у двоих руководителей цифры разные. Дальше две недели уходят на процессы и зависимости, а результат – карта критичных функций с теми же числами и с тем, что мешает их выдержать.

Основная часть – от восьми до четырнадцати недель для компании на 30–150 сотрудников: реестр, план непрерывности, инструкции по инцидентам, настройка мониторинга и копирования, передача команде. Завершение – учения и доработка планов.

Проект оценивается фиксированной суммой, ориентир – 30 000 $; точная цена – после обследования.

Связанные услуги

Техническая защита периметра – информационная безопасность. Риски в трёхлетнем плане – стратегическое планирование. Ликвидность и валютные разрывы – финансовое управление. Независимый взгляд на весь стек – ИТ-консалтинг.

Часто задаваемые вопросы

Когда получится провести первые учения?

Настольный разбор – пятая неделя, полное восстановление на отдельном контуре – между десятой и четырнадцатой. Собрать участников на два часа обычно сложнее, чем настроить копирование.

Чем это отличается от информационной безопасности?

Безопасность закрывает технический периметр: доступы, устройства, шифрование, мониторинг. Риски шире: уход ключевого сотрудника, отказ поставщика, потеря аккаунта. Киберриск – один пункт реестра.

С кем нужно поговорить, чтобы реестр не остался бумагой?

С теми, кто выполняет процесс руками: бухгалтер называет самый дорогой день месяца, администратор – время подъёма последнего упавшего сервера.

Кто ведёт реестр после завершения проекта?

Один человек из вашего руководства, названный до старта. Реестр живёт по календарю: пересмотр раз в квартал и после каждого инцидента. Остаются проверенные RTO и RPO, инструкции, настроенные мониторинг и копирование, отчёт по учениям.

---

Готовы начать?

Назовите функцию, остановка которой дороже всего: за разговор станет ясно, нужна ли полная программа или хватит двух-трёх точечных работ. Обсудить первую функцию: консультация бесплатная.