Одним из наших клиентов является компания PCI уровня 1, и их аудиторы внесли предложение в отношении нас как системных администраторов и наших прав доступа.
Мы администрируем их полностью основанную на Windows инфраструктуру из примерно 700 настольных компьютеров / 80 серверов / 10 контроллеров домена.
Они предлагают нам перейти к системе, где у нас есть три отдельных аккаунта:
DOMAIN.CO.UK\UserWS
DOMAIN.CO.UK\UserSRV
DOMAIN.CO.UK\UserDC
- Где WS - учетная запись, которая входит в систему только для WorkStations, - это локальный администратор на WorkStation.
- Где SRV - это учетная запись, которая входит в систему только для серверов без DC, это локальный администратор на серверах.
- Где DC - это учетная запись, которая входит в систему только для контроллеров домена, фактически учетная запись администратора домена.
После этого создаются политики, предотвращающие вход в систему неправильного типа с использованием неправильной учетной записи (в том числе удаление интерактивного входа для учетных записей администраторов домена на компьютерах без DC).
Это необходимо для предотвращения ситуации, когда скомпрометированная рабочая станция может предоставить маркер входа администраторов домена и повторно использовать его против контроллера домена.
Похоже, что это не только очень навязчивая политика для наших повседневных операций, но и значительный объем работы, направленной на то, чтобы решить относительно маловероятную атаку / эксплойт (в любом случае, это мое понимание, возможно, я неправильно понимаю выполнимость этого эксплойта) ,
Мне интересно услышать мнение других администраторов, особенно тех, кто был связан с компанией, зарегистрированной в PCI, и у вас есть подобные рекомендации. Каковы ваши правила в отношении входа администратора.
Напомним, что в настоящее время у нас есть учетная запись пользователя домена, которую мы обычно используем, и учетная запись администратора домена, которую мы также повышаем, когда нам нужны дополнительные права. Честно говоря, мы все немного ленивы и часто просто используем учетную запись администратора домена для повседневных операций, хотя это технически противоречит политике нашей компании (я уверен, что вы понимаете!).
Ответы:
Я работаю с поставщиком PCI первого уровня. У нас есть что-то вроде этого, с некоторыми отличиями.
Аудиторы на самом деле пытаются описать очень реальную проблему, но выполняют невероятно плохую работу, объясняя последствия и анализ потребностей.
Теперь эффективнее скомпрометировать систему, используя хэш пароля или существующий токен. Проще говоря, злоумышленнику больше не нужны ваши имя пользователя и пароль. Теперь есть более простые способы атаковать систему. Ни при каких обстоятельствах вы не должны предполагать или делать вывод, что этот тип атаки маловероятен. Хэш-атаки теперь являются вектором атаки де-факто .
Хеш-атаки на самом деле хуже с учетными записями смарт-карт, что иронично, потому что большинство людей ожидают, что внедрение смарт-карт повысит безопасность системы.
Если учетная запись взломана из-за атаки с использованием хэша, обычным ответом является изменение пароля учетной записи. Это меняет хеш, который используется для аутентификации. Кроме того, нормальное истечение срока действия / смена пароля может привести к вторжению из-за того, что хэш атакующего начнет давать сбой. Однако для смарт-карт пароль является «управляемым системой» (пользователь никогда не вводит пароль для аутентификации), поэтому хэш никогда не изменяется. Это означает, что для учетных записей смарт-карт вторжение может остаться незамеченным гораздо дольше, чем для учетной записи, использующей пароль.
Вот смягчающие меры, которые я бы рассмотрел:
Для учетных записей с поддержкой смарт-карт, которые многие крупные компании используют для учетных записей с высоким уровнем привилегий, меняйте пароль учетной записи с частыми интервалами. Это меняет хэш. Вы также можете изменить хэш, отключив смарт-карту, включив учетную запись, а затем повторно включив ее. Microsoft делает это каждые 24 часа, но вам необходимо оценить потенциальное влияние, которое это может оказать на вашу среду, и составить разумный график, чтобы не создавать дополнительных проблем.
Что касается рабочих станций, я бы вообще не использовал учетные записи домена для администраторов, если это возможно. У нас есть локальная учетная запись, которую можно использовать для повышения уровня операций типа UAC. Это удовлетворяет 99,9% большинства требований по высоте. Рабочие станции, как правило, являются горячими векторами атак из-за отсутствия регламентированного контроля изменений и наличия Java JRE и Flash.
Этот подход работает для нас, потому что у нас есть формальный механизм для управления и применения пароля для локальных учетных записей, и что пароль уникален в каждой системе, и что существует безопасный метод для кого-то, чтобы запросить пароль. Есть также коммерческие приложения, которые могут выполнять эту функцию.
Если вы не можете предоставить локальную учетную запись для рабочих станций, тогда да, для административного доступа к рабочим станциям следует использовать отдельную учетную запись домена, а эту учетную запись не следует использовать для административного доступа к серверам. Другим вариантом может быть использование удаленных, неинтерактивных средств управления поддержкой, которые используют LocalSystem для выполнения действий, и механизм аутентификации, отдельный от Windows.
Для учетных записей с самыми высокими привилегиями (Enterprise Admin, Domain Admin и т. Д.) Используйте только сервер перехода. Этот сервер будет подвергаться наиболее строгой защите, контролю изменений и аудиту. Для всех других типов функций административного типа рассмотрите возможность использования отдельной учетной записи администратора. Сервер прыжков следует перезапускать ежедневно, чтобы очистить токены процесса от процесса LSA.
Не выполняйте административные задачи со своей рабочей станции. Используйте усиленный сервер или сервер перехода.
Подумайте об использовании легко сбрасываемых виртуальных машин в качестве переключателей, которые можно сбросить для очистки памяти после каждого сеанса.
Дальнейшее чтение:
https://blogs.technet.com/b/security/archive/2012/12/06/new-guidance-to-mitigate-determined-adversaries-favorite-attack-pass-the-hash.aspx
Отчет Microsoft Security Intelligence, том 13, январь - июнь 2012 г.
http://www.microsoft.com/security/sir/archive/default.aspx
Прочитайте раздел: «Защита от атак через хэш».
Поражение страшных хакерских атак
https://www.infoworld.com/d/security/defeat-dreaded-pass-the-hash-attacks-179753
источник