Всі знають, що один з найбільш важливих принципів мережевої безпеки полягає в тому, щоб надавати якомога менше прав: надавати звичайним користувачам тільки ті права, які безпосередньо необхідні їм для роботи, і не більше того. Наприклад, якщо звичайним користувачам не потрібен доступ до даних, що зберігаються в ресурсі Accounting, не давайте їм ніяких прав на цей ресурс.
Принцип «як можна менше привілеїв» - це більше ніж принцип безпеки, це рятівний засіб для адміністратора. Причина цього, полягає в тому, що користувачі - це цікаві створення, які пробують все підряд. Дайте користувачеві права локального адміністратора на їх комп'ютер, і вони спробують все безліч речей, таких як установка додаткового програмного забезпечення, зміна конфігураційних налаштувань, і навіть залізуть в реєстр, щоб подивитися, що там можна налаштувати для кращої роботи їх комп'ютера. З точки зору адміністратора це може бути катастрофою, тому що неправильне налаштування може пошкодити деякі додатки, або навіть вивести комп'ютер з ладу. Потім користувач починає кликати на допомогу, і у вас як у адміністратора є два варіанти: або очистити їх машину і заново встановити операційну систему з стандартного образу вашої компанії, або марно витратити час, годинами намагаючись виявити причину проблеми. Другий варіант - це зазвичай порожня трата часу, на противагу політиці компанії, користувач зберігав важливі файли на своєму комп'ютері і не на мережевому ресурсі. А перший варіант - це практично плювок проти вітру, ви заново встановлюєте систему користувача, а він знову безперешкодно може її вивести з ладу.
Group Policy один із способів визначення того, що може, а що не може користувач робити зі своїм комп'ютером. Але що робити, якщо політики компанії (або культурні або політичні чи інші реалії) вимагають необхідність можливості для користувача самостійно налаштовувати свою машину? В цьому випадку у вас є два варіанти, або давати користувачам права локального адміністратора, або ні. Оскільки перший варіант викликає проблеми, про які я розповів вище, давайте розглянемо можливості другого варіанту.
Незручності при роботі не під обліковим записом адміністратора
Якщо ви оберете не робити обліковий запис користувача в домені локальним адміністратором на його машині, то користувач починає голосно скаржитися на ряд причин, які включають наступне:
- При спробі установки програмного забезпечення на свою машину, процес установки зазвичай припиняється з повідомленням про помилку різного виду.
- Коли вони намагаються встановити дату і час Control Panel, з'являється діалогове вікно, яке повідомляє, що у них недостатньо прав, щоб це зробити.
- Коли вони намагаються налаштувати Power Options в Control Panel, вони можуть змінювати налаштування в GUI, але при натисканні кнопки OK, щоб зберегти зміни з'являється повідомлення Access Denied (Доступ заборонений).
- Коли вони хочуть відкрити доступ до папки на їх машині, щоб інші користувачі отримали доступ до їх файлів, то вони не можуть цього зробити, тому що у вікні властивостей відсутня закладка Share.
Останні три скарги досить легко обійти (я покажу це свого часу), але проблема неможливості установки програмного забезпечення досить складна з кількох причин. По-перше, більшість програмного забезпечення (включаючи багато додатків Microsoft) вимагають права локального адміністратора для того, щоб їх можна було встановити для будь-яких версій Microsoft Windows. На основі цього ми стикаємося з фактом, що деяким програмам необхідно спеціальні області для запису в файлову систему і реєстр. Але це несправжня причина того, що додаткам необхідні права адміністратора для установки-реальна причина полягає в тому, що розробники зазвичай дуже ледачі, щоб подбати про створення пакетів для установки, які будуть також працювати не під обліковим записом адміністратора. Все це означає додаткову роботу для розробника (яку більшість розробників намагаються уникнути). Але це також означає розробку цих додатків, працюючи також не під обліковим записом адміністратора, що знову призводить до необхідності багато про що подбати - набагато простіше розробляти додаток, коли ви увійшли в систему, як адміністратор.
Установка програмного забезпечення не під обліковим записом адміністратора
На жаль, деякі програми після того, як вони були встановлені з використанням команди Runas як і раніше не будуть правильно працювати, коли ви запустите їх з правами звичайного користувача. Це відбувається тому, що коли ви використовуєте команду Runas для установки чогось, деякі важливі настройки записуються в профіль локального адміністратора, а не в профіль користувача, який увійшов в систему зараз. І звичайно, це викликає проблеми, коли ви намагаєтеся пізніше запустити встановлену програму як звичайний користувач. Знову ж, розробник, який написав програму, повинен був подбати про вирішення цієї проблеми, але навіщо турбуватися про це, якщо все одно все запускають Windows з правами адміністратора?
Я сам стикався з такою проблемою кілька разів як з додатками сторонніх виробників, так і з додатками .NET Framework, і це засмучує. Наприклад, недавно я хотів отримати електронний курс з навчання розробці в ASP.NET від Microsoft. На жаль, з деяких причин я не міг завантажити курс (сам додаток .NET), якщо я входив в систему з використанням облікового запису користувача домену, тому я відкрив посилання в Internet Explorer використовуючи права локального адміністратора і благополучно завантажив курс. Але коли я спробував запустити курс локально на моїй машині, він не запустився, коли я спробував це зробити з правами звичайного користувача. Тому я спробував використовувати Runas, щоб запустити курс з правами адміністратора, але він все одно не запустився. Зрештою, я вийшов із системи, зайшов з правами адміністратора для того щоб почати працювати. Кошмар! Може бути, якщо я досліджував проблему далі, я б з'ясував чому це не працювало з першого разу, але це добре ілюструє, чому більшість людей весь час працюють в Windows з правами адміністратора-якщо ви працюєте ні з правами адміністратора, ви можете витратити купу часу , щоб змусити речі працювати.
Відволікаючий маневр
До того ж-і це те, що тільки недавно стало розглядатися експертами з безпеки-може виявитися, що вся ця проблема з мінімумом привілеїв, всього лише відволікаючий маневр. Звичайно, якщо ви зайшли адміністратором, і ви йдете в інтернет, повз різних бридких сайтів і завантажили вірус, то це вірус отримає контроль над вашою системою з вашими власними правами, тобто з правами адміністратора. А якщо ви звичайний користувач, і заходите на той же самий сайт, то вірус отримує обмежений доступ (рівень привілеїв користувача домену) до всієї системи, тому потенційна шкода буде зменшений. Насправді все набагато складніше. Якщо шкідливий код, який ви завантажили - це черв'як, який використовує слабкість в службі Windows, то не важливо під який обліковим записом ви зайшли.
До того ж, дуже розумні хакери вже працюють над створенням нових можливостей, завдяки яким хакерський код зможе захопити систему навіть при роботі в ній з мінімальними правами. Тому що виходить можливість Least-privilegeUserAccount (LUA) Longhorn (тепер Windows Vista), яка відмовляється від застарілих груп Power Users і дозволяє установку і запуск LUA-сумісних програм з використанням прав звичайних користувачів, в дійсності не панацея для проблем безпеки, що оточують використання мінімуму привілеїв . Ви може посперечатися на свій останній долар, що погані хлопці знайдуть нові можливості для злому вашої системи.
Тому, поки мінімум привілеїв - це непогане рішення. Але так не буде тривати довго. Але інакше кажучи, ви можете як і раніше розглядати стратегію «мінімум привілеїв» як простий засіб проти хакерів.
Деякі обхідні рішення
Поки ми тут, зауважте, що дерево папок в IE відображає вузол Control Panel. Виберіть цей вузол і в правому вікні ви побачите аплети Control Panel. Спробуйте змінити дату і час - це спрацює! Оскільки IE запущений з правами адміністратора, всі програми, до яких ви звертаєтеся з його допомогою, включаючи Control Panel, також будуть запускатися з цими правами. Те ж відбувається і в разі з Power Options, Network Connections, System, і іншими аплету, до яких ви мали обмежений доступ, при роботі над ролі адміністратора.
Існує однак ще більш простий спосіб (спосіб з IE працює, але трохи плутано, якщо iexplore.exe не в системній директорії), для якого треба зробити наступне:
- Вийдіть з системи і зайдіть адміністратором.
- Відкрийте Windows Explorer
- Виберіть Tools. потім Folder Options. потім View. і поставте галочку в поле "Launch folder windows in a separate process"
- Закрийте Windows Explorer і вийдіть із системи.
Тепер, коли ви зайдете знову як простий користувач, ви можете натиснути правою кнопкою миші на explorer.exe (або його ярлику), вибрати "Run as ...", вказати повноваження адміністратора, і Windows Explorer тепер запуститься з правами адміністратора.
висновок
Запуск Windows не під обліковим записом адміністратора - це складне завдання, і до тих пір, поки вона вносить свої переваги, можна терпіти всі її недоліки. До того ж, ці переваги не такі великі, як говорять багато фахівців з безпеки, і вони будуть лише працювати до тих пір, поки погані хлопці, не знайдуть нові способи обійти систему безпеки.
Який ви має досвід у вирішенні даної проблеми? А ви змушуєте ваших користувачів працювати не під обліковими записами локальних адміністраторів? З яким труднощами ви при цьому зіткнулися? І як ви спробували вирішити ці проблеми? Напишете мені про все це, і я зберу всі ваші відповіді в наступній статті на WindowsNetworking.com, де я знову підніму проблему при роботі не під обліковим записом адміністратора.