Политика ИБ для корпоративного мессенджера: шаблон и гайд

У 80% компаний, которые используют корпоративный мессенджер, нет отдельного документа, регулирующего его использование с точки зрения информационной безопасности. Мессенджер есть, правила ИБ есть, а связки между ними — нет.

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

Этот гайд — для CISO, IT-директоров и руководителей, которые хотят навести порядок. Внутри — конкретная структура документа, примеры формулировок и готовый шаблон, который можно адаптировать под свою компанию.

Зачем нужна отдельная политика для мессенджера

«У нас уже есть общая политика ИБ, зачем ещё одна?» — справедливый вопрос. Ответ: потому что мессенджер отличается от остальных корпоративных систем по нескольким параметрам.

Мессенджер — самый используемый инструмент

Среднестатистический сотрудник проводит в мессенджере 2,5–3 часа в день (данные RescueTime). Это больше, чем в почте, CRM или таск-трекере. Через мессенджер проходит 70–80% оперативных коммуникаций. Это основной канал, через который информация создаётся, передаётся и хранится.

Мессенджер — неформальная среда

В почте люди пишут «Уважаемый Иван Петрович, прошу согласовать...». В мессенджере — «Вань, глянь документ, ок?». Неформальность снижает бдительность. Сотрудник, который никогда не отправит конфиденциальный файл по почте, легко кинет его в чат — «ну это же внутренний канал».

Мессенджер работает на личных устройствах

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

Мессенджер хранит историю

В отличие от звонка, сообщение в чате сохраняется навсегда (если не настроена политика удаления). Переписка за 3 года — это терабайты текста, файлов, ссылок, персональных данных. Всё это — объект регулирования, и обращаться с этим нужно аккуратно.

Типичные инциденты

Из реальной практики (компании обезличены):

• Сотрудник уволился, но остался в 12 рабочих чатах ещё 3 месяца — никто не проверил.
• Менеджер переслал клиентский договор с персональными данными в чат «Продажи», где 45 человек. Среди них — стажёр, который ушёл через неделю.
• Разработчик отправил API-ключ production-среды в чат техподдержки. Ключ провисел 2 недели, пока не заметили.
• При аудите ISO 27001 компания не смогла показать аудит-логи мессенджера за последние 6 месяцев — потому что использовала Telegram, где логов нет.

Все эти инциденты можно было предотвратить документом на 5 страниц и 30 минутами настройки мессенджера.

Требования регуляторов

ФЗ-152 «О персональных данных»

Если через мессенджер передаются персональные данные (а они передаются — имена, телефоны, email, сканы документов), компания обязана:

• Обеспечить хранение ПДн на территории РФ (ч. 5 ст. 18). Telegram хранит данные за рубежом — формально это нарушение.
• Принять организационные и технические меры защиты (ст. 19). Политика использования мессенджера — это организационная мера.
• Обеспечить конфиденциальность ПДн (ст. 7). Мессенджер без контроля доступа — риск нарушения конфиденциальности.
• Уведомить Роскомнадзор об инциденте с ПДн в течение 24 часов (с 2025 года). Для этого нужна процедура выявления инцидентов — без аудит-логов мессенджера вы можете не узнать об утечке вовремя.

Оборотные штрафы за утечку ПДн (от 1% до 3% годовой выручки, введены в 2025 году) делают вопрос финансово значимым для любого бизнеса.

Приказы ФСТЭК (17, 21, 239)

Для государственных информационных систем и систем, обрабатывающих ПДн, ФСТЭК устанавливает требования к:

• Идентификации и аутентификации пользователей (ИАФ).
• Управлению доступом (УПД).
• Регистрации событий безопасности (РСБ) — те самые аудит-логи.
• Защите информации при передаче (ЗИС) — шифрование.
• Контролю целостности (ОЦЛ).

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

ISO 27001

Стандарт требует документированные политики для всех значимых систем обработки информации. Мессенджер — одна из таких систем. При сертификации аудитор спросит: «Есть ли у вас политика использования мессенджера? Как контролируется доступ? Как обрабатываются инциденты?» Без документа — несоответствие.

