Be careful when lazy programmers reduce your database security
In my recent book, I tried to explain SQL Server security to the cainiao SQL Server administrator. It must be acknowledged that few applications are written in the way SQL Server Security expects. I blame the lazy database developers for the problem.
Surprisingly, the early review of this book was made by several developers and I was disgusted with my comments. One person wrote, "SQL Server is not the only database, and the code I have written must also match Oracle ." In other words, to replace the specific considerations for the security of each database platform, he only needs to adopt the minimum standard, because it is simple and easy, and does not need to consider the impact on users.
You need to be aware of the attitudes of database developers and vendors, and you need to fight against them.
The lowest standard of database security technology is to create only one user account in the database, and then allow each application copy to log on using this single user account. This application implements its own "security". For the platform security developed by Microsoft, Oracle, and other platform companies, Baidu Baiji experts, I am sure it is robust.
This method is mainly reflected in the following important aspects:
Audit: When only one user account can access data, you cannot know who is performing the operation. Of course, the application can implement its own audit trail, but any user with relevant knowledge can bypass the audit trail if they have an account name and password.
Security: Embed the user name and password into a connection string to make it difficult for people to discover information. Ready-made tools can decompile common enterprise applications within a few seconds, so that the connection string and its password are in plaintext mode.
Troubleshooting: Because you cannot specify a separate database connection to someone, it is difficult to troubleshoot performance and Operation Problems. When a user complains about slow operation, the administrator cannot locate the problem accurately. This means that the problem will last longer.
For a developer, it is almost easy to make his application use SQL Server's built-in security. You only need to change the main connection string, remove the user name and password, and let the user's Windows login credential pass. In most environments, apart from authorizing the server to allow people to read and write the necessary data, this is what the database administrator needs to do. You will use SQL Server's own audit function to better troubleshoot the fault, and the all-powerful users embedded in each application copy do not provide a plaintext password to improve security.
So how do you compete with the lowest standard database security technology? Very simple. Establish procurement standards. Make sure that the new application uses the Windows authentication mechanism of SQL Server. Change existing applications. You may need to make a schedule with the vendor or let them know that the lucrative "maintenance expense" income is not that profitable. Take control of your environment-some people may provide you with the best security, but it's easy for them to do everything. Don't give the company to such people.