Должен ли dev быть администратором на своем компьютере? [закрыто]

Должны ли разработчики в корпоративной среде иметь права администратора на своем компьютере? Зачем?

Технологическая среда:

• Windows 7
• Visual Studio 2008 & 2010
• SQL Server

Должны ли они? Это зависит от корпорации. Лично я думаю, что это нормально, если есть некоторые понятные правила.

1. Быть администратором на вашем ящике - это привилегия, а НЕ право.
   2. Ловля вирусов в нескольких случаях будет отменена
   3. Отключение корпоративных агентов приведет к отмене прав - AV / инвентаризация / развертывание программного обеспечения / и т. Д.
   4. В основном, если вы делаете что-то, что рискует, сеть будет отозвана
2. Любые инструменты, которые вы устанавливаете, не должны становиться зависимыми от вашего проекта без их включения в официально утвержденный список. Будьте добры, не срывайтесь в день развертывания и требуйте установки $ random_library на все серверы без тестирования
3. Для чего-либо за пределами обычных приложений, установленных везде, поддержка будет наилучшим усилием. Служба поддержки и / или системные администраторы не будут тратить 5 часов, пытаясь отладить причины конфликтов с DLL.

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

В развитии есть и наука, и искусство; это не так просто, как «знать», что нам нужно. Если у нас уже был ответ половину наша работа будет спорно; Поиск правильного подхода часто повторяется и может включать в себя несколько инструментов непредсказуемым образом. Требовать посредника для установки каждого из них (часто с высокой задержкой) только для того, чтобы найти (около часа в), что для вашего сценария необходим «аддон сверхабонентского инструмента», глупо.

Хотя виртуальная машина идеально подходит для этого, есть также много инструментов разработки, которые не могут работать (должным образом или даже вообще) в виртуальной машине, потому что они сами являются виртуальными машинами - и я не имею в виду такие вещи, как JVM; Я имею в виду полную машину emus / vms, например, наборы инструментов для устройства. Совместимость там улучшается.

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

Производительность огромна здесь; Как вы думаете, было ли нормально, чтобы пользователи ждали 3 секунды после каждого нажатия клавиши в Word для регистрации своего ключа? Я не шучу - инструменты разработки на виртуальных машинах и т. Д. Могут быть такими отстойными; для большинства целей разработки вам нужна отзывчивость. Прерывание потока сложной логики от мозга к клавиатуре может сделать практически невозможным выполнение работы. И я ненавижу это говорить, но да: время разработки стоит дорого.

В среде Windows, и особенно при использовании продуктов Microsoft для разработчиков, разработчику потребуются права администратора на их компьютере. Если вы лишите их этих прав, их способность выполнять свою работу будет ограничена, если не будет полностью запрещена.

Будучи разработчиком, я ставлю нас на уровень привилегий выше базового пользователя, но ниже системного администратора (ов).

Иногда мне может понадобиться установить дополнительную библиотеку для того, чтобы приложение, которое я разрабатываю, работало в производственной среде. При этом у меня есть строгое правило, которое я разработал: «Для любого приложения, для которого требуются сторонние библиотеки, библиотеки должны быть установлены в среде «песочницы» перед производственным развертыванием и, в некоторых случаях, перед разработкой приложения ».

Системный администратор, с которым я работаю, и я согласен с этим, и между нами мы будем активно применять это правило и откладывать любое развертывание приложения, которое не прошло «проверку зависимостей».

Чтобы ответить на ваш вопрос, да, разработчикам должен быть предоставлен полный доступ к их собственным машинам, но эти машины должны быть изолированы от среды, в которой в конечном итоге будет развернуто приложение. В этом случае даже развертывание приложения следует помещать в «песочницу» до тех пор, пока оно не будет сочтено безопасным для развертывания в производственной среде.

Отказ от ответственности: я разработчик.

Мне кажется, что этот вопрос (и ответы), кажется, атакуют проблему из-за неправильного подхода - то есть дискуссия сосредоточена на том, что администраторы хотят / нуждаются против того, что разработчики хотят / нуждаются. Но вы указали, что мы находимся в корпоративной среде, так что давайте посмотрим на это так.

Итак, давайте представим, что мы спорим об этом перед директором по ИТ или операциям, или кем бы ни контролировал наш бюджет , и задаем эти вопросы.

