Минимальная киберзащита небольшой команды

«Минимальная» не означает одинаковая для любой компании. Платежи, медицинские сведения, госзаказы, критическая инфраструктура и договорные требования могут требовать дополнительных мер. NIST CSF 2.0 предлагает управлять риском, а quick-start guide помогает начать организации с ограниченным планом; это не сертификат и не фиксированный каталог средств. Цель этой статьи — создать видимый базовый контур, который команда действительно поддерживает.

Потратьте первые 60–90 минут на один реестр и четыре решения: кто отвечает за почту, домен, файлы и платежи; какие устройства используются для работы; кто имеет административные права; что будет отключено при уходе человека. Если ответ хранится только в памяти основателя, система не управляется. Не вносите в реестр пароли, recovery-коды, полные токены и лишние персональные данные.

Единый контур: люди, устройства, доступы и данные

Создайте четыре связанные сущности. Человек получает индивидуальный аккаунт и роль. Устройство имеет владельца, supported status и набор рабочих данных. Аккаунт связан с сервисом, владельцем сервиса, recovery и администраторскими правами. Набор данных имеет бизнес-владельца, допустимых пользователей и способ восстановления. Связь позволяет ответить: что отключать при уходе, кому сообщать об инциденте и кто принимает restore test.

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

Аккаунты: индивидуальность, минимальные роли и MFA

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

Приоритет MFA: основная почта, файловое хранилище, удалённый доступ, домен, платежи и административные панели. Выбирайте наиболее сильный поддерживаемый метод; phishing-resistant passkey или аппаратный ключ предпочтительнее ручного кода, если сервис и recovery действительно проверены. Для подробной процедуры настроить систему паролей, passkey и MFA. Не делите один второй фактор между всеми сотрудниками без документированного владельца и причины.

Если shared account технически неизбежен, запишите владельца, список допущенных людей, способ MFA и recovery, правила использования и действие при смене роли. Такой режим не обеспечивает прослеживаемость индивидуального аккаунта. По возможности замените общий логин delegated access или ролями сервиса. Не передавайте пароль в чат и не храните его в общей незашифрованной таблице.

Устройства: поддержка важнее списка антивирусов

В реестр входят корпоративные и личные устройства, если с них открываются рабочая почта, файлы или административные панели. Для каждого отметьте supported OS, автоматические security updates, блокировку экрана, шифрование при поддержке, установленный рабочий scope и дату проверки. Неподдерживаемая ОС не становится безопасной из-за одного защитного продукта; запланируйте обновление или вывод устройства.

• Включите автоматические security updates там, где это совместимо с рабочим процессом, и назначьте контроль исключений.

• Удалите ненужные приложения и расширения, особенно имеющие доступ к рабочим данным.

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

• Определите, какие данные разрешены на личном устройстве и как отделяется частная информация.

• Запишите процедуру возврата, переназначения или безопасной утилизации корпоративного устройства.

BYOD требует прозрачной границы. Команда должна заранее объяснить, какие меры обязательны, что именно администратор может видеть, допускается ли удалённое стирание рабочего контейнера и что происходит при уходе. Скрытый мониторинг и попытка стереть личное устройство целиком недопустимы как технический default. Политику согласуют с трудовыми, правовыми и privacy требованиями.

Данные, копии и платёжные изменения

Для важных данных укажите владельца, место, допустимые роли и recovery. Наличие облака не заменяет backup автоматически. Определите scope, изоляцию и пробное восстановление, а затем рассчитать объём и расписание резервных копий. Журнал backup job без restore test не доказывает, что команда вернёт процесс после удаления, ransomware или блокировки аккаунта.

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

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

Чек-лист устройств, доступов и увольнения сотрудников

Уникальный инструмент состоит из трёх связанных таблиц и ритма контроля. Таблицы не должны дублировать HR-досье и не хранят secrets. Они фиксируют operational minimum: какое устройство и доступ связаны с человеком, кто владеет сервисом, какой recovery path существует и какое действие выполняется к согласованному моменту смены роли.

Таблица A. Устройства

Таблица B. Доступы

Таблица C. Смена роли или увольнение

Не назначайте универсальные «24 часа» или «48 часов» без контекста. Доступ прекращается к согласованному моменту, когда он больше не нужен, с учётом HR, legal и безопасности. Для срочного инцидента время может быть немедленным; для плановой передачи работы нужны заранее подготовленные владельцы. Точное решение принимает уполномоченная сторона, а не автор таблицы.

• Согласовать момент прекращения доступа и назначить координатора.

• Отключить индивидуальные аккаунты и удалить пользователя из групп и shared-access lists.

• Передать владельца файлов, доменов, интеграций, соцсетей и автоматизаций уполномоченному человеку.

• Завершить доступные сессии и отозвать app passwords или tokens по официальной инструкции сервиса.

• Обновить shared credentials, если от общего аккаунта пока нельзя отказаться.

• Вернуть корпоративное устройство и выполнить согласованное переназначение либо безопасную очистку.

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

• Записать исполнителя, время, результат и открытые исключения без секретов.

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

Таблица D. Ритм контроля

Карточка инцидента без собственного SOC

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

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

Что не входит в обещание baseline

CIS IG1 можно использовать как cross-check essential cyber hygiene, но галочки не доказывают compliance или безопасность. Команда с публичным API, производством, медицинскими данными или высоким объёмом платежей может нуждаться в централизованных логах, MDM, vulnerability management, сегментации, тестировании, формальном incident response и внешней экспертизе. Выбор идёт от реальных рисков и требований.

Шифрование, remote wipe, session revocation и backup isolation различаются по платформам. Проверяйте официальную документацию конкретной версии. Не заявляйте, что любое MFA остановит все атаки, любой антивирус очистит устройство или один training исключит фишинг. Минимальная система снижает вероятность и последствия, но оставляет residual risk, который владельцы должны видеть и принимать осознанно.

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

Сегодня создайте по пять строк в таблицах устройств и доступов. Начните с основной почты, файлов, домена, платежей и одного рабочего приложения. Для каждой строки назначьте owner, пользователя, роль, admin status, MFA method без secret и exit action. Затем выберите одного человека и мысленно проведите offboarding: какие файлы, группы, сессии, tokens и устройства останутся без владельца?

Исправьте сначала сиротские admin-права, неподдерживаемые устройства и доступы бывших участников. Назначьте дату выборочной проверки и проведите короткое упражнение по неизвестному входу. Если таблица не отвечает на вопрос «кто и что делает сейчас», не покупайте следующий security product ради ощущения прогресса. Сначала доведите базовый контур до состояния, где каждая критичная строка имеет владельца, recovery и проверяемое действие.

Что читать дальше

• настроить систему паролей, passkey и MFA

• рассчитать объём и расписание резервных копий

• восстановить критичные аккаунты после компрометации