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

135

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

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

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

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

Крейг Х.Б.
источник
116
Если бы я пришел на работу и обнаружил, что у меня нет прав администратора на мою машину, я не вернусь на следующий день. Сделайте жизнь разработчиков проще, а не сложнее.
Annakata
29
Этот вопрос будет страдать от предвзятости выбора - бывают случаи, когда машины разработчика должны быть заблокированы, но такой ответ никогда не будет одобрен на сайте, предназначенном для разработчиков.
romandas
5
Реже, чем можно подумать. В большинстве случаев основной проблемой являются конфиденциальные данные - например, швейцарские законы о банковской конфиденциальности, как правило, не позволяют разработчикам видеть фактические данные клиентов (сверка счетов остается в качестве упражнения для читателя). В этом случае проблема заключается не в блокировании компьютеров, а в предоставлении дезинфицированных наборов данных для разработки. Большинство других ситуаций являются либо нормативными требованиями (например, работа с секретными данными), либо самообслуживанием CYA.
ConcernedOfTunbridgeWells
12
Интересно, как тот же вопрос развернется на ServerFault ... (@romandas)
Бен Мошер,
4
@BenMosher: вот ваш ответ: serverfault.com/questions/232416/…
kmote

Ответы:

228

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

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

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

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

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

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

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

ConcernedOfTunbridgeWells
источник
3
Есть разница с правами администратора и выполнением всего с правами администратора :) Многим разработчикам, конечно, понадобятся права администратора. Но запускать все в интерактивном режиме с правами администратора в локальной системе - не в последнюю очередь привилегия. Он открывается для атак на производственные системы, к которым у разработчика есть доступ, а взломанный локальный ПК предоставляет любому злоумышленнику такой же доступ. Это проще, чем вы думаете. Безопасность - это послойная проблема, наименьшее количество привилегий для каждого процесса и проблема обучения пользователей. Уважать безопасность каждого устройства - это единственный способ: vimeo.com/155683357
Оскар Дювеборн
Я сторонник предоставления прав локального администратора разработчикам, но высказывание «права администратора на локальном ПК не оказывают существенного влияния на безопасность производственных систем» будет зависеть от вашей среды. Что беспокоит большинство ИТ-специалистов, так это то, что вы будете устанавливать программное обеспечение, содержащее вредоносное ПО / вирус, который может распространяться по всей компании, или если кто-то скомпрометирует ваш локальный компьютер и у вас есть файлы конфиденциальных данных, хранящиеся локально или в локальной базе данных. В идеальном мире ни один разработчик не имеет доступа к файлам данных HIPAA / PCI, и все базы данных dev очищены, но мы знаем, что это не так.
L_7337,
87

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

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

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

Не я
источник
5
Самая большая проблема, с которой я столкнулся с разработчиками с правами администратора, заключается в том, что вы принимаете как должное права, имеющиеся у вас на локальных ресурсах компьютера. Так много дрянного программного обеспечения - запись в C: \ Program Files, запись в HKLM и т. Д. На вашей рабочей станции, возможно, но требуется тестирование там, где вы этого не делаете.
SqlRyan
4
@rwmnau: Это не относится к веб-разработке. Кроме того, проблема становится очевидной довольно быстро, когда QA'ing под обычными разрешениями.
NotMe
2
Обеспечение доступности виртуальных машин и входа в dev-test без прав администратора - хороший способ облегчить тестирование программного обеспечения с обычными правами пользователя.
ConcernedOfTunbridgeWells
Программное обеспечение, которое выпускается с такими правами только для администратора, прошло очень плохой (или ни один) процесс контроля качества. Программное обеспечение должно быть протестировано в реальных условиях, поэтому QA должно поймать его раньше, и проблема, в противном случае упущенная разработчиками, будет исправлена. Правильно?
2
@ rwmnau - Любой разработчик, который стоит их соли, прекрасно знает об этом, но ответ не в том, чтобы заблокировать свою машину разработчика. Это предоставить им среду тестирования, в которой они могут развернуть свой проект для удобного решения этих проблем.
Спенсер Рупорт
48

Да и нет.

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

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

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

