Локальна політика безпеки. Частина 2: Політики облікових записів, Windows, Операційні системи, статті

У попередній частині статті про локальні політиках безпеки ви дізналися про методи використання локальних політик безпеки, за допомогою яких можна управляти настройками, що мають відношення до безпеки, як вашого домашнього комп’ютера, так і комп’ютерів, розташованих в доменній середовищі організації. Починаючи з цієї статті, будуть детально розглядатися всі категорії політик, які відносяться до забезпечення безпеки ваших комп’ютерів. У цій статті ви дізнаєтеся про управління перевірки автентичності користувача облікових записів, а саме про вузол “Політики облікових записів”. Застосування цих політик поширене в підприємствах з доменної середовищем. Для забезпечення безпеки ваших комп’ютерів, застосування політик цієї групи на комп’ютерах, що не входять в доменну середовище (наприклад, використання політик на вашому домашньому комп’ютері) допоможе вам істотно підвищити безпеку комп’ютера.

Без сумніву, корпоративні облікові записи становлять величезний інтерес для хакерів, яких може зацікавити розкрадання корпоративної інформації, а також отримання доступу до комп’ютерів вашого підприємства. Тому, одним з рішень, що дозволяють істотно убезпечити інфраструктуру підприємства, є використання безпечних складних паролів для зниження можливості проникнення зловмисниками. Також не варто забувати про те, що зловмисники можуть знаходитися набагато ближче, ніж ви собі уявляєте. Я настійно рекомендую змусити користувачів використовувати складні паролі, включаючи літери різних регістрів, цифри, а також спеціальні символи для паролів до своїх облікових записів і ні в якому разі не залишати свої паролі у всіх на виду. Я маю на увазі не записувати їх на папір і не розміщувати на своєму робочому місці, поруч з комп’ютером, а тим більше – не закріплювати їх на своїх моніторах (що зустрічається досить таки часто). Також користувачі зобов’язані змінювати свої паролі по закінченню терміну, який ви встановите. Наприклад, вказавши термін дії пароля в 30 днів, по його закінченню перед входом користувача в свій обліковий запис, відобразиться діалог з вимогою зміни поточного пароля.


Для того щоб знайти політики, призначені для управління обліковими записами, в редакторі управління груповими політиками відкрийте вузол Конфігурація компьютераПараметри безопасностіПолітікі облікових записів. Розглянемо детальніше кожну політику безпеки, яка застосовується для управління паролями і блокуванням облікових записів користувачів.


Політика паролів


За допомогою цього вузла ви можете змінювати налаштування паролів облікових записів користувачів, які складаються як в домені, так і в робочих групах. В організаціях ви можете застосовувати однакові політики паролів для всіх користувачів, що входять в домен або тільки для окремих груп за допомогою оснастки “Консоль управління груповими політиками”. У вузлі “Політика паролів” ви можете використовувати до шести політик безпеки, за допомогою яких можна вказати найбільш важливі параметри безпеки, які застосовуються для управління паролями облікових записів. Настійно рекомендую не ігнорувати дані політики. Навіть якщо ви умовте своїх користувачів використовувати складні паролі, не факт, що вони дійсно будуть це робити. Якщо ви правильно налаштуєте всі шість політик безпеки, розташованих в цьому вузлі, безпека паролів користувачів вашої організації значно підвищиться. Застосувавши всі політики, користувачам дійсно доведеться створювати безпечні паролі, на відміну від тих, які вони вважають “складними”. Доступні наступні політики безпеки:


*


Рис. 1 Вузол “Політика паролів”


Вести журнал паролів. Наскільки не був би ваш пароль безпечним, зловмисник рано чи пізно зможе його підібрати. Тому необхідно періодично змінювати паролі облікових записів. За допомогою цієї політики ви можете вказати кількість нових паролів, які призначаються для облікових записів до повторного використання старого пароля. Після того як ця політика буде налаштована, контролер домену буде перевіряти кеш попередніх хеш-кодів користувачів, щоб в якості нового пароля користувачі не могли використовувати старий. Число паролів може варіюватися від 0 до 24. Тобто, якщо ви вказали в якості параметра число 24, то користувач зможе використовувати старий пароль з двадцять п’ятого разу.


