Разрешения Windows для разработчиков?

Я работаю в компании Fortune 500 в качестве разработчика программного обеспечения для Windows в области исследований и разработок. Корпоративные ИТ в настоящее время готовятся к развертыванию Win7 в масштабах всей компании, и, как часть этого, они стремятся полностью заблокировать права администратора на всех компьютерах (включая наши рабочие станции для разработчиков).

Мне было поручено работать с ними, чтобы сделать переход максимально плавным. Повезло мне

Я хотел бы знать, есть ли какие-либо опубликованные или другие уважаемые ресурсы, которые я могу использовать для:

1. выяснить, где провести линию на песке
2. поддержи мою позицию.

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

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

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

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

Поскольку вы переходите конкретно на Windows 7, вам следует приложить все усилия, чтобы быть администраторами в своих собственных коробках. Есть две действительно веские причины, по которым разработчики не должны быть администраторами:

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

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

У некоторых боссов есть третья причина - я не хочу, чтобы вы устанавливали игры или неавторизованные инструменты. Не обсуждая достоинств этой причины, я буду наблюдать, что она обычно остается неустановленной. Вам нужен доступ администратора для установки того, что вы пишете, для настройки IIS, для перенастройки вашего компьютера для различных видов тестирования (например, для редактирования файла хоста), и две «настоящие» причины, по которым вы отказываетесь от доступа администратора, больше не применимы для Windows 7 Поэтому вы должны быть админами.

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

Это может помочь:

• http://www.slate.com/id/2226279/pagenum/all/
• /server/232416/should-dev-be-admin-on-their-computer
• http://avecto.com/blog/2010/09/the-pros-and-cons-of-windows-7-application-control-with-applocker/

PS: удачи!

Один из вариантов - запросить тестовые рабочие станции, которые разрешают административный доступ.

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

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

Четвертый вариант - торговля. Проект миграции обычно нуждается в разработке для обновления своего программного обеспечения для Win7. Может оказаться возможным обусловить поддержку прав администратора в новой среде.

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

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

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

С точки зрения чистой ИТ и развития многие компании решают эту проблему следующим образом:

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

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

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

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

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

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

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

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

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

1. Программисты имеют права локального администратора на своей машине разработки.
2. Разрабатывающие машины не подключены к сети компании.

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

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

Можете ли вы использовать виртуальную среду?

Если вы не занимаетесь графикой, то запуск MSVC в vmware или virtualbox - это нормально (если у вас много оперативной памяти), тогда вы можете иметь администратора в виртуальной среде, и «их» установка заблокирована