TrustLogix Policy Synchronization

Overview

Clients currently create and deploy policies on the TrustLogix platform to their respective data sources. However, there is a challenge in keeping the policies intact on objects when recreation of the objects happens as part of the development life cycle (either manually or via CI/CD pipelines).

To address this, there is a clear need for automation to keep the policy attachments. The automatic redeployment of the process is required to keep the policy reattached to the recreated objects so that sensitive objects are protected, thereby ensuring their security.

TrustLogix has introduced the automation service, called Policy Sync Service, to resolve this issue. This document provides end-to-end information on its internal workings.

The TrustLogix-managed Policy Sync Service can be activated upon request.

Sync Policy types Supported

• Object-based RBAC

• Object-based ABAC (RLS & Masking)

• Tag-based ABAC (RLS & Masking)

1. Objectives

1. Ensure governance policies remain enforced after object recreation.

2. Automatically detect drift between defined policies and actual enforcement.

3. Provide both on-demand and time-window (scheduled) remediation.

4. Maintain auditability and deterministic policy deployment.

2. Key Concepts

• Object Recreation Drift When a table/view is recreated, previously attached RBAC/RLS/Masking policies are removed.

• Policy Deployment Mode Intermediate state where policies are identified as applicable but not yet enforced.

• Tag Reference Store (Tag Ref) Metadata repository containing object ↔ tag mappings used for tag-based sync.

• Last Sync Timestamp Watermark used to identify delta objects.

3. Assumptions — Tag-Based Policies

Tag Latency Exists (Up to 2 Hours - Only for Snowflake)

In Snowflake:

• Tag assignment is immediate.

• But tag visibility in metadata views may be delayed.

• Tag references in ACCOUNT_USAGE may have latency.

• Tag propagation across replication may be delayed.

Sync Service Behavioral Assumptions

If Tag Not Found:

System assumes one of:

1. Tag not yet applied

2. Tag applied but not propagated

3. User forgot to apply tag

Because of latency, system must:

• Move policy to Pending Retry state

• Retry up to configured attempts

4. Lifecycle — Object-Based Policies

4.1 Creation & Initial Enforcement

1. An object (table/view) is created.

2. RBAC policy is defined and applied to objects.

3. ABAC RLS policy is created and attached.

4. Masking policy is applied to sensitive columns.

5. The object enters the Governed State.

4.2 Drift Scenario — Object Recreated

1. User drops/recreates objects.

2. Policies are no longer attached.

3. Object enters Ungoverned Drift State.

4.3 On-Demand Policy Sync Flow

Trigger: User knows event time and runs sync.

Flow

1. User triggers On-Demand Policy Sync Service.

2. Service reads configured last timestamp. [First time it will scan last 3 hours logs]

3. Identify objects recreated after timestamp.

4. For each object:

5. Lookup historical policy metadata.

6. Detects RBAC policy mapping.

7. Detects ABAC RLS policy mapping.

8. Detects masking configuration.

9. Mark policies as Deploy Mode in Trustlogix.

10. The Trustlet engine applies policies.

11. Object returns to Governed State.

4.3.1 On-Demand Policy Sync On Few Policies

Flow

Select only specific suggested policies

Allow users to manually choose which policies from the suggestion list should be processed.

Scenario

Drift engine identifies:

• 20 policies out of sync

• Admin wants to fix only 3 immediately

Instead of full sync, admin selects:

Policy A

Policy C

Policy F

System Behavior

• Accept selected policies

• Validate policy state (Active / Drifted)

• Process only selected policies

• Ignore others

Why This Matters

✔ Reduces execution scope ✔ Avoids impacting unrelated policies ✔ Enables staged rollout ✔ Supports emergency fixes

Sync Only Those Selected Policies Ensure the system enforces policies strictly within the selected scope.

Scenario

User selects 2 policies:

• Policy 1 → mapped to 10 tables

• Policy 2 → mapped to 5 views

System must:

• Evaluate only these 15 objects

• Not scan or evaluate other policies

Internal Flow

1. Fetch selected policies

2. Identify mapped objects

3. Perform drift detection per object

4. Generate delta enforcement plan

5. Deploy only required changes

Result

• Controlled execution boundary

• No cross-policy interference

• No global scan

Note: Un selected policies will be skipped and no action will be taken for those policies.

Avoid Re-Syncing Already Enforced Policies

