14.7 — Enterprise Security Architecture

1. Reference architecture

ENTERPRISE IDENTITY | v +-------------------+ | DATASPHERE TENANT | +-------------------+ | | | v v v GLOBAL SCOPED AUDIT ROLES ROLES / OPS | | +------+ | v DOMAIN SPACES | | | v v v DAC SHARING EXPOSED | | | +------+------+ | v CONSUMERS

2. Environment strategy

For enterprise lifecycle:

DEV | v TEST | v PROD

Security definitions must move through the same governed lifecycle as application content where supported.

Do not manually recreate complex security structures in production without governance.

3. Domain strategy

Example:

FINANCE PROCUREMENT SALES HR ENTERPRISE DATA

Every domain should have:

• owner;
• steward;
• administrator;
• modeler group;
• consumer group;
• data classification;
• authorization model.

4. Role engineering

Design roles around job functions, not individuals.

Bad:

Yogesh_Finance_Admin

Better:

FINANCE_SPACE_MODELer FINANCE_SPACE_VIEWER FINANCE_CONSUMER

5. Security matrix

Maintain a matrix such as:

Capability	Admin	Space Admin	Modeler	Viewer	Consumer
Tenant administration	Yes	No	No	No	No
Space administration	Selected	Yes	No	No	No
Modeling	As required	Yes	Yes	No	No
Data consumption	As required	Yes	Yes	Yes	Yes
Row-level restriction	Administer	Administer	Consume	Consume	Consume

The exact privileges must be validated against the current role model.

6. Security by design

Security should be reviewed at:

• source onboarding;
• space creation;
• model creation;
• sharing;
• consumption;
• production release;
• role review;
• incident response.

7. Data classification

Classify data before deciding access:

• public;
• internal;
• confidential;
• restricted.

Then map classification to:

• space;
• role;
• DAC;
• consumer;
• audit;
• retention.

8. Architecture decision records

For every important security decision record:

• requirement;
• threat;
• chosen control;
• alternatives;
• residual risk;
• owner;
• review date.

Architect capstone

Design security for:

• 4 environments;
• 12 domains;
• 3,000 users;
• 50,000 authorization relationships;
• SAC consumption;
• external audit access;
• regional restrictions.

Defend the model against privilege explosion and cross-domain leakage.