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