От чего защищаем ServiceDesk
Типовая модель угроз для ServiceDesk включает:
- Утечка персональных данных. В заявках — ФИО, email, должности, телефоны сотрудников. Это ПДн по 152-ФЗ.
- Компрометация учётных данных. В письмах пользователи иногда присылают пароли, ключи, реквизиты — несмотря на все запреты.
- Утечка информации об инфраструктуре. Описания инцидентов содержат карту систем, имена серверов, IP-адреса. Ценный артефакт для атакующего.
- Несанкционированный доступ операторов. Оператор L1 видит заявки, которые не должен (например, заявки руководства, HR, юридического отдела).
- Атаки через email-канал. Злоумышленник шлёт фишинг на
support@, открывая цепочку атаки. - Атаки на веб-интерфейс. SQL-инъекции, XSS, CSRF — стандартные для любого веб-приложения.
- Доступ из-за периметра. Для бизнес-континьюити ServiceDesk часто доступен снаружи (удалённые сотрудники) — расширяет поверхность атаки.
Российская регуляторика
152-ФЗ «О персональных данных»
Применяется практически ко всем ServiceDesk, т.к. в заявках есть ФИО, email, должности — это ПДн. Ключевые требования:
- Согласие субъекта — у сотрудника должно быть явное согласие на обработку (обычно в трудовом договоре)
- Локализация — хранение ПДн граждан РФ только на территории РФ (закрывает вопрос зарубежных SaaS)
- Организационные меры — политики доступа, разграничение прав, аудит
- Технические меры — шифрование, антивирус, средства защиты каналов
- Уведомление утечек — с 2022 года обязательное сообщение в Роскомнадзор при утечках ПДн
Для 152-ФЗ важно определить уровень защищённости (УЗ-1...УЗ-4) — зависит от категории ПДн и количества субъектов. Для типичного ServiceDesk обычно УЗ-3 или УЗ-2. Это влияет на требуемые средства защиты.
187-ФЗ «О безопасности КИИ»
Применяется к критической информационной инфраструктуре — банкам, телекому, энергетике, транспорту, здравоохранению, госсектору. Для этих организаций:
- Обязательная категоризация объектов КИИ (1, 2, 3 категория)
- Использование ПО из реестра отечественного для значимых объектов
- Подключение к ГосСОПКА
- Регулярный аудит ФСТЭК
Если ваш ServiceDesk обслуживает объект КИИ — он сам становится частью периметра защиты. Выбор on-premise-решения из реестра становится не пожеланием, а обязательством.
Руководящие документы ФСТЭК
Для тех, кто работает с гостайной или значимыми объектами КИИ — применимы РД ФСТЭК по защите от несанкционированного доступа. Ключевые требования:
- Сертифицированное СЗИ (средство защиты информации)
- Разграничение доступа по меткам конфиденциальности
- Аудит всех действий с отметкой даты, пользователя, IP
- Контроль целостности конфигураций
RBAC: разграничение прав
Role-Based Access Control — основа безопасности ServiceDesk. Принцип: не каждый оператор видит всё.
Типовые роли
| Роль | Что может | Что НЕ может |
|---|---|---|
| Пользователь | Создавать заявки, видеть только свои | Видеть чужие заявки, отчёты, настройки |
| Оператор L1 | Обрабатывать заявки своей очереди | Редактировать услуги, видеть заявки руководства |
| Оператор L2 | Работать с эскалированными, делать внутренние комменты | Администрировать пользователей |
| Руководитель команды | Отчёты по команде, управление очередями | Глобальные настройки |
| Администратор | Всё перечисленное + настройки системы | Аудит администраторов — только у офицера ИБ |
| Офицер ИБ | Аудит всех действий, включая админов | Вносить заявки от имени других |
Гранулярность прав
Современные системы позволяют разграничивать не только на уровне ролей, но и по атрибутам:
- По организационной структуре — оператор команды «Exchange» видит только заявки по услуге «Электронная почта»
- По группам пользователей — отдельная команда «VIP» работает только с заявками руководства; рядовые операторы их не видят
- По категориям обращений — заявки в HR-тематике (увольнения, зарплата) видны только команде HR-IT
- По полям — некоторые поля могут быть скрыты или read-only для определённых ролей
Аудит действий
Каждое значимое действие должно записываться в журнал аудита с неизменяемой историей:
- Вход / выход пользователей (успешные и неудачные)
- Создание / изменение / удаление заявок, комментариев
- Изменения ролей и прав
- Изменения настроек системы
- Экспорт данных (кто выгрузил базу пользователей)
- Доступ к чувствительным заявкам
Важные требования к журналу:
- Хранение минимум 1 год (для 152-ФЗ — 3 года для некоторых событий)
- Неизменяемость — даже администратор не может стереть запись
- Экспорт в SIEM (Splunk, ELK, ArcSight) для корреляции с другими источниками
- Отдельные права для просмотра аудита — не у всех администраторов
Без полного аудита вы никогда не узнаете, что произошла утечка или несанкционированный доступ. В случае расследования инцидента ИБ первым делом смотрят журнал — если его нет или он неполный, вы в слабой позиции.
Шифрование
Три уровня шифрования:
Шифрование в передаче
- HTTPS / TLS 1.2+ для веб-интерфейса — обязательно, без исключений
- IMAPS / SMTPS для email
- LDAPS для AD
- TLS для всех интеграционных API
Самоподписанные сертификаты допустимы только для изолированных сетей. Во всех остальных случаях — валидные сертификаты от CA (Let's Encrypt, GlobalSign, локальные УЦ).
Шифрование в хранилище
- Шифрование БД — на уровне диска (LUKS, BitLocker) или БД (TDE в PostgreSQL, MySQL)
- Шифрование файлов-вложений — S3 с SSE или на уровне файловой системы
- Шифрование бэкапов — обязательно, хранятся отдельно от ключей
Пароли и секреты
- Пароли пользователей — bcrypt / Argon2 (не MD5, не SHA1)
- Секреты интеграций (API-токены, пароли сервисных учёток) — в секретном хранилище (Vault, Secret Manager)
- Многофакторная аутентификация (2FA) — минимум для администраторов, опционально для всех
Защита email-канала
Email — самый рискованный входящий канал. Минимальный набор мер:
- SPF, DKIM, DMARC — защита от подделки отправителя
- Антивирус на вложениях перед приёмом в ServiceDesk
- Песочница для подозрительных вложений — если поддерживается антивирусом
- Rate limiting — защита от bulk-отправки заявок
- Фильтрация HTML — санитизация входящих писем от XSS
Защита веб-интерфейса
Стандартный набор защит для веб-приложений:
- Защита от OWASP Top-10 (SQL-инъекции, XSS, CSRF, SSRF)
- Content Security Policy (CSP) — жёсткие заголовки
- Rate limiting на login endpoint (защита от брутфорса)
- Блокировка после N неудачных попыток входа
- Session timeout — автологаут после 30–60 минут неактивности
- HTTPS-only cookie с флагами HttpOnly, Secure, SameSite
- Регулярные pentest и проверка уязвимостей
Бэкап и восстановление
Безопасность — это не только защита от атак, но и способность восстановиться после них (например, после ransomware):
- Ежедневные автоматические бэкапы полного состояния (БД, файлы)
- Хранение минимум 30 дней с ротацией
- Offline-копии — защита от зашифрованного нападения на онлайн-хранилище
- Регулярные тренировки восстановления — хотя бы раз в квартал полностью восстановить из бэкапа
- RTO / RPO — задокументированные цели восстановления
Реагирование на инциденты ИБ
Что делать, если инцидент ИБ в ServiceDesk уже произошёл:
- Изолировать систему — отключить от сети, чтобы атакующий не мог продолжить
- Сохранить артефакты — логи, дампы, снапшоты ВМ для расследования
- Уведомить команду ИБ и руководство
- Оценить масштаб — что скомпрометировано, какие данные утекли
- Восстановить из чистого бэкапа
- Уведомить регуляторов — Роскомнадзор при утечке ПДн, НКЦКИ для КИИ
- Разбор после устранения — Post-Incident Review с уроками
У компании должен быть план реагирования на инциденты ИБ (Incident Response Plan) с ролями и процедурами, а не "будем разбираться по ходу".
Почему on-premise выигрывает по безопасности
Для российских компаний с серьёзными требованиями к ИБ on-premise даёт несколько ключевых преимуществ:
- Данные в периметре — не уходят за границу, соответствует 152-ФЗ о локализации
- Контроль обновлений — обновляете, когда готовы и после внутреннего тестирования
- Интеграция с корпоративной ИБ — логи в корпоративный SIEM, доступы через корпоративный IdP
- Нет санкционных рисков — в отличие от зарубежного SaaS, который может быть заблокирован
- Включение в реестр отечественного ПО — возможно только для on-premise-решений
Подробнее о разнице — в статье On-premise vs SaaS.
Типовые ошибки
- "У нас же внутренняя система, зачем защита". 60% инцидентов ИБ — от инсайдеров или через фишинг против сотрудников. Внутренняя не равно безопасная.
- Один пароль админа на всех. Нет разграничения — нет возможности аудировать.
- Нет MFA для админов. Компрометация админского пароля даёт полный доступ ко всем заявкам компании.
- Логи хранятся в той же БД. При взломе атакующий удаляет следы.
- Шифрование только TLS. Забыли про шифрование БД и бэкапов — при физической краже дисков все данные в открытом виде.
Вывод
Безопасность ServiceDesk — комплексная задача: технические меры (шифрование, RBAC, аудит) + организационные (политики, обучение, реагирование) + регуляторные (152-ФЗ, 187-ФЗ). Ни один из элементов не достаточен сам по себе.
Для большинства российских компаний разумный путь — on-premise-решение с базовыми встроенными механизмами ИБ (RBAC, аудит, шифрование) + интеграция с корпоративным SIEM. В TIQQET все перечисленные механизмы доступны из коробки, продукт включён в реестр отечественного ПО.
Попробуйте TIQQET в деле
On-premise ServiceDesk с полным циклом заявок, SLA-контролем и мобильными приложениями. Развёртывание за 1 день.
Посмотреть демоЧастые вопросы
Нужен ли сертификат ФСТЭК для ServiceDesk?
Зависит от вашей организации. Для большинства коммерческих компаний — нет. Для работы с гостайной, объектами КИИ 1 категории, в ряде силовых ведомств — да. Уточняйте требования у вашего офицера ИБ и в регуляторных документах вашей отрасли.
Как обеспечить соответствие 152-ФЗ?
Минимум: (1) локализация данных в РФ — on-premise или российский облачный провайдер; (2) согласие субъектов на обработку — обычно в трудовом договоре; (3) технические меры согласно УЗ (обычно УЗ-3 или УЗ-2); (4) журнал аудита с хранением 3 года; (5) уведомление Роскомнадзора при утечках с 2022 года. Полный перечень — в приказе ФСТЭК №21.
Можно ли использовать ServiceDesk без MFA?
Формально — да, но крайне не рекомендуется. Как минимум для администраторов MFA должна быть обязательной. Для обычных пользователей — в зависимости от чувствительности данных в заявках. В компаниях с повышенными требованиями к ИБ MFA включается для всех.
Какой срок хранения логов правильный?
Для общего аудита — минимум 1 год. Для действий с персональными данными (по 152-ФЗ) — 3 года. Для объектов КИИ (187-ФЗ) — в соответствии с методикой НКЦКИ, обычно 3–6 месяцев оперативных + 1 год архивных. Для компаний финансового сектора может быть до 5 лет по отраслевым нормативам ЦБ.
Как защитить вложения к заявкам?
Четыре слоя: (1) антивирусная проверка при загрузке; (2) ограничение на разрешённые типы файлов; (3) хранение в шифрованном хранилище; (4) проверка прав доступа при скачивании — не только по ссылке, но и по ролям. Плюс логирование скачиваний.
Что делать, если пользователь прислал пароль в письме?
Две линии защиты. Проактивная: обучение пользователей, сканирование входящих на паттерны паролей с автоматическим удалением или маскировкой. Реактивная: если пароль всё же попал — немедленная смена пароля у пользователя, удаление письма из заявки (с записью действия в аудит), уведомление об инциденте.