Semantic Layer Security and Access Control: Protecting Governed Metrics

Semantic layer security and access control is the practice of protecting governed metrics by ensuring only authorized users and systems can access specific data based on their role, context, and need. A semantic layer without proper security is a liability - it could expose sensitive metrics to unauthorized viewers or allow data leakage that violates compliance requirements.

Security in a semantic layer is not just about preventing breaches. It is about enabling safe self-service analytics where users can freely explore the data they are permitted to see while being reliably prevented from accessing data they should not.

Security Dimensions

Authentication: Who Is Asking?

Verify the identity of every requestor:

User authentication:

• SSO integration (SAML, OIDC)
• Username/password for legacy systems
• Multi-factor authentication for sensitive access

Service authentication:

• API keys for applications
• Service accounts for system integrations
• Certificate-based authentication for high-security environments

Authorization: What Can They Access?

Determine permissions for authenticated identities:

Metric-level access: Who can query which metrics?

Dimension-level access: Which dimensions can each user see?

Row-level access: Which data rows are visible to each user?

Column-level access: Which columns are accessible or masked?

Access Control Models

Role-Based Access Control (RBAC)

Assign permissions to roles, assign roles to users:

roles:
  finance_analyst:
    metrics:
      - revenue: read
      - costs: read
      - profitability: read
    dimensions:
      - region: all
      - product: all
      - customer_name: masked

  regional_manager:
    metrics:
      - revenue: read
      - pipeline: read
    row_filters:
      - region: ${user.assigned_region}

  executive:
    metrics: all
    dimensions: all
    row_filters: none

users:
  jsmith:
    roles: [finance_analyst]
  mwilson:
    roles: [regional_manager]
    attributes:
      assigned_region: "North America"

RBAC works well for organizations with clear role boundaries.

Attribute-Based Access Control (ABAC)

Make access decisions based on attributes:

policies:
  - name: regional_data_access
    condition: |
      user.department == "sales" AND
      data.region IN user.assigned_regions
    grant: read

  - name: sensitive_metric_access
    condition: |
      metric.sensitivity_level <= user.clearance_level
    grant: read

  - name: pii_masking
    condition: |
      dimension.contains_pii == true AND
      user.pii_access != true
    action: mask

ABAC provides flexibility for complex access requirements.

Hybrid Approaches

Combine RBAC and ABAC:

• RBAC for baseline permissions
• ABAC for dynamic, context-aware decisions
• This handles both organizational structure and situational needs

Implementation Patterns

Metric-Level Security

Control access to entire metrics:

metric:
  name: employee_compensation
  access:
    roles: [hr_analyst, executive]
    deny_message: "This metric requires HR or Executive role"

Users without access cannot query this metric at all.

Dimension-Level Security

Control access to specific dimensions:

dimension:
  name: customer_name
  access:
    default: masked
    full_access_roles: [account_manager, executive]
    masking_function: hash_customer_name

Unauthorized users see masked values; authorized users see real names.

Row-Level Security

Filter data based on user context:

row_security:
  name: regional_filtering
  applies_to: [revenue, pipeline, customer_count]
  filter: region IN (${user.authorized_regions})

  exceptions:
    - roles: [executive, global_analyst]
      filter: none  # See all regions

Each user's queries automatically include their filter.

Column-Level Security

Control visibility of specific columns:

column_security:
  - column: ssn
    access: [hr_admin]
    mask_for_others: "***-**-****"

  - column: salary
    access: [hr_analyst, executive]
    mask_for_others: null  # completely hidden

Security in the Query Path

Pre-Query Security

Before executing queries:

1. Authenticate user
2. Validate requested metrics against user's metric permissions
3. Check dimension access
4. Construct row-level filters
5. Only then generate and execute query

Query Modification

Inject security into queries:

-- Original query
SELECT region, SUM(revenue) FROM sales GROUP BY region

