Является ли блокировка машины разработчиков большим усилием, чем это стоит? [закрыто]

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

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

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

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

Посмотрите, что этот Stackoverflow отправляет для некоторых живых дебатов о достоинствах заблокировать вниз машины разработчика. (Правовая оговорка: Я записал принятый ответ).

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

Сделайте изображение, которое можно использовать для восстановления машин с при необходимости. Вручную устанавливающий SQL Server dev выпуск, Visual Studio, Cygwin и MikTex плюс набор других приложений является довольно трудоемким. Изображение с этими установленными крупными приложениями будет довольно ценно, если необходимо повторно отобразить машины очень.

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

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

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

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

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

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

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

Я добавлю, что это - намного меньше проблемы о среде Linux или Unix; пользователи могут довольно в большой степени настроить свою собственную среду от их .profile. Можно скомпилировать и установить вещи под собственным /home/bloggsj/bin каталог к восхищению Вашей основы. 'Локальные права администратора' являются главным образом проблемой окон, хотя существует все еще несколько вещей, которые должны базироваться доступ под Unix.

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

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

Ответ действительно: нет никакого простого ответа "да" или "нет". Но безопасность, по крайней мере, как важная для Ваших dev пользователей что касается кого-либо еще.

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

Если Вы собираетесь предоставить devs полный, беспрепятственный доступ к их системам, то необходимо действительно рассмотреть следующие дополнительные меры:

• Обеспечьте другую систему, заблокированную вниз так, как системы обычного пользователя заблокированы вниз для нормального использования non-dev.
  • Помещенный их полный доступ dev машины в специальный VLAN, с доступом только к dev ресурсам.
• Спросите что, если что-нибудь препятствовало бы тому, чтобы зараженная система подвергла опасности кодовую базу. Мог backdoor'd машинный контроль в злостном коде, или вытирать кодовую базу, в руках враждебного хакера? Сделайте соответствующие шаги для снижения этого риска.
• Точно так же спросите, к чему, если что-нибудь защищает бизнес-данные, сохраненные в системах, devs имеют доступ.
• Регулярно делайте материально-технические ресурсы программного обеспечения и проверку защиты dev систем.
  • Поймите, что они выполняют и используют эту информацию для создания dev системных изображений повторного развертывания.
  • Рано или поздно у Вас будет dev, кто становится небрежным и устанавливает вещи, которые явно опасны или полностью non-work-related. Путем отправки предупреждений быстро, когда это происходит, Вы будете позволять dev сообществу знать, что да, кто-то смотрит, и они действительно несут ответственность остаться в рамках разумных стандартов.
• Вы делаете регулярные вредоносные сканирования? В некоторых случаях devs будет справедливо жаловаться на налог на производительность, наложенный системами AV при запуске (те системы AV, которые всегда включены, всегда сканируя на каждом доступе к файлу). Может быть предпочтительно переместиться в ночную стратегию сканирования и / или создать исключения файла/папки к Вашему сканированию при запуске. Удостоверьтесь, что исключенные файлы сканируются некоторым другим способом, все же.
  • Ваш поддерживающий администратора devs может выключить все сканирование AV? Как Вы обнаружили бы и устранили бы это?

Если Вы идете в блокировку dev системы, то необходимо рассмотреть следующее:

• У Вас есть возможность поддержки ответить на их запросы поддержки быстро? Полагайте, что среднее число платит по ставке Вашего devs и спрашивает, заслуживают ли они более быстрого SLA времени отклика. Вероятно, не имеет смысла сохранять Ваши $120 тысяч dev (кто является ключевым для многомиллионного проекта), ожидающий вокруг, в то время как Вы обрабатываете поддержку reqs от $60 тысяч / сотрудники года.
• У Вас есть ясная и однозначная политика в отношении того, какие запросы поддержки Вы будете и не обслуживать для Вашего devs? Если они начнут получать чувство, что поддержка произвольна, то Вы будете в конечном счете чувствовать боль.

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

Как примечание стороны, я видел, что очень похожие аргументы происходят с системными администраторами. По крайней мере на двух различных заданиях я видел, что системные администраторы обсуждают вполне резко, когда было предложено, чтобы они самостоятельно заблокировали вниз системы или по крайней мере используют два логина (один с корнем/администратором privs; один без). Многие системные администраторы чувствовали, что они не должны быть заблокированы вниз всегда и обсуждены напряженно против таких мер. Рано или поздно у некоторого нерасположенного к блокировке администратора был бы инцидент безопасности, и пример будет иметь образовательный эффект на всех нас.

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

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