1. Какая минимальная привилегия требуется для выполнения функций отдела? Это наша базовая линия.
2. Каковы риски предоставления им большего доступа? (реальные риски, а не только лучшие / худшие сценарии)
3. Какова истинная ожидаемая стоимость предоставления им большего доступа? (расходы на поддержку, исправление непреднамеренных изменений, сделанных неопытным администратором и т. д.)
4. Какова истинная ожидаемая стоимость не предоставляя им больше доступа? (потеря производительности, потребность в ИТ-поддержке для выполнения повседневных задач, текучесть кадров из-за морального состояния и т. д.)

Ответив на эти вопросы, вы можете принять обоснованное решение, а не страстное.

Для вашей конкретной среды есть некоторые вещи, которые требуют прав администратора (см. Права пользователя и Visual Studio ) - если они этого не делают, тогда вы можете ответить на вопросы 2 - 4.

Как консультант, я видел обе крайности этой политики, и, хотя я всегда хочу иметь административный доступ к машине, в некоторых случаях это не имело смысла. И я не уверен, что является причиной и что является следствием, но без исключения все места, где я видел разработку Windows, где разработчики имели доступ администратора, также имели НАМНОГО более высокую производительность от каждого разработчика, чем места, где они были заблокированы.

Я думаю, что вы задаете неправильный вопрос, вы должны спросить:

Будет ли хороший разработчик работать для работодателя, который не дает ему / ей права администратора на их ПК?

То, что кому-то «нужно» и чего они ожидают, часто не одно и то же, ведь вам не нужно позволять разработчику пить кофе в рабочее время, но если вы этого не сделаете…

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

На самом деле это зависит больше от того, кого вы спрашиваете о том, кому это действительно нужно. Если вы спросите корпоративные ИТ-группы и группы по управлению рисками, они будут окружать вас ужасными историями (и если они хотят дать вам это, они потребуют козла, принесенного в жертву в священном обещании, что они не будут нести ответственность), разработчики с другой стороны, требуются права администратора главным образом потому, что работа достаточно напряженная и требует усилий, не требуя разрешения справочной службы, чтобы уйти от утечки. Печальное положение вещей таково, что теперь речь идет больше о борьбе за власть и использовании власти, чем о потребностях бизнеса и производительности (например, все сводится к тому, кто заставит другого прыгнуть через обручи).

ИМХО, лучшая рабочая среда, которую я видел по сей день, - это то, где две группы держатся отдельно. Разработчики имеют свой собственный домен в лесу (посредством которого ИТ контролирует, что этот домен и его пользователи могут делать в остальной части компании), и все они являются локальными администраторами с опытными парнями с MCSE, выступающими в роли администраторов локальных доменов, у них есть собственная тестовая среда и может делать практически все, что им нужно и в их локальной сети, с помощью единой политики ИТ (без пиратского программного обеспечения). Корпоративные ИТ не несут ответственности и не оказывают поддержку разработчиков и только усиливают некоторые корпоративные правила высокого уровня (не facebook, порно или подобное через брандмауэр, УБСА не позволяют связываться с корпоративной локальной сетью), и все они имеют виртуальные частные сети на основе RSA для работы из дома который помещает их прямо в их локальной сети. Аккуратно, не правда ли?

Ответ, вероятно, будет субъективным и конкретным для каждого отдельного сценария, но в большинстве случаев я бы сказал, да.

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

Все идет не так, и вы можете стереть и восстановить в считанные минуты.

Определенно! Обычно большая часть разработки может происходить или не происходить в виртуальной среде. Права администратора помогают преодолеть множество переопределений обработки служб, записей реестра и IIS локально. С другой стороны, это зависит от того, насколько вы доверяете своим разработчикам.

Как разработчик, разочаровывает, когда что-то не работает, потому что у нас нет доступа.

Зависит. Как разработчик, всегда следует действовать по принципу наименьших привилегий. Если вы работаете в качестве государственного подрядчика, вы, возможно, по контракту обязаны не иметь доступа администратора, например.

Как Java-разработчик, у меня почти не было необходимости иметь права администратора на моей машине на постоянной основе . Тем не менее, существуют законные случаи, когда вам нужен доступ по требованию администратора (.ie. Вам нужно переместить свой ноутбук через физически отдельные домены, и вам нужно соответственно изменить свой сетевой адаптер.) Это был единственный раз, когда мне действительно нужно было постоянный постоянный доступ администратора к моей машине.

