Тема 3.9 — Непрерывность бизнеса и аварийное восстановление

В здравоохранении и уходе крупный сбой системы — событие безопасности пациентов раньше, чем проблема ИТ, поэтому ваша способность продолжать оказывать уход, пока система не работает, и полностью и быстро её восстановить — основная клиническая возможность и возможность общественного доверия, а не техническая сноска.

Почему это важно в здравоохранении и уходе#

Уход не останавливается, когда останавливается технология. Когда электронная карта пациента, платформа электронных назначений или система результатов лаборатории отказывает по всей больнице, клиницисты не могут приостановить лечение, пока инженеры работают. Они должны продолжать принимать пациентов, назначать лекарства и принимать решения, часто без оповещений об аллергиях, проверок доз и предшествующей истории, которые обычно обеспечивает отказавшая система. Поэтому сбой измеряется не только часами простоя и сервисными кредитами; он измеряется отложенными диагнозами, пропущенными взаимодействиями, отменёнными операциями и дополнительным риском, который несёт каждый клиницист, работающий вслепую. Непрерывность бизнеса — дисциплина обеспечения того, чтобы при худшем уход оставался настолько безопасным, насколько возможно.

Ставки национальные и хорошо задокументированы. Атака программы-вымогателя WannaCry 2017 года нарушила работу около трети трастов NHS в Англии, вынудила отменить тысячи приёмов и операций, перенаправить скорые и заблокировала персоналу доступ к самым устройствам (включая часть оборудования визуализации и патологии), которые нужны для лечения людей. Она обошлась NHS в оцениваемые £92 млн и, что важнее, показала, что кибератака на инфраструктуру здравоохранения обрушивается как клинический кризис, а не просто инцидент безопасности данных. С тех пор устойчивость переместилась из серверной за стол совета, и справедливо.

Эта тема расширяет операционную дисциплину темы 3.8 — Управление услугами и действующая эксплуатация, но смещает фокус с повседневной эксплуатации на крупное нарушение: пожар, наводнение, кибератаку, крах поставщика или региональный сбой, угрожающие вывести критичную услугу из строя на часы или дни. Она тесно связана с темой 1.7 — Управление информацией, защита данных и кибербезопасность (потому что восстановление после вымогателя теперь центральный сценарий непрерывности), с темой 4.0 — Техническая архитектура, облако и унаследованные системы (потому что устойчивость закладывается проектом, а не навешивается) и с темой 6.4 — Управление и гарантии (потому что кто-то должен владеть планом, тестировать его и отвечать за него). Сделайте это правильно, и нарушение станет плохим днём; сделайте неправильно, и оно станет публичным расследованием.

Ключевые понятия#

Непрерывность бизнеса и аварийное восстановление. Планирование непрерывности бизнеса (BCP) — способность продолжать оказывать продукты или услуги (в вашем случае безопасный уход) на заранее определённых приемлемых уровнях во время и после разрушительного инцидента. Аварийное восстановление ИТ (DR) — более узкое, техническое подмножество, касающееся восстановления систем, данных и инфраструктуры, лежащих в основе этих услуг. Непрерывность бизнеса — более широкое обещание («пациенты продолжают получать лечение»); аварийное восстановление — одно из средств («система результатов вернётся в течение четырёх часов»). Нужны оба, и нельзя путать восстановленный сервер с восстановленной услугой.

Управление непрерывностью бизнеса и анализ воздействия на бизнес. Управление непрерывностью бизнеса (BCM) — непрерывный процесс управления, а не разовый документ, выявляющий угрозы и создающий организационную устойчивость. Его основа — анализ воздействия на бизнес (BIA): структурированная оценка каждой услуги, спрашивающая, как быстро её потеря причиняет неприемлемый вред, от чего она зависит и насколько далеко назад во времени вы можете позволить себе потерять данные. BIA — место, где клиническое суждение входит в инженерию: клиницисты, а не только технологи, должны определить, что значит «неприемлемо» для системы родовспоможения и для интранета персонала.

Целевое время восстановления и целевая точка восстановления. Два числа закрепляют каждый план восстановления. Целевое время восстановления (RTO) — максимально приемлемое время восстановления услуги после сбоя. Целевая точка восстановления (RPO) — максимально приемлемый объём потери данных, выраженный во времени: RPO в пятнадцать минут означает, что вы можете перенести потерю не более последних пятнадцати минут записей. Для критичной клинической системы это могут быть минуты; для хранилища отчётности — дни. Честная установка их для каждой услуги — самое полезное решение по непрерывности, которое вы примете.

