Новости

У їжакових рукавицях

  1. Зміст статті Технології безпеки Windows Server 2012
  2. Інтеграція DAC і RMS
  3. біометрічна аутентіфікація

Зміст статті

Технології безпеки Windows Server 2012

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

Сьогодні дуже популярна технологія BYOD (Bring Your Own Device), коли співробітники використовують в роботі свої особисті пристрої, за якими стежать самостійно. Це зручно всім: компанія позбувається від постійної турботи закуповувати і оновлювати обладнання, а користувачі працюють з улюбленими і сучасними гаджетами. Однак заради зручності користувач може відключити службу установки оновлень, переконфігурувати брандмауер або працювати з застарілими антивірусними базами. Це призводить до збільшення ризиків, такі пристрої несуть потенційну небезпеку для інших систем. Щоб уникнути проблем при підключенні особистих пристроїв до корпоративної мережі, слід контролювати їх стан.

Нова функція Network Access Protection, що з'явилася в Win2k8, перевіряє ОС на відповідність прийнятим політикам. На основі аналізу стану для конкретного пристрою можна обмежити доступ, дозволити повний доступ тимчасово або постійно. Всі події журналіруются, і адмін завжди має в своєму розпорядженні свіжою інформацією про проблеми.

У карантинної підмережі розташовуються корекційні сервери (Remediation Server), що надають ресурси для усунення виявлених недоліків (сервер оновлень WSUS, антивірусна база). Після усунення проблем система повторно підключається і перевіряється, якщо все в нормі, вона отримує повноцінний доступ в мережу. У процесі роботи стан системи контролюється постійно, і якщо воно перестає задовольняти вимогам політик, то пристрій знову переводиться в карантин (або виконується будь-яке інше дію, запропоноване адміном). По суті, контроль стану і карантин - це вся роль NAP, все інше реалізується сторонніми механізмами. При налаштуванні NAP використовується кілька механізмів примусу (DHCP, VPN, IPsec, IEEE 802.1x та інші).

На віддаленій системі встановлюється клієнт NAP, що складається з агента NAP, агента стану системи (Windows Security Health Agent) і клієнта примусу (NAP Enforcement Client). Останній і відповідає за взаємодію з механізмом примусу. Зібрані дані клієнт відправляє серверу мережевих політик (NPS, Network Policy Server) у вигляді SHV-маркера (System Health Validators).

Агент вже включений в усі версії Windows від XP SP3, підтримується інтеграція з Cisco Network Admission Control (NAC). Сторонні фірми пропонують клієнти NAP для OS X і Linux і можуть додавати необхідну функціональність в NAP. Наприклад, рішення Symantec Endpoint Protection містить додаткові модулі, що дозволяють перевіряти стан за допомогою NPS.

Роль сервера «Служби політики мережі та доступу» можна використовувати для розгортання власне служби NPS або сервера і проксі-сервера RADIUS, що виконує авторизацію при запитах на підключення з боку клієнтів RADIUS (комутатори Ethernet з підтримкою 802.1X, хотспоти). Всі настройки проводяться за допомогою диспетчера сервера або утиліти netsh (контекст netsh nps, всі команди можна дізнатися в документації ).

У Win2k8R2 служба NPS отримала можливість використовувати кілька конфігурацій SHV, що дозволяє створювати свої політики для систем, що підключаються по різних каналах (LAN, VPN). Також з'явилися нові шаблони, що спрощують створення і експорт елементів конфігурації NPS.

У Win2012 служба маршрутизації та віддаленого доступу, яка раніше була частиною NPS, виведена в окрему роль сервера віддаленого доступу. Зроблено це, щоб зменшити плутанину при розгортанні. Для ролі сервера NPS знадобиться фізичний або віртуальний (Hyper-V) сервер, кластери не підтримуються.

Установка сервера NPS проводиться за допомогою майстра додавання ролей і компонентів, просто відзначаємо пункт «Служби політики мережі та доступу» і слідуємо його вказівок. Роль містить три служби ролей:

  • сервер політики мережі - використовується для централізованого управління доступом до мережі через різноманітні сервери доступу, включаючи точки бездротового доступу, VPN, сервери віддаленого доступу і 802.1X-комутатори;
  • центр реєстрації працездатності (HRA) - компонент, який відповідає за випуск сертифікатів працездатності для клієнтів, що проходять перевірку політики. Використовується тільки з примусовим методом протоколу IPsec;
  • протокол авторизації облікових даних вузлів (HCAP) - дозволяє об'єднати рішення для захисту доступу до мережі від MS з сервером контроль над доступом від компанії Cisco.

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

