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

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

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

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

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

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

Да и нет.

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

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

Мы разрабатываем с разрешениями администратора и без тестов. Что работает правильно.

Ответ 4

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

Ответ 5

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

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

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

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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

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

Ответ 9

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

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

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

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

Ответ 10

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

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

Ответ 11

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

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

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

Ответ 12

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

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

Ответ 13

Нет источника питания

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

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

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

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

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

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

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

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

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

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

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

Ответ 14

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

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

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

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

Ответ 15

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

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

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

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

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

- > Ответ: "Если есть процессы, для вас не делать то, что вы хотите. Он должен работать отлично в prod".

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

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

Ответ 16

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

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

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

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

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

Ответ 17

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

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

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

Крид

Ответ 18

Да, если вы хотите, чтобы пентестеры или некоторые опытные злонамеренные пользователи закрепились на компрометации вашего домена.

i.e Компрометировать низкоуровневую учетную запись> Найти где admin → Mimikatz → Поднять права → Администратор домена.

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

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

Если им нужен администратор как часть их рабочей роли, то выдают отдельные учетные записи локального администратора домена, используемые только для установки программного обеспечения (с правами администратора только на их собственной машине), но не для общего пользования или доступа в Интернет. Это должно иметь более строгую политику паролей (например, минимальная длина 15 символов). Для этого следует использовать функциональность Runas.

Любая среда, в которой обычные пользовательские учетные записи имеют права администратора, является рецептом для катастрофы безопасности.

Ответ 19

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

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

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

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

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

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

Ответ 20

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

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

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

Ответ 21

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

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

Ответ 22

Никто из Windows XP не должен использовать учетную запись администратора для повседневного использования, а в Vista, если вы должны быть администратором, по крайней мере, имеет UAC. Особенно веб-разработчики и другие разработчики, которые просматривают Интернет с помощью Internet Explorer.

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