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

Я работаю в компании со штатом приблизительно 1000 +. У нас в настоящее время есть программные сотрудники развития, которые работают над веб-проектами (приблизительно 50 человек).

Недавно из-за проблем безопасности наш IT и отдел безопасности осуществили ограничение, больше не позволяющее местный доступ администратора на машинах. Вся компания управляет Windows OS и для рабочих станций и для серверов. Я достиг единой точки зрения с решением удалить администратора, честно я думал, что оно давно ожидалось (поскольку компания имеет дело с терпеливыми данными и требует соблюдения HIPAA). К сожалению, я полагаю, что они приняли решение слишком далеко. Я принял подгруппу, или группа н. э. будет создана для пользователей, которым законно был нужен доступ администратора, чтобы сделать их работу (ИСКЛЮЧАЯ моей командой программистов) что-то как Техническая группа, которая сохранит доступ администратора. Однако, дело было не так единственная группа создала определенную группу Администратора для штата Сетевой и Справочной службы.

Основная проблема как веб-разработчики, мы управляем программами, которые требуют местного доступа администратора и к сожалению не могут сделать нашей работы без них бегущий как администратор. Примеры программы включают Visual Studio для веб-разработки ASP.NET, MAMP для местного развития, композитора, и т.д. Я верю главной причине, которой состоит в том этот доступ администратора потребности программ, потому что они должны управлять и изменить местный IIS, командную строку, и т.д.

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

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

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

Немного больше информации о нашей сетевой среде (не, что это действительно касается вопроса, я просто думал, что добавлю это):

  1. Мы используем AppBlocker, чтобы заблокировать программы не в одобренном списке
  2. Мы используем почтовый блокатор безопасности, который делает вещи как просмотр и преобразовывать приложения к PDF, и т.д.
  3. у Нас есть по крайней мере 2 главных антивирусных программы на всех рабочих станциях.
  4. сеть и это - очень отдельные серверы, у пользователей только есть доступ к определенным серверам, папкам и базам данных, к которым они законно нуждаются в доступе.
