Конфігурація аутентифікації користувача в ОС

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

Конфігурація комп'ютера для аутентифікації зазвичай включає конфігурацію ОС, firmware і програм на сервері, таких як ПО, яке реалізує мережевий сервіс. У спеціальних випадках для сайтів з високим ризиком або що зберігають важливі дані можна також застосовувати апаратуру для аутентифікації, наприклад, токени або пристрої з одноразовими паролями. Використання аутентифікаційних механізмів, в яких аутентифікаційна інформація є перевикористовуваною (наприклад, паролі) і передається в явному вигляді по мережі, не рекомендується, тому що інформація може бути перехоплена і задіяна таким, що атакує для підробки під аутентифікаційного користувача.

Для гарантії того, що відповідна аутентифікація користувача виконується, необхідно виконати наступні кроки:

· Видалити або заборонити невживані акаунты і групи, створені за умовчанням. Конфігурація ОС за умовчанням часто включає акаунт guest (як з паролем, так і без), акаунти рівня адміністратора або root, пов'язані з локальними і мережевими сервісами. Імена і паролі цих акаунтів добре відомі. Видаленню або забороні непотрібних акаунтів запобігає їх використання для проникнення, включаючи акаунти guest, на комп'ютерах, що містять чутливу інформацію. Якщо існує вимога залишити акаунт або групу guest, слід обмежити їх доступ і змінити пароль відповідно до політики для паролів в організації. Для акаунтів за умовчанням, які необхідно залишити, слід змінити імена (де можливо, особливо для акаунтів рівня адміністратора або root) і паролі відповідно до політики для паролів. Слід пам'ятати, що імена акаунтів і паролі за умовчанням добре відомі зловмисникам.

· Заборонити не інтерактивні акаунти. Заборонити акаунти (і пов'язані з ними паролі), які повинні існувати, але не вимагають інтерактивного входу. Для Unix-систем заборонити вхідний shell або надати вхідний shell з функціональністю NULL (/bin/false).

· Створити групи користувачів. Прив'язати користувачів до відповідних груп і призначати права групам. Даний підхід переважніше, чим призначати права індивідуальним користувачам.

· Створити акаунти користувачів. Визначити, хто авторизований використовувати кожен комп'ютер і його сервіси. Створити тільки необхідні акаунти. Не допускати використання акаунтів, що розділяються.

· Перевірити політику для паролів в організації. Встановити паролі акаунтів відповідним чином. Дана політика повинна розглядати наступне:

o довжина – мінімальна довжина паролів;

o складність – необхідні символи. Необхідні паролі містять букви як верхнього, так і нижнего регістрів і, принаймі, один неалфавітний символ;

o термін використання – як довго можна не змінювати пароль. Вимагати від користувачів періодично змінювати паролі. Пароль рівня адміністратора або root повинен змінюватися кожні 30–120 днів. Пароль користувача також повинен періодично змінюватися. Цей період визначається завдовжки і складністю пароля у поєднанні з чутливістю інформації, що захищається ним;

o перевикористовування – чи може пароль перевикористовуватися. Деякі користувачі намагаються обійти вимогу застарівання пароля, змінюючи пароль на той, який вони вже використали до цього. Потрібно по можливості гарантувати, що користувач не може змінити пароль простим додаванням “передбачуваних” символів до свого початкового пароля. Наприклад, початковий пароль був “mysecret”, а змінений – “mysecret1” або “1mysecret”;

o авторство – кому дозволено змінювати або встановлювати заново паролі і якого типу доказ потрібний перед початком будь-яких змін.

· Конфігурувати комп'ютери для заборони входу після невеликого числа невдалих спроб. Слід пам'ятати, що може бути відносне легко дістати доступ для неавторизованого користувача до комп'ютера, використовуючи автоматичні програмні засоби, які перебирають всі паролі. Щоб ОС не надавала таку можливість, її слід конфігурувати, таким чином, коли вона заборонятиме вхід після трьох невдалих спроб. Зазвичай акаунт блокується на певний час (наприклад, 30 хвилин) або до тих пір, поки користувач з відповідними повноваженнями не активує його.

Це приклад ситуації, коли від web-адміністратора вимагається ухвалення рішення про баланс між безпекою і зручністю. Реалізація даної можливості може допомогти запобігти деяким типам атак, але може також дозволити зловмисникові виконати невдалі спроби входу для недопущення доступу користувача, тобто виконати DoS-атаку для конкретного користувача.

Невдалі спроби мережевого входу не повинні забороняти вхід з консолі користувача і тим більше адміністратора. Відмітимо також, що всі невдалі спроби по мережі або з консолі повинні реєструватися. Також, якщо віддалене адміністрування не передбачене, слід заборонити можливість входу по мережі акаунтам рівня адміністратора або root.

· Інсталювати і конфігурувати інші механізми безпеки для посилення аутентифікації. Якщо інформація на web-сервері вимагає цього – розглянути використання інших аутентифікаційних механізмів, таких як токени, сертифікати клієнта і сервера або системи одноразових паролів. Хоча вони можуть бути дорожчими і важчими в реалізації, це, можливо, виправдається в деяких випадках. Коли використовуються подібні механізми аутентифікації і пристрою, політика організації повинна бути переглянута і в ній відбитий якнайкращий спосіб їх застосування.

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

Як наголошувалося раніше, порушник, використовуючи мережеві сніфери, може легко перехопити перевикористовувані паролі, передавані по мережі в явному вигляді. Замість цього слід використовувати менш уразливі технології аутентифікації і шифрування, такі як SSH і SSL/TLS.