8 разделов документа

Хорошая политика ИБ для мессенджера — это 5–8 страниц. Не 30 — пять. Если документ длиннее, его не прочитает никто, включая автора. Вот структура, которая работает.

Раздел 1: Цель и область применения

Одна страница. Зачем нужен документ, на кого распространяется, какой мессенджер регулирует. Пример формулировки:

Настоящая политика устанавливает правила использования корпоративного мессенджера [название] в ООО «Компания». Политика распространяется на всех сотрудников, подрядчиков и временный персонал, имеющих доступ к мессенджеру. Цель — защита корпоративной информации, соответствие требованиям ФЗ-152 и минимизация рисков утечки данных.

Раздел 2: Классификация информации

Какие категории данных существуют и что можно/нельзя передавать через мессенджер. Подробнее — в следующем разделе статьи.

Раздел 3: Управление учётными записями

Создание, деактивация, требования к паролям, 2FA. Подробнее — в разделе «Управление доступом».

Раздел 4: Правила использования

Что можно и что нельзя делать в мессенджере. Конкретные запреты и разрешения. Примеры:

• Запрещается передавать пароли и ключи доступа через мессенджер.
• Запрещается пересылать рабочие сообщения и файлы в личные мессенджеры.
• Запрещается обсуждать данные, классифицированные как «Строго конфиденциально», в групповых каналах.
• Допускается использование мессенджера на личных устройствах при условии установки PIN-кода / биометрической защиты на устройстве.
• При обнаружении конфиденциальной информации в открытом канале — немедленно сообщить администратору.

Раздел 5: Управление каналами и группами

Кто может создавать каналы, как именовать, кто отвечает за состав участников. Это кажется мелочью, но хаос из 200 каналов без ответственных — типичная ситуация.

Раздел 6: Хранение и удаление данных

Сроки хранения, политика ротации, бэкапы. Подробнее — в разделе «Хранение, ротация и бэкапы».

Раздел 7: Мониторинг и аудит

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

Раздел 8: Реагирование на инциденты

Что делать при утечке, компрометации аккаунта, обнаружении несанкционированного доступа. Подробнее — в разделе «Действия при инциденте».

Классификация информации

Без классификации любая политика — пустые слова. Сотрудник должен понимать: «Этот файл можно отправить в общий канал. А этот — только в личное сообщение конкретному человеку. А этот — вообще нельзя через мессенджер».

Четыре уровня

Стандартная классификация для большинства компаний:

1. Открытая информация. Маркетинговые материалы, публичные анонсы, информация с сайта компании. Можно передавать через любой канал.
2. Внутренняя информация. Рабочие обсуждения, внутренние новости, процессные документы. Передача только через корпоративный мессенджер, не подлежит пересылке за периметр.
3. Конфиденциальная информация. Финансовые отчёты, персональные данные сотрудников и клиентов, условия контрактов, техническая документация. Передача только в защищённых каналах с ограниченным доступом. Запрет на хранение на личных устройствах.
4. Строго конфиденциальная информация. Коммерческая тайна, ключи шифрования, пароли от критических систем, данные о слияниях/поглощениях. Передача через мессенджер запрещена. Только личные встречи или специализированные системы.

Как определить уровень

Простой тест: «Что случится, если эта информация окажется у конкурента или в открытом доступе?»

• Ничего страшного — открытая.
• Неприятно, но не критично — внутренняя.
• Финансовые потери или юридические последствия — конфиденциальная.
• Угроза существованию бизнеса — строго конфиденциальная.

Практическая реализация в мессенджере

Как это работает технически:

• Каналы маркируются по уровню конфиденциальности (в названии или описании).
• Доступ к каналам уровня «Конфиденциально» — только по заявке через руководителя.
• DLP-система мессенджера автоматически блокирует пересылку сообщений из конфиденциальных каналов за периметр.
• Файлы с грифом «Конфиденциально» не скачиваются на мобильные устройства (если это поддерживает мессенджер).

Управление доступом

Жизненный цикл учётной записи

