Які розумні привілеї надавати типовим користувачам? [зачинено]

Я вважаю, що перелік пільг, наданих MySQL, є дещо переважним. Я не впевнений, хто повинен мати які привілеї. На мою думку, для моєї ситуації є три типові користувачі:

1. root
2. developer
3. application

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

SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON

applicationмає ще більш обмежений набір. Це має бути обмежено маніпулюванням певною базою даних.

Я не впевнений, що таке розумний набір привілеїв. Що таке розумний набір привілеїв для надання розробника та програми та чому?

Типовий користувач повинен мати:

SELECT, INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES, EXECUTE

Перші чотири досить очевидні - хоча ви також можете налаштувати користувачів, які "лише для читання" SELECT.

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

EXECUTEзалежить від вашого типу системи. Чи зберігаються у вас підпрограми? Ви хочете, щоб ваші користувачі мали доступ до них? Переконайтеся, що ви також знаєте про SECURITY=DEFINER/INVOKERвизначення збережених процедур.

У будь-якому випадку обов’язково застосуйте все вищезазначене на конкретних схемах . Уникайте використання:

GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'some_user'@'some_host';

як зазначене вище, також надаються привілеї в mysqlсистемних таблицях, фактично дозволяючи будь-якому користувачеві створювати нові облікові записи або модернізувати свій набір привілеїв. Натомість зробіть:

GRANT SELECT, INSERT, UPDATE, DELETE ON some_schema.* TO 'some_user'@'some_host';
GRANT SELECT, INSERT, UPDATE, DELETE ON another_schema.* TO 'some_user'@'some_host';

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

У всіх середовищах програма повинна мати те, що їй потрібно, і не більше (як правило, це "вибрати / вставити / оновити на всіх таблицях" та "виконати всі процедури". Для великих систем, де у вас можуть бути окремі користувачі додатків для різних завдань (для наприклад, одна програма несе відповідальність за подачу даних про цензуру, а інша - за генерування звітів. Ви повинні розділити їхні привілеї, щоб вони мали найменше, що їм потрібно (користувачеві-звітнику, мабуть, не потрібно і права запису). середовища, якщо у вас є: Я бачив, як код підпадає під час просування до Live, який працював у тесті, оскільки все в тестовому середовищі отримувало доступ до БД як sa(еквівалент MSSQL root).В ідеалі користувач програми, як правило, не повинен мати привілеїв, які дозволяють йому змінювати вашу схему (CREATE,, DROP...) - з цього є винятки, але їх небагато і між ними.

rootє, ну root,. У виробництві це лише ваша DBA, і її слід використовувати рідко - лише для обслуговування системи (оновлення дизайну БД тощо) та моніторингу. Для великої системи, особливо в регламентованих умовах, де ви повинні підтримувати ретельний контроль над особами з метою підзвітності, ви можете взагалі не дозволити одному rootкористувачеві і спробувати розділити привілеї на менші рулони (я не впевнений, наскільки далеко ви можете піти з цим у mysql, але ви можете бути досить дрібними в MSSQL, Oracle тощо.

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

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