Skip to main content

14.4 — Data Access Controls & Row-Level Security

1. What DAC solves​

Space membership answers:

Can this user access this space?

Data Access Control answers:

Which rows inside the secured object may this user see?

This is row-level security.

2. Conceptual architecture​

USER ID | v PERMISSIONS ENTITY | v AUTHORIZATION CRITERIA | v SECURED OBJECT | v FILTERED RESULT

3. Permission data​

A permissions entity typically maps users to permitted criteria.

Example conceptual data:

USERCOMPANY_CODE
user_a1000
user_a1100
user_b2000

The business object can then be secured according to the relevant authorization criterion.

4. DAC versus role authorization​

Do not confuse them.

Roles control what the user can do.

DAC controls which authorized data the user can see in supported scenarios.

Both layers may be necessary.

5. Full-data access​

A user with sufficiently powerful unrestricted data privileges can bypass data-level restrictions.

Therefore:

Never design DAC while ignoring powerful administrator roles.

Security testing must include privileged-user scenarios.

6. Hierarchy-based authorization​

Datasphere supports hierarchy-based Data Access Control patterns, including hierarchy-with-directory scenarios.

This is useful when authorization follows organizational or business hierarchies.

Example:

GLOBAL | +-- EMEA | +-- Germany | +-- France | +-- AMERICAS +-- USA +-- Canada

An authorization model can grant a user access at an appropriate hierarchy node and include descendants where the model supports that behavior.

7. Security dimensions​

Typical dimensions include:

  • company;
  • sales organization;
  • purchasing organization;
  • region;
  • country;
  • cost center;
  • business unit.

Choose authorization dimensions deliberately.

8. DAC design rules​

Avoid:

  • duplicated permission logic;
  • uncontrolled many-to-many mappings;
  • business rules hidden in opaque SQL;
  • inconsistent user identifiers;
  • authorization data without ownership;
  • no negative testing.

9. Testing DAC​

Always test:

Positive​

User receives exactly the authorized rows.

Negative​

User cannot see unauthorized rows.

Boundary​

User with multiple authorizations receives the union intended by the design.

Privileged​

Administrator behavior is explicitly tested.

Change​

Removing authorization removes access as expected.

10. Performance​

Row-level security can affect query behavior.

Monitor:

  • permission entity size;
  • join/filter complexity;
  • authorization cardinality;
  • query concurrency;
  • downstream consumption;
  • repeated authorization evaluation.

Do not optimize security by weakening it.

Hands-on lab​

Build a procurement authorization model:

  • buyer A → Germany;
  • buyer B → France;
  • procurement lead → Germany + France;
  • central procurement → all authorized regions.

Then design positive and negative test cases.

Architect exercise​

Design row-level security for 10,000 users and 5 million authorization mappings.

Defend:

  • permission data model;
  • refresh strategy;
  • hierarchy strategy;
  • failure behavior;
  • performance monitoring;
  • emergency access procedure.