Чи є загальнодоступним доступ до місцевих адміністраторів для розробників в організаціях?

Я працюю в компанії з персоналом близько 1000 +. В даний час ми маємо співробітників з розробки програм, які працюють на веб-проектах (близько 50 осіб).

Нещодавно у зв'язку з проблемами безпеки наш відділ ІТ та безпеки реалізував обмеження, що більше не дозволяли доступ до локальних адміністраторів на машинах. Вся компанія запускає ОС Windows як для робочих станцій, так і для серверів. Я повністю погодився з рішенням видалити адміністратора, чесно кажучи я думав, що це давно назріло (так як компанія займається даними пацієнта і вимагає відповідності HIPAA). На жаль, я вважаю, що вони прийняли рішення занадто далеко. Я припустив, що підгрупа або група AD буде створена для користувачів, які потребують адміністративного доступу, щоб зробити свою роботу (EX моєї команди програмістів), щось на зразок Tech Group, що збереже доступ адміністратора. Однак це не було так, лише група створила певну групу адміністраторів для співробітників мережі та служби довідки.

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

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

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

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

Трохи більше інформації про наше мережеве середовище (не те, що воно дійсно стосується питання, яке я просто хотів би додати):

  1. Ми використовуємо AppBlocker, щоб заблокувати програми, які не затверджені списком
  2. Ми використовуємо блокувальника безпеки електронної пошти, який виконує такі дії, як сканування та конвертування вкладень у PDF, і т.д.
  3. На всіх робочих станціях є принаймні 2 великі антивірусні програми.
  4. Мережа та її сервери дуже відокремлені, користувачі мають доступ лише до певних серверів, папок і баз даних, до яких вони законно потребують доступу.
