Чи краще використовувати інтегровану безпеку (SSPI) для доступу до SQL Server для веб-додатків?

Розгортаючи веб-додатки (.net) у виробничому середовищі, чи краще використовувати інтегровану безпеку чи це навіть має значення?

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

Думки?

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

1. Ви підключаєтесь за межами домену, тому інтегрована авт.
2. Ви використовуєте показник TPC-C і кожен цикл рахується. Auth SQL - це трохи менше.

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

Хоча sql auth і Windows auth не дає явної переваги у вашому сценарії, є й інші проблеми, які слід врахувати:

1. Централізоване виконання політики: у вас є одне місце, щоб налаштувати політику паролів, включаючи термін служби та термін дії пароля, припинення облікового запису тощо.
2. Контроль за видаванням себе та делегуванням довіри. Після того, як sql auth буде використано в ланцюжку делегування довіри, всі ставки будуть вимкнені, оскільки це не є реальною «делегацією», і, отже, більше не підпадає під обмеження, які встановлює ваша політика
3. Аудит: sql auth навіть не бачив ваш LSA, тому вся ваша аудиторська інфраструктура просто обійдена. Вам потрібно explictly додати записи SQL виробляти про sql події auth, але це змішування яблук і апельсинів, оскільки ці події мають різні джерела, постачальник і схему в журналі подій

Останнє зауваження: протокол TDS розкриває пароль autl sql у чистому тексті над трафіком, але це, як правило, пом'якшується, вимагаючи шифрування трафіку SSL.

То чому ви все ще бачите sql auth WWW-хости, які зберігають пароль чітко у web.config? Це погані розробники / адміністратори, не будьте одним з них.

msdn.microsoft.com/en-us/library/aa378326(VS.85).aspx

technet.microsoft.com/en-us/library/ms189067.aspx

Якщо ви не використовуєте SSPI, ви жорстко кодуєте ім'я користувача та пароль у вихідні файли.

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

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

Перевага SSPI полягає в тому, що пароль ніколи не зберігається в чистоті.

Інші відповіді поки що були хорошими, але я кину ще одну: менеджмент.

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

Я тут не на 100% впевнений, але я думаю, що головне - це те, що автентичність SQL є незахищеною, тому краще використовувати Windows auth. Залежно від налаштування програми, ви також можете зберігати належні облікові дані у зашифрованому вигляді на пристрої за допомогою Windows auth. Я не думаю, що це справді можливо з автентифікацією SQL. Ви можете його притупити, але в кінцевому підсумку це повинно бути чітко.

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

Найкраще зробити це - обмежити те, що вони можуть робити, Якщо / Коли вони прориваються на веб-сервер. Це означає надання лише прав SQL, необхідних для роботи програми. Набагато простіше надати додатку права DBO, але це робить його БД набагато вразливішим у разі успішної атаки на веб-сервер.

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

Почнемо з того, що видає себе за машину. Якщо ідентифікатор пулу додатків - мережевий сервіс, і в додатку .NET немає жодних втілень, тоді так, веб-додаток підключиться до резервного SQL Server за допомогою облікового запису комп'ютера на комп'ютері. І це означає, що ви надали доступ до вказаного комп'ютерного рахунку. CRM Microsoft працює таким чином.

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

Тепер про те, навіщо використовувати SSPI. Перш за все, ви не використовуєте вхід на основі SQL Server. Це означає, що Active Directory є єдиним джерелом безпеки. Це означає, що у вас є звичайні засоби аудиту для визначення недійсного доступу. По-друге, це означає, що якщо немає інших програм, які цього вимагають, ви можете залишити свій SQL Server лише в режимі автентифікації Windows. Це означає, що вхід у систему SQL Server не дозволений. Це означає, що будь-які напади на sa зупиняються ще до того, як вони навіть розпочнуться. І нарешті, це полегшує одужання. Якщо ви використовуєте логін на основі SQL Server, вам потрібно буде витягнути логін з допомогою SID та зашифрованого пароля. Якщо ви використовуєте обліковий запис користувача на базі Windows як "обліковий запис служби", коли ви переходите на новий SQL Server, створюючи логін,

Питання в тому, що "краще"? На що важко відповісти, оскільки він спирається на контекст, цінності та пріоритети питаючого.

Особисто мені подобається автентичність SQL.

• AD - інша справа запускати та підтримувати та керувати обліковими записами послуг.
• AD має бути доступним у вашому середовищі хостингу.
• AD ускладнить перехід до хмари або гібридної хмари.
• AD дозволяє легко додавати облікові записи сервісів у групи, в яких адміністратори не повинні містити інших частин вашої організації.
• SSPI не обходить проблему шифрування рядка підключення, оскільки слід зашифрувати ім'я хоста SQL у config.
• Auth SQL - це проста і просто конфігурація тексту, її легко розгортати.
• Налаштування ідентифікацій пулу додатків - ще одна річ, щоб автоматизувати, а потім приховати ім'я користувача та пароль у цих сценаріях автоматизації для кожного середовища.
• Використання двох рядків з'єднання полегшує використання прокатуючих паролів, тому ви можете оновити пароль без простоїв.

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

Якщо користувачі не будуть маніпулювати базою даних безпосередньо (за допомогою інших інструментів клієнта, таких як SQL Server Management Studio), я, як правило, просто створять єдиний логін для програми для програми та нададуть їй необхідний доступ. У цей момент користувач обмежується тим, що вони можуть робити, як дозволяє інтерфейс веб-додатків.