«У вас есть svc_admin. А кто за него отвечает?»: почему технические учётные записи становятся скрытым риском для бизнеса

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

Но есть учётные записи, которые живут совсем по другим правилам.

svc_backup, integration_user, sql_service, api_admin – названия могут отличаться, но суть одна: это технические учётные записи, которые используются приложениями, сервисами, интеграциями, скриптами и другими автоматизированными процессами.

И однажды специалист по информационной безопасности задаёт простой вопрос:

«А кто отвечает за эту учётную запись?»

И тут начинается расследование.

Аккаунт есть. Ответственного нет

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

Проблема возникает позже.

Сервис, для которого создавался аккаунт, модернизировали. Ответственный сотрудник перешёл в другое подразделение. Систему передали другой команде. Подрядчик завершил проект. А техническая учётная запись продолжает существовать – иногда с весьма широкими полномочиями.

Через несколько лет восстановить историю становится сложно.

Кто запросил создание аккаунта? Для какой задачи? Какие права ему действительно необходимы? Кто сегодня является владельцем? Используется ли он вообще?

Если ответы приходится искать в старых заявках, переписках и спрашивать сотрудников, которые «вроде должны помнить», перед нами уже не просто административная проблема.

Это проблема управления доступом.

Почему технические аккаунты требуют отдельного внимания

В отличие от обычной учётной записи сотрудника, технический аккаунт не всегда связан с кадровым событием.

Сотрудник уволился – HR-система передала информацию, его доступ можно автоматически отозвать.

Но svc_backup не увольняется.

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

Отсюда появляются характерные риски.

Нет понятного владельца.
Учётная запись существует, но никто персонально не отвечает за необходимость её использования и предоставленные ей права.

Накапливаются избыточные полномочия.
Системы меняются, появляются новые интеграции и задачи, права добавляются, а старые далеко не всегда пересматриваются.

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

Теряется история изменений.
Через несколько лет становится сложно определить, кто и почему изменял параметры аккаунта или его полномочия.

И всё это может обнаружиться в самый неудобный момент – например, во время аудита или расследования инцидента.

Инвентаризация – только первый шаг

Кажется, что решение очевидно: собрать все технические аккаунты в единый реестр.

Это действительно важно, но самого списка недостаточно.

Настоящее управление начинается тогда, когда для каждой технической учётной записи можно ответить как минимум на несколько вопросов:

Что это за аккаунт? Для чего он существует? Где используется? Какие права имеет? Кто за него отвечает? Нужен ли он компании сегодня?

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

И главное – эта информация должна поддерживаться в актуальном состоянии, а не собираться вручную перед очередной проверкой.

Технической учётной записи тоже нужен жизненный цикл

Поэтому подход к таким аккаунтам постепенно меняется.

Вместо принципа «создали и забыли» появляется управляемый жизненный цикл:

создание → назначение ответственных → предоставление необходимых прав → контроль изменений → периодический пересмотр → блокировка или удаление.

Именно такой подход позволяет техническим учётным записям стать полноценной частью системы управления идентификацией и доступом.

В IDMX управление техническими учётными записями можно встроить в общий процесс Identity Management: создавать и редактировать их, назначать одного или нескольких ответственных, контролировать изменения и поддерживать актуальную информацию об аккаунтах.

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

Они становятся объектами, которыми можно управлять.

IDMX помогает перевести управление техническими учётными записями из области корпоративной памяти в управляемый и контролируемый процесс.

Потому что проблема не в том, что у компании есть svc_admin.

Проблема начинается тогда, когда никто уже не знает, зачем он нужен и кто за него отвечает.

Автор: 
Команда IKOD