113
У моїй роботі я завжди мав доступ до адміністратора. Одна компанія спробувала усунути це з нас, але припинила його досить швидко після того, як зрозумів, що розробники не тільки розчаровані, а й просто перестали працювати. Не тому, що вони не хотіли, а тому, що вони більше не могли працювати. Так що принаймні з мого особистого досвіду (в Німеччині) досить поширеним є доступ адміністратора для розробників. (Я знаю, що від деяких розробників, що вони повинні використовувати віртуальні машини (з правами адміністратора) як компроміс для сильних середовищ безпеки
додано Автор Majin Magu, джерело
Я є контрактним програмістом в оборонній промисловості. Кожна компанія, для якої я працюю, має програму, яка надасть права адміністратора тимчасового адміністрування під час входу в дію з міркувань безпеки. Для того, щоб відповісти на ваше запитання: "чи є вона загальною?" - так, але це дійсно чітке питання безпеки (жодне злочин не призначений)
додано Автор JW., джерело
Одним з недоліків розробників програмного забезпечення, запущених як місцеві адміністратори, є те, що вони ніколи не можуть зіткнутися з проблемами кінцевого користувача, які трапляються тільки тоді, коли у вас немає таких прав. Я особисто бачив це багато разів.
додано Автор Benjamin Podszun, джерело
Ви спробували встановити кінцеві точки WAAS, щоб надати користувачеві/групі доступ до http://+: 80 /? Google для "netsh http add urlacl" ...
додано Автор Haakon, джерело
Анекдот: Я ніколи не працював у компанії, яка заблокувала їх службовця таким чином, що мав будь-яку справжню компетентну безпеку. Будь-яка компанія, за яку я працювала, зробила це невдало, в той час як робота для своїх співробітників надзвичайно складна. Я також скажу, що я ніколи більше не працюватиму для такої компанії знову. Навпаки, я б хотіла займатися важливою роботою, ніж боротися з бюрократичними витратами часу кожного.
додано Автор idrosid, джерело
@atdre Орендуйте інженерів компетентних органів. Крім того, якщо все правильно налаштовано, жодне з того, про що ви скаржилися, не є реальним ризиком.
додано Автор idrosid, джерело
Слід зазначити, що деякі засоби розробки не запускатимуться, якщо обліковий запис не є адміністратором. Це, як правило, більш вірні, чим старше програмні засоби.
додано Автор alexis.kennedy, джерело
Якщо ви дозволите appdevs ladmin свої машини, то вони встановлять unauth FTP, RSH, Webmin, Jenkins, Tomcat, ColdFusion, JBoss/WildFly, Splunkd, ElasticSearch і т.д. - і вони ніколи не будуть оновлюватися. Вони налаштують SimpleHTTPServer, SMB, AFP та/або NFS, щоб дозволити волю-неволі доступ для читання та запису до своїх локальних файлових систем через мережу (або їх частини), після чого вони залишать сценарії оболонки та ключові матеріали для цих спільних папок . Вони зроблять те ж саме з базами даних і всім іншим, що може прив'язати до мережевого сокету.
додано Автор Rufo Sanchez, джерело
@Brad: Близько 300 співробітників, це неможливо. Існують переконливі докази того, що навіть професіонали з кібербезпеки стають жертвами загального фішингу та фішингу копій. Коли ви прогоняєте фінансово-мотивованого актора, або національної держави, проти однієї людини - це, як правило, людина, яка печера. Ні, це завжди так. Немає належного "налаштування", про яке я чув, що зменшує ризик розширення доступу в середовищі Windows Server Forest. Навіть Microsoft не продає її.
додано Автор Rufo Sanchez, джерело
Ідк, у вас є чудові ідеї, але я їх ніколи не бачив. Я думаю, що краще впровадити JitJea незалежно. Ніхто не повинен навіть мати адміністратора протягом довгих (секунд), особливо не місцевого адміністратора на робочу станцію або адміністратор/групу домену для мереж великої інсталяції.
додано Автор Rufo Sanchez, джерело
Оскільки компанія бачить розробників як проблему, а не як рішення (мабуть, ваш бос або не був почутий або проігнорований), я пропоную шукати більш дружнє для розробника середовище в інших місцях. А оскільки ми знаходимося на Stackexchange, наш великий засновник має Сильна думка про те, як Ваша компанія звертається до Вас.
додано Автор Kromster, джерело
Я не думаю, що ви дійсно хочете запитати, чи є це "типовим". Але скоріше це виправдано, і які витрати/вигоди? На моєму досвіді це досить поширене явище для великих організацій. Витрати досить високі, і це різко впливає на продуктивність для розробників, але "люди з безпеки", як правило, не хвилюють, тому що воно оточене у полі SEP (проблема хтось іншої). Якщо ви хочете позбутися цього, ви навряд чи виграєте, намагаючись знайти, що це не типово, а скоріше, що це ДОРОГО. Компанії ненавидять дорого.
додано Автор Steve Sether, джерело
@Jacco Я більше не можу погодитися. Раніше я працював для організації, яка зробила це, і вона створила саме те, про що ви говорите. Коли корпорація Big Evil намагалася реалізувати це, мої перші думки зосереджувалися навколо стрибка огорожі. Будь-який досвідчений розробник може придумати півдюжини способів перестрибувати ці типи огорож без особливих зусиль.
додано Автор Steve Sether, джерело
Наявність двох окремих антивірусних програм у системі майже напевно принесе більше шкоди, ніж користі. Ви отримаєте незначне збільшення виявлення, в той час як подвоєння вашого впливу вразливостей самого програмного забезпечення AV, а також суттєве уповільнення постраждалих систем.
додано Автор Valerie Anderson, джерело
@Jacco Не кажучи вже про когнітивний дисонанс між не довірою до розробника з власною машиною і одночасно довіряючи їм розробляти власний код для запуску на серверах компанії та обробляти інформацію конфіденційних користувачів. Якщо вони не зможуть утримувати вірус від своєї машини без захисту, я не думаю, що я хочу, щоб вони розробляли мої програми, які я міг би бути оштрафований за те, що я не зробив правильно.
додано Автор jpmc26, джерело
@Neil Так, ви повинні бути місцевим адміністратором, щоб навіть відкрити менеджер iis або прикріпити відладчик до iis робочого процесу.
додано Автор Obviously_Anon, джерело
@Neil За винятком випадків, коли ви не можете використовувати службу IIS Express, наприклад, коли вам потрібно розгорнути програму на іншому комп'ютері та підключити його до вашої робочої станції.
додано Автор Obviously_Anon, джерело
@Neil Це не питання інтеграції; якщо ви не думаєте, що розробник, який запускає додаток, працює над локальним тестом, перш ніж здійснювати його, - це "інтеграція". Є багато інших речей, які розробники повинні будуть робити, які вимагають місцевого адміністратора, і не маючи місцевого адміністратора є серйозною перешкодою для виробництва, що, ймовірно, тому більшість розробників в кінцевому підсумку з ним (і я особисто не працював би десь я t).
додано Автор Obviously_Anon, джерело
Політика компанії, яка заохочує тертя між ІТ та розвитком, є ризикованою політикою. Якщо є одна група людей, яка може серйозно підірвати зусилля з безпеки ІТ-департаменту, це будуть розробники. Хороша політика компанії буде спрямована на те, щоб ІТ та Розробка об'єднали свої колективні знання для посилення загальної безпеки. Змусити ІТ поставити бар'єри для розвитку є контрпродуктивним для цього результату. Враховуючи достатньо стимулів, люди почнуть шукати творчі обхідні шляхи. Творчі обхідні шляхи від розробників завдадуть шкоди загальній безпеці.
додано Автор Brythan, джерело
@matwonk Будь ласка, повідомте нам про те, як вийшла проблема.
додано Автор Brythan, джерело
Не одне і те ж питання, але дуже споріднене, я був з іншого боку (ІТ-сторона речей, а ІТ-люди часто не погоджуються з такою божевільною політикою): security.stackexchange.com/questions/135359/& hellip;
додано Автор grochmal, джерело
Будь-який розробник, який вартий прокляття, отримає кореневий доступ на машині, до якої він має фізичний доступ:)
додано Автор Navin, джерело
Яким чином я мав справу з цим у минулому, роблячи досить основний заклик до начальника/директора, який знаходиться вище за ІТ-безпеки людей у ​​старшинстві. Це виглядає так: "У мене є проблема, яка означає, що я не можу отримати будь-яку роботу, але я визначив рішення і тільки потребують вашого схвалення, щоб реалізувати його." Досить дивно, що необхідність компанії робити гроші завжди перевершує екзистенційну загрозу, яку люди з ІТ-безпеки придумують, щоб виправдати свої драконівські заходи. Однак: завжди приємно робити це - ви хочете, щоб команда з безпеки ІТ була на вашому боці, довгострокова.
додано Автор user128064, джерело
@atdre Це цілком можливо, вам потрібно просто організувати себе краще. Коли я працював у величезному магазині програмного забезпечення, кожен проект був повністю відокремленою «віртуальною компанією» у сфері інформаційних технологій, з нею є власні сервери, команда та повністю ізольована інфраструктура. Не було необхідності постійно розміщувати всіх на одній мережі. Він творив чудеса. Вона також мала плюс, що ви могли б перемістити команду в будь-якому місці, не компрометуючи її роботу або встановлюючи доступ до центрального сервера - коли один з наших офісів згорів, ми орендували простір на кібер-кафе і продовжували рухатися, поки все не було виправлено.
додано Автор T. Sar, джерело
@atdre Крім того, маючи повністю відокремлені інфраструктури, ми могли б запускати оновлення та різні установки в кожній команді. Оскільки команда ІТ також була розділена на «віртуальну компанію», кожен професіонал також мав набагато менше турбот у будь-який час.
додано Автор T. Sar, джерело
Іноді це потрібно для налагодження. Наприклад, при використанні Visual Studio без локальних прав адміністратора, ви не можете налагоджувати процес, запущений під іншим користувачем. Але компанія може налаштувати певний процес для запиту тимчасових прав адміністратора на робочу станцію для конкретного користувача.
додано Автор Confutus, джерело
Примітка: Якщо ви дозволяєте Visual Studio запускати "Як адміністратор", користувач може запускати код "Як адміністратор". Код з привілеями адміністратора може призначити привілей SeDebug будь-якому маркеру безпеки, який він хоче, і, отже, розробник має повний контроль над машиною.
додано Автор Galaxy, джерело
Давайте навіть не розглядати помилки, тобто додавання нових антивірусних продуктів робить систему більш безпечною.
додано Автор Galaxy, джерело
У багатьох компаніях розробники також подвоюють системні адміністратори, тому вони, звичайно, мають привілеї.
додано Автор Charlotte Vandersleyen, джерело
Насправді це одне з питань, які я часто задаю в інтерв'ю, якщо відповідь "ні", розробникам не дозволяють права місцевого адміністратора, то я ввічливо відмовляюся продовжувати.
додано Автор user149010, джерело
Це багато в чому залежить від сектора. Банківські, військові, комунальні послуги - вони, швидше за все, будуть набагато більш обмежувальними, ніж більшість інших. Програмна інженерія - це навик, який можна перейти до будь-якої галузі, але не завжди є галуззю
додано Автор user155848, джерело
Ви/дійсно/потрібен доступ адміністратора до використання ASP.NET/IIS? Я розробляв ці проекти протягом 10 років, і ніколи не потребував доступу адміністратора. Я працював з розробниками, які наполягають на цьому (на тій же кодовій базі), але це, як правило, тому, що вони мають "інструменти", які вони (погано) написали самі.
додано Автор Dan Roberts, джерело
@Andy Або просто використовуйте IIS Express, і тоді ви цього не зробите.
додано Автор Dan Roberts, джерело
@Navin в деяких місцях, які дадуть вам коротку поїздку до HR, щоб отримати ваш P45. Так звичайно !
додано Автор Dan Roberts, джерело
@Andy Це звучить більше як питання інтеграції, а не розвитку. 100% ваших робіт з розробки можна зробити без прав адміністратора.
додано Автор Dan Roberts, джерело