113
В моей жизни работы у меня всегда был доступ администратора. Одна Компания попыталась удалить это от нас, но остановила его довольно быстро после понимания, что devs не только становятся разбитыми, но и просто прекратили работать. Не потому что они не хотели, но потому что они не могли больше работать. Так, по крайней мере, на основе моего личного опыта (в Германии) довольно распространено иметь доступ администратора для разработчиков. (Я знаю от НЕКОТОРОГО devs, что они должны использовать VMs (с правами администратора) как компромисс для сильной окружающей среды безопасности
добавлено автор Majin Magu, источник
Я - программист контракта в оборонной промышленности. У каждой компании, на которую я работаю, есть программа, которая даст права администратора временного секретаря, регистрируя меры, принятые из соображений безопасности. Отвечать на ваш вопрос: "действительно ли это распространено?" - да, но that' s действительно четко определенный вопрос о безопасности (никакое предназначенное преступление)
добавлено автор JW., источник
Одна оборотная сторона разработчикам программного обеспечения, бегущим как местные администраторы, они никогда могут не сталкиваться с проблемами конечного пользователя, которые только происходят, когда вы не имеете таких прав. I' ve, лично замеченный это много раз происходить.
добавлено автор Benjamin Podszun, источник
Вы попытались установить конечные точки WAAS давать вашему пользователю/групповому доступу http://+:80/? Google для "netsh http добавляет urlacl"...
добавлено автор Haakon, источник
История: I' ve никогда не работал на компанию, которая захватила вниз их employee' s этот путь, у которого был любой вид реальной компетентной безопасности. Любая компания I' ve работал на это, сделал подведенный в основах, делая работу для их сотрудников чрезвычайно трудной. I' ll также говорят, что я никогда не буду работать на компанию как этот снова. I' d скорее на самом деле делают значащую работу, чем соглашение с бюрократической тратой everyone' s время.
добавлено автор idrosid, источник
Наем @atdre compentent инженеры. Кроме того, если вещи настраиваются правильно, ни один из того, на что вы просто жаловались, имеет любой реальный риск.
добавлено автор idrosid, источник
Знаменитый, некоторые средства разработки не будут работать, если счет не будет администратором. Это имеет тенденцию быть более верно более старое, которое программные инструменты.
добавлено автор alexis.kennedy, источник
Если вы позволите appdevs ladmin их машины, то они установят unauth FTP, RSH, Webmin, Дженкинса, Кота, ColdFusion, JBoss/WildFly, Splunkd, ElasticSearch, и т.д. - и они никогда не будут модернизировать. They' ll формируют SimpleHTTPServer, SMB, Франс-Пресс и/или NFS, чтобы позволить волей-неволей доступ для чтения-записи к их локальным файловым системам по сети (или части этого) и затем they' ll оставляют сценарии оболочки и ключевой материал по тем совместно используемым папкам. They' ll делают то же самое с базами данных и чем-либо еще, что может связать с сетевым гнездом.
добавлено автор Rufo Sanchez, источник
@Brad: Прошлый приблизительно 300 сотрудников, это невозможно. Есть убедительные доказательства, что даже профессионалы кибербезопасности пали жертвой универсального фишинга и фишинга копья. Когда вы складываете мотивированного в финансовом отношении актера или национальное государство, против одного человека — это обычно - человек, который проделывает отверстие. Nah, это всегда. Там не надлежащее, “настраивает” это, я услышал об этом, снижает риск расширения доступа в Лесной окружающей среде Windows Server. Даже Microsoft не продает тот.
добавлено автор Rufo Sanchez, источник
Idk, у вас есть прекрасные идеи, но я никогда не видел их осуществленный хорошо. Я думаю it' s лучше всего, чтобы осуществить JitJea независимо. Ни у кого не должно даже быть администратора для длинного (секунды), особенно не местный администратор к рабочей станции или администратор домена / группа к сетям большой установки.
добавлено автор Rufo Sanchez, источник
Так как компания рассматривает devs как проблему и не как решение (по-видимому, вашего босса или не услышали или проигнорировали), я предлагаю искать более благоприятную для разработчика окружающую среду в другом месте. И так как мы находимся на Stackexchange, у нашего великого основателя есть a твердое мнение о том, как ваша компания рассматривает вас.
добавлено автор Kromster, источник
Я don' t думают, что вы действительно хотите спросить если it' s "типичный". А скорее действительно ли это допустимо, и какова стоимость/преимущества? В моем опыте it' s несколько характерный для крупных организаций, чтобы попробовать это. Затраты довольно высоки, и это решительно обычно затрагивает производительность для Разработчиков, но "специалисты по безопасности" don' t заботятся потому что it' s окруженный в СЕНТЯБРЬСКОЙ области (Кто-то Else' s проблема). Если вы хотите избавиться от этого, you' ре вряд ли, чтобы выиграть попытку найти, что этот isn' t типичный, а скорее это it' s ДОРОГОЙ. Дорогая ненависть компаний.
добавлено автор Steve Sether, источник
@Jacco I couldn' t соглашаются больше. Я раньше работал на организацию, которая сделала это, и она создала точно то трение you' ре, говорящее о. Когда Big Evil Corp. пыталась осуществить это, мои первые мысли, сосредоточенные вокруг скачка забора. Любой промежуточный квалифицированный разработчик может придумать полдюжины способов подскочить эти типы заборов без особых усилий.
добавлено автор Steve Sether, источник
Наличие двух отдельных антивирусных программ на системе почти наверняка принесет больше вреда, чем пользы. You' ll получают незначительное увеличение обнаружения, удвоив вашу подверженность слабым местам в самом программном обеспечении AV, а также значительно замедлив затронутые системы.
добавлено автор Valerie Anderson, источник
@Jacco Не говоря уже о внутреннем конфликте между не доверением разработчику с их собственной машиной и одновременно доверием им, чтобы разработать пользовательский код, которым будут управлять на company' s серверы и это обрабатывает чувствительную информацию о конечном пользователе. Если они can' t держат вирус от своей машины без мер защиты, я don' t думают I' d хотят их разрабатывающий мои приложения, что я мог быть оштрафован за то, что я не сделал правильно.
добавлено автор jpmc26, источник
@Neil Да, необходимо быть местным администратором, чтобы даже открыть iis менеджера или приложить отладчик к iis рабочему процессу.
добавлено автор Obviously_Anon, источник
@Neil Кроме тех случаев, когда вы can' t используют IIS Express, как то, когда необходимо развернуть приложение к другому компьютеру и иметь его, соединяются с рабочей станцией.
добавлено автор Obviously_Anon, источник
@Neil не проблема интеграции; если вы не думаете, что разработчик, управляющий приложением его, продолжает работать в местном масштабе, чтобы проверить его, прежде чем совершение будет "интеграцией". Есть много других вещей, которые должны будут сделать разработчики, которые требуют местного администратора, и не наличие местного администратора является серьезным препятствием для того, чтобы быть производством, которое является, вероятно, почему большинство разработчиков заканчивает с ним (и я лично не работал бы где-нибудь я didn' t).
добавлено автор Obviously_Anon, источник
Политика компании, которая поощряет разногласия между IT и развитием, является опасной политикой. , Если есть одна группа людей, которые могли бы серьезно подорвать IT department' s усилия по безопасности, это будут разработчики. Хорошая политика компании стремилась бы иметь IT, и развитие объединяют их коллективное знание, чтобы укрепить полную безопасность. Принуждение IT поднять барьеры для развития контрпродуктивно к этому результату. Учитывая достаточное количество стимула, люди начнут искать творческие искусственные приемы. Творческие искусственные приемы от разработчиков будут вредны к полной безопасности.
добавлено автор Brythan, источник
@matwonk, Пожалуйста, сохраняйте нас размещенными на как проблема законченный.
добавлено автор Brythan, источник
Не тот же самый вопрос, но очень связанный, я был с другой стороны (сторона IT вещей, и люди IT часто не согласовывают с такой сумасшедшей политикой ни одного): security.stackexchange.com/questions/135359/…
добавлено автор grochmal, источник
Любое dev стоящее проклятого получит доступ корня на машине, к которой у него есть физический доступ:)
добавлено автор Navin, источник
Путем I' ve, с которым имеют дело с этим в прошлом, делая довольно основное обращение к боссу/директору, который является выше людей безопасности IT-систем в старшинстве. Это проходит примерно так: "У меня есть проблема, что означает I can' t получают любую сделанную работу, но I' ve определил решение, и только нуждаются в вашем одобрении осуществить его". Странно достаточно потребность в компании, чтобы делать деньги всегда бьет экзистенциальную угрозу, что люди безопасности IT-систем изобретают, чтобы оправдать их драконовские меры. ОДНАКО: всегда будьте приятны, делая это - вы хотите команду безопасности IT-систем на своей стороне, долгосрочной.
добавлено автор user128064, источник
@atdre, Который является completly возможный, вы просто, должен организовать себя лучше. Когда я работал в огромном магазине программного обеспечения, каждый проект был полностью отделенной "виртуальной компанией" в связанных с IT вопросах, с ним собственные серверы, команда и полностью изолированный infraestructure. Не было никакой потребности поместить всех на ту же самую сеть все время. Это творило чудеса. Это также имело, плюс который вы могли переместить команду куда угодно, не ставя под угрозу ее работу или имея необходимость настроить доступ к центральному серверу - когда один из наших офисов сгорел, мы арендовали пространство на интернет-кафе и продолжали идти, пока вещи не были починены.
добавлено автор T. Sar, источник
@atdre кроме того, тем, что полностью отделили infraestructures, мы могли управлять модернизациями и различными установками в каждой команде по мере необходимости. Так как команда IT была также compartimentalized за "виртуальную компанию", у каждого профессионала также был путь меньше, чтобы заботиться прочь в любом случае.
добавлено автор T. Sar, источник
It' s иногда требуемый для отладки. Например, используя Visual Studio без местных прав администратора тогда вы can' t отлаживают процесс that' s начался при другом пользователе. Но компания может установка некоторый процесс, чтобы просить временные местные права администратора на рабочей станции для определенного пользователя.
добавлено автор Confutus, источник
Примечание: Если вы позволяете Visual Studio бежать, "Поскольку Администратор" пользователь может управлять кодом, "Как Администратор". Код с административными привилегиями может назначить привилегию SeDebug любому маркеру безопасности, который это хочет, и следовательно разработчик имеет полный контроль над машиной.
добавлено автор Galaxy, источник
Позволяет даже не исследуют ошибку то есть, добавление, что больше антивирусных продуктов делает систему более безопасной.
добавлено автор Galaxy, источник
Во многих компаниях devs также удваиваются как системные администраторы так they' у ll естественно есть привилегии.
добавлено автор Charlotte Vandersleyen, источник
Это - на самом деле один из вопросов, которые я обычно задаю в собеседованиях, если ответ не, разработчики - not' t позволил местные права администратора, тогда я вежливо отказываюсь продолжать двигаться дальше.
добавлено автор user149010, источник
Это в основном зависит от сектора. Банковское дело, вооруженные силы, утилиты - they' ре все более вероятно, чтобы быть намного более строгим, чем большинство других. Разработка программного обеспечения - умение, которое вы можете переместить в любую промышленность, но являетесь не всегда промышленностью самостоятельно
добавлено автор user155848, источник
Вы/really/нужен доступ администратора, чтобы использовать ASP.NET/IIS? I' ve, разрабатывая те проекты в течение 10 лет, и никогда необходимый доступ администратора. I' ve работал с разработчиками, которые настаивают на нем (на той же самой кодовой базе), но that' s обычно, потому что у них есть ' tools' то, что они (ужасно) написали себя.
добавлено автор Dan Roberts, источник
@Andy Или просто используют IIS Express, и затем вас don' t.
добавлено автор Dan Roberts, источник
@Navin в некоторых местах, которые заставят вас короткая поездка в HR получать свой P45. Да действительно!
добавлено автор Dan Roberts, источник
@Andy, Который больше походит на проблемы интеграции, а не развитие. 100% вашей технической разработки могут быть сделаны без прав администратора.
добавлено автор Dan Roberts, источник

