In the previous blog in this series, we discussed authentication and authorization mechanisms, and how configuring them properly can help secure your databases. In this blog, we’ll talk about how data breaches can be prevented by implementing the principle of least privilege (POLP).
According to Verizon’s 2019 Data Breach Investigations Report, insiders account for 76 percent of all compromised database records. Malicious insiders pose a substantial threat to organizations, as they already possess prior knowledge about critical servers and databases in the enterprises. The principle of least privilege is a good starting point for tackling insider threats.
What is the principle of least privilege?
The principle of least privilege works on the basis of users and systems having the bare minimum privileges needed to carry out their jobs. Minimizing each user’s level of access is a defensive strategy against data exploitation. The level of access users can possess depends upon the activities they are entitled to perform in the database.
Consider a scenario where a user needs to export records from a database. The user should be given privileges only to read and export the records. If the user is given privileges to perform any other operation in the database, such as write, then there’s a chance that the privileges could be misused, and possibly result in data manipulation. Unfortunately, IT teams often grant more privileges than necessary for the sake of convenience, resulting in security loopholes.
How to implement the principle of least privilege and secure your SQL Servers
Database users and systems can be grouped based on their roles. Consider different groups of users as follows:
-
- Users who require access just to read and export data from the database
- Users who can read and write to specific schema (edit access)
- Privileged users who can add and delete the schema (data definition language)
- Privileged and administrative users who can add and grant access rights to various users
Here, the users under particular groups are granted the privileges necessary to perform their duties in the database. You can see that privileged users are also split into two groups; this is because the users who can create and delete schema don’t necessarily require privileges that can grant access rights. Similarly, they can’t be grouped under the users who can just read and write to the database.
If a user who just has to read and write to specific rows in a database possesses privileges to add or delete schema, the tables and records are vulnerable to attack. The user may carelessly or maliciously wipe out the entire database, resulting in a major incident. To avoid such mishaps, users and systems should be assigned just enough privileges to perform their duties, nothing more and nothing less.
To further fortify security, privileged users with administrative access should have two accounts: A user account for normal database access, and an admin account for adding users or assigning duties.
Below are six best practices to observe when following the POLP:
-
- Reconsider the permissions assigned to users and systems from time to time, and ensure the principle of least privilege is properly implemented.
- Disable user accounts that are no longer in use.
- Remove users from groups they are no longer part of.
- Revise the permissions assigned to admin groups, and closely monitor their activities.
- Monitor privilege escalations and take necessary remedial actions, if any.
- Maintain an audit trial of all the activities taking place in your SQL Server.
SQL Server uses GRANT, REVOKE, and DENY Transact-SQL statements to effectively assign permissions to user and system accounts. These statements can also be used for groups, where every new user added to the group will inherit the permissions given to the entire group. Different levels of access can be provided to different groups based on the functions they have to perform in the databases.
To understand SQL Server auditing in-depth and get a bigger picture about various use cases, you can refer to our e-book on the Basics of SQL log auditing.
Auditing SQL Server activities using an effective security information and event management (SIEM) solution enables you to more easily identify unauthorized access, privilege escalations, and deviant behavior of privileged user accounts. SIEM solutions can correlate activities across your network, and detect anomalies that help prevent data breaches and secure your SQL Servers.
Want to see a holistic SIEM solution in action? Schedule a free demo of ManageEngine Log360 now.