Резервные копии и проверенные восстановления. Резервная копия — копия данных, хранящаяся в другом месте, чтобы оригинал можно было восстановить после потери. Базовый уровень отрасли — правило 3-2-1: три копии на двух типах носителей, одна из которых хранится вне площадки (а в эпоху вымогателей одна хранится неизменяемой или автономной). Решающе важно: резервная копия, которую вы никогда не восстанавливали, — надежда, а не контроль. Вымогатели регулярно шифруют резервные копии, доступные из сети, а непроверенные восстановления регулярно проваливаются в день. Дисциплина состоит не в «делаем ли мы резервные копии?», а в «когда мы в последний раз успешно восстанавливались от начала до конца и сколько это заняло?».

Высокая доступность, избыточность и отказоустойчивое переключение. Высокая доступность (HA) — свойство проекта, сохраняющее систему работающей при отказе компонентов, обычно измеряемое «девятками» времени работы. Она достигается через избыточность, сознательное дублирование критичных компонентов, и отказоустойчивое переключение (failover), автоматическое переключение на резервный компонент или площадку при отказе основного. Высокая доступность снижает частоту сбоев; аварийное восстановление справляется с теми, что прошли. Они дополняют, а не заменяют друг друга, и их путаница оставляет опасные пробелы.

Единые точки отказа и критичные зависимости. Единая точка отказа (SPOF) — любой компонент, отказ которого останавливает всю услугу: одна сетевая линия, одна служба аутентификации, один поставщик, одна база данных или один человек, единственный знающий, как что-то работает. Картирование SPOF и критичных зависимостей (вышестоящих служб и третьих сторон, на которые ваша услуга молча полагается) — аналитическое сердце устойчивости. В современных ИТ здравоохранения зависимости редко локальны: служба единого входа, соединение с национальной магистралью или облачный регион могут вывести из строя сразу много систем.

Клинический простой и процедуры непрерывности бизнеса. У здравоохранения и ухода есть особый контроль, которого нет у универсальных ИТ: процедура клинического простоя — отрепетированный, безопасный запасной вариант (обычно бумажный) для оказания ухода, когда цифровая система недоступна, плюс процесс повторного ввода для сверки этой бумажной записи обратно в систему, когда она вернётся. Это непрерывность бизнеса, воплощённая у постели больного, и именно здесь планы непрерывности чаще всего встречаются с реальностью.

Вымогатели и киберпереход. Программа-вымогатель шифрует ваши данные и требует выкуп, и она стала определяющей угрозой непрерывности для систем здравоохранения. Атака WannaCry 2017 года — эталонный случай: поэтому киберрестановление (изоляция, пересборка из чистых резервных копий и проверка целостности до повторного подключения) теперь первоклассный сценарий в каждом серьёзном плане.

Стандарт непрерывности. ISO 22301 — международный стандарт систем менеджмента непрерывности бизнеса. Он предлагает признанную структуру (контекст, руководство, планирование, поддержка, операции, оценка, улучшение) для построения и аудита возможностей непрерывности и является полезным остовом независимо от того, добиваетесь ли вы формальной сертификации.

Лучшие практики#

1. Начинайте с анализа воздействия на бизнес, которым владеют клиницисты, а не только ИТ. Ранжируйте каждую услугу по клиническому вреду, причиняемому её отказом, и по тому, как быстро этот вред становится непереносимым, затем назначьте каждой конкретные RTO и RPO. Делайте это с клиницистами и операционными руководителями, несущими последствия, потому что «как долго мы можем безопасно работать без этого?» — вопрос ухода, а не инфраструктуры. Результат — приоритизированный список, говорящий, куда сначала тратить ваш конечный бюджет устойчивости.

2. Проектируйте устойчивость соразмерно критичности. Соотносите инженерию с воздействием: критичные для миссии системы (отделение неотложной помощи, ведение пациентов, электронные назначения) оправдывают высокую доступность, географическую избыточность и автоматическое переключение; менее критичные системы могут принять более долгое восстановление и более простые резервные копии. Сопротивляйтесь и недостаточной инженерии критичных систем, и золочению тривиальных. Архитектуру и непрерывность нужно проектировать вместе (см. тему 4.0 — Техническая архитектура, облако и унаследованные системы), потому что нельзя навесить устойчивость на хрупкий проект постфактум.