19 ответы

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

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

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

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

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

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

110
добавлено
@Deduplicator, как так? Можно скопировать материал достаточно легко через Карты памяти. Это заставляет вас думать о том, что вы действительно хотите вместо того, чтобы беспорядочно нажать на барахло и установить все. Отсутствие доступа администратора заставило меня организовать свои загрузки в партиях так I' m намного более отборный с тем, что я устанавливаю.
добавлено автор plusplus, источник
@Flater, даже если it' s небезопасный,
добавлено автор plusplus, источник
+1 Это - то, как Infosec/A/V продавец, на которого я работал, сделал это также. Они отнеслись к сетевой сегментации довольно серьезно - это было terminalable преступление включить dev машину в сеть инфраструктуры напоминания / внутреннюю сеть инфраструктуры, и я должен был назвать больше чем одного разработчика для того, чтобы сделать так. Однако, я думаю, что это - лучший, самый дружественный для разработчика подход к проблеме - “вот ваш dev ноутбук в вашей dev сети, и мы изолируем вас от чего-либо, что могло бы быть повреждено из-за evelated разрешений, которых вы требуете, чтобы сделать вашу работу хорошо”.
добавлено автор Shawn, источник
I' d должен был работать в несколько подобной установке, работая в подрядчике DoD. В этом случае моя главная dev машина была связана с главной сетью, Интернетом, и имела местного администратора. Производственные машины были airgapped от мира за запертыми дверями и в широком масштабе захватили вниз. Способность сделать большинство моих dev/initial, проверяющие обычно, уменьшало боль много, но были времена он wasn' t выполнимый создать применимый несекретный набор данных и я должен был сделать все на высокой стороне. Это было несчастно, потому что это была, по крайней мере, 20-футовая прогулка к связанному с Интернетом PC, и только твердая копия xfer к dev.
добавлено автор Brendan Long, источник
@Nelson, Что подход становится очень болезненным на практике. It' s распространенный в наше время, чтобы использовать структуры, чтобы ускорить развитие. Много современных структур зависят в ряде библиотек, и это может быть сложно и подвержено ошибкам, чтобы определить точные зависимости структуры, которую вы используете, чтобы спасти их к USB-устройству. Вы также теряете доступ к важной безопасности, оснащающей тот путь. Некоторые современные диспетчеры пакетов могут автоматически проверить, имеют ли ваши зависимости предупреждения системы безопасности и модернизируют их раз так. Если необходимо сделать это на различной машине, то та машина становится фактической dev машиной.
добавлено автор Valerie Anderson, источник
+1, некоторые группы разработчиков в нашей компании используют ту же самую практику. Хотя мы don' t воздушный зазор сеть развития. Мы обращаемся с ним, используя VLANs.
добавлено автор Philipp, источник
Утечки Исходного кода @NickT обычно - вопрос второстепенной важности. Или во многих организация, никакое беспокойство вообще, потому что их программное обеспечение так специализировано, что у этого нет стоимости ни для кого, но их / их клиент. Опасностью, которая затрагивает всех, является неумышленное вредоносное распространение. Машина, работающая на полных административных привилегиях и получающая доступ к Интернету с программным обеспечением, не исследуемым отделом ИТ, является вредоносным магнитом
добавлено автор Philipp, источник
Откровенно говоря, я вручил бы свое уведомление самый момент, эта политика была введена... Наличие доступа в Интернет на dev машине является просто безумием.
добавлено автор Abdul, источник
Действительно ли ваша "разработка - сеть" действительно производственная сеть? У вас должно действительно быть две коробки, один, чтобы прочитать докторов на, другой, чтобы закодировать? Если it' s dev/test сеть, I' m перепутанный беспокойством, проникновением нападавших, получающих код? Экс-фильтрация кода (ваш devs будет работать вокруг этого приблизительно через 5 секунд)? Если бы это была производственная сеть, вы могли бы, вероятно, постараться не предоставлять доступ инженеров к нему вообще (QA/ops развертывается в напоминание).
добавлено автор The Lazy DBA, источник
На моем рабочем месте USB (и другие съемные носители) отключается (и только допускается белый список dev устройств на ограниченный срок в целях работы), но у нас есть 2 счета, Администратор один для работы dev с нет/ограниченный доступом в Интернет и низким пользователем разрешения, который может просмотреть веб-сайты. Никакая потребность в 2 машинах.
добавлено автор Landmaster, источник
Гм, машины развития, не имеющие любое подключение к Интернету, кажутся довольно серьезным ограничением.
добавлено автор Deduplicator, источник
Большинство мест you' d видят, что развертывание как это хорошо проходит понятие пользовательских машин и хорошо в понятие Счетов: они все управляют VMs или Сетевым широким управляемым бухгалтерским учетом с совместно используемой памятью. Ваш PC Администратора может легко иметь доступ RW к NAS, или даже быть целью VM VPN/SSH, которой только позволяют управлять одним клиентом за комнату (чтобы остановиться, люди, оставляющие его, авторизовались). Это обычно идеально как тогда, IT может получить доступ к администратору от любой системы, Devs может работать, устанавливает через него, но требуются, чтобы логин от учетной записи пользователя станд. сначала, опознавая пользователя Администратора.
добавлено автор Jack, источник
Блокирование доступа к открытой сети является, конечно, безумием, но во всей честности, если вы хотите к dev в окружающей среде администратора, поддерживая безопасность, ваша сторона IT должна виртуализировать ваш номер люкс, таким образом, это могло поиграть в песочнице доступ администратора. Это позволяет вам делать столько же административной работы, пока ограничение вас к внешнему Управлению доступом от VM и мешать любому говорят, заражаясь вирусом на совместно используемой памяти.
добавлено автор Jack, источник
@Nelson, На самом деле, чтобы улучшить безопасность, используемые порты всей USB на технической окружающей среде должны быть разрушены, они неотъемлемо неуверенны. Намного более полезный и более безопасный было бы использование Диода Данных, чтобы допускать загрузку, которой управляют, внешних обновлений. en.wikipedia.org/wiki/Unidirectional_network
добавлено автор MathEW, источник
@Nelson: Как может вы исследовать это что you' ре, копирующее по карте с интерфейсом USB, безопасно? В то время как, очевидно, необходимо позволить копировать с администрации к разработке; вы позволили бы копировать к машину администрации? Поскольку, если вы позволяете обоим, данные, переданные на палке, так безопасны, как данные обменяли на физическом сетевом кабеле (непосредственно между этими двумя машинами), it' s просто более медленный процесс.
добавлено автор user180510, источник
Это не решение сделать слегка. Будет значительное воздействие на развитие. Не говоря it' s невозможный сделать, просто указав на некоторые последствия. От технических вещей, таких как пакеты nuget/npm (вы won' t имеют доступ в режиме реального времени к общественному корму и должны будут скопировать все вручную), но также и больше тривиальных проблем (разработчики can' t скопировать/вставить от StackOverflow больше. И let' s быть реальными здесь, все мы делаем это, даже если мы соглашаемся, что проверка кода необходима (какой imo, это), вручную имение необходимость напечатать все это не будет способствующим эффективной работе).
добавлено автор user180510, источник
Необходимость купить второй PC/ноутбук для сотрудников походит на довольно дорогой способ сделать людей менее продуктивными
добавлено автор public wireless, источник

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

