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

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

Менеджер проекта вбегает в чат техподдержки:

> *«Срочно дайте ребятам доступы в GitLab, VPN, базу данных и документацию! У них контракт на три недели, нужно начинать прямо сейчас!»*.

Дежурный админ в мыле заводит три доменные учётки contractor_ivan, contractor_petr, скидывает конфиги OpenVPN в личку в Telegram и возвращается к своим задачам.

Через три недели спринт заканчивается, подрядчики получают оплату и машут ручкой.

А ещё через полгода компания проводит внутренний аудит безопасности и с удивлением обнаруживает: все трое подрядчиков до сих пор активны в каталоге, их VPN-ключи работают, а с IP-адресов в Сербии и на Бали каждую неделю кто-то тихо клонирует свежие коммиты из мастер-ветки компании.

---

3 фатальные ошибки при работе с аутсорсом

Ошибка 1. Бессрочные учётки («Account Expires: Never»)

Когда сисадмин создаёт пользователя в Active Directory через графическую оснастку, по умолчанию галочка «Срок действия учетной записи» отключена.

В пылу спринта никто не ставит напоминалку в календарь «заблокировать Васю через 21 день». В итоге временные учетки подрядчиков превращаются в бессмертных зомби, накапливаясь годами.

Ошибка 2. «Один VPN-конфиг на всю бригаду»

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

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

Ошибка 3. Избыточные привилегии («Дай всё, а то не заведётся»)

Аутсорсеру нужен доступ к одному микросервису верстки? Ему выдают доступ к общему GitLab, где лежат секреты продакшна. Нужен доступ к тестовой базе? Ему открывают прямой сетевой маршрут через VPN во внутреннюю подсеть, откуда виден весь продакшн.

---

Как построить безопасный шлюз для подрядчиков

Работа с внешними исполнителями не должна напоминать игру в русскую рулетку. В шлюзе доступа OwnGate управление внешними командами выстроено по принципу Time-Bound Zero Trust:

1. Жесткий срок жизни (Auto-Expiry по умолчанию)

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

• При создании профиля шлюз требует дату: например, 2026-10-31;
• Ровно в полночь указанного дня шлюз автоматически деактивирует аккаунт и аннулирует все сессионные токены;
• Чтобы продлить доступ, менеджер проекта должен нажать кнопку пролонгации в панели. Никакой человеческий фактор и забывчивость админа больше не могут оставить доступ открытым.

2. Строгий скоупинг (Только Staging, никакого Prod)

Шлюз OwnGate разделяет доступы на уровне политик OIDC:

• Подрядчик физически не видит продакшн-сервисы в портале приложений;
• Токены, выпущенные шлюзом для подрядчика, содержат ограниченный скоуп прав (env:staging, role:external_contributor);
• Попытка стукнуться с таким токеном в боевой контур отбивается шлюзом с ответом 403 Forbidden.

3. Обязательный персональный 2FA

Никаких общих аккаунтов. Каждый внешний разработчик обязан пройти регистрацию в шлюзе и привязать собственный генератор кодов TOTP (Google Authenticator, Яндекс Ключ).

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

4. Изолированный аудит подрядчиков

Все действия внешних разработчиков помечаются специальным флагом external_vendor в журнале аудита OwnGate. Вы в один клик можете посмотреть:

• В какие сервисы заходил аутсорс за последнюю неделю;
• С каких IP-адресов и стран выполнялись подключения;
• Были ли попытки достучаться до закрытых внутренних ресурсов компании.

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