Чи коли-небудь є хорошою практикою використовувати окремий обліковий запис бази даних для кожного користувача програми?

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

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

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

Також існує назва цього типу налаштування?

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

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

У веб-додатку база даних (наприклад, порт 1433), як правило, не піддається впливу безпосередньо, тому у вас є рівень безпеки. Навіть якщо веб-додаток безпосередньо отримує доступ до бази даних, користувачі все ще не мають прямого доступу до бази даних.

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

У базі даних ви можете мати дуже тонкий контроль. Але контроль рівня рядків - це трохи робота. База даних не є хорошим інструментом для ділових правил. Правила ведення бізнесу та детальна безпека зазвичай застосовуються на рівні заявки.

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

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

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

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

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

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

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

Єдиний обліковий запис для всіх - чудове джерело запитань тут і в інших місцях - "запис x видалено, як я дізнаюся, хто це зробив?" - відповідь ви не можете - без індивідуальних рахунків та аудиту .

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

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

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

Може, якби ви дали нам свої RDBMS, ви могли б отримати поради, більш конкретні / відповідні вашій ситуації?

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

Зазвичай це робиться через незнання, заради простоти чи іноді для виконання.

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

Ви хочете вибрати сервер db, який підтримує безпеку рядків, захист стовпців та внесення особових даних / автентифікацію проксі (який підтримує реальних користувачів db + об'єднання з'єднань)

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