Достаточно ли локальных прав «Пользователь» или разработчикам нужен локальный администратор или опытный пользователь при кодировании?

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

Требуется ли для VS2010 локальный администратор или локальный опытный пользователь? Как вы работаете без повышенных прав? С какими проблемами вы столкнетесь?

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

Если вам нужны повышенные права на работу, для чего-либо, кроме установки программного обеспечения, вы делаете что-то очень неправильно. Хуже того, если вы работаете как опытный пользователь или отключаете запросы UAC и т. П., Вы игнорируете проблемы, которые влияют на конечных пользователей вашего программного обеспечения, заставляя их работать с теми же привилегиями, что и вы. Это не правильно.

Это правда, независимо от того, на какой операционной системе вы находитесь. Хотя Windows, кажется, единственная, где она появляется.

Чтобы уточнить:

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

Это политический или управленческий вопрос, а не технический.

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

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

Тем не менее, если указанные программы не являются незаконными или морально неприемлемыми, то почему это проблема в первую очередь?

Это зависит от того, что вы ожидаете, что они будут развиваться независимо.

Некоторые вещи, такие как настройка IIS, удаленная отладка, изменение доступа к GAC, безусловно, повлияют на возможность запуска собственного MSI. Если вы ожидаете, что эти ресурсы будут выполнять самостоятельно, я бы не стал делать это без большого тестирования.

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

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

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

Мне нужны права администратора для запуска Apache через порт 80 на моем MacBook для разработки. Кроме того, нет никаких причин, по которым я не мог находиться на заблокированном компьютере без прав администратора. И я мог бы использовать нестандартный порт, если бы мне действительно было нужно. С точки зрения корпоративных ресурсов имеет смысл, чтобы разработчики не были привилегированными пользователями своих машин.

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

Я предпочитаю второе, очевидно, но я вижу мудрость первого.

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

Более того, с ростом UAC все больше и больше приложений теперь можно устанавливать без полномочий администратора. Они не помещают вещи в HKLM, они ничего не касаются в System32, они помещают исполняемый файл куда-нибудь в папку users \ whoever, и это значительно упрощает их удаление, но может не соответствовать исходной точке, которую они устанавливают " бессмысленное программное обеспечение », под которым я предполагаю, что вы имеете в виду игры, музыкальные проигрыватели и т. д.

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

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

Я полагаю, что удаление прав администратора у разработчиков должно сопровождаться назначением одного из системных администраторов для установки программного обеспечения для команды. Если у вас обоих нет прав администратора и вы не можете попросить администратора установить что-то для вас, вы просто беззащитны перед лицом проблем, с которыми вы сталкиваетесь. Это как будто ты запираешь свою офшорную команду в тюрьме.

Это зависит от того, для чего вы пишете программное обеспечение.

Если вашему программному обеспечению не нужно вмешиваться в вашу систему, вам не нужны полномочия администратора.

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

Я видел два подхода к этому. Одним из них было заставить всех работать с ноутбуков, которые они должны были передать администраторам, когда они вернутся домой. Как только администратор получит его, он вставит компакт-диск, который будет перезаписывать компьютер. После того, как это было повторно изображено, это пошло на полку, где это было бы доступно следующему человеку, который нуждался в этом. Просто убедитесь, что все машины одинаковы, так что вы не попадете на тех, кто перебирает их всех в поисках «хорошего».

Другая вещь, которую я видел, это чтобы все загружались с сервера Citrix. У машин вообще нет локального хранилища, они просто загружают стандартный образ из сети и запускаются из него. Это работает лучше, если у вас есть разные «типы» пользователей, которым требуются разные конфигурации (например, у разработчиков пользовательского интерфейса есть образ с Silverlight, у разработчиков WCF есть IIS и SQL Server и т. Д.)

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