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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да и нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кроме того, желательно иметь [чистую] систему или ВМ, чтобы можно было правильно протестировать ее и не попасть в сценарий «все в моей системе работает / работает нормально» из-за настройки системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

вероучение

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

т.е. компрометация низкоуровневой учетной записи> Найти где admin -> Mimikatz -> Поднять права -> Администратор домена.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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