Максимальні термін дії пароля. Ця політика вказує період часу, протягом якого користувач може використовувати свій пароль до наступної зміни. По закінченню встановленого терміну користувач зобов’язаний змінити свій пароль, так як без зміни пароля увійти в систему йому не вдасться. Доступні значення можуть бути встановлені в проміжку від 0 до 999 днів. Якщо встановлено значення рівне 0, термін дії пароля необмежений. У зв’язку із заходами безпеки бажано відмовитися від такого вибору. Якщо значення максимального терміну дії пароля варіюється від 1 до 999 днів, значення мінімального терміну має бути менше максимального. Краще всього використовувати значення від 30 до 45 днів.


Мінімальна довжина пароля. За допомогою цієї політики ви можете вказати мінімальну кількість знаків, яке повинно міститися в паролі. Якщо активувати цей параметр, то при введенні нового пароля кількість знаків буде порівнюватися з тим, яке встановлено в цій політиці. Якщо кількість знаків буде менше вказаного, то доведеться змінити пароль відповідно до політики безпеки. Можна вказати значення політики від 1 до 14 знаків. Оптимальним значенням для кількості знаків для пароля користувачів є 8, а для серверів від 10 до 12.


Мінімальні термін дії пароля. Багато користувачів не захочуть обтяжувати себе запам’ятовуванням нового складного пароля і можуть спробувати відразу змінити ввести таку кількість нових паролів, щоб використовувати свій добре відомий початковий пароль. Для запобігання подібних дій була розроблена поточна політика безпеки. Ви можете вказати мінімальну кількість днів, протягом якого користувач повинен використовувати свій новий пароль. Доступні значення цієї політики встановлюються в проміжку від 0 до 998 днів. Встановивши значення рівне 0 днів, користувач зможе змінити пароль відразу після створення нового. Необхідно звернути увагу на те, що мінімальний термін дії нового пароля не повинен перевищувати значення максимального терміну дії.


Пароль повинен відповідати вимогам складності. Це одна з найважливіших політик паролів, яка відповідає за те, чи повинен пароль відповідати вимогам складності при створенні або зміні пароля. У зв’язку з цими вимогами, паролі повинні:



У тому випадку, якщо користувач створив або змінив пароль, який відповідає вимогам, то пароль пропускається через математичний алгоритм, перетворюють його в хеш-код (також званий односторонньої функцією), про який йшла мова в політиці “Вести журнал паролів”.


Зберігати паролі, використовуючи оборотне шифрування. Для того щоб паролі неможливо було перехопити за допомогою додатків, Active Directory зберігає тільки хеш-код. Але якщо перед вами постане необхідність підтримки додатків, що використовують протоколи, вимагають знання пароля користувача для перевірки автентичності, ви можете використовувати поточну політику. Оборотне шифрування за умовчанням відключено, оскільки, використовуючи цю політику, рівень безпеки паролів і всього домену зокрема значно знижується. Використання цієї функції аналогічно зберігання пароля у відкритому вигляді.


Політика блокування облікового запису


Навіть після створення складного пароля і правильного налаштування політик безпеки, облікові записи ваших користувачів усе ще можуть бути піддані атакам недоброзичливців. Наприклад, якщо ви встановили мінімальний термін дії пароля в 20 днів, у хакера достатньо часу для підбору пароля до облікового запису. Дізнатися ім’я облікового запису не є проблемою для хакерів, так як, найчастіше імена облікових записів користувачів збігається з ім’ям адреси поштової скриньки. А якщо буде відомо ім’я, то для підбору пароля просто знадобиться які дві-три тижні.


Групові політики безпеки Windows можуть протистояти таким діям, використовуючи набір політик вузла “Політика блокування облікового запису”. За допомогою даного набору політик, у вас є можливість обмеження кількості некоректних спроб входу користувача в систему. Зрозуміло, для ваших користувачів це може бути проблемою, тому що не у всіх вийде ввести пароль за вказану кількість спроб, але зате безпека облікових записів перейде на “новий рівень”. Для цього вузла доступні тільки три політики, які розглядаються нижче.



Рис. 2 “Політика блокування облікового запису”


