Якщо розробники мають права адміністратора на своєму ПК

Чи повинні розробники мати адміністраторські дозволи на своєму ПК чи надавати їм доступ користувача живлення?

Деякі коментарі:

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

Ми команда з 5 розробників і створюємо веб-додатки

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

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

Однак найважливішою причиною надання адміністративного доступу є те, що створення компрометованого середовища або середовища розробки другого рівня надсилає повідомлення вашому персоналу розвитку:

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

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

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

Слід зазначити, що адміністративні привілеї набагато менше проблем для розробки в системах unix-oid або mainframe, ніж у Windows. На цих платформах користувач може зробити набагато більше у власному домені, не потребуючи загальносистемних дозволів. Ви, ймовірно, все ще хочете отримати доступ до root або sudo для розробників, але не матимете це набагато рідше. Ця гнучкість є важливою, але менш відомою причиною постійної популярності операційних систем Unix, отриманих у школах інформатики.

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

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

Це означає, що вони повинні бути адміністратором у їхньому вікні, а не в мережі.

Так і ні.

Так, це економить багато часу, що турбує підтримку системи.

Ні, у ваших користувачів цього немає, тому на нього не розраховуйте.

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

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

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

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

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

Це досить відповідь для Windows. В Linux та інших системах Unix-y розробники можуть частіше обходитися лише обліковими записами користувачів, часто для тестування їм не потрібен інший обліковий запис (якщо у них є акаунт, з яким вони можуть судоступити, вони знають, коли вони використовують sudo, але їм може знадобитися одне і те ж груповий дозвіл), і вони можуть легко нанести неймовірні пошкодження ОС, тому необхідна та сама політика ІТ.

Так, Half-Life 1 (і всі пов'язані з ними моди: контр-страйк, день поразки тощо) потребують прав адміністратора (принаймні для першого запуску, я думаю) для належної роботи в Windows NT, 2000, XP тощо .

І який розробник не грає Counter Strike в обідній час? (напевно, точно)

Витримавши біль від необхідності розвиватися без прав адміністратора на машині, моя відповідь може бути лише так, це дуже важливо.

Абсолютно! Як інакше встановити менеджер завантажень, щоб завантажувати фільми вночі?

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

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

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

Відповідь, розробники повинні мати 2 машини !!

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

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

Якщо ви інвертуєте питання, я думаю, що відповісти стає простіше; чи слід видаляти дозволи розробників у розробників? Що таке виграш?

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

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

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

"Це працює на моїй машині" - це ніколи не привід!

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

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

Немає споживача живлення

Перш за все, Power User в основному є адміністратором, тому " обмеження " користувача Power User не забезпечує підвищення безпеки в системі - ви також можете бути адміністратором.

Увійдіть інтерактивно, як звичайний користувач

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

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

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

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

Надайте розробнику окремий особистий обліковий запис адміністратора на свою машину (бажано, обліковий запис домену), який також є дійсним адміністратором на інших серверах розробки / тестування та полях, до яких людині потрібен адміністративний доступ.

Використовуйте функцію "запустити як" і в Vista + UAC, щоб запросити або запросити запит і ввести адміністративні дані для завдань і процесів лише за потреби. PKI зі смарт-картами чи подібними може значно зменшити напругу в частому введенні облікових даних.

Усі раді (або?;)

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

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

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

Я не впевнений, якою була б еквівалентна система Windows, але, на мій досвід, це ідеальне налаштування:

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

• З іншого боку, програмне забезпечення Windows має довгу і довгу історію припущення, що всі користувачі мають права адміністратора, до того, що багато програм не працюватимуть для користувачів, які не є адміністратором. Багато питань безпеки Windows випливають безпосередньо з цієї неявної вимоги, що для надійного використання комп’ютера всі користувачі повинні бути адміністраторами. Це повинно змінитись, і найефективніший спосіб забезпечити, що ваше програмне забезпечення буде працювати для користувачів, які не є адміністраторами, це те, що ваші розробники запускатимуть його як не-адміністратори.

[Вибачення англійська - це не моя рідна мова, я роблю все можливе :)]