3. Выслеживайте единые точки отказа и скрытые зависимости. Систематически нанесите на карту зависимости каждой критичной услуги (сеть, аутентификация, DNS, национальные соединения, питание, охлаждение, ключевые поставщики и ключевые люди) и определите, где один отказ каскадируется. Уделите особое внимание общим службам, таким как единый вход или общий движок интеграции, отказ которых выводит из строя много систем сразу. Зависимость, которую вы не нанесли на карту, — зависимость, которую вы обнаружите во время сбоя.

4. Резервируйте так, чтобы пережить вымогателя, и доказывайте восстановления тестированием. Следуйте правилу 3-2-1 и держите хотя бы одну резервную копию неизменяемой или физически автономной, чтобы атакующий, достигший вашей сети, не мог зашифровать вашу последнюю линию защиты. Затем тестируйте восстановления по графику, замеряя время относительно вашего RTO и проверяя целостность данных относительно вашего RPO: восстановление, занимающее два дня при цели в четыре часа, — проваленный контроль, который вы просто ещё не заметили. Считайте «последнее успешное полное восстановление» метрикой, о которой вы отчитываетесь, а не задачей, которую предполагаете выполненной.

5. Пишите, обеспечивайте ресурсами и репетируйте процедуры клинического простоя. Для каждой критичной клинической системы поддерживайте проверенный бумажный (или автономный) запасной вариант, позволяющий персоналу продолжать безопасный уход во время сбоя, плюс ясный процесс повторного ввода этих данных потом без потерь и дублирования. Храните формы простоя там, где до них можно добраться, когда сеть и принтеры тоже не работают. Репетируйте их с персоналом переднего края, потому что процедуру, живущую только в папке, не найдут, не поймут и не будут ей доверять в 3 часа ночи во время кризиса.

6. Поддерживайте план аварийного восстановления с реальным переключением площадки. Задокументируйте для каждой критичной системы, как именно она восстанавливается: что где работает, в каком порядке, кто решает её задействовать и как вы возвращаетесь потом. Там, где воздействие это оправдывает, ведите по-настоящему отдельную площадку или облачный регион восстановления и докажите, что можете на него переключиться: порядок восстановления важен, потому что у систем есть зависимости, диктующие последовательность. Непроверенная площадка DR — дорогое допущение.

7. Отрабатывайте план; не проверенный план — проваливающийся план. Проводите регулярные учения по спектру: настольные прохождения сценариев, технические тесты переключения и эпизодические полные живые симуляции, включая клинический запасной вариант. Учения выявляют пробелы (устаревший список контактов, шаг восстановления, требующий пароля, которого ни у кого нет, допущение, что персонал знает бумажный процесс), пока их безопасно находить. Фиксируйте уроки, исправляйте и повторно тестируйте; учение без продолжения — театр.

8. Распространите непрерывность на поставщиков и облако. Ваша устойчивость настолько сильна, насколько сильны третьи стороны, от которых зависят ваши критичные услуги, поэтому сделайте непрерывность вопросом договора и гарантий: требуйте от поставщиков подтверждать их собственные RTO/RPO, тестирование DR и киберрестановление и понимайте модель общей ответственности вашего облачного поставщика: зоны доступности и регионы защищают от одних сбоев, но не от неверной конфигурации или компрометации учётной записи, которыми владеете вы. Планируйте и сам отказ поставщика, включая сценарий, где поражён вымогателем именно ключевой поставщик (см. тему 6.3 — Закупки и коммерческие вопросы).

9. Примите признанный стандарт и поставьте непрерывность под управление. Используйте ISO 22301 как структурированный остов, а руководство NHS и национальное руководство как отраслевую надстройку, и дайте названному руководителю подотчётность за непрерывность бизнеса с докладом совету. Непрерывность, которой никто не владеет, не финансирует и не пересматривает, тихо разлагается, пока инцидент её не раскроет. Подключите её к вашей рамке гарантий (см. тему 6.4 — Управление и гарантии), чтобы планы поддерживались, тестировались и улучшались как рутина, а не заново открывались в кризисе.