-- With row-level security for user jsmith
SELECT region, SUM(revenue) FROM sales
WHERE region IN ('North America', 'Europe')  -- jsmith's regions
GROUP BY region

Post-Query Security

After query execution:

• Mask sensitive columns in results
• Audit log the access
• Apply any output transformations

Integration with Identity Systems

SSO Integration

Connect to enterprise identity:

authentication:
  provider: okta
  protocol: SAML

  attribute_mapping:
    user_id: nameID
    email: email
    department: custom.department
    regions: custom.sales_regions

Group Synchronization

Sync roles with identity provider groups:

group_mapping:
  "okta://groups/Finance-Analysts": finance_analyst
  "okta://groups/Sales-Managers": regional_manager
  "okta://groups/Executive-Team": executive

Just-In-Time Provisioning

Create semantic layer accounts automatically:

1. User authenticates via SSO
2. Semantic layer checks if account exists
3. If not, create account with default role
4. Map groups to roles
5. User proceeds with appropriate access

Audit and Compliance

Query Logging

Log every query for audit:

{
  "timestamp": "2024-02-21T10:30:00Z",
  "user_id": "jsmith",
  "user_email": "jsmith@company.com",
  "user_roles": ["finance_analyst"],
  "requested_metrics": ["revenue", "costs"],
  "requested_dimensions": ["region", "quarter"],
  "filters_applied": ["year = 2024"],
  "row_security_applied": ["region IN ('NA', 'EU')"],
  "result_row_count": 8,
  "execution_time_ms": 245,
  "source_ip": "10.0.1.50",
  "client_application": "tableau_server"
}

Access Reviews

Periodic review of access rights:

1. Generate report of all users and their permissions
2. List metrics accessed by each user
3. Identify unused permissions (granted but never used)
4. Review with business owners
5. Revoke unnecessary access
6. Document review completion

Compliance Reporting

Support compliance requirements:

SOX compliance:

• Track access to financial metrics
• Document segregation of duties
• Maintain access change history

GDPR compliance:

• Log access to personal data
• Support data subject access requests
• Enforce data retention policies

HIPAA compliance:

• Control access to health information
• Maintain detailed audit trails
• Implement minimum necessary access

Security Best Practices

Principle of Least Privilege

Grant minimum necessary access:

• Start users with no access
• Add permissions as needed
• Require justification for broad access
• Review and revoke unused permissions

Defense in Depth

Layer security controls:

Layer 1: Network security (firewall, VPN)
Layer 2: Authentication (SSO, MFA)
Layer 3: Semantic layer authorization
Layer 4: Database-level security

Breach of one layer does not compromise everything.

Secure Defaults

Default to restrictive:

• New metrics are restricted until explicitly granted
• New users have minimal permissions
• API endpoints require authentication
• Logging is always enabled

Separation of Duties

Divide critical functions:

• Those who define metrics should not control access
• Those who grant access should not be sole users
• Security policies require multiple approvers

Common Security Scenarios

Scenario: Multi-Tenant SaaS

Isolate customer data:

row_security:
  name: tenant_isolation
  applies_to: all_metrics
  filter: tenant_id = ${session.tenant_id}
  mandatory: true  # Cannot be bypassed

Scenario: Hierarchical Organization

Manager sees their team's data:

row_security:
  name: org_hierarchy
  filter: |
    employee_id IN (
      SELECT id FROM employees
      WHERE manager_chain CONTAINS ${user.employee_id}
    )

Scenario: Time-Limited Access

Temporary elevated permissions:

access_grant:
  user: contractor_a
  role: data_analyst
  expires: "2024-03-31"
  granted_by: security_admin
  reason: "Q1 audit project"

Security and access control make the semantic layer trustworthy - not just in data accuracy but in data protection. Users can confidently use self-service analytics knowing they can only see what they are authorized to see. Organizations can confidently deploy semantic layers knowing sensitive data remains protected.