Devise an Attribute-based Access Control Plan that Won’t Affect Database Performance

By: Morpheus Data

Basing data-access rights on the attributes of users, data, resources, and environments helps keep your data safe from thieves by preventing nearly all brute-force access attempts. However, applying attribute-based access controls to existing database systems requires careful consideration of potential performance bottlenecks you may be creating.

Attribute-based access controls (ABAC) for databases tend to be as simple or complex as the organization using them. For a 40-person office, it isn’t particularly difficult to establish the roles, policies, rules, and relationships you’ll use to determine users’ data access rights.

For example, to ensure that only managers in the finance department have access to the company’s financial data, create Role=Manager and Department=Finance. Then require these attributes in the permissions of any user who requests financial data.

As you can imagine, access controls are rarely that simple. When creating enterprise-wide ABACs, an attribute-management platform and machine-enforced policies may be required. IT Business Edge’s Guide to Attribute Based Access Control (ABAC) Definition and Considerations (registration required) outlines the major components of such an attribute-management system:

  • Enterprise policy development and distribution
  • Enterprise identity and subject attributes
  • Subject attribute sharing
  • Enterprise object attributes
  • Authentication
  • Access control mechanism deployment and distribution

The nuts and bolts of policy-based access controls

ABAC policies are established using the eXtensible Access Control Markup Language (XACML). As explained by ABAC vendor Axiomatics, attributes are assigned to subjects, actions, resources, and environments. By evaluating the attributes in conjunction with the rules of your policies, access to the data or resource is allowed or denied.

ABAC applies rules to access requests based on the attributes and policies you establish for subjects, environments, resources, and actions. Source: Axiomatics

Applying an ABAC system to existing RDBMSs can be problematic, as exemplified in a post from March 2014 on the Stack Exchange Information Security forum. In particular, what effect will implementing fine-grain access have on database performance? And can existing Policy Enforcement Points (PEPs) implement XACML?

Axiomatics’ David Brossard replies that performance is most affected by the PEP-to-PDP (Policy Decision Point) communication link, and the PDP-to-PIP (Policy Information Point) link. In particular, how you expose the authorization service PDP helps determine performance: if exposed as a SOAP service, you invite SOAP latency, and if exposed via Apache Thrift or another binary protocol, you’ll likely realize better performance.

Brossard identifies six areas where ABAC performance can be enhanced:

  • 1. How policies are loaded into memory
  • 2. How policies are evaluated
  • 3. How attribute values are fetched from PIPs
  • 4. How authorization decisions are cached by PEPs
  • 5. How authorization requests are bundled to reduce roundtrips between the PEP and PDP
  • 6. How the PEP and PDP communicate

Six potential performance bottlenecks in a typical ABAC implementation. Source: Stack Exchange Information Security

Database performance monitoring needn’t be so complicated, however. With the Morpheus database-as-a-service, you can use a single dashboard to monitor your heterogeneous MySQL, MongoDB, Redis, and ElasticSearch databases. You can invoke a new instance of any SQL, NoSQL, or in-memory database quickly and simply via the Morpheus dashboard.

Your databases are deployed on an SSD-backed infrastructure for fast performance, and direct patches to Amazon EC2 ensure the lowest latency available. Visit the Morpheus site to create a free account.