MySQL Security policy →▉ collection and collation ▋

MySQL Security Policy

Guide

Database security operation and maintenance is the cornerstone of the normal operation of business, not to be sloppy

In addition to MySQL's own account password security management, system level, application level security policy have you noticed?
Data is the core asset of the enterprise, the data is one of the most important work for the enterprise. A little careless, it is very likely that the data unintentionally leaked, even by hackers malicious steal the risk. Every year the industry will be a few big events, a well-known or not well-known company was taken off trousers (the homophonic, meaning the entire database was hacked) and the like.
From the data security can also be divided into the external network security and internal operational security, discussed below separately.

Internal operational Security Policy
1. Whether to reclaim DBA full authority

Imagine, if the DBA has no authority, the daily operation of the DB operations, as well as emergency troubleshooting, how to implement it? So

It is suggested that in the absence of mature automated dimensional plane, it should not be rude to reclaim too much of the DBA's authority, otherwise it may result in reduced productivity,

Even DBAs have a negative feeling of not being trusted.

2. mysql Layer Security Policy
Business accounts can only be remotely connected via the intranet, but not through the public network.
Add an account for the OPS platform, which allows remote connection from a dedicated management platform server. Of course, you need to do security on the server where the management platform is deployed and the necessary

Security audit strategy.
We recommend that you enable the database auditing feature. This requires the use of MySQL Enterprise Edition, or the PERCONA/MARIADB branch version, which is not supported by the MySQL community version.
Enable the Safe-update option to prevent full table data from being modified without a WHERE condition;
Instead of deleting the data directly in the application, it is better to set a flag bit. When a real deletion is required, the DBA is backed up and then physically removed to avoid misoperation

Delete all data. You can also use triggers to do some ancillary functions, such as preventing hackers from maliciously tampering with data.

3. MySQL Account permission rules
Business account, permissions to minimize, and never allow drop, truncate permissions.
The business account is granted only the permissions required by the normal DML, that is, select, UPDATE, INSERT, delete, execute, and so on.
After MySQL initialization, delete the unused account, delete the anonymous test database
Mysql> Delete from mysql.user where user!= ' root ' or host!= ' localhost '; Flush privileges;
mysql> drop database test;
Create a backup dedicated account, only select permissions, and only allow the native to log in.
Set the password security policy for the MySQL account, including length, complexity.

4, about data backup
Remember, doing a full backup of the data is the last straw when the system crashes and cannot be repaired.
Backup data can also be used for data audits or data source extraction for data warehouses.
In general, the backup strategy is to be fully prepared once a day and to make regular binlog, or to use the Binlog server mechanism to transfer binlog to other remote

      on the host. With a fully prepared +binlog, you can restore to any point in time on demand.
       Special Reminder: when using Xtrabackup streaming backup, consider using encrypted transmission to avoid malicious interception of backup data.

in fact, The security of operating system and application is more important than the security policy of the database itself. Similarly, the application and the server-side system security on which it resides is also important,

a lot of data security incidents are through code exploits to the application server, and then to probe the database, Finally successfully dragged the library.

1, operating system security recommendations
        

And as mentioned above, the database account permission level must be strictly restricted.
The system account is changed to be based on SSH key authentication, do not allow remote password login, and SSH key algorithm, length is required to ensure relative security.

This will not risk the loss of the password unless the private key is stolen.
Further, even the entire server can be enabled PAM certification, to achieve unified account management, but also more convenient and secure.
Shut down unnecessary system services, only the necessary processes, such as mysqld, sshd, networking, Crond, SYSLOGD and other services, are closed.
Root account is not allowed to log in remotely.
It is forbidden to use root account to start the normal business service process such as mysqld.
The port number of the SSHD service is recommended to be modified above 10000.
Enable firewall policies on MySQL service ports whenever possible without compromising performance (high concurrency, using iptables may affect performance,

We recommend using the IP route policy instead.)
Grub must have the password set, and the default password for the physical server, such as Idrac/imm/ilo, should also be modified.
Every employee who needs to log in to the system uses each person's private account, rather than using a public account.
The system-level operational audits should be enabled, all SSH logs logged, or the appropriate action commands should be logged and sent to the remote server, and then a corresponding security audit

Find unsafe operations in a timely manner.
Correctly set MySQL and other database services related directory permissions, not all 755, general 750 is enough.
You can consider deploying a bastion machine, all of which are connected to a remote server by a bastion machine, and all operational records and auditing functions can be implemented on the bastion machine.
Scripting encryption is not much help for security improvements. For experienced hackers, as long as the system login permission, you can easily get root by means of power, and so on.

2, apply security recommendations
        Disable AutoIndex configuration for Web server.
       from the system level, to prevent employees to upload code to the external GitHub, there may be internal IP, account password leakage risk, really must be uploaded before the security audit.
      try not to use open-source CMS, blogs, forums and other systems on the public network, unless you have done a code security audit, or a good security policy beforehand. This type of system is generally a hacker

The key research object, very easy to be engaged;
In the Web server layer, you can use some security modules, such as Nginx WAF module;
In the application layer, security vulnerabilities such as code security auditing, security scanning, preventing XSS attacks, CSRF attacks, SQL injection, file upload attacks and bypassing cookie detection can be done.
Where an application involves an account password, such as a JDBC connection string configuration, as far as possible to encrypt the plaintext password, and then use the internal private decryption tool

Re-use after decryption. Or you can let the application first use the intermediate account to connect the proxy layer, and then the proxy connection to MySQL, to avoid the application layer directly connected to MySQL;

Summarize:

1. Any smart security strategy is not as important as the safety awareness of internal employees.

2, security no small things, everyone should be remembered in the heart. In the face of data security, you can sacrifice some of the convenience, of course, not too much, otherwise it may outweigh the benefits.

This article is from the "Boyhack" blog, make sure to keep this source http://461205160.blog.51cto.com/274918/1956127

MySQL Security policy →▉ collection and collation ▋