После сезона отпусков проверьте доступы: какие-то уже точно пора закрыть

Один из сотрудников подменял руководителя и на время получил его права. Другого подключили к CRM, чтобы помочь с отчётом. Подрядчик закончил работу, но его учётную запись не отключили. Пароль от общего сервиса по-прежнему лежит в старом сообщении Slack.

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

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

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

Сначала уберите тех, кому доступ уже не нужен

Начните с бывших сотрудников и подрядчиков. Это самая понятная часть проверки, хотя именно здесь часто находятся забытые учётные записи.

Возьмите список действующих сотрудников и подрядчиков из кадровой системы и сравните его со списками пользователей в основных рабочих сервисах: GitHub, AWS, Google Workspace или Microsoft 365, CRM, Jira, Slack, системах сборки и развёртывания. В первую очередь интересуют сервисы, где хранятся важные данные или можно что-то изменить.

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

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

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

Разберите временные права

Временный доступ легко переживает задачу, ради которой его выдавали. К примеру, сотрудник две недели заменял руководителя и видел его папки. Маркетолог помогал коллегам с CRM и получил дополнительные разрешения. Разработчика подключили к аварийной работе в основной системе. Проект закончился, руководитель вернулся, а все эти права никто не снял.

Так возникает накопление лишних полномочий, или privilege creep. Для каждого дополнительного права попробуйте назвать нынешнюю задачу, которую без него нельзя выполнить. Если такой уже нет, доступ можно отозвать.

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

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

Общий пароль не делает доступ командным

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

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

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

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

Проверьте администраторов

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

Каждое лишнее разрешение увеличивает возможный ущерб от ошибки или взлома учётной записи. CISA рекомендует ограничивать права рабочей необходимостью, а NIST — пересматривать их и снимать, когда прежнее основание больше не действует.

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

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

Не пропустите ботов, токены и служебные аккаунты

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

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

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

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

Ревизия на один рабочий день

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

Пройдитесь по пяти пунктам:

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

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

Не нужно просить каждого сотрудника письменно доказывать, что ему нужна Jira. Хорошая ревизия убирает необъяснимые доступы, не создавая новый круг бюрократии.

Если хотите разобраться глубже

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

Cyber Security: Identity Access Management and Authentication / Coursera

Курс начального уровня от Macquarie University. Шесть модулей посвящены жизненному циклу учётных записей, единому входу, многофакторной и беспарольной аутентификации, а также работе с Azure AD, Okta и AWS IAM.

Программа курса

Identity and Access Management (IAM) / Udemy

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

Программа курса

SC-300 Identity and Access Manager / edX

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

Программа курса

Заключение

После ревизии у вас должен остаться список доступов, который можно объяснить: кто входит в важные системы, для какой работы и на какой срок.

Начните с бывших сотрудников, временных прав и администраторов. Обычно именно там находятся доступы, которые можно закрыть в тот же день.