19 Відповіді

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

Існує ряд мереж. Вони фізично відокремлені і зв'язані з повітрям, виконуючи різні кольорові мережні кабелі.

Кожен співробітник має «адміністративну» машину, яка може підключатися до Інтернету (через проксі-сервер) для здійснення електронної пошти тощо.

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

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

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

110
додано
@Deduplicator як це так? Ви можете копіювати матеріали досить легко через USB-накопичувачі. Це змушує вас думати про те, що ви дійсно хочете замість випадкового натискання на сміття і встановлення всього. Відсутність доступу адміністратора змусило мене організувати мої завантаження партіями, так що я набагато більш вибірково з тим, що я встановлюю.
додано Автор plusplus, джерело
@Flater, навіть якщо це небезпечно,
додано Автор plusplus, джерело
+1 Так і зробив постачальник Infosec/A/V, яким я працював. Вони дуже серйозно сприйняли сегментацію мережі - це було терміновим злочином підключення пристрою dev до мережі продукту/внутрішньої інфраструктури, і мені довелося призначити більш ніж одного розробника для цього. Тим не менш, я вважаю, що це найкращий підхід до розробки, який є найзручнішим для розробників - “ось ваш ноутбук для розробників у вашій мережі dev, і ми розберемо вас від усього, що може бути завдано збитків від необхідних повноважень, щоб зробити вашу роботу добре. "
додано Автор Shawn, джерело
Мені довелося працювати в дещо подібній установці під час роботи в DoD-підряднику. У такому випадку моя головна машина була підключена до основної мережі, Інтернету, і мав місцевого адміністратора. Виробничі машини були повітрянозамкнені зі світу за закритими дверима і масово заблоковані. Можливість робити більшу частину мого дев/початкового тестування, як правило, значно знижувала біль, але були випадки, коли було неможливо створити придатний для використання некласичний набір даних, і мені довелося зробити все на високій стороні. Це було жалюгідним, тому що це була принаймні 20-метрова прогулянка до комп'ютера, підключеного до Інтернету, і лише друкований xfer для розробника.
додано Автор Brendan Long, джерело
@Nelson Такий підхід стає дуже болючим на практиці. Сьогодні звичайно використовувати рамки для прискорення розвитку. Багато сучасних фреймворків залежать від ряду бібліотек, і це може бути складним і схильним до помилок, щоб визначити точні залежності рамки, яку ви використовуєте, щоб зберегти їх на USB-пристрої. Ви також втратите доступ до важливих інструментів безпеки. Деякі сучасні менеджери пакунків можуть автоматично перевіряти, чи у ваших залежностях є застереження щодо безпеки, і, якщо це так, оновити їх. Якщо вам потрібно зробити це на іншій машині, тоді ця машина стане вашим де-факто пристроєм.
додано Автор Valerie Anderson, джерело
+1, деякі команди розробників нашої компанії використовують таку ж практику. Хоча ми не розв'язуємо повітряну мережу. Ми працюємо з використанням VLAN.
додано Автор Philipp, джерело
@NickT Витоки вихідного коду, як правило, є другорядною проблемою. Або в багатьох організаціях, зовсім не занепокоєння, тому що їх програмне забезпечення настільки спеціалізовано, що не має значення для будь-кого, крім них/їхнього клієнта. Небезпека, яка впливає на всіх, - це ненавмисне розповсюдження шкідливих програм. Машина, що працює на повних привілеях адміністратора і отримує доступ до Інтернету за допомогою програмного забезпечення, яке не перевіряється ІТ-департаментом, є магнітом для шкідливих програм
додано Автор Philipp, джерело
Чесно кажучи, я б вручив своє повідомлення в той самий момент, коли ця політика була введена ... Не маючи доступу до Інтернету на dev машині просто божевілля.
додано Автор Abdul, джерело
Ваша "інженерна мережа" дійсно є виробничою мережею? Вам дійсно потрібно мати дві коробки, одну для читання документів, іншу для коду? Якщо це мережа dev/test, то я заплуталася з приводу занепокоєння, проникнення зловмисників, які отримують код? Exfiltration коду (ваші devs буде працювати навколо що приблизно у 5 секундах)? Якщо це була виробнича мережа, ви, ймовірно, можете уникнути доступу інженерів до неї взагалі (QA/ops розгортається в прод).
додано Автор The Lazy DBA, джерело
На моєму робочому місці USB (та інші знімні носії) вимкнено (і дозволено лише для білого списку пристроїв dev на обмежений час для робочих цілей), але ми маємо 2 облікові записи, адміністратор для роботи з без/обмеженого доступу і користувач з низьким дозволом, який може переглядати веб-сторінки. Не потрібно 2 машин.
додано Автор Landmaster, джерело
Hm, розробка машин, які не мають будь-якого підключення до Інтернету, здається досить жорстким обмеженням.
додано Автор Deduplicator, джерело
У більшості місць, де можна побачити розгортання, подібні до цього добре пройшли концепцію користувацьких машин і добре розуміють концепцію облікових записів: всі вони працюють з віртуальними машинами або з мережею керованого обліку з загальним сховищем. Ваш адміністраторський ПК може легко мати RW-доступ до NAS, або навіть бути ціллю VM VPN/SSH, що дозволяється запускати лише одного клієнта в кімнаті (для припинення входу в систему). Це зазвичай ідеально, оскільки IT може отримати доступ до адміністратора з будь-якої системи, Devs може запускати встановлення через неї, але спочатку потрібно ввійти з облікового запису std користувача, ідентифікуючи користувача Admin.
додано Автор Jack, джерело
Блокування доступу до відкритих веб-сайтів, безумовно, є безумством, але при всій чесності, якщо ви хочете розробити в адміністративному середовищі, зберігаючи безпеку, ваша ІТ-сторона повинна бути віртуалізувати свій пакет, щоб він міг мати доступ до адміністратора з пескою. Це дає вам змогу виконати стільки адміністративних робіт, але обмежити вас зовнішнім контролем доступу від VM і зберегти будь-кого, скажімо, отримати вірус на спільному сховищі.
додано Автор Jack, джерело
@Nelson, Насправді, для поліпшення безпеки, всі порти USB використовуються на інженерному середовищі повинні бути відключені, вони по суті небезпечні. Набагато більш корисним і безпечним буде використання Data Diode для забезпечення контрольованого завантаження зовнішніх оновлень. en.wikipedia.org/wiki/Unidirectional_network
додано Автор MathEW, джерело
@Nelson: Як ви можете перевірити, що те, що ви копіюєте через флешку, безпечне? Хоча вам очевидно потрібно дозволити копіювання з адміністрації на інженерію; ви б дозволили копіювати до адміністративної машини? Оскільки, якщо ви дозволяєте обидва, дані, обмінювані на паличці, настільки ж безпечні, як дані, які обмінюються на фізичному мережевому кабелі (безпосередньо між двома машинами), це лише повільніше.
додано Автор user180510, джерело
Це не рішення зробити легке. Це матиме значний вплив на розвиток. Не кажучи, що це зробити неможливо, тільки вказуючи на деякі з наслідків. З технічних речей, таких як пакети nuget/npm (у вас не буде реального доступу до загальнодоступних каналів і потрібно буде скопіювати все вручну), але й більш тривіальні проблеми (розробники більше не можуть копіювати/вставляти з StackOverflow. реальний тут, ми всі робимо це, навіть якщо ми погоджуємося, що перевірка коду є необхідною (яка ІМО, це є), вручну потрібно вводити все це не буде сприяти ефективній роботі).
додано Автор user180510, джерело
Наявність покупки другого ПК/ноутбука для співробітників здається досить дорогим способом зробити людей менш продуктивними
додано Автор public wireless, джерело

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

