Как следует защищать привилегированные учетные записи в Linux и Windows?
Недавно я начал работать в области безопасности приложений в фирме среднего размера, перейдя от 5+ лет в области консалтинга по безопасности (тестирование на пентест и т. Д.). Одна из самых больших проблем, которые я вижу здесь с самого начала, заключается в том, что сканеры безопасности и другие инструменты используют доступ с правами root / администратора, поскольку именно это производители и сказали им использовать, скорее всего из-за простоты настройки. Мне действительно не нравится эта идея. Например, Nexpose и Nessus настроены на использование root и Administrator.
Мой вопрос - каковы наилучшие практики с точки зрения управления доступом к этим привилегированным учетным записям? Сначала я думал о том, чтобы иметь систему парольных хранилищ, которая знает только пароли к системе. Затем пользователь может "проверить" пароль root/Administrator по мере необходимости "В частности, для Nessus только несколько команд запускаются от имени root, поэтому я думаю, что имеет смысл просто создать стандартного пользователя и добавить его к файл sudoers, в то время как разрешены только эти конкретные команды.
Спасибо!
3 ответа
На сайте моего нынешнего работодателя одной из многих мер безопасности является использование учетных записей, доступ к которым возможен только с помощью привилегированного монитора сеансов, который записывает все действия.
В определенных системах управление паролями всех привилегированных учетных записей передается приложению внешнего хранилища паролей, и даже администраторы не знают паролей root/Administrator/DB-owner и т. Д.
В случаях, когда четко определенных RBAC недостаточно и root / Administrator / и т.д. требуется доступ, администратор запрашивает доступ после одобрения группой операций по обеспечению безопасности (принцип четырех глаз, контрольный журнал с номером изменения / инцидента) и через хранилище паролей запускается SSH или RDP с правильными учетными данными из хранилища. Администратор не получает текстовую копию пароля, хранящегося в хранилище. Сеанс SSH или RDP может отслеживаться и записываться для требуемого контрольного журнала. После закрытия сеанса приложение хранилища снова изменит пароль.
Конечно, фактическая безопасность таких процедур в значительной степени зависит от качества и понимания безопасности вашего управления конфигурацией, мониторинга событий и общей зрелости вашей операционной команды.
Риск, которым вы рискуете (на самом деле реальность), заключается в том, что разрешение инцидентов и даже запланированная работа займет значительно больше времени, но, по крайней мере, у вас будет отличный контрольный след, почему так!
Если вы ищете централизованную группу или менеджера пользователей, есть много коммерческих приложений для этого.
На ваших Linux-боксах отключите вход в систему как root и заставьте пользователей входить в систему как от себя. Если ящик аутентифицируется в LDAP или AD, у вас будет запись таких транзакций. Вам все еще нужно будет дать этому пользователю определенные права на коробке. Использование sudo после входа в систему также упрощает аудит и отслеживание.
Не зная, как ваша компания структурирована и разделена, затруднить ответ на вопрос. Безопасность, Администраторы сервера, Менеджеры приложений - это отдельные подразделения, в которых я работаю. Менеджеры приложений не имеют прав администратора для запуска таких инструментов, только администраторы сервера. Администраторы сервера, в то время как они могут добавлять / удалять / удалять локальные учетные записи на коробке, не могут изменять AD/LDAP. Служба безопасности проверяет все серверы, чтобы узнать, какие локальные учетные записи находятся в определенном окне, и нуждаются в людях, чтобы оправдать их использование.
Использование универсального имени пользователя может сделать вашу систему широко открытой без возможности определить, кто вызвал проблему. Лучше заблокировать все это и предоставить доступ по мере необходимости, чем предполагать, что люди будут честными, а новые вещи испортят. Это больше работы для вас, но это позволит вам лучше спать по ночам. Что еще более важно, вы никогда не жили, пока не обнаружили, что один из ваших серверов был взломан, и ИТ-директор хочет знать, почему.
Защита привилегированных учетных записей имеет решающее значение для поддержания безопасной вычислительной среды. Лучшие методы защиты привилегированных учетных записей как в Linux, так и в Windows включают:
- Использование надежных паролей или кодовых фраз для привилегированных учетных записей и их регулярная смена.
- Ограничение доступа к привилегированным учетным записям только тем, кому это необходимо.
- Реализация многофакторной аутентификации для привилегированных учетных записей.
- Использование хранилища паролей или другой безопасной системы управления паролями для хранения учетных данных привилегированной учетной записи и управления ими.
- Аудит и мониторинг активности привилегированных учетных записей для обнаружения любого несанкционированного доступа или использования.
- Внедрение контроля доступа на основе ролей, чтобы гарантировать, что пользователи имеют доступ только к тем привилегиям, которые им необходимы для выполнения своих рабочих функций.
В вашем конкретном сценарии хорошим подходом будет использование хранилища паролей для управления паролями root/администратора и внедрение sudoers для ограничения команд для обычных пользователей. Это гарантирует, что только авторизованные пользователи смогут получить доступ к привилегированным учетным записям, и ограничивает потенциальное влияние любого несанкционированного доступа.