Каждая учётная запись проходит четыре стадии:

1. Создание. При приёме на работу IT-отдел создаёт учётную запись в мессенджере. Идеально — через LDAP/Active Directory, чтобы одна учётка давала доступ ко всем системам. Учётная запись сразу включается в каналы, соответствующие отделу и роли сотрудника.
2. Использование. Сотрудник работает, получает/теряет доступ к каналам при смене проекта или должности. Каждое изменение — по заявке через руководителя.
3. Блокировка. При увольнении — немедленная деактивация. Не «когда HR дойдёт до IT-отдела», а в день увольнения, в течение часа. Автоматизируйте: увольнение в HR-системе триггерит блокировку в мессенджере.
4. Удаление. Через установленный срок (30–90 дней после блокировки) учётная запись удаляется. Данные архивируются в соответствии с политикой хранения.

Аутентификация

Минимальные требования:

• Пароль: не менее 12 символов, буквы (верхний и нижний регистр), цифры, спецсимволы. Смена каждые 90 дней. Запрет использования 5 последних паролей.
• Двухфакторная аутентификация (2FA): обязательна для всех. TOTP (Google Authenticator, Яндекс.Ключ) или аппаратный ключ (YubiKey, Рутокен). SMS-код — допустим как запасной вариант, но не как единственный фактор (уязвим для SIM-свопинга).
• SSO (Single Sign-On): рекомендуется для компаний от 100 сотрудников. Снижает количество паролей и упрощает управление.

Принцип минимальных привилегий

Сотрудник получает доступ только к тем каналам, которые нужны для его работы. Не больше. Распространённая ошибка — добавить нового человека во все каналы «на всякий случай». Через полгода у стажёра есть доступ к каналу совета директоров, потому что его туда добавили «по ошибке» и забыли удалить.

Рекомендуемая практика: ежеквартальный ревью доступов. IT-отдел отправляет руководителю отдела список сотрудников и их каналов. Руководитель подтверждает или корректирует.

Хранение, ротация и бэкапы

Сроки хранения

Определите, сколько хранить переписку. Нет универсального ответа — зависит от отрасли и регулятора:

• Банки и финансовые организации: 5 лет (требования ЦБ РФ).
• Медицинские организации: 25 лет для медицинских данных.
• Обычные компании: 1–3 года — разумный срок. Дольше — растёт объём хранилища и риски при утечке.
• Персональные данные: хранить только пока есть основание (ФЗ-152, ст. 5). Если сотрудник уволился — ПДн в его переписке должны быть удалены или обезличены в течение 30 дней.

Ротация данных

Настройте автоматическое удаление сообщений по истечении срока хранения (retention policy). Большинство корпоративных мессенджеров поддерживают эту функцию. Например, в b8q можно задать политику удаления отдельно для каждого канала: рабочие обсуждения — 1 год, канал инцидентов — 3 года, оффтоп — 30 дней.

Бэкапы

Правила бэкапирования мессенджера:

• Частота: ежедневно для базы данных, еженедельно для файлового хранилища.
• Хранение: 3-2-1 (три копии, два носителя, одна за пределами площадки).
• Шифрование: бэкапы шифруются тем же уровнем, что и исходные данные. Незашифрованный бэкап — это утечка, ожидающая своего часа.
• Тестирование: ежеквартальное восстановление из бэкапа на тестовом сервере. Если не тестируете — считайте, что бэкапа нет.
• Доступ: к бэкапам имеют доступ только администраторы системы (не более 2–3 человек). Каждый доступ логируется.

Удаление на устройствах

Если мессенджер поддерживает MDM (Mobile Device Management) или удалённое стирание, настройте:

• Автоматическое стирание данных мессенджера при деактивации учётной записи.
• Возможность экстренного стирания при утере/краже устройства.
• Запрет создания локальных резервных копий мессенджера на устройстве (для конфиденциальных данных).

Действия при инциденте

Инцидент — это не «если», а «когда». Разница между компанией с планом и без плана — в скорости реакции и масштабе последствий.

Типы инцидентов

