Права доступа в корпоративном портале: внешние пользователи, рабочие группы и утечки через открытые ссылки

Корпоративный портал внедряют ради удобства: документы, задачи, рабочие группы, базы знаний, согласования, файлы для подрядчиков, всё в одном месте. Но чем проще сотруднику нажать кнопку «поделиться», тем выше риск, что договор, клиентская база, финансовый отчет или внутренний регламент однажды окажутся доступны «всем, у кого есть ссылка».
И это не всегда выглядит как кибератака. Иногда утечка начинается буднично: создали рабочую группу, добавили подрядчика, выдали доступ на пару недель, забыли закрыть, потом кто-то отправил публичную ссылку в чат. Через полгода никто уже не помнит, зачем в группе внешний пользователь и почему файл с персональными данными открывается без авторизации.
Почему это вопрос информационной безопасности
Права доступа в портале отвечают на вопрос: кто может увидеть, скачать, изменить, удалить или передать информацию дальше. Если портал содержит персональные данные, договоры, коммерческие предложения, кадровые документы, финансовые материалы, внутренние регламенты или результаты аудитов, управление доступами становится не «админской настройкой», а полноценной мерой защиты информации.
149-ФЗ определяет защиту информации как правовые, организационные и технические меры против неправомерного доступа, копирования, предоставления и распространения информации; обладатель информации и оператор информационной системы в установленных случаях должны предотвращать несанкционированный доступ, вовремя выявлять такие факты и контролировать уровень защищенности.
Если в портале обрабатываются персональные данные, дополнительно работает 152-ФЗ: оператор обязан принимать меры защиты от неправомерного или случайного доступа, копирования, предоставления и распространения ПДн, а также устанавливать правила доступа и обеспечивать регистрацию действий с персональными данными в информационной системе.
Если документы относятся к коммерческой тайне, мало просто сказать «это конфиденциально». 98-ФЗ требует определить перечень такой информации, ограничить доступ к ней, учитывать лиц, получивших доступ, и регулировать использование коммерческой тайны работниками и контрагентами.
Где чаще возникают утечки
Основных проблем обычно три:
Внешние пользователи
Подрядчики, клиенты, аудиторы, интеграторы и партнеры получают доступ к порталу, но их права живут дольше проекта. Договор закрыли, акт подписали, команда разошлась, а внешний пользователь всё еще внутри группы.
Рабочие группы
Группы создаются быстро: под проект, отдел, задачу, согласование, подрядчика. Но закрываются редко. Внутри остаются документы, обсуждения, файлы, внешние участники и бывшие сотрудники. Особенно опасны группы без владельца, если владелец уволился, проект закончился, а доступы никто не пересмотрел.
Открытые ссылки
Публичная ссылка удобна, потому что не требует создавать пользователя и настраивать права. Но именно поэтому она опасна, поскольку ссылка легко уходит в личную почту, мессенджер, чат подрядчика или старую переписку. Формально никто ничего не «взламывал», но доступ вышел из-под контроля.
В некоторых корпоративных платформах в публичных ссылках можно настраивать срок действия, пароль, режим просмотра или редактирования. Например, в Битрикс24 документация прямо указывает, что по умолчанию публичная ссылка открывает документ в режиме просмотра без пароля и ограничения по времени, но эти параметры можно изменить. В Яндекс 360 администратор может ограничивать внешний доступ по ссылкам, включать режим «только внутри организации» и задавать срок действия ссылок.
Как правильно управлять внешними пользователями
Внешний пользователь это не сотрудник. Для портала у него должна быть отдельная роль: гость, подрядчик, внешний участник. Такой роли допустимо видеть только то, что нужно для конкретной работы.
Правильная схема внешнего доступа выглядит так:
- доступ выдается только по заявке;
- в заявке указано, кто внешний пользователь, от какой организации, зачем ему доступ, к каким данным и на какой срок;
- доступ ограничен конкретной группой, папкой, задачей или проектом;
- срок действия обязателен;
- внешний пользователь не может приглашать других людей и создавать публичные ссылки;
- для внешних пользователей включается MFA, если платформа это поддерживает;
- по завершении проекта доступ закрывается автоматически или по обязательной процедуре.
Внешний пользователь должен видеть ровно столько, сколько нужно для работы, и ровно столько времени, сколько эта работа длится. Всё остальное это лишние риски.
Рабочие группы
Рабочей группе необходим владелец, конкретный ответственный, который следит за составом участников, внешними доступами, документами и закрытием группы после завершения проекта.
Для порядка группы можно разделить по типам:
- Открытые внутренние группы — для новостей, мероприятий, общих инициатив. Без конфиденциальных документов и внешних пользователей.
- Закрытые внутренние группы — для отделов и проектов, где доступ нужен ограниченному кругу сотрудников.
- Проектные группы с внешними участниками — для работы с подрядчиками и партнерами. Срок действия доступа обязателен, состав участников пересматривается.
- Группы с чувствительными данными — персональные данные, финансы, юридические документы, ИБ-инциденты, аудиты, коммерческая тайна. Внешний доступ здесь либо запрещен, либо выдается только по отдельному согласованию.
Если группа завершила задачу, ее нужно архивировать. Если владелец уволился, то передать новому владельцу или закрыть. Если в группе есть внешние участники, регулярно проверять, актуален ли их доступ.
На практике это особенно важно в современных корпоративных порталах, где проект это уже не просто список задач. Например, в современном корпоративном портале проектное пространство может объединять чаты, задачи, файлы, встречи и другие инструменты командной работы. В такие пространства часто можно приглашать внешних участников, подрядчиков, клиентов или партнеров, а сам доступ может быть открытым для всех сотрудников компании либо закрытым только для приглашенных участников. Это удобно, но с точки зрения ИБ важно помнить, что в зависимости от настроек пользователь может получить доступ к задачам, файлам и истории обсуждений в пределах своих прав.
Поэтому права в таких пространствах нужно настраивать отдельно и осознанно: кто может приглашать участников, кто видит задачи проекта, кто может изменять или удалять материалы, кто управляет сообщениями, а права к файлам и календарю проверять отдельно.
Открытые ссылки
Открытая ссылка это разрешение на доступ, завернутое в URL. Поэтому правила должны быть жесткими:
- публичные ссылки запрещены по умолчанию;
- для внешнего доступа ссылка должна иметь срок действия;
- для чувствительных документов нужен пароль;
- пароль нельзя отправлять тем же сообщением, что и ссылку;
- редактирование по публичной ссылке только как редкое исключение;
- для документов с ПДн, коммерческой тайной, финансовыми и кадровыми данными публичные ссылки лучше запретить полностью;
- все активные публичные ссылки должны попадать в регулярный отчет.
Отдельно важно контролировать права по умолчанию. Если любой сотрудник может создать публичную ссылку, открыть документ на редактирование или добавить внешнего пользователя, компания фактически работает на доверии всем. Это удобно, но безопасность обычно плачет в углу.
Безопаснее настроить так, чтобы по умолчанию был просмотр, внешний доступ запрещен или ограничен, срок действия обязателен, управление доступом только у владельца документа и ограниченного круга администраторов.
Минимальная классификация документов
Нельзя нормально управлять доступом, если все документы в портале одинаковые. Нужна простая классификация, понятная не только безопаснику, но и обычному пользователю:
- Публичные материалы — то, что можно отправлять вовне после проверки: презентации, пресс-релизы, открытые инструкции.
- Внутренние материалы — регламенты, внутренние новости, общие документы отделов, доступ только у сотрудников.
- Конфиденциальные материалы — договоры, коммерческие предложения, проектные документы, внутренняя аналитика, доступ только определенным группам.
- Персональные данные — клиентские базы, кадровые документы, обращения, анкеты, выгрузки из CRM, доступ только тем, кому это нужно по роли.
- Критичные документы — ИБ-инциденты, результаты аудитов, схемы инфраструктуры, уязвимости, ключи, токены, резервное копирование, внутренние расследования. Публичные ссылки запрещены.
Классификация должна помогать сотруднику быстро понять, можно ли делиться файлом, с кем, как и на какой срок.
Что делать, если ссылка уже утекла
Если обнаружили, что документ был доступен по открытой ссылке, нужно зафиксировать и локализовать ситуацию:
- Зафиксировать время обнаружения.
- Сохранить ссылку, параметры доступа, владельца, историю изменений и логи.
- Отключить ссылку или ограничить доступ.
- Определить, какие данные были доступны.
- Проверить обращения к документу: время, IP, учетные записи, скачивания.
- Понять, есть ли в документе персональные данные, коммерческая тайна или иная конфиденциальная информация.
- Подключить ИБ, юристов, владельца данных и руководство.
- Устранить причину: настройки, процесс, обучение, права или отсутствие владельца.
Если инцидент связан с неправомерной или случайной передачей, предоставлением, распространением или доступом к персональным данным и повлек нарушение прав субъектов, оператор обязан уведомить Роскомнадзор: в течение 24 часов о факте инцидента, причинах, возможном вреде и принятых мерах; в течение 72 часов о результатах внутреннего расследования. Такая форма уведомления размещена на портале персональных данных Роскомнадзора.
Не каждая забытая ссылка автоматически означает утечку ПДн. Но каждая такая ситуация должна быть проверена и зафиксирована.
Заключение
Корпоративный портал должен помогать работать, для этого внешние пользователи должны быть отдельной управляемой категорией, рабочие группы должны иметь владельца и срок жизни, а открытые ссылки использоваться только как исключение и с ограничениями.
Утечка через портал редко выглядит как сложная атака. Чаще она выглядит как обычная кнопка «Поделиться», нажатая без правил. А если у вас еще остались вопросы, «Астрал. Безопасность» всегда готовы с этим помочь!
Автор статьи: Филиппова Анастасия, специалист по информационной безопасности «Астрал. Безопасность».