Один дуже поширений доступ - це доступ до Гіпервізора на робочій станції (будь-яка версія VMWare або Hyper-V, що поставляється разом з Windows), а також конкретні дозволи, необхідні для створення та знищення віртуальних машин у межах цього гіпервізора за необхідністю ( Hyper-V / VMWare ) , включаючи створення Віртуальні машини, де вони мають права адміністратора на гостьову ОС. Як правило, деякі з цих віртуальних машин будуть довговічними, навіть якщо вони не працюють увесь час, де ніколи не виникає питання про необхідність підготувати всю ВМ лише для того, щоб зробити те, що має бути швидким тестом з тим, що потребує прав адміністратора.

Гіпервізор може або не може бути налаштований, щоб дозволити доступ до Інтернету для своїх віртуальних машин; Я бачив це в обох напрямках, хоча особисто я віддаю перевагу тому, щоб доступ до Інтернету повинен бути дозволений ... хоча б для тих типів розробок, з якими я маю найбільше досвіду. Але доступ до Інтернету, коли він буде наданий, може і повинен, як мінімум, бути налаштований, щоб примусити віртуальні машини до виділеного vlan, окремо від решти корпоративної мережі. Я не впевнений, що це можливо застосувати безпосередньо через Hyper-V або VMWare, але ви можете використовувати 802.1x на портах для багатьох мережевих комутаторів, щоб запобігти доступу до певних версій від неавторизованих машин, включаючи віртуальні машини devloper. Тоді ви можете дати невеликий підручник розробникам про те, як встановити тег vlan у віртуальній машині і дайте їм знати, які vlan теги будуть дозволені на їхньому комутаційному порту. Я також бачив, що це виконується лише як указ про політику, а не за допомогою технічних заходів.

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