Всі установки виробляються з консолі «Сервер групових політик». Початкові налаштування задаються за допомогою готового сценарію, просто вибираємо потрібний зі списку і слідуємо вказівкам майстра. Політики дозволяють задати групи (Windows, комп'ютерів або користувачів), HCAP (групи користувачів і розміщення), обмеження по днях тижня і часу, типу посвідчення, класу IP, ОС та архітектури, критерієм політики працездатності та іншими параметрами.

У кожного контролера домену, який працює на Win2012, повинна бути та ж настройка політики адміністративних шаблонів (Конфігурація комп'ютера -> Політики -> Адміністративні шаблони -> Система -> KDC -> Підтримка динамічного контролю доступу та захисту Kerberos).

У Win2012 також додалася можливість використовувати PowerShell для установки і настройки деяких параметрів ролі NPS, тому багато операцій можна виконати з консолі. Ставимо і дивимося новий набір з 13 командлетів ).

PS> ADD-WindowsFeature NPAS-Policy-Server -includemanagementtools PS> Import-Module NPS PS> Get-Command -Module NPS

Наприклад, командлети Export / Import-NPSConfiguration дозволяють зберегти і відновити конфігурацію NPS-сервера. Вони замінять netsh nps export / import, що виконують аналогічну функцію. Виклик простий. зберігаємо:

PS> Export-NpsConfiguration -Path C: NPSTemp -Path Npsconfig.xml

Файл містить дані RADUIS-клієнтів, тому необхідно подбати, щоб ніхто не отримав до нього доступ. Тепер на іншому сервері імпортуємо, просто вказавши на файл.

PS> Import-NpsConfiguration -Path C: Npsconfig.xml

Як і netsh, командлети PowerShell не підтримують перенесення налаштувань шаблонів. Це доступно через інтерфейс консолі.

Початкові налаштування NPS задаються за допомогою готового сценарію Початкові налаштування NPS задаються за допомогою готового сценарію   Визначаємо параметри безпеки клієнта Визначаємо параметри безпеки клієнта

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

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

Захистити вміст можна за допомогою служби управління правами (Rights Management Services), але вона знімає тільки частина проблем. Більш глобально завдання управління доступом і аудиту покликана вирішити технологія динамічного управління доступом (Dynamic Access Controls, DAC). Технологія базується на трьох основних поняттях:

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

Реалізована інтеграція DAC зі службою RMS, що дозволяє в реальному часі захищати документи, яким присвоєно відповідний тег. Налаштування спрощує автоматичне тегування документів, яке створюється за допомогою правил, що настроюються за допомогою диспетчера ресурсів файлового сервера (File Server Resource Manager).

Для реалізації DAC система безпеки Win2012 отримала новий механізм затвердження claims, такі твердження існують для ресурсів, користувачів і облікових записів комп'ютерів. При вході в систему крім ідентифікатора безпеки SID (Security Identifier) ​​облікового запису в маркер додаються claims (переглянути їх можна, запровадивши «whoami / claims»). Ось ці твердження, разом з даними про участь в групах, і використовуються при доступі до об'єктів файлової системи. При цьому старі механізми нікуди не зникли. Спочатку застосовуються права доступу до мережного ресурсу, потім NTFS і, нарешті, вступає в роботу DAC.

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

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

Політики задаються централізовано на рівні домену, поширюються за допомогою GPO і вказуються в настройках конкретного ресурсу. У першому випадку установки задаються в консолі центру адміністрування Active Directory (ADAC, Active Directory Administrative Center), в якому знаходиться спеціальний підрозділ, який містить вісім покрокових налаштувань. На кожному необхідно буде заповнити запропоновані майстром поля.

На кожному необхідно буде заповнити запропоновані майстром поля

Налаштування класифікації документів

Першим йде настройка тверджень, де є понад 100 атрибутів Active Directory, кожен з яких може бути присутнім в claims. Для зручності пошуку запропонований фільтр. Наприклад, атрибут departament описує відділ, в якому працює користувач. Послідовно відбираємо потрібні, створюючи claims. Поле «Запропоновані значення» дозволяє вказати необхідні значення атрибутів. Наприклад, для departament прописуємо назви відділів, для яких будемо створювати політики.

Другим кроком йде настройка властивостей ресурсів (Resource Properties), що дозволяють класифікувати конкретні файли і папки. За замовчуванням вже створено кілька властивостей, які потрібно відредагувати і включити або додати нові. Переходимо до кроку три - створення централізованого правила доступу (Central Access Rule), де вибираємо критерії цільових ресурсів і дозволу. Процес простий: вибираємо зі списків властивості, вказуємо значення і задаємо права (система запропонує дозволу, їх можна відредагувати і застосувати). У підсумку всі ресурси, які будуть позначені відповідним тегом (зазначеним в значенні), будуть потрапляти під правило. Так як правил може бути кілька, то для зручності застосування на наступному кроці їх об'єднують в політики (Central Access Policies).

Так як правил може бути кілька, то для зручності застосування на наступному кроці їх об'єднують в політики (Central Access Policies)

Для настройки динамічного контролю доступу необхідно пройти вісім кроків

Після створення політик вони повинні бути опубліковані на файловому сервері. Для цього викликаємо редактор групової політики, переходимо в «Конфігурація комп'ютера -> Політики -> Конфігурація Windows -> Файлова система -> Централізована політика доступу». Вибираємо в контекстному меню пункт «Управління централізованими політиками доступу» і в списку створені раніше політики, які необхідно застосувати. Власне, це все.

Для управління аудитом слід перейти в «Конфігурація розширеної політики аудиту -> Політика аудиту -> Доступ до об'єктів», де в Win2012 з'явився новий пункт «Аудит звірки з централізованою політикою доступу».

Тепер застосовуємо політику. Переходимо в властивості документа / каталогу, вибираємо «Додатково» і переходимо у вкладку «Централізована політика», вибираємо в списку потрібну політику.

Традиційно нова можливість отримала свій набір з 58 командлетів PowerShell, які відносяться до модулю Active Directory ( goo.gl/304CC ). Наприклад, за допомогою Get-ADCentralAccessPolicy можемо отримати інформацію про всі центральних політиках доступу.

PS> Get-ADCentralAccessPolicy -Filter * PS> Get-ADCentralAccessPolicy -Filter *   Динамічним контролем доступу можна управляти за допомогою командлетів PowerShell Динамічним контролем доступу можна управляти за допомогою командлетів PowerShell

Інтеграція DAC і RMS

Для повноцінного захисту конфіденційної інформації необхідно застосовувати шифрування. Інтеграція DAC і RMS дозволить все виконати автоматично на основі тегів змісту документа, причому налаштування дають можливість зашифрувати і раніше створені документи. Для роботи слід активувати властивість ресурсів Impact, що дозволяє класифікувати ресурси по одному з трьох значень важливості. Далі в консолі диспетчера ресурсів файлового сервера, в розділі «Управління класифікацією -> Правила класифікації» (Classification Management -> Classification Rules) створюємо правила, в яких вказуємо тип і розташування файлів, метод класифікації (Windows PowerShell, папки або вмісту) і власне рядки або регулярні вирази, збіги з якими будуть активувати правило. Тут же вказуємо, яке значення привласнити доступним атрибутам. У списку можна побачити всі створені раніше атрибути, нас в даному випадку цікавить Impact. Щоб привести механізм в дію, переходимо в «Завдання управління файлами», де створюємо нову задачу. Вказуємо назву, папки, налаштовуємо оповіщення і розклад. У вкладці «Дія» вибираємо «Шифрування RMS» і доступний шаблон RMS. У вкладці «Умова» слід вказати властивість файлу, яке призведе до виконання завдання.

Сьогодні організація може використовувати десятки серверів і додатків, розміщених на різних платформах, до яких необхідно забезпечити безпечний доступ. Якщо додатки різнорідні і для ідентифікації використовують різні стандарти, це стає проблемою. Microsoft пропонує для її вирішення сервіс Windows Azure AppFabric Access Control Service (ACS, goo.gl/2dmqR ), Що дозволяє реалізувати механізми федеративної авторизації і обробку запитів на основі декларативних правил. Сервіс, до яких забезпечується доступ, не обов'язково повинен працювати в середовищі Azure, це може бути будь-яка (в тому числі не Windows) платформа або додаток, що працює на популярних мовах, включаючи Java, Ruby, PHP. Як зрозуміло з назви, сервіс відноситься до Azure Fabric і виступає в ролі посередника між додатком і провайдерами ідентифікацій (identity providers) - базою даних користувачів. ACS використовує принцип ідентифікації на основі заявок (claims-based identity), кожна сутність в процесі ідентифікації грає одну або більше канонічних ролей: суб'єкт (subject), провайдер ідентифікації (identity provider), довіряє сторона (relying party) і провайдер федерації (federation provider ).

Підтримуються стандартні механізми аутентифікації (OpenID, OAuth WRAP, OAuth 2.0, WS-Trust і WS-Federation), інтеграція з Windows Live ID, Active Directory, Google, Yahoo !, Facebook і так далі. Сам AppFabric Access Control (ASC) базується на Windows Identity Foundation (WIF, розширення Microsoft .NET Framework) і являє собою сервіс, спеціально створений для забезпечення безпеки хмарних обчислень. Модель WIF відокремлює додаток від деталей того, як відбувається аутентифікація, і від низькорівневих деталей, пропонуючи зручну абстракцію, що дозволяє просто вказувати зовнішній механізм. Всі установки можна виконати за допомогою спеціального майстра в Visual Studio, писати код не потрібно. Для новачків будуть цікаві приклади , Що дозволяють розібратися, як інтегрувати ACS з веб-сервісами.

Windows Azure AppFabric складається з трьох основних компонентів: Access Control (управління доступом), Bus Service (Сервіс шини) і Cache (Кеш - Асоціативний пам'ять).

біометрічна аутентіфікація

Вимоги до складності пароля з шкірних днем ​​посілюються, такоже растет Кількість сервісів, з Якими доводитися працювати корістувачеві. Все це утріматі в Голові Важко, та й співробітнікі часто забувають паролі, навантажуючі саппорт. Тому нерідко Користувачі йдут на Спрощення, вікорістовуючі одну комбінацію на різніх ресурсах. Досить зламаті один пас, и отрімуємо доступ до Всього Іншого. Вихід два - використовуват біометрічну або апаратно (смарт-карти) аутентіфікацію. Це як мінімум Зручне, Аджея Вже НЕ нужно Нічого запам'ятовувати. При біометрії все необхідне у користувача завжди з собою: для ідентифікації використовуються унікальні характеристики людини, найбільш популярний з методів відбиток пальця. Раніше підтримка засобів біометричної аутентифікації забезпечувалася спеціальними драйверами і ПО, що поставляються виробниками. Для програмістів виробники пропонували власний SDK (відомі як комерційні, так і опенсорсний рішення). Кожен реалізовував механізм як хотів, єдиного стандарту не було. Починаючи з Windows 7, Microsoft пропонує свій варіант - спеціальний фреймворк Windows Biometric Framework (WBF, goo.gl/QzYZK ).

Керують процесом за допомогою чотирьох об'єктів групової політики, які знаходяться в «Конфігурація комп'ютера -> Політики -> Адміністративні шаблони -> Компоненти Windows -> Біометрія». Змінилася в Win2012 / 8 і підтримка смарт-карт: з'явилися віртуальні смарт-карти, змінився порядок взаємодії з користувачем і логіка запуску / зупинки служби.

За настройку біометрії відповідають чотири групові політики

Механізми управління доступом, що застосовуються в різних ОС, сьогодні навряд чи можна назвати достатніми. Нововведення, які з'явилися в Win2012, дозволяють на порядок знизити ризики і забезпечити максимальну безпеку даних. Справа залишилася за малим - їх впровадити.

Сергій Яремчук, [email protected]

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

Или позвоните нам по телефонам: (048) 823-25-64

Организация (обязательно) *

Адрес доставки

Объем

Как с вами связаться:

Имя

Телефон (обязательно) *

Мобильный телефон

Ваш E-Mail

Дополнительная информация: