it-swarm.com.ru

Если разработчики имеют права администратора на своем ПК

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

Некоторые комментарии:

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

Мы команда из 5 разработчиков и создаем веб-приложения

120
Craig HB

Ответ "Да". Разработчикам нужно будет поиграть с конфигурациями системы, чтобы протестировать элементы, установить программное обеспечение (если не что иное, чтобы протестировать процесс установки того, что они разрабатывают), поковыряться в реестре и запустить программное обеспечение, которое не будет работать должным образом без прав администратора (просто перечислить несколько предметов). Существует множество других задач, неотъемлемых для работы по разработке, для выполнения которых требуются права администратора.

Учитывая, что сотрудники по разработке не обязательно имеют root-доступ к рабочим системам, права администратора на локальном ПК не наносят существенного ущерба безопасности производственных систем. Почти нет законных операционных причин для ограничения доступа администратора к локальным ПК для сотрудников, которым это необходимо для выполнения своей работы.

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

"Мы так мало ценим вашу работу, что готовы значительно скомпрометировать вашу способность выполнять свою работу без веской причины. На самом деле, мы очень рады сделать это, чтобы прикрыть нашу собственную задницу, потворствовать прихотям мелкая бюрократия или потому что мы просто не можем быть обеспокоены. Это просто лучший случай. Худший случай - это то, что мы на самом деле тот тип фанатов контроля, которые рассматривают это как наше право говорить вам, как выполнять свою работу и что вы делаете или не нужно это делать. Делайте то, что вам дают, и будьте благодарны, что у вас вообще есть работа. '

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

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

Следует отметить, что административные привилегии являются гораздо меньшей проблемой для разработки на системах Unix-oid или мэйнфреймах, чем на Windows. На этих платформах пользователь может делать гораздо больше в своем собственном домене без необходимости общесистемных разрешений. Вы, вероятно, по-прежнему будете хотеть доступ root или Sudo для разработчиков, но не имея этого, вы будете гораздо реже под ногами. Такая гибкость является важной, но менее известной причиной продолжающейся популярности операционных систем на основе Unix в школах информатики.

213
ConcernedOfTunbridgeWells

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

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

Тем не менее, они должны быть администратором на своем поле, а не в сети.

82
NotMe

И да и нет.

Да, это экономит много времени, мешая поддержке системы.

Нет, ваши пользователи не имеют его, поэтому не рассчитывайте на это.

Мы разрабатываем с правами администратора и тестировать без. Который работает правильно.

45
Toon Krijthe

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

18
Nick Van Brunt

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

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

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

Это довольно специфичный для Windows ответ. В Linux и других системах Unix-y разработчики могут чаще обходиться только с учетными записями пользователей, часто им не нужна другая учетная запись для тестирования (если у них есть учетная запись, с которой можно работать в Sudo, они знают, когда используют Sudo, но им может понадобиться один с одинаковыми групповыми разрешениями), и он может очень легко нанести невероятный ущерб ОС, поэтому необходима та же ИТ-политика.

13
David Thornley

Да, Half-Life 1 (и всем связанным модам: Counter-Strike, Day of Beat и т.д.) Необходимы права администратора (по крайней мере, для 1-го запуска, я думаю) для правильной работы в Windows NT, 2000, XP и т.д. ,.

И какой разработчик не играет в Counter Strike во время обеда? (вый точно)

10
fortran

Пережив боль от необходимости разработки без прав администратора на машине, мой ответ может быть только да, это важно.

8
Jason

Абсолютно! Как еще установить менеджер загрузок для загрузки фильмов ночью?

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

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

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

7
User

Ответ: у разработчиков должно быть 2 машины!

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

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

7
Nate Dawg

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

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

5
Ed Guiness

Да, но они должны знать об ограничениях, с которыми сталкиваются их пользователи при работе программного обеспечения в более ограниченной среде. Разработчики должны иметь легкий доступ к "типичным" средам с ограниченными ресурсами и разрешениями. В прошлом я включал развертывание сборок на одну из этих "типичных" систем (часто VM на моей собственной рабочей станции) как часть процесса сборки, чтобы я всегда мог быстро понять, как Программное обеспечение работало на компьютере конечного пользователя.

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

"Это работает на моей машине" никогда не является оправданием!

5
John Cromartie

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

Кроме того, желательно иметь [чистую] систему или виртуальную машину (-и), чтобы вы могли правильно протестировать ее и не попасть в сценарий "все в моей системе работает/работает нормально" из-за подстройки системы.

5
atom255

[извинения, английский не мой родной язык, стараюсь изо всех сил :)] Ну,

Личный опыт (я разработчик c ++/SQL):

Раньше я был администратором моей машины Windows на моей предыдущей работе. У меня также были права dbo (не dba) на базы данных, включая базы данных производственной среды. Через 2 с половиной года с 8 людьми, имеющими эти безумные высокие права ... у нас никогда не было никаких проблем. На самом деле мы решили много проблем, обновив db вручную. Мы могли бы сделать много вещей очень быстро для исправлений и разработчиков.

Теперь я сменил работу. Мне удалось (много плакать) быть администратором моей машины Windows. Но сервер dev - это сервер Red Hat, к которому мы подключаемся с помощью ssh. Попытка установить Qt была пыткой, ограничением квоты, ограничением пространства, выполнением и правами на запись. Мы наконец сдались и попросили админа сделать это за нас. Через 2 недели все еще ничего не установлено. Я очень быстро читаю газеты и нажимаю alt + tab.

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

-> Ответ: "Если существуют процессы, то вы не должны делать то, что хотите. Он должен нормально работать один раз в программе".

-> Попытка объяснить нетехническому менеджеру: "У меня не будет никаких прав администратора в рабочей среде или в среде UAT. Но моя машина разработки отличается. Если бы я собирал стулья вместо программного обеспечения, вы бы сказали мне, что я могу я не могу использовать инструменты, которые мне нужны, потому что моя мастерская должна выглядеть как место, где будет использоваться кресло? Я даю исполняемый пакет uat. Библиотеки и инструменты, которые я использовал для их сборки, невидимы для конечного пользователя или чувак, устанавливающий пакет. "

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

3
user2346536

Нет опытного пользователя

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

Войдите в систему в интерактивном режиме как обычный пользователь

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

Вы серьезно не хотите запускать [вставьте любой браузер, плагин, IM, почтовый клиент и т.д.] В качестве администратора.

Обычно вы также не входите в систему Linux с правами root, даже если у вас есть доступ с правами root, когда вам это нужно.

Используйте отдельную личную учетную запись администратора

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

Используйте "Запуск от имени" и в Vista + UAC для запроса или запроса запроса и введите учетные данные администратора для задач и процессов только при необходимости. PKI со смарт-картами или аналогичными устройствами может значительно снизить нагрузку при вводе учетных данных.

Все счастливы (или?;)

Затем проведите аудит доступа. Таким образом, есть прослеживаемость и простой способ выяснить, кто использует сеансы служб терминалов на конкретном сервере dev/test, к которому вы должны получить доступ прямо сейчас ...

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

3
Oskar Duveborn

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

Я не уверен, каким будет эквивалентное расположение Windows, но, по моему опыту, это идеальная установка:

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

  • С другой стороны, программное обеспечение Windows имеет долгую и долгую историю, предполагая, что все пользователи имеют права администратора, и многие программы не будут запускаться для пользователя без прав администратора. Многие из проблем безопасности Windows напрямую связаны с этим неявным требованием, что для того, чтобы иметь возможность надежно использовать компьютер, все пользователи должны быть администраторами. это должно измениться и самый эффективный способ гарантировать, что ваше программное обеспечение будет работать для пользователей без прав администратора, - это чтобы ваши разработчики запускали его сами как пользователи без прав администратора.

3
Dave Sherohman

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

По моему опыту, компромисс между нами (программистами) и ними (безопасность) всегда необходим. Я признаю (хотя я ненавижу), есть заслуга в статье Microsoft выше. Поскольку я был программистом в течение многих лет, я испытал боль, когда мне нужно было просто установить другой отладчик, просто чтобы раздражаться, я не могу. Это заставило меня задуматься о том, как выполнить свою работу. После многих лет борьбы с нашей командой безопасности (и нескольких дискуссий) я понимаю, что им нужно защищать все области, включая мой рабочий стол. Они показали мне ежедневные уязвимости, которые появляются даже в самом простом приложении Quicktime. Я вижу их разочарование каждый раз, когда я хочу установить быструю утилиту или настроить мою локальную IIS, что я могу вызвать серьезную проблему безопасности. Я не до конца понимал это, пока не увидел, как другой разработчик получил консервы. Он пытался отлаживать и в итоге отключил Symantec только для того, чтобы донести (а затем и подарить) какой-нибудь вирус сотням людей. Это был беспорядок. Разговаривая с одним из "секретарей" (охранников) о том, что произошло, я увидел, что он просто хотел сказать: "Я тебе так сказал ...".

Я узнал, что наши главы (ну, по крайней мере, мои) просто хотят защитить нашу компанию. Хорошая новость заключается в том, что мы нашли компромисс, и я могу выполнить свою работу, а секреты в нашей защищенной сети классные!

Вероучение

2
Creed

Вы можете ответить на это двумя способами. Да и нет, или это зависит. - Могу ли я быть более расплывчатым ....

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

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

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

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

2
Mark

Вау, этот вопрос, безусловно, откроет некоторые интересные ответы. В ответ я цитирую часто используемое слово - "Это зависит" :)

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

Лично я фанат "учетной записи администратора", которую можно использовать при необходимости, то есть "Запуск от имени" (я заметил, что этот подход в принципе был очень похож на UAC позже).

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

Сказав это, если у вас хорошая тестовая лаборатория и/или приличная команда QA, это может быть спорным вопросом, особенно если у вас есть приличная практика ALM.

Итак, наконец - я развиваюсь без UAC, главным образом потому, что доверяю себе и своим навыкам. В командной среде я бы поставил это на голосование. В более крупных организациях у вас может не быть этой свободы. Администраторы предприятия часто имеют последнее слово :)

0
RobS

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

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

Кстати, у меня было больше проблем с боссом, который возился с вещами, чем с кем-либо еще. Вроде как старый вопрос: "Где сидит слон? Где угодно!" Но в небольшой фирме, где он по сути является "резервным" системным администратором, выбора не так много.

0
Mike