Особистий досвід (я c ++ / SQL розробник):

Раніше я був адміністратором своєї машини Windows на своїй попередній роботі. Я також мав права на dbo (не dba) на бази даних, включаючи бази даних виробничого середовища. За два з половиною року, коли 8 людей мали ці шалено високі права ... у нас ніколи не було проблем. Насправді ми вирішили багато проблем, оновивши db вручну. Ми могли б зробити дуже багато справ дуже швидких для гарячих виправлень та розробок.

Тепер я змінив роботу. Мені вдалося (багато плакала) бути адміністратором своєї машини Windows. Але сервер dev - це сервер червоного капелюха, до якого ми підключаємось за допомогою ssh. Спроба встановити Qt була тортурами, обмеження квоти, обмеження місця, права на виконання та запис. Ми нарешті здалися і попросили адміністратора зробити це за нас. Через 2 тижні все одно нічого не встановлено. Я дуже швидко переглядаю газету та натискання клавіш Alt +.

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

-> Відповідь: "Якщо у вас є процеси, ви не будете робити все, що завгодно. Він повинен працювати добре один раз у продажі".

-> Намагаючись пояснити не технічному менеджеру: "У мене не буде жодних прав адміністратора у виробництві чи середовищі UAT. Але моя машина для розробників інша. Якби я будував стільці замість програмного забезпечення, ти скажи мені, що я можу "Я не розміщую будь-які інструменти, які я хочу в своїй майстерні, тому що моя майстерня повинна мати вигляд місця, де буде використовуватися стілець? Я дарую виконуючий пакунок uat. Кільця та інструменти, які я використовував для їх побудови, невидимі для кінцевого користувача або для чувак встановлює пакет ".

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

На це можна відповісти двома способами. Так і ні, або це залежить. - Чи можу я бути більш невиразним….

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

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

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

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

ht tp: //msdn.microsoft.com/en-us/library/aa302367.aspx

На мій досвід, завжди потрібен компроміс між нами (кодерами) та ними (безпека). Я визнаю (хоча я ненавиджу), але в цій статті є заслуга. Оскільки я був програмістом протягом багатьох років, я відчув біль, де мені потрібно було просто встановити інший налагоджувач, тільки щоб роздратуватися, я не можу. Це змусило мене творчо задуматися над тим, як зробити свою роботу. Після багатьох років боротьби з нашою командою з безпеки (і декількома дискусіями) я розумію їхню роботу - забезпечити безпеку всіх областей, включаючи мій робочий стіл. Вони показали мені щоденні вразливості, які з'являються, навіть у найпростішому додатку Quicktime. Я бачу їх розмивання щоразу, коли хочу встановити швидку утиліту або налаштувати свій локальний IIS, що я можу викликати серйозну проблему безпеки. Я не повністю зрозумів це, поки не побачив, як інший розробник отримує консерви. Він намагався налагодити помилку, і в кінцевому підсумку вимкнув Symantec лише для того, щоб дістати (а потім ДАВАТИ) якийсь вірус сотні людей. Це був безлад. Розмовляючи з одним із "секеїв" (хлопців із безпеки) про те, що сталося, я міг бачити, що він хотів просто сказати: "сказав вам так ...".

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

Символ віри

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

тобто Компромісний обліковий запис низького рівня> Знайдіть, де адміністратор -> Mimikatz -> Підвищити дозволи -> Адміністратор домену.

Тож ні, нормальні користувачі не повинні бути адміністраторами.

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

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

Будь-яке середовище, де нормальні облікові записи користувачів є адміністратором, є рецептом катастрофи безпеки.

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

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

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

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

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

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

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

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

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

Це залежить від навичок розробника та того, чи він / він консультант чи ні.

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

Ніхто в Windows XP не повинен використовувати обліковий запис адміністратора для щоденного використання, а у Vista, якщо ви повинні бути адміністратором, принаймні увімкнено UAC. Особливо веб-розробники та інші розробники, які переглядають Інтернет за допомогою Internet Explorer.

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