Skip to main content

14.1 — Security Foundations

1. The security mental model​

Think about access as a chain:

IDENTITY | v GLOBAL AUTHORIZATION | v SPACE MEMBERSHIP | v OBJECT / TASK PRIVILEGES | v DATA ACCESS CONTROL | v CONSUMPTION BOUNDARY

A failure at any layer can produce either too much access or no access.

2. Authentication versus authorization​

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

Datasphere security architecture must keep these questions separate.

3. Major security layers​

Tenant administration​

Controls platform-wide administrative capabilities such as users, roles and spaces.

Space authorization​

A space is both a data-residence boundary and an authorization boundary. Objects and data inside a space are not automatically available outside it.

Application and object privileges​

Privileges determine which tools and operations a role can perform.

Data Access Control​

Data Access Controls provide row-level filtering for supported objects. The authorization criteria are evaluated against the user's identity and the permissions data.

Consumption security​

Only explicitly exposed data should cross the boundary into external consumers.

4. Least privilege​

Least privilege means granting the minimum authority required for a job.

Bad design:

  • everyone receives administrator privileges;
  • every analyst receives every space;
  • modelers receive unrestricted production access.

Better design:

  • platform administrators administer the tenant;
  • space administrators administer designated spaces;
  • modelers receive modeling privileges only where required;
  • consumers receive consumption access without modeling privileges;
  • row-level restrictions are handled with Data Access Controls where required.

5. Security boundaries are architecture decisions​

Do not start with:

Which role should I assign?

Start with:

  1. What is the user trying to do?
  2. In which space?
  3. On which object?
  4. At which operation level?
  5. At which data-row level?
  6. Through which consumer?
  7. What evidence must exist after the access is granted?

6. Security threat model​

Consider:

  • unauthorized discovery;
  • unauthorized data access;
  • excessive write authority;
  • cross-space leakage;
  • accidental exposure;
  • privilege escalation;
  • stale role assignments;
  • orphaned users;
  • excessive administrator concentration;
  • weak auditability.

7. Security design principle​

A good security architecture is understandable by another administrator six months later.

Architect exercise​

Design authorization for:

  • 3 platform administrators;
  • 8 data engineers;
  • 20 analysts;
  • 200 business consumers;
  • Finance, Procurement and Sales spaces;
  • regional row-level restrictions.

Document the required boundary at each layer before selecting roles.