Как безопасно передать пароль подрядчику или партнёру
Как безопасно передать пароль подрядчику или партнёру
Подрядчик просит доступ к рекламному кабинету. Партнёр нуждается в учётных данных от тестовой среды. Аудитор запрашивает временный вход в систему. Это стандартные рабочие ситуации, с которыми сталкивается любая компания.
Вопрос в том, как это делается на практике. В большинстве случаев ответ — сообщение в Telegram или письмо на почту: «Вот логин: admin, пароль: CompanyName2024». Быстро, удобно и небезопасно по целому ряду причин.
Кажется, что переслать пароль в личном сообщении — мелочь. Но за этой мелочью стоит целый набор проблем.
Пароль остаётся в переписке навсегда. Сообщение в Telegram, WhatsApp или Slack хранится в истории чата. Через полгода, когда подрядчик уже давно закончил работу, пароль всё ещё лежит там — и если переписка попадёт не туда, скомпрометирован будет актуальный доступ.
Вы не знаете, что получатель сделал с паролем. Подрядчик мог переслать его коллеге, сохранить в заметках телефона, записать на листок. Пароль вышел за пределы вашего контроля — и вы об этом не знаете.
Нет аудита. Невозможно понять, кто в итоге воспользовался доступом, когда и сколько раз. Если что-то пойдёт не так — расследовать инцидент будет крайне сложно.
Пароль не меняется после передачи. После того как работа с подрядчиком завершена, кто-то должен вспомнить, что надо сменить этот пароль. На практике об этом часто забывают — особенно если подрядчиков много и они меняются.
Мессенджеры не предназначены для передачи секретов. Даже зашифрованные мессенджеры не дают гарантии того, что сообщение с паролем не будет сохранено на устройстве, скопировано или случайно показано постороннему.
Что происходит с доступами подрядчиков в типичной компании
Картина, которую обнаруживают при аудите доступов, почти всегда одинакова.
Подрядчик попросил доступ к рекламному кабинету три года назад. Тогда ему скинули пароль в Telegram. Сотрудничество закончилось через два месяца, но пароль никто не менял — потому что этого не было в чеклисте, а потом просто забыли. Сейчас этот пароль по-прежнему работает. Где он хранится у бывшего подрядчика — неизвестно.
Умножьте этот сценарий на десять подрядчиков в год на протяжении нескольких лет — и получите типичную картину неуправляемых доступов, которая рано или поздно приводит к инциденту.
Правильные способы передать пароль внешнему лицу
Способ 1. Одноразовая ссылка (Shared Link)
Это наиболее удобный и безопасный способ для передачи пароля подрядчику. Принцип работы простой: вы генерируете защищённую ссылку, которая действует ограниченное время или сгорает после первого просмотра. Подрядчик открывает ссылку, видит пароль — и ссылка становится недействительной.
Что это даёт:
Пароль не хранится в переписке — в чате есть только ссылка, которая уже не работает. Вы видите, когда ссылка была открыта. Если ссылка не была открыта в ожидаемое время — что-то пошло не так. Можно установить срок действия: ссылка автоматически истекает через час, день или неделю. При необходимости ссылку можно отозвать до того, как её откроют.
В BearPass функция Shared Links работает именно так: вы создаёте временную ссылку на конкретный элемент, указываете срок действия и получаете URL, который можно безопасно отправить подрядчику любым каналом — в мессенджере, по почте, в задаче трекера.
Способ 2. Временный доступ к папке
Если подрядчику нужен доступ не к одному паролю, а к набору учётных данных (например, доступы к нескольким сервисам для проведения работ), удобнее создать отдельную папку в менеджере паролей и выдать на неё временный доступ.
Подрядчик получает приглашение в систему с доступом только к нужной папке, работает с учётными данными в рамках выделенного пространства, не видит ничего лишнего. По завершении работ доступ отзывается одним кликом — или автоматически по истечении заданного срока.
Все действия подрядчика в системе фиксируются в журнале событий: когда входил, какие пароли открывал. Это важно и для внутреннего аудита, и на случай разбора инцидента.
Способ 3. Создание отдельного аккаунта для подрядчика
Для долгосрочного сотрудничества — когда подрядчик работает с вами месяцами — правильнее создать ему отдельную учётную запись в системе с чётко ограниченными правами.
Это даёт полный контроль: вы видите все его действия, можете в любой момент изменить права, а при завершении сотрудничества удалить аккаунт и быть уверены, что доступ закрыт полностью. Пароль при этом знает только сам подрядчик — вы его никуда не пересылаете.
Способ 4. Сервисный аккаунт с ограниченными правами
Если подрядчику нужен технический доступ к API или инфраструктуре, правильный подход — создать отдельный сервисный аккаунт с минимально необходимыми правами специально для этого подрядчика.
Не давайте подрядчику свои учётные данные или реквизиты основного сервисного аккаунта. Создайте отдельный — с тем же принципом минимальных привилегий. При завершении работ этот аккаунт деактивируется, основная инфраструктура остаётся нетронутой.
Что нельзя делать при передаче паролей подрядчикам
Передавать пароль от основной учётной записи. Если подрядчику нужен доступ к Google Ads — не давайте ему пароль от основного аккаунта агентства. Создайте отдельного пользователя с нужными правами.
Использовать один пароль для разных подрядчиков. Если вы используете один и тот же пароль для доступа, который даёте разным внешним людям, вы никогда не узнаете, кто именно совершил то или иное действие.
Передавать пароли голосом по телефону. Это кажется безопаснее мессенджера, но на самом деле хуже: нет никакой записи, что именно было сказано и кому.
Забывать менять пароль после завершения работ. Это нужно включить в обязательный чеклист завершения сотрудничества с любым внешним подрядчиком.
Давать подрядчику больше прав, чем нужно. Принцип минимальных привилегий работает и здесь. Если подрядчику нужен доступ к одной папке — он получает доступ к одной папке, не ко всему хранилищу.
Чеклист: передача доступа подрядчику
Используйте этот алгоритм каждый раз, когда нужно дать внешнему человеку доступ к корпоративным системам.
До начала работ: Определить, к каким именно системам и ресурсам нужен доступ. Создать минимально необходимые учётные данные или папку с нужными паролями. Установить срок действия доступа. Зафиксировать, кому, когда и к чему выдан доступ.
В процессе работы: Убедиться, что подрядчик использует именно выданные учётные данные, а не запросил их у ваших сотрудников. Периодически проверять журнал событий — особенно если речь о чувствительных системах.
По завершении работ: Немедленно отозвать все выданные доступы. Сменить пароли, которые подрядчик знал в открытом виде. Проверить журнал и убедиться, что доступы использовались только в рамках согласованных задач. Зафиксировать дату завершения сотрудничества и закрытия доступов.
Регуляторный аспект: почему это важно не только для безопасности
С 30 мая 2025 года действует новая редакция КоАП по утечкам персональных данных. Если утечка произошла через скомпрометированный доступ подрядчика, ответственность несёт компания как оператор персональных данных — вне зависимости от того, кто фактически допустил утечку.
Штраф для юридических лиц составляет от 3 до 15 млн рублей, при повторном нарушении — от 1 до 3% годовой выручки. Наличие задокументированного процесса управления доступами подрядчиков и журнала событий существенно снижает риски при разборе инцидента с регулятором.
Журнал событий в BearPass фиксирует все действия пользователей, включая внешних подрядчиков. Если регулятор задаст вопрос «кто имел доступ к системе в период X» — ответ будет готов за несколько минут.
Как это работает в BearPass
Shared Links — создание одноразовых или ограниченных по времени ссылок на конкретный пароль. Настраивается срок действия, количество просмотров, опциональная защита паролем на саму ссылку.
Временный доступ к папке — выдача внешнему пользователю доступа к папке с нужными паролями на заданный период. По истечении срока доступ закрывается автоматически.
Журнал событий — полная история действий каждого пользователя, включая подрядчиков: когда входил, какие пароли открывал, что изменял.
Мгновенный отзыв — один клик для деактивации учётной записи или отзыва доступа к папке. Подрядчик теряет доступ немедленно, в реальном времени.
Итог
Передача пароля в мессенджере — это не просто неудобная практика, это системная проблема управления доступами. Пароль выходит из-под вашего контроля, остаётся в переписке, не меняется после завершения работ и не оставляет следов в журнале.
Правильный подход — использовать инструменты, которые дают временный ограниченный доступ с полным аудитом: одноразовые ссылки, временные учётные записи, папки с настроенным сроком действия. Это занимает не больше времени, чем написать сообщение в мессенджер — но оставляет доступ под контролем компании, а не подрядчика.