Час до скидання лічильників блокування. Active Directory і групові політики дозволяють автоматично розблокувати обліковий запис, кількість спроб входу в яку перевищує встановлений вами порогове значення. За допомогою цієї політики встановлюється кількість хвилин, які повинні пройти після невдалої спроби для автоматичного розблокування. Ви можете встановити значення від однієї хвилини до 99999. Це значення повинно бути менше значення політики “Тривалість блокування облікового запису”.


Граничне значення блокування. Використовуючи цю політику, ви можете вказати кількість некоректних спроб входу, після чого обліковий запис буде заблокована. Закінчення періоду блокування облікового запису задається політикою “Тривалість блокування облікового запису” або адміністратор може розблокувати обліковий запис вручну. Кількість невдалих спроб входу може варіюватися від 0 до 999. Я рекомендую встановлювати допустиму кількість від трьох до семи спроб.


Тривалість блокування облікового запису. За допомогою цього параметра ви можете вказати час, протягом якого обліковий запис буде заблокована до її автоматичної розблокування. Ви можете встановити значення від 0 до 99999 хвилин. У тому випадку, якщо значення цієї політики буде дорівнює 0, обліковий запис буде заблокована до тих пір, поки адміністратор не розблокує її вручну.


 

Політика Kerberos


В доменах Active Directory для перевірки автентичності облікових записів користувачів і комп’ютерів домену використовується протокол Kerberos. Відразу після аутентифікації користувача або комп’ютера, цей протокол перевіряє справжність зазначених реквізитів, а потім видає особливий пакет даних, Який називається “Квиток надання квитка (TGT – Ticket Granting Ticket)”. Перед підключенням користувача до сервера для запиту документа на контролер домену пересилається запит разом з квитком TGT, який ідентифікує користувача, що пройшов перевірку автентичності Kerberos. Після цього контролер домену передає користувачеві ще один пакет даних, званий квитком доступу до служби. Користувач надає квиток на доступ службі на сервері, який приймає його як підтвердження проходження перевірки автентичності.


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



Рис. 3. “Політика Kerberos”


Максимальна похибка синхронізації годинника комп’ютера. Для запобігання “атак повторної передачі пакетів” існує поточна політика безпеки, яка визначає максимальну різницю часу, допускає Kerberos між часом клієнта і часом на контролері домену для забезпечення перевірки автентичності. У разі установки даної політики, на обох годинниках повинні бути встановлені однакові дата і час. Справжньою вважається та відмітка часу, яка використовується на обох комп’ютерах, якщо різниця між годинами клієнтського комп’ютера і контролера домену менше максимальної різниці часу, визначеної цією політикою.


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


Максимальний термін життя квитка служби. Використовуючи цю політику безпеки, сервер буде видавати повідомлення про помилку в тому випадку, якщо клієнт, запитувач підключення до сервера, пред’являє прострочений квиток сеансу. Ви можете визначити максимальну кількість хвилин, протягом якого отриманий квиток сеансу дозволяється використовувати для доступу до конкретної службі. Квитки сеансів застосовуються тільки для перевірки справжності на нових підключеннях до серверів. Після того як підключення пройде перевірку справжності, термін дії квитка втрачає сенс.


Максимальний термін життя для відновлення квитка користувача. За допомогою даної політики ви можете встановити кількість днів, протягом яких може бути відновлений квиток надання квитка.


Примусові обмеження входу користувачів. Ця політика дозволяє визначити, чи повинен центр розподілу ключів Kerberos перевіряти кожен запит квитка сеансу на відповідність політиці прав, що діє для облікових записів користувачів.


Висновок


У наш час все частіше доводиться піклуватися про безпеку облікових записів, як для клієнтських робочих місць вашої організації, так і домашніх комп’ютерів. Недоброзичливцями, які хочуть отримати доступ над вашим комп’ютером можуть бути не тільки хакери, розташовані в тисячах і сотнях тисяч кілометрів від вас, але і ваші співробітники. Захистити свої облікові записи допомагають політики облікових записів. У цій статті докладно розповідається про всі політиках, які мають відношення до паролів ваших облікових записів, блокування облікового запису при спробі підбору пароля, а також політикам Kerberos – протоколу, використовуваного для перевірки автентичності облікових записів користувачів і комп’ютерів домену. У наступній статті ви дізнаєтеся про політиків аудиту.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*