1. Компрометация учётной записи. Кто-то получил доступ к аккаунту сотрудника (фишинг, подбор пароля, кража устройства).
2. Утечка данных. Конфиденциальная информация оказалась за периметром компании (пересылка, скриншот, экспорт).
3. Несанкционированный доступ. Посторонний человек в корпоративном канале (бывший сотрудник, ошибочное приглашение).
4. Инсайдерская угроза. Сотрудник намеренно собирает или передаёт конфиденциальную информацию.
5. Технический сбой. Потеря данных, недоступность сервиса, ошибка в настройках безопасности.

Алгоритм реагирования

Шаг 1: Обнаружение (0–15 минут).

• Источник обнаружения: автоматический мониторинг (DLP, SIEM), сообщение сотрудника, внешнее уведомление.
• Первичная классификация: тип инцидента, предполагаемый масштаб, затронутые данные.
• Уведомление ответственного за ИБ (по телефону, не через мессенджер, если мессенджер скомпрометирован).

Шаг 2: Сдерживание (15–60 минут).

• Блокировка скомпрометированных учётных записей.
• Отключение доступа с подозрительных устройств.
• Принудительная смена паролей для затронутых пользователей.
• Изоляция скомпрометированного канала (при необходимости).

Шаг 3: Расследование (1–24 часа).

• Анализ аудит-логов: кто, когда, откуда, что делал.
• Определение масштаба: какие данные затронуты, сколько пользователей.
• Идентификация причины: техническая уязвимость, человеческий фактор, целенаправленная атака.
• Фиксация доказательств (для возможного судебного разбирательства).

Шаг 4: Уведомление (в течение 24 часов).

• Уведомление руководства компании.
• Уведомление Роскомнадзора — если затронуты персональные данные (требование ФЗ-152 с 2025 года).
• Уведомление пострадавших субъектов ПДн (если применимо).
• Уведомление регулятора отрасли (ЦБ, ФСТЭК — если применимо).

Шаг 5: Устранение и восстановление (1–7 дней).

• Устранение причины инцидента.
• Восстановление нормальной работы.
• Верификация: проблема действительно решена?

Шаг 6: Постмортем (в течение 2 недель).

• Подробный разбор: что произошло, почему, как предотвратить повторение.
• Обновление политики ИБ (если нужно).
• Обучение сотрудников (если причина — человеческий фактор).
• Документирование инцидента в реестре.

Шаблон политики

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

ПОЛИТИКА ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ
использования корпоративного мессенджера

Версия: 1.0
Дата утверждения: [дата]
Утверждено: [должность, ФИО]
Ответственный за актуализацию: [должность, ФИО]
Пересмотр: ежегодно или при значительных изменениях

1. Общие положения

1.1. Настоящая Политика устанавливает требования к использованию корпоративного мессенджера [название мессенджера] (далее — Мессенджер) в [полное название организации] (далее — Компания).

1.2. Политика распространяется на всех сотрудников, подрядчиков, временный персонал и третьих лиц, имеющих доступ к Мессенджеру.

1.3. Нарушение настоящей Политики может повлечь дисциплинарные взыскания, вплоть до увольнения, а также административную и уголовную ответственность в соответствии с законодательством РФ.

2. Классификация информации

2.1. Информация, передаваемая через Мессенджер, классифицируется по четырём уровням: Открытая, Внутренняя, Конфиденциальная, Строго конфиденциальная.

2.2. Через Мессенджер допускается передача информации уровней «Открытая», «Внутренняя» и «Конфиденциальная» (последняя — только в каналах с ограниченным доступом).

2.3. Передача строго конфиденциальной информации через Мессенджер запрещена.

3. Управление учётными записями

3.1. Учётная запись создаётся IT-отделом в течение [1] рабочего дня с момента приёма сотрудника на работу.

3.2. Учётная запись деактивируется в течение [1 часа] с момента получения уведомления об увольнении.

3.3. Двухфакторная аутентификация обязательна для всех пользователей.

3.4. Требования к паролю: не менее [12] символов, смена каждые [90] дней.

4. Правила использования

