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


19

Працюючи розробником і в ІТ-адміністраторі / підтримці команди розробників, я стикався з багатьма різними типами середовища від повністю замкненого до абсолютно не. В моєму обмеженому досвіді підтримки я думаю, що було менше зусиль для підтримки з менш заблокованою машиною, і я, звичайно, відчував це легше, але, звичайно, це може бути упередженим. Мені хотілося б знати, що таке погляд з точки зору підтримки ІТ, чи справді важче підтримати розробників, які не мають закритих машин?


10
Враховуючи великий сегмент програміста у сукупності серверних помилок із переповнення стека, я вважаю, що це страждає від упередженості вибору. Який розробник справді скаже: "Закрий мене, будь ласка!"?
romandas

Відповіді:


11

Найбільшою проблемою, що не блокувати машину розробників, є те, що будь-яке програмне забезпечення, яке вони розробляють, потребуватиме повних прав адміністратора для запуску. Доступ для розробників повинен бути таким самим, як і середовище, в якому їм потрібно буде запустити. Якщо їм потрібно бути "самопідтримуваними" або "самовстановлюваними", то надайте їм інший обліковий запис адміністратора, наприклад Bruce.admin, який вони повинні використовувати при виконанні адміністратора речі, але не використовуються день у день.

Так само, як жоден гідний адміністратор UNIX, який не коштує своєї солі, ніколи не використовуватиме кореневий обліковий запис для своєї щоденної роботи без адмін.


14
Я ображаюся на "вимагатимуть". Ви робите це звуком як попередньо зроблений висновок, що розробники, природно, зроблять неправильну справу. Хоча я погоджуюся, що розробляти програмне забезпечення, яке працює лише з надмірно високими привілеями, є менш бажаним, я не думаю, що ІТ слід намагатись застосовувати конкретні практики розробки за допомогою жорстких заходів, таких як блокування машини. Якщо ІТ є зацікавленою стороною в процесі визначення вимог до додатків - і це повинно бути для внутрішніх додатків - тоді зробіть це вимогою розробленою та тестованою, щоб програми працювали з меншими привілеями.
Кріс В. Реа

Але я думаю, що ідея окремого рахунку має заслугу. Але не змушуйте мене, це все.
Кріс В. Реа

4
У Windows краще робити це навпаки. Створіть тестові акаунти, які поводяться з дозволами звичайного користувача. Програми можна перевірити, увійшовши до машини (або VM) як облікового запису тестового користувача.
ЗанепокоєнийOfTunbridgeWells

3
Я сформував думку "зажадаю" на основі 15-річного досвіду технічного тестування. Звичайно, є винятки, але більшість програм у Windows не розроблені для найменшої привабливості, і це не тому, що розробники, природно, роблять неправильну справу, це тому, що це справді важко зробити.
Брюс МакЛейд,

1
використовуючи як декілька тисяч різних додатків, лише 5% з них потребували прав адміністратора без реальних причин.
Mircea Chirea

55

Більшість розробників технічно підковані і знають, що вони роблять. Їм часто потрібно встановлювати багато спеціалізованих додатків, тому потрібно отримати дозвіл на це, і змусити ІТ знизитись та додати, що може бути дуже неприємно, особливо у великих компаніях, для обох сторін.

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

Блокувати когось у бухгалтерському обліку, щоб використовувати лише IE та відкрите слово, це добре, але якщо ваш розробник, якому потрібно встановити 4 різні типи браузера та потрібно швидко встановити додаток, щоб вирішити проблему, це може прикро.

Мій досвід полягає в тому, що компанії, які мають багато технічних знань, тому магазини розвитку, ІТ-постачальники тощо, які довіряють своїм працівникам і дозволяють їм вирішити, що вони хочуть встановити, набагато щасливіші і менше турбують ІТ


10
Якби я міг проголосувати за цю відповідь кілька разів, я би. Я розробник і згоден 110%. +1
Кріс В. Реа

1
@ cwrea: Що може бути надлишком 10%?
сетзамора

3
Я згоден, але компанії, які дуже суворо ставляться до інформаційної безпеки, ніколи не дозволять встановлювати додатки, які не відповідають "компаніям стандартам"
setzamora

Щойно забравши мої адміністраторські права, я кожні півгодини надсилаю електронну пошту, щоб отримати це чи інше, або змінити це налаштування чи це налаштування. Загальною темою для перевірки дат розгортання було подвійне клацання часу в області сповіщень. Щось, для чого я зараз "не маю належного рівня привілеїв" для ... Це зводить мене з глузду!

