Make no mistake: data is at risk. Data breaches hit all-time highs in 2021, and they are increasing at some of the fastest rates in history. The consequences of a data breach are immediate, long-lasting, and financially devastating (the average breach costs $4.35 million in 2022). And with the proliferation of cloud services and remote users, data has never been more dispersed, so securing it has never been more complicated.
As a resource that’s both extremely valuable in the right hands and extremely volatile in the wrong hands, data access management plays a vital role in data security. We’ve all heard that “identity is the new perimeter.” That’s especially true when it comes to data. No one can be assumed to be safe, secure, or authorized. Everyone and everything requesting access to data must have their identity verified and their privileges assigned. Otherwise, a data disaster is all but inevitable.
Privileged access management (PAM) seems like the obvious solution. After all, it successfully authenticates and authorizes users in other contexts. Applying it to databases theoretically solves the data security problem using a tool already in the security stack. It looks like a win-win…but don’t be deceived.
The World of Identity and Access Management
Spending on Identity and Access Management (IAM) solutions is on pace to rise by 62% over the next five years, which comes as no surprise. With the collapse of the traditional corporate network, stationing “gatekeepers” around individual assets is the only way to balance productivity with security.
PAM is one subset of IAM, and an important one because 74% of all data breaches involve some form of privileged credential abuse. PAM solutions first authenticate a user’s identity, then grant privileges based on that identity. They’re a vital tool for modern cybersecurity; 70% of organizations now use some form of PAM, up from 40% in 2020.
On the surface, the case for using PAM to grant database access looks strong. The problem is that PAM solutions are not data or database aware: they don’t interface with data or databases effectively, so they don’t manage access effectively either, and everything from security to accessibility suffers as a result.
You will benefit from deploying a PAM solution elsewhere. For databases, though, they’re an obstacle at best and a massive liability at worst. They’re explicitly the wrong tool for the job, and it’s important to understand why.
Why Your PAM Solution Fails for Database Security
PAM solutions applied to databases work something like this: does your privilege grant you access to this database? If yes, come inside. That approach creates authentication, authorization, and auditing issues that are important to be aware of before deploying a PAM solution for your databases:
- Authentication – A PAM solution focuses on privileged user authentication. However, privileged users only represent a subset of what accesses a database today. The number of apps, browser tools, microservices, and BI tools accessing databases is growing much faster than users by comparison, yet PAM solutions don’t support them. In practice, applications have to circumvent the PAM solution in order to access the database, which ultimately defeats the security purpose of PAM. Even for users, PAM requires rigid, agent-based deployments and certificates to authenticate properly to databases, which also breaks down at scale. Good authentication should make access easier for anything or anyone with permission. PAM does exactly the opposite.
- Authorization – PAM solutions work in a very binary way – access is granted or denied. With databases, they are not equipped to grant privileges based on who or what is accessing the data, what they are accessing, and for what purpose. PAM solutions authorize everyone to do the same thing. To better protect databases, companies need to provide the right privileges (e.g. admin, read/write, read-only), field-level controls (e.g. data masking), and real-time governance (e.g. Just-In-Time access) to specific users and user groups. Without these types of fine-grained controls, access is either too restrictive, limiting productivity, or too relaxed, increasing risk. Databases require granular authorization but, once again, PAM does exactly the opposite.
- Auditing – One of the main challenges with database security is that traditional products like PAM are not database-centric. They serve as a jump-host to the database server, and don’t provide any audit capabilities beyond the users logging into them to access the database. They are unable to provide any visibility into what native accounts may be used by users or apps that can be used to bypass the PAM server itself, there is no accounting of what data resides in the database and if it is actually accessed by anyone, and no visibility into any application activity. All these limitations result in challenges for security, operations and compliance teams.
Perhaps the strongest argument against using a PAM solution for databases is not that it’s ineffective. PAM is also hard to implement at speed or scale. Agent-based systems are obstacles to getting this initiative off the ground. Deploying a PAM in front of various data repositories in different environments is nontrivial. Consequently, most attempts to put PAM on databases stall out before they even have a chance to underperform.
What Does Strong Database Security Look Like?
Looking at what PAM can’t do makes it easy to imagine what the ideal solution looks like. It must be able to authenticate anyone and any application from anywhere, and do so in a way that’s secure, efficient, and consistent. Then, it must be able to apply security controls that carefully dictate privileges on the data layer.
Checking both those boxes doesn’t just fill the gaps in PAM solutions. It catalyzes a company’s data strategy. How? By connecting more data consumers with more data sources while minimizing the risk of something dangerous getting inside the database. More queries get fulfilled and fewer (if any) breaches reach the data. That’s the true win-win.
The ideal solution for database IAM is not imaginary. It’s Cyral. Contact us about arranging a demonstration.