Назад | Перейти на главную страницу

Как должны быть защищены привилегированные учетные записи в Linux и Windows?

Я недавно начал работать в сфере безопасности приложений в фирме среднего размера, после того как я более 5 лет занимался консалтингом по безопасности (пентестинг и т. Д.). Одна из самых больших проблем, которые я вижу здесь с самого начала, заключается в том, что сканеры безопасности и другие инструменты используют доступ root / Administrator, поскольку это то, что поставщики сказали им использовать, скорее всего, из-за простоты настройки. Мне очень не нравится эта идея. Например, Nexpose и Nessus настроены на использование root и Administrator.

Мой вопрос - каковы наилучшие методы управления доступом к этим привилегированным учетным записям? Моя первоначальная мысль заключалась в том, чтобы иметь систему хранилища паролей, которая знает только пароли к системе. Затем пользователь может «проверить» пароль root / администратора по мере необходимости. «В частности, для Nessus только несколько команд запускаются от имени root, поэтому я думаю, что имеет смысл просто создать стандартного пользователя и добавить его в sudoers, разрешая только эти конкретные команды.

Спасибо!

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

Для определенных систем управление паролями всех привилегированных учетных записей передается внешнему приложению хранилища паролей, и даже администраторы не знают паролей root / Administrator / DB-owner и т. Д.

В случаях, когда четко определенных RBAC недостаточно и root / Administrator / etc. доступ требуется, администратор запрашивает доступ, после утверждения группой безопасности (принцип четырех глаз, контрольный журнал с номером изменения / инцидента) и через хранилище паролей запускается SSH или RDP с правильными учетными данными из хранилища. Администратор не получает копию пароля, хранящегося в хранилище, в открытом виде. Сеанс SSH или RDP можно отслеживать и записывать для желаемого контрольного журнала. После закрытия сеанса приложение хранилища снова изменит пароль.

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

Риск, которым вы подвергаетесь (на самом деле, реальность), заключается в том, что разрешение инцидентов и даже запланированные работы займут значительно больше времени, но, по крайней мере, у вас будет отличный контрольный журнал, объясняющий, почему!

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

В ваших ящиках Linux отключите вход в систему как root и заставьте пользователей входить в систему как они сами. Если ящик аутентифицируется в LDAP или AD, у вас будет запись таких транзакций. Вам все равно нужно будет предоставить этому пользователю определенные права на поле. Использование sudo после входа в систему также упрощает аудит и отслеживание.

Незнание того, как ваша компания структурирована и разделена, затрудняет ответ на этот вопрос. Безопасность, администраторы сервера, менеджеры приложений - это отдельные подразделения, в которых я работаю. Менеджеры приложений не имеют прав администратора для запуска таких инструментов, только администраторы сервера. Администраторы сервера, которые могут добавлять / удалять / удалять локальные учетные записи в ящике, не могут изменять AD / LDAP. Безопасность проверяет все серверы, чтобы узнать, какие локальные учетные записи находятся на конкретном устройстве, и нужны люди для обоснования их использования.

Использование универсального входа в систему может оставить вашу систему полностью открытой без возможности определить, кто вызвал проблему. Лучше все это заблокировать и предоставить доступ по мере необходимости, чем предполагать, что люди будут честными и начнут лажать. Это больше для вас работы, но позволит вам лучше спать по ночам. Что еще более важно, вы никогда не жили, пока не обнаружили, что один из ваших серверов был взломан, и ИТ-директор хочет знать, почему.