1
Хоча кажуть, що "якщо ви його видалите, це не підтримується", це все добре і добре, практично це перетворюється на розробника, який скаржиться своєму начальникові, що програмне забезпечення xyz не працює, і Система / Служба підтримки не допоможе мені. Бос збивається однолітком, і наступне, що ви знаєте, менеджер / директор / ВП дихає шиєю когось, не піклуючись про те, що це не підтримується, просто виправте це зараз. Тепер Системи / Helpdesk має підтримувати випадкову програму xyz для розробника a та випадкову програму abc для розробника b. Якщо вам це справді потрібно, поставте його через канали.
Zypher

14

Дивіться цю публікацію в Stackoverflow для дещо бурхливої дискусії про достоїнства блокування машин розробників. (Відмова: Я написав прийняту відповідь).

З точки зору sysadmin, доступ до виробничих систем є чутливим, і ви повинні обмежувати такий доступ людям, які потребують його для виконання своєї роботи (сюди можуть входити розробники, які мають обов'язки щодо підтримки рівня 3 для програми). Права місцевого адміністратора на ПК для розробки або сервер розробки не суттєво ставлять під загрозу безпеку ваших виробничих систем.

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

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

Ще одне місце, де розробникам, як правило, потрібна велика робота адміністратора, є сервери баз даних, що розміщують середовища розробки. Більшість розробників здатні легко засвоїти рутинні завдання DBA і так чи інакше повинні отримати знання про це (принципово IMHO). Надмірно обмежувальні правила доступу адміністратора на серверах розробки можуть підніматись багатьма способами.

Мережа розроблення подряпин - це дуже гарна ідея, якщо її можна впорядкувати - ви можете брандмауер це зробити з виробничих серверів, якщо це необхідно.

  • Коли розробники можуть легко копіювати структуру виробничого середовища, це сприяє культурі тестування розгортання, де тест на інтеграцію можна синтезувати, не перестрибуючи обручі. Це сприятиме покращенню якості випуску та розгортання продукції.

  • Можливість імітувати виробниче середовище також підвищує обізнаність щодо розгортання виробництва та питань підтримки. Це заохочує співробітників розробників думати про те, як програма може підтримуватися у виробництві, що, ймовірно, заохочуватиме архітектури, побудовані з урахуванням цього.

  • Якщо в цій мережі є контролер домену, ви можете встановити довірчі відносини, щоб вона довіряла вашому головному контролеру домену та його обліковим записам. Ці довірчі відносини не повинні бути взаємними, тому це не загрожує безпеці інфраструктури вашої виробничої мережі. Це може надавати вам ненадійну мережу розвитку, але все ж дозволяти розробникам доступ до автентифікованих доменних ресурсів, таких як облікові записи Exchange або файлові сервери.

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

Додам, що це набагато менше проблем у середовищі unix або linux; користувачі можуть досить сильно налаштувати власне середовище зі свого .profile. Ви можете складати та встановлювати речі у власному /home/bloggsj/binкаталозі на радість вашому серцю. "Локальні права адміністратора" - це здебільшого проблема Windows, хоча все ще є кілька речей, яким потрібен кореневий доступ під Unix.


Я хотів прокоментувати вашу останню точку кулі. Ви згадуєте "політичні перешкоди" - майте на увазі, що первісний намір практик безпеки - це будь-що, крім політичного. Пізніше це може перетворитись на щось інше, тому що всі орги врешті-решт набувають людей, які слідують письму, але не за наміром цього правила, а ще гірше, перетворюють колись шляхетну політику у феодності. Але хороша безпека та хороша політика МОЖУТЕ йти рука об руку. Однак для цього потрібні добросовісні зусилля.
quux

Як правило, розумно керована політика не породжує такого типу політичної перешкоди або, принаймні, не зробить її непереборною. Однак ІТ-політика, як правило, розробляється по кожному інциденту і не завжди є "розумним"
ConcernedOfTunbridgeWells

8

Найрозумніший варіант, який я коли-небудь бачив (був з обох сторін - і досі є) - це просто розблоковані речі і також непідтримувані . Дайте їм свободу, і якщо вони закрутяться, все, що вони можуть отримати, - це перезавантаження зі стандартним зображенням. У цій ситуації мені здається гарним планом розмістити їх у якійсь формі "ненадійної" мережі.

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


2
Я отримую приблизно 20 хвилин підтримки тоді пропозицію нового зображення. Добре працює для нас.
Преет Сангха

6

Відповідь насправді: немає простого відповіді так чи ні. Але безпека як мінімум важлива для ваших розробників, як і для всіх інших.

З одного боку, так, дияволи, як правило, технічно більш кмітливі. З іншого боку, їхня робота часто є напруженою роботою, і їхні основні етапи розвитку, ймовірно, матимуть перевагу над додатковим доглядом, необхідним для підтримки власної системи як безпечного середовища. Це не критика розробників; це чесне врахування їх щоденних обов'язків.

Якщо ви збираєтеся надати розробникам повний, безперебійний доступ до їхніх систем, то вам слід дійсно розглянути наступні додаткові заходи:

  • Забезпечте іншу систему, заблоковану стільки, скільки звичайні користувацькі системи заблоковані, для нормального використання не для розробників.
    • Покладіть свої повнорозмірні верстати для розробників у спеціальну VLAN, що має доступ лише до ресурсів розробника.
  • Запитайте, що, якщо що-небудь не завадить зараженій системі загрожувати кодовій базі. Чи міг бэкдор-машину перевірити злоякісний код чи стерти базу коду в руках ворожого хакера? Вживайте відповідних заходів для зменшення цього ризику.
  • Аналогічно запитайте, що якщо що-небудь захищає бізнес-дані, що зберігаються в системах, до яких мають доступ розробники.
  • Регулярно проводите інвентаризацію програмного забезпечення та аудит безпеки систем розробників.
    • Отримайте уявлення про те, що вони працюють, і скористайтеся цією інформацією для створення зображень для перерозподілу системи розробок.
    • Рано чи пізно у вас з’явиться розвідник, який стає недбалим і встановлює речі, явно небезпечні або зовсім не пов'язані з роботою. Швидко надсилаючи попередження, коли це станеться, ви дасте спільноті розробників знати, що так, хтось дивиться, і вони несуть відповідальність дотримуватися розумних норм.
  • Ви регулярно скануєте шкідливі програми? У деяких випадках розробники справедливо скаржаться на податок на продуктивність, що стягується AV-системами під час доступу (ті АВ системи, які завжди увімкнено, завжди скануючи кожен доступ до файлів). Можливо, бажано перейти до стратегії нічного сканування та / або створити виключення файлів / папок для сканування під час доступу. Переконайтеся, що виключені файли скануються іншим способом.
    • Чи можуть ваші адміністратори з розробленими дисками вимкнути все сканування AV? Як би ви виявили та усунули це?

Якщо ви збираєтесь заблокувати системи розробників, то вам слід врахувати наступне:

  • Чи є у вас можливість підтримки швидко відповідати на їх запити? Розгляньте середню ставку оплати ваших розробників і запитайте, заслуговує чи ні, чи вони заслуговують на швидший час у відповідь на угоду. Це, мабуть, не має сенсу тримати ваші диски в розмірі 120 тис. Доларів (хто є ключем до багатомільйонного проекту), поки ви обробляєте технічну підтримку від співробітників 60 000 доларів на рік.
  • Чи є у вас чітка та однозначна політика щодо того, які запити про підтримку ви хочете, а не будете обслуговувати своїх розробників? Якщо вони починають отримувати відчуття , що підтримка є довільною, ви будете в кінцевому підсумку відчувати біль.

Так чи інакше, вам потрібно визнати, що розробники - це особливий випадок, і їм потрібна додаткова підтримка. Якщо ви не сплачуєте бюджет на це, проблеми, швидше за все, гнійні зараз ... або будуть у майбутньому.

Як зауваження, я бачив дуже схожі аргументи, що мають місце з систематинами. Щонайменше на двох різних роботах я бачив, як системні адміністратори доволі люто сперечаються, коли було висловлено припущення, що вони повинні самі заблокувати системи або принаймні використовувати два логіни (один з root / admin privs; один без). Багато сисадмінів вважали, що їх ні в якому разі не можна закривати, і наполегливо виступали проти таких заходів. Рано чи пізно у якогось адміністратора, що запобігає заблокуванню, виникне інцидент із безпекою, і приклад матиме навчальний вплив на всіх нас.

Я був одним із тих сисадмінів, які весь час бігали з адміністратором приват. Коли я вніс зміни в подвійні рахунки і лише підняв на потребу, я визнаю, що це було дуже неприємно протягом перших кількох місяців. Але срібна підкладка в хмарі полягала в тому, що я дізнався набагато більше про безпеку систем, якими я керував, коли мій звичайний обліковий запис жив під тими ж обмеженнями, які я розміщував на користувачів. Це зробило мене кращим адміністратором! Я підозрюю, що те саме стосується розробників. І, на щастя, у світі Windows зараз у нас є UAC, що полегшує запуск обмеженого користувача та піднімає його лише за потреби.

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

Давайте по-іншому. Якщо Марка Русиновича можна взяти за допомогою руткіта , будь-хто може!


3

Якщо у вас є декілька розробників, підхід надати їм сервери розробки - це можливість, але якщо у вас є цілий поверх розробників, я дуже проти дати їм будь-яких прав адміністратора.

Проблема полягає в тому, що ви закінчите цілий поверх розробників, кожен з яких робить те, що вони роблять, як правило, більшість людей навіть не захищені безпекою і просто хочуть, щоб їх програма працювала. Тоді вас звернеться із запитом - "Ми завершили етап розробки, будь ласка, скопіюйте наше середовище розробників на тест, попередній продаж і прода".

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

Я роблю політику досить просто:

  • Розробники НЕ отримують кореневого доступу ніколи для середовища розробки.
  • Розробники НЕ отримують кореневий доступ до VV-серверів, що розробляються VV, але НІ підтримують.
  • Розробники повинні або надавати пакети RPM, що належать до дистрибутиву ОС, на якому буде працювати їх додаток, АБО пакети RPM, які відповідають FHS та LSB.
  • Жодне їхнє застосування ні за яких обставин не може працювати як root
  • У користувача не буде доступу до suабо sudoкористувачу програми - що буде заблоковано, щоб не мати доступу до оболонки. (Це для обліку / аудиту).
  • Будь-які команди, які їм потрібно виконати з привілейованим доступом, повинні бути чітко запитані та затверджені - в цей час вони будуть додані до sudoersфайлу.
    • Жодна з цих команд / скриптів не буде написана ними.
    • Жоден скрипт (прямо чи опосередковано) посиланням на ці команди не буде написаний ними.

Наведене вище, перш за все, змусить їх замислитись над тим, що буде і чого не буде дозволено, коли настане час перенести проект на тестовий і вище сервер.


2

Блокування машин розробників вимагає більше зусиль, ніж варто. Це серйозно завдає шкоди продуктивності, оскільки без адміністративних прав ви не можете зробити майже нічого. Звичайно, з часом система заплутається, але, безумовно, ваш ІТ-деп не забезпечує підтримку всіх тих сторонніх інструментів, які використовуються в розробці?

Отже, як запропонував Вінсент Де Баєр, найкращим способом дій було б лише відновлення системи із образу, звичайно, після цього необхідно відновити середовище, але це не повинно бути проблемою ІТ. Якщо це трапляється N разів, ви можете помістити зазначену особу у своєрідний "чорний список" і, так, відкинути його адміністративні права на деякий час.

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


1

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

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

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


Це правда, що MS рекомендує VS2005 запускати як адміністратор. Але Майкл Говард, один із головних спеціалістів із забезпечення програмного забезпечення в MS, каже, що 99% часу він працює просто чудово, як nonadmin: blogs.msdn.com/michael_howard/archive/2007/01/04/… ... Отже, якщо безпека для вас важлива, ви можете спробувати запустити її nonadmin. Приємний сюрприз, ймовірно, чекає на вас!
quux

1

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

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


+1 .. Я не розумію, чому VM так не використовуються. Не тільки з метою, про яку ви згадали, але розповсюдження програмного забезпечення було б набагато простіше за допомогою VM.

1

Я (як сам дев) вважаю за краще повністю контролювати свою техніку, тобто; працює як адміністратор при необхідності.

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

Переважно їм потрібно знати більше про ІТ-інфраструктуру з точки зору підтримки ІТ / ІТ-підтримки, пов'язаних із безпекою матеріалів, а також, чому б не розвиватися з підвищеними правами. (і як переконатися в тому, що ви цього не зробите ...)

"Не сліпо довіряйте нам, коли ми скажемо вам, що ми знаємо все, що нам потрібно знати про комп'ютери" ;-)

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


