MySQL Security Policy (MySQL security considerations) and mysql policy considerations
Guide
MySQL is used in more and more businesses and has higher requirements on Data Security in key businesses. How can we ensure MySQL Data Security?
Data security is obviously not adequate only at the MySQL application layer. It needs to be protected at multiple layers, including the network, system, logic application layer, and database layer.
The following are some security policies that we can learn from.
1. network and system layers
At this level, we can do a lot of things. We can put these security requirements as the standard requirements for new system installation in the automated installation solution.
Place the server running MySQL on the Intranet and do not enable the internet;
If you have to enable the public network, modify the sshd port to 10000 or above;
Set a firewall policy to allow only trusted servers to connect sshd and MySQL ports;
Change the idrac/imm password and set the GRUB Password;
Set a password security policy. For example, PASS_MIN_LEN must be no less than 8 characters. In fact, it is best to use a complex password for MD5 and then use it as the official password. The 32-bit length is safe enough;
Operation logs are recorded in syslogs and sent to the remote log server, so they cannot be stored locally only;
Except for the required accounts, all other accounts are set to have no logon permission;
Try to separate the server running MySQL from the web server and app server. If permission separation is required, the owner of the web server and app server processes cannot directly access MySQL datadir;
Disable the autoindex configuration at the web server layer;
If possible, use https instead of http;
Key applications must be updated to avoid vulnerabilities in earlier versions;
Set security policies for nginx, php, and other application services, and disable dangerous functions;
You can purchase some security protection, scanners, and other products provided by the carrier;
Resolutely put an end to the second force, and upload key configuration files to the public network (for example, put the company project code on github as a personal project, containing the Intranet account password information ).
2. Logical Application Layer
At this level, most of the tasks depend on the security awareness of operators and developers. Many low-level security vulnerabilities that can be avoided can be completely handled at this level, for example, the XSS, CSRF, and SQL Injection Vulnerabilities mentioned below.
Do not use open-source cms, blog, forum, and other systems on the public network unless you have performed code security audits or made security policies in advance. This type of system is generally the key research object of hackers, and it is easy to be engaged;
On the web server layer, you can use some security modules, such as the WAF module of nginx;
At the app server layer, code security auditing and security scanning can be performed to prevent XSS attacks, CSRF attacks, SQL injection, File Upload attacks, bypass cookie detection, and other security vulnerabilities;
For example, if the JDBC connection string is configured in an application involving the account and password, try to store the plaintext password in encrypted mode and use the internal private decryption tool for reverse decryption before use. Alternatively, the application can first connect to the proxy layer with an intermediate account, and then connect to MySQL through the proxy to avoid direct connection to MySQL at the application layer;
Key log records, such as transaction logs, are enabled at the application layer to facilitate subsequent reconciliation.
3. MySQL database layer
If the previous layers are not safe enough, the layer is almost at risk. But we can still do something.
Enable the safe-update option to avoid modifying the full table data without the WHERE condition;
Extend the retention period of binlog to facilitate subsequent audit and review;
The application account only grants SELECT, UPDATE, and INSERT permissions, and cancels the DELETE permission. Change the logic requiring the DELETE permission to UPDATE to avoid physical deletion;
If you need to delete a database, the database is backed up by the DBA before physical deletion;
You can use the SQL audit plug-in of Percona. It is said that there is also a macark plug-in;
You can also use triggers for some auxiliary functions, such as preventing malicious data tampering by hackers.
4. Postscript
There are many things that data security can do. This article only lists some simple and fast implementation solutions. Every enterprise should have its own security policy specifications, and every participant should be in awe and strive to abide by these necessary specifications, so as not to make information security an empty talk.
Real Data Security relies on everyone's awareness and security. Without such awareness, mechanisms, systems, and tools are unreliable. Yu