Вопросы для обсуждения с командой#

1. Для каждой из наших критичных клинических систем какие RTO и RPO мы на самом деле согласовали с клиницистами и можем ли мы их сейчас выдержать? Этот вопрос выводит разрыв между стремлением и возможностью на свет. Многие организации никогда не задавали явных целей восстановления или задавали их в ИТ без клинического вклада, так что «приемлемый» простой — просто то, что нынешняя архитектура случайно обеспечивает. Обсудите, где клиническая потребность (минуты для системы неотложной помощи) сталкивается с тем, чего ваши резервные копии и DR могут реально достичь (возможно, день), потому что этот разрыв — неуправляемый клинический риск, который вы несёте, называете вы его или нет. Посмотрите конкретно на ваше последнее реальное или проверенное восстановление: сколько оно заняло, сколько данных вы бы потеряли и кто подписал, что это безопасно? Хороший, честный ответ называет конкретные числа по каждой системе, признаёт, где вы пока не можете их выдержать, и превращает каждый разрыв в финансируемое действие, а не в комфортное молчание.

2. Если бы сегодня ночью вымогатель зашифровал наши основные системы и наши резервные копии, как бы мы обеспечили безопасность пациентов завтра и сколько времени до полного восстановления? Это сценарий, поразивший реальные системы здравоохранения, поэтому он заслуживает конкретного, не отводящего глаз разбора, а не заверений. Изучите обе половины честно: немедленная клиническая непрерывность (отрепетированы ли процедуры простоя, обеспечены ли ресурсами и достаточно ли им доверяют, чтобы вести целую больницу на бумаге днями?) и техническое восстановление (неизменяемы ли и автономны ли резервные копии, тестировали ли вы пересборку из чистых копий, знаете ли вы порядок восстановления?). Выведите на свет неудобные зависимости: если единый вход, движок интеграции или ключевой поставщик не работает, сколько ещё падает вместе с ним? Подумайте, кто объявляет крупный инцидент, кто говорит с персоналом, пациентами и СМИ и кто решает, что систему безопасно подключить повторно. Сильный ответ описывает отрепетированный план с названными ролями и проверенными восстановлениями; слабый предполагает, что резервные копии в порядке, а бумажный процесс просто заработает.

3. Когда мы в последний раз тестировали наши планы непрерывности и аварийного восстановления от начала до конца и что мы узнали? Цель здесь — отличить живую возможность от документа на полке. План, который не отрабатывался, не проверен, а непроверенные планы регулярно проваливаются при контакте с реальностью: список контактов устарел, шаг восстановления требует учётных данных, которых ни у кого нет, формы простоя хранятся на системе, которая не работает. Обсудите диапазон учений, которые вы реально проводите: настольные сценарии, технические тесты переключения и полные симуляции, включающие клинический запасной вариант переднего края, а не только восстановление сервера. Проверьте, были ли уроки прошлых инцидентов и учений действительно исправлены и повторно протестированы или записаны и забыты. Хороший ответ показывает регулярный календарь учений, доказательства найденных и закрытых пробелов и честность в том, какие части плана остаются недоказанными.

4. Какими из наших критичных зависимостей мы не управляем и каков наш план на день, когда одна из них откажет? Современные ИТ здравоохранения редко отказывают в одиночку; они отказывают через службы и поставщиков под ними. Подтолкните команду за пределы систем, которыми вы владеете, к тем, на которые вы лишь полагаетесь: соединение с национальной магистралью, поставщик единого входа, облачный регион, движок интеграции, аутсорсинговый центр данных, партнёр по управляемым услугам, держащий ключи к восстановлению. Для каждой спросите, что происходит с уходом, если она исчезнет на день, обязывает ли контракт третью сторону к цели восстановления, соответствующей вашей клинической потребности, и видели ли вы когда-нибудь доказательства их тестирования DR, а не успокаивающий абзац в заявке. Неудобная правда в том, что вы можете нести остаточный риск, которому никогда не назначали цену, потому что сбой находится в чужом парке. Честный ответ называет конкретные внешние зависимости каждой критичной услуги, указывает, какие договорно гарантированы, а каким просто доверяют, и определяет запасной вариант (даже ручной) для зависимостей, которые вы не можете сделать устойчивыми.

