Борих се с това преди всички тези години, така че ето отговора, който бих искал да имам:
Като цяло това е твърде усложняващо нещата и отговорът на заглавието за основно приложение е:разрешенията на потребителите ще се управляват от PHP кода в API повикванията, които правите, и един потребител на DB е добре. Всички потребители трябва да избягват директното взаимодействие с DB за разработчици на приложения като цяло, за да предотвратят нарушаване на неприкосновеността на данните.
Хубаво е да се мисли за сигурността и ограниченията, но простотата е най-важната – колкото по-сложна я направите, толкова по-трудна е за поддръжка и следователно е по-лесно да пропуснете ъглови кутии.
Трябва ли да създавам нов потребител на база данни всеки път, когато регистрирам нов потребител в мрежата?
Не, потребителите на база данни се отличават със своите привилегии. В резултат на това всички потребители отговарят на набор от групи с различни нива на привилегии. Акаунтите в базата данни са отделни от уеб акаунтите – свързването с базата данни се извършва зад кулисите и няма връзка към използвания уеб акаунт.
Добър подход би бил да създадете акаунт в DB за всяка услуга, свързваща се директно с DB. За огромното мнозинство това ще бъде една услуга, вашият уеб сървър. Ако приложението се разраства и се появят изолирани услуги като одити, микроуслуги, сигурност, IOT, те вероятно трябва да имат свои собствени акаунти.
Безопасни ли са CRUD привилегиите за предоставяне на всички потребители на уебсайта?
Въпросът е погрешен - даваш CRUD на DB акаунта, който ще има нужда от него. За CRUD разрешенията, управлявани в PHP, наистина зависи от вашето приложение и конкретни крайни точки. Например, вероятно не искате всички ваши потребители да могат да изтриват потребителски записи, така че вашият PHP код трябва да предотврати това.
Колко различни типа потребители на DB трябва да има?
Броят зависи от вашата база данни. По принцип има 4 групи
- Администратори на база данни
- Дизайнери на бази данни
- Случайни крайни потребители
- Нативни крайни потребители
Въпреки това, ако искате да предоставите привилегии на ниво таблица, може да се наложи да разклоните малко повече. Това предполага, че 10 DB акаунта са доста малко, по-вероятно е няколкостотин .
Колкото повече привилегии, толкова повече пространство се изисква, но това е доста малко съображение и не трябва да играе голяма роля за производителността. Сложността е следващият проблем - помислете внимателно колко групи и пермутации всъщност искате да тествате. В случая на въпроса по-горе, аз бях разработчик-любител - един акаунт като DBA вероятно е добре. Ако имаше множество потребители, които имат директен достъп до DB (вероятно вече е лоша идея за разработчиците на приложения), тогава може би ги разделете с различни разрешения.
Говоренето за разрешения на ниво таблица за обикновено приложение е просто пресилено!
