Представьте себе ситуацию, Вы руководите IT-службой крупной компании, у Вас несколько доменов и несколько тысяч пользователей в Active Directory. В подчинении у Вас как минимум несколько системных администраторов, каждый из которых выполняет свои обязанности. Неожиданно сотрудники в одном из подразделений жалуются на то, что они никак не могут придумать себе новые пароли после истечения срока действия старых – система не принимает заново создаваемые пароли. После быстрого просмотра политики паролей соответсвующего подразделения Вы понимаете, что длина и сложность пароля были изменены. Чтобы узнать, что стало причиной, Вы обращаетесь к журналам событий и понимаете, что информации о том, когда и кем была изменена политика паролей, нет – журналы уже перезаписались. Кто изменил политику – останется тайной.
А вот еще один пример: администратор вдруг обнаруживает, что один из пользователей может ставить без каких-либо проблем ПО на свою машину. И это при том, что в групповой политике для OU, в которой состоит пользователь, такая установка была запрещена. Опять-таки информацию о том, кто и когда разрешил такую установку необходимо искать в журналах событий, продираясь сквозь “шум” неинформативных данных.
Все это приводит к однозначному выводу IT-служба компании должна уделять внимание происходящим в групповых политиках изменениях. Делать это необходимо, чтобы не допустить как образования дыр в системе информационной безопасности (“какой там софт поставит нерадивый пользователь?”), так и обеспечения непрерывности деятельности (когда 200 человек одновременно не могут зайти на свои машины, так как не в состоянии придумать подходящий пароль).
Только на практике выходит так, что контроль над изменениями групповых политик редко кто практикует. И лишь при возникновении проблемы или обнаружении подозрительной активности начинается поиск источника проблемы путем анализа журналов событий и опроса коллег.
Читать полностью »
