Раздел предоставляет объективные данные об использовании корпоративного мессенджера, нагрузке на инфраструктуру и действиях администраторов. На основе этих метрик вы принимаете обоснованные решения: оптимизировать рабочие пространства, масштабировать серверные мощности или подтвердить соответствие политикам безопасности при внутренних и внешних аудитах.
Что это и зачем
Инструмент анализа активности каналов и команд. Система выявляет коммуникационные пространства, которые используются регулярно, и те, где активность отсутствует длительное время. Это позволяет поддерживать порядок в цифровой среде, снижать информационную нагрузку на сотрудников и повышать эффективность работы с каналами.
Основные возможности
- Формирование перечня каналов и команд с нулевой или минимальной активностью за заданный период (неделя, месяц, квартал).
- Ключевые метрики вовлеченности: количество сообщений, файлов, реакций и упоминаний в разрезе каждого канала.
- Автоматические рекомендации по архивации, объединению или назначению ответственного за развитие канала.
- Анализ распределения активности по дням и часам для выбора оптимального времени для массовых коммуникаций.
Рекомендации по применению
- Проводите ежемесячный обзор неактивных каналов после завершения пилотных проектов или реорганизации отделов.
- Установите корпоративную политику: канал без сообщений более 14 дней переводится в режим «только чтение» с уведомлением владельца.
- Используйте данные для обучения руководителей подразделений эффективной организации канальной структуры.
Пример из корпоративной практики
В ходе планового анализа выявлено, что 15% каналов в команде «Маркетинг» не использовались более трех недель. Администратор направляет владельцам этих каналов запрос на подтверждение необходимости. Пять каналов архивируются, в двух объединяются тематически близкие обсуждения. В результате сокращается время, которое сотрудники тратят на переключение между чатами, и повышается заметность действительно важных коммуникаций.
Что это и зачем
Агрегированные показатели производительности серверной инфраструктуры DST App. Вы получаете данные о текущей и пиковой нагрузке, использовании дискового пространства, быстродействии базы данных и поискового движка. Это позволяет своевременно планировать расширение ресурсов и предотвращать сбои.
Основные возможности
- Количество активных пользователей в реальном времени и динамика за выбранный период (день, неделя, месяц).
- Объем занятого хранилища в разрезе: файлы, индексы поиска (Elasticsearch), журналы событий.
- Время отклика критических компонентов (база данных, поиск) — ключевой показатель качества работы.
- Тренды роста: изменение числа пользователей, сообщений и загружаемых файлов.
Рекомендации по применению
- Настройте пороговые оповещения: при достижении 80% занятого дискового пространства или увеличении времени ответа базы данных более чем на 30% от нормы.
- Включайте анализ статистики системы в еженедельный отчет службы эксплуатации.
- Используйте исторические данные для обоснования бюджета на развитие ИТ-инфраструктуры.
Пример из корпоративной практики
За квартал число активных пользователей выросло на 25%, а объем хранимых файлов увеличился на 40%. На основе данных раздела «Статистика системы» технический директор инициирует закупку дополнительных дисковых массивов и настраивает политику автоматической очистки файлов в публичных каналах старше 90 дней. Модернизация проходит до того, как пользователи начинают испытывать ограничения, и бизнес-процессы остаются непрерывными.
Что это и зачем
Детальная аналитика активности по каждой команде (подразделению, проектному офису, региональному филиалу). Руководители среднего звена получают объективные данные об использовании мессенджера своими сотрудниками, что помогает оценивать вовлеченность и выявлять отклонения в коммуникационных процессах.
Основные возможности
- По каждой команде: количество активных участников, объем сообщений и файлов, частота использования реакций и упоминаний.
- Временные профили активности — например, утренние пики коммуникации или спад после обеда.
- Сравнение метрик между командами одинаковой численности без раскрытия содержания переписок.
- Экспорт отчета для передачи руководителю команды в форматах, принятых в организации.
Рекомендации по применению
- Предоставляйте статистику команды ее руководителю ежемесячно для использования на оперативных совещаниях.
- Сопоставляйте данные с KPI подразделения: например, если активность в мессенджере падает, но количество выполненных задач не меняется, возможно, общение дублируется в других каналах (почта, телефон).
- Используйте статистику для выявления лучших практик: команда с высокой вовлеченностью может служить эталоном для остальных.
Пример из корпоративной практики
Руководитель IT-департамента видит, что команда разработки демонстрирует на 50% более высокую активность в мессенджере по сравнению с командой тестирования при равной численности. Анализ, проведенный с участием руководителей обеих групп, показывает, что тестировщики продолжают использовать электронную почту для отчетов о дефектах. После перевода всех отчетов в выделенный канал и отключения почтовых рассылок активность команды тестирования выравнивается, а время реакции на критические баги сокращается на 30%.
Что это и зачем
Полная хронология событий, связанных с работой системы и действиями администраторов. В отличие от технических логов, данный журнал структурирован для задач информационной безопасности и внутреннего контроля: он фиксирует входы в панель управления, изменения конфигураций, создание и удаление пользователей, а также системные сбои.
Основные возможности
- Регистрация всех аутентификаций: пользователь, временная метка, IP-адрес, результат попытки.
- Аудит действий администраторов: любые изменения в разделах «Управление пользователями», «Разрешения», «Интеграции».
- Системные события: перезапуск сервера, ошибки подключения к БД, исчерпание дискового пространства.
- Фильтрация и поиск по дате, типу события, пользователю или затронутому объекту (канал, файл).
Рекомендации по применению
- Храните журнал сервера в отдельном защищенном хранилище с запретом на модификацию и удаление записей.
- Назначьте ответственного за еженедельный выборочный просмотр событий с уровнем «критический» и «предупреждение».
- Включите настройку автоматического уведомления при подозрительных действиях: например, более 5 неудачных попыток входа за минуту или удаление пользователя вне рабочего времени.
Пример из корпоративной практики
При утренней проверке журнала администратор обнаруживает запись о том, что в 23:47 пользователь с учетной записью «petrov» (уволенный накануне) выполнил массовое удаление сообщений в канале «Проект Альфа». В журнале зафиксирован IP-адрес, соответствующий корпоративному ноутбуку, который еще не был заблокирован. Доступ к ноутбуку немедленно отзывается, учетная запись деактивируется, а инициируется служебное расследование. Журнал сервера предоставляет исчерпывающую доказательную базу для разбирательства.
Раздел предназначен для централизованного администрирования учетных записей, организационной структуры и прав доступа. Здесь вы определяете, кто входит в систему, как сотрудники объединяются в группы и команды, какие каналы создаются и какие действия разрешены каждой роли. Это основа для соблюдения принципа минимально необходимого доступа и обеспечения информационной безопасности.
Что это и зачем
Реестр всех учетных записей, имеющих доступ к корпоративному мессенджеру: сотрудники, внешние подрядчики, гостевые участники. Раздел обеспечивает полный жизненный цикл учетной записи — от создания до блокировки или удаления.
Основные возможности
- Создание новых пользователей вручную или автоматический импорт из корпоративного каталога (AD/LDAP).
- Блокировка, временное отключение или безвозвратное удаление учетной записи.
- Сброс пароля, принудительное включение многофакторной аутентификации.
- Назначение системных ролей: администратор, менеджер пользователей, обычный пользователь, гость.
- Просмотр истории входов и последней активности.
Рекомендации по применению
- Внедрите процедуру автоматической деактивации учетных записей при увольнении сотрудника (интеграция с кадровой системой или AD).
- Для критичных ролей (администраторы, руководители) установите обязательную двухфакторную аутентификацию на уровне учетной записи.
- Используйте корпоративные домены электронной почты для регистрации; запретите использование личных почтовых адресов.
Пример из корпоративной практики
В компании с численностью 2 000 сотрудников настроена синхронизация с Active Directory. При увольнении кадровая служба блокирует запись в AD, и в течение часа учетная запись в DST App автоматически переводится в статус «Заблокирована». Вся корпоративная переписка и файлы уволенного сотрудника остаются в системе и доступны руководителю или правопреемнику. Утечка клиентской базы через личный мессенджер исключена.
Что это и зачем
Логические объединения пользователей по общему признаку (отдел, должность, уровень доступа). Группы позволяют назначать права и разрешения не каждому сотруднику индивидуально, а целой категории, что значительно упрощает администрирование в крупных организациях.
Основные возможности
- Создание групп, например: «Бухгалтерия», «Руководство», «Внешние подрядчики».
- Автоматическое включение пользователей в группы при регистрации (на основе атрибутов из AD/HR-системы).
- Наследование разрешений: участник группы автоматически получает все права, назначенные группе.
- Иерархия групп: возможность включать одну группу в состав другой.
Рекомендации по применению
- Проектируйте структуру групп в соответствии с организационной структурой и матрицей ответственности.
- Назначайте владельца группы, который может управлять ее составом без прав глобального администратора.
- Регулярно (раз в квартал) проводите аудит членства в группах с высокими привилегиями.
Пример из корпоративной практики
В розничной сети создана группа «Администраторы магазинов». Все директора торговых точек автоматически добавляются в эту группу при назначении на должность (синхронизация с HR-системой). Группе назначено разрешение создавать каналы для своего магазина и приглашать сотрудников, но запрещено удалять системные каналы. При переводе сотрудника на другую должность он автоматически покидает группу, и его права перестают действовать без ручного вмешательства администратора.
Что это и зачем
Пространства верхнего уровня, объединяющие каналы, пользователей и настройки вокруг функционального направления, проекта или регионального филиала. Команда — это «цифровой офис» подразделения, внутри которого создаются тематические каналы для обсуждений.
Основные возможности
- Создание команд, например: «Продажи», «Разработка продукта», «Московский филиал».
- Настройка видимости команды: публичная (доступна всем) или частная (только по приглашению).
- Назначение владельца команды с правами управления участниками и каналами.
- Ограничения на уровне команды: максимальный размер файлов, разрешенные типы вложений, политика хранения.
Рекомендации по применению
- Внедрите правило: одна команда — один назначенный владелец, ответственный за порядок, архивацию и соблюдение политик.
- Для проектов с ограниченным сроком жизни создавайте временные команды с автоматической архивацией по дате завершения.
- Используйте префиксы в названиях команд для удобной навигации (например, «Фин_», «ИТ_», «Регион_»).
Пример из корпоративной практики
Крупный логистический оператор создает отдельные команды для каждого регионального хаба: «Хаб_Москва», «Хаб_Новосибирск», «Хаб_Владивосток». Внутри каждой команды настроены каналы «Оперативный штаб», «Водители», «Диспетчерская». Руководители хабов назначены владельцами команд и могут самостоятельно управлять участниками, не обращаясь к центральному администратору. При этом глобальная политика безопасности (запрет на экспорт, срок хранения сообщений) единообразно применяется ко всем командам.
Что это и зачем
Тематические чаты внутри команды для обсуждения конкретных задач, проектов или тем. Каналы — основное рабочее пространство для повседневной коммуникации сотрудников. Правильная организация каналов снижает информационный шум и повышает фокусировку.
Основные возможности
- Создание публичных (доступны всем участникам команды) и частных (только по приглашению) каналов.
- Назначение владельцев и модераторов канала.
- Установка лимитов на размер вложений, запрет или разрешение внешних ссылок.
- Архивирование каналов с сохранением истории и возможностью восстановления.
- Шаблоны именования и автоматическое создание каналов при старте проекта.
Рекомендации по применению
- Разработайте стандарт именования каналов, например:
проект-альфа-разработка,hr-вопросы,объявления-офис. - Для долгосрочных рабочих групп используйте публичные каналы, для конфиденциальных обсуждений — частные.
- Настройте политику, при которой любой канал без сообщений в течение заданного срока автоматически переводится в режим архивации с уведомлением владельца.
Пример из корпоративной практики
В команде «ИТ-инфраструктура» создан частный канал «Уязвимости_критические». Доступ к нему имеют только руководитель ИБ, системный администратор и технический директор. В канале публикуются отчеты о пентестах и планы закрытия уязвимостей. При этом в публичном канале «ИТ-новости» размещаются только общие объявления о плановых работах. Разделение каналов по уровню конфиденциальности позволяет соблюдать требования регуляторов без ущерба для оперативной работы.
Что это и зачем
Тонкая настройка прав доступа для ролей, групп и отдельных пользователей. Разрешения определяют, какие действия разрешены: создание каналов, приглашение новых участников, удаление сообщений, загрузка файлов, экспорт переписки и другие. Это ключевой инструмент контроля и соблюдения политик безопасности.
Основные возможности
- Назначение прав на уровне системы, команды, канала.
- Предопределенные роли (администратор, менеджер, пользователь, гость) с возможностью кастомизации.
- Гранулярные настройки: разделение прав на создание, чтение, обновление, удаление для разных типов объектов.
- Наследование разрешений: права группы распространяются на всех ее участников.
- Аудит изменений разрешений (фиксируется в журнале сервера).
Рекомендации по применению
- Придерживайтесь принципа минимально необходимых привилегий: предоставляйте ровно те права, которые требуются для выполнения должностных обязанностей.
- Регулярно (не реже одного раза в полгода) проводите ревизию разрешений групп и ролей.
- Для внешних подрядчиков используйте роль «Гость» с ограниченными правами (без возможности приглашать других, без доступа к файлам вне выделенных каналов).
Пример из корпоративной практики
В медицинской организации настроены следующие разрешения: врачи имеют право создавать каналы для обсуждения пациентов, но не могут удалять сообщения старше 30 дней (требование по сохранности истории). Администраторы отделений могут приглашать новых сотрудников, но не имеют доступа к каналам финансового блока. Главный врач и служба комплаенса имеют право экспортировать переписку для внутренних проверок. Благодаря гибкой системе разрешений удается соблюсти отраслевые нормативы без излишних ограничений для клинической работы.
Раздел предназначен для создания гибкой модели доступа, основанной на характеристиках пользователей, а не на их фиксированных ролях или ручном добавлении в каналы. Системные атрибуты позволяют автоматизировать управление доступом в условиях динамичной организационной структуры, частых перемещений сотрудников между отделами, регионами и проектами.
Что это и зачем
Атрибуты — это структурированные метки, присваиваемые учетной записи пользователя и описывающие его свойства: должность, подразделение, регион, уровень допуска, статус занятости и любые другие характеристики, значимые для вашей организации. В отличие от статической роли («администратор», «пользователь»), атрибуты могут комбинироваться и динамически изменяться.
Основные возможности
- Создание пользовательского справочника атрибутов: тип атрибута (текст, число, список значений), допустимые значения.
- Примеры атрибутов: «Регион» (Москва / Санкт-Петербург / Новосибирск), «Должность» (инженер / руководитель / директор), «Уровень доступа» (1 / 2 / 3), «Проектная роль» (разработчик / аналитик / заказчик).
- Ручное присвоение атрибутов через интерфейс администратора или автоматическое — при импорте из AD/LDAP, HR-системы, кадрового учета.
- Массовое обновление атрибутов: например, перевод всех сотрудников филиала в другой регион.
- История изменений атрибутов для аудита.
Рекомендации по применению
- Согласуйте перечень атрибутов с отделом кадров и службой информационной безопасности. Атрибуты должны отражать реальные бизнес-процессы и политики доступа.
- Настройте автоматическую синхронизацию атрибутов из корпоративных систем-источников (AD, SAP, 1С). Это исключает ручные ошибки и задержки при кадровых перемещениях.
- Не создавайте избыточное количество атрибутов. Начните с ключевых: подразделение, должностная категория, регион.
Пример из корпоративной практики
Крупный ритейлер с 15 000 сотрудников и 500 торговыми точками ввел атрибуты: «Магазин» (номер точки), «Должность» (администратор, продавец-кассир, товаровед), «Регион управления» (Центр, Урал, Дальний Восток). Эти атрибуты автоматически загружаются из корпоративной HR-системы при приеме на работу и при переводе. Благодаря этому доступ к каналам, содержащим коммерческую тайну (цены закупки, маржинальность), автоматически открывается только для тех сотрудников, у которых атрибут «Должность» содержит «товаровед» или «администратор», а атрибут «Магазин» соответствует конкретному подразделению. При переводе сотрудника в другой магазин доступ перестраивается автоматически в течение часа.
Что это и зачем
Модель управления доступом, при которой решение о предоставлении прав на канал, команду или функцию принимается динамически на основе набора атрибутов пользователя, а не его статического членства в группе или роли. ABAC (Attribute-Based Access Control) позволяет формулировать правила доступа на естественном языке: «Доступ открыт, если атрибут „Регион“ = Москва И атрибут „Должность“ = старший инженер». Это исключает необходимость вручную добавлять и удалять пользователей из сотен каналов при каждой кадровой перестановке.
Основные возможности
- Создание правил доступа в формате «ЕСЛИ (условие) ТО (разрешить / запретить)». Условия могут объединять несколько атрибутов с операторами И/ИЛИ.
- Применение правил к каналам, командам, а также к отдельным функциям (экспорт, создание интеграций).
- Автоматическое перерасчет доступа при изменении атрибутов пользователя (например, при переводе в другой отдел).
- Тестирование правил на тестовых пользователях перед развертыванием.
- Журнал срабатываний правил для аудита и отладки.
Рекомендации по применению
- Начинайте с простых правил, охватывающих наиболее частые сценарии (доступ по региону, по должностной категории). Усложняйте по мере накопления опыта.
- Документируйте каждое правило с указанием бизнес-обоснования и владельца (кто утвердил).
- Регулярно (раз в квартал) проводите аудит правил ABAC: удаляйте устаревшие, корректируйте изменившиеся.
- Для критических каналов (например, совет директоров) используйте комбинацию ABAC и ручного подтверждения.
Пример из корпоративной практики
В федеральной сети аптек действует требование: доступ к каналу «Аналитика продаж — рецептурные препараты» должны иметь только провизоры с атрибутом «Регион» = Самара или Екатеринбург, а также руководители категории вне зависимости от региона. Создано одно правило ABAC:
Разрешить доступ, если (атрибут "Должность" содержит "провизор" И атрибут "Регион" в [Самара, Екатеринбург]) ИЛИ (атрибут "Роль" = "руководитель категории").
При переводе провизора из Самары в Казань его атрибут «Регион» меняется автоматически из кадровой системы, и доступ к каналу закрывается без участия администратора. При этом руководитель категории, переехавший в любой регион, доступ сохраняет. Административные затраты на управление доступом снижены на 80%, риск ошибок исключен.
Раздел предназначен для настройки и мониторинга всех серверных компонентов, обеспечивающих работу DST App. Здесь конфигурируются веб-сервер, базы данных, файловые хранилища, интеграции с внешними сервисами (почта, push-уведомления), параметры отказоустойчивости, производительности и безопасности. Данный раздел ориентирован на системных администраторов и инженеров эксплуатации, однако понимание его возможностей полезно и для руководителей ИТ-подразделений, так как напрямую влияет на надежность, скорость и безопасность корпоративных коммуникаций.
Что это и зачем
Компонент, принимающий HTTP/HTTPS-запросы от клиентских приложений (веб-версия, десктопные и мобильные приложения) и возвращающий им интерфейс, сообщения и файлы. Настройка веб-сервера определяет, по какому домену доступен мессенджер, как шифруется трафик и какие ограничения на подключения действуют.
Основные возможности
- Привязка к корпоративному домену (например, chat.company.ru).
- Установка и автоматическое продление SSL-сертификатов (HTTPS) — обязательно для защиты данных.
- Настройка лимитов на количество одновременных подключений и размер передаваемых данных.
- Включение сжатия трафика для ускорения загрузки интерфейса.
- Конфигурация безопасных HTTP-заголовков (защита от XSS, кликджекинга, MIME-снифинга).
Рекомендации по применению
- Используйте только HTTPS с сертификатами от доверенного удостоверяющего центра, предпочтительно с автоматическим продлением (например, Let’s Encrypt).
- Ограничьте максимальный размер тела запроса для защиты от атак типа «отказ в обслуживании».
- Внедрите политику безопасности контента (CSP) для предотвращения загрузки вредоносных скриптов.
Пример из корпоративной практики
Финансовая организация развернула DST App на внутреннем домене corp-messenger.finance.ru. Настроен HTTPS с сертификатом, выпущенным внутренним удостоверяющим центром. Установлен лимит подключений — не более 10 000 одновременных сессий, что соответствует пиковой нагрузке с 40% запасом. Заголовки безопасности настроены в соответствии с рекомендациями Центрального банка. При внешнем сканировании уязвимостей веб-сервер показывает высший уровень защиты.
Что это и зачем
Хранилище всех структурированных данных: пользователей, сообщений, настроек, разрешений, метаинформации о файлах. Стабильность и производительность базы данных критически важны — любая задержка или сбой делает мессенджер недоступным.
Основные возможности
- Настройка параметров подключения (хост, порт, пул соединений).
- Конфигурация резервного копирования: расписание, тип резервирования (полное, инкрементное), место хранения копий.
- Регулировка параметров производительности: размер кэша, количество параллельных запросов.
- Настройка репликации для отказоустойчивости (совместно с разделом «Высокая доступность»).
Рекомендации по применению
- Регулярно (не реже одного раза в сутки) выполняйте резервное копирование базы данных. Храните копии на отдельном физическом носителе.
- Тестируйте процедуру восстановления из резервной копии не реже одного раза в квартал.
- Мониторьте размер базы данных и время выполнения запросов; при росте нагрузки рассматривайте увеличение ресурсов или оптимизацию.
Пример из корпоративной практики
В нефтегазовой компании с 5 000 пользователей база данных DST App занимает 200 ГБ. Настроено ежедневное инкрементное резервное копирование в 02:00 и полное — по воскресеньям. Копии отправляются на выделенный сервер в другом дата-центре. При сбое основного дискового массива восстановление заняло 45 минут, потери данных — не более 15 минут (инкремент за предыдущий день). Время восстановления соответствует внутреннему SLA.
Что это и зачем
Поисковый движок, обеспечивающий мгновенный полнотекстовый поиск по всем сообщениям и файлам. Без него поиск по миллионам сообщений занимал бы десятки секунд. Elasticsearch индексирует содержимое чатов и позволяет находить информацию по ключевым словам, датам, авторам.
Основные возможности
- Настройка подключения к кластеру Elasticsearch (один или несколько узлов).
- Управление индексами: какие данные индексировать, период хранения индексов.
- Конфигурация релевантности: вес заголовков, тела сообщений, вложений.
- Настройка ротации старых индексов для экономии дискового пространства.
Рекомендации по применению
- Храните индексы Elasticsearch на отдельном дисковом массиве или на более быстрых носителях (SSD), чем основная база данных.
- Настройте автоматическое удаление индексов старше заданного срока (например, 6 месяцев), если это не противоречит политике хранения данных.
- При высокой нагрузке рассмотрите кластеризацию Elasticsearch из 2–3 узлов.
Пример из корпоративной практики
Юридическая компания хранит переписку по судебным делам за 3 года. Elasticsearch индексирует около 50 миллионов сообщений. Среднее время поиска по ключевым словам — 0,8 секунды. Настроена автоматическая ротация: индексы старше 3 лет перемещаются в медленное (архивное) хранилище, старше 5 лет — удаляются. Пользователи не испытывают задержек, а объем быстрого дискового пространства остается в бюджете.
Что это и зачем
Место хранения всех загруженных вложений: изображений, документов, PDF, аудио- и видеозаписей звонков. Выбор типа хранилища влияет на скорость доступа к файлам, стоимость и возможности резервного копирования.
Основные возможности
- Выбор провайдера хранилища: локальная файловая система, сетевое хранилище (NFS), объектное хранилище (S3-совместимое, например, MinIO или AWS S3).
- Установка квот и максимального размера одного файла.
- Настройка антивирусной проверки загружаемых файлов (при интеграции с соответствующим ПО).
- Разделение на «горячее» (SSD) и «холодное» (HDD) хранилище для оптимизации затрат.
Рекомендации по применению
- Для крупных организаций (от 500 пользователей) рекомендуем объектное хранилище — оно легче масштабируется.
- Установите максимальный размер файла в соответствии с бизнес-задачами (обычно от 50 МБ до 1 ГБ).
- Включите автоматическую очистку файлов, не открывавшихся более 180 дней, если иное не требуется политикой.
Пример из корпоративной практики
Строительный холдинг использует DST App для обмена проектной документацией. Средний размер файла — 30 МБ, за месяц загружается 200 ГБ. Выбрано объектное хранилище на базе MinIO с двумя серверами. Горячие файлы (последние 30 дней) хранятся на NVMe-дисках, остальные автоматически перемещаются на HDD-массив. Затраты на хранение снижены на 40% по сравнению с единым дорогим хранилищем, а скорость доступа к свежим файлам осталась высокой.
Что это и зачем
Промежуточный сервер, который загружает внешние изображения (например, по ссылкам из сообщений) от имени сервера, а не от клиентского устройства. Это скрывает реальные IP-адреса пользователей, защищает от утечек и позволяет кэшировать контент для ускорения.
Основные возможности
- Включение/отключение проксирования внешних изображений.
- Настройка разрешенных доменов (белый список).
- Установка времени жизни кэша изображений.
- Фильтрация потенциально опасных форматов или контента.
Рекомендации по применению
- Включите прокси-сервер изображений по умолчанию для всех публичных каналов.
- Для конфиденциальных каналов можно дополнительно отключить загрузку внешних изображений.
- Регулярно обновляйте список разрешенных доменов, блокируйте нежелательные.
Пример из корпоративной практики
В государственной организации сотрудники часто обмениваются скриншотами с внешних ресурсов. При включенном прокси-сервере все изображения сначала загружаются на сервер DST App, проверяются на вредоносный код, затем отдаются пользователям. IP-адреса сотрудников не покидают периметр организации. Кроме того, кэширование снизило трафик на 30%, так как одно и то же изображение не загружается 20 раз.
Что это и зачем
Настройки исходящей электронной почты. DST App отправляет письма для подтверждения регистрации, сброса пароля, приглашений новых пользователей, а также уведомлений о пропущенных сообщениях (если пользователь отключил push). SMTP-сервер должен быть доступен из инфраструктуры.
Основные возможности
- Указание адреса SMTP-сервера, порта, протокола шифрования (STARTTLS, SSL/TLS).
- Учетные данные для аутентификации (логин/пароль).
- Настройка адреса отправителя и имени отправителя (например, «DST App noreply@company.ru»).
- Ограничение частоты отправки для предотвращения попадания в спам.
- Шаблоны писем (возможность кастомизации).
Рекомендации по применению
- Используйте выделенный почтовый ящик и домен, настроенный с DKIM, SPF и DMARC — это повышает доставляемость.
- Не используйте личные почтовые серверы (gmail.com, yandex.ru) для массовых рассылок.
- Настройте мониторинг очереди писем и уведомления об ошибках доставки.
Пример из корпоративной практики
Ритейлер настроил SMTP через корпоративный Microsoft Exchange. Адрес отправителя — messenger@5ka.ru. Письма с приглашениями и сбросом пароля доставляются во внутреннюю почтовую систему мгновенно. Настроены SPF и DKIM, благодаря чему письма не попадают в спам даже у внешних контрагентов.
Что это и зачем
Компонент, отвечающий за доставку уведомлений на мобильные устройства (iOS, Android) и десктопные приложения, даже когда они закрыты. Push-уведомления отправляются через внешние сервисы (APNS для Apple, FCM для Google) либо через собственный корпоративный шлюз.
Основные возможности
- Выбор типа push-сервера: публичные сервисы Google/Apple или корпоративный сервер (при использовании собственного MDM).
- Загрузка ключей и сертификатов для аутентификации в APNS/FCM.
- Настройка политики уведомлений: показывать текст сообщения или только заглушку.
- Установка «тихих часов», когда уведомления не отправляются.
Рекомендации по применению
- Для конфиденциальных организаций (госструктуры, финансы) рассмотрите отключение показа текста сообщений в push-уведомлениях.
- При использовании публичных push-сервисов убедитесь, что это не противоречит вашей политике безопасности.
- Настройте fallback-канал (например, email) на случай недоступности push.
Пример из корпоративной практики
Банк использует корпоративный MDM-сервер для push-уведомлений, чтобы данные не уходили на серверы Google. В push-уведомлении отображается только «Новое сообщение от [имя отправителя]» без текста. Для сотрудников с мобильными устройствами вне офиса настроены тихие часы с 22:00 до 08:00. Это соответствует внутренней политике информационной безопасности и требованиям ЦБ РФ.
Что это и зачем
Режим работы, при котором система продолжает функционировать при отказе одного или нескольких серверов. Высокая доступность достигается кластеризацией — объединением нескольких физических или виртуальных машин в группу, где при падении одного узла другой автоматически берет нагрузку.
Основные возможности
- Настройка кластера из нескольких узлов DST App.
- Настройка балансировки нагрузки (распределение запросов между узлами).
- Репликация базы данных и Elasticsearch между узлами.
- Автоматическое переключение (failover) при детекте отказа.
Рекомендации по применению
- Обязательна для организаций, где простой мессенджера влияет на операционную деятельность (диспетчерские, медицинские учреждения, банки).
- Проводите плановые учения по отказу одного узла не реже раза в полугодие.
- Храните узлы в разных физических стойках или дата-центрах для защиты от локальных аварий.
Пример из корпоративной практики
Единая диспетчерская служба города использует DST App на кластере из трех узлов: два в основном дата-центре, один в резервном. При пожаре в основном ДЦ произошло автоматическое переключение на резервный узел за 90 секунд. Потери сообщений не было благодаря синхронной репликации. Диспетчеры продолжили прием заявок, городские службы не заметили сбоя.
Что это и зачем
Временное хранение часто запрашиваемых данных (списки каналов, профили пользователей, настройки) в оперативной памяти. Кэш ускоряет работу системы в десятки раз, снижая нагрузку на базу данных.
Основные возможности
- Выбор типа кэш-хранилища (по умолчанию используется встроенный кэш, но можно подключить выделенный Redis).
- Настройка объема памяти, выделяемого под кэш.
- Установка времени жизни объектов в кэше (TTL).
- Выбор данных, которые кэшируются (сессии, пользователи, каналы).
Рекомендации по применению
- Для крупных развертываний (более 500 пользователей) используйте выделенный сервер Redis.
- Мониторьте процент попаданий в кэш (hit ratio). Если он ниже 80%, увеличьте объем кэша или TTL.
- При перезапуске кэша ожидайте временное снижение производительности (кэш «прогревается»).
Пример из корпоративной практики
В производственной компании с 3 000 пользователей после внедрения Redis для кэширования время загрузки списка каналов сократилось с 2,5 секунд до 0,3 секунды. Процент попаданий в кэш — 92%. При плановом перезапуске Redis система работала медленнее первые 10 минут, но бизнес-критичные процессы не пострадали.
Что это и зачем
Механизм, ограничивающий количество запросов или действий от одного пользователя или IP-адреса в единицу времени. Защищает систему от злонамеренных атак (DDoS, брутфорс) и от случайных перегрузок (например, бот, отправивший 10 000 сообщений за минуту).
Основные возможности
- Установка лимитов для анонимных (неавторизованных) и авторизованных запросов.
- Настройка отдельных лимитов для различных API-методов (отправка сообщений, поиск, загрузка файлов).
- Исключения для внутренних интеграций и ботов.
- Действия при превышении: блокировка на время, задержка выполнения.
Рекомендации по применению
- Установите более строгие лимиты для операций, требующих ресурсов (поиск, экспорт).
- Для публичных каналов и гостевого доступа лимиты должны быть ниже, чем для сотрудников.
- Ведите журнал превышений для выявления аномальной активности.
Пример из корпоративной практики
В логистической компании при подключении нового партнера через гостевой доступ злоумышленник попытался запустить брутфорс паролей. Настроенное ограничение — 5 неудачных попыток входа за минуту — привело к автоматической блокировке IP-адреса на 15 минут после 10 попыток. Сервер не испытал нагрузки, а служба безопасности получила уведомление о подозрительной активности.
Что это и зачем
Настройка сбора технических логов (логов работы сервера, ошибок, предупреждений). Эти логи необходимы для диагностики сбоев, расследования инцидентов и мониторинга состояния системы.
Основные возможности
- Выбор уровня детализации: debug (максимально подробно), info, warning, error.
- Место хранения логов (локальная файловая система, syslog, внешняя система, например, Graylog или ELK).
- Ротация логов: максимальный размер файла, количество хранимых архивов.
- Фильтрация (не логировать определенные события для снижения объема).
Рекомендации по применению
- В production-среде используйте уровень info или warning. Debug включайте только при поиске конкретной проблемы.
- Храните логи не менее 30 дней, если иное не требуется регуляторами.
- Настройте отправку критических ошибок в систему мониторинга (например, в Telegram-бота или email администратора).
Пример из корпоративной практики
При переходе на новую версию DST App администратор временно включил debug-логирование. В логах обнаружена ошибка подключения к Elasticsearch из-за неправильного порта. Проблема исправлена до того, как пользователи заметили замедление поиска. После исправления уровень логирования возвращен на info. Логи хранятся 60 дней на отдельном сервере с ротацией.
Что это и зачем
Настройка времени жизни сессии (токена авторизации). Определяет, как долго пользователь остается залогиненным без повторного ввода пароля. Баланс между удобством (не нужно часто вводить пароль) и безопасностью (риск перехвата сессии).
Основные возможности
- Время жизни токена доступа (обычно от 1 часа до 7 дней).
- Время жизни refresh-токена (максимальный период, через который потребуется полная повторная аутентификация).
- Автоматический выход при бездействии (таймаут).
- Требование повторной аутентификации для критичных действий (смена пароля, экспорт данных).
Рекомендации по применению
- Для обычных пользователей установите время сессии 8–12 часов (рабочий день), для администраторов — 1–2 часа.
- Настройте выход при бездействии через 30 минут для мобильных устройств и 60 минут для десктопа.
- Для организаций с высокими требованиями безопасности (гостайна, медицина) используйте выход при закрытии браузера.
Пример из корпоративной практики
В медицинском центре врачи работают с DST App на планшетах. Настроена продолжительность сеанса — 4 часа, при бездействии более 15 минут требуется повторный PIN-код. Для администраторов время сессии — 1 час, при бездействии 5 минут — выход. За месяц зафиксировано 0 инцидентов с несанкционированным доступом через оставленные без присмотра устройства.
Что это и зачем
Инструмент сбора метрик о состоянии системы: загрузка CPU, память, дисковые операции, количество активных пользователей, время ответа API. Эти данные можно экспортировать во внешние системы мониторинга (Prometheus, Zabbix, Grafana) для создания дашбордов и алертов.
Основные возможности
- Включение/выключение экспорта метрик.
- Настройка формата метрик (Prometheus — стандарт де-факто).
- Пороговые значения для алертов (например, при загрузке CPU > 80%).
- Интеграция с корпоративной системой мониторинга.
Рекомендации по применению
- Разверните Grafana + Prometheus для визуализации метрик и настройки алертов.
- Определите ключевые показатели (SLI): время ответа API, количество ошибок 5xx, доступность.
- Настройте уведомления ответственных лиц при приближении к критическим порогам.
Пример из корпоративной практики
В ИТ-компании настроен дашборд в Grafana, отображающий активность пользователей в реальном времени, загрузку CPU и базы данных. При превышении порога 70% CPU ответственный администратор получает SMS. Во время акции распродажи нагрузка выросла на 300%, администратор получил предупреждение и за 15 минут добавил ресурсы контейнеру DST App. Пользователи не заметили замедления.
Что это и зачем
Раздел для управления API-доступом и интеграцией с внешними системами. Здесь создаются токены для ботов и приложений, настраиваются вебхуки, ограничивается частота вызовов для API. Раздел предназначен для ИТ-команд, автоматизирующих бизнес-процессы.
Основные возможности
- Включение/отключение REST API.
- Создание и отзыв токенов доступа для интеграций (например, для CRM или системы мониторинга).
- Настройка rate limits для API (отдельно от пользовательских).
- Регистрация вебхуков — URL, на которые DST App будет отправлять события (например, новое сообщение).
- Тестовый режим (песочница) для отладки.
Рекомендации по применению
- Каждой интеграции выдавайте отдельный токен с минимально необходимыми правами (принцип наименьших привилегий).
- Храните токены в защищенных менеджерах секретов (HashiCorp Vault, Azure Key Vault), не в коде.
- Регулярно (раз в квартал) ревизуйте активные токены и отзывайте неиспользуемые.
Пример из корпоративной практики
Крупный ритейлер интегрировал DST App с системой управления заказами (OMS). Создан бот-интегратор с токеном, имеющим право только на отправку сообщений в канал «Заказы_CRM». Через вебхук OMS отправляет уведомления о статусе заказов. Токен ротируется каждые 90 дней. При утечке токена злоумышленник мог бы только отправлять сообщения в один канал, что не представляет угрозы для критичных данных.
Что это и зачем
Политики безопасности, применяемые к мобильным приложениям DST App (iOS, Android). Позволяют защитить корпоративные данные на устройствах сотрудников, особенно если используется BYOD (Bring Your Own Device).
Основные возможности
- Запрет скриншотов и записи экрана внутри приложения.
- Требование PIN-кода, биометрии (Face ID / Touch ID) при каждом открытии приложения.
- Запрет запуска на устройствах с root-доступом (Android) или джейлбрейком (iOS).
- Ограничение на копирование текста из приложения в буфер обмена.
- Возможность удаленной блокировки доступа к данным при утере устройства.
Рекомендации по применению
- Включите запрет скриншотов для каналов с конфиденциальной информацией (финансы, персональные данные).
- Требуйте PIN/биометрию для всех мобильных устройств.
- Разработайте политику: при утере телефона сотрудник обязан немедленно сообщить в ИБ для удаленной блокировки.
Пример из корпоративной практики
В страховой компании сотрудники используют личные смартфоны для работы с клиентами в DST App. Включены политики: запрет скриншотов, обязательная биометрия, приложение не запускается на джейлбрейкнутых устройствах. При попытке сделать скриншот диалога с клиентом приложение показывает черный экран. Это предотвратило утечку персональных данных клиентов, о чем свидетельствует нулевое количество инцидентов за год.
Раздел объединяет параметры, определяющие внешний вид, поведение и функциональные возможности интерфейса DST App для конечных пользователей. Здесь настраиваются брендирование, языковые и региональные параметры, политики уведомлений, правила обмена сообщениями и файлами, а также система глобальных объявлений. Цель раздела — адаптировать мессенджер под корпоративную культуру, требования безопасности и пользовательские предпочтения организации.
Что это и зачем Базовые параметры идентичности и внешнего вида платформы. Позволяют представить DST App как собственный корпоративный инструмент, а не стороннее решение, что повышает доверие сотрудников и узнаваемость бренда.
Основные возможности
- Замена логотипа в интерфейсе (главный экран, окно входа, шапка приложения).
- Настройка цветовой схемы в соответствии с корпоративным стилем (основной цвет, акцентный цвет, фон).
- Изменение названия мессенджера (отображается в заголовке окна, на вкладках браузера, в приложениях).
- Установка URL-адреса сервера (если используется несколько доменов).
- Добавление юридических реквизитов (отображаются в подвале веб-версии или в разделе «О системе»).
Рекомендации по применению
- Используйте логотип в векторном формате (SVG) для корректного отображения на разных экранах.
- Проверьте контрастность выбранных цветов (особенно текста на фоне) для соответствия стандартам доступности (WCAG).
- Укажите контактные данные службы поддержки внутри мессенджера, чтобы пользователи знали, куда обращаться.
Пример из корпоративной практики
Сеть аптек «Фармстандарт» заменила стандартный логотип и зеленую цветовую схему на свой фирменный оранжевый и белый. Название изменено на «Фармстандарт.Чат». При открытии веб-версии сотрудники видят знакомый брендинг, что снизило количество вопросов «а что это за приложение?» и повысило скорость принятия нового инструмента.
Что это и зачем Настройки языка интерфейса, форматов дат, времени и чисел. Необходимы для организаций с филиалами в разных регионах или странах, а также для международных команд.
Основные возможности
- Выбор языка по умолчанию (русский, английский, другие доступные языки).
- Настройка формата даты (ДД.ММ.ГГГГ / ММ/ДД/ГГГГ), времени (12h / 24h), первого дня недели.
- Формат чисел (десятичный разделитель — точка или запятая).
- Возможность автоматического определения языка пользователя на основе настроек браузера или профиля.
Рекомендации по применению
- Для российских компаний используйте по умолчанию русский язык, формат даты ДД.ММ.ГГГГ и 24-часовой формат времени.
- Если в компании работают иностранные сотрудники или подрядчики, добавьте английский язык и разрешите пользователям выбирать.
- Синхронизируйте часовой пояс с сервером, если все сотрудники в одной локации; для распределенных команд позвольте каждому пользователю задавать свой часовой пояс.
Пример из корпоративной практики
Международный логистический холдинг с офисами в Москве, Алматы и Минске настроил локализацию: основной язык — русский, но для казахстанского филиала добавлен казахский язык. Часовые пояса заданы пользовательские. Сотрудники в Алматы видят время сообщений по местному времени, что исключает путаницу при оперативной диспетчеризации.
Что это и зачем Глобальные правила, регулирующие создание и управление учетными записями и командами (пространствами). Позволяют централизованно задать политики, предотвращающие хаотичный рост числа команд и бесконтрольное создание каналов.
Основные возможности
- Определение того, кто имеет право создавать команды: только администраторы, или также менеджеры, или все пользователи.
- Настройка автоматического добавления новых пользователей в обязательные команды (например, «Общий чат компании», «Новости»).
- Политики именования пользователей (например, обязательно использование реального имени и фамилии).
- Ограничение на создание команд одним пользователем (максимальное количество).
- Настройка видимости списка пользователей в организации (только для своих или для всех команд).
Рекомендации по применению
- Для крупных организаций (более 500 сотрудников) ограничьте право создания команд только администраторами или назначенными менеджерами, чтобы избежать «мусора».
- Внедрите обязательную верификацию корпоративной электронной почты при регистрации.
- Назначьте владельцев команд, ответственных за регулярную очистку и архивацию.
Пример из корпоративной практики
В розничной сети (3 000 сотрудников) право создавать команды было дано только руководителям филиалов и отделов. За квартал было создано 15 новых команд вместо 200 (как в первый месяц, когда право было у всех). Это сократило навигационный шум и упростило администрирование. Новые пользователи автоматически добавляются в команду «Корпоративные новости» и в команду своего филиала.
Что это и зачем Пользовательские предпочтения по умолчанию для всех новых учетных записей. Определяют, какие уведомления и как получают сотрудники при первом входе. Каждый пользователь может изменить настройки для себя, но разумные значения по умолчанию снижают количество жалоб на информационный шум.
Основные возможности
- Тип уведомлений по умолчанию: все сообщения, только упоминания и прямые сообщения, либо ничего.
- Настройка звуковых уведомлений (включены/выключены по умолчанию).
- Настройка уведомлений на десктопе (показывать всплывающие окна).
- Период «не беспокоить» по умолчанию (например, с 22:00 до 08:00).
- Правила для конкретных каналов (можно переопределить глобальные настройки).
Рекомендации по применению
- Для большинства сотрудников рекомендуется значение по умолчанию «только упоминания и прямые сообщения». Это снижает отвлечение при активной работе в каналах.
- Для критических каналов (например, «Служба безопасности», «Аварийный штаб») установите переопределение — уведомлять обо всех сообщениях.
- Проведите обучающую рассылку о том, как настроить уведомления индивидуально.
Пример из корпоративной практики
В консалтинговой компании после внедрения DST App сотрудники жаловались на постоянные отвлечения из-за уведомлений по каждому сообщению в общих каналах. Администратор изменил глобальную настройку по умолчанию на «только упоминания». Жалобы прекратились, при этом срочные вопросы по-прежнему доставляются через упоминания @username.
Что это и зачем Технические параметры доставки уведомлений на уровне всей инфраструктуры. В отличие от пользовательских настроек, здесь управляется надежность, приоритеты и каналы доставки (push, email, десктоп). Раздел для системных администраторов и службы эксплуатации.
Основные возможности
- Настройка очереди уведомлений и повторных попыток при сбое доставки.
- Приоритеты уведомлений (критические — доставляются всегда, обычные — могут накапливаться).
- Шаблоны уведомлений для email (можно кастомизировать).
- Политика минимизации данных: показывать или скрывать текст сообщения в push/email уведомлениях.
- Настройка fallback-канала (если push не доставлен, отправить email).
Рекомендации по применению
- Для конфиденциальных каналов (финансы, персональные данные) отключите отображение текста сообщений в push-уведомлениях на мобильных устройствах.
- Настройте мониторинг очереди уведомлений — при накоплении более 1000 неотправленных сообщений формируйте алерт.
- Используйте отдельный почтовый сервер для email-уведомлений, чтобы не смешивать с оперативной перепиской.
Пример из корпоративной практики
В банке для каналов с информацией, составляющей банковскую тайну, в настройках системы уведомлений установлено: в push-уведомлениях отображается только «Новое сообщение в канале [название]», без текста. Это соответствует требованиям регулятора и снижает риск утечки при компрометации мобильного устройства.
Что это и зачем Настройки использования эмодзи и пользовательских стикеров. Смайлики — важный элемент неформальной коммуникации, который повышает вовлеченность, но может требовать модерации в корпоративной среде.
Основные возможности
- Включение/отключение пользовательских (кастомных) смайликов.
- Загрузка собственных наборов стикеров (например, с корпоративной символикой).
- Модерация загружаемых смайликов (предварительное одобрение администратором).
- Ограничения по размеру и формату файлов для смайликов.
- Возможность полного отключения смайликов (при строгой корпоративной политике).
Рекомендации по применению
- Разрешите кастомные смайлики, но включите модерацию — это предотвратит загрузку нежелательного контента.
- Загрузите набор корпоративных реакций («в работе», «одобрено», «требуется внимание») для быстрых откликов.
- Для госорганизаций и строгих корпоративных культур рассмотрите отключение кастомных смайликов, оставив только стандартные эмодзи.
Пример из корпоративной практики
Креативное агентство загрузило в DST App собственные стикеры с маскотами компании и набор смайликов для быстрой обратной связи по проектам («правки незначительные», «требуется доработка», «принято»). Вовлеченность сотрудников в обсуждениях выросла, а время на формулировку статуса задачи сократилось.
Что это и зачем Правила, регулирующие создание, редактирование и удаление сообщений. Позволяют управлять порядком в переписке и соответствовать требованиям аудита (например, запрет на неограниченное редактирование истории).
Основные возможности
- Разрешить или запретить редактирование сообщений после отправки.
- Лимит времени на редактирование (например, в течение 5 минут после отправки).
- Разрешить или запретить удаление сообщений (своих и чужих — в зависимости от прав).
- Ограничения на форматирование (Markdown, ссылки, встраивание кода).
- Включение/отключение обсуждений (веток обсуждения для организации диалогов).
Рекомендации по применению
- Для соблюдения требований комплаенса (152-ФЗ, GDPR) рекомендуется установить лимит на редактирование (например, 15 минут) и запретить безлимитное удаление сообщений (или вести журнал удалений).
- Обсуждения полезны для команд с высокой интенсивностью общения — они не дают «забыть» важный вопрос в общем потоке.
- При отключении обсуждений все сообщения отображаются линейно, что проще для небольших команд.
Пример из корпоративной практики
В юридической компании настроено: редактирование сообщений возможно только в течение 5 минут, удаление сообщений разрешено, но все факты удалений фиксируются в журнале аудита. Это позволило соблюсти требование о неизменяемости переписки по делам, находящимся в производстве, и при этом оставить сотрудникам возможность исправлять опечатки.
Что это и зачем Возможность визуальной маркировки сообщений и файлов в соответствии с уровнем конфиденциальности или категорией информации. Помогает пользователям осознавать, с какими данными они работают, и соблюдать политики безопасности.
Основные возможности
- Создание шаблонов меток (например, «Внутреннее использование», «Конфиденциально», «Для служебного пользования»).
- Автоматическое применение меток к каналам (все сообщения в канале имеют метку).
- Возможность ручного добавления метки пользователем при отправке сообщения.
- Водяные знаки при экспорте или скриншотах (если включено).
- Разные цвета и иконки для визуального распознавания.
Рекомендации по применению
- Согласуйте уровни маркировки со службой информационной безопасности.
- Для каналов с конфиденциальной информацией установите обязательную метку, которую пользователь не может снять.
- Интегрируйте метки с политиками DLP (систем предотвращения утечек), если это предусмотрено интеграцией.
Пример из корпоративной практики
В оборонном предприятии созданы метки: «Секретно», «Для служебного пользования», «Открыто». Каналы с обсуждением госконтрактов имеют обязательную метку «Секретно», которая отображается красным фоном в заголовке. При попытке скопировать сообщение или сделать скриншот в системе формируется событие аудита. Это соответствует требованиям режимно-секретного подразделения.
Что это и зачем Политики, регулирующие загрузку файлов в мессенджер и их последующее распространение. Позволяют контролировать риски, связанные с передачей вредоносного ПО, превышением квот хранилища и утечкой данных.
Основные возможности
- Разрешенные типы файлов (например, только документы, изображения, архивы — запрещены исполняемые файлы).
- Максимальный размер одного файла.
- Общая квота хранилища на пользователя или команду.
- Антивирусная проверка загружаемых файлов (если интеграция настроена).
- Возможность пересылки файлов за пределы команды/компании.
Рекомендации по применению
- Запретите загрузку исполняемых файлов (.exe, .scr, .bat) — это снижает риск распространения вредоносного ПО.
- Установите максимальный размер файла в 100–200 МБ, если нет потребности в больших объемах.
- Включите антивирусную проверку для всех загружаемых файлов, если это предусмотрено инфраструктурой.
Пример из корпоративной практики
В производственной компании запретили загрузку видеофайлов (размер часто превышал 500 МБ) и исполняемых файлов. Для передачи больших объемов данных используется отдельный файловый сервер. В результате нагрузка на хранилище DST App снизилась на 60%, а скорость работы интерфейса выросла.
Что это и зачем Возможность создавать публичные ссылки на файлы или сообщения для внешних получателей (партнеров, клиентов). Дает удобный способ поделиться информацией с теми, у кого нет учетной записи в DST App, но требует контроля для предотвращения утечек.
Основные возможности
- Включение/отключение функции публичных ссылок глобально.
- Установка срока действия ссылки (например, 7 дней).
- Требование пароля для доступа к публичной ссылке.
- Водяные знаки на файлах, открытых через публичную ссылку.
- Журнал создания и использования публичных ссылок.
Рекомендации по применению
- Для организаций с высокими требованиями безопасности полностью отключите публичные ссылки.
- Если функция нужна, установите короткий срок жизни (7–14 дней) и обязательный пароль.
- Назначьте ответственного за аудит журнала публичных ссылок — кто, когда и какую ссылку создал.
Пример из корпоративной практики
Страховая компания использует публичные ссылки для обмена полисами с клиентами. Срок жизни ссылки — 3 дня, пароль отправляется клиенту отдельно. При попытке открыть ссылку после истечения срока доступ блокируется. Журнал показывает, что за месяц создано 250 ссылок, из них использовано 180. Ни одной утечки не зафиксировано.
Что это и зачем Инструмент для публикации глобальных сообщений, которые видят все пользователи при входе в систему или на определенных страницах. Используется для информирования о технических работах, изменениях политик, корпоративных событиях.
Основные возможности
- Создание объявления с заголовком, текстом, датами начала и окончания показа.
- Выбор места показа (главный экран, панель уведомлений, всплывающее окно).
- Возможность требования подтверждения прочтения (пользователь должен нажать «Ознакомлен»).
- Приоритеты объявлений (критическое всегда поверх остальных).
- История всех объявлений с указанием автора.
Рекомендации по применению
- Используйте объявления для плановых уведомлений о технических работах (не менее чем за 3 дня).
- Для критических сообщений (сбой сервера, эвакуация) используйте приоритет «Высокий» и подтверждение прочтения.
- Не публикуйте более одного активного объявления одновременно, чтобы не перегружать пользователей.
Пример из корпоративной практики
Перед плановым обновлением сервера администратор создал объявление с текстом «15 мая с 23:00 до 01:00 мессенджер будет недоступен». Объявление показывалось при входе в систему за 3 дня до события и требовало подтверждения прочтения. К моменту начала работ 98% активных пользователей подтвердили ознакомление. Жалоб на внезапную недоступность не поступало.
Раздел управляет процессами регистрации, входа в систему и подтверждения личности пользователей. Здесь настраиваются методы аутентификации — от классических паролей до многофакторной аутентификации (MFA) и интеграции с корпоративными каталогами (AD/LDAP) и протоколами единого входа (SAML, OIDC). Также регулируется гостевой доступ для внешних участников. Правильная конфигурация данного раздела обеспечивает баланс между удобством работы сотрудников и требованиями информационной безопасности.
Что это и зачем
Определяет, каким образом новые пользователи получают учетные записи в системе. Гибкие настройки регистрации позволяют организовать как открытое приглашение (по ссылке или email), так и строго контролируемый процесс с ручным утверждением.
Основные возможности
- Режим регистрации: открытая (любой желающий), по приглашению (только по ссылке), с одобрением администратором.
- Ограничение доменов электронной почты (например, только @company.ru).
- Автоматическое присвоение ролей и добавление в команды при регистрации.
- Настройка капчи или других механизмов защиты от ботов.
- Возможность полного отключения самостоятельной регистрации (учетные записи создаются только администратором или через AD/LDAP).
Рекомендации по применению
- Для корпоративного использования всегда ограничивайте регистрацию корпоративными доменами почты.
- Если не используется интеграция с AD/LDAP, включите режим «по приглашению» или «с одобрением администратором».
- Для госорганизаций и финансового сектора предпочтительнее полное отключение самостоятельной регистрации — учетные записи создаются централизованно.
Пример из корпоративной практики
В банке самостоятельная регистрация отключена. Новые сотрудники заносятся в систему через интеграцию с Active Directory при оформлении в отделе кадров. Это гарантирует, что доступ к корпоративному мессенджеру имеют только действующие сотрудники, а все учетные записи проходят согласование с ИБ.
Что это и зачем
Настройки, связанные с использованием электронной почты в качестве идентификатора пользователя и способа подтверждения действий (регистрация, сброс пароля, уведомления). Email-адрес служит основным идентификатором учетной записи.
Основные возможности
- Требование подтверждения email-адреса при регистрации (отправка ссылки с кодом).
- Возможность смены email-адреса пользователем (требует повторного подтверждения).
- Ограничение на использование одноразовых или публичных почтовых сервисов (gmail.com, mail.ru и т.п.) — разрешены только корпоративные домены.
- Политика повторного использования email (например, запрет на регистрацию нового аккаунта с ранее использованным email после увольнения).
Рекомендации по применению
- Всегда включайте подтверждение email для предотвращения регистрации с чужими адресами.
- Для корпоративного использования настройте белый список доменов (например, @company.ru, @subsidiary.ru).
- При интеграции с AD/LDAP политики email синхронизируются с каталогом — ручная смена не требуется.
Пример из корпоративной практики
В розничной сети, где сотрудники часто переходят между магазинами, настроено: регистрация только на корпоративный email (домен @5ka.ru). При увольнении сотрудника его email блокируется в AD, и DST App автоматически деактивирует учетную запись. При повторном приеме создается новая учетная запись, старый email не может быть использован повторно для сохранения чистоты аудита.
Что это и зачем
Политики сложности и срока действия паролей. Позволяют задать требования к парольной защиты, снижая риск взлома учетных записей методом подбора или использования слабых паролей.
Основные возможности
- Минимальная длина пароля (рекомендуется от 8 символов).
- Требование к сложности: наличие заглавных и строчных букв, цифр, специальных символов.
- Запрет использования пароля, содержащего имя пользователя или часть email.
- Срок действия пароля (например, 90 дней) с обязательной сменой по истечении.
- Хранение истории паролей (запрет на повторное использование последних N паролей).
- Блокировка учетной записи после нескольких неудачных попыток входа.
Рекомендации по применению
- Следуйте современным стандартам безопасности (например, рекомендации НКЦКИ): минимальная длина 12 символов, обязательное использование всех типов символов.
- Установите блокировку после 5 неудачных попыток входа на 15 минут.
- Для организаций с высокой степенью защиты (гостайна, финансы) срок действия пароля — не более 60 дней.
Пример из корпоративной практики
В медицинском учреждении настроены требования: пароль не менее 12 символов, обязательно наличие цифр и спецсимволов, срок действия 90 дней. При попытке установить простой пароль вроде «password123» система отклоняет его с пояснением. Частота взломов учетных записей снизилась на 95% по сравнению с периодом отсутствия политик.
Что это и зачем
Требование подтверждения личности с использованием второго фактора (код из приложения-аутентификатора, SMS, аппаратный ключ) помимо пароля. МФА критически повышает защиту от компрометации пароля, особенно для административных и привилегированных учетных записей.
Основные возможности
- Включение обязательной МФА для всех пользователей или выборочно (для ролей, групп).
- Выбор методов: TOTP (Google Authenticator, Microsoft Authenticator), SMS-код, аппаратные ключи (FIDO2).
- Резервные коды для восстановления доступа при утере устройства с аутентификатором.
- Политика принудительной настройки МФА при первом входе.
- Возможность временного отключения МФА администратором (при утере телефона сотрудником).
Рекомендации по применению
- Обязательно включите МФА для всех администраторов и пользователей, имеющих доступ к конфиденциальным каналам.
- Для крупных организаций рекомендуемый метод — TOTP через корпоративный менеджер паролей или выделенное приложение.
- Храните резервные коды в защищенном месте (например, в сейфе или в менеджере корпоративных секретов).
Пример из корпоративной практики
В государственной организации обязательная МФА введена для всех сотрудников, работающих с документами ограниченного доступа. В качестве второго фактора используется TOTP через служебные телефоны. Резервные коды распечатаны и хранятся у руководителя подразделения. За год ни одного инцидента с несанкционированным доступом, даже при попытках фишинга паролей.
Что это и зачем
Интеграция с корпоративным каталогом (Microsoft Active Directory или LDAP-совместимые серверы, например, OpenLDAP, FreeIPA). Позволяет использовать существующие учетные записи сотрудников для входа в DST App, синхронизировать пользователей и группы, автоматически деактивировать доступ при увольнении.
Основные возможности
- Подключение к одному или нескольким серверам AD/LDAP.
- Настройка атрибутов (идентификатор пользователя, имя, email, членство в группах).
- Синхронизация пользователей: импорт при входе (Just-in-Time) или пакетная синхронизация по расписанию.
- Маппинг групп AD/LDAP на команды и роли в DST App.
- Единый выход (Single Logout): при блокировке в AD доступ к DST App также блокируется.
Рекомендации по применению
- Используйте защищенное соединение (LDAPS) для передачи данных.
- Настройте синхронизацию групп — это упростит управление доступом (например, группа «Москва_Финансы» автоматически дает доступ к соответствующей команде).
- Регулярно проверяйте логи синхронизации на предмет ошибок.
Пример из корпоративной практики
Нефтегазовая компания с 15 000 сотрудников интегрировала DST App с Active Directory. При приеме сотрудника кадровая служба создает запись в AD, и в течение часа учетная запись появляется в DST App. При увольнении доступ блокируется автоматически. Сотрудники используют свои доменные пароли, не запоминая отдельные учетные данные для мессенджера.
Что это и зачем
Стандарт федеративной аутентификации, позволяющий организовать единый вход (Single Sign-On — SSO) через корпоративного провайдера удостоверений (например, ADFS, Okta, Keycloak, Яндекс ID для бизнеса). Пользователи входят в DST App, используя свои учетные данные от корпоративного портала или облачного каталога.
Основные возможности
- Настройка подключения к Identity Provider (IdP): указание метаданных, сертификатов.
- Маппинг атрибутов, передаваемых от IdP (имя, email, роли).
- Принудительный SSO: все попытки входа перенаправляются на корпоративный портал.
- Автоматическое создание пользователей при первом входе (JIT provisioning).
- Поддержка SP-инициированного и IdP-инициированного входа.
Рекомендации по применению
- SAML 2.0 предпочтителен для организаций, уже использующих корпоративный SSO (например, через ADFS или Azure AD).
- Включите принудительный SSO для всех сотрудников, чтобы избежать обхода через локальную аутентификацию.
- Настройте автоматическое обновление сертификатов IdP для предотвращения сбоев входа.
Пример из корпоративной практики
Крупный ритейлер использует единый вход через Azure AD. Настроена интеграция SAML 2.0: сотрудник открывает DST App, его перенаправляет на корпоративную страницу входа, где он вводит свой доменный пароль и подтверждает MFA. После успешной аутентификации он попадает в мессенджер. Администратору не нужно создавать отдельные учетные записи, а пользователи экономят время.
Что это и зачем
Современный протокол единого входа, основанный на OAuth 2.0. Более гибкий и простой в настройке по сравнению с SAML. Поддерживается большинством современных провайдеров: Keycloak, Google Workspace, Microsoft Entra ID (бывший Azure AD), а также собственными реализациями.
Основные возможности
- Настройка провайдера: Client ID, Client Secret, URL авторизации и токенов.
- Маппинг атрибутов пользователя из ID-токена или UserInfo endpoint.
- Поддержка автоматического создания пользователей при первом входе.
- Возможность использования refresh-токенов для продления сессии.
- Настройка области (scope) запрашиваемых данных.
Рекомендации по применению
- OpenID Connect — хороший выбор для организаций, использующих современные облачные IdP или Keycloak.
- Храните Client Secret в защищенном месте (менеджер секретов) и регулярно его ротируйте.
- При использовании публичных провайдеров (Google) убедитесь, что это разрешено политикой безопасности.
Пример из корпоративной практики
IT-компания использует Keycloak в качестве корпоративного IdP. DST App настроен на OpenID Connect. При первом входе сотрудник перенаправляется на страницу Keycloak, аутентифицируется (пароль + TOTP), и DST App автоматически создает учетную запись, импортируя имя, email и роль из атрибутов. Управление доступом централизовано в Keycloak, что упрощает администрирование.
Что это и зачем
Специальный тип учетных записей для внешних участников: подрядчиков, партнеров, клиентов. Гостевой доступ изначально ограничен по функциям и видимости, что снижает риски утечки корпоративной информации.
Основные возможности
- Создание гостевых учетных записей с ограниченными правами (без возможности приглашать других, без доступа к списку пользователей компании).
- Ограничение каналов, доступных гостю (только те, куда его явно добавили).
- Установка срока действия гостевого аккаунта (автоматическая блокировка после даты).
- Запрет на загрузку файлов или экспорт сообщений для гостей.
- Отдельные политики именования и уведомлений.
Рекомендации по применению
- Всегда задавайте срок действия для гостевых учетных записей (по умолчанию 30 дней).
- Назначьте владельца, отвечающего за каждого гостя (сотрудник компании). При завершении сотрудничества владелец обязан деактивировать гостя.
- Ограничьте гостям возможность создавать каналы, приглашать других гостей и просматривать профили сотрудников.
Пример из корпоративной практики
Строительная компания привлекает субподрядчиков для проекта. Для каждого субподрядчика создается гостевая учетная запись со сроком действия, равным длительности контракта. Гость имеет доступ только к каналам, связанным с проектом, не видит сотрудников других отделов и не может загружать файлы, превышающие 10 МБ. По окончании контракта учетная запись блокируется автоматически. Благодаря этому коммерческая тайна защищена, а субподрядчики эффективно координируются.
Раздел позволяет подключать дополнительные модули, расширяющие функциональность DST App. Плагины работают в вашем защищенном контуре: все обрабатываемые данные (тексты сообщений, аудио- видеопотоки) не покидают серверы организации. Это ключевое отличие от публичных сервисов, где использование «умных» функций часто означает передачу данных внешним поставщикам.
Что это и зачем
Централизованное управление установленными и доступными для установки плагинами. Здесь вы включаете, отключаете, обновляете и удаляете расширения, а также управляете их правами доступа к данным системы.
Основные возможности
- Просмотр списка установленных плагинов, их версий и статуса (активен / неактивен).
- Включение или отключение плагина без удаления его конфигурации.
- Установка новых плагинов из репозитория (при наличии) или загрузка вручную.
- Настройка разрешений плагина: к каким данным (сообщения, файлы, метаданные) он имеет доступ.
- Обновление плагинов до новых версий с проверкой совместимости.
- Просмотр логов работы плагинов для диагностики ошибок.
Рекомендации по применению
- Устанавливайте только проверенные плагины из доверенных источников. Для госорганизаций рекомендуется внутренняя сертификация плагинов.
- Регулярно обновляйте плагины для получения исправлений безопасности.
- Отключайте неиспользуемые плагины — каждый активный плагин потенциально расширяет атакуемую поверхность.
- Перед обновлением в production протестируйте новую версию на тестовом стенде.
Пример из корпоративной практики
В финансовой организации используется три плагина: «Агенты ИИ» для суммаризации совещаний, «Звонки» для видеоконференций и «Экспорт в архив» для интеграции с системой долговременного хранения. Администратор ежемесячно проверяет наличие обновлений. Плагин «Игры и опросы», установленный по умолчанию, отключен как не соответствующий политике использования. Журнал плагинов регулярно анализируется службой ИБ.
Что это и зачем
Модуль для подключения внутренних моделей искусственного интеллекта (больших языковых моделей), развернутых на серверах организации. Агенты ИИ могут автоматически переводить сообщения, суммаризировать длинные обсуждения, помогать в написании ответов или классифицировать контент — без передачи данных во внешние облака (DST AI, DST AI Efos, ChatGPT, Anthropic и др.).
Основные возможности
- Подключение к одному или нескольким эндпоинтам внутренних LLM (например, через API локально развернутой модели).
- Настройка доступных агентов: переводчик, суммаризатор, ассистент, модератор.
- Определение триггеров: по команде пользователя (например, /summarize), автоматически для длинных тредов, или при обнаружении иностранного языка.
- Политика данных: какие каналы или команды могут использовать агентов ИИ (например, разрешено только в публичных каналах, запрещено в финансовых).
- Настройка степени креативности, объема выходного текста.
- Журнал обращений к ИИ-агентам для аудита.
Рекомендации по применению
- Перед внедрением убедитесь, что развернутая LLM (например, LLaMA, Mistral, Qwen) работает в изолированном контуре и не имеет выхода в интернет.
- Начните с одного-двух агентов (например, суммаризация длинных тредов и автоперевод для международных команд).
- Четко обозначьте пользователям, что ответы генерируются ИИ и требуют проверки человеком при критических решениях.
- Регулярно анализируйте логи на предмет попыток извлечения конфиденциальных данных через ИИ.
Пример из корпоративной практики
Международная производственная компания развернула локальную модель для перевода с русского на английский и обратно. Агент ИИ автоматически определяет язык сообщения и добавляет перевод в виде скрытой подсказки. Также настроен агент суммаризации: в конце каждого рабочего дня в канале «Итоги_проекта» публикуется краткое резюме из 3–5 пунктов по всем сообщениям за день. Данные не покидают сервер компании, затраты на внешние API отсутствуют, а продуктивность международных команд выросла на 25%.
Что это и зачем
Плагин, обеспечивающий аудио- и видеозвонки, а также конференции внутри DST App. В отличие от публичных сервисов (Zoom, Teams, Skype), все медиапотоки и записи звонков остаются на вашей инфраструктуре. Это критически важно для организаций, работающих с персональными данными, врачебной тайной или коммерчески чувствительной информацией.
Основные возможности
- Одноранговые аудио- и видеозвонки.
- Групповые видеоконференции с настраиваемым максимальным количеством участников.
- Запись звонков с возможностью хранения на вашем файловом хранилище.
- Демонстрация экрана и передача файлов во время звонка.
- Интеграция с календарями (при необходимости) для планирования конференций.
- Настройка качества видео (разрешение, битрейт) в зависимости от пропускной способности сети.
- Включение / отключение функций (чат во время звонка, реакции, поднятие руки).
Рекомендации по применению
- Для организаций с высокой нагрузкой на сеть настройте ограничение максимального качества видео (например, 720p вместо 1080p).
- Включите обязательную запись для совещаний, где обсуждаются важные решения, и храните записи в соответствии с политикой хранения данных.
- Для госорганизаций и медицины используйте режим «только аудио» или отключайте видеопотоки по умолчанию для экономии трафика и повышения безопасности.
- Настройте отдельное хранилище для записей звонков с ограниченным доступом.
Пример из корпоративной практики
В медицинском центре внедрены видеозвонки для телемедицинских консультаций. Все звонки записываются, записи шифруются и хранятся 5 лет (согласно законодательству). Плагин настроен на максимальное качество видео 720p, что достаточно для осмотра пациента, но не перегружает сеть. Доступ к записям имеют только лечащий врач и главный врач. Интеграция с расписанием позволяет автоматически создавать конференции к назначенному времени. Внешние сервисы (Zoom, WhatsApp) больше не используются, риски утечки врачебной тайны исключены.
Раздел предназначен для подключения внешних систем, автоматизации рабочих процессов и управления ботами. Интеграции позволяют DST App обмениваться данными с CRM, системами мониторинга, CI/CD, корпоративными порталами и другими сервисами, расширяя возможности мессенджера как центра коммуникаций.
Что это и зачем
Центральный узел для создания и настройки интеграций с внешними системами. Здесь определяются входящие и исходящие вебхуки, слэш-команды, OAuth-подключения и другие точки взаимодействия. Правильное управление интеграциями позволяет автоматизировать уведомления, выполнять действия из мессенджера и синхронизировать данные.
Основные возможности
- Создание входящих вебхуков (URL, на который внешняя система отправляет POST-запросы для публикации сообщений в канал).
- Создание исходящих вебхуков (DST App отправляет HTTP-запрос во внешнюю систему при определенных событиях).
- Настройка слэш-команд (например,
/jira создать задачу текст). - Управление OAuth-приложениями для безопасного доступа внешних сервисов к API DST App.
- Просмотр логов интеграций (успешные и неудачные запросы).
- Ограничение скорости для каждой интеграции.
Рекомендации по применению
- Для каждой интеграции создавайте отдельный токен или вебхук с минимально необходимыми правами.
- Регулярно проверяйте логи интеграций на наличие ошибок и аномальной активности.
- Отключайте неиспользуемые интеграции, особенно те, что были созданы для тестовых целей.
- Используйте HTTPS для всех вебхуков и проверку подписи запросов для защиты от подделки.
Пример из корпоративной практики
В ИТ-компании настроен входящий вебхук из системы мониторинга Zabbix: при критическом сбое Zabbix отправляет POST-запрос в канал «IT-аварии». В сообщении указывается хост, тип ошибки и время. Дежурный инженер видит уведомление мгновенно. Также настроена слэш-команда/oncall @username, которая через исходящий вебхук вызывает API системы дежурств и меняет ответственного. Время реакции на инциденты сократилось на 40%.
Что это и зачем
Специальные учетные записи, предназначенные для автоматизированных действий (ботов). Боты могут отправлять сообщения, выполнять команды, интегрироваться с внешними системами. Они отличаются от человеческих пользователей тем, что обычно не имеют пароля и входа через интерфейс, а управляются программно через API.
Основные возможности
- Создание ботов с указанием имени, аватара, описания.
- Генерация токенов доступа для ботов.
- Назначение ботов в каналы (бот может быть участником канала).
- Ограничение прав бота: может ли он отправлять файлы, упоминать пользователей, создавать каналы.
- Просмотр активности бота (количество сообщений, ошибки).
- Отзыв токенов и удаление ботов.
Рекомендации по применению
- Давайте ботам понятные имена с пометкой «[бот]», чтобы пользователи не путали их с живыми сотрудниками.
- Используйте отдельные боты для разных задач (один для CI/CD, другой для опросов, третий для CRM).
- Регулярно ротируйте токены ботов, особенно если бот имеет широкие права.
- Ограничьте права бота только необходимыми действиями: например, бот-уведомитель может только отправлять сообщения, но не читать историю канала.
Пример из корпоративной практики
В логистической компании создан бот «Статус доставки», подключенный к системе управления перевозками. При изменении статуса заказа бот отправляет сообщение в канал клиента: «Заказ №12345 передан в доставку». У бота есть только права на отправку сообщений в определенные каналы. Токен бота хранится в защищенном хранилище секретов и ротируется каждые 90 дней. Клиенты довольны прозрачностью, а нагрузка на колл-центр снизилась.
Что это и зачем
Настройка использования GIF-анимаций в сообщениях. GIF могут оживлять коммуникацию, но также создавать риски (отвлечение, нежелательный контент, нагрузка на хранилище). Раздел позволяет контролировать источники GIF, фильтровать контент или полностью отключать функцию.
Основные возможности
- Включение / отключение поддержки GIF в системе.
- Выбор поставщика GIF (например, GIPHY, Tenor) или использование собственного локального репозитория.
- Ограничение доступа к GIF по доменам (разрешить только корпоративный сервер с одобренными анимациями).
- Фильтрация контента по возрастным рейтингам (PG, PG-13, R) — если поставщик поддерживает.
- Лимит на размер и частоту отправки GIF.
- Журнал использования GIF для аудита (при необходимости).
Рекомендации по применению
- Для строгих корпоративных сред (финансы, госорганы) рекомендуется полностью отключить GIF.
- Для компаний с молодежной культурой разрешите GIF, но с фильтром PG-13 и ограничением частоты (не более 10 GIF в час на пользователя).
- Рассмотрите возможность создания локального репозитория одобренных GIF (например, корпоративные мемы). Это исключит нежелательный контент.
Пример из корпоративной практики
В рекламном агентстве GIF разрешены, но только через корпоративный прокси, который кэширует анимации с GIPHY с фильтром PG. Сотрудники могут обмениваться креативными GIF, но откровенный контент блокируется. Также установлен лимит 20 GIF в день на пользователя для предотвращения спама. Культура общения стала живее, но инцидентов с неуместным контентом не зафиксировано.
Что это и зачем
Настройка правил междоменного обмена данными. CORS определяет, какие веб-домены (например, корпоративный портал, внутренние приложения) имеют право отправлять запросы к API DST App из браузера пользователя. Правильная настройка CORS защищает от атак типа CSRF и несанкционированного доступа к данным мессенджера с внешних сайтов.
Основные возможности
- Указание разрешенных источников (доменов) в формате
https://portal.company.ru. - Разрешенные HTTP-методы (GET, POST, PUT, DELETE) и заголовки.
- Поддержка учетных данных (cookies) в междоменных запросах (разрешить/запретить).
- Максимальное время кэширования preflight-запросов.
- Возможность полного запрета CORS (только запросы с того же источника).
Рекомендации по применению
- Разрешайте только те домены, которые действительно необходимы (например, корпоративный портал, внутренняя CRM).
- Не используйте подстановочный символ
*в production-среде — это разрешает доступ с любого домена. - Для внутренних интеграций через API (не из браузера) CORS не требуется.
- Регулярно пересматривайте список разрешенных доменов, удаляйте устаревшие.
Пример из корпоративной практики
В корпоративном университете DST App встроен в обучающий портал через iframe. Для работы функции «отправить сообщение из портала» настроен CORS: разрешен только доменhttps://learn.company.ru. При попытке встроить мессенджер на левом сайте браузер блокирует запросы, защищая данные сотрудников. Также включена поддержка учетных данных, чтобы сессия пользователя на портале автоматически авторизовывала его в DST App.
Что это и зачем
Настройка возможности встраивания DST App во внешние веб-приложения через iframe, а также встраивания внешнего контента (например, карт, документов, видео) в сообщения DST App. Встраивание позволяет интегрировать мессенджер в корпоративные порталы и обогащать сообщения мультимедийным контентом.
Основные возможности
- Разрешение / запрет встраивания интерфейса DST App на сторонние сайты (через X-Frame-Options и Content-Security-Policy).
- Указание списка доменов, которым разрешено встраивать DST App.
- Настройка отображения в iframe (ограничение функционала: скрыть боковую панель, отключить возможность выхода).
- Разрешение / запрет встраивания внешних ссылок (oEmbed, Open Graph) в сообщения — например, автоматическое отображение превью YouTube, Twitter, карт.
- Белый список доменов для встраивания контента (только доверенные ресурсы).
Рекомендации по применению
- Для большинства организаций встраивание DST App на внешние сайты должно быть запрещено (по умолчанию). Разрешайте только для внутренних порталов.
- Для встраивания внешнего контента в сообщения составьте белый список доменов (например,
youtube.com,company-docs.internal). Это снизит риски фишинга. - В режиме встраивания отключайте функции, которые могут привести к утечке данных (например, экспорт, приглашения).
- Проверьте, что при встраивании сохраняются все политики безопасности (CORS, CSP).
Пример из корпоративной практики
В государственной организации DST App встроен в корпоративный портал сотрудника. Если сотрудник заходит на портал, он видит виджет мессенджера с последними сообщениями. Настроено: встраивание разрешено только с доменаportal.gov.ru. В режиме встраивания отключены кнопки «Пригласить пользователя» и «Экспорт канала». Также в сообщениях разрешено встраивать превью только с доменов, внесенных в белый список (например,maps.rosreestr.ru,docs.gov.ru). Пользователи могут безопасно обмениваться ссылками на внутренние ресурсы, а риски перехода на вредоносные сайты минимизированы.
Раздел обеспечивает соблюдение законодательных требований (152-ФЗ, GDPR, отраслевые стандарты), внутренних политик безопасности и регламентов хранения данных. Здесь настраиваются автоматическое удаление сообщений, экспорт переписки для проверяющих органов, мониторинг нарушений, защищенный журнал аудита и правила использования системы, с которыми соглашаются пользователи. Корректная конфигурация комплаенс-механизмов позволяет организации проходить внешние и внутренние аудиты без штрафов и репутационных рисков.
Что это и зачем
Инструмент автоматического управления сроками хранения сообщений, файлов и других данных в зависимости от типа канала, команды или категории пользователей. Политики хранения помогают соблюдать требования регуляторов (например, хранить переписку с клиентами 3 года, а внутренние обсуждения — 30 дней), экономить дисковое пространство и снижать риски утечки устаревшей информации.
Основные возможности
- Создание отдельных политик для разных каналов, команд или типов контента (сообщения, файлы, аудиозаписи звонков).
- Установка срока хранения (например, 30 дней, 6 месяцев, 3 года, бессрочно).
- Действие по истечении срока: автоматическое удаление, перемещение в архив или отправка на внешнее хранилище.
- Исключения для юридически значимых каналов (например, канал «Совет директоров» — бессрочное хранение).
- Уведомления владельцев каналов о предстоящем удалении данных.
- Журнал примененных политик для аудита.
Рекомендации по применению
- Согласуйте сроки хранения с юридическим отделом и службой ИБ на основе отраслевых и регуляторных требований.
- Для каналов с персональными данными (отдел кадров, зарплатные комитеты) установите минимально необходимый срок хранения.
- Регулярно (раз в полгода) пересматривайте политики: законодательство может меняться, а бизнес-процессы — эволюционировать.
- Тестируйте применение политик на небольшой группе каналов перед массовым развертыванием.
Пример из корпоративной практики
Банк обязан хранить переписку с клиентами по спорным операциям в течение 5 лет. Для канала «Клиентские обращения» установлена политика хранения 5 лет с автоматическим удалением после этого срока. Внутренний чат «Обеденные разговоры» имеет политику хранения 7 дней. В результате объем хранилища сократился на 40%, а требования ЦБ РФ выполняются в автоматическом режиме.
Что это и зачем
Механизм выгрузки сообщений, файлов и метаданных в машиночитаемом формате (JSON, CSV, PDF/A) для предоставления проверяющим органам, внутренних расследований, судебных разбирательств или арбитража. Экспорт комплаенса отличается от обычного экспорта тем, что сохраняет неизменяемость данных и включает все юридически значимые атрибуты (временные метки, автор, IP-адрес при отправке).
Основные возможности
- Выбор каналов, временного периода, авторов для экспорта.
- Форматы выгрузки: JSON (для машинной обработки), PDF/A (для предоставления в суд), CSV (для анализа).
- Включение метаданных: точное время отправки, идентификатор сообщения, IP-адрес отправителя (если логируется), файлы-вложения.
- Возможность добавить цифровую подпись или хеш-сумму для подтверждения неизменности.
- Контроль доступа к функции экспорта: только специальная роль «комплаенс-офицер» или «администратор безопасности».
- Журнал всех экспортов: кто, когда, какие данные выгружал, куда (хеш файла экспорта).
Рекомендации по применению
- Назначьте ограниченный круг лиц, имеющих право на экспорт комплаенса (обычно юристы, ИБ, комплаенс-офицер).
- Храните экспортированные данные в защищенном хранилище с ограниченным доступом.
- При судебных разбирательствах используйте экспорт в PDF/A с цифровой подписью сервера.
- Ведите реестр всех экспортов (автоматически создается в журнале аудита).
Пример из корпоративной практики
В ходе налоговой проверки регулятор запросил переписку между отделом закупок и тремя поставщиками за последние 2 года. Комплаенс-офицер создал экспорт по каналам «Закупки_Поставщик1», «Закупки_Поставщик2», «Закупки_Поставщик3» за период 01.01.2022–31.12.2023. Выгрузка сформирована в формате PDF/A с хешем SHA-256. Налоговая приняла документы без возражений. Время подготовки — 15 минут вместо нескольких дней при ручном сборе.
Что это и зачем
Система автоматического контроля за соблюдением заданных политик безопасности и комплаенс-правил. Мониторинг выявляет потенциальные нарушения (например, отправка файлов с персональными данными в публичный канал, использование неразрешенных внешних ссылок, отключенная MFA у привилегированного пользователя) и оповещает ответственных.
Основные возможности
- Предопределенные и пользовательские правила-триггеры (например, «сообщение содержит паттерн номера паспорта», «файл загружен с внешнего домена»).
- Оповещения при срабатывании: email, внутреннее сообщение в канал комплаенс, webhook в SIEM-систему.
- Уровни критичности: информационное, предупреждение, нарушение.
- Автоматические действия при нарушении: блокировка сообщения, уведомление руководителя, принудительный выход пользователя.
- Панель дашборда с текущими нарушениями и динамикой.
- Отчеты о соблюдении комплаенса за период (еженедельные, ежемесячные).
Рекомендации по применению
- Начните с 5–10 ключевых правил, покрывающих основные риски (утечка ПДн, пересылка коммерческой тайны). Постепенно расширяйте.
- Для каждого правила назначьте ответственного сотрудника (из ИБ или комплаенс-подразделения).
- Избегайте избыточных ложных срабатываний — тестируйте правила на небольшой выборке.
- Интегрируйте оповещения с корпоративной SIEM или SOC для централизованного реагирования.
Пример из корпоративной практики
В медицинской организации настроено правило: если сообщение в любом канале содержит слово «паспорт» и цифры в формате «XXXX XXXXXX», оно блокируется, а отправитель и его руководитель получают уведомление. Также настроен мониторинг на попытки экспорта переписки неавторизованными пользователями. За месяц выявлено 3 попытки отправки паспортных данных в общие чаты (все заблокированы) и одна подозрительная попытка экспорта со стороны уволенного сотрудника (аккаунт немедленно заблокирован). Служба безопасности признала инструмент эффективным.
Что это и зачем
Неизменяемая, защищенная от модификации запись всех ключевых событий в системе: входы пользователей, изменения разрешений, создание/удаление каналов и пользователей, экспорт данных, настройки комплаенс-политик. Журнал аудита — доказательная база для расследований инцидентов и подтверждение соответствия регуляторным требованиям.
Основные возможности
- Автоматическая фиксация событий с указанием времени, пользователя, IP-адреса, типа события, затронутого объекта.
- Защита от модификации: журнал хранится в отдельной базе данных или файлах с контролем целостности (хеши, подписи).
- Фильтрация и поиск по событиям, пользователям, датам.
- Экспорт журнала аудита для внешнего аудита.
- Настройка срока хранения журнала (обычно не менее 1 года, по требованиям — до 5 лет).
- Интеграция с внешними системами управления логами (syslog, SIEM, ELK).
Рекомендации по применению
- Храните журнал аудита на отдельном физическом или логическом носителе, недоступном для обычных администраторов.
- Настройте оповещение при попытке отключения журналирования или изменения конфигурации аудита.
- Периодически (раз в квартал) проверяйте целостность журнала с помощью контрольных сумм.
- Ограничьте доступ к чтению журнала аудита только сотрудниками ИБ и комплаенс.
Пример из корпоративной практики
При плановой проверке ФСТЭК аудитор запросил логи изменений прав доступа за последние 6 месяцев. Администратор экспортировал журнал аудита в защищенный архив. Аудитор проверил контрольные суммы и убедился в неизменности записей. В журнале было зафиксировано каждое добавление пользователя в канал «Секретно», что подтвердило соблюдение политики. Нарушений не выявлено, штрафных санкций избежано.
Что это и зачем
Размещение и управление юридическим документом (офертой, пользовательским соглашением, правилами использования), с которым пользователь обязан согласиться перед началом работы в DST App. Это обеспечивает правовую основу для обработки данных, ответственности за нарушения, соблюдения корпоративных и регуляторных норм.
Основные возможности
- Загрузка HTML- или текстового документа с условиями использования.
- Версионирование: при изменении условий пользователи должны принять новую версию.
- Принудительное принятие условий при первом входе (невозможно продолжить без согласия).
- Журнал согласий: кто, когда, какую версию принял.
- Возможность настроить периодическое подтверждение (например, раз в год).
- Исключения для учетных записей ботов и системных интеграций.
Рекомендации по применению
- Условия должны быть разработаны юристами с учетом специфики деятельности организации и требований законодательства.
- Указывайте в условиях ответственность пользователя за сохранность учетных данных, запрет на передачу доступа третьим лицам, правила публикации контента.
- При изменении условий дайте пользователям разумный срок (например, 30 дней) на ознакомление перед принудительным принятием.
- Храните историю версий и журнал согласий не менее срока исковой давности (обычно 3 года).
Пример из корпоративной практики
Финансовая организация внедрила пользовательские условия, запрещающие передачу конфиденциальной информации через публичные каналы и требующие немедленного уведомления ИБ при компрометации учетной записи. При первом входе каждый сотрудник обязан прочитать и принять условия. После инцидента с утечкой, где сотрудник нарушил запрет, журнал согласий подтвердил, что он принял условия. Дисциплинарное взыскание и судебное разбирательство (при необходимости) имеют юридическое основание.
Экспериментальные функции. см. в разделе "Экспериментальные функции"
DST Global (ООО «ДСТ Глобал», до 2020 года — ООО «Дженерал Офис Технолоджис») — российская, передовая компания-разработчик программного обеспечения, основанная в 2008 году и аккредитованная в Министерстве цифрового развития, связи и массовых коммуникаций Российской Федерации.
| Параметр | Значение |
|---|---|
| Полное наименование | Общество с ограниченной ответственностью «ДСТ Глобал» (ООО «ДСТ Глобал») |
| Год основания | 2008 |
| Адрес | г. Ижевск, ул. Воткинское шоссе, 170Е. Региональный оператор Сколково. Технопарк Нобель |
| Телефон | +7 922 5019164 |
| Аккредитация | ИТ-аккредитация в Минцифры России |
| Портфолио | Свыше 500 реализованных проектов |
| Опыт на рынке | Более 18 лет |
| Официальный сайт | https://dstglobal.ru |
| Официальный репозиторий | github.com/DSTGlobal |
| Центр поддержки | dstglobal.ru/support |
| Почта | info@dstglobal.ru |