Корпоративные знания во внутреннем контуре: пять угроз и способы защиты

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

Представим: компания перенесла базу знаний на собственные серверы и закрыла доступ из интернета. Через месяц выясняется: у подрядчика сохранился доступ к материалам завершённого проекта, бывший сотрудник читает документы в незакрытой сессии, а ИИ-помощник передаёт фрагменты внутренних регламентов внешней модели. Площадка под контролем, но пути доступа к информации и места её обработки никто до конца не проверил.

Разберём пять угроз на примере коробочной версии TEAMLY: где помогает локальное размещение, какие настройки нужны до запуска и что придётся делать всё время, пока система работает.

1. Данные обрабатываются за пределами согласованной инфраструктуры

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

Облачная модель сама по себе не означает слабую защиту. Вопрос в том, соответствуют ли устройство сервиса и договор требованиям компании. Если организация должна самостоятельно определять место обработки данных и контролировать сетевые соединения, стоит рассмотреть On-Premise — установку платформы на собственных серверах или в инфраструктуре под её управлением. При этом компании понадобятся ресурсы на обслуживание: обновления, мониторинг и восстановление.

Коробочная версия TEAMLY поддерживает локальное развёртывание. Заказчик может включить платформу в корпоративную инфраструктуру и определить порядок доступа к ней. Однако физическое положение сервера ничего не говорит о том, куда обращаются интеграции и ИИ-компоненты.

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

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

2. Сотрудник видит документы, которые ему не нужны

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

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

В TEAMLY предусмотрены роли и разграничение доступа к корпоративным материалам. Это позволяет работать с общей базой знаний, ограничивая доступ к отдельным пространствам и документам. Конкретную комбинацию разрешений выбирают под структуру команды и проверяют на пилоте.

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

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

3. Уволенного сотрудника отключили не везде

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

Здесь важна вся последовательность увольнения: кто сообщает об уходе, какие системы получают изменение и когда прекращается доступ. Передаче материалов посвящена статья «Как извлечь знания уходящего эксперта до его увольнения».

В корпоративной TEAMLY предусмотрены интеграция с Active Directory и единый вход через SSO. При проектировании уточняют подключение к каталогу, включая использование LDAP, синхронизацию групп и обработку блокировки. 

На пилоте входят тестовым пользователем с двух устройств, блокируют его в каталоге и пробуют открыть документ. Новый вход и уже действующая сессия могут обрабатываться по-разному. Доступ должен прекратиться в срок, установленный компанией. Также проверяют отзыв локального пароля и персональных токенов, если они используются.

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

4. Подозрительную активность замечают слишком поздно

Администратор открыл конфиденциальное пространство большой группе. Это могло быть ошибкой, согласованным действием или результатом захвата его учётной записи. Чтобы разобраться, службе ИБ нужны записи: кто изменил разрешения, когда, для какого объекта и с каким результатом.

В TEAMLY предусмотрены журналирование и интеграция с SIEM — системой сбора и анализа событий безопасности. Она помогает сопоставить действия в разных приложениях: например, подозрительный вход в корпоративную сеть и последующую смену прав в базе знаний.

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

Получение события не останавливает утечку автоматически. Для сигнала об изменении прав назначают ответственного: он выясняет причину, при необходимости ограничивает доступ и начинает расследование.

Мониторинг массовых выгрузок возможен, только если платформа журналирует такие действия. Сам журнал тоже защищают: в нём могут быть названия закрытых документов.

5. ИИ отправляет внутренние материалы внешнему провайдеру

Сотрудник спрашивает помощника об условиях договора. Система находит фрагменты документа и передаёт их языковой модели для подготовки ответа. Если модель работает у внешнего провайдера, корпоративные сведения могут покинуть согласованную инфраструктуру, даже когда сама база знаний установлена локально.

Для закрытого контура TEAMLY предусмотрен вариант использования ИИ на инфраструктуре заказчика. Локальная языковая модель — LLM — позволяет организовать обработку материалов внутри согласованной среды. Модель, вычислительные ресурсы и состав компонентов определяют при проектировании решения.

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

Второй вопрос — права на источники. ИИ TEAMLY учитывает доступ пользователя к материалам. На пилоте двум аккаунтам с разными разрешениями задают одинаковые вопросы о закрытом проекте. Сравнивают ответы, ссылки и фрагменты: недоступные сотруднику сведения не должны появляться в выдаче.

Устройство такого поиска разобрано в статье «Как заставить AI-ассистента работать с базой знаний в enterprise-компании. RAG-модель в архитектуре».

Что остаётся за компанией после установки

Предположим, база знаний переехала в свой дата-центр, но вся ИТ-служба продолжает пользоваться одним административным аккаунтом. Кто-то изменил права, а журнал показывает общее имя. Если пароль украдут, злоумышленник получит все полномочия. Локальное размещение не устраняет этот риск: нужны персональные аккаунты, ограничения привилегий и защита административного входа.

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

Отдельный процесс — восстановление. Резервные копии должны охватывать данные и компоненты, необходимые для возвращения системы в работу. Их хранят с отдельными ограничениями доступа и восстанавливают в тестовой среде. Файл с копией ещё не доказывает, что приложение запустится с нужными документами и разрешениями. Компания определяет, сколько последних изменений допустимо потерять и как быстро должна заработать база знаний.

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

Что согласовать до развёртывания

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

1. Размещение. Где работают приложение, база данных, хранилище и ИИ; где находятся резервные копии.

2. Доступ. Кто согласует права, пересматривает их после переводов и закрытия проектов, отключает подрядчиков.

3. Авторизация. Как связаны каталог, SSO и платформа; что происходит с сессиями после блокировки.

4. Мониторинг. Какие события получает SIEM, кто разбирает сигналы и ограничивает доступ при инциденте.

5. Эксплуатация. Кто устанавливает обновления, проверяет копии и восстанавливает систему; как подключается поддержка поставщика.

6. Соединения. Какие интеграции нужны, что они получают и как отключаются; где обрабатываются ИИ-запросы.

Как использовать TEAMLY внутри контура

Коробочная версия TEAMLY объединяет работу с корпоративными материалами и обучение сотрудников. Например, команда ведёт проектную документацию, а общие инструкции использует для подготовки курсов.

На этапе внедрения отдельно согласуют поставляемые возможности и настройки заказчика: схему каталога и SSO, модель прав, состав событий для SIEM и конфигурацию ИИ. Для локальной модели определяют ресурсы и маршрут запросов; для API-интеграций — полномочия и передаваемые данные.

Резервное копирование включают в проект как эксплуатационную задачу: с поставщиком уточняют поддерживаемый способ, состав копий и автоматизацию, затем назначают ответственного за проверку восстановления.

Когда система готова к работе

У подрядчика из вводного примера доступ должен прекращаться после закрытия проекта, у уволенного сотрудника — после блокировки, а ИИ-запрос должен обрабатываться по согласованному маршруту. Каждый из этих результатов зависит от конкретной настройки и ответственного за неё.

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