5. Когда ударит крупный инцидент, кто что решает, кто с кем общается и знает ли каждый свою роль до этого дня? Непрерывность — столько же о командовании и коммуникации, сколько о резервных копиях, и именно здесь расходятся отрепетированные планы и импровизированный хаос. Проработайте человеческую хореографию: у кого есть полномочия объявить крупный инцидент и задействовать план, кто ведёт операционное реагирование, кто решает, что систему безопасно подключить повторно, и кто говорит с персоналом, пациентами, прессой, регуляторами и, при кибератаке, правоохранительными органами. Подумайте об отказе ваших собственных инструментов во время инцидента, потому что сбой может вывести из строя электронную почту, телефонный справочник или интранет, которыми вы обычно координировались бы. Выведите на свет напряжение между быстрым и безопасным движением и репутационными ставками ошибки в публичном сообщении. Сильный ответ указывает на проверенную структуру командования инцидентом с названными, замещаемыми ролями, внеполосными каналами коммуникации и заранее согласованными шаблонами сообщений; слабый предполагает, что нужные люди просто соберутся и будут знать, что делать.

6. Как мы финансируем, владеем и поддерживаем жизнь непрерывности, когда два года ничего не шло не так? Устойчивость тихо разлагается в промежутке между инцидентами, и этот вопрос противостоит организационной дисциплине, не дающей ей гнить. Непрерывность конкурирует за деньги и внимание с видимыми, срочными клиническими и цифровыми приоритетами, а незрелая и везучая организация выглядит неотличимо от зрелой вплоть до дня, когда это не так. Обсудите, кто действительно владеет непрерывностью на уровне руководства, есть ли у неё финансируемая строка, а не заимствованная доброжелательность, и как планы, карты зависимостей и списки контактов поддерживаются актуальными по мере изменения систем и персонала. Спросите, что совет на самом деле видит: проверенные гарантии и честные пробелы или зелёный рейтинг и подшитый документ. Хороший ответ описывает названную подотчётность, повторяющийся бюджет и календарь учений и ритм управления, считающий поддерживаемую, проверенную непрерывность рутиной, а не тем, что заново открывают в следующем кризисе.

На практике: пример из здравоохранения и ухода#

NHS Foundation Trust Meadowvale ведёт больницу неотложной помощи на 600 коек. Во вторник утром персонал обнаруживает, что их электронная карта пациента (EPR), патология и системы радиологии заблокированы запиской с требованием выкупа; атакующие вошли через учётную запись удалённого доступа поставщика десятью днями ранее. Директор по информации объявляет крупный инцидент в течение часа, и активируется план непрерывности бизнеса траста.

Поскольку траст провёл анализ воздействия на бизнес, он знал, что EPR и патология — системы наивысшей критичности с согласованными целями восстановления, а его процедуры простоя были отрепетированы прошлой осенью. Отделения переходят на бумажные листы лекарств и заранее напечатанные формы наблюдений, намеренно хранящиеся в физических шкафах в каждом отделении, а не на общем диске, а отделение неотложной помощи возвращается к бумажному маршруту. Плановые операции на неделю откладываются и сообщаются пациентам; скорые перенаправляются в самые напряжённые периоды. Уход продолжается, ухудшенный, но безопасный, потому что персонал отрабатывал работу таким образом.

Восстановление труднее, чем возврат. Команда безопасности изолирует сеть, чтобы остановить распространение, затем пересобирает критичные системы из неизменяемых резервных копий, хранимых автономно, копий, до которых атакующие не могли добраться. Эти резервные копии проверялись восстановлением ежеквартально, так что команда знала, что процесс работает и примерно сколько он занимает; EPR возвращается в пределах своего RTO в восемь часов, хотя патология, с более сложными зависимостями, занимает два дня. RPO в пятнадцать минут означает, что потеряно лишь короткое окно данных, а персонал сверяет бумажные записи обратно в систему по контролируемому процессу повторного ввода, перепроверяя лекарства и результаты.

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

Отраслевые перспективы#

Стартап#

