Остаточный доступ к файлам: почему ссылки уволенного сотрудника продолжают работать

Ситуация, когда сотрудник покидает компанию, но предоставленные им ранее ссылки на корпоративные документы продолжают функционировать, представляет собой классический пример проблемы «остаточного доступа». В ходе практического исследования было установлено, что поведение ссылок на Яндекс Диске при блокировке учетной записи напрямую зависит от того, где физически располагался файл. Если ссылка была создана на документ, находящийся в собственном хранилище (Диске) уволенного пользователя, то при удалении аккаунта или закрытии доступа к нему содержимое становится недоступным по данной ссылке. Однако если тот же сотрудник создал публичную ссылку на файл, который находился в общей (чужой) папке, принадлежащей другому пользователю или группе, ситуация кардинально меняется. После деактивации учетной записи создателя такая ссылка не аннулируется и продолжает предоставлять доступ к документу любому, у кого она есть.

Техническая механика сохранения прав доступа

Причина такого поведения кроется в архитектуре разрешений облачного хранилища. Когда пользователь делится файлом из своей директории, система привязывает право на просмотр непосредственно к его личной учетной записи как владельца ресурса. Удаление владельца логично влечет за собой отзыв всех выданных им разрешений. Но когда речь идет о файле в чужой папке, текущий аккаунт выступает лишь как один из участников совместной работы, обладающий определенными правами (например, редактор). Создавая публичную ссылку, он генерирует токен доступа, который проверяется системой относительно прав самого файла и политики общего доступа к родительской директории. Поскольку владельцем ресурса является другой субъект, удаление одного из соавторов не затрагивает глобальные настройки видимости документа. Для проверки этого механизма достаточно выполнить простой GET-запрос к API Яндекс Диска без авторизационного токена по URL старой ссылки — сервер вернет статус 200 OK и метаданные файла.

Риски для информационной безопасности организации

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

Проблемы аудита и слепые зоны мониторинга

Традиционные средства контроля, такие как отчеты административного портала Яндекс 360, оказываются бесполезными в данном сценарии. Справка сервиса прямо не описывает такое поведение системы, вводя администраторов в заблуждение. Журналы действий администратора зафиксируют факт блокировки пользователя, но они не покажут список всех публичных ссылок, которые этот сотрудник успел инициировать на чужие ресурсы. Уведомления владельцу целевой папки о том, что один из участников создал общедоступную ссылку, также могут отсутствовать или затеряться в потоке ежедневных оповещений. Это формирует классическую «слепую зону»: служба ИБ уверена, что периметр замкнут, тогда как фактически существует множество точек входа, известных неограниченному кругу лиц. Отсутствие централизованного реестра всех внешних ссылок делает невозможным их своевременный аудит силами стандартных инструментов платформы.

Практические шаги по минимизации рисков

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

Проведение регулярного сканирования общих папок на предмет наличия публичных ссылок (public shares). Эту задачу должны выполнять системные администраторы перед удалением любой рабочей станции или учетки.
Централизованное управление доступом: запрет рядовым сотрудникам создавать публичные ссылки на документы внутри корпоративных директорий. Обмен файлами должен происходить только через приглашения конкретных пользователей по email.
Использование специализированных скриптов или API-инструментов для принудительного отзыва всех активных токенов доступа, связанных с увольняемым идентификатором пользователя, во всей организации, а не только в рамках его личного диска.
Внедрение регламентированной процедуры передачи прав владения критически важными документами руководителю отдела до момента деактивации учетной записи сотрудника.

Как проверить с помощью Perimeter

Платформа Perimeter EASM позволяет выявить подобные риски внешнего контура, связанные с непреднамеренной публикацией данных. Модуль сканирования cloud (S3) и смежные инструменты анализа экспозиции способны обнаруживать открытые объекты хранения и проверять доступность ресурсов по прямым ссылкам. Система проводит инвентаризацию публично доступных эндпоинтов, имитируя действия анонимного пользователя извне. Если в процессе мониторинга Perimeter обнаружит, что по определенной URL-ссылке доступен документ, содержащий ключевые слова вашей компании или специфические метаданные, платформа классифицирует это как инцидент и создаст алерт. Это позволит офицеру безопасности найти ту самую «забытую» ссылку уволенного сотрудника раньше, чем ее найдет злоумышленник.