A closer look at the granularity and security of an ABAC solution
While many data platform solutions implement attribute-based access control (ABAC) security layers, it is important to analyze the nuances between different design philosophies and implementations in order to understand which solution is right for a specific use case.
The granularity of the ABAC implementation is an often overlooked, yet critical, consideration for determining the scalability and Zero Trust nature of the solution. Additionally, the overall security of different solutions can be impacted by the specific implementation of the ABAC layer.
Both of these details, in addition to common factors such as maintenance, storage, and performance considerations, can drastically change the short-term and long-term costs and security of a database platform secured with ABAC.
Granularity
Describing a database solution as ABAC-secured does not inherently describe the granularity of this security. This, in turn, can obscure the ramifications of different granularity levels.
Applying ABAC labels at the cellular level allows for total access control over every single piece of data, whereas ABAC at any higher level (i.e., row, column, table, bucket, etc.) allows for access control only down to the level where the label is applied. Therefore:
- ABAC at the cellular level is the pinnacle of a Zero Trust data layer solution because every single data point is checked that its attributes match the requester’s permissions before being disseminated.
- Higher granularity solutions are only Zero Trust down to the level where the label is applied; beyond that point the data does not adhere to Zero Trust principles.
While the level at which the ABAC labels can be applied is important, so, too, is the complexity of the labels themselves that can be applied. One solution is a policy-based approach, and while that is familiar and generally easy to understand, it limits the granularity by orders of magnitude and is much more manual that it otherwise needs to be.
Another solution is to use a programmatic approach to describing ABAC labels that can adhere to policy as well, but it has the added benefit of creating labels based on anything that can be described by code, whether external or internal to the data itself. Labels based on pieces of, combinations of, or interpretations of the data or the overarching policy can be easily and comprehensively built to ensure the accuracy and granularity of any application.
Security
There are significant security considerations when it comes to the method in which ABAC security labels are applied. Two primary approaches are:
- applying labels as part of a security addition to an existing system, and
- applying labels as an intrinsic part of the data storage.
ABAC policies applied as an addition to a system have the advantage of leaving the underlying databases unchanged and in place, however, the underlying databases can still be accessed by bypassing the ABAC security filter. Internal users, connectors straight into the databases, admin users, and anything or anyone else with the ability to access the original databases represent security vulnerabilities and would not be protected by the new ABAC layer. Applying labels as an intrinsic part of the data storage avoids this risk.
Besides the security considerations, there is also technical debt and complexity that is expounded with a layered solution but reduced with a built-in ABAC solution. When requests have to be routed through to multiple disparate databases, the complexities and quirks of each of those databases must be accounted for, and the individual databases must be maintained over time. Those maintenance considerations and complexity can be reduced down to a single database when the data is brought into a centralized database and ABAC-tagged during the move.
To learn more, contact us or try Koverse for free today koverse.com/get-started