Кибергигиена малого бизнеса: проверяемый чек-лист

Сначала определите, что именно нельзя потерять

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

Для каждого актива ответьте на три вопроса. Что произойдёт при потере доступа? Можно ли восстановить работу без конкретного сотрудника? Какой документ или тест подтверждает ответ? Если доказательства нет, статус не «всё хорошо», а UNKNOWN. Такая честная отметка полезнее уверенного предположения: она превращается в конкретную задачу с владельцем и сроком.

Проверяемый чек-лист: четыре статуса вместо формального «да»

Используйте один из четырёх результатов: PASS_WITH_EVIDENCE — контроль работает и есть актуальное подтверждение; FAIL — проверка показала нарушение; UNKNOWN — ответ не подтверждён; NOT_APPLICABLE_WITH_REASON — пункт неприменим и причина записана. Для каждого пункта храните дату, владельца, ссылку на безопасное место с доказательством и дату следующей проверки. Самоутверждение без артефакта считается UNKNOWN.

Контроль	Что проверить	Допустимое доказательство	Результат
Доступы	У каждого критичного сервиса есть владелец, резервный администратор и отдельные учётные записи	Экспорт списка ролей без секретов, дата ревизии, заявка на отзыв доступа	PASS / FAIL / UNKNOWN / N/A
MFA	Второй фактор включён для почты, домена, облака, финансов и администраторов	Скриншот политики или отчёт провайдера без резервных кодов	PASS / FAIL / UNKNOWN / N/A
Резервные копии	Копия отделена от основной среды и восстановлена на тестовой площадке	Протокол последнего восстановления: объект, дата, длительность, результат	PASS / FAIL / UNKNOWN / N/A
Устройства	Поддерживаемые версии, обновления, шифрование и блокировка экрана контролируются	Отчёт управления устройствами либо подписанный журнал выборочной проверки	PASS / FAIL / UNKNOWN / N/A
Инцидент	Есть контакты, порядок изоляции и чистый канал связи	Карточка инцидента и результат настольной тренировки	PASS / FAIL / UNKNOWN / N/A

Доступы: уберите общие аккаунты и одиноких администраторов

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

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

Где MFA ставить первой

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

Резервная копия считается только после восстановления

Запись «backup включён» не отвечает на главный вопрос: можно ли вернуть нужные данные в приемлемый срок. Укажите, какие объекты копируются, как часто, сколько версий хранится, кто получает сигнал об ошибке и где находится копия. Хотя бы одна копия должна быть недоступна теми же учётными данными, которыми управляется рабочая среда; иначе одна компрометация может затронуть и оригинал, и резерв.

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

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

Устройства: поддерживаемость важнее количества программ

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

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

Почта, домен и облако: один сбой не должен отдавать всё

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

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

Карточка первых действий при инциденте

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

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

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

Персональные данные: технический список не заменяет правовую обязанность

Статья 19 закона №152-ФЗ устанавливает обязанность оператора применять правовые, организационные и технические меры защиты персональных данных. Нельзя вывести соответствие закону из факта установки одного продукта. Сначала определяют роли оператора, состав обработки, системы, угрозы и применимые нормативные требования, затем документируют меры и контроль. Для конкретной организации нужна актуальная правовая и техническая оценка.

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

План на семь рабочих дней

День	Работа	Проверяемый результат
1	Назначить владельцев почты, домена, банка, CRM, облака и резервирования	Реестр критичных активов без секретов
2	Сверить администраторов, внешние доступы и пути восстановления	Список отзывов и UNKNOWN-пунктов
3	Включить MFA на приоритетных аккаунтах	Отчёт провайдера без резервных кодов
4	Проверить устройства и поддерживаемые версии	Инвентаризация и план обновлений
5	Восстановить один критичный набор из копии	Протокол теста и исправления
6	Собрать карточку инцидента и независимые контакты	Доступный офлайн экземпляр
7	Провести настольную тренировку и назначить повторную ревизию	Журнал пробелов с владельцами и сроками

После недели не объявляйте безопасность «готовой». Переведите проверки в ритм: отзыв доступов по событию, ежемесячный просмотр критичных сигналов, квартальная ревизия ролей, регулярное восстановление и тренировка после существенных изменений. Метрика — не количество закупленных лицензий, а доля контролей с актуальными доказательствами и время закрытия FAIL/UNKNOWN.

Когда нужен внешний специалист

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

Практический следующий шаг

Сегодня выберите пять критичных активов и заполните первые две строки чек-листа: доступы и резервное восстановление. Любой ответ без артефакта пометьте UNKNOWN, назначьте владельца и дату проверки. Через семь дней повторно посчитайте только подтверждённые результаты. Такой цикл не обещает отсутствия атак, но создаёт наблюдаемую управляемость и уменьшает зависимость от памяти одного человека.