Security & Compliance Overview

Security in Struktural is not an afterthought; it is built into the lowest levels of the data access layer. The platform employs a multi-layered defense strategy to ensure data privacy, isolation, and compliance with modern enterprise standards (such as GDPR, HIPAA, and SOC2).

1. Role-Based Access Control (RBAC)

RBAC governs what actions a user can perform at the macro level.

• System Roles: Users are assigned roles (e.g., Manager, Operator, Auditor). These roles dictate base permissions across the system.
• Granular Operations: Permissions are explicitly granted per entity and per operation type (Create, Read, Update, Delete). If a permission is not explicitly granted in the Struktural_Sys_Permission table, the system defaults to DENY.
• Action Security: Custom Actions (UI Buttons) can be individually protected, ensuring that only specific roles (e.g., Financial Controller) can execute high-risk functions like "Approve Wire Transfer".

UI Approach: Navigate to the Users & Roles module in the Studio.

• To manage users, use the Users tab to manually create accounts and assign their base roles.
• To configure permissions, switch to the Roles & Permissions tab. Select a Role from the top dropdown, then use the section dropdown to configure access across Entities, Fields, Custom Actions, Menus, and Views using the interactive grid checkboxes. You can also map specific SSO Entra ID Object IDs directly to a Role here.

2. Row-Level Security (RLS) and Data Isolation

RLS governs which specific records a user is allowed to see or interact with, even if they have read access to the table. Struktural enforces this at the Entity Framework Query level, meaning it cannot be bypassed by clever API requests.

• Dynamic Profiles: Users are mapped to Profiles based on their Single Sign-On (SSO) Entra ID Groups. A Profile contains Dynamic LINQ filters (e.g., Region == "North America"). The engine automatically appends this filter to all database queries.

• Materialized ACLs (Hierarchical RLS): For complex graph data (e.g., Folders containing sub-folders and files), calculating dynamic permissions on-the-fly is too slow. Struktural uses an asynchronous background worker to calculate the intersection of permissions and flattens them into a __Struktural_Acl column directly on the target tables. This provides instantaneous read performance while maintaining deep hierarchical security.

  Schema Configuration (JSON Approach): To enable this, define the SecurityInheritance array on the child entity in app-schema.json.

  • 1:N Direct Inheritance: {"InheritFrom": "Folder", "ViaField": "FolderId"}
  • M:N Junction Inheritance: {"InheritFrom": "Project", "ViaJunction": "ProjectDocument", "JunctionLocalField": "DocumentId", "JunctionParentField": "ProjectId"}

  Schema Configuration (UI Approach):

  1. Navigate to the Data Schema module.
  2. Select the child entity (e.g., Document).
  3. In the right-hand Properties pane, scroll down to Hierarchical Security (RLS).
  4. Click Add Inheritance Rule.
  5. Select the parent entity to inherit from, choose the Strategy (Direct vs Junction), and map the corresponding Foreign Key fields.

3. Field-Level Security (FLS) and Encryption

FLS ensures that highly sensitive data columns (e.g., Social Security Numbers, API Keys, Medical Diagnoses) are completely hidden from unauthorized users.

• API Scrubbing: If a user lacks the specific FLS grant to read a field, the Struktural API physically removes that property from the JSON payload before transmitting it over the network.
• Encryption at Rest: Fields designated as ApplicationWideSecureString are automatically encrypted at the application layer using AES-256 before being written to the database. Even if a malicious actor gains direct access to the SQL database backups, the data remains unreadable without the Master Encryption Key held in Azure Key Vault or AWS Secrets Manager.
• End-to-End Encryption (E2EE): For extreme security scenarios, UserSecureString fields utilize client-side RSA encryption. The server only ever sees ciphertext, ensuring a zero-knowledge architecture.

4. Audit Trails (WORM Compliance)

To comply with strict regulatory frameworks, entities can be marked as Audited.

• Immutability: When enabled, physical deletion of records is intercepted and converted to a Soft Delete.
• Change Tracking: A dedicated [EntityName]_Audit table is automatically generated. The engine records every mutation, saving the old state, the new state, the exact timestamp, and the identity of the actor.
• Semantic Integrity: The platform's internal validators prevent configuration combinations that break compliance—for example, preventing an Administrator from granting "Hard Delete" permissions to standard users on an audited entity.