Дозволи для Windows для розробників?

Я працюю в компанії Fortune 500 як розробник програмного забезпечення для Windows в науково-дослідних розробках. В даний час корпоративний ІТ готується до розгортання всієї компанії Win7, і, як частина цього, вони прагнуть повністю заблокувати права адміністратора на всіх скриньках (включаючи наші робочі станції розробників).

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

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

1. з’ясувати, де намалювати лінію на піску
2. підтримати мою позицію.

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

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

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

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

Оскільки ви спеціально збираєтесь до Windows 7, вам слід наполегливо наполягати на тому, щоб бути адміністратором у власних скриньках. Є дві дійсно вагомі причини, щоб не дозволяти розробникам бути адміністраторами:

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

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

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

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

Вони можуть допомогти:

• http://www.slate.com/id/2226279/pagenum/all/
• /server/232416/should-dev-be-admin-on-their-computer
• http://avecto.com/blog/2010/09/the-pros-and-cons-of-windows-7-application-control-with-applocker/

PS: Найкраща удача!

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

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

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

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

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

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

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

З точки зору ІТ та перспективи розвитку багато компаній вирішують проблему таким чином:

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

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

Подумайте про те, щоб дати розробникам два акаунти.

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

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

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

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

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

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

1. Програмісти отримують доступ до локального адміністрування на своїй машині розвитку.
2. Машини розробки не підключені до мережі компанії.

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

Тепер ви знайдете якесь офіційне джерело про це? Я думаю, це залежить від того, кого ти вважаєш офіційним . Думка з цього приводу в основному одностайна. Але це так добре зрозуміло, що це рідко заявляється. Це трохи схоже на запитання: " Чи повинен мій автомобіль мати стояночне гальмо? " Ви не збираєтеся знайти авторитетних джерел, які говорять з теми, тому що в них краще робити, і всі вже знають цю відповідь.

Чи можете ви використовувати віртуальне середовище?

Якщо ви не займаєтесь великою графікою, то запуск MSVC у vmware або virtualbox чудово (якщо у вас багато оперативної пам'яті), ви можете мати адміністратора у віртуальному середовищі, а встановлення "їх" заблоковано