Appearance

Identity, Audit, and Compliance ​

This section describes identity/SSO configuration, ABAC, audit trails, and compliance alignment.

What You'll Learn

  • How to configure identity adapters and SSO for applications
  • How to apply ABAC requirements across apps, mounts, and Storage Contexts
  • How to set up audit trails that meet compliance requirements

1. Identity Access (SSO) ​

Identity access is configured via apps[].modifications.identityAccess and related identity settings.

Key principles:

  • Least-privilege SSO – Only apps that require tokens receive them.
  • Prefer file-based token injection over environment variables or registry where possible.
  • Use ABAC to require specific identity posture (for example, usPersonStatus=verified).

Typical tasks:

  • Map SSO adapters to specific apps.
  • Restrict which users or contexts receive tokens.
  • Align SSO scopes with app capabilities and DLP posture.

See: Identity Access (SSO)

2. ABAC and contextual controls ​

Attribute-based access control (ABAC) expressions can appear on:

  • App policies (apps[].authorization.requirements).
  • Mounts and Storage Context visibility (visibility.abac.requirements).
  • Other policy elements that support requirements.

Typical attributes:

  • userAttributes – Department, role, group membership, citizenship, clearance, etc.
  • contextConstraints – Allowed geos, device posture, network zone, machine health.

Use cases:

  • Restrict high-sensitivity apps to specific roles and geographies.
  • Require compliant hosts for access to Turbo Drive or removable media.
  • Enforce different policies for on-prem vs remote workers.

See: Authorization & Visibility

3. Audit trails and integrity ​

Audit configuration is global and defined under configuration.launch.runtime.audit plus policy-level audit settings.

Key capabilities:

  • Integrity – Hash chains, RFC3161 timestamping.
  • Failure policy – Fail closed when audit is unavailable.
  • Export – Forward events to SIEM with retention metadata.

Example:

json
{
  "configuration": {
    "launch": {
      "runtime": {
        "audit": {
          "settings": {
            "integrity": {
              "hashChain": true,
              "timestamping": {
                "mode": "rfc3161",
                "tsaUrl": "http://timestamp.provider.com"
              }
            },
            "failurePolicy": {
              "onFailure": "block",
              "requireHealthyFor": ["all"]
            },
            "export": {
              "mode": "siemForwarding",
              "deliveryGuarantee": "atLeastOnceConfirmed",
              "complianceMetadata": {
                "retentionPolicyRef": "WORM_7Y"
              }
            }
          }
        }
      }
    }
  }
}

See: Audit Trails

4. Compliance posture ​

By combining:

  • Allowlist application policy with strong matchAll rules.
  • ABAC-based authorization on apps, mounts, and storage.
  • DataMotion and DLP rules for clipboard/screen capture/export.
  • Hardened Secure Sandbox storage (encrypted, posture-validated volumes).
  • Integrity-protected audit trails with fail-closed configuration.

administrators can align Turbo Launcher deployments with frameworks such as CMMC, NIST, and ITAR.

Guidance:

  • Map audit event types to required control families (for example, access control, audit & accountability, media protection).
  • Use classification-aware DLP rules to enforce marking and handling requirements.
  • Enforce encryption-at-rest and device allowlists for removable media used as Secure Sandbox storage.

See:

Turbo.net © 2025