Одно очень общее жилье - доступ к <�сильному> Гиперщитку на рабочей станции (ли некоторая версия VMware или Hyper-V, который идет с Windows), наряду с определенными разрешениями должен был создать и разрушить VMs в том гиперщитке по мере необходимости <�глоток> (Hyper-V/VMware) </глоток>, включая создание VMs, где у них есть права администратора гостю OS. Как правило, некоторые из этих VMs будут долговечны, даже если они не будут бежать все время, где это никогда не вопрос необходимости подготовить весь VM только, чтобы сделать то, что должно быть быстрым тестом с чем-то, чему нужны права администратора.

Гиперщиток может или не может формироваться, чтобы позволить доступ в Интернет, поскольку это - VMs; я видел его оба пути, хотя лично я сильно одобряю тот доступ в Интернет , должен быть позволенным..., по крайней мере, для типов развития, с которым у меня есть большая часть опыта. Но доступ в Интернет, когда предоставлено, может и если в минимуме формироваться, чтобы вызвать VMs в специальный vlan, отдельный от остальной части корпоративной сети. Я не уверен, что это возможно провести в жизнь непосредственно через Hyper-V или VMware, но можно использовать 802.1x на портах для многих выключателей сети, чтобы предотвратить доступ к определенному vlans от несанкционированных машин, включая devloper VMs. Тогда можно дать немного обучающей программы разработчикам о том, как установить признак vlan в VM и сообщить им, какие признаки vlan будут разрешены на их порте выключателя. Я также видел, что это провело в жизнь просто как стратегический указ, а не через технические меры.

И, конечно, это совпадает с предоставлением разработчикам с машинами, достаточно мощными, чтобы управлять многократным VMs когда-то.

66
добавлено
Это походит на хорошее решение - очень хорошее решение - но я don' у t есть достаточно администратора-foo Windows, чтобы знать, прокладывает ли это на самом деле себе путь (определенные привилегии или права прясть VMs, не имея общего местного администратора privs) - так IMO, этот ответ мог быть очень улучшен со связями с некоторыми пунктами/или бумаг/поваренной книги документации / белыми пунктами/или бумаг/поваренной книги, таким образом, которые подтверждают это.
добавлено автор Grant Collins, источник
Да, большая связь! Бен Армстронг - парень, чтобы пойти в! Плюс деталь о материале VLAN.
добавлено автор Grant Collins, источник
VMs также предоставляют другие преимущества для разработчиков. Один физический компьютер может принять несколько VMs, управляя различными версиями ОС или версиями программного обеспечения при тесте. Поскольку они доступны, легче повторить тесты, возвращаясь к выбранной контрольной точке.
добавлено автор Raedwald, источник
@davidbak Лучше?
добавлено автор Phonon, источник
@davidbak I' ve работал над машиной с гиперщитком (VirtualBox), установленный, не имея прав администратора
добавлено автор Naoise Golden, источник

Я работаю на довольно крупную фирму по управлению инвестициями (~6000 сотрудников), и разработчики - одна из групп, что мы одобряем для местного доступа администратора. Мы говорим им не устанавливать любое программное обеспечение, поскольку это обработано местным соблюдением рабочего стола/программного обеспечения.

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

44
добавлено
@Steve - к сожалению, это - так же ошибочно чрезвычайное представление как это, вы добираетесь от некоторых чрезвычайных людей безопасности. It' s не параноидальный, чтобы защитить организации от угрозы посвященного лица. На самом деле для многих это - самая большая угроза их существованию.
добавлено автор Rory Alsop, источник
@TomK. Это отвечает на фактический вопрос, который является, "Почему моя организация делает мою жизнь очень, очень трудно, на по-видимому никаком серьезном основании, и что я могу делать с этим?". OP ясно пытается соответствовать этому (вполне откровенно причудливый и параноидальный) практика в его мировоззрение. Люди пытаются указать, как их организации уравновесили параноидальные специалисты по безопасности реальными потребностями Разработчиков.
добавлено автор Steve Sether, источник
Это не отвечает на вопрос. Это не дает объяснения, если или почему это было бы "типично".
добавлено автор Sean, источник

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

If we had not local admin access, we would try all sorts of bad "solutions" which, as in your case, leads to less security. This is one of those cases, that restrictions actually lead to the opposite of their intention.