4.1. Мессенджер используется исключительно для рабочих коммуникаций.

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

4.3. При использовании на личном устройстве обязательна блокировка экрана (PIN/биометрия).

5. Управление каналами

5.1. Создание каналов — по заявке через [руководителя отдела / IT-отдел].

5.2. Каждый канал имеет ответственного, который контролирует состав участников.

5.3. Ревью состава каналов — ежеквартально.

6. Хранение и удаление

6.1. Срок хранения переписки — [1 год / 3 года / 5 лет].

6.2. По истечении срока хранения данные удаляются автоматически.

6.3. Бэкапы создаются ежедневно, хранятся [30] дней, шифруются.

7. Мониторинг

7.1. Действия пользователей в Мессенджере логируются (вход, выход, создание/удаление сообщений, загрузка файлов, изменение настроек каналов).

7.2. Аудит логов проводится [ежеквартально] или при инциденте.

7.3. Сотрудники уведомлены о логировании в рамках настоящей Политики.

8. Реагирование на инциденты

8.1. При обнаружении инцидента ИБ сотрудник обязан немедленно сообщить [ответственному за ИБ / IT-отделу] по телефону [номер].

8.2. Порядок реагирования — в соответствии с Приложением 1 к настоящей Политике.

8.3. Все инциденты фиксируются в реестре инцидентов ИБ.

Как внедрить: пошаговый план

Написать документ — половина дела. Внедрить так, чтобы он работал, — вторая половина.

Шаг 1: Согласование (1–2 недели)

Подготовьте черновик и согласуйте с:

• IT-отделом — техническая реализуемость.
• Юристами — соответствие законодательству, корректность формулировок.
• HR — процедуры приёма/увольнения, дисциплинарные меры.
• Руководством — утверждение и поддержка «сверху».

Важно: не согласовывайте с 20 людьми. Три-четыре ключевых stakeholder — достаточно. Иначе процесс растянется на месяцы.

Шаг 2: Техническая настройка (1–3 дня)

Настройте мессенджер в соответствии с политикой:

• Включите 2FA для всех пользователей.
• Настройте retention policy (автоудаление старых сообщений).
• Настройте роли и политики доступа к каналам.
• Включите аудит-логи.
• Настройте DLP (если мессенджер поддерживает).
• Проверьте бэкапы и процедуру восстановления.

Шаг 3: Обучение (1 день)

Проведите короткий (30–40 минут) тренинг для всех сотрудников:

• Зачем нужна политика (реальные примеры инцидентов — обезличенные).
• Что можно и нельзя делать в мессенджере (5 ключевых правил).
• Как реагировать при инциденте (кому звонить).
• Где найти полный текст политики.

Не делайте двухчасовой вебинар с 80 слайдами. 30 минут, 10 слайдов, реальные примеры. После — ссылка на документ и контакт для вопросов.

Шаг 4: Подписание (1 день)

Каждый сотрудник подписывает ознакомление с политикой. Электронная подпись или цифровое подтверждение в HR-системе — достаточно. Бумажный вариант — по желанию.

Шаг 5: Мониторинг (постоянно)

Первые 2–4 недели после внедрения — период адаптации. Будут вопросы, будут нарушения. Мягко напоминайте, не штрафуйте. Через месяц — первый аудит: соблюдаются ли правила? Есть ли типичные нарушения? Нужно ли скорректировать политику?

Шаг 6: Пересмотр (ежегодно)

Политика — живой документ. Пересматривайте минимум раз в год или при:

• Смене мессенджера.
• Изменении законодательства (новые требования ФЗ-152, ФСТЭК).
• Серьёзном инциденте ИБ.
• Значительном росте компании (новые отделы, новые роли).

Хорошая политика ИБ для мессенджера — это 5 страниц текста, 3 дня настройки и 30 минут обучения. Это минимальные инвестиции, которые закрывают серьёзные риски. Если ваш корпоративный мессенджер поддерживает управление доступом, аудит-логи и DLP на техническом уровне — политика становится организационным дополнением к уже работающим техническим мерам. Если нет — это повод задуматься о смене мессенджера.