У стартапа цифрового здравоохранения редко есть запасной центр обработки данных, поэтому его стратегия непрерывности почти целиком опирается на облачно-нативную устойчивость и дисциплинированные резервные копии. Используйте управляемые услуги со встроенной высокой доступностью по зонам доступности, автоматизируйте резервные копии с неизменяемыми копиями вне учётной записи, чтобы пережить и вымогателя, и скомпрометированную облачную учётную запись, и действительно репетируйте восстановление в чистую среду. Ваши клиенты (траcты NHS и интегрированные системы ухода) будут всё чаще требовать доказательства RTO, RPO и тестирования DR через рамки вроде DTAC и гарантий поставщика, поэтому считайте непрерывность коммерческим активом, а не накладными расходами. Экзистенциальный риск для небольшого поставщика в том, что единственный инцидент или основатель, единственный понимающий развёртывание, становится вашей единой точкой отказа.

Малый бизнес#

Устоявшийся небольшой поставщик (практика врача общей практики, общественная аптека, дом престарелых, агентство ухода на дому или клиника в одном месте) несёт ту же обязанность сохранять пациентов в безопасности во время сбоя, что и крупный траст, но с реальными пациентами, тугими деньгами и часто вовсе без выделенного ИТ-персонала. Непрерывность здесь намеренно прагматична: знайте, какие одна-две системы (клиническая карта, система отпуска или eMAR) остановили бы безопасный уход при отказе, настаивайте, чтобы поставщик вашей системы подтверждал собственные резервные копии, RTO и RPO, и держите простой, распечатанный пакет простоя (бумажные листы лекарств, ключевые телефоны, недавние списки пациентов) там, где персонал может до него дотянуться, когда экраны тёмные. Поскольку один управляющий практикой или одинокий ИТ-подрядчик — часто единственный человек, понимающий настройку, запишите шаги восстановления и убедитесь, что второй человек может им следовать. Вымогатели и сломанная линия широкополосного доступа — повседневные угрозы, поэтому автономная или неизменяемая резервная копия и запасной способ работы важнее любой сложной площадки DR, которую вы не можете себе позволить или вести.

Крупная организация#

Крупный траст NHS, интегрированная система ухода или крупный поставщик health-tech несёт разросшийся, взаимозависимый парк, где самая трудная проблема — картирование зависимостей и общих служб, а не какая-либо отдельная система. Инвестируйте в формальную программу BCM, согласованную с ISO 22301, поддерживаемую карту зависимостей, площадки или регионы DR для критичных систем и скользящий календарь учений, включающий клинический запасной вариант. Масштаб означает, что SPOF часто — общие службы (идентификация, движки интеграции, ядра сети), чей отказ каскадируется по десяткам систем. Связывающее ограничение — управление: при многих командах и поставщиках непрерывность держится, только если названный руководитель владеет ею, а совет рассматривает проверенные гарантии, а не бумажные планы.

Государство#

Национальный орган (NHS England, департамент здравоохранения децентрализованной администрации или UKHSA) должен думать об устойчивости в масштабе населения и системы, где отказ национальной услуги или широко используемого поставщика сам является событием непрерывности для всего сектора. Задавайте стандарты и ожидания (цели восстановления, киберрестановление, обязательные учения), финансируйте общие защитные возможности и координируйте общесекторное реагирование на крупные инциденты, такие как национальная кампания вымогателей. Реагирование на WannaCry переформатировало национальную политику именно потому, что воздействие пересекло сотни организаций сразу, выявив общие слабости. Подотчётность здесь публична и парламентская, поэтому прозрачность в отношении известных рисков и честная отчётность о готовности значат не меньше самих технических контролей.

Типичные способы сбоя#

• Резервные копии, которые никогда не восстанавливали. Путаница «мы делаем резервные копии каждую ночь» с «мы можем восстановиться». Непроверенные восстановления регулярно проваливаются или срывают RTO; измеряйте и докладывайте успешные сквозные восстановления, а не завершение резервного копирования.
• Резервные копии, доступные вымогателю. Хранение каждой резервной копии онлайн и подключённой к сети, так что атакующий шифрует их вместе с производством. Держите хотя бы одну неизменяемую или автономную копию.
• DR, защищающий серверы, а не услуги. Восстановление базы данных, но не зависимостей, интеграций и доступа, делающих её пригодной клинической услугой. Восстанавливайте и тестируйте целые услуги в порядке зависимостей.
• Процедуры простоя, существующие только на бумаге о бумаге. Запасные планы, которые никогда не репетировались, хранятся на отказавшей системе или неизвестны персоналу переднего края. Репетируйте их там, где уход на самом деле происходит.
• Нанесённые на карту зависимости и общие SPOF не нанесены. Обнаружение во время сбоя, что единый вход, DNS или один поставщик лежали под всем. Наносите зависимости на карту до инцидента, а не во время него.
• План, написанный для аудитора и никогда не отработанный. Непрерывность как документ соответствия, разлагающийся непроверенным до дня, когда он понадобится. Не проверенный план — проваливающийся план.
• Игнорирование непрерывности поставщиков и облака. Предположение, что ваши третьи стороны устойчивы без доказательств, и забывание модели общей ответственности. Сделайте непрерывность договорной и гарантируемой.

