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

Перш ніж перейти до розгляду механізмів аутентифікації і
авторизації, необхідно визначитися з протоколами взаємодії
рівнів нашої системи. При розробці з використанням. NET Framework у
нас є дві основні можливості організації віддаленого взаємодії
об'єктів -. NET Remoting та Web Services. Не зупиняючись на детальному
аналізі цих двох підходів, виберемо SOAP як протокол
взаємодії компонент бізнес-логіки з рівнем користувальницького
інтерфейсу. Природним чином для такого сценарію в якості Сервера
Програма буде виступати Internet Information Server (IIS) в
поєднанні з технологіями ASP.NET, Web Services і Enterprise Services.

Такий підхід дозволить:

Аутентифікація і авторизація

У рамках запропонованого сценарію система аутентифікації та авторизації
буде будуватися на принципі використання контексту безпеки
аутентифікованим користувача Windows домену. Це дозволить:

По відношенню до оригінального, викликає Web Service, користувачеві ми
хочемо здійснювати авторизацію по. NET ролям і / або за Windows ACL. У
випадку використання режиму Windows ayтентіфікаціі в ASP.NET немає
необхідності конфігурувати імперсонацію. Для перевірки за. NET ролям
WindowsPrincipal об'єкт являє контекст викликає, який може
бути отриманий таким чином:

 

WindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal);
if ( wp.IsInRole("PowerUser") )
{
/ / Користувач авторизований і включений в роль PowerUser
}

Модуль FileAuthorizationModule здійснює перевірки ACL по відношенню
до оригінального зухвалому для типів файлів, які відображені в IIS
для aspnet_isapi.dll фільтра. Для статичних файлів, таких як. Jpg,
. Gif і. Htm, IIS здійснює перевірку доступу, використовуючи ідентиті
оригінальному викликає користувача. Ви повинні забезпечити достатню
гранулювання Windows груп у відповідність до потреб системи
безпеки. Безпека, заснована на. NET ролях, визначає
приналежність користувача до ролі по його входженню в Windows групу.
Windows група, яка використовується для управління ролями, може бути локальною
для цього комп'ютера або групою домену.

 

З'єднання з базою даних

Транзакції на однорідних джерелах (в рамках однієї бази даних)
можуть реалізовані через звернення до відповідних класів. NET
Framework. При необхідності використання розподілених транзакцій при
взаємодії із зовнішніми програмами можуть бути використані служби
COM + додатків і координатор розподілених транзакцій (DTC). У цьому
випадку. NET компоненти повинні використовувати класи Enterprise Services і
встановлюватися в COM + додатки.

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

Для забезпечення такого з'єднання з базою даних будемо використовувати
режим інтегрованої аутентифікації в SQL Server і один обліковий запис
в Windows. Режим інтегрованої аутентифікації в SQL Server дозволить
уникнути зберігання в рядку з'єднання облікових даних.

Примітка

Можливо застосування варіацій такого підходу, коли сервер додатків
автентифіковані на сервері баз даних під різними обліковими записами
для різних груп вихідних користувачів (наприклад – привілейовані
користувачі, звичайні користувачі, адміністратори). У цьому випадку пул
з'єднань буде підтримуватися на рівні груп користувачів

Загальна схема реалізації системи безпеки

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

 

Аутентифікація

Авторизація

Захист каналів даних

 

Конфігурування підсистем безпеки

Клієнтський додаток

 

Отримання контексту безпеки
користувача

Користувач здійснює інтерактивний
вхід в Windows домен при завантаженні
операційної системи. Credentials
користувача за замовчуванням не передаються через проксі
Web Service на стороні клієнтського
додатки. Для забезпечення передачі контексту безпеки на
рівень сервера додатків необхідно в клієнтському додатку
встановити відповідний параметр для proxy
об'єкта викликається Web Service, як
показано нижче:

 


Proxy.Credentials =
System.Net.CredentialCache.DefaultCredentials

 

Сервер додатків

IIS

 

Заборонити Anonymous
доступ до віртуального каталогу Web Service

 

Встановити режим інтегрованої
Windows аутентифікації для
віртуального каталогу Web Service

У разі інтегрованої аутентифікації,
IIS може використовувати або
NTLM або Kerberos

ASP.NET

 

Змінити ASPNET
пароль у фіксований відоме значення

Для Web
додатків за умовчанням використовується ASPNET
обліковий запис з мінімумом необхідних привілеїв. За
замовчуванням, пароль для облікового запису управляється
ASP.NET.
Оскільки потрібно передача контексту безпеки цього
користувача на рівень баз даних, необхідно вручну керувати
паролем для цього облікового запису. Це здійснюється наступним
чином: 1. встановіть пароль ASPNET в
фіксоване значення, використовуючи консоль управління
користувачами і групами.

2. Відредагуйте
machine.config і встановіть
атрибут пароля для елемента <processModel>:

За замовчуванням:

username=”machine”
password=”AutoGenerate” 

Стає:

 username=”machine”
password = "фіксір._пароль"

 

(machine.config
розташований в директорії

%windir%Microsoft.NETFramework<ver>CONFIG)

Конфігурувати Web
Service для використання Windows
аутентифікації

Відредагуйте web.config
у віртуальному каталозі Web Service.
Встановіть елемент <authentification> :

 <authentification
mode=”Windows”>

Вимкнути імперсонацію
ASP.NET додатки

За замовчуванням імперсонація вимкнена.
Переконайтеся в цьому, перевіривши що елемент <identity>
файлу web.config
виглядає наступним чином:

<identity
impersonate=”false”>

SQL Server

Створити обліковий запис
Windows на SQL Server, яка
збігається з моїм обліковим записом ASPNET на
сервер додатків

