Рекомендуется ли иметь отдельный логин для домена для администраторов домена?

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 и Джо, так что +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 человек) На самом деле, у наших администраторов доменов есть -THREE- учетные записи. Один для повседневного использования, один для администрирования ПК / локальной установки программного обеспечения. Третий - это учетные записи администратора домена, которые используются исключительно для администрирования серверов и домена. Если бы мы хотели быть более параноидальными / безопасными, четвертый, вероятно, был бы в порядке.

— Кристофер Карел
источник

Три аккаунта ... интересно ... Я должен учитывать, что для надвигающегося изменения домена в моей компании ...

— pepoluan

1

То же самое в моей компании. Обычная учетная запись рабочего стола, учетная запись администратора для локального доступа администратора на клиентских компьютерах и отдельная учетная запись администратора сервера. Обе учетные записи администратора не получают электронную почту и доступ в интернет. Единственная проблема заключается в том, что учетной записи сервера-администратора требуются права локального администратора на рабочей станции, иначе UAC мешает запуску MMC локально с RunAs в качестве учетной записи сервера-администратора. (Может использовать RDP на сервере и запускать все оттуда, но иногда это действительно мешает, если вам нужно скопировать / вставить или сравнить с данными, которые запускаются на учетной записи рабочего стола.)

— Тонни

Нам удалось добиться того, что наши администраторы доменов RDP подключились к серверу для их работы по управлению. Copy & Paste на самом деле перемещается по RDP на удивление хорошо. И на этом единственном сервере уже установлены все наши утилиты управления. Но, как говорится ... Я считаю, что группа администраторов домена по умолчанию имеет права локального администратора. Я просто предпочитаю, чтобы эти учетные данные никогда не касались настольных компьютеров, чтобы предотвратить кражу токенов и тому подобное.

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

8

В моей бывшей компании я настаивал на том, что все системные администраторы получили 2 учетных записи, а именно:

Домен \ st19085
ДОМЕН \ st19085a («а» для администратора)

Сначала коллеги отказывались, но это стало практическим правилом после того, как типичный вопрос об угрозе вируса «мы получили антивирус» был разоблачен устаревшей вирусной базой ...

Как вы упомянули, можно использовать команду RUNAS (у меня был пакетный скрипт, представляющий пользовательское меню, запускающий определенные задачи с помощью команды RUNAS).
Еще одна вещь - это использование консоли управления Microsoft , вы можете сохранить необходимые инструменты и запустить их с помощью щелчка правой кнопкой мыши , Запуск от имени ... и вашей учетной записи администратора домена.
Последнее, но не менее важное, я использовал для запуска оболочки PowerShell от имени администратора домена и запуска необходимого для этого материала.

— Камиль Ле Муэль
источник

6

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

— HopelessN00b

+1 большое наблюдение @ HopelessN00b: «люди, которые возражают, - это люди, которых больше всего нужно изолировать от запуска всего с

— правами

На самом деле вы должны использовать отдельную рабочую станцию, которая была заблокирована для запуска только администратора

— Джим Б

4

Я работал в местах, которые делают это обоими способами, и обычно предпочитают иметь отдельный аккаунт. На самом деле все намного проще, вопреки тому, что неохотные пользователи / клиенты joeqwerty, похоже, думают:

Плюсы использования вашей обычной, повседневной учетной записи для действий администратора домена: Yay, все инструменты администрирования работают на моей рабочей станции без runas! W00t!

Минусы использования вашего обычного ежедневного аккаунта для действий администратора домена: Страх. ;) Настольный техник просит вас посмотреть на компьютер, потому что он не может понять, что с ним не так, вы входите, на нем есть вирус. Отключите сетевой кабель, измените пароль (где-то еще). Когда менеджеры спрашивают вас, почему вы не получаете свою рабочую электронную почту на свой персональный blackberry через своего оператора сотовой связи, вы получаете объяснение, что они сохраняют ваш пароль DOMAIN ADMIN на своих серверах, когда вы делаете это. И т. Д., И т. Д. Ваш высоко привилегированный пароль используется для таких вещей, как ... веб-почта, vpn, войдите на эту веб-страницу (Ew.) (Честно говоря, моя учетная запись была заблокирована с веб-страницы «изменить пароль», поэтому, по крайней мере, это произошло. Если бы я хотел изменить свой старый пароль LDAP, который синхронизировал веб-страницу, мне пришлось бы перейти на рабочий стол сотрудника.)

Плюсы использования другой учетной записи для действий администратора домена: Намерение. Эта учетная запись предназначена для административных инструментов и т. Д., А не для электронной почты, веб-почты, vpn, логинов веб-страниц и т. Д. Таким образом, меньше опасайтесь, что мои обычные действия "пользователя" подвергают риску весь домен.

Минусы использования другой учетной записи для действий администратора домена: мне нужно использовать runas для административных инструментов. Это просто не так больно.

Версия TL; DR: иметь отдельный аккаунт просто проще. Это также лучшая практика, так как это наименее необходимая привилегия .

— Кэтрин Вилляр
источник

2

Least Priv должна быть достаточной причиной, но в противном случае также учтите, что если вы используете учетную запись с теми же разрешениями, что и у ваших пользователей, вы, скорее всего, столкнетесь с любыми проблемами, которые они делают, - и вы сможете отладить их в своей учетной записи. слишком часто, прежде чем они даже увидели их!

Нет ничего хуже, чем администратор, который говорит «это работает для меня» и закрывает билет :)

— Том Ньютон
источник

+1 за признание того, что ежедневное использование учетной записи уровня пользователя повышает эффективность устранения неполадок.

— Я говорю, восстановите Монику

1

Во всей теории, лучше всего, чтобы вы не использовали высокодоступный вход в систему администратора для своей повседневной деятельности. Существует множество причин, таких как вирусы: если у вас есть вирус и вы выполняете вход в систему администратора домена, то у вируса есть простой способ получить доступ к вашей сети, полный доступ! Возможные ошибки легче сделать наверняка, но я не считаю это самой большой проблемой. Если вы обойдете свой кампус и войдете в систему со своим главным администратором, возможно, кто-то перебирает ваш пароль через ваше плечо. Все подобные вещи.

Но практично ли это? Мне трудно следовать этому правилу, но я бы хотел следовать ему.

— ETL
источник

0

добавив мои 2 цента на основе фактического опыта ..

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

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

— badbanana
источник

Это хорошая теория, но по моему опыту она не работает (по крайней мере, не для всех). Я видел, как коллеги по ошибке удаляли огромные объемы данных из производственных систем (достаточно пустого места в командной строке).

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

это не теория, мы практикуем ее здесь ;-) по моему опыту, вы проверяете людей, которым вы дадите такие привилегии, а не просто передаете их для запроса.

— Бадбанана