66
додано
Це звучить як хороше рішення - дуже хороше рішення - але я не маю достатньо адміністратора для Windows, щоб дізнатися, чи дійсно він працює таким чином (певні привілеї або права для розгортання віртуальних машин без загального доступу місцеві адміністрування privs) - так IMO ця відповідь може бути значно покращена з посиланнями на деякі документи/документи/кухонні книги/або такі, які підтверджують це.
додано Автор Grant Collins, джерело
Так, відмінне посилання! Бен Армстронг - хлопець, до якого потрібно йти! Плюс деталі на VLAN речі.
додано Автор Grant Collins, джерело
Віртуальні машини також надають іншим користувачам переваги. Один фізичний комп'ютер може розміщувати кілька віртуальних машин, виконуючи різні версії ОС або версії програмного забезпечення, що тестується. Оскільки вони одноразові, простіше повторювати тести, повертаючись до обраної контрольної точки.
додано Автор Raedwald, джерело
@davidbak Краще?
додано Автор Phonon, джерело
@Davidbak Я працював на машині з гіпервізором (VirtualBox), встановленим, не маючи прав адміністратора
додано Автор Naoise Golden, джерело

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

У нас також є група розробників AD, яка дозволяє учасникам змінювати політику виконання на своїх машинах, не вимагаючи місцевого адміністратора.

44
додано
@Steve - на жаль, це так само хибно виглядає, як ви отримуєте від деяких людей з надзвичайною безпекою. Це не параноїда для захисту організацій від інсайдерської загрози. Адже для багатьох це найбільша загроза їх існуванню.
додано Автор Rory Alsop, джерело
@TomK. Вона відповідає актуальному питанню: «Чому моя організація робить моє життя дуже, дуже важким, начебто не має ніякої причини, і що я можу зробити з цим?». ОП явно намагається пристосувати цю (цілком відверто дивну і параноїдальну) практику до свого світогляду. Люди намагаються вказати, як їхні організації врівноважили параноїдальних людей з реальними життєвими потребами розробників.
додано Автор 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. Не існує способу дізнатися, що типово відсутнє для якогось опитування, тому відповідь на ту частину питання не відбудеться.
додано Автор Obviously_Anon, джерело
@TomK. Ці опитування або дослідження, якщо вони навіть існують, були б небажаними. Як ви вже сказали, itd просто бути збіркою того, що може бути "типовим", і тільки тому, що щось типове не означає його правильний шлях.
додано Автор Obviously_Anon, джерело
Це не відповідає на запитання. Вона не дає жодного пояснення, якщо і чому це буде "типовим".
додано Автор Sean, джерело
@ PeterA.Schneider: Правильно, як правило, жодна людина не може канонічно відповісти на глобальне питання, подібне до цього, лише з його/її досвідом . Але на щастя є такі речі, які називаються "кращими практиками", які записані і відкриті для перевірки. Інші можливості - це дослідження або статті. Просто сказати "Для мене, це так" не достатньо.
додано Автор Sean, джерело
@Andy Правильно. Ці дослідження чи дослідження проводяться вченими або часто консультантами, які розвивають - як я вже згадував - найкращі практики. Цитуючи ці найкращі практики або дослідження, це буде правильною відповіддю.
додано Автор Sean, джерело
@TomK. Це відповідає на питання частково. Якщо 10 людей з 10 говорять: "Я завжди мав права адміністратора", то разом - це відповідь. Жодна людина не може канонічно відповісти на це глобальне питання; кожна єдина відповідь до ступеня анекдотична, "точка даних", як його назвав Джо. (Джо також стверджував: "Я знаю, що це поширене в інших оригіналізаціях", не додаючи "я знаю".)
додано Автор Bobas_Pett, джерело

У відносно невеликому відділі великої організації (~ 100 у відділі, ~ 3500 у повній організації) ми вибрали посеред рішення:

    Системні адміністратори
  • мали 2 облікові записи: один (не адміністратор навіть для локальної машини), який використовувався для неадміністративних завдань (пошта, видання документів тощо), а один із привілеями адміністратора AD, які повинні використовуватися лише для адміністрування AD
  • всі інші користувачі мали лише один обліковий запис без адміністратора
  • devs (і деякі потужні користувачі ) отримали локальний обліковий запис з правами адміністратора локальної машини. Передбачалося, що це буде рідко, коли потрібно місцева адміністрація.

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

  • Якщо більше ніж кілька разів на день, я радив би використовувати основний обліковий запис.
  • Якщо менше ніж раз на тиждень, я б використовував вторинний обліковий запис.

Виберіть своє, якщо ви перебуваєте між ними ...

27
додано
Міркування: скільки доступу в Інтернет для облікового запису AD. На моєму робочому місці мого AD практично не має доступу до Інтернету (окрім оновлень Visual Studio). Я повинен використовувати свій звичайний рахунок для інтернет/завантаження/і т.д.
додано Автор julionc, джерело
Сьогодні ми провели зустріч з нашою ІТ-групою з цього приводу, і я схиляюся до позначення цієї відповіді як відповідь просто тому, що це рішення для нас.
додано Автор David, джерело
Так, ми зробили це теж. Хоча наші облікові записи адміністратора AD також мали права локального адміністратора на кожній машині (яка була частиною домену/оголошення).
додано Автор Sami Liedes, джерело

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

Яка загроза вашій мережі погіршується місцевими правами адміністратора?

Відповідь має бути: NONE - доступ до ресурсів у вашій мережі повинен бути обмежений для кожного користувача, абсолютно не пов'язаний з тим, якщо цей користувач має локальний доступ root, admin або 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.

Чому розробники повинні мати місцеві права адміністратора

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

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

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

