Чи достатньо місцевих прав "Користувач" чи розробникам потрібен місцевий адміністратор або користувач Power Power під час кодування?

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

Чи вимога до місцевого адміністратора чи місцевого споживача живлення з VS2010? Як ти біжиш без підвищених прав? З якими питаннями ви зіткнетесь?

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

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

Це вірно, незалежно від операційної системи, на якій ви працюєте. Хоча Windows, здається, є єдиним, де воно з'являється.

Для уточнення:

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

Це політичне чи управлінське питання, а не технічне.

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

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

Однак, якщо зазначені програми є незаконними або морально неприйнятними, то чому це питання в першу чергу?

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

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

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

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

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

Мені потрібні права адміністратора, щоб запустити Apache на порт 80 в моєму MacBook розвитку. Крім цього, немає жодної причини, щоб я не міг бути на заблокованій машині без прав адміністратора. І я міг би використовувати нестандартний порт, якщо мені це справді потрібно. З точки зору ресурсів підприємства, має сенс розробники не бути привілейованими користувачами своїх машин.

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

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

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

Більше того, із зростанням UAC все більше та більше програм тепер можуть встановлюватись без адміністраторських повноважень. Вони не ставлять речі в HKLM, вони нічого не торкаються під System32, вони кладуть exe кудись під папку користувачів \ хто б не робив, і це значно полегшує їх видалення, але, можливо, не звертається до вашого початкового пункту, який вони встановлюють " нісенітниця програмного забезпечення ", під яким я вважаю, ви маєте на увазі ігри, музичні плеєри тощо.

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

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

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

Це залежить від того, для чого ви пишете програмне забезпечення.

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

Краще рішення: для встановлення / тестування можливо використовувати VM або тестові лабораторні комп'ютери.

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

Інше, що я бачив - це всі завантажуватися з сервера Citrix. Машини взагалі не мають локального сховища, вони просто завантажують стандартне зображення з мережі і запускаються з цього. Це краще працює, якщо у вас є різні "типи" користувачів, яким потрібні різні конфігурації (наприклад, розробники інтерфейсу мають зображення із Silverlight, розробники WCF мають IIS та SQL Server тощо)

Але, маючи на увазі все, я думаю, що Thorbjorn [sic] вдарив цвяхом по голові: це питання управління, і, ймовірно, не буде належним чином вирішено технічне рішення.