Управление командой передачи файлов: разрешения и роли

Роскомнадзор вправе проводить плановые и внеплановые проверки компаний, обрабатывающих персональные данные, — а это значит, что журналы передачи файлов должны быть готовы к предъявлению в любой момент. Управление командой по передаче файлов означает определение того, кто может отправлять что, кому, с каким сроком хранения и кто видит логи. Рабочая настройка содержит как минимум четыре роли: администратор (настраивает рабочее пространство), менеджер (одобряет нестандартные запросы), отправитель (рядовые пользователи) и наблюдатель (только аудит). Добавьте SSO через SAML 2.0 или SCIM-провизию от Okta, Azure AD или Google Workspace; применяйте политики DLP к содержимому файлов; фиксируйте события в неизменяемом журнале аудита и подключите всё это к командному плану сервиса передачи, открывающему эти настройки.

Четыре роли для большинства команд

Усложнение ролей создаёт путаницу. Упрощение — порождает теневые ИТ-решения. Рабочая иерархия:

Администратор: провизирует пользователей, настраивает параметры хранения по умолчанию, задаёт правила DLP, управляет биллингом, видит все передачи в рабочем пространстве.
Менеджер: одобряет передачи, отмеченные политикой (свыше 20 ГБ, на внешние домены, содержащие паттерны персональных данных), видит передачи своей команды, не может менять настройки рабочего пространства.
Отправитель: рядовой пользователь. Может создавать передачи до потолка политики, защищать паролем, устанавливать срок в допустимом диапазоне, удалять собственные передачи.
Наблюдатель: роль для соответствия требованиям или безопасности. Доступ только для чтения к журналам аудита по всему рабочему пространству. Не может создавать передачи или изменять конфигурацию.

Сопоставьте с группами вашей директории. Если в Okta уже есть engineering-leads, зеркально отразите это как роль менеджера для инженерных передач вместо создания нового членства.

Провизия через SCIM лучше ручного онбординга

Ручное управление пользователями ломается при 50+ пользователях. SCIM 2.0 (System for Cross-domain Identity Management) позволяет вашему провайдеру идентификации автоматически передавать создание, обновление и деактивацию пользователей в сервис передачи.

Okta, Azure AD, OneLogin и JumpCloud поддерживают SCIM. Настройте один раз — и онбординг нового сотрудника в группу AD marketing автоматически создаёт его аккаунт в сервисе передачи. Офбординг работает в обратную сторону: удаление из AD деактивирует аккаунт в течение минут, закрывая реальный вектор утечки. Большинство аудиторов по соответствию требованиям спросят о свидетельствах автоматического отключения доступа; SCIM — это и есть такое свидетельство.

Гранулярные настройки, которые стоит сконфигурировать

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

Максимальный размер передачи по роли: отправители — 10 ГБ, менеджеры — 50 ГБ, администраторы — 100 ГБ.
Максимальный срок хранения по роли: отправители — 7 дней, менеджеры — 30 дней, администраторы — 90 дней.
Требование пароля: обязательно для любой передачи на внешние домены или с файлами свыше 1 ГБ.
Требование срока действия: нет варианта «не истекает»; жёсткое ограничение в 90 дней.
Ограничение скачиваний: по умолчанию 10 скачиваний на ссылку; отправители могут повысить до 50 с кодом причины.
Географическое ограничение: блокируйте загрузку или скачивание из стран за пределами ваших операционных регионов, если это требует соответствие нормативам.

Задокументируйте настройки по умолчанию в одностраничной политике и покажите их в интерфейсе передачи, чтобы пользователи видели правила в момент отправки.

DLP без удара по производительности

Предотвращение потери данных при передаче содержимого ловит отправки, которые вы не намеревались разрешать. Типичные паттерны:

Обнаружение персональных данных на основе регулярных выражений: номера кредитных карт (формат PAN), СНИЛС, номера паспортов РФ, ИНН. Блокировать или требовать утверждения менеджера.
Списки ключевых слов: «конфиденциально», «коммерческая тайна», «слияние», «только для внутреннего использования». Отметить для проверки.
Ограничения типов файлов: блокировать .exe, .dll, .msi для большинства ролей; блокировать .pst и .ost кроме как для экспорта в целях соответствия.
Хеширование содержимого: сравнивать хеши файлов со списком известно-конфиденциальных документов (протоколы заседаний совета, выпуски исходного кода). Блокировать или уведомлять.

