Это - лучшие практики, чтобы иметь отдельный вход в систему для домена для администраторов домена?
будучи вовлеченным в длинное (и очень дорогой) проект миграции рекламы, я стал поклонником наличия внутренней рекламы, которая "универсальна" относительно Вашего названия компании. если Вы находитесь в бизнесе, который может быть куплен или объединен с другим бизнесом, можно найти, что необходимо не обязательно изменить домен рекламы из-за бизнес-решения.
например, если Вы находитесь в бизнесе обуви, Вы могли бы купить доменное имя как corpshoe.net и только использовать его для активного каталога. Ваш корпоративный веб-сайт и электронная почта могут остаться такими же как Ваши регулярные доменные имена, и если Ваша компания изменяется, Ваша реклама не имеет к.
я также полагаю, что необходимо владеть названием рекламы во внешнем мире. это просто делает все легче.
«Лучшая практика» обычно диктует LPU (наименее привилегированный пользователь) ... но вы правы (как и ETL и Джо, так и +1), что люди редко следуют этой модели.
Большинство рекомендации - делать то, что вы говорите ... создать 2 аккаунта и не делиться этими аккаунтами с другими. Одна учетная запись не должна иметь прав администратора даже на локальной рабочей станции, которую вы используете теоретически, но опять же, кто следует этому правилу, особенно с UAC в наши дни (который теоретически должен быть включен).
Есть несколько факторов, почему вы хотя хочу пойти по этому пути. Вы должны учитывать безопасность, удобство, корпоративную политику, нормативные ограничения (если таковые имеются), риск и т. Д.
Сохранение групп уровня домена администраторов и администраторов в чистоте и порядке с минимальные учетные записи - всегда хорошая идея. Но не надо t просто делитесь общими учетными записями администратора домена, если можно этого избежать. В противном случае есть риск, что кто-то что-то сделает, а системные администраторы укажут пальцем на то, что «это не я использовал эту учетную запись». Лучше иметь индивидуальные учетные записи или использовать что-то вроде CyberArk EPA для правильного аудита.
Также в этих строках ваша группа Schema Admins всегда должна быть ПУСТОЙ, если вы не вносите изменения в схему, а затем вы введите учетную запись, внесите изменения и удалите учетную запись. То же самое можно сказать и о администраторах предприятия , особенно в модели с одним доменом.
Вы также НЕ должны разрешать привилегированным учетным записям VPN в сети. Используйте обычную учетную запись, а затем поднимите ее, когда потребуется, когда войдете внутрь.
Наконец, вы должны использовать SCOM или Netwrix или какой-либо другой метод для аудита любой привилегированной группы и уведомлять соответствующую группу в ИТ всякий раз, когда какой-либо из членов этой группы изменяется. Это заставит вас сказать: "Погодите, почему вдруг стал администратором домена?" и т. д.
В конце концов, есть причина, по которой это называется «Лучшая практика», а не «Только практика» ... ИТ-группы делают приемлемый выбор на основе их собственных потребностей и философии по этому поводу. Некоторые (как сказал Джо) просто ленивы ... в то время как другим просто все равно, потому что они не заинтересованы в затыкании одной дыры в безопасности, когда уже существуют сотни и ежедневные пожары, с которыми нужно бороться. Однако теперь, когда вы все это прочитали, считайте себя одним из тех, кто будет вести добрую борьбу и делать все возможное, чтобы сохранить безопасность. :)
Ссылки:
http://www.microsoft.com/en-us/download/details.aspx?id=4868
В моей бывшей компании я настаивал, чтобы у всех системных администраторов было 2 аккаунта, то есть:
- ДОМЕН \ st19085
- ДОМЕН \ st19085a ("a" для администратора)
Коллеги сначала сопротивлялись, но это стало практическим правилом после того, как типичный вопрос о вирусной угрозе «мы получили антивирус» был опровергнут устаревшей вирусной базой ...
Как вы упомянули, RUNAS (раньше у меня был пакетный сценарий, представляющий настраиваемое меню, запускающий определенные задачи с помощью команды RUNAS).
Еще одна вещь - использование консоли управления Microsoft , вы можете сохранить нужные инструменты и запустить их правой кнопкой мыши , Запуск от имени ... и ваш аккаунт администратора домена.
- И последнее, но не менее важное: Я запускал оболочку PowerShell от имени администратора домена и запускал оттуда все, что мне было нужно.
Это лучший способ из соображений безопасности. Как уже упоминали другие, это предотвращает случайное выполнение вами каких-либо действий или нарушение безопасности при просмотре сети. Это также ограничивает ущерб, который может нанести ваш личный просмотр - в идеале, ваша повседневная работа не должна иметь даже прав локального администратора, а тем более администратора домена.
Это также невероятно полезно для противодействия Pass the Hash ] или перехват токенов проверки подлинности Windows. ( Пример ) Правильный тест на проникновение легко докажет это. А именно, как только злоумышленник получит доступ к локальной учетной записи администратора, он будет использовать это право для миграции в процесс с токеном администратора домена. Тогда они фактически обладают этими полномочиями.
Что касается примера людей, использующих это, моя компания имеет! (200 человек, команда из 6 человек) Фактически, У наших администраторов домена есть -ТРИ учетных записи. Один для повседневного использования, другой для администрирования ПК / локальной установки программного обеспечения. Третий - это учетные записи администратора домена, которые используются исключительно для администрирования серверов и домена. Если бы мы хотели быть более параноидальными / безопасными, возможно, нам подойдет четвертый.
Я работал в местах, где это делается обоими способами, и обычно предпочитаю иметь отдельную учетную запись. На самом деле это намного проще, вопреки тому, что, кажется, думают упорные пользователи / клиенты joeqwerty:
Плюсы использования вашей обычной повседневной учетной записи для действий администратора домена: Ура, все инструменты администрирования работают на моей рабочей станции без использования runas! W00t!
Минусы использования обычной повседневной учетной записи для действий администратора домена: Страх. ;) Настольный техник просит вас взглянуть на машину, потому что он не может понять, что с ней не так, вы входите в систему, на ней есть вирус. Отключите сетевой кабель, сменить пароль (в другом месте). Когда менеджеры спрашивают вас, почему вы не получаете свою рабочую электронную почту на свой персональный Blackberry через своего оператора сотовой связи, вы должны объяснить, что они хранят ваш пароль DOMAIN ADMIN на своих серверах, когда вы это делаете. И т. Д. И т. Д. Ваш высокопривилегированный пароль используется для таких вещей, как ... веб-почта, vpn, авторизуйтесь на этой веб-странице. (Фу.) (Честно говоря, моя учетная запись была заблокирована на веб-странице «смени свой пароль», так что, по крайней мере, так и было. Если бы я хотел изменить свой старый пароль LDAP, который синхронизировала веб-страница, мне пришлось бы пойти к столу коллеги.)
Плюсы использования другой учетной записи для действий администратора домена: Намерение. Эта учетная запись предназначена для инструментов администрирования и т. Д., А не для электронной почты, веб-почты, vpn, входа на веб-страницы и т. Д. Итак, меньше опасений, что мой обычный «пользователь» деятельность подвергает риску всю область.
Минусы использования другой учетной записи для действий администратора домена: я должен использовать runas для инструментов администрирования. Это не так уж больно.
Версия TL; DR: иметь отдельную учетную запись просто проще. Это также лучшая практика, так как это наименее необходимые привилегии .
По всей теории, лучше не использовать для повседневных действий вход с правами верхнего администратора. Есть много причин, таких как вирусы - если вы заразились вирусом и используете вход в систему администратора домена, то у вируса есть простой способ проникнуть в вашу сеть, полный доступ! Совершить возможные ошибки наверняка легче, но я не считаю это самой большой проблемой. Если вы обойдете свой кампус и войдете в систему со своим главным администратором, кто-то может искать ваш пароль через плечо. Все в таком роде.
Но практично ли это? Мне трудно следовать этому правилу, но я бы хотел ему следовать.
AFAIK, для администраторов домена / сети считается лучшей практикой иметь стандартную учетную запись пользователя для входа на свою рабочую станцию для выполнения рутинных «пользовательских» задач (электронная почта, документация и т. Д.) И иметь именованную административную учетную запись, которая имеет соответствующее членство в группе, чтобы позволить им выполнять административные задачи.
Это модель, которой я стараюсь следовать, хотя ее сложно реализовать, если существующий ИТ-персонал не привык к этому
Лично я найду ИТ-персонал, который не решится двигаться в этом направлении, я придерживаюсь мнения, что они либо ленивы, неопытны, либо не понимают практики системного администрирования.
Least Priv должно быть достаточной причиной, но если это не так, также учтите, что если вы используете учетную запись с теми же разрешениями, что и ваши пользователи, у вас с большей вероятностью возникнут проблемы, которые они делают. - и вы также можете отлаживать их под своей учетной записью - часто до того, как они их даже увидят!
Нет ничего хуже, чем администратор, который говорит: «У меня работает» и закрывает заявку :)
добавляю мои 2 цента на основе реального опыта ..
знание и постоянная осведомленность о том, что вы используете учетную запись администратора для своей повседневной работы, заставляет вас очень осторожно относиться к своим действиям. поэтому вы не просто нажимаете на электронную почту / ссылку или просто запускаете какие-либо приложения без тройной проверки. я думаю, это держит вас в напряжении.
Использование учетной записи с минимальными привилегиями для повседневной работы делает человека небрежным.