16
додано
@Downvoter піклується про те, як мій відповідь може бути покращений, або чому ви вважаєте, що це абсолютно неправильно?
додано Автор Tim Jansen, джерело
@JamesSnell Я великий прихильник оборони в глибину, але я просто не бачу місцевого обмеженого облікового запису, що забезпечує що-небудь цінне, крім локальних апаратних засобів. До будь-якої вартості бізнесу можна скористатися з правами користувачів xkcd.com/1200
додано Автор Tim Jansen, джерело
Захист в глибині для мене включає в себе зашифрований жорсткий диск, надійний пароль на локальному обліковому записі, захищений модуль апаратного забезпечення ... Але місцеве обмеження прав користувача на одному ноутбуці користувача - це просто театр безпеки
додано Автор Tim Jansen, джерело
@JamesSnell як захищена машина? Зловмисника з правами користувача на машині достатньо для запуску повної атаки на вашу мережу. Ноутбук вже може бути зараженим комп'ютером без доступу адміністратора.
додано Автор Tim Jansen, джерело
@JamesSnell іронічно IDE, який вони могли б встановити без локальних прав адміністратора ;-) Але я бачу вашу точку зору: Так, він розширює потенційну поверхню атаки, але лише невеликим відривом. І якщо ваші розробники не отримують місцевого адміністратора і завантажують деякі "допоміжні інструменти" для того, щоб обійти це, ви, ймовірно, маєте ще більше поверхні атаки. - Я хотів би побачити опитування, якщо розробники використовують свою машину більш відповідальною, якщо їм довіряють відповідальність, а не довіряють.
додано Автор Tim Jansen, джерело
@JamesSnell Як може кожен розробник так само по своїй волі, якщо ви йому довіряєте. Місцевий адміністратор не означає "використовує корінь весь час", але "може використовувати корінь необхідного"
додано Автор Tim Jansen, джерело
Можливо, мені слід відредагувати свою відповідь, щоб визначити це ясно - я думаю, що розробники повинні використовувати захищений обліковий запис нормально, але мають можливість включити місцевого адміністратора, якщо це необхідно, без необхідності заповнювати форму і просити дозволу. І я довіряю їм використовувати цю привілею розумно і скупо
додано Автор Tim Jansen, джерело
Коротше кажучи, ця відповідь порушує принцип найменш привілейованого і всього поняття оборони в глибині. Причина обмеження локального адміністрування полягає в тому, щоб допомогти пом'якшити атаки, які проходять, і хороші розробники зрозуміють це. Там, де існує очевидна потреба, це - інша гра, яка часто зустрічається з окремим обліковим записом адміністратора, так що використання підвищених привілеїв є тимчасовим; але операційна система говорить, що вони є веб-розробниками, тому не повинно бути необхідності в локальних правах адміністратора. Див. security.stackexchange.com/a/190182/17321
додано Автор Martin Spamer, джерело
@Falco - справа в тому, що машині не дозволяється використовувати її як платформу для запуску нових атак ...
додано Автор Martin Spamer, джерело
@Falco - це зменшує поверхню атаки, чи ви не читали відповідь? Плюс ... theregister.co.uk/2018/07/25/developers_malware_vectors
додано Автор Martin Spamer, джерело
@Falco - це не питання довіри. Таким чином я керую своїми системами. Я обмежую свої права, коли мені це не потрібно.
додано Автор Martin Spamer, джерело
@JamesSnell Visual Studio потребує локальних прав адміністратора, що є (imo) великою причиною, оскільки розробки без Visual Studio просто не відбувається. Не погоджуючись з іншим вашим коментарем, просто необхідність місцевих прав адміністратора.
додано Автор user180588, джерело

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

Схоже, ваша організація знаходиться на кордоні малих і великих, так що ...

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

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

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

Ви все одно не займаєтеся розвитком своїх виробничих активів, чи не так?

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

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

Існує декілька способів реалізації окремого середовища розробки:

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

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

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

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

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

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

додано Автор Luc, джерело
Замість того, щоб писати свою власну відповідь, я хочу будувати на цьому. На моїй роботі ми розрізняємо: 1) сервери розвитку, 2) інші сервери, що не виробляються (QA, TST і т.д.), і 3) виробництво. Розробники можуть мати адміністраторський доступ для виконання робіт з розробки, але очікується, що вони будуть упаковувати свій код та інші активи та надавати їх нам для розгортання в інших безпрограшних середовищах, а також всю документацію про будь-які налаштування ОС, які необхідно зробити. Я навіть не хочу їх на тих системах групи 2, які вводять відмінності від Prod, що усуває мету групи 2.
додано Автор KS.Pan, джерело
Це правильна відповідь. Розробники повинні/повинні мати адміністраторський доступ до своїх робочих станцій розробки, але не повинні мати доступу до виробничих систем, dbs з конфіденційними даними тощо з цих робочих станцій.
додано Автор Galaxy, джерело

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

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

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

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

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

10
додано
Існує різниця між не відповідаючи на запитання і даючи іншу точку зору або намагаючись показати проблему OP в іншому світлі.
додано Автор Sean, джерело
У всій реальності, оскільки ви відмітили відповідь Марселя: Здається, ваш відповідь не відповідає на питання і фактично явно відмовляється робити це. Якщо ви хочете заохотити ОП, щоб задати інше, більш актуальне питання, розглянути можливість зробити це в коментарі.
додано Автор Bobas_Pett, джерело

Це принципово залежить від контексту, і зокрема від вашої моделі загрози.

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

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

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

7
додано

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

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

Ось що аргументи не розуміють: порушення особистих рахунків розробника не є точкою запуску; це джекпот. Існує ніяких причин, щоб піти на адміністратора звідти. Розбежник має здатність змінювати код, щоб вставити бекдор. Отримання адміністратора у вікні розробника не набагато цікавіше.

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

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

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

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

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

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

6
додано

