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

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

Самая большая проблема с тем, чтобы не блокировать машину разработчика, состоит в том, что любое программное обеспечение, которое они разрабатывают, потребует полных прав администратора для запуска. Доступ для разработчиков должен быть таким же, как и в среде, в которой они должны будут работать. Если они должны быть «самостоятельно поддерживаемыми» или «самостоятельно устанавливаемыми», то предоставьте им другую учетную запись администратора, например Bruce.admin, которую они должны использовать при выполнении администратора вещи, но не используются изо дня в день.

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

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

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

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

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

Посмотрите эту публикацию в Stackoverflow, чтобы узнать о преимуществах блокировки компьютеров разработчиков. (Отказ от ответственности: я написал принятый ответ).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы собираетесь заблокировать системы разработки, вам следует учесть следующее:

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

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

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

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

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

Скажем по-другому. Если Марк Руссинович может быть принят руткитом , любой может!

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

Проблема в том, что в конечном итоге вы получите целый этаж разработчиков, каждый из которых делает то, что они делают, обычно большинство из них даже не заботятся о безопасности и просто хотят, чтобы их приложение работало. Затем вы получите запрос: «Мы завершили фазу разработки, пожалуйста, скопируйте нашу среду разработки на test, pre-prod и prod».

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

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

• Разработчики НЕ получают root-доступ - никогда - для среды разработки.
• Разработчики получают root-доступ к пред-разработчикам серверов VMware, но НИКАКОЙ поддержки.
• Разработчики должны либо предоставить RPM-пакеты, относящиеся к дистрибутиву ОС, на котором будет работать их приложение, ИЛИ RPM-пакеты, соответствующие FHS и LSB.
• Ни одно из их приложений ни при каких обстоятельствах не может работать от имени пользователя root
• Не будет иметь доступ к suили sudoк пользователю приложения - которые будут заблокированный к наличию NO оболочки доступа. (Это для учета / аудита).
• Любые команды, которые они должны выполнить с привилегированным доступом, должны быть явно запрошены и утверждены - в это время они будут добавлены в sudoersфайл.
  • Ни одна из этих команд / скриптов не будет доступна для записи.
  • Никакая ссылка на скрипт (прямо или косвенно) этими командами не будет доступна для записи.

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

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

Таким образом, как предположил Винсент Де Баер, лучшим вариантом было бы просто восстановить систему из образа, конечно, после этого необходимо восстановить среду, но это не должно быть проблемой ИТ. Если это случается N раз, вы можете поместить указанного человека в своего рода «черный список» и, да, на время отбросить его административные права.

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

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

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

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

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

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

Я (как сам разработчик) предпочитаю полностью контролировать свои машины, то есть смысл; работает как администратор, когда это необходимо.

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

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

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

Вам все равно придется поддерживать их сетевыми ресурсами, доменами и учетными записями, установкой программного обеспечения не-dev-инструментов и т. Д.

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

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

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

Мы бы хотели поместить всех людей с правами администратора в «ненадежный» vlan, но мы так и не добрались до этого.