MySQL access authorization policy

I think everyone knows that if authorization is the simplest, easiest and most convenient, and the maintenance workload is the least, it is naturally the easiest and most convenient way to grant all permissions to all users. However, we all certainly know that the greater the authority a user has, the greater the potential threat he brings to our system. Therefore, from a security perspective, the smaller the permissions granted, the better. An administrator with sufficient security awareness will only grant necessary permissions when granting authorization, and will not grant any unnecessary permissions. Since our chapter is dedicated to discussing security, we will now consider how to design a more secure and reasonable authorization strategy from a security perspective.

First, you need to know about the visiting host.

Since the MySQL database login verifies the user, in addition to the user name and password, the source host must also be verified. So we also need to know which hosts each user may initiate connections from. Of course, we can also directly use the "%" wildcard to give all hosts access permissions during authorization, but this violates the principles of our security policy and brings potential risks, so it is not advisable. Especially in the absence of firewall protection on the LAN, users who can log in from any host cannot be easily allowed to exist. If it can be specified by a specific host name or IP address, try to limit the visiting host by using a specific host name and IP address. If it cannot be specified by a specific host name or IP address, it also needs to be limited by using a wildcard range as small as possible.

Secondly, understand user needs.

Since we want to grant only the necessary permissions, we must understand the role played by each user. In other words, we need to fully understand what work each user needs to connect to the database to complete. Understand whether the user is a read-only application user or a read-write account; whether the user is a backup job user or a daily management account; whether the user only needs to access a specific (or a few) database (Schema) ), still need to access all databases. Only by understanding what needs to be done can we accurately understand what permissions need to be granted. Because if the permissions are too low, the work will not be completed normally, and if the permissions are too high, there are potential security risks.

Once again, classify the work.

In order to perform their respective duties, we need to classify the work that needs to be done, use different users for different types of work, and separate users well. Although this may increase some workload in terms of management costs, based on security considerations, this increase in management workload is well worth it. And the user separation we need to do is only a moderate separation. For example, separate specific accounts for backup work, replication work, general application access, read-only application access, and daily management work to grant the required permissions to each. In this way, security risks can be minimized, and similar permissions of the same type and level can be merged together without being intertwined with each other. Special permissions such as PROCESS, FILE and SUPER are only required for administrative accounts and should not be granted to other non-administrative accounts.

Finally, make sure only those who absolutely need to have GRANT OPTION permissions.

We have already learned about the particularity of the GRANT OPTION permission and the potential risks of having this permission when introducing the permission system before, so we will not repeat it here. In short, for security reasons, the fewer users with GRANT OPTION permissions, the better. As much as possible, only users with super permissions have GRANT OPTION permissions.

The above is the content of MySQL access authorization policy. For more related content, please pay attention to the PHP Chinese website (www.php.cn)!