27
добавлено
@TomK. There' s никакой способ знать, что типично за исключением некоторого обзора, таким образом отвечая что часть вопроса isn' t собирающийся происходить.
добавлено автор Obviously_Anon, источник
@TomK. Те обзоры или исследования, если бы они даже существуют, были бы барахлом. Как вы сказали, itd просто быть коллекцией того, что могло бы быть "типичным" и просто потому что что-то - типичный doesn' t означают, что это - правильный способ пойти.
добавлено автор Obviously_Anon, источник
Это не отвечает на вопрос. Это не дает объяснения, если или почему это было бы "типично".
добавлено автор Sean, источник
@PeterA.Schneider: Правильный, как правило никакой единственный человек не может канонически ответить на глобальный вопрос как это только с его/ее события . Но к счастью есть такие вещи, названные "методами наиболее успешной практики", которые записаны и открываются к исследованию. Другие возможности - исследования или статьи. Просто говоря "Для меня, it' s как это" недостаточно.
добавлено автор Sean, источник
Правильный @Andy. Эти обзоры или исследования сделаны учеными или часто времена консультантами, которые развиваются - как я упомянул - методы наиболее успешной практики. Цитирование этих методов наиболее успешной практики или исследований составило бы действительный ответ.
добавлено автор Sean, источник
@TomK. Это отвечает на вопрос частично. у , Если 10 человек из 10 говорят "Меня всегда, были права администратора" тогда вместе , который является ответом. Никакой единственный человек не может канонически ответить на глобальный вопрос как это; каждый единственный ответ в известной степени анекдотичен, "точка данных", как Джо назвал его. (Джо также утверждал, что "Я знаю, что это распространено в другом origanisations", будучи не в состоянии добавить, "о котором я знаю".)
добавлено автор Bobas_Pett, источник

В довольно небольшом отделе более крупной организации (~100 в отделе, ~3500 в полной организации) мы выбрали в середине решение:

    у системных администраторов <�лития> было 2 счета, один (не администратор даже для местной машины), который использовался для не administative задачи (почта, выпуск документа, и т.д.) и один с администратором н. э. priviledges, который, как предполагалось, только использовался для администрации н. э.
  • все другие пользователи был только один единственный не счет администратора
  • <�литию> devs (и некоторые продвинутые пользователи ) предоставили местный счет с местными машинными правами администратора. Это, как предполагалось, редко использовалось, когда местные органы власти требовались.

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

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

Выберите свое собственное, если вы промежуточные...

27
добавлено
Соображения: сколько доступа в Интернет для счета н. э. На моем рабочем месте у моего н. э. нет фактически доступа в Интернет (Исключенные обновления Visual Studio). Я должен использовать свой регулярный счет на Интернет/загрузку/и т.д.
добавлено автор julionc, источник
У нас была встреча сегодня с нашей командой IT относительно этого и I' m склоняющийся к маркировке этого ответа, как отвечено просто, потому что это - решение, они предстали перед нами.
добавлено автор David, источник
Да, мы сделали это также. Хотя наш администратор н. э. считает, также имел местные административные привилегии на каждой машине (который был частью области/объявления).
добавлено автор Sami Liedes, источник

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

Какая угроза вашей сети усугублена местными правами администратора?

К которому ответ shoud быть: НИ ОДИН - доступ к ресурсам в вашей сети должен быть ограничен на за пользовательское основание, абсолютно не связанное с фактом, если у этого пользователя есть местный корень, администратор или masterOfTheUniverse доступ на его машине. Если пользователь имеет права взорвать вашу сеть, местному вирусу даже не нужен доступ администратора, это может просто использовать учетную запись пользователя, чтобы взорвать вашу сеть. - И если учетная запись пользователя не может получить доступ к чему-то в вашей сети, местные права администратора ничего не изменят об этом.

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

Addendum: You should grant your developers the possibility to use local-admin rights whenever they need to. This doesn't mean they should be logged in with an unsecured admin-account all the time, but you should trust them to use it sensibly whenever they need it - without asking for permission every time.

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

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

Сначала есть выгода более высокой производительности, потому что разработчик может просто формировать, установить и проверить все, что он должен на его местной машине. Ему, возможно, понадобится определенное программное обеспечение, инструменты помощника или необычные конфигурации, чтобы экспериментировать с определенными аспектами его программного обеспечения (например, управляют его программным обеспечением на более старой версии OS или с более старым drivers/SDK).

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

16
добавлено
@Downvoter хотят прокомментировать, как мой ответ мог быть улучшен, или почему вы думаете, что это абсолютно неправильно?
добавлено автор Tim Jansen, источник
@JamesSnell I' m крупный защитник защиты подробно, но меня просто don' t видят, что местный ограниченный счет обеспечивает что-либо стоимости, кроме локального оборудования. К чему-либо бизнес-ценности можно получить доступ с пользовательскими правами xkcd.com/1200
добавлено автор Tim Jansen, источник
Защита подробно для меня включает зашифрованный жесткий диск, сильный пароль на местном счете, безопасном аппаратном модуле... Но ограничение права локального пользователя на ноутбук отдельного пользователя - просто театр безопасности
добавлено автор Tim Jansen, источник
@JamesSnell, как машина защищена? Нападавшего с пользовательскими правами на машине достаточно, чтобы пойти в наступление полного масштаба на вашу сеть. Ноутбук может уже быть зараженным хозяином без любого доступа администратора.
добавлено автор Tim Jansen, источник
@JamesSnell иронически IDE, который они могли установить без местных прав администратора;-), Но я вижу ваш пункт: Да это расширяет поверхность потенциальной атаки, но только маленьким полем. И если ваши разработчики don' t получают местного администратора и загружают некоторые "инструменты помощника", чтобы работать вокруг этого, у вас, вероятно, есть еще больше поверхности атаки. - Я хотел бы видеть обзор, если разработчики используют свою машину, более ответственную, если им доверяют ответственность вместо подозревавшего.
добавлено автор Tim Jansen, источник
@JamesSnell, Как может каждый разработчик так добровольно, если вы доверяете ему. Местный администратор не подразумевает, что "корень использования все время", но "может использовать корень необходимых"
добавлено автор Tim Jansen, источник
Возможно, я должен отредактировать свой ответ, чтобы установить это ясное - я думаю, что разработчики должны обычно использовать обеспеченный счет, но иметь выбор позволить местному администратору при необходимости без потребности заполнить форму и попросить разрешение. И я доверяю их, чтобы использовать эту разумную привилегию и экономно
добавлено автор Tim Jansen, источник
Короче говоря, этот ответ нарушает принцип наименьшего-количества-привилегии и целое понятие защиты подробно. Причина ограничения местного администратора состоит в том, чтобы помочь смягчить нападения, которые действительно проходят, и хороший devs поймет это. Где there' s доказуемая потребность тогда it' s различный ballgame, часто это может быть встречено отдельным местным счетом администратора так, чтобы использование поднятых привилегий было временным; но OP говорит they' веб-разработчики ре, таким образом, должно быть очень мало потребности в местных правах администратора. Посмотрите security.stackexchange.com/a/190182/17321
добавлено автор Martin Spamer, источник
@Falco - дело в том, что машине препятствуют использоваться в качестве платформы идти в дальнейшее наступление... читает связанный вопрос.
добавлено автор Martin Spamer, источник
@Falco - это уменьшает поверхность атаки, разве вы не прочитали связанный ответ? Плюс... theregister.co.uk/2018/07/25/developers_malware_vectors
добавлено автор Martin Spamer, источник
@Falco - it' s не проблема доверия. Я управляю своими собственными системами этот путь. Я ограничиваю свои собственные права когда я don' t нужны они.
добавлено автор Martin Spamer, источник
@JamesSnell Visual Studio нужны местные права администратора, который является (imo) большой причиной, поскольку развивающийся без Visual Studio просто не происходит. Не не соглашаясь с остальной частью вашего комментария, просто потребность в местных правах администратора.
добавлено автор user180588, источник

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

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

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

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

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