Повинні збігатися ім'я та пароль для
зазначеного запису.

Надайте облікового запису наступні
права:

  • Access this
    computer from the network
  • Deny Logon locally
  • Logon as batch job

 

Це мінімальний набір прав, необхідних для
доступу до SQL сервера з мережі

Настройте SQL
сервер для інтегрованої Windows
аутентифікації

 

Створіть SQL Server
Login для створеної ASPNET
облікового запису

Це дасть сервера додатків доступ до
SQL Server

Створіть користувача в базі даних
програми та зв'яжіть створений на попередньому кроці
Login c цим користувачем

Це дасть сервера додатків доступ до
вказаній базі даних

Примітки

  1. Для організації з'єднання з базою даних ми використовували дві
    локальні облікові записи з однаковими credentials – на сервері
    додатків і на сервері баз даних. Управління двома обліковими
    записами несе додаткове навантаження при адмініструванні
    системи. Виходом може бути створення однієї непривілейований
    доменної облікового запису та використання її на обох серверах. Але при
    такому підході доведеться вказати ім'я доменного користувача в атрибуті
    user. ASPNET_WP.EXE буде запускатися під цим користувачем і йому
    необхідно надати права для виконань ASP.NET додатків.
  2. ASP.NET додаток, реалізує Web Service, запускається в нашому
    сценарії без імперсонаціі, тобто з під непривілейований облікової
    запису ASPNET з мінімумом необхідних привілеїв. Це знижує
    потенційний збиток при прориві систем безпеки.
  3. При виклику з клієнтського застосування методів Web Service по
    протоколу SOAP у разі NTLM аутентифікації будемо спостерігати передачу
    двох HTTP запитів на кожен виклик методу. Цього неможливо уникнути
    через механізмів роботи NTLM протоколу. Це може викликати
    істотні затримки при спілкуванні шару представлення даних з шаром
    бізнес логіки. Уникнути посилки двох HTTP запитів можна тільки при
    використанні Kerberos протоколу. Вибір NTLM або Kerberos протоколу
    при інтегрованої аутентифікації залежить від настройок конфігурації
    на сервері і на клієнті. У разі використання Kerberos протоколу
    для посилки Credentials в першому запиті необхідно виставити на
    Proxy об'єкті такі властивості:

     

    proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
    proxy.PreAuthenticate = true;
    
  4. На IIS 5.x завжди запускається один примірник ASPNET_WP.EXE
    процесу і установки для ASP.NET облікового запису конфігуруються на
    рівні всієї машини (у machine.config). Це може бути незручним,
    коли на одному IIS сервері ми хоста декількох Web додатків / Web
    Services c різними налаштуваннями для ASPNET користувача. Доброю
    новиною є те, що в Everett (наступна версія. NET Framework
    і Visual Studio.NET) і IIS6.0 даний недолік буде ліквідовано.
  5. Ми зберігаємо пароль для ASPNET облікового запису в machine.config в
    відкритому вигляді. І хоча напряму з web додатків немає доступу до
    конфігураційним файлів, це є потенційною слабкістю нашої
    системи безпеки. У Everett буде реалізована можливість
    використання Win32 Data Protection API (DPAPI) для роботи з
    конфігураційними файлами на рівні ASP.NET.

Використання COM + служб

Для доступу до інших ресурсів системи (наприклад, факс сервер
стороннього виробника, додатковий сервіс і т.п.) може
знадобитися імперсонація під спеціалізованим користувачем.
Використання Logon API всередині ASP.NET додатки для імперсонаціі
ASPNET_PW.EXE процесу під іншим користувачем є
недоцільним, оскільки ми повинні будемо дати ASPNET облікового запису
право "act as part of operating system", що потенційно послаблює
систему безпеки. (Гарним правилом є призначення мінімуму
необхідних прав будь-якого об'єкта в системі)

Ми можемо вирішити, чи передавати чи не передавати контекст користувача
до COM + додатки. Якщо нам не потрібно проводити додаткової
авторизації користувача на рівні COM + додатки, то контекст
передавати не будемо і звернення до COM + додатком буде здійснюватися
з під ASPNET користувача (не забувайте – ми не використовуємо імперсонацію
на рівні ASP.NET і наше ASP.NET додаток виконується під ASPNET
обліковим записом).

Якщо ми захочемо передавати контекст користувача до COM + додатки,
то нам доведеться включити імперсонацію в ASP.NET додатку через
зміна Web.config:

 

<identity impersonate="true">

Для передачі контексту в COM + додаток додатково в machine.config
в елементі <processModel> потрібно встановити наступний атрибут:

<processModel 
    comImpersonationLevel="Impersonate"

Не буду детально зупинятися на конфігуруванні COM + додатки.
Тільки зроблю зауваження, що ми повинні встановити його як серверне
додаток (тобто буде запускатися в окремому процесі під управлінням
dllhost.exe). Обліковий запис, під якою буде виконуватися COM +
додаток, повинна бути саме тією обліковим записом (збігатися в разі
використанні локальних записів), яка використовується для доступу до
віддаленого ресурсу системи

Такий підхід може так само бути використаний, коли необхідно
забезпечити доступ до різних джерел даних в SQL Server в межах
однієї програми і, відповідно, надавати різні Credentials
для доступу до цих джерел.

 

Висновок

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

Вичерпні відповіді на питання, пов'язані безпекою при побудові
ASP.NET додатків і розподілених додатків на. NET Framework,
використанні Web Services і. NET Remoting, ви знайдете в документі

Building Secure ASP.NET Applications: Authentication, Authorization, and
Secure Communication. Приготуйтеся до довгого вивчення (608 сторінок
!) І розробляйте свої додатки з продуманою і надійною системою
безпеки.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*