Устаревший доступ сохраняется дольше, чем предполагалось, и большинство организаций никогда его не отслеживают. Новые права доступа предоставляются в течение дня после запроса. Старые права отзываются, если вообще отзываются, только по чьей-то наводке. Инструменты, помогающие сотрудникам подтверждать, ротировать и сохранять свои служебные учетные записи, снова и снова убеждали меня в том, что удаление доступа должно быть столь же продуманным, как и его предоставление. Специалисты по безопасности могут устранить этот разрыв, внеся простые изменения в свои политики перемещения ролей и проверки доступа.
Это происходит постоянно. Сотрудник переходит из одной команды в другую. Новый руководитель в течение дня одобряет доступ, необходимый для новой роли, и человек начинает продуктивно работать к обеду. Доступ из старой роли остается. Спустя месяцы проверка доступа содержит только один вопрос: «Вам это все еще нужно?» Рецензент видит имя рядом с разрешением, но на панели управления нет никаких данных о том, использовалось ли оно с момента перехода. Трудно нажать «нет», потому что что-то может сломаться. Нажимать «да» им никогда не приходилось. Поэтому они нажимают «да», и их это устраивает.
Почему предоставить доступ легко, а удалить — сложно?
Предоставление доступа имеет владельца и срок. Менеджер подает запрос, утверждающий нажимает «да», и процесс завершается всего за несколько часов, поскольку в нем участвует кто-то конкретный. Удаление не имеет ни того, ни другого. Никто не открывает заявку, когда разрешение становится ненужным, поскольку единственный, кто это заметит, не подаст заявку из-за отсутствия причин для этого. Стоимость поддержания разрешения высока, но она невидима и возникает в будущем. Стимулы работают так же. Никто не оценивает, насколько низкий уровень доступа поддерживает его команда, в то время как ошибочно удаленное и ставшее необходимым разрешение приводит к подаче возмущенной заявки в службу поддержки в тот же день.
И это то, что должно делаться через проверки, но, на мой взгляд, делается не так. И, по крайней мере, во всех мероприятиях по аттестации и переаттестации, в которых я участвовал, рецензенту задается лишь один базовый вопрос: действителен ли доступ? Сказать «да» не так уж сложно — доступ был предоставлен, последующих действий не было, а проверка нескольких сотен занимает меньше времени, чем расследование одного конкретного доступа. Это не то, что появится на вашем экране. При проверке имен учетных записей вы не знаете, использовались ли они на прошлой неделе или в прошлом году.
Управление доступом на основе ролей помогает здесь, но проблема в том, что когда пользователь меняет роль, его роль обновляется, но не прямой доступ, группы и папки, которые он приобрел за это время.
Какова реальная стоимость устаревшего доступа?
Я должен быть очень осторожен здесь, поскольку этот показатель не отражает оставшийся доступ. Отчет 2026 Verizon Data Breach Investigations Report показал, что эксплуатация уязвимостей была наиболее часто используемым методом взлома, составляя 31% всех взломов, в то время как предыдущий лидер — злоупотребление учетными данными — сократился до 13%. Однако я хочу подчеркнуть, что этот конкретный отчет не имеет отношения к проблеме устаревших разрешений. Тем не менее, то, что злоумышленник мог сделать после проникновения в систему, зависит от разрешений скомпрометированной учетной записи, что, в свою очередь, зависит от количества приобретенных разрешений. На практике это выглядит как результаты аудита и расследования, которые длятся вечно, потому что никто точно не знает, кому разрешить доступ к корпоративным данным.
Однако есть информация, подтверждающая случай уходящих сотрудников, хотя и довольно скудная. Так, согласно опросу PasswordManager.com, проведенному в марте 2023 года среди 1000 американских работников, 58% работников, ответивших, что использовали пароли своих предыдущих работодателей, признались, что никогда не обновляли свои пароли после ухода из компании. Это опрос общественного мнения, проведенный онлайн, и именно поэтому он является индикатором. Действительно, я тоже заметил это: уходящие сотрудники должны проходить контрольные списки HR по завершению работы, но не разрешения и сертификаты, созданные сотнями людей за многие годы.
Переводы — это еще большая проблема, и исследований по ним меньше. В случае ухода сотрудника происходит хотя бы что-то — запускается процесс увольнения. При переводе ничего не запускается. И поэтому я считаю, что переводы должны быть столь же важны, как и увольнения, потому что стандарты требуют именно этого. NIST SP 800-53 Rev. 5 — каталог средств контроля безопасности и конфиденциальности, используемый во всех организациях — содержит элементы управления AC-2 и AC-6 для управления учетными записями и принципа наименьших привилегий, требующие проверки учетных записей, обработки переводов и увольнений, а также предоставления только привилегий, необходимых для роли человека.
3 исправления, которые делают устаревший доступ трудно игнорируемым
И вот как я позабочусь о внедрении изменений. Нет необходимости внедрять новые технологии. Только решение относительно владения процессом удаления.
1. Каждое изменение должности будет рассматриваться как событие удаления
Начните с записи HR в системе. После изменения создайте задачу для уходящего и приходящего менеджера, где будет только один вопрос, на который менеджер должен ответить: что человеку больше не понадобится? Предоставьте им список доступа и 10 минут для ответа на вопрос. Весь доступ, который человек имел в течение этого периода, должен иметь владельца. Если вы сделаете только одно из этих трех, сделайте это.
2. Каждое разрешение должно иметь своего уникального владельца и срок действия
Разрешения или доступ к папкам проекта, специальные разрешения или доступ к производственной системе должны истекать к определенной дате, которая может быть либо датой истечения срока действия проекта, либо, по умолчанию, через три месяца после его выдачи, если он не продлен владельцем, который должен быть указанным лицом, а не адресом электронной почты. Я думаю об учетной записи, владельце и приложениях, к которым она имеет доступ, как о графе, потому что если произойдет какое-либо изменение в учетных записях, то одним запросом можно определить, чем он/она владеет и каковы его/ее зависимости. Продление должно быть опцией в один клик, но в случае, если этот человек больше не доступен, это должно быть сделано через его/ее менеджера, чтобы это не осталось незамеченным. Это настройка по умолчанию. В текущем сценарии, если вы ничего не делаете, это ваше разрешение; следовательно, лень — опасный путь. Не делайте действием по умолчанию продление разрешения.
3. Представляйте информацию о последнем использовании при всех проверках и позволяйте людям действовать на ее основе
Извлекайте временные метки последнего входа и последней активности из вашего поставщика удостоверений и журналов приложений и представляйте их вместе с каждым разрешением. Упорядочьте список так, чтобы наименее используемый доступ появлялся вверху, выберите его для удаления и попросите рецензента объяснить, почему им нужно его сохранить. По опыту я обнаружил, что люди охотно подтверждают, когда на экране появляется сообщение «это разрешение не использовалось семь месяцев». Затем позвольте им действовать в соответствии с тем, что они считают лучшим. Если аттестация происходит с использованием одного инструмента, а ротация/сохранение — с использованием другого, то вы найдете людей, подтверждающих вопрос и пропускающих действие. Вот почему я начал объединять аттестацию, ротацию, сохранение и вывод из эксплуатации доступа в один процесс. Помните, однако, что у этого подхода есть ограничения. Не все приложения ведут журналы использования, и иногда существует законный доступ, который редко используется. Возьмите, к примеру, учетные записи для квартального закрытия и учетные записи «break glass». Им должен быть назначен владелец и примечание.
Хотя сотрудники смогут определить, что им больше не нужно, это эффективно только тогда, когда существует система, позволяющая им делать это безопасно и легко, и это еще одна причина, по которой нам необходимо внедрить три вышеуказанных исправления.
В этом квартале начните с одной системы, где хранятся конфиденциальные данные, и запустите отчет о последнем использовании для этой системы. Начните с пользователей, которые были переведены на другую должность в течение последнего года, поскольку никто не проверял их права доступа с тех пор. Отправьте список всех тех пользователей, которые не использовали эту систему за последние шесть месяцев, владельцу системы и задайте им один простой вопрос: требуется ли им это по-прежнему? Результаты будут достаточны, чтобы обосновать необходимость внедрения для остальных систем сильнее, чем любая структура.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Vaishnavi Khosla
