Чи найкращі практики мати окремий вхід для домену для адміністраторів домену?

33

Я, як правило, люблю налаштовувати окремі входи для себе, один із регулярними дозволами користувача та окремий для адміністративних завдань. Наприклад, якщо домен був XXXX, я створив би XXXX \ bpeikes та XXXX \ adminbp. Я завжди робив це, тому що відверто кажучи, я не довіряю собі ввійти в систему як адміністратор, але в кожному місці, де я працював, системні адміністратори, здається, просто додають свої звичайні облікові записи до групи адміністраторів домену.

Чи є найкращі практики? Я бачив статтю з MS, яка, схоже, говорить про те, що ви повинні використовувати Run As, а не входити в систему як адміністратор, але вони не дають приклад реалізації, і я ніколи не бачив, щоб хтось це робив.

— Бенджамін Пейкес
джерело

1

Оскільки той, хто займається в основному в Linux / Unix і не є експертом Windows, чи не саме це повинно виправити UAC? Я маю на увазі, щоб можна було користуватися одним обліковим записом, але все-таки лише авторизовані процеси отримували адміністративні пільги.

— Dolda2000

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

— HopelessN00b

1

@ HopelessN00b: А ви говорите, що UAC не стосується цих речей? Чому ні? Чи є технічні причини, чи їх реалізації просто не вистачає?

— Dolda2000

2

@ Dolda2000 Ну, UAC повинен був виправити проблему з тим, що зловмисне програмне забезпечення могло використовувати контекст адміністратора користувача, який увійшов у систему, щоб встановити себе на ПК кінцевих користувачів та споживачів. І це робить. Це також заблокує цей конкретний вектор від використання контексту користувача адміністратора домену для локальної установки зловмисного програмного забезпечення, однак, це не ступінь проблем безпеки, пов'язаних із запуском адміністратора домену замість обмеженого користувача.

— HopelessN00b

1

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

— Монсьє

25

"Найкраща практика" зазвичай диктує LPU (найменш привілейований користувач) ... але ви праві (як ETL і Joe так +1), що люди рідко дотримуються цієї моделі.

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

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

Підтримувати групи Domain Adminsта Administratorsрівні домену красивими та чистими з мінімальними обліковими записами - це завжди хороша ідея. Але не просто діліться загальними обліковими записами адміністратора домену, якщо ви можете цього уникнути. Інакше є ризик того, що хтось щось зробить, а потім пальцем вкаже між сисадмінами "це я не використовував цей рахунок". Краще мати індивідуальні акаунти або використовувати щось на зразок CyberArk EPA, щоб перевірити його правильно.

Крім того, у цих рядках ваша Schema Adminsгрупа завжди повинна бути ВИПУСКОВОЮ, якщо ви не вносите зміни до схеми, а потім внесете обліковий запис, внесете зміни та вилучите обліковий запис. Те саме можна сказати, Enterprise Adminsособливо для однієї доменної моделі.

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

Нарешті, ви повинні використовувати SCOM, Netwrix або інший метод для аудиту будь-якої привілейованої групи та повідомляти відповідну групу в ІТ, коли хтось із членів цієї групи змінився. Це дасть вам голову сказати "почекай хвилинку, чому так і так раптом Адміністратор домену?" тощо.

Зрештою, є причина, яку називають "Найкраща практика", а не "Тільки практика" ... Є прийнятні варіанти, які ІТ-групи роблять на основі власних потреб та філософії щодо цього. Деякі (як сказав Джо) просто ледачі ... а інші просто не байдужі, оскільки їм не цікаво забивати один отвір у безпеці, коли вже сотні і щодня воюють для боротьби. Однак тепер, коли ви все це прочитали, вважайте себе одним із тих, хто буде боротися з доброю боротьбою, і зробіть все можливе, щоб забезпечити безпеку. :)

Список літератури:

http://www.microsoft.com/en-us/download/details.aspx?id=4868

http://technet.microsoft.com/en-us/library/cc700846.aspx

http://technet.microsoft.com/en-us/library/bb456992.aspx

— Очисник
джерело

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

— Джим Б

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

— TheCleaner

28

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

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

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

— joeqwerty
джерело

12

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

Також неймовірно корисно протидіяти викраденням маркерів аутентифікації Pass Hash або Windows. ( Приклад ) Правильний тест на проникнення це доведе легко. А саме, як тільки зловмисник отримає доступ до локального облікового запису адміністратора, він використовуватиме цю силу для переходу в процес із маркером домену адміністратора. Тоді вони фактично мають ці повноваження.

Що стосується прикладу людей, які використовують це, моя компанія робить! (200 осіб, команда з 6 чоловік) Насправді, наші адміністратори домену мають -ТРИ-акаунти. Один для щоденного використання, один - для адміністрування / встановлення ПК на місцевому рівні. Третій - це облікові записи адміністратора домену та використовуються виключно для адміністрування серверів та домену. Якби ми хотіли бути більш параноїчними / захищеними, напевне, був би поряд.

— Крістофер Карел
джерело

Три облікові записи ... цікаво ... Я повинен врахувати, що для

