The principle of least privileges is an important element to consider when it comes to setting up security in any information system. Whether it is through Windows, Linux, or a database, a “superuser” account is viewed as a role that comes with unrestricted access to all commands, functions, and resources within a system. Those superuser roles in a database for example have the ability to create databases, roles, or completely remove them.
If these roles are misused even by accident of dropping a database or on purpose, these roles can create significant damage to a database. Most of the security protection measures are handled around the perimeter of an information system. However, with superuser roles and accounts, they are already on the inside. For example, if an individual had temporary access to the superuser role in a database, they could create additional roles that they could connect to and further do damage. Even if the superuser role that they had been using was removed, they now have backdoors through other roles. Through the role, they could also remove their activity within the system. For example, an intruder with superuser roles could create order within a system and have items that they did not purchase sent to them. Once the order had been sent out, they could delete the order and any related data so that the system had no indication of that order.
In the last tutorial, we explored one of the issues around SQL injections where the individual could potentially drop a table or even a database. They would only be able to do that if the role that the application was logging into had that permission. As such, typically any roles that a user of an application would interface with should only be given the necessary privileges to complete their tasks. In some organizations, these superuser roles and accounts are shared among various users such as database administrators. By doing this, the audit trail becoming a lot more difficult to track.
This is where policies need to be put in place to help provision, segregate and monitor various risks. The superuser type of role should be limited to a number of individuals. In addition, for individuals, you can temporarily increase the privileges of the individuals when needed without granting them full superuser privileges around the clock. You can also work on separating the privileges of users and enforcing them to use certain accounts depending on when they need certain privileges. You may have separate accounts/roles that have the ability to update and query data while having other accounts/roles that can only query data if that role doesn’t need to make changes. All permissions should be granted to the user rather than being automatically given.
In many other cases, it can be important to change out the superuser password on a regular basis so that even if the account is compromised, it will be changed out on a regular basis. For some instances, organizations may even change the password after each use of the role to keep it safe.