Работая разработчиком и ИТ-администратором / службой поддержки команды разработчиков, я сталкивался со многими различными типами сред, от полностью заблокированных до совершенно не связанных. При моем ограниченном опыте поддержки я думаю, что было меньше усилий поддерживать менее заблокированную машину, и я определенно чувствовал, что это было проще, но, конечно, это могло быть предвзятым отношением. Я хотел бы знать, какова точка зрения с точки зрения ИТ-поддержки, действительно ли сложнее поддерживать разработчиков, у которых есть незафиксированные машины?
Большинство разработчиков технически подкованы и знают, что делают. Им часто приходится устанавливать множество специализированных приложений, и необходимость получения разрешения на это и принуждение ИТ-отделов к тому, чтобы добавить это, может быть очень неприятным, особенно в крупных компаниях, для обеих сторон.
Я обнаружил, что лучше всего позволяет им делать то, что они хотят, в отношении установки программного обеспечения на свои машины, но если у них возникнут проблемы с тем, что мы не поддерживаем, они останутся сами по себе. Большинство разработчиков довольны этим и в любом случае предпочитают иметь возможность позаботиться о своей машине.
Запретить кого-то в бухгалтерии использовать только IE и open word - это нормально, но если вы разработчик, которому нужно установить 4 разных типа браузера и вам нужно быстро установить приложение для решения проблемы, это может раздражать.
Мой опыт показывает, что компании, обладающие большим объемом технических знаний, например, центры разработки, поставщики ИТ и т. Д., Которые доверяют своим сотрудникам и позволяют им решать, что им нужно установить, намного счастливее и меньше беспокоят ИТ-специалистов.
Видеть эта публикация в Stackoverflow для оживленных дискуссий о достоинствах блокировки машин разработчиков. (Отказ от ответственности: я написал принятый ответ).
С точки зрения системного администратора, доступ к производственным системам является деликатным, и вам следует ограничить такой доступ для людей, которым он нужен для выполнения своей работы (это могут быть разработчики, у которых есть обязанности по поддержке уровня 3 для приложения). Права локального администратора на ПК для разработки или на сервере разработки не оказывают существенного влияния на безопасность ваших производственных систем.
Создайте образ, который можно использовать для восстановления машин при необходимости. Ручная установка SQL Server dev edition, Visual Studio, Cygwin и MikTex, а также множества других приложений занимает довольно много времени. Образ с установленными этими большими приложениями будет достаточно ценным, если вам придется сильно переопределять образ машин.
С точки зрения разработки я считаю, что могу исправить большинство проблем с машиной, и обычно мне нужна помощь со стороны персонала службы поддержки сети в довольно редких случаях. Чрезмерно ограничительные среды имеют тенденцию генерировать ложный трафик поддержки разработчиков для выполнения работы, которую разработчики вполне способны выполнять сами.
Еще одно место, где разработчикам, как правило, требуется много административной работы, - это серверы баз данных, на которых размещены среды разработки. Большинство разработчиков способны легко изучить рутинные задачи DBA и в любом случае должны получить практические знания об этом (IMHO в принципе). Чрезмерно ограничивающие политики административного доступа на серверах разработки могут быть сбиты с толку разными способами.
Сеть разработки с нуля - неплохая идея, если ее можно организовать - при необходимости вы можете использовать брандмауэр со своих производственных серверов.
Когда разработчики могут легко воспроизвести структуру производственной среды, это способствует развитию культуры тестирования развертывания, при которой интеграционный тест может быть синтезирован, не прыгая через обруч. Это будет способствовать повышению качества выпуска и развертывания производственной среды.
Возможность эмуляции производственной среды также повышает осведомленность о проблемах производственного развертывания и поддержки. Это побуждает разработчиков задуматься о том, как приложение может поддерживаться в производственной среде, что, вероятно, будет способствовать созданию архитектур, построенных с учетом этого.
Если в этой сети есть контроллер домена, вы можете установить доверительные отношения, чтобы он доверял вашему основному контроллеру домена и его учетным записям. Эти доверительные отношения не обязательно должны быть взаимными, поэтому они не ставят под угрозу безопасность вашей производственной сетевой инфраструктуры. Это может позволить вам иметь ненадежную сеть разработки, но при этом разрешить разработчикам доступ к ресурсам с проверкой подлинности домена, таким как учетные записи Exchange или файловые серверы.
Вы хотите, чтобы у разработчиков был разумный простор для экспериментов без необходимости прыгать через обручи. Создание политических препятствий на пути этой работы имеет тенденцию поощрять нанесение штукатурных растворов, которые политически целесообразны, но создают долгосрочный (и часто непризнанный) технический долг. Как системный администратор или аналитик службы поддержки, угадайте, кто возьмется за дело ...
Я добавлю, что это гораздо менее серьезная проблема в среде unix или linux; пользователи могут довольно сильно настраивать свою среду из своих .profile. Вы можете компилировать и устанавливать самостоятельно /home/bloggsj/bin каталог к радости вашего сердца. «Права локального администратора» - это в основном проблема Windows, хотя есть еще несколько вещей, которым нужен root-доступ в Unix.
Самая большая проблема, связанная с отказом от блокировки машины разработчиков, заключается в том, что для запуска любого программного обеспечения, которое они разрабатывают, потребуются полные права администратора. Доступ разработчиков должен быть таким же, как и среда, в которой они будут работать. Если они должны быть «самоподдерживаемыми» или «самоустанавливаемыми», дайте им другую учетную запись администратора, например Bruce.admin, который им нужно использовать при работе с администратором, но не используется изо дня в день.
Точно так же, как ни один достойный администратор UNIX никогда не будет использовать учетную запись root для своей повседневной работы без администратора.
Самый разумный вариант, который я когда-либо видел (были с обеих сторон - и до сих пор -) - это просто разблокировать вещи и неподдерживаемый также. Дайте им свободу, и если они облажаются, все, что они смогут получить, - это рестаж со стандартным изображением ... В этой ситуации я считаю хорошим планом подключить их к какой-либо «ненадежной» сети.
Что касается (не) чувства блокировки рабочих столов разработчиков: я почти уверен, что все блокировки в любом случае только мешают производительности, более того, любой достаточно опытный разработчик легко найдет дыры ...
Ответ действительно таков: нет простого ответа «да» или «нет». Но безопасность по крайней мере так же важна для ваших пользователей-разработчиков, как и для всех остальных.
С одной стороны, да, разработчики имеют тенденцию быть технически более подкованными. С другой стороны, их работа часто бывает напряженной, и их этапы разработки, вероятно, будут иметь приоритет над дополнительной заботой, необходимой для поддержания собственной системы в качестве безопасной среды. Это не критика разработчиков; это прямое рассмотрение их повседневных обязанностей.
Если вы собираетесь предоставить разработчикам полный, неограниченный доступ к их системам, вам действительно следует рассмотреть следующие дополнительные меры:
Если вы собираетесь заблокировать системы разработки, вам следует учесть следующее:
В любом случае, вы должны признать, что разработчики - это особый случай, и им действительно нужна какая-то дополнительная поддержка. Если вы не планируете для этого бюджет, скорее всего, проблемы возникнут прямо сейчас ... или будут в будущем.
Кстати, я видел очень похожие споры с системными администраторами. По крайней мере, на двух разных должностях я видел, как системные администраторы довольно яростно спорили, когда предлагалось, чтобы они сами заблокировали системы или, по крайней мере, использовали два входа в систему (один с правами root / admin; один без). Многие системные администраторы считали, что их нельзя блокировать каким-либо образом, и яростно возражали против таких мер. Рано или поздно у какого-нибудь администратора, не склонного к изоляции, случится инцидент с безопасностью, и этот пример окажет на всех нас образовательный эффект.
Раньше я был одним из тех системных администраторов, которые все время работали с правами администратора. Когда я перешел на двойные учетные записи и повысил их только при необходимости, я признаю, что в первые несколько месяцев это было довольно неприятно. Но серебряной подкладкой в облаке было то, что я узнал намного больше о безопасности систем, которыми я управлял, когда моя обычная учетная запись находилась под теми же ограничениями, которые я наложил на пользователей. Это сделало меня лучшим админом! Я подозреваю, что то же самое и с разработчиками. И, к счастью, в мире Windows теперь есть UAC, который упрощает работу с ограниченными правами и повышает только при необходимости.
Лично я не думаю, что кто-то должен быть выше тех или иных мер безопасности. Все (системные администраторы, разработчики, высшее руководство в том числе) должны подвергаться достаточному количеству процедур безопасности и надзора, чтобы держать их в напряжении. Сказать иначе - значит сказать, что системы и данные компании не стоят усилий по защите.
Скажем иначе. Если Марк Руссинович может быть взят руткитом, может любой!
Если у вас есть несколько разработчиков, возможно предоставление им серверов разработки, но если у вас есть целый этаж разработчиков, то я категорически против предоставления им каких-либо прав администратора.
Проблема в том, что вы получите целый этаж разработчиков, каждый из которых будет делать то, что делает, обычно большинство даже не заботятся о безопасности и просто хотят, чтобы их приложение работало. Затем вы получите запрос: «Мы завершили этап разработки, пожалуйста, реплицируйте нашу среду разработки на тестовую, предварительную и производительную».
Они также приобретают привычку устанавливать случайный мусор (плохо упакованное программное обеспечение), а затем поручают вам установить его на дюжину или около того серверов на других уровнях.
Я делаю политику довольно простой:
su или sudo пользователю приложения - который будет заблокирован, чтобы НЕ иметь доступа к оболочке. (Это для бухгалтерии / аудита).sudoers файл. Вышеупомянутое, прежде всего, заставит их задуматься о том, что будет, а что нельзя, когда придет время переносить проект на тестовые и выше серверы.
Блокировка машин разработчиков требует больше усилий, чем того стоит. Это серьезно вредит производительности, поскольку без административных прав ничего нельзя сделать. Конечно, в конечном итоге система выйдет из строя, но наверняка ваш ИТ-отдел не обеспечивает поддержку всех тех сторонних инструментов, которые используются при разработке?
Итак, как предположил Винсент Де Бэр, лучшим способом действий было бы просто восстановить систему из образа, конечно, после этого необходимо восстановить среду, но это не должно быть проблемой ИТ. Если это произойдет N раз, вы можете занести указанного человека в своего рода «черный список» и, да, на время лишить его административных прав.
В любом случае среда должна быть настроена таким образом, чтобы гарантировать, что зараженная (или иным образом испорченная) машина вообще не влияет на другие машины или, скажем, не рассылает спам или что-то в этом роде (хорошо, теперь Я просто говорю очевидные вещи, извините).
Что ж, это может частично зависеть от того, в какой среде вы работаете (например, Linux или Windows); однако, если предположить, что среда Windows, это обычно больше проблем, чем того стоит просто потому, что для работы некоторых программ разработки требуются повышенные разрешения. Например, Известно, что Visual Studio требует разрешений администратора.как таковой, я не вижу пользы в том, чтобы заставлять кого-то прыгать через обруч для необходимой части своей работы.
Однако, если компания требует, чтобы все было заблокировано, ваш лучший выбор, скорее всего, предоставит всем разработчикам виртуальные машины в их системах, от которых они могут сойти с ума. Хотя некоторым это может не так сильно нравиться, это, вероятно, даст вам лучшее из обоих миры (например, обычный рабочий стол с ограничениями и полностью настраиваемая среда).
Обновить - Что касается Windows, стоит отметить еще кое-что, по-видимому, Visual Studio, требующая прав администратора, немного устарела, и теперь есть явные способы установки необходимых разрешений (PDF-файл). Однако я не думаю, что это сильно меняет мой вариант, поскольку большинство разработчиков, которых я знаю, включая меня, склонны использовать дополнительные инструменты, помимо Visual Studio, и трудно предсказать, что им всем нужно с точки зрения разрешений.
Я согласен с идеей использования виртуальных машин поверх ограниченного рабочего стола -
Если не требуется иное, я считаю, что лучшая установка - это ограниченный рабочий стол Linux с общедоступной виртуальной машиной сверху. Linux снижает накладные расходы для меня, виртуальная машина может не только быть какой-то адской ОС, которую они хотят, но также может быть восстановлена в моментальные снимки или резервные копии, и в целом мир выглядит немного ярче, когда нет целого ряда различных настроек, требующих служба поддержки.
Я (как разработчик) предпочитаю иметь полный контроль над своим оборудованием, то есть; при необходимости работает как администратор.
Вы можете провести специальную подготовку для разработчиков, прежде чем им будет предоставлен полный доступ к своим компьютерам. Установите для них некоторые правила, и, возможно, вы могли бы время от времени проводить аудит, чтобы убедиться, что они следуют лучшим практикам.
В основном им нужно будет знать больше об ИТ-инфраструктуре с точки зрения ИТ-администратора / ИТ-поддержки, о вещах, связанных с безопасностью, а также о том, почему бы не разрабатывать с повышенными правами. (и как убедиться, что вы этого не сделаете ...)
"Не доверяйте нам слепо, когда мы говорим вам, что знаем все мы нужно знать о компьютерах ";-)
Вам все равно придется поддерживать их с помощью сети, работы с доменами и учетными записями, установки программного обеспечения инструментов, не предназначенных для разработки, и т. Д.
Мой опыт связан с популяцией пользователей, которые были примерно поровну разделены между людьми, которым нужна была только заблокированная машина, и другими (разработчиками, учеными), которым требовался доступ администратора. Эти высококлассные люди использовали много различного программного обеспечения, некоторые из них были собственными, некоторые нет, но для запуска многих из них требовался администратор, а их работа требовала от них использования большого количества пакетов, поэтому имело смысл позволить людям делать это. это сами.
В итоге мы получили следующие процессы:
Мы бы хотели поместить всех людей с административным доступом в «ненадежный» vlan, но до этого так и не дошли.