Я бачив два підходи, які працюють.

  1. Надайте адміністраторам доступ до своїх машин. Це найпростіший і найпоширеніший підхід. Як правило, це найкращий вибір
  2. Створити команду в організації, вся робота якої полягає в тому, щоб розробники могли працювати без доступу адміністратора. Ця команда зазвичай буде 3-4 людини. Ви побачите, що вимоги до апаратних засобів розробника різко зростають, оскільки ви використовуєте контейнери та/або віртуальні машини, тому бюджет на придбання нового обладнання для всіх розробників. Коли ви розгортаєтеся, почніть з команди ранніх користувачів, а потім поступово пересуньте всіх своїх розробників на машину без доступу адміністратора. Цей процес займе не менше шести місяців.

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

5
додано
Це абсолютно нерозумно для будь-яких інструментів розробки, які потребують будь-якого доступу адміністратора. Що б вони не думали, що їм це потрібно, ІТ-команда, відповідальна за створення та підтримку коробок розробників, повинна мати можливість переналаштувати програмне забезпечення або віртуалізувати відповідні інтерфейси, щоб інструменти працювали без шкоди для безпеки інфраструктури.
додано Автор Mike Caron, джерело
@UEFI: Натомість вам доведеться просто залучати людей до повторного зображення машин розробників щоразу, коли вони встановлюють віруси і мають справу з усіма втраченими часом розробки та можливими втратами активів ... Re: налагодження, безумовно, має бути налаштована політика, щоб дозволити Користувачі, які не є адміністраторами, налагоджують свої власні процеси .
додано Автор Mike Caron, джерело
@UEFI: Ні, оскільки JS є вбудованою мовою, яка не виконується в домені привілеїв вашого облікового запису користувача. Він виконується у складному домені привілеїв, реалізованому браузером. Це правда, що під уразливістю для пісочниці в браузері існує вектор для налагодження інших процесів (але вже є кращі вектори для нападу на вас у випадку втечі пісочниці). Отже, для укріплення корисно, щоб політику приєднання відладчика можна було налаштовувати й вимикати для користувачів, які не зацікавлені в його використанні. Але це не є суттєвим аспектом будь-якої моделі привілеїв.
додано Автор Mike Caron, джерело
3-4 людини, повний робочий день ?! Це дуже багато грошей, які, на мою думку, можуть бути витрачені краще. І, можливо, вам захочеться детально зупинитися на тому, чому ви вважаєте, що надання адміністративним правам розробників найкращий вибір.
додано Автор Luc, джерело
@Luc Багато інструментів розробки покладаються на привілеї локального адміністратора. MS Visual Studio, наприклад, не потребує всіх локальних адміністративних привілеїв для належної роботи, але потребує певних привілеїв адміністратора. DEBUG_SE для налагодження, управління послугами для - керування службами, створення прав для баз даних, і я міг би продовжувати віки. Тепер виявлення того, чому розробник не здатний запускати скрипт бази даних, налагодження програми або встановлення служби може бути дуже багато часу, і це або час зазначеного розробника, або час спеціалізованого персоналу.
додано Автор Jeff, джерело
@R .. Я регулярно запускаю програму, потім додаю до неї відладчик, щоб я міг читати його внутрішній стан, призупинити його виконання і зробити його виконанням довільного коду. Для цього потрібний доступ адміністратора. Моя продуктивність знизиться, якщо ви забороните мені робити це.
додано Автор jagsler, джерело
@Luc Краще надати адміністраторам доступ, оскільки це дешевше. Це означає, що вам не доведеться зайняти 3-4 людини на повний робочий день, щоб працювати з машинами розробника та подавати скаргу на політику безпеки.
додано Автор jagsler, джерело
@R .. Отже, мій веб-браузер, який запускає java-script, повинен мати доступ до внутрішнього стану іншої програми в моїй системі, наприклад, до менеджера паролів? Я не бачу жодних проблем із безпекою ....
додано Автор jagsler, джерело
@R, можливо, захочете прочитати на "devops", ви побачите, що сучасні розробники мають дуже обгрунтовані мотиви для бажання доступу адміністратора. Для мене особисто, не маючи контролю над своєю машиною, є величезний червоний прапор. Якщо сказано заздалегідь, я відкину пропозицію про роботу, якщо ні, мої перші два тижні будуть моїми останніми.
додано Автор Douwe, джерело

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

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

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

4
додано
Це не відповідає на запитання. Вона не дає жодного пояснення, якщо і чому це буде "типовим".
додано Автор Sean, джерело

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

Час від часу вони організовують соціальну подію, наприклад, грають у боулінг. Приєднання було безкоштовним, але ви повинні були додати своє ім'я до списку у файлі Excel, розміщеному у спільній папці. Ця папка була присвячена соціальним подіям, нічого іншого.

Отже, ви хочете грати в боулінг? Ви хочете додати своє ім'я до цього списку? Ohhhhhhhhhh, дорогий ... Це не так, як вони можуть дозволити всім редагувати цей файл, чи не так? Ви повинні попросити відповідні дозволи.

Це процедура:

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

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.

Тепер.

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

Отже, до чого призвів цей підхід? Якщо ви хотіли вкрасти все, що компанія зробила, ви просто повинні були принести USB-диск і підключити його до комп'ютера. Немає доступу до папки "Confidential_Documents"? Просто попросіть, вони підпишуть. А якщо це терміново? "Привіт, мені потрібен цей документ, але я не можу отримати доступ до нього. Чи можете ви дати мені свій пароль?"

