7 мая 2025 г.

Окончание, начало тут

Возникает резонный вопрос: а стоит ли столько усилий тратить на противостояние рискам, которые достаточно редки? Последний масштабных блэкаут в Москве был ровно 20 лет назад — в мае 2005 года! Разумеется, это каждая компания решает в индивидуальном порядке. Хотя масштабные блэкауты бывают относительно редко, от локальных — в масштабах области, города района или, например, нескольких кварталов — никто не застрахован, причин для них может быть много, от природных и техногенных до злонамеренных.

Крупнейшая авария в энергосистеме Москвы произошла 25 мая 2005 года, в результате нее на несколько часов была отключена подача электроэнергии в ряд районов мегаполиса. Столичные веерные отключения привели к проблемам с электрическом в Подмосковье и ряде сопредельных регионов — в Тульской, Калужской и Рязанской областях. Экономический ущерб был огромен, в частности, на птицефабриках регионов тогда погибли порядка миллиона куриц.

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

От ПК и ПАК до «сетевухи» и телекома

Количество вопросов, на которые нужно найти ответы в зависимости от особенностей бизнес-процессов в компании и ее оргструктуры, оказывается достаточно велико. Нужно определить, какие endpoint’ы должны продолжать работу даже при масштабном блэкауте и в течение какого срока.

После этого определить варианты обеспечения электропитания, причем как самих устройств, так и компонентов сетевого обеспечения, отвечающих за коммуникацию этих компонент ИТ-инфраструктуры с серверной составляющей. Сетевая структура может оказаться очень разнообразной, для ее работы придется обеспечивать локальное функционирование самых разных решений — от роутеров до NGFW — а также определить, как блэкаут повлияет на работу операторов связи, если какие внешние каналы при работе нужны для связи с «облаками» и/или с ИТ-системами контрагентов.

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

Фокус внимания: от «железа» до данных

В ходе подготовки следует позаботиться о сохранности данных, обрабатываемых на компьютерах, функционирование которых в случае масштабного блэкаута решено не поддерживать. Что-то можно списать на «сопутствующий ущерб», а чему-то понадобится аккуратное сохранение. Последний вариант имеет разные решения: от перевода систем в группу «работают даже при блэкауте» до переноса вычислений на виртуальные машины, которые «крутятся» на серверах в ЦОДе/серверной, способных работать даже при масштабных отключениях.

Следует помнить о традиционных вопросах инфобезопасности. В общем случае анализ защищенности «урезанного» рельефа нужно проверять отдельно. Вполне возможно, например, что wi-fi-роутеры, призванные обеспечивать работоспособность в аварийных условиях, когда кабельная сеть отключена, требуют обновления прошивок, активации нужных протоколов шифрования или банальной замены пар логин/пароль от установленных по умолчанию.

Нужны киберучения

Кроме постановки бизнес-задач и решения нужного для них ряда технических, интеграционных и организационных вопросов нужно понять, насколько изменения в ИТ-рельефе, необходимые для подготовки в блэкауту, окажутся работоспособны на практике. Ответ на этот вопрос могут дать только проведенные киберучения. Только так можно выяснить, например, что для продолжения работы системы документооборота в компании — предположим, что она является business critical — необходимо функционирование отдельных компьютеров в секретариате и хотя бы одного МФУ. Разумеется, анализировать придется корректность поведения сотрудников и взаимодействия с контрагентами.

К контрагентам в рассматриваемом контексте относятся самые разные компании и даже отдельные персоны. Прежде всего, это поставщики решений — не только коммуникационных сервисов и «облаков», но и различных «...aaS» — но стоит помнить о поставщиках/заказчиках, филиалах и дочерних структурах, сотрудниках, работающих «на удаленке», фрилансерах и т. д. Напомним, что с ИТ-ресурсами корпоративного заказчика могут — в разрешенных регламентами пределах, разумеется — взаимодействовать не только люди, но и роботы, количество и разнообразие которых растет.

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

Вместо заключения

Мы рассмотрели только часть проблем, в реальности ситуация гораздо шире, учитывая поведение не только ИТ-рельефа, но и киберфизических систем, обеспечивающих работу инфраструктуры. Например, как поведет себя при отключении энергии система контроля и управления доступом? Не окажется ли офис открыт для проникновения или, наоборот, не заблокирует ли СКУД внутри помещения сотрудников? Разумеется, аналогичные вопросы возникнут для MES или, предположим, складских ИТ-решений, и все это тоже нужно решать.

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

Источник: Александр Маляревский, внештатный обозреватель IT Channel News