Удалённые подрядчики как второй периметр риска
Внешние инженеры и интеграторы требуют особой дисциплины доступа - не меньшей, чем штатные сотрудники, а часто большей.
Когда компания нанимает внешнего разработчика или интегратора, основное внимание обычно уходит на задачу: что нужно сделать, в какой срок, сколько стоит. Вопрос о том, какой доступ получит этот человек и что с ним произойдёт после окончания работ, чаще всего остаётся на периферии.
Это понятная расстановка приоритетов. И это системная уязвимость.
Почему подрядчик - это отдельная категория риска
Штатный сотрудник проходит онбординг, подписывает соглашения, работает в корпоративной инфраструктуре и, как правило, заинтересован в долгосрочных отношениях. Его доступ оформляется через HR, связан с конкретной ролью и имеет понятный жизненный цикл.
Подрядчик работает иначе. Он может быть физически в другом городе или стране. Он работает с нескольких машин, возможно - с личного оборудования. Его мотивация ограничена сроком контракта. После завершения работ никто автоматически не отзывает его доступ, если этот процесс не выстроен намеренно. Принцип того, что внешние каналы доступа могут стать вектором атаки - а не только внутренние уязвимости, - был наглядно продемонстрирован на промышленном уровне.
Кроме того, подрядчики нередко работают с несколькими клиентами одновременно. Это само по себе не проблема, но означает, что корпоративные учётные данные могут жить рядом с данными других компаний на одних устройствах.
Типичные ошибки при работе с внешним доступом
Из практики: наиболее частые проблемы выглядят так.
Доступ выдаётся широкий - "чтобы не мешать работать". Подрядчику дают права администратора или доступ к продуктивной среде там, где достаточно было бы тестовой.
Доступ не ограничен по времени. Контракт заканчивается, человек перестаёт работать, но учётная запись остаётся активной. Иногда это обнаруживается через год случайно.
Доступ не документирован. Кто именно выдал, к чему, когда - нет записи. При разборе инцидента восстановить картину невозможно.
Для нескольких подрядчиков создаётся одна общая учётная запись. Персонализации нет, аудита нет.
Что должно быть выстроено
Дисциплина работы с внешними доступами - это не параноя, это базовая гигиена. Минимальный набор:
- отдельная учётная запись для каждого подрядчика с его именем, не общая;
- доступ только к тому, что нужно для конкретной задачи - не "на всякий случай";
- срок действия доступа привязан к сроку контракта - лучше явно, а не "разберёмся потом";
- список активных внешних доступов ведётся и проверяется хотя бы раз в квартал;
- при завершении работ доступ отзывается явно, а не ждёт, когда кто-нибудь вспомнит.
Отдельно - выдача доступа к продуктивным данным. Если задача решаема в тестовой среде или на обезличенных данных, доступ к продуктиву не нужен. Это правило чаще нарушается ради удобства, чем по объективной необходимости.
Как это работает при интеграторах
С интеграторами ситуация сложнее: у одной компании-подрядчика может работать несколько людей, и состав команды меняется в процессе проекта. Здесь важно договориться на берегу: кто конкретно получает доступ, как вы об этом узнаёте при ротации, и кто со стороны интегратора несёт ответственность за соблюдение режима.
Соглашение об уровне доступа и ответственности лучше зафиксировать в договоре или отдельном приложении к нему. Устные договорённости здесь не работают.
Контрольный список перед выдачей доступа
Прежде чем открыть доступ внешнему подрядчику, я рекомендую ответить на пять вопросов:
- К каким конкретно системам и данным нужен доступ - и почему именно к ним?
- Какой минимальный уровень прав достаточен для задачи?
- На какой срок выдаётся доступ?
- Кто внутри компании отвечает за его отзыв?
- Где зафиксирован факт выдачи?
Если ответов нет - выдавать доступ рано.