Політика облікового запису адміністраторів домену (після аудиту PCI)

Одним із наших клієнтів є компанія PCI Tier 1, і їхні аудитори зробили пропозицію щодо нас як системних адміністраторів та наших прав доступу.

Ми адмініструємо їх повністю на базі Windows інфраструктури приблизно з 700 настільних ПК / 80 серверів / 10 контролерів домену.

Вони пропонують перейти до системи, де у нас є три окремі облікові записи:

DOMAIN.CO.UK\UserWS  
DOMAIN.CO.UK\UserSRV  
DOMAIN.CO.UK\UserDC  

• Там, де WS є обліковим записом, який входить у систему лише WorkStation, є локальним адміністратором WorkStation
• Якщо SRV - обліковий запис, який входить у систему лише на серверах, що не є постійним струмом, - локальний адміністратор на серверах
• Якщо DC - це обліковий запис, який входить у систему лише до контролерів домену, фактично обліковий запис адміністратора домену

Тоді діє політика для запобігання входу в неправильний тип системи з неправильного облікового запису (що включає видалення інтерактивного входу для облікових записів адміністратора домену на машинах, що не мають постійного струму)

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

Це здається не лише дуже нав'язливою політикою для наших повсякденних операцій, але й значною роботою над вирішенням того, що є надзвичайно малоймовірним нападом / експлуатуванням (це я так чи інакше розумію, можливо, я неправильно розумію доцільність цього подвигу) .

Мені цікаво почути думки інших адміністраторів, особливо тих, хто був причетний до компанії, зареєстрованої PCI, і ви маєте подібні рекомендації. Які ваші політики щодо логотипів адміністратора.

Для запису в даний час у нас є обліковий запис Користувача домену, який ми зазвичай використовуємо, з обліковим записом адміністратора домену, який ми також піднімаємо, коли нам потрібні додаткові права. Чесно кажучи, ми всі трохи ліниві і часто просто використовуємо обліковий запис Адміністратора домену для щоденних операцій, хоча це технічно суперечить політиці нашої компанії (я впевнений, що ви розумієте!).

Я є постачальником PCI першого рівня. У нас є щось подібне на місці з кількома відмінностями.

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

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

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

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

Ось пом'якшення, які я б врахував:

• Для облікових записів із підтримкою смарт-карт, які багато великих компаній використовують для високопривілейованих облікових записів, часто змінюйте пароль облікового запису. Це змінює хеш. Ви також можете змінити хеш, включивши обліковий запис un-smartcard, увімкнувши його, а потім повторно включивши його. Microsoft робить це кожні 24 години, але вам потрібно оцінити потенційний вплив, який це може спричинити для вашого оточення, і встановити здоровий графік, щоб не створювати додаткових проблем.

• Для робочих станцій я взагалі не використовував облікові записи домена для цілей адміністратора. У нас є локальний обліковий запис, який можна використовувати для підйому для операцій типу UAC. Це задовольняє 99,9% більшості вимог висоти. Робочі станції, як правило, є гарячими векторами атаки, через відсутність режиму регулювання змін та існування Java JRE та Flash.

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

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

• Для найвищих привілейованих облікових записів (Enterprise Admin, Administrator домену тощо) використовуйте лише стрибковий сервер. Цей сервер підлягає найбільш обмежувальній безпеці, контролю змін та аудиту. Для всіх інших типів функцій адміністративного типу розгляньте наявність окремого адміністративного рахунку. Сервер стрибків повинен бути перезапущений щоденним перезавантаженням, щоб очистити маркери процесу від процесу LSA.

• Не виконуйте адміністративних завдань зі своєї робочої станції. Використовуйте загартований сервер або сервер стрибків.

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

Подальше читання:

https://blogs.technet.com/b/security/archive/2012/12/06/new-guidance-to-mitigate-determined-adversaries-favorite-attack-pass-the-hash.aspx

Microsoft Report Intelligence Report, том 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