Тун Крижте
источник
11
Моей жене пришлось спорить о том, что у нее на компьютере нет учетной записи администратора, поэтому она могла сделать так, чтобы пользователи могли делать то, что она могла. Ваша политика абсолютно правильна (и поэтому проголосовала).
Дэвид Торнли
1
Точно, dev должен иметь admin, test и QA должен иметь user.
Доктор Ватсон
Я не могу с тобой согласиться! Доступ администратора удобен для разработки, но у большинства пользователей его нет (если вы разрабатываете корпоративное программное обеспечение ... ИТ-специалисты обычно довольно хорошо блокируют).
Pulsehead
18

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

Ник Ван Брант
источник
15

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

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

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

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

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

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

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

Фортран
источник
10

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

Джейсон
источник
8

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

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

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

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

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

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

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

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


источник
9
Отличная идея ... но большинство компаний даже не дадут вам одну "хорошую" машину, пусть вдвоем.
Мэтью Уайтед
1
Вы можете создать вторую машину в виртуальной машине со «стандартной» сборкой. Это особенно полезно, если сеть разработки разделена на собственный домен. Отдельная производственная виртуальная машина в основном домене предоставляет разработчикам доступ к сетевым ресурсам.
ConcernedOfTunbridgeWells
5

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

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

Эд Гинесс
источник
5

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

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

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

Джон Кромарти
источник
5

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

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

atom255
источник
3

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

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

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

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

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

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

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

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

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

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

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

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

Оскар Дювеборн
источник
2
Вы говорите: не позволяйте им войти в систему как администратор, но дайте им ключи на тот случай, если им нужно сделать что-то, что требует этого. Я читал ту же самую чушь на сайте MS, касающуюся UAC, и она показывает полное отсутствие реального внимания к сотням вещей, которые dev делает за день.
NotMe
2
UAC был введен, чтобы не дать нормальным людям выстрелить себе в ногу. Если разработчик делает это, позор ему. Если он постоянно делает это, ему нужно найти другую работу.
NotMe
Если вы даете им ключи, вы фактически «позволяете» им, нам, входить в систему как администраторы. Просто никогда не стоит делать это для повседневных задач. Почему люди все еще думают, что это нормально или необходимо просто потому, что они гики, программисты или администраторы - вне меня.
Оскар Дюверборн
Если бы вы когда-нибудь увидели, что современный системный администратор делает за день, вы бы поняли, что потребность в административном доступе и вводе альтернативных учетных данных намного выше, чем когда-либо видел хардкорный системный кодер. Они по-прежнему не входят в систему в качестве администраторов для выполнения повседневных задач и работают нормально.
Оскар Дюверборн
Обычно вы не входите в систему как root в систему Unix, даже когда вы управляете ею, так зачем вам это делать в системе Windows, даже если вы разработчик? Это не имеет смысла. Запуск всех случайных приложений, таких как Skype или еще много чего, с высокими системными привилегиями, по меньшей мере, невежественен - ​​вы повышаете только приложения, которым это нужно.
Оскар Дювеборн
3

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

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

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

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

Дейв Шерохман
источник
Я не думаю, что встречал бизнес-приложение, которое не может работать как обычный пользователь последние 5-10 лет. Когда-то я был BOFH, и все пользователи в этом месте были вынуждены запускать все как обычные пользователи, начиная с ~ 2001 года - фактически, никакие права администратора не делегировались, и это работало хорошо и подавляло множество вредоносных программ того времени. Кроме того, в более поздних версиях Windows применяются автоматические прокладки, если такое устаревшее приложение запущено (дурачит его в песочнице), и в моей повседневной работе по разработке это в значительной степени только Visual Studio, которая когда-либо получает повышение, когда мне нужно присоединить другим процессам для отладки.
Оскар Дювеборн
3

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

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

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

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

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

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

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

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


источник
2

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

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

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

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

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

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

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

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

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

вероучение


источник
1

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

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

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

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

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

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

SilverlightFox
источник
0

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

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

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

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

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

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

Robs
источник
0

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

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

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

Майк
источник
-1

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

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

Манрико Корацци
источник
6
Почему вы связываете руки консультанта, а не обычного сотрудника? Разве они оба не выполняют одну и ту же работу? Ожидаете ли вы меньше от консультанта, хотя вы, вероятно, платите за него больше? Это звучит очень глупо. Кроме того, если разработчик не может поддерживать работу своей собственной машины, ему нужна новая работа
NotMe
-1

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

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

Bratch
источник