Чи повинен dev бути адміністратором на своєму комп’ютері? [зачинено]

Чи повинні у корпоративних умовах розробники мати права адміністратора на своєму комп’ютері? Чому?

Технологічне середовище:

• Windows 7
• Visual Studio 2008 та 2010 років
• SQL Server

Чи повинні вони? Це залежить від корпорації. Особисто я думаю, що це добре , якщо є деякі зрозумілі правила.

1. Бути адміністратором у своїй коробці - це привілей НЕ право.
   2. Кілька разів лову вірусів буде відкликано право
   3. Відключення корпоративних агентів буде відкликано право - AV / інвентар / розгортання програмного забезпечення / тощо
   4. В основному, якщо ви робите щось, що ризикує, мережа позбавиться права
2. Будь-які інструменти, які ви встановлюєте, не повинні бути залежними від вашого проекту, не потрапляючи в офіційно затверджений список. Попросіть красиво не врізатися в день розгортання і вимагайте встановити $ random_library на всіх серверах без тестування
3. Для нічого, крім звичайних додатків, встановлених скрізь, підтримка буде найкращим зусиллям. Служба підтримки та / або sysadmins не витратять 5 годин на те, щоб налагодити причину конфліктів у dll.

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

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

Незважаючи на те, що VM ідеально підходить для цього, є також багато інструментів розробки, які не можуть запустити (належним чином, або навіть взагалі) в VM, тому що вони самі є ВМ - і я не маю на увазі такі речі, як JVM; Я маю на увазі повну машину emus / vms, наприклад набори інструментів. Сумісність там поліпшується.

Крім того, більшість інструментів розробки мають дуже великий слід - набагато більший, ніж "звичайні" інструменти (що робить VM-хостинг трохи болючішим, ніж ви могли очікувати), і часто за своєю природою відладчик процесу вимагає підвищеного доступу. Не кажучи вже про те, що вони можуть бути інтенсивними в GUI; намагатися запустити повний робочий день на графічному інтерфейсі VM - це надзвичайно боляче.

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

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

Будучи розробником, я класифікую нас за рівнем привілеїв вище основного користувача, але нижче системного адміністратора.

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

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

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

Відмова: Я розробник.

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

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

1. Який мінімальний привілей необхідний для виконання функцій відділу? Це наш базовий рівень.
2. Які ризики надати їм більший доступ? (фактичні ризики, а не лише найкращі та гірші сценарії)
3. Яка справжня очікувана вартість надання їм більшого доступу? (витрати на підтримку, виправлення ненавмисних змін, внесених недосвідченим адміністратором тощо)
4. Яка справжня очікувана вартість не надавати їм більше доступу? (втрачається продуктивність, потребує ІТ-підтримки для виконання щоденних завдань, обороту досвідчених людей через моральний стан тощо)

З відповіддю на ці запитання ви можете приймати зважене рішення, а не пристрасне.

У вашому конкретному середовищі є деякі речі, які потребують прав адміністратора (див. Права користувачів та Visual Studio ) - якщо вони цим не займаються, то ви можете відповісти на питання 2 - 4.

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

Я думаю, ви задаєте неправильне запитання, вам слід задати:

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

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

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

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

ІМХО, найкраще робоче середовище, що я бачив до цього часу, - це коли дві групи тримаються відокремленими. Розробники мають власний домен у лісі (завдяки якому ІТ контролює, що цей домен та його користувачі можуть робити в решті компанії), і всі вони місцеві адміністратори з досвідченими хлопцями з MCSE, які виступають адміністраторами локальних доменів, у них є власне тестове середовище і можуть робити все, що хочуть і потребують у своїй локальній локальній мережі, використовуючи єдину ІТ-політику (без піратського програмного забезпечення). Корпоративний ІТ не несе відповідальності і не надає підтримку розробникам і лише застосовує деякі корпоративні правила високого рівня (без фейсбуку, порно чи подібного через брандмауер; розробки не дозволяють возитися з корпоративною локальною мережею), і всі вони мають VPN, засновані на RSA, для роботи з дому який розміщує їх безпосередньо у своїй локальній мережі. Акуратно, чи не так?

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

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

Що-небудь піде не так, і ви можете витерти та відновити за лічені хвилини.

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

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

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

Як розробник Java я навряд чи потребував постійних прав адміністратора на своїй машині . Однак є обґрунтовані випадки, коли вам потрібен доступ адміністратора за запитом (тобто. Вам потрібно переміщати свій ноутбук через фізично окремі домени, і вам потрібно відповідно змінити свій NIC.) Це був єдиний раз, коли мені це було дійсно потрібно постійний постійний доступ адміністратора до моєї машини.

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

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

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

Інакше ні. Пам’ятайте про принцип найменшої пільги , люди.

Є розробники і є розробники. Якщо "розробник" коштує близько $ 40 / годину, JBoss хлопець Java пише правила для двигуна правил, то, звичайно, ні. Якщо "розробник" - це $ 350 / годину, C / Assembly хлопець змушує програмне забезпечення для редагування відео працювати якомога швидше на графічному процесорі, то так, звичайно.

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

Це не обов'язково вірно ...

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

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

Розробники повинні (в ідеалі) мати два входи в домен.

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

Потім це повинно зменшити ймовірність появи ItWorksOnMyMachine-itis, що виникає зрідка .....

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

"1.Переведення адміністратора в мій ящик - це привілей НЕ право." Ці системи є корпоративним активом, за який я зрештою несу відповідальність. Коли Joe Developer встановлює свою піратську копію Microsoft Bob ("тому що мені це потрібно "), йому не доведеться пояснювати, як її не було знайдено до аудиту. Розробники звичайно думають, що певні корпоративні правила просто не стосуються їх. Даючи їм VM з пісочним кодом, вони можуть дотримуватися всіх правил, яким повинні дотримуватися всі інші (оскільки тепер тільки ІТ може копіювати файли в систему та з неї). Магічно система запитів знову використовується розробниками, небо більше не падає, коли Joe Developer маніпулює своїм вікном розробки - він просто просить новий (або відновити, якщо він попросить резервного копіювання)

Містер Денні згадав розробників, які коштують грошей, коли їм доведеться чекати встановлення додатків, А. привіт ... мій час, як правило, такий же цінний, як і Joe Developer (як правило, тим більше, що я продовжую працювати існуючі crapware - і чи дійсно я доведеться згадати весь час, витрачений на допомогу розробнику Джо налагодження його останнього шедевра), і Б., коли Dev перестає надбудувати, тому що вони чекали програми та намагаються звинуватити в цьому ІТ, я б сказав:

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

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

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