Смена IT-подрядчика: как передать доступы без рисков
Как передать пароли и доступы при смене IT-подрядчика: чеклист без рисков
Смена IT-подрядчика — это один из наиболее уязвимых моментов в жизни корпоративной инфраструктуры. Именно здесь чаще всего обнаруживаются «призраки»: учётные записи старых подрядчиков которые остались активными, пароли которые знает уже уволенный инженер, системы о существовании которых новый подрядчик не подозревает.
По статистике, в среднем доступы внешних подрядчиков остаются активными ещё несколько месяцев после окончания отношений. Это не злой умысел — это отсутствие процесса.
Почему смена подрядчика это риск
Во-первых, вы не знаете полный список доступов. За время работы подрядчик мог получить доступ к десяткам систем — напрямую, через общие учётки, через пароли переданные в мессенджере. При смене вы закрываете то о чём знаете. Остальное остаётся открытым.
Во-вторых, пароли уже вышли за периметр. Любой пароль переданный подрядчику через мессенджер или почту остался в истории переписки навсегда. Даже если вы закроете учётную запись — пароль знает инженер который больше не работает с вами, его переписка доступна его новому работодателю, и этот пароль может использоваться в других системах по принципу повторного использования.
В-третьих, новый подрядчик начинает с нуля. Передача знаний о инфраструктуре часто сопровождается и передачей старых паролей — «вот логины, которые использовал предыдущий». Так скомпрометированные учётные данные живут годами.
Знаете ли вы полный список доступов которые есть у вашего текущего IT-подрядчика?
BearPass хранит все доступы подрядчиков централизованно. При смене — один клик закрывает все сессии, все пароли остаются в вашем хранилище. До 5 пользователей бесплатно навсегда.
Составить полный список систем к которым имел доступ подрядчик. Включить: корпоративные системы с учётными записями подрядчика, системы куда передавались пароли в открытом виде, API-ключи и токены выданные подрядчику, SSH-ключи и сертификаты, VPN-доступы, учётные записи в облачных сервисах.
Проверить в каких мессенджерах и почтовых переписках фигурировали пароли которые получал подрядчик. Все эти пароли нужно сменить независимо от смены учётных записей.
Запросить у старого подрядчика документацию: какие учётные записи создавались, к каким системам выдавался доступ, есть ли у них локальные копии данных.
В день смены: закрытие доступов
Деактивировать все учётные записи подрядчика в AD и во всех системах которые не синхронизированы с AD. Применить Kill Switch если пароли хранились в BearPass — завершить все активные сессии.
Сменить все пароли которые знал подрядчик. Особое внимание: пароли от систем куда подрядчик входил под своей учётной записью могут не требовать смены — но пароли которые были переданы ему в открытом виде сменить обязательно.
Отозвать SSH-ключи, API-ключи и токены. Деактивировать сертификаты. Закрыть VPN-доступы.
В течение недели после смены: аудит
Проверить журнал событий: не было ли обращений к системам с учётных записей подрядчика после даты закрытия. Если были — это сигнал что закрыли не всё.
Проверить Active Directory и все корпоративные системы на наличие учётных записей с именами или email подрядчика которые не были деактивированы.
Запустить мониторинг скомпрометированных паролей. Если пароли компании попали в публичные базы утечек через инфраструктуру подрядчика — обнаружим это немедленно.
Выдача доступов новому подрядчику: правильный порядок
Создать новые учётные записи с минимально необходимыми правами. Не передавать пароли в мессенджерах — только через временные ссылки из BearPass с ограниченным сроком действия.
Для каждой системы которую будет обслуживать новый подрядчик — отдельная папка в BearPass с нужными учётными данными. Подрядчик получает доступ к папке, а не к конкретным паролям напрямую. При необходимости расширить или сузить доступ — одно действие администратора.
Настроить уведомления в модуле «Правила»: уведомлять при каждом просмотре пароля из папок подрядчика. Это не недоверие — это стандартная практика мониторинга внешних доступов.
Установить срок действия доступа с первого дня. По завершении работ доступ закрывается автоматически.
Как выстроить процесс чтобы смена подрядчика не была экстренной операцией
Проблема большинства компаний не в том что они не знают как закрыть доступы при смене подрядчика. Проблема в том что к моменту смены они не знают что именно нужно закрывать.
Централизованное хранилище паролей с отдельными папками для каждого подрядчика решает эту проблему на уровне архитектуры. Все доступы подрядчика — в одном месте. При смене: деактивировать учётную запись, применить Kill Switch, сменить пароли из папки подрядчика. Полная операция занимает 15 минут вместо нескольких дней.
При этом пароли никогда не покидают хранилище компании. Подрядчик работает с системами через временные ссылки или через свою учётную запись в BearPass — но сами пароли остаются вашей собственностью. При смене подрядчика менять пароли от систем не нужно, потому что подрядчик никогда не знал их в открытом виде
BearPass
Смена подрядчика за 15 минут вместо нескольких дней
Временные ссылки · Изолированные папки · Kill Switch · Журнал доступов On-premise · Реестр РФ №15427 · Шифрование ГОСТ
Безопасная смена подрядчика строится на трёх принципах: знать все доступы которые есть у подрядчика (централизованное хранилище), иметь возможность закрыть их мгновенно (Kill Switch), и не передавать пароли в открытом виде чтобы при смене менять только учётные записи, а не пароли от систем.
BearPass — корпоративный менеджер паролей
Все доступы подрядчиков под контролем. Смена без экстренных операций.
Временные ссылки · Kill Switch · Журнал событий · Изолированные папки On-premise · Данные на вашем сервере · Реестр РФ №15427 · ГОСТ