— настання

1

Те саме у моїй компанії. Звичайний настільний обліковий запис, обліковий запис адміністратора для доступу локального адміністратора на клієнтські комп'ютери І окремий обліковий запис адміністратора сервера. Обидва облікові записи адміністратора не мають електронної пошти та доступу до Інтернету. Єдине питання полягає в тому, що обліковий запис сервера-адміністратора потребує місцевих адміністраторських прав на робочій станції, або ж UAC заважає запускати MMC локально з RunAs як обліковий запис адміністратора сервера. (Можна використовувати RDP на сервері та запускати все звідти, але це часом перешкоджає, якщо вам потрібно скопіювати / вставити або порівняти з даними, що працюють на настільному обліковому записі.)

— Тонні,

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

— Крістофер Карел

8

У своїй колишній компанії я наполягав на тому, щоб усі адміністратори системи отримали 2 рахунки, тобто:

ДОМАН \ st19085
DOMAIN \ st19085a ("a" для адміністратора)

Колеги спочатку неохоче ставилися, але це стало правилом, після типового питання про вірусну загрозу "ми отримали антивірус" було розблоковано застарілою базою вірусів ...

Як ви вже згадували, команда RUNAS могла бути використана (у мене був пакетний сценарій, представлення користувальницького меню, запуск конкретних завдань за допомогою команди RUNAS).
Інша справа - використання консолі управління Microsoft , ви можете зберегти потрібні інструменти та запустити їх клацанням правою кнопкою миші , запустити як ... та свій обліковий запис адміністратора домену.
І останнє, але не менш важливе, я запускав оболонку PowerShell як адміністратор домену та запускав потрібні мені речі звідти.

— Каміль Ле Муелік
джерело

6

Це, по суті, реалізація, яку я використовував (і змушував усіх інших) скрізь, де я мав сказати в цьому. Ви входите на комп’ютер і виконуєте щоденні завдання як звичайний користувач, як і всі інші. Коли вам потрібні права адміністратора, ви Run As/ Run as Administratorта користуєтесь обліковим записом адміністративного користувача. Просто використання одного облікового запису є поганою практикою безпеки, і, на мій досвід, люди, які заперечують, - це той паєпл, якого найбільше потрібно ізолювати від запуску всього в якості адміністратора.

— HopelessN00b

+1 чудове спостереження від @ HopelessN00b: "люди, які заперечують, - це люди, яких найбільше потрібно ізолювати від запуску всього адміністратора"

— mr.b

Насправді вам слід скористатися окремою робочою станцією, яка була заблокована для роботи лише адміністратора

— Jim B

4

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

Плюси використання вашого звичайного щоденного рахунку для діяльності адміністратора домену: Так, усі адміністративні інструменти працюють на моїй робочій станції без рун! W00t!

Мінуси використання вашого звичайного щоденного рахунку для діяльності адміністратора домену: Страх. ;) Технологія настільних ПК просить вас подивитися на машину, оскільки він не може зрозуміти, що з цим не так, ви ввійдете, у неї є вірус. Відключіть мережевий кабель, змініть пароль (де-небудь ще). Коли менеджери запитують вас, чому ви не отримуєте свою електронну пошту на особисту ожину через свого мобільного оператора, ви пояснюєте, що вони зберігають ваш пароль DOMAIN ADMIN на своїх серверах, коли ви це робите. І т. Д. Ваш високо привілейований пароль використовується для таких речей, як ... веб-пошта, vpn, увійдіть на цю веб-сторінку. (Справедливо). Для справедливості мій обліковий запис був заблокований із веб-сторінки "змінити пароль", так що принаймні там було це. Якщо я хотів би змінити свій старий пароль LDAP, який веб-сторінка синхронізувала, я б повинен був перейти до столу колеги.)

Плюси використання іншого облікового запису для діяльності адміністратора домену: Намір. Цей обліковий запис призначений для адміністративних інструментів тощо, а не для електронної пошти, веб-пошти, vpn, входу на веб-сторінки тощо. Отже, менше побоювання, що мої звичайні дії "користувача" піддають ризику весь домен.

Мінуси використання іншого облікового запису для діяльності адміністратора домену: я повинен використовувати руни для адміністративних інструментів. Це просто не так боляче.

Версія TL; DR: мати окремий обліковий запис просто простіше. Це також найкраща практика, оскільки це найменш необхідна пільга .

— Кетрін Вільярд
джерело

2

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

Нічого гіршого, ніж адміністратор, який каже "це працює на мене" і закриває квиток :)

— Том Ньютон
джерело

+1 за визнання, що щоденне використання облікового запису на рівні користувача підвищує ефективність усунення несправностей.

— Я кажу, відновіть Моніку

1

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

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

— ETL
джерело

0

додавши мої 2 копійки на основі фактичного досвіду ..

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

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

— бадбанана
джерело

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

— Джеральд Шнайдер

це не теорія, ми тут це практикуємо ;-), з мого досвіду, ви ветеринуєте людей, яким ви будете надавати такі пільги, а не просто здаєте їх на прохання.

— badbanana