Иногда вам нужен доступ администратора, потому что ИТ недоукомплектованы (или некомпетентны, или погрязли в волоките). Но если вы работаете с компетентным ИТ-отделом, они могут установить его для вас даже удаленно (или предоставив пользовательских установщиков, которые будут «запускаться как» "Администратор и установить материал для вас, просто нажав на них.)

Так что ответ (опять же) - это зависит. Есть ли у вас отзывчивый ИТ-персонал, который может устанавливать вещи по требованию (или в разумные сроки)? Нужно ли это разработчикам для тех задач, за которые им платят ?

Если разработчики действительно и законно нуждаются в этом (как в «Я буквально не смогу ничего сделать без него» ), в отличие от удобства (как в «Я хочу установить все, что я хочу» ), и если ИТ-поддержка недостаточно отзывчив (по каким-либо причинам), тогда да, у них должен быть доступ администратора к своим машинам.

В противном случае нет. Помните принцип наименьших привилегий , люди.

Есть разработчики и есть разработчики. Если «разработчик» - это какой-то Java-парень JBoss за $ 40 / час, пишущий правила для механизма правил, то, конечно, нет. Если «разработчик» - это C / Assembly за $ 350 / час, который заставляет ваше программное обеспечение для редактирования видео работать на GPU с максимальной скоростью, то да, конечно.

Для корпораций, которые беспокоятся о безопасности, они будут заставлять сотрудников безопасности диктовать и пытаться навязать политику, которая работает с их моделью развития и системами. В среде Windows большинство людей скажут вам, что для выполнения их задач у вас должны быть права администратора на хосте, на котором они разрабатываются.

Это не обязательно правда...

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

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

Разработчики должны (в идеале) иметь два доменных имени пользователя.

Тот, который имеет права локального администратора (для разработки) и тот, который имеет те же права, что и все остальные в компании. Затем они могут проверить свою работу на репрезентативном наборе разрешений.

Это должно уменьшить вероятность того, что ItWorksOnMyMachine-itis иногда появляется .....

Я должен (явно) предоставить несогласный голос и сказать не только нет, но и черт возьми. У меня нет проблем с предоставлением прав администраторам на изолированную виртуальную машину, которая не имеет доступа к сети. У Зайфера это было почти правильно (исправление выделено жирным шрифтом):

«Быть ​​администратором на моем ящике - это привилегия, а НЕ право». Эти системы являются корпоративными активами, за которые я несу полную ответственность. Когда Джо Разработчик устанавливает свою пиратскую копию Microsoft Боба («потому что мне это было нужно »), ему не придется объяснять, как ее не нашли до аудита. Разработчики обычно думают, что корпоративные правила так или иначе не применяются к ним. Предоставляя им изолированную виртуальную машину, они могут следовать всем правилам, которым должны следовать все остальные (поскольку теперь только ИТ-специалисты могут копировать файлы в систему и из нее). Волшебным образом система запросов снова используется разработчиками, небо больше не падает, когда Джо Разработчик портит свой ящик для разработки - он просто просит новый (или восстановление, если его просят сделать резервные копии)

Г-н Денни упомянул, что разработчики стоят денег, когда им приходится ждать установки приложений, А. привет ... мое время, как правило, столь же ценно, как и Joe Developer (как правило, тем более, поскольку я поддерживаю работающее программное обеспечение - и действительно ли я Я должен упомянуть все время, потраченное на то, чтобы помочь разработчику Джо отладить его последний шедевр), и Б., когда dev перебирает бюджет, потому что они ждали приложения и пытались обвинить в этом ИТ, я бы сказал:

Я не несу ответственности за то, что вы не спланировали то, что вам нужно для написания программного обеспечения, у нас есть стандартный набор инструментов, и если на этом наборе инструментов отсутствует то, что вам нужно, у вас должны были быть просьбы ускорить использование большего количества инструментов, а не пытаться заставить меня прыгнуть. через обручи, чтобы получить его для вас, потому что ваш срок завтра.

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

РЕДАКТИРОВАТЬ: Конечно, вполне возможно, что разработчики, с которыми я сталкивался, необычайно скучны (опрос текущего урожая только 1 слышал о переполнении стека, чтобы дать некоторый уровень эталона). Исходная точка зрения, с которой я начинаю, - «что вам нужно делать, что компания платит за вас». Если вам нужны права администратора, вы их получаете, но не стоит с ними бороться, и если я могу дать вам коробку, которая, честно говоря, мне все равно, что вы с ней делаете, и это работает, тогда мы оба готовы идти вперед.