SentriScope System Architecture

1. Executive Summary

SentriScope is a production-grade SaaS Cyber Risk Intelligence Platform built on Django. It is SaaS-first by design — multi-tenancy, audit logging, and tenant isolation are architectural foundations, not retrofitted features.

The platform provides enterprise security teams with:

• Canonical data normalization — All security data (assets, vulnerabilities, identities, incidents, threat intelligence) normalized into a single canonical model regardless of source.
• Risk-based prioritization — Deterministic, explainable risk scoring with full scoring lineage.
• Intelligence-driven correlation — Attack paths, IOC correlation, threat actor profiling, and assessment management.
• AI-augmented query — Natural language to SQL pipeline over canonical data with strict schema grounding and security guardrails.
• Connector ecosystem — Governed ingestion from EDR, CMDB, vulnerability scanners, threat intel feeds, ITSM, and security rating platforms.

2. High-Level Architecture

┌────────────────────────────────────────────────────────┐
│                     Load Balancer                      │
│              (SSL termination, routing)                │
└──────────────┬─────────────────────┬───────────────────┘
               │                     │
       ┌───────▼──────┐      ┌──────▼───────┐
       │   Django App  │      │  Django App   │
       │  (WSGI/ASGI)  │      │  (WSGI/ASGI)  │
       │   Instance 1  │      │   Instance N  │
       └───────┬──────┘      └──────┬───────┘
               │                     │
     ┌─────────▼─────────────────────▼─────────┐
     │          Middleware Pipeline             │
     │  SecurityHeadersMiddleware               │
     │  HostRoutingMiddleware (URLconf switch)  │
     │  SessionMiddleware                       │
     │  AuthenticationMiddleware                │
     │  TenantContextMiddleware ◄── Fail-closed │
     │  AuditMiddleware                         │
     │  CSPMiddleware                           │
     └─────────┬───────────────────────────────┘
               │
     ┌─────────▼─────────────────────────────────┐
     │           Application Layer               │
     │  tenants │ accounts │ audit │ console     │
     │  platform_console │ security │ jobs        │
     │  canonical │ connectors │ reference        │
     │  intelligence_dashboard │ decision_intel   │
     │  llm │ compliance │ billing │ entitlements │
     └─────────┬───────────────────────────────┘
               │
     ┌─────────▼────────────┐  ┌──────────────┐
     │  Database Layer       │  │  Redis/Cache │
     │  Default DB (Shared)  │  │  (per-tenant │
     │  Tenant DB 1 (Dedic.) │  │   key space) │
     │  Tenant DB N (Dedic.) │  └──────────────┘
     └───────────────────────┘  ┌──────────────┐
                                 │    Celery    │
                                 │ (tenant-ctx  │
                                 │  enforced)   │
                                 └──────────────┘

3. Application Responsibilities

4. Directory Structure

sentriscope/
├── config/                    # Django project configuration
│   ├── settings/
│   │   ├── base.py            # Shared, security-hardened defaults
│   │   ├── development.py     # Local dev overrides
│   │   ├── production.py      # Production enforcement
│   │   └── test.py            # Test-optimized settings
│   ├── celery.py              # Celery with tenant enforcement
│   ├── urls.py / urls_portal.py / urls_tenant.py / urls_public.py
│   └── wsgi.py / asgi.py
├── apps/
│   ├── tenants/               # Multi-tenant core
│   ├── accounts/              # Identity, RBAC, authentication
│   ├── audit/                 # Immutable audit logging
│   ├── console/               # Platform API (control plane)
│   ├── platform_console/      # Portal UI
│   ├── security/              # Encryption, secrets, validators
│   ├── jobs/                  # Tenant-aware Celery tasks
│   ├── canonical/             # Canonical data models
│   ├── connectors/            # Connector framework and integrations
│   ├── reference/             # Platform-shared reference data
│   ├── compliance/            # Compliance and governance
│   ├── billing/               # Billing
│   ├── entitlements/          # Entitlements and quotas
│   ├── intelligence_dashboard/ # Intelligence dashboard
│   ├── decision_intelligence/ # Decision Intelligence Layer
│   ├── llm/                   # LLM integration
│   └── attack_graph/          # Attack graph
├── templates/                 # Django templates (pt-BR)
├── static/                    # Static assets
├──               # Active documentation (see README.md)
└── conftest.py                # Shared test fixtures

5. Host-Based Multi-Application Routing

The platform serves three distinct applications from one codebase using host-based URLconf switching:

HostRoutingMiddleware sets request.urlconf and request._host_type before any view runs. Unknown hosts return 404 immediately — no routing to any view.

6. Key Invariants

These invariants are enforced at the platform level and must never be violated:

1. Every business model inherits TenantAwareTimestampedModel.
2. Every ORM query outside a tenant context raises TenantContextError.
3. Tenant A can never read or write Tenant B's data — enforced by ORM, RLS, and middleware.
4. Every security-relevant action is audit-logged via log_audit_event().
5. Every Celery task carries tenant_id and uses @tenant_task().
6. No global cache keys — all cache keys are tenant-scoped.
7. No credentials stored in plaintext — encrypted via Secrets Manager.
8. Platform scope and Tenant scope are mutually exclusive per session.

7. Extension Model

Future products plug into this platform without modifying platform core:

1. Create a new app under apps/ (e.g., apps/vuln_scanner/)
2. Inherit from TenantAwareTimestampedModel for all business data models
3. Use TenantAwareManager (automatic via TenantAwareModel)
4. Use TenantAwareTask as the Celery base class
5. Declare feature flags in PlanFeatureFlag for feature gating
6. Use log_audit_event() for all security-relevant operations

No changes to the platform core are required.

Related Articles

• SentriScope Data Architecture