Политики и процедуры информационной безопасности
В этой главе — три основополагающих документа: политика допустимого использования (что сотрудникам можно и нельзя), план реагирования на инциденты (что делать, когда что-то пошло не так) и политика классификации данных (как обращаться с разными видами информации). Все три — с готовыми шаблонами, которые можно адаптировать за один рабочий день. Не рамочные документы, требующие комитета и полугода согласований, — а рабочие инструменты.
Лидер безопасности — сотрудник, который берёт на себя вопросы информационной безопасности в команде как дополнительную зону ответственности. Далее по тексту — «лидер безопасности».
Зачем политики нужны малому бизнесу
«Нас 20 человек, все друг друга знают» — работает ровно до первого инцидента. Почему письменные политики важны:
Сотрудники приходят и уходят. Знания «как у нас принято» существуют только в головах и исчезают при увольнении. Новый человек не знает, что считается нормой, пока кто-то не объяснил или не нарушил.
Инциденты случаются внезапно. Когда в 2 ночи взломали сервер, времени думать, кому звонить и что сохранять, нет. Нужен план, который работает на автопилоте.
Юридическая защита. Если сотрудник сделал что-то недопустимое, а письменного запрета не было — доказать умысел или халатность значительно сложнее. Политика фиксирует, что человек был ознакомлен с правилами.
Требования клиентов и партнёров. B2B-клиенты (особенно корпоративные) всё чаще запрашивают политики безопасности при заключении договоров. Наличие реальных документов, а не «мы следим за безопасностью», помогает выиграть сделку.
Требования страховщиков. Кибер-страхование становится дороже и требует документально подтверждённых политик. Без них — повышенный тариф или отказ в выплате.
Соответствие 152-ФЗ. Если компания обрабатывает персональные данные, письменные организационные меры защиты — не рекомендация, а требование закона (приказ ФСТЭК России № 21).
Цель — не бюрократия, а ясные ответы на типовые вопросы, чтобы не изобретать велосипед каждый раз.
Принципы эффективной политики
Краткость важнее полноты
Политику, которую никто не читает, лучше не писать вовсе — она создаёт ложное ощущение защищённости.
Ориентиры по объёму:
- Политика допустимого использования: 2–3 страницы
- План реагирования на инциденты: 3–5 страниц
- Классификация данных: 1–2 страницы
Простой язык — не упрощение
Пишите для реальных сотрудников, а не для аудиторов.
ПЛОХО: «Сотрудники обязаны воздерживаться от использования
корпоративных вычислительных ресурсов в целях, не связанных
непосредственно с авторизованной производственной деятельностью.»
ХОРОШО: «Не используйте рабочий компьютер для личных дел,
которые могут навредить компании: пиратское ПО,
неприемлемый контент, параллельный бизнес.»
Понятные последствия
Расплывчатые угрозы не работают. Будьте конкретны:
ПЛОХО: «Нарушение политики влечёт дисциплинарные меры.»
ХОРОШО: «Первое нарушение: устное предупреждение + обязательный инструктаж.
Повторное нарушение: письменный выговор в личное дело.
Серьёзные нарушения (утечка данных, заражение вирусом):
возможно немедленное увольнение.»
Объясняйте «почему»
Люди соблюдают правила, которые понимают:
ПЛОХО: «Личные устройства не подключать к корпоративной сети.»
ХОРОШО: «Личные устройства не подключаются к корпоративной сети,
потому что мы не можем проверить их безопасность.
Заражённый личный телефон — один из самых частых способов
проникновения в корпоративную инфраструктуру.
Для личных нужд используйте гостевой Wi-Fi.»
Документируйте исключения
У каждого правила есть исключения. Пропишите их — иначе сотрудники придумают свои:
Правило: Программное обеспечение устанавливается только после согласования.
Исключение: Разработчики могут устанавливать пакеты через npm/pip/cargo для рабочих проектов без предварительного согласования. Пакеты в производственных сборках должны проверяться на уязвимости.
Где искать образцы и шаблоны
Не нужно начинать с нуля. В России и на международном уровне есть открытые материалы, пригодные как отправная точка.
Российские регуляторные документы
| Источник | Что даёт | Применимость |
|---|---|---|
| ФСТЭК России (fstec.ru) | Приказы № 17, 21, 239 — меры защиты для ГИС, ПДн, КИИ; методические документы по классификации | Обязательны для регулируемых сфер; полезны всем как структура мер защиты |
| НКЦКИ (cert.gov.ru) | Рекомендации по реагированию на инциденты, оповещению, взаимодействию с ГосСОПКА | Золотой стандарт для плана реагирования в российском контексте |
| Банк России (cbr.ru) | Положения 683-П, 719-П, 802-П; ГОСТ Р 57580.1 — для финансовых организаций | Финансовый сектор и компании, работающие с банковскими картами |
| ГОСТ Р ИСО/МЭК 27001-2021 | Система менеджмента информационной безопасности (СМИБ) — полная методология | Для компаний, готовящихся к аттестации или сертификации |
Быстрый старт: минимальный набор политик
Если нужны документы немедленно и ресурсы ограничены:
1. Политика допустимого использования (2–3 часа)
- Возьмите шаблон из этой главы за основу
- Замените плейсхолдеры на реальные данные компании
- Уберите неприменимые разделы
- Добавьте специфику своих инструментов и процессов
- Итерируйте после первых инцидентов
2. План реагирования на инциденты (3–4 часа)
- Определите команду реагирования и роли
- Адаптируйте шаблон из этой главы под структуру компании
- Добавьте актуальные контакты
- Согласуйте с руководством
- Протестируйте в виде учебной тревоги
3. Классификация данных (1–2 часа)
- Используйте 4-уровневую схему: Публичные / Внутренние / Конфиденциальные / Ограниченного доступа
- Для каждого уровня — 3–5 примеров из вашей реальной деятельности
- Определите, где каждый уровень может храниться
Двухстраничная политика, которую все подписали и соблюдают, лучше двадцатистраничного документа, который лежит в папке. Выпустите версию 1.0 быстро, а потом улучшайте.
Что происходит без политик: российские сценарии
Это не запугивание — это уроки, которые компании получают дорогой ценой.
Нет плана реагирования на инциденты
Сценарий — логистическая ИТ-компания, ~60 человек. В пятницу вечером обнаружили, что база данных клиентов доступна извне через открытый порт. Несколько часов ушло на выяснение, кто вообще должен принимать решения, кому звонить, нужно ли уведомлять клиентов. Данные успели скопировать — об этом узнали из сообщения на тематическом форуме.
Итог: уведомление Роскомнадзора (152-ФЗ обязывает это сделать в течение 24 часов после обнаружения факта утечки персональных данных), потеря нескольких клиентов, внеплановые работы команды в выходные. Письменный план с чёткими ролями позволил бы начать реагирование на час–два раньше и сохранить контроль над ситуацией.
Что изменил бы ПРИ (план реагирования на инциденты): Чёткие роли, алгоритм первых 30 минут, шаблон уведомления для Роскомнадзора — всё это было бы готово заранее.
Нет политики допустимого использования
Сценарий — дизайн-студия, 25 человек. Сотрудник использовал корпоративную почту для регистрации на сомнительном сервисе. Пароль — тот же, что от рабочей учётки. Когда сервис взломали, атакующие получили доступ к корпоративной почте. Оттуда от имени руководителя попросили бухгалтерию срочно перевести оплату «поставщику».
Политика допустимого использования с явным запретом использовать корпоративную почту для личных регистраций и правилом уникальных паролей закрыла бы эту цепочку.
Нет классификации данных
Сценарий — небольшой ретейлер, интернет-магазин. При миграции между хостинг-провайдерами технический специалист случайно сделал папку с резервными копиями публично доступной. В копиях — данные 8 000 покупателей: имена, адреса, номера телефонов. Ни специалист, ни руководство не понимали, насколько это критично, пока ситуация не стала публичной.
Классификация данных с явным правилом «резервные копии баз с ПДн = ограниченный доступ, шифрование обязательно» исключила бы неопределённость.
Общая закономерность: компании без письменных политик принимают худшие решения в стрессовой ситуации, реагируют дольше и получают более тяжёлые последствия — в том числе регуляторные.
Политика допустимого использования (ПДИ)
Определяет, что сотрудники могут и не могут делать с корпоративными ресурсами: компьютерами, сетью, почтой, облачными сервисами и данными. Фундамент всех остальных политик.
Что включить
- Цель и область применения — на кого распространяется, какие ресурсы охватывает
- Общие принципы — профессионализм, запрет незаконных действий
- Учётные записи и пароли — требования к паролям, МФА, запрет передачи реквизитов
- Почта и коммуникации — деловое использование, осторожность с вложениями
- Интернет и социальные сети — что допустимо в рабочее время
- Программное обеспечение — что можно устанавливать, процедура согласования
- Личные устройства (BYOD) — условия доступа к корпоративным данным
- Обращение с данными — как обращаться с корпоративными и клиентскими данными
- Удалённая работа — VPN, публичный Wi-Fi, физическая безопасность дома
- Мониторинг и конфиденциальность — что компания отслеживает, права сотрудника
- Сообщение о нарушениях — как сообщать, защита от преследования
- Последствия — что происходит при нарушении
Шаблон политики допустимого использования
Готовый шаблон покрывает учётные записи и пароли, почту, интернет, установку ПО, личные устройства (BYOD), удалённую работу, мониторинг и последствия нарушений. Заполните разделы в квадратных скобках под вашу компанию.
Все шаблоны этой главы — в библиотеке шаблонов.
Типичные ошибки при создании ПДИ
| Ошибка | Почему опасно | Решение |
|---|---|---|
| Копирование корпоративных шаблонов | Слишком сложно, не соответствует вашей реальности | Пишите с нуля, коротко |
| Нет механизма исполнения | Политика превращается в рекомендацию | Определите конкретные последствия и выполняйте их |
| Устаревшие технологии | Политика описывает мир, которого нет | Обновляйте ежегодно под реальный стек |
| Чрезмерная строгость | Люди обходят правила, которые мешают работать | Балансируйте безопасность и удобство |
| Нет процедуры исключений | Сотрудники игнорируют неисполнимые правила | Пропишите, как запросить исключение |
| Юридический язык | Никто не читает | Пишите для людей, а не для юристов |
План реагирования на инциденты (ПРИ)
Когда что-то идёт не так — шифровальщик, утечка данных, скомпрометированная учётная запись — нужен план. ПРИ говорит всем, что именно делать. Не стратегия — чек-лист для кризиса.
Почему ПРИ нужен до инцидента
Во время инцидента вы будете в стрессе, с дефицитом сна, принимая быстрые решения. Худшее время, чтобы думать:
- Кто за что отвечает?
- Кому звонить снаружи?
- Что говорить клиентам?
- Сохраняем ли мы доказательства правильно?
Пишите ПРИ в спокойной обстановке. Следуйте ему в панике.
Структура ПРИ
- Классификация инцидентов — что считается инцидентом, уровни критичности
- Команда реагирования и роли — кто что делает
- Обнаружение и сообщение — как мы узнаём об инцидентах
- Локализация — остановить распространение, изолировать затронутые системы
- Расследование — выяснить, что произошло
- Устранение и восстановление — убрать угрозу, вернуть нормальную работу
- Коммуникация — внутри компании, с клиентами, с регуляторами
- Разбор после инцидента — извлечь уроки
- Список контактов — все, кому может понадобиться позвонить
Шаблон плана реагирования на инциденты
Готовый шаблон покрывает все 9 разделов структуры выше: роли и команду реагирования, первые 30 минут, локализацию, расследование, устранение и восстановление, коммуникации с клиентами и регуляторами, разбор после инцидента и список контактов. Внутри — три готовых встроенных шаблона: журнал инцидента, уведомление клиента и постмортем.
Общий процесс описан в ПРИ, а пошаговые действия для четырёх самых частых типов инцидентов — в главе плейбуки реагирования.
Политика классификации данных
Классификация данных объясняет сотрудникам, как обращаться с разными видами информации. Без неё люди либо защищают всё одинаково строго (неэффективно), либо не защищают ничего (опасно).
Зачем классифицировать данные?
- Концентрация усилий — не все данные требуют одинаковой защиты
- Чёткие правила — сотрудники знают, что можно и нельзя
- Соответствие требованиям — 152-ФЗ и другие нормы требуют разграничения
- Реагирование на инциденты — сразу понятно, насколько серьёзна утечка
Простая схема классификации
Для малого бизнеса достаточно трёх-четырёх уровней:
| Уровень | Описание | Примеры |
|---|---|---|
| Публичные | Можно свободно распространять | Маркетинговые материалы, публичный сайт, открытый код |
| Внутренние | Только для сотрудников | Внутренняя вики, оргсхема, общие политики |
| Конфиденциальные | Чувствительная бизнес-информация | Финансовые данные, стратегические планы, кадровые данные, списки клиентов |
| Ограниченного доступа | Максимальная защита | Персональные данные клиентов (ПДн), реквизиты доступа, ключи шифрования, платёжные данные |
Шаблон политики классификации данных
Готовый шаблон описывает все 4 уровня чувствительности (публичные, внутренние, конфиденциальные, ограниченного доступа), правила обращения по каждому уровню, обращение по каналам и сроки хранения/уничтожения.
Все шаблоны этой главы — в библиотеке шаблонов.
См. также
- Плейбуки реагирования — пошаговые действия при инциденте
- Внедрение политик — как внедрить написанное
- Соответствие требованиям — какие документы требует регулятор
Что дальше
Три документа написаны. Следующая глава — плейбуки реагирования: пошаговые действия для четырёх самых частых типов инцидентов, которые дополняют план реагирования.