MySQL应用程序用户与数据库用户 [英] MySQL application users vs database users
问题描述
不幸的是，这个问题可能有点笼统，因为我无法制定适当的条件来帮助我将所有这些结合在一起.我是php/SQL的新手，我正尝试通过非常简单的登录/注册功能来建立一个最小的站点.
- 每当我注册一个新的Web用户时，我都应该创建一个新的数据库用户吗?
- CRUD特权可以安全地授予网站的所有用户吗?
我真的应该让一个DB用户注册，一个只能插入到用户表中的用户，直到他们登录( mysqli_connect()不需要密码)之前，什么都不能插入?
登录后，他们将连接到另一种类型的数据库用户，该数据库用户具有使用该网站的更多特权.
- 应该有多少种不同类型的数据库用户?
我假设数据库工作者的用户群体很小(包括一个用于root访问的用户)，每种类型的Web用户的用户群体都是另一类(即，雇主比雇员拥有更多的特权)，而另一个仅用于注册的受限用户./p>
- 总而言之，在一个小型网站中> 10个DB用户是否会与众不同?
- 拥有许多类型的用户是否会产生性能/空间成本?
我感谢您的任何答复和链接，如果这些是非常基本的问题，我们深表歉意.
这些年来，我一直在为此苦苦挣扎，所以我希望我能给出以下答案:
通常，这使事情复杂化了，对于基本应用程序的标题答案是:用户的权限将由您进行的API调用中的PHP代码管理，并且一个DB用户是可以的.通常，所有用户都应避免直接与DB for App开发人员进行交互，以免违反数据的神圣性.
考虑安全性和限制是件好事，但是简单性是至上的-复杂性越强，维护起来就越困难，因此错过极端情况也就越容易.
每当我注册一个新的Web用户时，我都应该创建一个新的数据库用户吗?
否，数据库用户通过特权来区分.结果，所有用户都符合一组具有不同特权级别的组.数据库帐户与Web帐户是分开的-连接到数据库是在后台完成的，并且没有链接到正在使用的Web帐户.
一种好的方法是为每个直接连接到数据库的服务创建一个数据库帐户.对于绝大多数人来说，这将是一项服务，即您的Web服务器.如果应用程序增长并且诸如审计，微服务，安全性，物联网等孤立的服务应运而生，那么它们可能应该拥有自己的帐户.
CRUD特权可以安全地授予网站的所有用户吗?
这个问题被误导了-您将CRUD交给需要它的数据库帐户.对于PHP内部管理的CRUD权限，它实际上取决于您的应用程序和特定的终结点.例如，您可能不希望所有用户都能够删除用户记录，因此您的PHP代码应防止这种情况的发生.
应该有多少种不同类型的数据库用户?
该数字取决于您的数据库.通常，有 4个组
- 数据库管理员
- 数据库设计师
- 最终用户
- 本地最终用户
但是，如果要授予表级特权，则可能需要多做一些分支.这表明10个DB帐户是一个很小的数目， 解决方案
I struggled with this all those years ago, so here is the answer I wish I had:
Generally, this is overcomplicating things, and the headline answer for a basic application is: the permissions of users will be managed by the PHP code in the API calls you make, and one DB user is fine. All users should avoid interacting directly with the DB for app dev generally, to prevent violating the sanctity of the data.
It's good to think about security and restrictions, but simplicity is king - the more complex you make it, the harder it is to maintain, and therefore the easier it is to miss corner cases.
Should I be creating a new database user whenever I register a new web user?
No, database users are distinguished by their privileges. As a result, all users conform to a set of groups with varying privilege levels. The database accounts are separate from the web accounts - connecting to the database is done behind the scenes and has no link to the web account being used.
A good approach would be to create a DB account for each service connecting directly to the DB. For the vast majority, this will be one service, your web server. If the application grows and isolated services such as audits, microservices, security, IOT spring up, they should probably have their own accounts.
Are CRUD privileges safe to give to all users of the website?
The question is misguided - you give the CRUD to the DB account, which will need it. For the CRUD permissions managed inside the PHP, it really depends on your app and specific endpoints. For example, you probably don't want all your users to be able to delete User records, so your PHP code should prevent that from happening.
How many different types of DB users should there be?
The number depends on your database. Generally, there are 4 groups
- Database Administrators
- Database Designers
- Casual End Users
- Native End Users
However, if you want to grant table level privileges then you might need to branch out a little more. This would suggest 10 DB accounts is quite a small amount, several hundred is more likely.
The more privileges, the more space is required, but it's a fairly minute consideration, and shouldn't play a big role in performance. Complexity is the next issue - think carefully how many groups and permutations you actually want to test. In the case of the question above, I was a single hobbyist developer - one account as a DBA is probably fine. If there were multiple users directly accessing the DB (already probably a bad idea for app dev), then maybe split out them with varying permissions.
Talking about table level permissions for a simple app is just way overkill!
这篇关于MySQL应用程序用户与数据库用户的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
