Системный администратор ушел и забрал пароли: что делать?

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

Менеджмент организации должен учитывать, что пароли администратора дают доступ к фундаменту ИТ-инфраструктуры: доменам, маршрутизаторам, виртуализации, облачным сервисам и средствам резервного копирования. В ситуации, когда доступ находится только у одного человека, компания фактически ставится в позицию заложника. При внезапном увольнении и (или) конфликтных ситуациях это может привести к потере данных и финансовым убыткам. В частности, опасно, когда у компании нет документации, нет резервных учетных записей, а пароли хранятся только в голове у одного сотрудника. Такой подход противоречит базовому принципу отказоустойчивости: критические учетные данные не должны быть известны только одному человеку, а минимум нескольким уполномоченным лицам, также подразумевается, что они будут храниться в специализированных системах.

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

В первую очередь необходимо оценить масштаб бедствия. Руководство и ИТ-подразделение должны определить, какие именно сервисы используются компанией и где потенциально могли находиться административные учетные записи. Обычно необходимо проверить корпоративную почту, контроллеры домена, системы виртуализации, облачные платформы, серверы резервного копирования, сетевое оборудование, корпоративные сайты, базы данных, системы электронного документооборота, бухгалтерские системы и сервисы удаленного доступа. Затем следует оценить контроль над этой инфраструктурой: какие системы еще доступны, какие учетные записи существуют, где находятся резервные копии и кто имеет хотя бы частичный административный доступ. Порой выясняется, что часть паролей хранится у руководителя, часть – у подрядчика, а часть – в сохраненных настройках сервиса, и это позволяет восстановить управление без полной остановки работы.

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

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

После получения контроля над инфраструктурой необходимо перейти к следующему этапу – предотвращение потенциального злоупотребления доступом. Даже если бывший сотрудник не демонстрировал признаков недобросовестного поведения, его учетные записи должны быть заблокированы или отключены. Это касается не только доменных учетных записей, но и VPN-доступа, облачных сервисов, удаленного администрирования, систем мониторинга и других компонентов инфраструктуры, а также активных токенов, привязанных устройств и сохраненных сессий. Помните золотое правило: отзыв доступа и блокировку учетных записей необходимо осуществить сразу при увольнении сотрудника. Для этого нужно своевременно передавать информацию об увольнении системным администраторам. Хорошо, если для этого используются автоматизированные системы обработки обращений. Процесс централизованного отзыва могут обеспечить системы класса IAM (Identity and Access Management). В случае, если централизованный отзыв прав невозможен, администраторы систем должны осуществить отзыв в каждой системе по отдельности. Чтобы этот процесс качественно и быстро выполнялся на практике, важно закрепить его документально: описать каждый шаг и ответственных сотрудников во внутреннем регламенте и утвердить его. Кроме того, можно обратить внимание на возможность создания администратором скрытых учетных записей с повышенными привилегиями. Например, уволенный сотрудник мог создать локальные учетные записи на серверах. Поэтому после блокировки основной учетной записи нужно запустить сканирование инфраструктуры на предмет добавления новых администраторов. Можно ориентироваться на срок до трех месяцев и в случае обнаружения нелегитимных администраторов отключить их.

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

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

Для исправления сложившегося подхода требуются организационные изменения. Первое: все корпоративные учетные записи должны обязательно оформляться на организацию, а не на сотрудника – то есть при регистрации нужно использовать контактные данные организации: почта, телефон, адрес и прочее. Второе: пароли и доступы должны храниться в корпоративном менеджере паролей и (или) физически записаны на бумажный носитель с хранением в сейфе с доступом к нему у ограниченного круга лиц. Как правило, доступ должен быть у директора информационной безопасности или ИТ-инфраструктуры и его заместителя. Все попытки доступа к паролю должны фиксироваться в системе или записываться в журнал в случае, если речь идет о физическом хранении. Также есть возможность использовать одну из более продвинутых схем по «разделению секрета», которая позволит защитить мастер-пароль от утери. Речь идет о системе, когда пароль делится на несколько частей между руководителями, таких частей должно быть минимум три. В случае утраты доступа, любые две части из трех помогут восстановить мастер-пароль. Для реализации понадобится специализированное программное обеспечение. Третье: необходимо вести актуальную документацию по ИТ-инфраструктуре, включая схемы сети, перечень сервисов, учетные записи, владельцев доступов, резервное копирование и процедуры восстановления.

Также при наличии масштабной инфраструктуры, мы рекомендуем внедрить архитектурное решение PAM (Privileged Access Management). Такое решение сводит к минимуму угрозу ухода администратора с паролями, так как он ими не обладает. При правильной настройке процесс можно выстроить таким образом, что пароли генерируются и хранятся в зашифрованном виде внутри хранилища, а администратору выдается сессионный доступ с ограниченными правами. После завершения сессии пароль автоматически меняется, сама сессия при этом полностью логируется, для возможных расследований инцидентов ИБ.

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

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

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

Автор: Юлия Сонина, Старший аналитик Аналитического центра УЦСБ