Смена IT-подрядчика: как передать доступы без рисков

Как передать пароли и доступы при смене IT-подрядчика: чеклист без рисков

Смена IT-подрядчика — это один из наиболее уязвимых моментов в жизни корпоративной инфраструктуры. Именно здесь чаще всего обнаруживаются «призраки»: учётные записи старых подрядчиков которые остались активными, пароли которые знает уже уволенный инженер, системы о существовании которых новый подрядчик не подозревает.

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

Почему смена подрядчика это риск

Во-первых, вы не знаете полный список доступов. За время работы подрядчик мог получить доступ к десяткам систем — напрямую, через общие учётки, через пароли переданные в мессенджере. При смене вы закрываете то о чём знаете. Остальное остаётся открытым.

Во-вторых, пароли уже вышли за периметр. Любой пароль переданный подрядчику через мессенджер или почту остался в истории переписки навсегда. Даже если вы закроете учётную запись — пароль знает инженер который больше не работает с вами, его переписка доступна его новому работодателю, и этот пароль может использоваться в других системах по принципу повторного использования.

В-третьих, новый подрядчик начинает с нуля. Передача знаний о инфраструктуре часто сопровождается и передачей старых паролей — «вот логины, которые использовал предыдущий». Так скомпрометированные учётные данные живут годами.

Полный чеклист смены IT-подрядчика

За 2 недели до смены: инвентаризация

Составить полный список систем к которым имел доступ подрядчик. Включить: корпоративные системы с учётными записями подрядчика, системы куда передавались пароли в открытом виде, API-ключи и токены выданные подрядчику, SSH-ключи и сертификаты, VPN-доступы, учётные записи в облачных сервисах.

Проверить в каких мессенджерах и почтовых переписках фигурировали пароли которые получал подрядчик. Все эти пароли нужно сменить независимо от смены учётных записей.

Запросить у старого подрядчика документацию: какие учётные записи создавались, к каким системам выдавался доступ, есть ли у них локальные копии данных.

В день смены: закрытие доступов

Деактивировать все учётные записи подрядчика в AD и во всех системах которые не синхронизированы с AD. Применить Kill Switch если пароли хранились в BearPass — завершить все активные сессии.

Сменить все пароли которые знал подрядчик. Особое внимание: пароли от систем куда подрядчик входил под своей учётной записью могут не требовать смены — но пароли которые были переданы ему в открытом виде сменить обязательно.

Отозвать SSH-ключи, API-ключи и токены. Деактивировать сертификаты. Закрыть VPN-доступы.

В течение недели после смены: аудит

Проверить журнал событий: не было ли обращений к системам с учётных записей подрядчика после даты закрытия. Если были — это сигнал что закрыли не всё.

Проверить Active Directory и все корпоративные системы на наличие учётных записей с именами или email подрядчика которые не были деактивированы.

Запустить мониторинг скомпрометированных паролей. Если пароли компании попали в публичные базы утечек через инфраструктуру подрядчика — обнаружим это немедленно.

Выдача доступов новому подрядчику: правильный порядок

Создать новые учётные записи с минимально необходимыми правами. Не передавать пароли в мессенджерах — только через временные ссылки из BearPass с ограниченным сроком действия.

Для каждой системы которую будет обслуживать новый подрядчик — отдельная папка в BearPass с нужными учётными данными. Подрядчик получает доступ к папке, а не к конкретным паролям напрямую. При необходимости расширить или сузить доступ — одно действие администратора.

Настроить уведомления в модуле «Правила»: уведомлять при каждом просмотре пароля из папок подрядчика. Это не недоверие — это стандартная практика мониторинга внешних доступов.

Установить срок действия доступа с первого дня. По завершении работ доступ закрывается автоматически.

Как выстроить процесс чтобы смена подрядчика не была экстренной операцией

Проблема большинства компаний не в том что они не знают как закрыть доступы при смене подрядчика. Проблема в том что к моменту смены они не знают что именно нужно закрывать.

Централизованное хранилище паролей с отдельными папками для каждого подрядчика решает эту проблему на уровне архитектуры. Все доступы подрядчика — в одном месте. При смене: деактивировать учётную запись, применить Kill Switch, сменить пароли из папки подрядчика. Полная операция занимает 15 минут вместо нескольких дней.

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

Итог

Безопасная смена подрядчика строится на трёх принципах: знать все доступы которые есть у подрядчика (централизованное хранилище), иметь возможность закрыть их мгновенно (Kill Switch), и не передавать пароли в открытом виде чтобы при смене менять только учётные записи, а не пароли от систем.

Рекомендуем к прочтению

• Беарпасс объявила о начале процедуры сертификации ФСТЭК
• Инсайдеры и SIEM: журнал паролей ускоряет обнаружение угроз
• БЕАРПАСС 2.27.0 — Защищённые пространства: Zero-Knowledge-шифрование для корпоративных данных