«Если кто-то из вне получает доступ к вашим системам, это почти всегда чёрная метка. Потому что забыть про него, это один из самых простых способов создать уязвимость. И такой уязвимость пользуются».
Нет временных учётных записей
Владельцы системы — администраторы или сотрудники — имеют постоянный статус. Их учетные записи создаются и удаляются в рамках регламента, контролируются ИБ-службой. У подрядчика статус неопределённый: он может быть внешним сотрудником на договорной основе, фрилансером, представителем сторонней компании. Его учётная запись создаётся по запросу на «несколько дней для выполнения задачи». Но в системе нет механизма, который автоматически отключит этот доступ через заданный срок.
По сути, «временная» учётная запись, это просто обычная учётная запись, созданная сегодня. Никаких внутренних флагов или триггеров на её удаление не существует. Она остаётся в системе, пока администратор не вспомнит о ней и не выполнит процедуру удаления. А этого вспоминания чаще всего не происходит.
Почему мы не удаляем доступы подрядчиков
Есть несколько причин, которые позволяют «недельным» учётным записям жить месяцами и годами.
- Нет централизованного реестра. Подрядчик получает доступ в рамках конкретного проекта. Администратор, который выдал доступ, может забыть о проекте после его завершения, а новый администратор не знает, кем была создана эта учётная запись и для чего.
- Нет процесса проверки. В крупных организациях есть регулярные процедуры аудита учётных записей сотрудников, но учётные записи подрядчиков часто попадают в отдельный список, который никто не проверяет.
- Неявная зависимость. Подрядчик может выполнить работу, но его учётная запись остаётся связанной с некоторыми ресурсами (например, с файлами в облаке или записями в базе данных). Системные администраторы опасаются удалить учётную запись, потому что это может нарушить работу приложения или привести к потере данных. Они предпочитают «не трогать», даже если связь давно неактуальна.
- Человеческий фактор. Проект закончился, подрядчик ушёл, но у администратора нет задачи «удалить учётные записи». Это дополнительная операция, которая не является частью стандартного рабочего процесса. Она просто не выполняется.
Что может делать учётная запись подрядчика
Оставшись в системе, учётная запись подрядчика сохраняет все права, которые были ей выданы. Это может быть:
- доступ к файловым хранилищам (например, к корпоративному облаку или сетевой папке);
- права на чтение или изменение баз данных;
- административные права в отдельных приложениях;
- доступ к API внутренних служб;
- возможность запускать скрипты или выполнять команды на серверах.
Если права были выданы в рамках выполнения задачи, они остаются после её завершения. При этом учётная запись может быть использована для действий, не связанных с первоначальным проектом.
Как находят такие учётные записи
Злоумышленники, проводящие сканирование или анализ системы, могут обнаружить учётные записи подрядчиков по нескольким признакам:
- Нестандартные названия. Имена учётных записей часто отличаются от стандартного шаблона для сотрудников (например, не
ivanov, аcontractor_projectXилиtemp_dev). - Отсутствие активности в корпоративных системах. Учётная запись не участвует в ежедневных рабочих процессах, не появляется в чатах, не отправляет корпоративные письма, это может быть сигналом.
- Привязка к неактивным проектам. Анализ прав учётной записи может показать, что она связана с ресурсами, которые давно не используются или принадлежат завершенному проекту.
учётная запись подрядчика может стать удобной точкой входа для атаки.
Чем опасен постоянный доступ подрядчика
Оставшаяся учётная запись подрядчика создаёт риски даже если сам подрядчик не является злоумышленником.
- Её могут использовать другие люди, если пароль был передан или утерян.
- В случае изменения политик безопасности (например, внедрения новых требований к паролям или двухфакторной аутентификации) учётная запись подрядчика может остаться без защиты, потому что на нее не распространяются автоматические политики обновления.
- Через учётную запись подрядчика можно получить доступ к данным или системам, которые считаются внутренними и защищенными. Это нарушает принцип разделения ответственности и может привести к утечке информации.
учётная запись подрядчика становится «слабым местом» в системе защиты.
Как предотвратить превращение временного доступа в постоянный
Необходимо внедрить процессы, которые автоматически или полуавтоматически удаляют учётные записи подрядчиков после завершения их работы.
- Ведите реестр всех временных учётных записей. Для каждой записи указывайте проект, дату создания, предполагаемый срок действия и контакт администратора, который её создал. Реестр должен проверяться регулярно (например, каждые две недели).
- Создавайте учётные записи подрядчиков с ограниченным сроком жизни. Используйте функции систем управления учётными записями (например, в Active Directory или LDAP), которые позволяют установить дату автоматического отключения учётной записи. Если такой функции нет, можно создать скрипт, который периодически проверяет сроки и удаляет старые записи.
- Назначайте учётным записям подрядчиков отдельные группы или роли. Это позволяет управлять их правами централизованно и быстро отключать все доступы одной операцией.
- Связывайте учётные записи с проектами. После закрытия проекта автоматически запускайте процедуру удаления всех учётных записей, связанных с этим проектом. Это можно сделать через системы управления проектами или через простые скрипты.
- Контролируйте права. Не выдавайте подрядчикам права, которые превышают необходимые для выполнения задачи. После завершения задачи права должны быть уменьшены или полностью удалены.
Проверьте свои системы сейчас
Если в вашей организации есть учётные записи, созданные для подрядчиков или временных сотрудников, выполните несколько действий:
- Получите полный список всех учётных записей в системах (Active Directory, облачных сервисах, базах данных).
- Выделите учётные записи с нестандартными именами или учётные записи, которые не связаны с действующими сотрудниками.
- Определите, к каким проектам относятся эти учётные записи, и проверьте статус этих проектов.
- Если проект завершен и учётная запись не используется — удалите её или отключите.
- Обновите процессы управления учётными записями, чтобы включить в них автоматическое удаление временных учётных записей.
Простая проверка может обнаружить учётные записи, которые были созданы несколько лет назад и все ещё имеют активный доступ к корпоративным системам. Их удаление снижает риски и повышает уровень безопасности.