Быть готовым к техно-инциденту: что бизнесу нужно предусмотреть до того, как произойдёт ИТ-сбой

Большинство компаний задумываются о надёжности своей ИТ-инфраструктуры только после серьёзного сбоя – например, когда «падает» сервер и сотрудники теряют доступ к файлам, останавливаются продажи или бухгалтерия не может провести платежи. Обычно в этот момент выясняется, что никто не знает, где находится нужный сервер, кто отвечает за его обслуживание и где искать резервные копии. О том, что бизнесу стоит предусмотреть до того, как произойдёт ИТ-инцидент, порталу Biz360.ru рассказал эксперт по кибербезопасности Анатолий Волков.

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

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

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

Когда ИТ-система перестаёт работать, не стоит сразу искать причину поломки или пытаться перезапустить оборудование. На первом этапе задача проще. 

Шаг №1: зарегистрировать факт сбоя 

Сначала нужно зафиксировать, что именно перестало работать. Например, сотрудники не могут зайти в 1С или получить доступ к рабочим файлам. На этом этапе проверяем, стала ли причиной недоступности техническая неисправность, проблема с интернетом или что-то другое. 

Шаг №2: найти ответственного 

Следующий шаг – выяснить, кто отвечает за работу сервиса или хотя бы знает, как он устроен и где находится. Если в компании есть штатный системный администратор или ИТ-поддержка на аутсорсе, обращаться нужно к ним (к слову, при наличии мониторинга подрядчик может узнать о сбое ещё до обращения сотрудников). 

Шаг №3: проверить доступ к серверу или онлайн-сервису 

Если сотрудники не могут открыть локальную систему, например 1С, сначала стоит проверить сетевое подключение: есть ли доступ к другим ресурсам, не запущен ли VPN. Некоторые VPN-сервисы блокируют доступ к локальным сетям. Можно также перезагрузить компьютер, чтобы перезапустить службы и вернуть его в штатное состояние. 

Если это не помогло, нужно проверить сам сервер – выяснить, включен ли он и работает ли оборудование. Дальнейшие действия, в том числе перезагрузку сервера, лучше согласовать с ИТ-специалистом. 

Если речь об онлайн-сервисе, нужно проверить, оплачена ли подписка, обратиться в техподдержку и посмотреть, нет ли сообщений о сбоях на стороне поставщика. 

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

Обычно собственники ищут помощь через знакомых, в бизнес-сообществах, на Avito или Profi.ru. Часто у собственника есть контакты частников, которые когда-то что-то им настраивали. Но даже если такой человек нашёлся и приехал, он не знает вашу инфраструктуру: ему нужно время, чтобы разобраться, где что находится, как оно настроено и что именно сломалось. Это дополнительные часы простоя. 

Решение одно – договариваться с подрядчиком заранее. Неважно, будет это штатный администратор, аутсорс-команда или частный специалист на регулярной основе. Важно, чтобы человек владел знаниями об инфраструктуре и понимал, что делать в случае сбоя. Если компания сильно экономит на поддержке, она проиграет во времени. Если экономия умеренная, время восстановления после инцидента сокращается в разы. 

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

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

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

Во время инцидента важно не забывать о коммуникации внутри компании. Сотрудники должны понимать, что проблема обнаружена, специалисты занимаются её решением и работа над восстановлением уже идёт. Это не вопрос вежливости, это вопрос организации работы. Если люди не знают, что произошло, они будут дёргать сисадмина вопросами «Ну что там? Когда заработает?» – а каждое отвлечение увеличивает время восстановления. Поэтому если есть предварительная оценка сроков, её стоит сообщить. 

Две ошибки сотрудников, которые увеличивают ущерб: 

• Первая ошабка – молчание. Если шифровальщик попал на компьютер сотрудника через фишинговое письмо, и тот обнаружил подозрительную активность, но промолчал в надежде, что само пройдёт или что никто не заметит, процесс шифрования распространится на сетевые папки и удалённые ресурсы. К моменту, когда проблема станет очевидной, будет уже поздно.
  
  

• Вторая ошибка – беготня за специалистом. Сотрудники стоят над душой и задают вопросы, на которые не хотят знать ответов. Формулировка «А почему это не работает?» ставит администратора в тупик: он начинает объяснять технические детали, которых пользователь не поймёт, и теряет время на бесполезную работу. Каждый такой разговор – минуты и часы, которые прибавляются к общему времени простоя. 

Резервные копии (бэкапы) – один из ключевых элементов подготовки к ИТ-инцидентам. Однако на практике компании нередко относятся к ним формально. По нашим наблюдениям, примерно в 70% случаев, с которыми мы сталкивались, резервные копии либо отсутствовали, либо были настроены неправильно или не проверялись. Подчеркну, что это именно наша оценка по опыту работы с компаниями, а не общая статистика рынка. 

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

Частая иллюзия: данные лежат в облаке («Яндекс Диск», Google Drive, облако 1С) – «значит, они защищены». Это не так. Облачный сервис могут заблокировать, провайдер может пострадать от внешней атаки, аккаунт могут скомпрометировать. Отсюда вытекает правило: резервная копия должна быть независимой, храниться отдельно от рабочей среды и регулярно обновляться. 

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

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

Возврат к нормальной работе – это мини-аудит, в ходе которого необходимо проверить несколько вещей: 

• Доступность специалиста, который будет вести восстановление. Не важно, штатный он, ИТ-аутсорсер или частник – главное, чтобы он был на связи и владел информацией об инфраструктуре.
  
  

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

• Состояние резервных копий: что есть у бизнеса и где они находятся, насколько бэкапы свежие, проверялась ли возможность восстановления системы из них. 

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

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

Подготовка к ИТ-инциденту – не обязательно сложный и дорогой проект. Для начала бизнесу нужно разобраться в собственной инфраструктуре: навести порядок, определить критичные сервисы, найти специалиста или аутсорс-команду, которым можно доверять, и проверить, действительно ли резервные копии помогут вернуть данные. Эти шаги не исключат сбои, но позволят не начинать решение проблемы с нуля и сократить время простоя.

Фото: Dispida Foto/Shutterstock/Фотодом

Чтобы не пропустить интересную для вас статью о малом бизнесе, подпишитесь на наш Telegram-канал и страницу в «ВКонтакте».
biz360