Вы не делаете развития против своих производственных активов так или иначе, правильно?

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

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

Есть много способов осуществить отдельную среду разработки:

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

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

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

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

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

Вы don' t нужен огромный и полужирный текст, чтобы прочитать ваш ответ или ваш пункт через.

добавлено автор Luc, источник
Вместо того, чтобы писать мой собственный ответ, я хочу положиться на этого. На моей работе мы различаем: 1) Серверы разработки, 2) Другое непроизводство (обеспечение качества, TST и т.д.) серверы, и 3) Производство. У разработчиков может быть доступ администратора, чтобы сделать техническую разработку, но they' ре ожидало упаковывать их код и другие активы и давать их нам, чтобы развернуться в другой окружающей среде ненапоминания, наряду со всей документацией о любых изменениях OS, которые должны быть сделаны. Я don' t даже хочу их на тех системах группы 2, вводящих различия от Напоминания, которое побеждает цель группы 2.
добавлено автор KS.Pan, источник
Это - правильный ответ. Разработчики должны иметь доступ администратора к своим рабочим станциям развития, но не должны иметь доступа к производственным системам, dbs с уязвимыми данными и т.д. от тех рабочих станций.
добавлено автор Galaxy, источник

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

Если местный доступ администратора <�силен> необходимый для человека (будьте им подрядчик или сотрудник), тогда это - обязательство службы безопасности/человек - кто бы ни отвечает за ту конкретную область - чтобы найти решение. Есть разнообразные решения: создавая изолированный VLAN, виртуальные машины и других назвали здесь.

Не имеет никакого смысла спрашивать после установки других организаций только, чтобы услышать, что "у нас также есть права администратора на наших машинах". Вы не найдете инфраструктуру, которая является точно </ими> то же самое как ваш. Единственная вещь, которая вопросы, что служба безопасности/человек планирует безопасное решение, которое тогда осуществляется IT deparment в этот конкретный организация.

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

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

10
добавлено
There' s различие между не ответом на вопрос и предоставлением другой точки зрения или попыткой показать OP проблему в другом свете.
добавлено автор Sean, источник
Во всей действительности, так как вы заметили относительно Marcel' s ответ: кажется, что ваш , ответ не отвечает на вопрос и на самом деле явно отказывается делать так. Если вы хотите поощрить OP спрашивать различный, более актуальный вопрос, рассмотрите выполнение этого в комментарии.
добавлено автор Bobas_Pett, источник

Это существенно зависит от контекста, и в особенности от вашей модели угрозы.

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

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

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

7
добавлено

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

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

Вот то, что не понимают аргументы: нарушение личных счетов разработчика не является стартовой точкой; это - джекпот. Нет никакой причины пойти для администратора оттуда. У breacher есть возможность изменить codebade, чтобы вставить черные ходы. Извлекающий пользу администратор на коробке разработчика не то, что намного более интересен.

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

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

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

Намного более мудро просто дать devs местному администратору на одной коробке, связанной с Интернетом и с местной областью и готовым иметь дело с тем, чем могут быть последствия. Защитите производство вместо этого. Есть меньше людей, которые должны получать доступ к производству на высоком уровне привилегии, поэтому строгая изоляция легче, и компетентные организации учатся делать это.

Но внезапно устранение администратора как это почти всегда приводит к потере более важного devs. Вы не хотите это.

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

6
добавлено

Я видел два подхода та работа.

  1. Дает доступ администратора разработчиков к их машинам. Это - самый легкий и наиболее распространенный подход. Это обычно - лучший выбор
  2. Создает команду в организации, целый Джоб которой должен гарантировать, что разработчики могут работать без доступа администратора. Эта команда обычно будет 3-4 людьми. Вы найдете, что требования к аппаратным средствам разработчика увеличиваются существенно, поскольку вы будете использовать контейнеры и или VMs, так бюджет для покупки новых аппаратных средств для всех разработчиков. Когда вы выкатите, начните с команды ранних последователей, тогда постепенно перемещайте всех своих разработчиков к машине без доступа администратора. Этот процесс займет по крайней мере шесть месяцев.

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