Prevent re-execution of policies already correctly enforced.

Scenario

Policy appears in drift list due to:

• Cached metadata delay

• Object recreated but auto-tagged

• Manual DBA enforcement already done

• Actual Snowflake state is compliant.

Required System Behavior

Before enforcement:

1. Validate current datasource state:

2. Check POLICY_REFERENCES

3. Check grants

4. Check masking attachments

5. Compare expected vs actual state

6. If identical → Skip deployment

4.4 Scheduled Policy Sync Flow (Object-Based)

Trigger: Background job (e.g., hourly).

Flow

1. Scheduler runs sync jobs & scans the logs.

2. Scan metadata for objects recreated in the last 1 hour. [First time it will scan the last 3 hours of log data.]

3. For each object:

4. Check if object-level policies exist in TrustLogix.

5. Move policies to Deploy Mode.

6. Execute deployment.

7. Log audit record.

5. Lifecycle — Tag-Based Policies

5.1 Creation & Tagging

1. An object is created.

2. The object is tagged (domain/classification).

3. Columns are tagged (PII, Sensitive, etc.).

4. Tag metadata populated into Tag Ref.

5. ABAC tag-based RLS policy created.

6. ABAC tag-based masking policy created.

7. The object enters the Governed State.

5.2 Drift Scenario — Object Recreated

1. The object is recreated.

2. Tags and policies are no longer attached.

3. Object enters Tag Drift State.

5.3 On-Demand Tag-Based Sync Flow

Pre-requisite: Tag Ref must contain updated mappings.

Flow

1. The user triggers on-demand sync.

2. Sync service reads the last timestamp.

3. Identify objects tagged/untagged after timestamp.

4. Object tags

5. Column tags

6. Identify applicable ABAC policies.

7. Move policies to Deploy Mode.

8. Deploy policies and reapply grants.

9. Object returns to Governed State.

5.4 Scheduled Tag-Based Sync Flow

Trigger: Periodic job (e.g., hourly).

Flow

1. Scheduler runs sync jobs & scans the logs.

2. Sync service reads the last timestamp.

3. Identify objects tagged/untagged after timestamp.

4. Object tags

5. Column tags

6. Identify applicable ABAC policies.

7. Move policies to Deploy Mode.

8. Deploy policies and reapply grants.

9. Object returns to Governed State.

5.4.1 Object tags not populated for scheduled sync service

Flow

Handle scenarios where:

• A user recreates an object (table/view)

• Required governance tags are not yet populated

• Tag-based policies cannot be enforced immediately

• Scheduled Sync must retry intelligently before skipping

This ensures:

• No premature policy failures

• Controlled retry mechanism

• Reduced false drift alerts

• Stable enforcement behavior

6. Policy States

State	Description
Draft	Policy defined but not evaluated
Active	Policy attached and enforced
Drifted	Object exists but policy missing
Publish Mode	Policy queued for enforcement
Deployed	Deployment successful
Failed	Deployment error

7. Metadata & Inputs

Required Metadata

• Object creation timestamp

• Object recreation event

• Policy catalog (RBAC / RLS / Masking)

• Tag Ref mappings

• Last sync watermark

8. Audit & Observability

Each sync run should log:

• Sync type (On-Demand / Scheduled)

• Time window processed

• Objects evaluated

• Policies redeployed

• Failures

9. CI/CD Policy Sync API

API Endpoint

POST

/api/account/{accountId}/access_policies/sync

Description: sync policies based on object names provided.

Request:

Method: POST
Headers:
Content-Type: application/json
Accept: application/json
Authorization: <API Key>
Param:
ignoreSyncDatabases : true/false 
Default : false

NOTE: If client wants to do policy sync only for configured DBs, please enable this flag while sending the request. Please share the DB list to the TrustLogix support team.

• Body: JSON

[
  {
    "objectName": "BRONZE.PURCHASE.SALES_TRANSACTIONS"
  }
]
Responses:
200 OK: Indicates a successful operation.
Body: JSON
{
  "code": 200,
  "message": "Data access policies sync successfully done.",
  "data": [
    "Policy ID: 123, Policy Name: schema_multi_obj_policy PUBLISHED."
  ]
}

Authentication

API requests require authentication. Please refer to the Trustlogix API documentation for details on how to authenticate your requests. This typically involves a JWT token.