Погано весь час увійти як адміністратор?

У офісі, де я працюю, троє інших членів ІТ-персоналу весь час увійшли до своїх комп’ютерів за допомогою акаунтів, які є членами групи адміністраторів домену.

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

Яка тут найкраща практика? Чи повинні адміністратори мережі постійно входити з правами на всю мережу (або навіть на свій локальний комп'ютер з цього питання)?

Абсолютна найкраща практика - жити користувачем, робочим коренем . Користувач, у якого ви ввійшли в систему, коли ви натискаєте оновити функцію Server Fault кожні 5 хвилин, повинен бути звичайним користувачем. Той, який ви використовуєте для діагностики проблем маршрутизації Exchange, повинен бути адміністратором. Домогтися цього розділення може бути важко, оскільки в Windows, щонайменше, потрібні подвійні сеанси входу, і це означає, що в деякому роді два комп'ютери.

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

Чому це найкраща практика? Частково це тому , що я так сказав , і так багато інших. SysAdminning не має центрального органу, який би встановлював кращі практики будь-яким остаточним способом. В останнє десятиліття у нас було опубліковано кілька найкращих практик ІТ-безпеки, які дозволяють використовувати, коли ви користуєтесь підвищеними приватними особами лише тоді, коли вам це потрібно. деякі найкращі практики встановлюються на основі гештальту досвіду систематиків протягом останніх 40 років. Документ з LISA 1993 ( посилання ), приклад статті від SANS ( посилання , PDF), розділ із «критичних засобів безпеки ДАНС» стосується цього ( посилання ).

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

Моя практика полягає в тому, щоб створити обліковий запис домену та надати йому права адміністратора на всіх робочих станціях (ПК-адміністратор) та окремий обліковий запис домену для роботи адміністратора сервера (сервер-адміністратор). Якщо ви стурбовані тим, що ваші сервери зможуть спілкуватися один з одним, ви можете мати окремі облікові записи для кожної машини (<x> -admin, <y> -admin). Однозначно спробуйте використовувати інший обліковий запис для запуску завдань адміністратора домену.

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

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

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

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

Думки дещо відрізняються між Windows та * nix, але ваша згадка про адміністраторів домену змушує мене думати, що ви говорите про Windows, тому це контекст, в якому я відповідаю.

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

На сервері це тема багато дискусій. Моя власна думка полягає в тому, що я входжу на сервер лише для того, щоб виконувати роботу адміністратора, тому просто не має сенсу входити як користувач, а потім запускати кожен окремий інструмент за допомогою run-as, що, відверто кажучи, завжди було справжнім болем що ви знаєте, що і для більшості робочих місць це просто робить життя адміністратора надмірно складним та трудомістким. Оскільки більшість адміністраторів Windows виконується за допомогою інструментів GUI, існує певна ступінь безпеки, яка не існує, скажімо, адміністратор Linux, що працює в командному рядку, де звичайний друкарський помилок може надіслати його снуванням за минулу ніч резервної стрічки.

моє життя просте ... аккаунт виразно названий, і всі мають різні паролі.

God account - адміністратор домену, щоб виконувати всі роботи на сервері

напівбожний акаунт для управління ПК - не має прав на спільні користування / сервери - лише на ПК

немічний користувач - я надаю себе власному користувачеві на своєму ПК, але я навіть не маю цих прав на інших ПК

причин розлуки багато. аргументу не повинно бути, просто зробіть це!

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

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