5
добавлено
It' s абсолютно неблагоразумный для любых средств разработки нуждаться в любом виде доступа администратора. Независимо от того, что они думают, что им нужен он для, команда IT, ответственная за подготовку и поддержание developers' коробки должны быть в состоянии повторно формировать программное обеспечение или виртуализировать надлежащие интерфейсы так, чтобы инструменты работали, не ставя под угрозу безопасность инфраструктуры.
добавлено автор Mike Caron, источник
@UEFI: Вместо этого you' ll просто должны нанять людей к машинам разработчиков переизображения каждый раз, они устанавливают вирусы и соглашение со всем потерянным временем разработки и возможной потерей активов... Ре: отладка, конечно должна быть конфигурируемая политика позволить пользователям неадминистратора отлаживать свои собственные процессы .
добавлено автор Mike Caron, источник
@UEFI: Нет, потому что JS - вложенный язык, который не бежит в области привилегии вашей учетной записи пользователя. Это бежит в сложной области привилегии, осуществленной браузером. It' s верный, что под уязвимостью спасения песочницы в браузере, был бы вектор для отладки других процессов (но уже есть лучшие векторы для нападения на вас в случае спасения песочницы). По сути, для укрепления it' s полезный для отладчика - прилагают политику быть конфигурируемым и прочь для пользователей, у которых нет интереса к использованию его. Но it' s не существенный аспект любой модели привилегии.
добавлено автор Mike Caron, источник
3-4 человека, полный рабочий день?! That' s много денег, что я думаю, мог быть потрачен лучше. И вы могли бы хотеть уточнить то, почему вы думаете, давая devs, разрешения администратора лучший выбор.
добавлено автор Luc, источник
@Luc Много средств разработки полагаются в большой степени на привилегии локального администратора. Visual Studio MS, например, doesn' t нужны все местные административные привилегии бежать правильно, но нуждается в определенных административных привилегиях. DEBUG_SE для отладки, сервисное управление для - хорошо - руководящие услуги, Создают права для баз данных, и я мог продолжить целую вечность. Теперь обнаруживая, почему разработчик isn' t, способный к управлению сценарием базы данных, отладке применения или установке обслуживания, может быть чрезвычайно отнимающим много времени, и это - или время упомянутого разработчика, или время специального персонала.
добавлено автор Jeff, источник
@R.. Я регулярно запускаю программу, затем прилагаю отладчик к той программе так, чтобы я мог прочитать it' s внутреннее состояние, пауза it' s выполнение и заставляют его выполнить произвольный код. Это требует доступа администратора. Моя производительность понизится, если вы запретите мне делать это.
добавлено автор jagsler, источник
@Luc It' s лучше, чтобы дать devs доступ администратора, потому что it' s более дешевый. Это означает вас won' t должны нанять 3-4 человек полный рабочий день, чтобы держать developer' s машинная работа и жалоба с вашей политикой безопасности.
добавлено автор jagsler, источник
@R.. Так мой веб-браузер бегущий JavaScript должен способным, чтобы получить доступ к внутреннему состоянию другой программы на моей системе, такой как мой менеджер паролей? Я не вижу проблем безопасности с этим....
добавлено автор jagsler, источник
@R вы могли бы хотеть читать на ' devops' you' ll находят, что у современных дневных разработчиков есть очень разумные побуждения для желания доступа администратора. Для меня лично, не имея контроля над моей машиной огромный красный флаг. Если сказали заранее, I' ll отклоняют ваше предложение работы, в противном случае мои первые две недели будут моим последним.
добавлено автор Douwe, источник

Да и нет - наши старшие devs действительно сделали, чтобы отдельный администратор считал, который разрешает им поднимать при необходимости и устанавливать заявления/обновления. Их не разрешают к логину к компьютеру со счетом все же. Их счет администратора также разрешает им доступ администратора к обычным dev компьютерам, чтобы оказать более быструю поддержку, чем прохождение команды IT.

Это все объединено с белым применением/черный список, политика сильного пароля, запрет на съемное устройство, полномочия ворот, политика DLP, строгие правила AV и больше. Их машины обычно ревизуются, и видимость команды IT высока.

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

4
добавлено
Это не отвечает на вопрос. Это не дает объяснения, если или почему это было бы "типично".
добавлено автор Sean, источник

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

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

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

Это - процедура:

  • , Открытый территория компании
  • Считает раздел с некоторыми модулями готовым быть заполненным в
  • Находит и загружает документ, названный "Лист Выпуска"
  • Печать это
  • Заполняет его с вашим запросом и подписывает его
  • Раздает его секретарю
  • секретарь возьмет все эти запросы менеджеру утром следующего дня
  • Рано или поздно менеджер подпишет его
  • секретарь возвратит его вам
  • В этом пункте можно просмотреть его
  • , Открытый сайт, использованный IT, чтобы обращаться с билетами
  • Создает билет, описывающий (снова), в чем вы нуждаетесь и прилагаете просмотренный Лист Выпуска. Не забывайте устанавливать безотлагательность с одного часа до двух недель.
  • В конечном счете IT сделает это (надо надеяться)

On average, it would take 3-4 days to get it done. In some cases, weeks. Really efficient, eh? Hey, you asked for access to a certain folder but forgot to mention the subfolder? HA! You've won another round! And, guess what? Since they were following some QA process, they were organizing documents in a lot of different folders. When a new colleague came, he could easily spend weeks trying to get all the permissions he needed.

Теперь.

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

Так, к чему это приближалось к лидерству? Это, если вы хотели украсть все компания, когда-нибудь сделанная, вы просто, должно было ввести Карту памяти и соединить ее с вашим PC. Никакой доступ к той папке "Confidential_Documents"? Просто попросите его, они подпишут его. И если это срочно? "Привет, мне нужен тот документ, но я не могу получить доступ к нему, можно ли дать мне пароль?"

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

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

4
добавлено

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

Вещью, которую придумало управление, были две виртуальных машины подход.

Одна из наших виртуальных машин была основным бизнесом машина с электронной почтой, веб-Доступом и Microsoft Suite. Это удовлетворило потребность общаться.

Другая виртуальная машина имела местные права администратора , но была разъединенный от Интернета полностью . Тем путем мы ничего не могли загрузить на той машине. (Хотя мы могли все еще загрузить его с другой и скопировать загрузку..) Мы все еще получили доступ к внутренним местам и добавили несколько вещей в белый список использование Visual Studio (Nuget, Символы, и т.д.)

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

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

3
добавлено

Short answer: Yes, it is common to have local admin access to selected groups, such as developers or IT admins. Basically, people whose day job is a lot easier with admin access while the usual office worker would need it at most once a month and typically much less than that.

Long answer: It depends...

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

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

That doesn't necessarily mean that they are wrong. A full analysis could very well lead to the same conclusion.

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

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

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

3
добавлено

Мы решили эту проблему при помощи <�сильной> Виртуальной машины .

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

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

3
добавлено
Let' s просто принимают потребности OP (Местные) Административные привилегии управлять средой разработки. Вышеупомянутый Microsoft Visual Studio и Студия управления SQL, например, полагаются в большой степени на Административные привилегии. Другая вещь те, которые программное обеспечение полагается в большой степени (с точки зрения обновлений, помощи онлайн, управление исходным кодом и я могли продолжить целую вечность) являются Интернетом связь. Наличие VM без Подключения к Интернету, но обеспечение (Местных) прав администратора означает переключать скалу с твердым местом.
добавлено автор Jeff, источник

Несмотря на MS WINDOWS NT, которых был многопользовательской системной системой начиная с ее начала, ее не действительно простой в эксплуатации это таким способом и разработчиками (включая Микозофта) все еще имеет тенденцию игнорировать идею разделения привилегии. Этот вид управления доступом плохо зарегистрирован, имеет тенденцию не показывать в обучении, часто трудном к доступу через UI, трудно ревизовать, отсутствие образцов/инструментов для применения разделения....

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

