Доступ подрядчиков и фрилансеров в офисную сеть: как не оставить открытую дверь после проекта

За пятнадцать лет в ИТ-аутсорсинге я разгребал последствия чужого «временного» доступа раз двадцать, не меньше. Приходит новый клиент, а у него в домене висит учётка «programmer1» с паролем от две тысячи девятнадцатого года и правами администратора. Никто не помнит, кто это и зачем. Сегодня расскажу, как выдавать доступ подрядчикам так, чтобы потом не икалось.

Почему временный доступ почти никогда не бывает временным

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

А учётка остаётся. Потому что убрать её — отдельная задача, которую никто не поставил в план. У одного клиента, юридической фирмы на тридцать человек, я нашёл семь таких «мёртвых душ» в Active Directory. Самой старой было четыре года. Пароль — тот же, что при создании, естественно, слабый, восьмизначный, без обновления.

Это не разгильдяйство одного конкретного админа. Это системная проблема: доступ создать легко и быстро, а отозвать — трудно и не горит. Вот и копится долг, как невынесенный мусор.

Реальная история: как бывший фрилансер чуть не обвалил бухгалтерию

Расскажу случай без имён, но правдивый до последней буквы. Клиент — производственная компания, человек сорок в штате. Год назад им делал доработку 1С сторонний программист, работал удалённо через RDP. Договор закончился, оплата прошла, все разошлись.

Через восемь месяцев в компании происходит смена финансового директора. Новый человек начинает разбираться в базе и видит: кто-то заходил в 1С по ночам, менял справочник контрагентов, причём с той самой учётки фрилансера. Оказалось — не злой умысел, просто у бывшего исполнителя остался доступ, и он по инерции иногда заглядывал «посмотреть, как там дела», даже не задумываясь, что это уже не его зона ответственности.

Ничего не украли, слава богу. Но представьте, если бы этот доступ попал не к добросовестному фрилансеру, а к кому-то менее щепетильному, или его пароль утёк бы в результате слива с другого сервиса. RDP-порт торчал наружу, пароль был из восьми символов. Это готовый сценарий для шифровальщика, который кладёт всю бухгалтерию за одну ночь.

Принцип нулевого доверия для подрядчика: доступ только на срок проекта

Первое правило, которое я внедряю у клиентов: любой внешний исполнитель получает учётку с датой истечения. В Active Directory это делается одним чекбоксом — «Срок действия учётной записи». Ставите дату окончания проекта плюс неделя на всякий случай, и система сама заблокирует вход, даже если все забудут.

Второе — минимальные права. Если человек настраивает 1С, ему не нужен доступ к бухгалтерской папке на файловом сервере и уж точно не нужны права администратора домена. Даём ровно то, что требуется для задачи, не больше. Звучит банально, но на практике я вижу обратное в девяти случаях из десяти.

Третье — отдельная учётка на каждого подрядчика, никогда не общая на «всех фрилансеров сразу». Я понимаю соблазн: одна учётка проще завести. Но потом невозможно понять, кто именно заходил и что делал, а логи превращаются в кашу.

Изоляция сети: подрядчику не место в одном VLAN с бухгалтерией

Вот что реально спасает даже при утечке пароля — сегментация сети. У себя и у клиентов мы делаем отдельный VLAN для гостевого и подрядческого доступа, физически или логически отрезанный от рабочих станций сотрудников и уж тем более от сервера 1С и базы данных.

Условно: у клиента, медицинской клиники, монтажники видеонаблюдения подключались через тот же Wi-Fi, что и администратор с доступом к базе пациентов. Технически они были в одной сети класса С, видели друг друга по протоколу ARP, могли просканировать соседей nmap-ом за пять минут. Мы развели их по VLAN, добавили правило на межсетевом экране: гостевой сегмент видит только интернет, и точка.

Для удалённого доступа — то же самое. Никакого прямого RDP на боевой сервер из интернета, только через VPN с отдельной учёткой, которая падает в свой изолированный сегмент. У нас в компании стоит правило: подрядчик заходит через OpenVPN или WireGuard, попадает в песочницу, а к нужному ресурсу — уже точечным правилом firewall, и никак иначе.

Автоматическое отключение: не полагайтесь на человеческую память

Самое надёжное решение — то, которое не требует, чтобы кто-то вспомнил и не забыл. Отсюда правило: каждая временная учётка подрядчика создаётся сразу с датой истечения, привязанной к дате окончания договора. Не «когда-нибудь потом отключим», а автоматически, в момент создания.

В Windows Server это делается через Active Directory Users and Computers, вкладка Account, поле Account expires. Для linux-серверов — команда chage с флагом даты истечения. Для облачных сервисов вроде 1С:Фреш или облачной СБИС — там свои механизмы отзыва доступа, но принцип тот же: срок задаётся заранее, а не отзывается вручную по памяти.

У нас в АйТи-Фреш это правило прописано в регламенте: ни один договор с подрядчиком не подписывается без пункта о сроке доступа. И раз в квартал мы делаем ревизию всех активных учётных записей у клиентов на обслуживании — просто выгружаем список и смотрим, кто там числится и почему. Занимает час, экономит потом недели разгребания.

Что делать, если подрядчик уже давно ушёл, а доступ остался

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

Второй шаг: пройдитесь по Active Directory, по локальным группам администраторов на серверах, по спискам пользователей 1С, по доступам к облачным сервисам — Google Workspace, СБИС, банк-клиент. Всё, что не опознано и не подтверждено кем-то из действующих сотрудников — блокировать сразу, разбираться потом.

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

Частые вопросы

Сколько стоит настроить автоматическое отключение доступа подрядчиков?
Если инфраструктура на Active Directory, это не требует лицензий — только время администратора на настройку регламента и групповых политик, обычно четыре-восемь часов работы. Для облачных сервисов может понадобиться платный тариф с ролевой моделью доступа, но обычно это уже входит в существующую подписку.

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

Как понять, что доступ подрядчика пора отзывать, если договора уже нет под рукой?
Заведите простую таблицу или карточку в CRM на каждого внешнего исполнителя с датой начала и окончания доступа ещё на этапе выдачи учётки. Тогда не придётся искать договор — достаточно раз в месяц смотреть список с датами.

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