Цифровой хаос в компании: как понять, какие сервисы, доступы и данные нужно взять под контроль

Компания может исправно продавать, запускать рекламу и обновлять сайт — и при этом почти не контролировать собственную цифровую инфраструктуру.

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

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

Проблема не в количестве сервисов

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

Само по себе это нормально. Опасная точка возникает тогда, когда компания перестаёт видеть цифровой контур целиком.

Например, сайт может находиться на виртуальном сервере, домен — у отдельного регистратора, DNS — управляться через третий сервис, код — храниться в репозитории, а формы передавать заявки сразу в CRM, систему аналитики и сервис email-рассылок. Если каждый элемент существует независимо и известен только человеку, который когда-то его настраивал, возникает зависимость не от технологии, а от конкретных сотрудников и подрядчиков.

Международные рекомендации по информационной безопасности начинают именно с инвентаризации. В CIS Controls v8.1 отдельные базовые меры посвящены учёту корпоративных активов, программного обеспечения, аккаунтов и данных. NIST Cybersecurity Framework 2.0 также рассматривает понимание активов, рисков и ответственности как часть системного управления киберрисками.

Для бизнеса это означает довольно простой принцип: невозможно нормально защищать, восстанавливать и передавать то, о существовании чего компания не знает.

Где цифровой хаос обычно прячется

Доступы принадлежат людям, а не компании

Один из самых частых сценариев — важный сервис зарегистрирован на персональный или индивидуальный рабочий аккаунт.

Так появляется домен, оформленный на бывшего разработчика, аналитика на почте агентства или облачный сервис, где единственный администратор — руководитель, который когда-то самостоятельно его подключил.

Проблема здесь шире пароля. Нужно понимать, кто является владельцем аккаунта, кто администратором, кто может восстановить доступ и на какие контакты придёт письмо при его сбросе.

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

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

Компания не знает, где лежат её данные

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

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

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

Если компания работает с персональными данными, этот вопрос имеет и правовую сторону. Действующая редакция 152-ФЗ требует от оператора принимать правовые, организационные и технические меры защиты персональных данных, устанавливать правила доступа и обеспечивать регистрацию и учёт действий с ними. Кроме того, с 1 июля 2025 года часть 5 статьи 18 устанавливает ограничения на использование зарубежных баз данных при сборе персональных данных граждан РФ, за исключением предусмотренных законом случаев.

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

Составьте карту цифровых активов

Для начала не нужна сложная CMDB или отдельная система управления инфраструктурой. Для небольшой или средней компании достаточно единого реестра, если он действительно поддерживается в актуальном состоянии.

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

Это защищает от ситуации, когда IT знает, как работает CRM, но не понимает, насколько она критична для продаж, а коммерческий отдел знает её ценность, но не может объяснить, где находятся данные и как вернуть систему в работу.

Самая важная проверка — что произойдёт при увольнении человека

Хороший тест цифровой зрелости звучит не «есть ли у нас пароли», а иначе:

Если завтра конкретный сотрудник или подрядчик перестанет работать с компанией, какие процессы остановятся?

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

В CIS Controls отдельно предусмотрены процессы выдачи и отзыва доступа, а также регулярная проверка существующих аккаунтов. При прекращении работы сотрудника или изменении его роли доступы должны пересматриваться, а не оставаться активными «на всякий случай».

Практически это означает, что offboarding должен затрагивать не только корпоративную почту. Нужно проверить CRM, документы, рекламные системы, аналитику, CMS, серверы, репозитории, сервисы рассылок, телефонию, менеджеры паролей и любые системы, где человек имел административные права.

Отдельно проверьте технические доступы

Часть критичных доступов вообще не выглядит как обычная учётная запись.

Это SSH-ключи, API-токены, ключи интеграций, доступы к базам данных, service accounts, ключи деплоя и секреты, используемые приложениями.

Их сложнее контролировать, потому что они могут продолжать работать после блокировки корпоративной почты человека.

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

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

Бэкап существует только тогда, когда понятен процесс восстановления

Фраза «у нас есть резервные копии» сама по себе мало что говорит об устойчивости бизнеса.

Нужно знать, что именно резервируется, как часто создаются копии, сколько они хранятся, кто имеет к ним доступ и сколько шагов потребуется для восстановления.

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

CISA включает резервное копирование в рекомендации для малого и среднего бизнеса, а NIST подчёркивает необходимость не только регулярно создавать копии, но и проверять их в ходе восстановления.

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

Не пытайтесь привести в порядок всё за один день

Цель первого аудита — не построить идеальную систему управления доступами, а обнаружить критические неизвестные.

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

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

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

Следующий шаг — установить регулярность проверки. Реестр, который составили один раз и забыли, быстро превращается в ещё один устаревший документ.

Контроль не означает централизацию всего

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

Это не обязательно.

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

Цифровой порядок — это не минимальное количество аккаунтов и не единая панель управления всем бизнесом.

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

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