Таким чином, ця “модель безпеки” була неймовірно повільною, незграбною і неприємною, і вона взагалі не захищала їхні властивості, але принаймні ніхто не міг легко заплутатися з учасниками боулінгу ( обов'язковий xkcd ).

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

4
додано

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

Те, що керівництво придумало, було підходом двох віртуальних машин .

Однією з наших віртуальних машин була машина основного бізнесу з електронною поштою, веб-доступом і пакетом Microsoft Suite. Це задовольняло необхідність спілкування.

Друга віртуальна машина мала права місцевого адміністратора , але повністю відключена від Інтернету . Таким чином, ми не могли скачати нічого на цій машині. (Хоча ми все ще можемо завантажити його з іншого та скопіювати завантаження через ..) Ми все ще отримали доступ до внутрішніх сайтів і списку білих списків, які використовує візуальна студія (Nuget, Symbols і т.д.

Цей підхід залишив ІТ-відділ задоволеним з точки зору їх безпеки, а також надав нам доступ до адміністратора.

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

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.

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

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

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

3
додано

Цю проблему ми вирішили за допомогою Віртуальної машини .

Кожен розробник має звичайний обліковий запис користувача без прав адміністратора. Усередині цього облікового запису користувача існує віртуальна машина без доступу до Інтернету. Всередині віртуальної машини розробник може запустити свою програму з правами адміністратора.

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

3
додано
Давайте просто припустимо, що операційній системі потрібні (локальні) права адміністратора для запуску середовища розробки. Вищезгадані Microsoft Visual Studio і SQL Management Studio залежать від привілеїв адміністратора. Іншою річчю, на яку ці програми покладаються в значній мірі (з точки зору оновлень, онлайнової допомоги, керування джерелами та можливим продовженням віків), є підключення до Інтернету . Маючи віртуальну машину без підключення до Інтернету, але надаючи (місцеві) права адміністратора, означає перемикати рок із жорстким місцем.
додано Автор Jeff, джерело

Незважаючи на те, що MS-Windows NT з моменту свого створення є багатокористувацькою системною системою, її не дуже легко керувати таким чином, і розробники (включаючи Micosoft) все ще ігнорують ідею розділення привілеїв. Цей вид контролю доступу погано задокументований, як правило, не відзначається в навчанні, часто важко отримати доступ через інтерфейс користувача, важко перевірити, відсутність шаблонів/інструментів для застосування розділення.

Чесно кажучи, навіть у системах Unix/Linux, я бачу багато розробників, які не в змозі використати розділення привілеїв належним чином як для реальних користувачів, так і для послуг. Але на будь-якій платформі, розміщення бар'єрів на шляху розмежування привілеїв розробників є ще більш контрпродуктивним для безпеки, ніж надання їм повних (локальних) адміністративних привілеїв

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

про те, що місцевий доступ адміністратора було видалено, було короткий час

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

На всіх робочих станціях є принаймні 2 основні антивірусні програми

Це дуже наївний підхід до захисту цілісності цих систем і малює картину того, з чим ви маєте справу.

Там не існує багато альтернативних варіантів

Отримання в дискусії про це, ймовірно, не буде дуже продуктивним на даний момент.

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

2
додано
.... а потім я згадав, чому я уникаю програмування на Microsoft Windows :)
додано Автор bpapa, джерело
Фактично неправильно. Visual Studio буде працювати без привілеїв місцевого адміністратора, і насправді це за замовчуванням . І якщо ви привласните привілеї налагодження для облікових записів розробника, це означає, що Visual Studio не потрібно буде підвищувати до адміністративних дозволів, що часто. Чи можна цілком уникнути? Ні, для розробників драйверів буде потрібний адміністраторський доступ, наприклад.
додано Автор Martin Marconcini, джерело
Однією з причин, чому Visual Studio ці права адміністратора полягає в тому, щоб дозволити налагодження процесів, що належать іншим користувачам IIS, традиційно працює під системним обліковим записом. Як тільки розробник налагоджує інший процес, вони могли б відключити вірусні шашки тощо. Звідси вибір між не дозволяючи розробникам використовувати відладчик і довіру до розробників .....
додано Автор Gowri, джерело
@ mg30rg: DEBUG_SE насправді означає "Відлагодження чужого процесу".
додано Автор Joshua, джерело
@ mg30rg: Правда, однак, якщо розробник працює над кодом, який зазвичай виконується як admin, то він все одно має адміністратора.
додано Автор Joshua, джерело
@ mg30rg: Застарілий Kestrel. Тепер він працює під ім'ям розробника.
додано Автор Joshua, джерело
Visual Studio буде працювати без привілеїв адміністратора, але в деяких випадках він не буде працювати належним чином без привілеїв адміністратора. Так, не потрібні всі права локальних адміністраторів для належної роботи, але потрібні певні привілеї адміністратора. DEBUG_SE для налагодження, управління послугами для - керування службами, створення прав для баз даних, і я міг би продовжувати віки. Звичайно, можна зв'язатися з командою безпеки і вимагати певних прав, які потрібно, скажімо, щодня, але чи знаєте ви, як це називається? Продуктивність-вбивство.
додано Автор Jeff, джерело
@Joshua І що ви думаєте, потрібно для налагодження служби Windows, що працює під обліковим записом системи, наприклад? Цей сценарій далекий від незвичайного в розвитку Windows.
додано Автор Jeff, джерело
@ Джошуа М-ключ, і як щодо розвитку ASP.Net? Для цього потрібно налагодити процес, запущений і запущений під службою IIS, що працює під обліковим записом мережевої служби?
додано Автор Jeff, джерело
@Joshua Kestrel навряд чи IIS.
додано Автор Jeff, джерело

Виділіть свої мережі

Ви повинні мати відносно ізольоване середовище для розвитку, тестування, виробництва та бізнесу. Це дозволяє вашим розробникам мати привілеї, де вони потрібні.

Правильна сегрегація запобігає несанкціонованим змінам, обмежує поширення шкідливих програм і перешкоджає ексфільтрації даних.

Що відбувається де?

Розвиток

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.

Комп'ютери запускають середовища інтегрованої інтеграції (IDE), початкові сховища та необхідні програми/рамки для ваших програм. Спеціальний інструмент співпраці або інші конкретні програми 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. Обмежувальні правила брандмауера/ACL існують між середовищами
  4. Стандартні заходи безпеки, такі як брандмауер, веб-проксі, IDS/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
додано

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

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

0
додано