Модель зрелости#

Контрольный список#

• Анализ воздействия на бизнес, совместный с клиницистами, ранжирует каждую услугу и задаёт явные RTO и RPO для каждой критичной системы.
• Критичные системы имеют высокую доступность и избыточность, соразмерные их клинической критичности.
• Единые точки отказа и критичные зависимости (включая общие службы и поставщиков) нанесены на карту и смягчены.
• Резервные копии следуют правилу 3-2-1 с хотя бы одной неизменяемой или автономной копией, до которой вымогатель добраться не может.
• Восстановления тестируются по графику и замеряются относительно RTO/RPO, а «последнее успешное восстановление» докладывается как метрика.
• У каждой критичной клинической системы есть отрепетированная процедура простоя и контролируемый процесс повторного ввода данных.
• План аварийного восстановления определяет шаги восстановления, порядок, полномочия принятия решений и возврат, а площадка/регион DR протестированы.
• Сценарий киберрестановления (изоляция, пересборка из чистых резервных копий, проверка, повторное подключение) задокументирован и отработан.
• Непрерывность поставщиков и облака договорно требуется, подтверждается и гарантируется, включая модель общей ответственности.
• Непрерывность согласована с ISO 22301, принадлежит названному руководителю, отрабатывается по календарю и докладывается совету.

Ключевые источники#

• NHS England — Business Continuity Management Toolkit и Emergency Preparedness, Resilience and Response (EPRR) Framework and Core Standards.
• National Cyber Security Centre (NCSC) — руководство по автономным/неизменяемым резервным копиям, смягчению вымогателей и реагированию на инциденты.
• ISO 22301:2019 — Security and resilience — Business continuity management systems — Requirements (International Organization for Standardization).
• ISO/IEC 27031 — Guidelines for information and communication technology readiness for business continuity.
• Business Continuity Institute (BCI) — Good Practice Guidelines.
• National Audit Office — Investigation: WannaCry cyber attack and the NHS (2017) и обзор уроков Департамента здравоохранения.
• NHS England / Data Security and Protection Toolkit (DSPT) — стандарты безопасности данных, включая непрерывность бизнеса и реагирование на инциденты.
• GOV.UK Service Manual — руководство по устойчивости, мониторингу и восстановлению для действующих услуг.

Ссылки#

1. Business continuity planning — Wikipedia — https://en.wikipedia.org/wiki/Business_continuity_planning
2. IT disaster recovery — Wikipedia — https://en.wikipedia.org/wiki/IT_disaster_recovery
3. ISO 22301 — Wikipedia — https://en.wikipedia.org/wiki/ISO_22301
4. Backup — Wikipedia — https://en.wikipedia.org/wiki/Backup
5. High availability — Wikipedia — https://en.wikipedia.org/wiki/High_availability
6. Redundancy (engineering) — Wikipedia — https://en.wikipedia.org/wiki/Redundancy_(engineering)
7. Failover — Wikipedia — https://en.wikipedia.org/wiki/Failover
8. Single point of failure — Wikipedia — https://en.wikipedia.org/wiki/Single_point_of_failure
9. Ransomware — Wikipedia — https://en.wikipedia.org/wiki/Ransomware
10. WannaCry ransomware attack — Wikipedia — https://en.wikipedia.org/wiki/WannaCry_ransomware_attack
11. ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements — International Organization for Standardization — https://www.iso.org/standard/75106.html
12. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
13. Emergency Preparedness, Resilience and Response (EPRR) — NHS England — https://www.england.nhs.uk/ourwork/eprr/
14. Offline backups in an online world — National Cyber Security Centre — https://www.ncsc.gov.uk/blog-post/offline-backups-in-an-online-world
15. Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/