Файл: Управление правами пользователей в ос windows Локальная политика безопасности Пенза, 2014.doc

Рисунок 3 – Консоль «локальная политика безопасности»
Консоль включает несколько интегрированных контейнеров:

• 
  «Политики учётных записей»;
  
• 
  «Локальные политики»;
  
• 
  «Брандмауэр Windows в режиме повышенной безопасности»;
  
• 
  «Политики диспетчера списка сетей»;
  
• 
  «Политики открытого ключа»;
  
• 
  «Политики ограниченного использования программ»;
  
• 
  «Политики управления приложениями»;
  
• 
  «Политики безопасности IP на «Локальный компьютер»;
  
• 
  «Конфигурация расширенной политики аудита».
  

Каждый контейнер включает свои интегрированные компоненты.

Политики учётных записей. Политика паролей

При помощи этого узла возможно изменение настроек паролей учётных записей пользователей, которые состоят как в домене, так и в рабочих группах. В организациях можно применять одинаковые политики паролей для всех пользователей, входящих в домен или только для отдельных групп при помощи оснастки «Консоль управления групповыми политиками».

В узле «Политика паролей» доступно использование до шести политик безопасности, при помощи которых можно указать наиболее важные параметры безопасности, применяемые для управления паролями учётных записей. Если правильно настроить все шесть политик безопасности, расположенных в этом узле, безопасность паролей пользователей организации значительно повысится. Применив все политики, пользователям действительно придется создавать безопасные пароли, в отличие от тех, которые они считают «сложными». Доступны следующие политики безопасности:

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

Максимальные срок действия пароля

---

. Эта политика указывает период времени, в течение которого пользователь может использовать свой пароль до последующего изменения. По окончанию установленного срока пользователь обязан изменить свой пароль, так как без изменения пароля войти в систему ему не удастся. Доступные значения могут быть установлены в промежутке от 0 до 999 дней. Если установлено значения равное 0, срок действия пароля неограничен. В связи с мерами безопасности желательно отказаться от такого выбора. Если значения максимального срока действия пароля варьируется от 1 до 999 дней, значение минимального срока должно быть меньше максимального. Лучше всего использовать значения от 30 до 45 дней.

Минимальная длина пароля. При помощи этой политики можно указать минимальное количество знаков, которое должно содержаться в пароле. Если активировать этот параметр, то при вводе нового пароля количество знаков будет сравниваться с тем, которое установлено в этой политике. Если количество знаков будет меньше указанного, то придется изменить пароль в соответствии с политикой безопасности. Можно указать значение политики от 1 до 14 знаков. Оптимальным значением для количества знаков для пароля пользователей является 8, а для серверов от 10 до 12.

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

Пароль должен отвечать требованиям сложности. Это одна из самых важных политик паролей, которая отвечает за то, должен ли пароль соответствовать требованиям сложности при создании или изменении пароля. В связи с этими требованиями, пароли должны:

• 
  содержать буквы верхнего и нижнего регистра одновременно;
  
• 
  содержать цифры от 0 до 9;
  