Давайте поместим его иначе. Если Mark Russinovich может быть принят руткитом, кто-либо может!

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

Проблема состоит в том, что Вы закончите со всем этажом разработчиков, каждое выполнение, что они делают, обычно большинство даже не сознательно безопасность и просто хочет, чтобы их приложение работало. Затем Вы будете поражены запросом - "Мы завершили этап разработки, копируйте нашу dev среду на тест, предварительное напоминание и напоминание".

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

Я вырабатываю довольно простую политику:

• Разработчики НЕ получают корневой доступ - никогда - для среды разработки.
• Разработчики ДЕЙСТВИТЕЛЬНО получают корневой доступ к pre-dev серверам VMware, но НИКАКУЮ поддержку.
• Разработчики должны или обеспечить RPM-пакеты, которые принадлежат распределению ОС, на которое их приложение будет работать, ИЛИ, RPM-пакеты, которые выполняют FHS и LSB.
• Ни одно из их приложений не может ни при каких обстоятельствах, выполненных как корень
• Желание не имеет доступ к su или sudo пользователю приложения - который будет заблокирован вниз к наличию НИКАКОГО доступа оболочки. (Это для учета/аудита).
• Любые команды, которые они должны выполнить с привилегированным доступом, нужно будет явно требовать и утвердить - в котором времени он будет добавлен к sudoers файл.
  • Ни одна из этих команд/сценариев не будет перезаписываема ими.
  • Никакой сценарий (прямо или косвенно) ссылка этими командами не будет перезаписываем ими.

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

Блокировка вниз машин разработчиков прилагает больше усилий, чем он ценность. Это серьезно вредит производительности, поскольку Вы в значительной степени ничего не можете сделать без административных прав. Конечно, в конечном счете система станет испорченной, но конечно Ваш DEP IT не оказывает поддержку для всех тех сторонних инструментов, которые используются в разработке?

Так, как предложенный Vincent De Baere, лучший план действий просто восстановил бы систему из изображения, конечно, среда должна быть восстановлена после этого, но это не должно быть проблемой IT. Если это происходит времена N, можно поместить упомянутого человека в своего рода "черный список" и, да, отбросить его административные права некоторое время.

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

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

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

Обновление - На стороне Windows вещей существует немного больше, которое стоит отметить, по-видимому, Visual Studio, требующая, чтобы права Администратора были немного датированы и существуют теперь явные способы установить необходимые полномочия (файл PDF). Однако я не думаю, что это изменяет мою опцию так очень в этом большинство разработчиков, я знаю, сам включенный, склонен использовать дополнительные инструменты вне просто Visual Studio и знающий, в чем все они нуждаются с точки зрения полномочий, может быть твердо предсказать.

Я соглашаюсь с понятием использования виртуальных машин сверх ограниченного рабочего стола -

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

Я (как dev сам) предпочитаю иметь полный контроль над своим оборудованием, имея в виду; выполнение как администратор при необходимости.

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

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

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

Необходимо будет все еще поддерживать их с сетями, доменом - и материал учетной записи, установки программного обеспечения non-dev инструментов и т.д.

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

Мы закончили со следующими процессами:

• Наше стандартное изображение имело основные инструменты: Windows, Office, Антивирус, Acrobat, несколько утилит.
• Мы обеспечили много пространства сетевого диска: достаточно так, чтобы все могло быть сохранено в сети. О единственном исключении был в процессе видеофайлы, которые должны были остаться локальными.
• У штата (после консультаций с их супервизорами) было два варианта: или IT поддержал их ПК, делая все установки и конфигурацию, ИЛИ у них мог быть доступ администратора, чтобы сделать это самих. В любом случае все данные были сохранены в сети.
• Если IT обслужил систему, и это умерло, мы отложили его к состоянию, это было в, включая добавление дополнительного программного обеспечения, им было нужно это, мы установили.
• Если бы у них был доступ администратора, и система умерла, то мы взглянули бы и попытались бы зафиксировать его, но наше обязательство состояло в том, чтобы вернуть их к стандартному изображению, и они должны будут взять его оттуда. Если бы у них были какие-либо локальные данные, то мы попытались бы получить это от первого, но наш SLA должен был только получить их работа, стандартный ПК как можно скорее.
• Любой, которого w/доступ администратора потребовался, чтобы знать, как удостовериться обновления Windows, работал, для держания в курсе Антивируса и антивируса.

Нам понравилось бы помещать всех людей с доступом администратора на "недоверяемом" VLAN, но мы никогда не добирались до этого.