Ловушка — ложные срабатывания. Агент клиентского сервиса, отправляющий тестовые номера кредитных карт для обучения, не должен блокироваться. Настраивайте правила DLP в «теневом режиме» (только уведомления, без блокировки) в течение двух недель до начала применения.

Журналы аудита, которыми воспользуется команда по соответствию

Журналы аудита ценны только при условии захвата нужных событий и их регулярного просмотра. Фиксируйте как минимум:

События аутентификации пользователей (вход, вызов MFA, перенаправление SSO).
Создание передачи (пользователь, домен получателя, хеши файлов, размер, срок, установлен ли пароль).
События скачивания (IP, user agent, временная метка, успех/неудача).
Нарушения политики (попытка загрузить слишком большой файл, совпадение DLP, попытка обойти ограничение срока).
Изменения конфигурации (кто что изменил, старое и новое значение).

Храните логи от 1 до 7 лет в зависимости от режима: 7 для SOX, 6 для HIPAA, 5 для требований 152-ФЗ. Экспортируйте в свою SIEM (Splunk, Datadog, Elastic), чтобы события были рядом с остальной телеметрией безопасности. Ежеквартальный просмотр логов ролью наблюдателя обнаруживает дрейф — кто-то с повышенной ролью, которой у него не должно быть, обход правила DLP, ставший привычкой, паттерны крупных передач в нерабочее время.

Аналитика использования, которая помогает принимать решения

Панели администратора должны отвечать на вопросы, а не просто показывать графики. Полезные метрики:

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

Просматривайте ежемесячно. Убирайте неиспользуемые лицензии, выявляйте аномалии и возвращайте паттерны в обновления политики.

Внешние соавторы без открытия дверей

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

Ссылки-запросы: администратор или отправитель генерирует одностороннюю ссылку для загрузки со списком разрешённых получателей и сроком. Загрузчику не нужен вход, но загрузки попадают в рабочее пространство отправителя.
Гостевые аккаунты: именной внешний пользователь с SSO через собственный провайдер идентификации (B2B-федерация). Сложнее в настройке, подходит для долгосрочных взаимодействий.
Анонимные папки для загрузки: полезны для публичных отправок (соискатель работы с портфолио), но требуют агрессивного сканирования на вредоносное ПО и ограничений по размеру.

Выбирайте наилегчайший вариант, подходящий для задачи. Ссылки-запросы покрывают 80% внешнего сотрудничества.

Политики безопасности, которые стоит записать

Политика передачи умещается на двух страницах. Охватите:

Утверждённые инструменты передачи (и заблокированные — включая личные аккаунты WeTransfer).
Схему классификации (публичный, внутренний, конфиденциальный, ограниченный) с примерами файлов для каждой.
Обязательные средства контроля по классификации (базовое шифрование, требование пароля, максимальный срок, триггер рабочего процесса утверждения).
Обязательства по отчётности (если вы подозреваете, что передача была перехвачена, кому и в какие сроки сообщать).
Аварийный план (утерянный ноутбук с активными ссылками для передачи, скомпрометированный аккаунт, случайная отправка).

Сделайте её читаемой. 30-страничная политика, которую никто не читает, не защищает ничего.

Шифрование и работа с ключами

Базовый уровень, которому должен соответствовать ваш командный план: AES-256-GCM для содержимого в состоянии покоя, TLS 1.3 для транспорта, PBKDF2 с 600 000+ итерациями или Argon2id для ключей на основе паролей. Инструменты, шифрующие на стороне клиента (в браузере, до загрузки), означают, что сервис никогда не хранит открытый текст. HexaTransfer использует эту модель — ключ шифрования хранится во фрагменте URL, который браузер никогда не отправляет на сервер.

Для командных планов проверьте, могут ли администраторы восстановить передачи, если отправитель покидает компанию. Истинное E2EE означает «нет, не без доступа получателя». Это особенность, а не недостаток, если ваша модель угроз предполагает, что сервис может быть обязан предоставить данные.

Гигиена жизненного цикла

Установите ежеквартальные повторяющиеся задачи:

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

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

Попробуйте на https://hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.