• 
  содержать символы, которые отличаются от букв и цифр (например, !, @, #, $, *);
  
• 
  не содержать имени учётной записи пользователя или частей полного имени пользователя длиной более двух рядом стоящих знаков.
  

---

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

Хранить пароли, используя обратимое шифрование. Для того чтобы пароли невозможно было перехватить при помощи приложений, Active Directory хранит только хэш-код. Но если перед вами встанет необходимость поддержки приложений, использующих протоколы, требующие знание пароля пользователя для проверки подлинности, можно использовать текущую политику. Обратимое шифрование по умолчанию отключено, так как, используя эту политику, уровень безопасности паролей и всего домена в частности значительно понижается. Использование этой функции аналогично хранению пароля в открытом виде.
Политика блокировки учётной записи

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

Групповые политики безопасности Windows могут противостоять таким действиям, используя набор политик узла «Политика блокировки учётной записи». При помощи данного набора политик возможно ограничение количества некорректных попыток входа пользователя в систему. Для этого узла доступны только три политики, которые рассматриваются ниже.

Время до сброса счетчиков блокировки. Active Directory и групповые политики позволяют автоматически разблокировать учётную запись, количество попыток входа в которую превышает установленное вами пороговое значение. При помощи этой политики устанавливается количество минут, которые должны пройти после неудачной попытки для автоматической разблокировки. Разрешается устанавливать значение от одной минуты до 99999. Это значение должно быть меньше значения политики «Продолжительность блокировки учётной записи».

Пороговое значение блокировки

---

. Используя эту политику, можно указать количество некорректных попыток входа, после чего учётная запись будет заблокирована. Окончание периода блокировки учётной записи задается политикой «Продолжительность блокировки учётной записи» или администратор может разблокировать учётную запись вручную. Количество неудачных попыток входа может варьироваться от 0 до 999. Рекомендуется устанавливать допустимое количество от трех до семи попыток.

Продолжительность блокировки учётной записи. При помощи этого параметра можно указать время, в течение которого учётная запись будет заблокирована до её автоматической разблокировки. Можно установить значение от 0 до 99999 минут. В том случае, если значение этой политики будет равно 0, учётная запись будет заблокирована до тех пор, пока администратор не разблокирует её вручную.
Политика Kerberos

В доменах Active Directory для проверки подлинности учётных записей пользователей и компьютеров домена используется протокол Kerberos. Сразу после аутентификации пользователя или компьютера, этот протокол проверяет подлинность указанных реквизитов, а затем выдает особый пакет данных, который называется «Билет предоставления билета (TGT – Ticket Granting Ticket)». Перед подключением пользователя к серверу для запроса документа на контроллер домена пересылается запрос вместе с билетом TGT, который идентифицирует пользователя, прошедшего проверку подлинности Kerberos. После этого контроллер домена передает пользователю другой пакет данных, называемый билетом доступа к службе. Пользователь предоставляет билет на доступ службе на сервере, который принимает его как подтверждение прохождения проверки подлинности.

Данный узел можно обнаружить только на контроллерах домена. Доступны следующие пять политик безопасности:

Максимальная погрешность синхронизации часов компьютера. Для предотвращения «атак повторной передачи пакетов» существует текущая политика безопасности, которая определяет максимальную разность времени, допускающую Kerberos между временем клиента и временем на контроллере домена для обеспечения проверки подлинности. В случае установки данной политики, на обоих часах должны быть установлены одинаковые дата и время. Подлинной считается та отметка времени, которая используется на обоих компьютерах, если разница между часами клиентского компьютера и контроллера домена меньше максимальной разницы времени, определённой этой политикой.

Максимальный срок жизни билета пользователя

---

. При помощи текущей политики можно указать максимальный интервал времени, в течение которого может быть использован билет представления билета (TGT). По истечении срока действия билета TGT необходимо возобновить существующий билет или запросить новый.

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

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

Принудительные ограничения входа пользователей. Эта политика позволяет определить, должен ли центр распределения ключей Kerberos проверять каждый запрос билета сеанса на соответствие политике прав, действующей для учётных записей пользователей.

Практическое задание №7

1. 
   Запустить консоль «Локальные политика безопасности», перейти к настройке «Политике учётных записей».
   
2. 
   Перейти к пункту «Пороговое значение блокировки» в «Политике блокировки учётной записи», установить параметр равный 3 попыткам.
   
3. 
   Перейти к пункту «Минимальная длина пароля» в «Политике паролей», установить значение 10.
   
4. 
   Перейти к пункту «Пароль должен отвечать требованиям сложности», поставить галочку.
   

Длина пароля может достигать 128 знаков. Маленький отрывок из поэмы А.С.Пушкина «Руслан и Людмила» со всеми знаками препинания, набранный русскими буквами в латинской раскладке и установленный в качестве пароля, может привести в замешательство любого взломщика: E kerjvjhmz le, ptktysq, Pkfnfz wtgm yf le,t njv, B lytv b yjxm. Rjn extysq, Dct [jlbn gj wtgb rheujv/. Этот пароль надежный, а запомнить его очень просто: «У лукоморья дуб зеленый, златая цепь на дубе том, и днём и ночью кот учёный, всё ходит по цепи кругом».

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

---