SentriScope Security Architecture

1. Security Overview

SentriScope applies a defense-in-depth security model across all layers: transport, authentication, authorization, data, LLM, and audit. All controls are aligned with OWASP Developer Guide and mapped to SOC 2 Trust Services Criteria.

2. Operator Scope Boundary Model

2.1 The Problem

In a multi-tenant SaaS, a single user might theoretically be both a platform operator and a tenant user. Without enforcement, privilege escalation across the platform/tenant boundary is possible.

2.2 The Solution: operator_scope

Every authenticated session carries exactly one scope:

session["operator_scope"] = "PLATFORM" | "TENANT"

No dual-scope sessions exist. Users who qualify for both must log in on the appropriate host.

2.3 Three Lines of Defense

2.4 Scope Rules by Host

2.5 Fail-Closed Behavior

All mismatches return 404 (not 403 — never reveal resource existence):
- Scope mismatch → 404
- Missing scope → 404
- Missing tenant → 404
- Missing membership → 404
- Unknown host → 404

3. RBAC Model

3.1 Platform Roles (Django Groups)

All platform-scope groups are prefixed with PLATFORM_:

Custom roles may be created via Portal → Roles → New Role.

3.2 Tenant Roles

Stored in UserTenantMembership.role:

3.3 Intra-Tenant Hierarchy

Within a tenant, users may be further scoped to a BusinessUnit or Team:
- Team/BU-scoped queries filter server-side by business_unit_id or team_id.
- LLM queries never receive team_id or business_unit_id from user prompt — only from session context.
- Authorization must happen before aggregation — no reuse of tenant-wide aggregates for scoped users.

4. Security Control Layers

4.1 Edge and Transport Security

• TLS 1.2+ enforced on all connections (prefer TLS 1.3)
• HTTP → HTTPS redirect enforced
• HSTS enabled with long max-age
• WAF required in production
• No public database exposure
• Firewall: ingress restricted to ports 80, 443

SOC 2: CC6.6, CC6.7, CC7.1

4.2 Authentication and Identity Security

• Mandatory MFA enforcement (tenant-configurable; cannot be bypassed once enabled)
• Step-up MFA for privileged actions
• Session rotation on login
• Account lockout: 5 failed attempts / 30-minute window
• Impossible travel detection (IP-based geolocation)
• Suspicious browser/IP/OS detection
• Device fingerprinting
• Active session monitoring
• Security email notifications on new login (IP, OS, browser, timestamp)

SOC 2: CC6.1, CC6.2, CC7.2, CC7.3

4.3 Application-Level Security

• CSRF tokens on all state-changing forms
• CSP headers — no inline scripts; CDN resources require SRI
• X-Frame-Options: DENY
• Referrer-Policy: strict-origin-when-cross-origin
• Cache-Control: no-store, no-cache, must-revalidate, private on authenticated responses
• All user content auto-escaped by Django templates
• No |safe or mark_safe() in templates
• IDOR checks: object.tenant_id == request.tenant.id validated on every mutation

4.4 API Security

• All API endpoints require HasTenantAccess permission
• RBAC permission classes applied per endpoint: IsAnalyst, IsTenantAdmin, etc.
• get_queryset() overrides filter by current tenant automatically
• Input validation via DRF serializers
• Rate limiting per tenant via connector rate limit model

SOC 2: CC6.3, CC6.6

5. Data Classification Model

5.1 Classification Rules

• Classification applies at entity level and field level.
• Field-level classification overrides entity-level classification.
• Related entities do not inherit classification automatically.
• Classification is stored in canonical metadata.
• LLM response masking uses the classification stored at snapshot time (never retroactively reclassified).

5.2 LLM Data Masking

The LLM pipeline enforces masking before returning data to users:

• CONFIDENTIAL fields: values masked as [CONFIDENTIAL].
• RESTRICTED fields: values masked as [REDACTED], not sent to LLM.
• Column-level masking applied by apps/llm/masking.py before query execution.
• No PII or credential material ever included in LLM prompts or responses.
• LLM query logs are stored without raw PII.

6. Encryption and Key Management

• At rest: Database fields containing PII and credentials are encrypted via apps.security.encryption. AES-256-GCM.
• Credentials: Never stored in plaintext. Always via credential secret reference pointing to the Secrets Manager.
• Key rotation: Historical records remain accessible after rotation (re-encryption transparent); backup uses the same key policy.
• Tenant-scoped encryption context: Per-tenant encryption keys are optional; shared-DB tenants use logical isolation with shared key unless dedicated key is configured.
• No credentials in logs or audit events.

SOC 2: CC6.7, CC6.8

7. Connector Security

• Connector credentials stored only in credential secret reference. Never in connector_config JSON or logs.
• Webhook payloads validated for signature, timestamp, and replay nonce before processing.
• Webhook replay protection: timestamp tolerance ±5 minutes; idempotency keys required; out-of-tolerance events rejected and logged as security events.
• Connector trust levels: Tier 1 (high trust, API key), Tier 2 (OAuth), Tier 3 (webhook, lowest trust — full payload validation required).

8. Internal Service Authentication

• Internal service-to-service calls use mTLS or signed JWT.
• No database access without service identity.
• Least-privilege principle: services have only required permissions.
• Internal calls are auditable.

9. Abuse Detection

• Abuse thresholds are not exposed to end users (opaque enforcement).
• Automated actions on detection: throttling, suspension, alert.
• Progressive escalation: throttle → suspension → account lock.
• All automated enforcement actions are audit-logged.

10. Session Management

Session cookies are scoped by domain. Portal and tenant sessions are browser-isolated by domain.

11. SOC 2 Control Mapping Summary

For detailed SOC 2 readiness plan, see:

Related Articles

• SentriScope Data Architecture
• SentriScope LLM Architecture