Как не потерять бизнес после ухода ИТ-директора или подрядчика

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

Как это работает? Скажем, может выясниться, что ни у кого в компании нет актуального списка сервисов, доменов, серверов и облаков. Аккаунты зарегистрированы на личные электронные адреса покинувших организацию сотрудников, а это грозит потерей доступов к корпоративным облачным хранилищам и панелям управления (ISPmanager, Bitrix, Miro, Jira и др.). Продолжаются платные подписки на сервисы, к которым никто не имеет доступа, неизвестно, какие лицензии/услуги продлены, а какие уже истекают. И при этом у бывших сотрудников или подрядчиков остаются активные доступы, потому что про них просто забыли. А в худшем случае возможны утечки и саботаж – так бывает, если «развод» сотрудников с компанией прошел в негативном ключе и спровоцировал недовольство.

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

Все это приводит к риску остановки бизнеса, когда любой сбой превращается в многодневную аварию.

Шаг 1. Назначить ответственных и зафиксировать роли:

• Кто администрирует, кто следит за доступами, кто отвечает за обучение, кто отвечает за мониторинг, обновления, инциденты.

Шаг 2. Провести ревизию ИТ-ресурсов и доступов:

• Составить перечень всех ИТ-сервисов, включая теневые и самописные: CRM, почта, облака, сайты, серверы, базы.
• Определить всех, у кого есть доступы, отозвать или изменить устаревшие и "общие" аккаунты.
• Назначить владельцев каждого сервиса и зоны ответственности.

Шаг 3. Формализовать процессы, описав их в базовых документах:

• Политике информационной безопасности.
• Регламенте управления доступами (создание, отзыв, пересмотр, временный доступ).
• Инструкции владельцам сервисов по обеспечению информационной безопасности.
• Инструкции пользователя.
• Регламенте обновления ПО.
• Регламенте резервного копирования и восстановления.
• Регламенте инцидентов: что делать при фишинге, взломе, утечке.
• Шаблоне соглашения о неразглашении.

Шаг 4. Подготовить план реагированию на инциденты:

• Кто и что делает при утечке, заражении, взломе. Создать «канал тревоги»: куда писать при подозрении на инцидент.
• Контакты подрядчиков, хостеров, облаков для быстрого отключения/ограничения.
• Копии всех документов по ИБ и доступов — в защищённом хранилище.

Шаг 5. Обучить сотрудников практикам и культуре безопасности, потому что информационная безопасность – это общее дело:

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

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

Информационная безопасность — это не про железо. Это про готовность, дисциплину и внимание к деталям.