Привилегированный доступ: угроза изнутри важнее внешнего периметра
Почему контроль привилегированных учётных записей - самый недооценённый рычаг безопасности для руководителя, и как устроить разумную защиту.
Большинство разговоров о безопасности в компаниях крутятся вокруг внешних угроз: вирусы, взломы, фишинг. Это реальные риски. Но есть категория инцидентов, которая происходит без всякого взлома периметра - и которая обходится дороже.
Сотрудник с широкими правами доступа - системный администратор, разработчик с доступом к продакшн-базе, консультант с правами на изменение конфигурации - может скопировать данные, изменить записи или нарушить работу систем. Без взлома. Просто потому что у него есть полномочия.
После разоблачений Сноудена в 2013 году этот сценарий перестал быть абстрактным. Вопрос "кто из наших людей мог бы сделать нечто подобное" стал вполне конкретным.
Почему это системная проблема
Привилегированный доступ накапливается постепенно. Системный администратор получил права три года назад для конкретной задачи - задача давно решена, права остались. Разработчик попросил прямой доступ к базе данных "на время отладки" - прошло полгода. Уволенный сотрудник иногда может войти ещё несколько недель после ухода, потому что никто не деактивировал учётную запись.
Это не злой умысел. Это обычное накопление технического долга в области доступа. Но результат тот же: по факту прав у людей больше, чем нужно для их работы, и никто точно не знает, у кого что есть.
Другая часть проблемы - отсутствие журнала. Что именно делал пользователь с расширенными правами - запрашивал данные, изменял конфигурацию, копировал файлы - во многих компаниях никак не фиксируется. Инцидент можно обнаружить, но что именно произошло - восстановить нельзя.
Три минимальных контроля
Я не сторонник перегружать компании инструментами безопасности, которые дороги в сопровождении. Но есть три вещи, без которых привилегированный доступ остаётся неуправляемым.
Инвентаризация привилегированных учётных записей. Кто имеет административный доступ к каким системам? Этот список должен существовать и быть актуальным. Без него невозможно ни управлять рисками, ни расследовать инцидент.
Минимум необходимых прав. Права должны выдаваться под конкретную задачу и ограниченный срок. После завершения - отзываться. Это неудобно. Но это единственный способ сдержать накопление избыточного доступа.
Логирование привилегированных действий. Что делал администратор в системе, должно записываться. Не только факт входа, но и действия: какие запросы выполнялись, какие файлы открывались, какие изменения вносились. Это дорого в хранении - но это то, что позволяет разобраться в инциденте.
Кто должен владеть этим вопросом
В большинстве компаний среднего размера этот вопрос не принадлежит никому конкретно. ИТ управляет правами в рамках операционной необходимости. Безопасность существует где-то рядом. Аудит приходит раз в год.
Проблема в том, что инцидент с привилегированным доступом - это операционный, юридический и репутационный риск одновременно. Это уровень директора, а не только ИТ.
Разумная структура - назначить конкретного человека ответственным за политику привилегированного доступа, провести ревизию текущего состояния и установить квартальный процесс пересмотра прав. Это не требует больших затрат. Это требует решения.
Несколько вопросов для самопроверки
- Можете ли вы прямо сейчас назвать всех людей с административным доступом к вашим критическим системам?
- Есть ли среди них бывшие сотрудники или подрядчики, доступ которых не был своевременно отозван?
- Если произошёл бы инцидент - могли бы вы восстановить, что именно делал пользователь с расширенными правами?
- Кто в компании отвечает за актуальность списка привилегированных учётных записей?
Если хотя бы на один вопрос нет чёткого ответа - это работа, которую стоит начать раньше, чем понадобится.