Политики безопасности: три шаблона для офиса

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

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

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

Почему документ, а не настройка

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

Второй аргумент — доказательность. Аудитор по ISO 27001 или SOC 2 смотрит не только на конфигурацию, но и на то, что требования существуют, утверждены, доведены до людей и пересматриваются. Если всё сделано правильно, но предъявить нечего, зачёт не получится.

Что должно быть в каждом документе

Шаблон политики — не только список запретов. Минимальный набор полей одинаков для всех трёх документов: владелец (конкретная должность, а не «отдел ИТ»), версия и дата утверждения, область действия, срок следующего пересмотра, порядок ознакомления и последствия нарушения.

Владелец — ключевое поле. Документ без владельца устаревает за один квартал: меняется подрядчик, появляется новый сервис, и старое правило начинает противоречить реальности. На практике владельцем становится операционный директор или руководитель ИТ; важно, чтобы у него было право утверждать изменения, а не только собирать замечания.

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

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

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

Что стоит зафиксировать:

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

Отдельный пункт — уведомление о мониторинге. Если компания смотрит журналы и трафик, это должно быть написано прямо: скрытый контроль разрушает доверие сильнее, чем объявленный.

Политика личных устройств: как пустить телефон в рабочий контур

Личные устройства уже в контуре, вопрос лишь в том, управляются ли они. По отраслевым данным, около 70% таких устройств не находятся под управлением, а 22% хотя бы раз в месяц подключаются к небезопасной сети Wi-Fi. Запрет «только корпоративная техника» в компании из двадцати человек не работает: почту с телефона проверяют всё равно, просто молча.

Работающая политика строится на условиях доступа, а не на запрете:

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

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

Политика паролей: что действительно изменилось

Требование менять пароль каждые 90 дней устарело. Современные рекомендации NIST SP 800-63B прямо не советуют принудительную ротацию без признаков компрометации: человек добавляет единицу в конец, записывает новый вариант на стикер и считает, что стал защищённее.

Актуальная политика выглядит иначе:

минимальная длина — 12–15 символов, приветствуются парольные фразы из нескольких слов;
требования к набору категорий символов не нужны, длина важнее;
проверка по списку скомпрометированных паролей при смене;
запрет контрольных вопросов как способа восстановления доступа;
обязательная MFA для почты, VPN, админ-панелей и облачных сервисов;
хранение только в менеджере паролей, отдельная запись на каждый сервис.

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

Кто утверждает и когда пересматривать

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

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

Как внедрить за первый месяц

Первая неделя — назначить владельца и адаптировать тексты под свои сервисы: вычеркнуть пункты про системы, которых нет, добавить названия своих облачных хранилищ и способ сообщить об инциденте.

Вторая — провести брифинг на 30 минут и собрать подписи. Не пересказ документа, а три-четыре реальных случая: письмо «от руководителя» с просьбой оплатить счёт, потерянный телефон, ссылка на общий диск.

Третья — включить ограничения, на которые политика ссылается: MFA, регистрацию устройств, запрет внешнего автоперенаправления почты. Правило без поддержки настройкой живёт неделю.

Четвёртая — выборочная проверка: десять случайных записей на наличие MFA и список устройств против MDM. Результат стоит записать, чтобы через полгода было с чем сравнить.

Ошибки, из-за которых политики не работают

Юридический язык. Двадцать страниц формулировок не читает никто.
Запрет без последствий. Правило без описанной эскалации остаётся пожеланием.
Устаревшие требования к паролям. Ротация каждые 90 дней снижает стойкость, а не повышает.
Отсутствие владельца. Документ живёт до первого изменения в инфраструктуре.

Как проверить, что документ работает

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

Полезно связать политику с процедурой увольнения: именно там обнаруживаются забытые доступы. Готовый порядок — в чек-листе по безопасности при увольнении. А настройки, которых политика требует, перечислены в чек-листе по Microsoft 365.

Итог

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

Частые вопросы

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

Обязательно ли менять пароль каждые 90 дней? Нет. Принудительная ротация без признаков компрометации даёт предсказуемые и слабые пароли. Менять пароль нужно при подозрении на утечку или по указанию ИТ после инцидента.

Что делать, если сотрудник отказывается ставить MDM на личный телефон? Предложить альтернативу: корпоративное устройство или веб-доступ без локального хранения данных. Отказ без альтернативы почти всегда заканчивается обходом правил.

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

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

Если нужно привести документы в соответствие с реальной инфраструктурой — Связаться с командой.

Шаблоны политик безопасности для малого бизнеса