І ще одне: переконайтеся, що у нас встановлено належний AV ... Примусово, якщо потрібно ... ;-)
Арджан Ейнбу

1

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

Ми закінчили такі процеси:

  • У нашому стандартному зображенні були основні інструменти: Windows, Office, антивірус, Acrobat, кілька утиліт.
  • Ми забезпечили велику кількість мережевого дискового простору: достатньо, щоб усе могло зберігатися в мережі. Єдиним винятком були відеофайли, які були в процесі обробки, які мали залишатися локальними.
  • Співробітники (за консультацією зі своїми керівниками) мали два варіанти: або ІТ підтримували свій ПК, робили всі встановлення та конфігурацію, або АБО могли мати доступ адміністратора, щоб зробити це самостійно. В будь-якому випадку всі дані були резервні копії в мережі.
  • Якщо ІТ підтримував систему, і вона загинула, ми повертаємо її до стану, в якому вона знаходилась, включаючи додавання додаткового програмного забезпечення, яке було потрібно для встановлення.
  • Якби у них був доступ адміністратора, і система померла, ми б переглянули та спробували її виправити, але нашим зобов’язанням було повернути їх до стандартного зображення, і вони мали б взяти його звідти. Якби у них були місцеві дані, ми б спробували вийти з цього спочатку, але наша угода про надання послуг була лише для того, щоб якнайшвидше зробити їх робочим, стандартним ПК.
  • Будь-хто з доступом до адміністраторів повинен знати, як переконатися, що оновлення Windows працюють, щоб оновити Антивірус та анти-шкідливі програми.

Ми хотіли б поставити всіх людей з адміністраторським доступом на "недовірену" vlan, але ми ніколи до цього не потрапляли.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.