С другой стороны, в то время как я знаю мало о развитии на MS Windows, я действительно нахожу, что это удивляющий ту местную административную привилегию требуется, чтобы управлять Visual Studio. И если единственная причина, вам нужен доступ администратора, для остановка/старт услуг или повторно формируя их тогда у меня нет большого сочувствия к вам - возможным предоставить эту услугу обозначенным пользователям, не давая им местного администратора. Одно из больших изменений в IIS7 было делегированный администратор способность. И его всегда легкий делегировать переконфигурацию апача, MySQL и PHP.

было короткое уведомление о том, когда местный доступ администратора был удален

Это кажется, что проблема - Служба безопасности, стремящаяся к уровню компетентности, которую они неспособны обеспечить (это, в моем опыте, является очень </ими> распространенный). Они не должны были налагать изменение политики, не делая надлежащей оценки воздействия и рассматривая смягчение для любого вреда производительности/безопасности.

У нас есть по крайней мере 2 главных антивирусных программы на всех рабочих станциях

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

кажется, нет очень для альтернатив там

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

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

2
добавлено
.... и затем я помнил, почему я стараюсь не делать любое программирование на Microsoft Windows:)
добавлено автор bpapa, источник
Фактически неправильный. Visual Studio будет бежать без местных административных привилегий, и на самом деле that' s дефолт . И если вы назначаете привилегии отладки счетам разработчика, который означает, что Visual Studio не должна будет поднимать до разрешений администратора настолько часто. Действительно ли это совершенно преодолимо? Нет, разработчикам водителя абсолютно будет нужен доступ администратора, например.
добавлено автор Martin Marconcini, источник
Одна причина Visual Studio, которую эти права администратора должны позволить отладить процессов, принадлежавших другим пользователям IIS традиционно, бежит под системным счетом. Как только отладка разработчика, которую другой процесс, они могли отключить антивирусные проверки и т.д. головы, удаленные в 90%, замедляет, который весьма распространен от них. Следовательно выбор между не разрешением разработчикам использовать отладчик и доверие к разработчикам.....
добавлено автор Gowri, источник
@mg30rg: DEBUG_SE на самом деле означает, "Отлаживают кого-то else' s процесс".
добавлено автор Joshua, источник
@mg30rg: Правда, однако если разработчик работает над кодом, который обычно бежит как администратор, тогда у него есть администратор так или иначе.
добавлено автор Joshua, источник
@mg30rg: Obsoleted пустельгой. Теперь это бежит под developer' s имя.
добавлено автор Joshua, источник
Visual Studio будет , которым управляют без административных привилегий, но в некоторых случаях этого won' t пробег правильно без административных привилегий. Да, это doesn' t нужны все местные административные привилегии бежать правильно, но нуждается в определенных административных привилегиях. DEBUG_SE для отладки, сервисное управление для - хорошо - руководящие услуги, Создают права для баз данных, и я мог продолжить целую вечность. Конечно, можно было связаться со службой безопасности и потребовать определенных прав, в которых каждый нуждается на - let' s говорят - ежедневное основание, но делают вы знаете как it' s названный? Убийство производительности.
добавлено автор Jeff, источник
@Joshua И что делает вас, думают, требуется, чтобы отлаживать обслуживание окон, бегущее под Системным счетом, например? Этот сценарий совсем не необычен в развитии Windows.
добавлено автор Jeff, источник
M-ключ @Joshua, и что относительно развития ASP.Net? Для этого необходимо ли отладить процесс, начатый и бегущий под обслуживанием IIS, бегущим под счетом сетевой службы?
добавлено автор Jeff, источник
Пустельга @Joshua - едва IIS.
добавлено автор Jeff, источник

Выделяйте свои сети

У вас должны быть относительно изолированные среды для развития, тестирования, производства и бизнеса. Это позволяет вашему devs иметь привилегии, где им нужны они.

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

Что происходит где?

Развитие

The Развитие network is where coding takes places. Developers should have administrative rights in case they want to test code snippets or run something without packaging it for deployment to test/prod.

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

Тестирование

The Тестирование network is where compiled, ready-to-ship code is tested. Developers may have admin rights, but regular system admins should be deploying applications.

Deployments should reflect what the admins will maintain in Производство for internal apps. They should be customer-ready packages for external apps (including install wizard and digital signatures, albeit using a separate signature for Тестирование purposes to prevent accident releases).

Developers often need system logs and debug access, and these are the only reasons they should have admin rights. They should not be involved with installation, configuration, and Тестирование unless absolutely necessary.

Производство

The Производство network is where you provide services to clients and partners. Since a formal deployment process should exist, there is no reason for it to connect to your dev/test networks.

To minimize risks of internet-borne malware and accidental changes, accounts from the dev/test/Бизнес networks should have no access to Производство if possible, which translates to limited permissions with occasional arguments in practice.

Ideally, this network would be completely isolated, but in practice this is impossible in a world where Производство servers must interface with systems for sales, billing, scheduling, netops, and project management. Get as close to the ideal as you can; it's really all we can do.

Бизнес

Это - основная система коммуникаций для предприятия.

Email, web browsing, and partner connectivity all bring a host of risks. Your Развитие, Тестирование, and Производство networks should be isolated from these risks to the maximum extent possible.

Детали, детали, детали

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

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

  1. Там - отдельные, непривилегированные счета на доступ в Интернет
  2. Уникальные счета используется в каждой окружающей среде
  3. Строгий брандмауэр rules/ACLs существует между окружающей средой
  4. меры по Стандартной защите, такие как брандмауэр, веб-полномочие, ИДЫ/IPS, и т.д. существует

Вашим разработчикам будут нужны четыре счета:

  • Unprivileged dev account to access resources on the internet (if they do not want to hop back and forth from the Бизнес network, which is onerous)
  • Privileged dev account to configure workstation and test code
  • Privileged test account to debug applications
  • Unprivileged Бизнес account for email, web, intranet

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

Developers should have no access to the Производство network and no administrative privileges on the Бизнес network. If this impossible for the moment, then those roles should be separated or else a rigorous change control process should be put in place.

2
добавлено

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

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

0
добавлено
Про Windows
Про Windows
941 участник(ов)

Microsoft Windows и всё, что с этим связано. Список интересных групп и каналов: https://github.com/goq/telegram-list

Microsoft Developer Community Chat
Microsoft Developer Community Chat
584 участник(ов)

Чат для разработчиков и системных администраторов Microsoft Developer Community. __________ Новостной канал: @msdevru __________ Баним за: оскорбления, мат, рекламу, флуд, флейм, спам, NSFW контент, а также большое количество оффтоп тем. @banofbot