Importance of Role & Permission Management for Database Deployments

Permissions management for database deployments is a stumbling block in many DevOps pipelines. It requires a careful balancing act between access control and productivity. Unfortunately, the most common way to manage database permissions is manually. The lack of automation creates complexity and increases the risks of compromise. This problem is especially salient when employees are transitioning to remote work due to COVID-19 related lockdown restrictions. Here is what you can do to simplify your roles and permissions management with DBmaestro.

Manual management of database permissions is a recipe for a disaster

There is no way around the fact that employees require access to specific environments to do their jobs. Every single employee who needs access to the database requires a set of permissions: Devs, DBAs, compliance officers. And the list goes on and on.

When it comes to the databases, permission management processes are, for the most part, manual. Most organizations lack a centralized depository to document and manage user permissions. And this causes serious problems.

Database permissions are usually not well organized. We have zero visibility with too many passwords and permissions; we can’t know who has what permissions and why. Moreover, there is the issue of weak, stolen, and reused credentials and the resulting security risks.

On the one hand, privileged access exposes the organization to risks. On the other hand, if we follow the least privileged access, we end up with bottlenecks and lack of productivity.  So you either have a mess with permissions sprawling out of control, or you cut everything down, giving only the DBA access to enter the database, creating bottlenecks.

In other words – it’s a lose-lose scenario.

Privileged access exposes organizations to risk

Since it is not always known who needs to do what exactly, and tasks change from time to time, what often happens is that every user ends up with the highest permissions possible. This creates an unhealthy and dangerous situation where many people have high-level permissions to access the database.

This issue is exacerbated by the endemic use of weak, unsecured, and reused passwords in enterprise environments.

Weak, unsecured, or reused passwords

When users need to manually login into the system to perform tasks, there are severe security risks involved.

Think about your own usage of passwords. Nobody likes to admit it, but the vast majority of users routinely reuse passwords across multiple, if not all, sites. An average person has 70-80 passwords, and it is simply humanly impossible for users to remember 80 unique login/password combinations.

Over the course of the last several years, billions of login credentials have landed in the hands of hackers as a result of data breaches. Password reuse combined with credential dumps is a ticking bomb.

Moreover, there is a risk of phishing and keylogger attacks. What ends up happening when a user unwittingly exposes their password to a threat actor is that the threat actor gets access to everything the user has access to.

This is an especially salient issue right now when many users access enterprise resources from unsecured home networks and devices.

The least privilege access principle creates bottlenecks

So the solution seems obvious – let’s adhere to the least privilege principle instead, and therefore reduce the complexity of permissions to the very minimum. If we cut everything down, and give only the DBA access to enter the database we will no longer have sprawling permissions. Problem solved!

Not so fast. We might have reduced the complexity, but now we created a bottleneck where only a few people can do anything on the database. The lack of self-service to your developers will bring your release process to a standstill until the DBA manually pushes required changes. The problem creates a host of productivity issues and brings the CI/CD process to a halt whenever the database is involved.

So what did we achieve here? We traded complexity and high risk for lack of productivity and loss of agility. Not a situation any of us would consider ideal.

Lack of visibility

When permissions are managed manually, there is no centralized control, and nobody has any visibility into who has what permissions and why.

A postmortem analysis becomes difficult when damage is done as you can’t determine which user caused issues, when and where.

Automating roles and permissions management for database deployments

So it is clear that we need to bring order to chaos. There are two ways to go about it. You can make it into an ad-hoc project that you need to maintain and manually and grant and revoke permissions whenever a person comes onboard or leaves the company. You will end up neck deep in a  complex and lengthy project,  wasting lots of time setting up permissions for all users.  This is far from ideal.

Flexible and fully automated role-based permissions management allows you to maintain the appropriate balance of collaboration and control while giving you peace of mind that your data is secure and protected.

How does the DBmaestro’s database roles and permissions management work

DBmaestro links database permissions to the domain permissions.  Instead of manually granting and revoking permissions to individual users, we allow organizations to link existing permissions – for example, from Active Directory – to user roles and the corresponding access levels to the database.

For example when a user has domain permissions, that doesn’t necessarily mean that they also automatically get necessary permissions to your Oracle, MySQL, MsSQL etc.

But suppose we base access to the database on a person’s role, instead of individual user credentials and automatically grant them correct permission? We create a separation between the database and the users themselves while at the same time granting access to relevant users.

DBmaestro replaces all direct permissions with roles, defines release pipeline, and through the release pipe configures which environments need access by which users.

The bottom line: when permissions are configured via roles, you don’t need to manage the role permission at the user level. This is a simple yet elegant and powerful solution that solves many problems we talked about.

How DBmaestro simplifies roles and permissions management

First of all, the moment you’ve introduced Role-Based Access Control for your database, you reduce the permissions problem’s complexity. Once you’ve set up permissions for a DBA role – whenever a DBA comes or goes, you simply assign or remove the user’s role once, and all permissions are automatically granted.

Second, your users no longer access your database via their credentials since we remove user-level permissions and set up permissions based on the role.

For example, if you are a Developer, you may release to QA; if you are DBA or a DevOps person – you may release to production.

Instead of connecting directly to the environment, now the developer connects to DBmaestro, and DBmaestro connects to the QA on their behalf. It means that the developer doesn’t know the credentials to the QA and, therefore, cannot expose those credentials, either willingly or by accident.

The power of a structured process

Two things happened here- not only did we reduce complexity and boosted security, but we introduced a structured process.

Automatically document every action

DBmaestro manages permissions in a structured way and documents every action that happens. Everything is automatically documented – what the user did in the system as well as the feedback from the server.  This is no longer a user who went in and out, and you don’t know what they did.

Block non-policy and dangerous actions

DBmaestro not only manages the access control, but also analyzes the content of the changes and blocks non-policy, dangerous, unsecured actions.

DBmaestro detects and automatically disallows dangerous actions as defined by your policies. For example, if a user wants to drop a table, which may be risky, the command will not be executed, and they will be immediately alerted to change the command. Or if a user tries to provide a “grant all” access permission, DBmaestro will immediately pop up with a warning to specify permissions as required by company policy.

Through the structured process, no longer can accidental exposures of your database happen, runtime errors are eliminated, and downtime and data loss prevented.

Taking it to the next level with CyberArk integration

So now you have a structured process, where everything is documented, and policies are automatically enforced. The next step is taking our permissions game to the next level by adding CyberArk or other password vaults to the mix.

With CyberArk integration, even DBmaestro no longer knows the passwords to your environments. As a result, developers don’t know the passwords, DBAs don’t know the passwords, and even DBmaestro no longer knows the password.

At the same time, the release process is not hindered and users can freely release to assigned environments and perform authorized actions via DBmaestro.

With DBmaestro and CyberArk integration, you can achieve the holy grail of permission management where nobody knows their credentials but can perform whatever actions their role in the company requires.