Secure Enterprise Operations Platform

Architecture & Security

How the platform is structured, how it is defended, and which tradeoffs were made deliberately.

System boundaries and data flow (target architecture)

Four trust zones with authorization enforced server-side at every hop. This is the production design; the MVP renders synthetic in-memory data with no auth, database or audit store.

  Zone 0 — Untrusted            Zone 1 — Edge              Zone 2 — Application            Zone 3 — Data
  ┌────────────────┐            ┌──────────────┐           ┌──────────────────────┐        ┌─────────────────┐
  │ Analyst browser│  TLS 1.3   │  CDN / WAF   │  mTLS     │ Route handlers       │  TLS   │ Managed Postgres│
  │ Auditor browser│ ─────────▶ │  Rate limit  │ ────────▶ │ AuthZ + validation   │ ─────▶ │ (KMS AES-256)   │
  └────────────────┘            │  TLS term.   │           │ Server functions     │        └─────────────────┘
                                └──────────────┘           │ Audit writer         │        ┌─────────────────┐
  ┌────────────────┐            ┌──────────────┐           │ AI triage (advisory) │ append │ Audit store     │
  │ Identity (SSO) │ ◀────────▶ │ Token verify │ ◀───────▶ │                      │ ─────▶ │ (write-once)    │
  │ MFA enforced   │   OIDC     └──────────────┘           └──────────┬───────────┘        └─────────────────┘
  └────────────────┘                                                  │ pull at runtime
                                                            ┌─────────▼──────────┐
                                                            │ Managed secret store│
                                                            └────────────────────┘
  • · No browser client ever talks to the data tier directly.
  • · Every request carries a verified identity; authorization is re-evaluated server-side.
  • · Secrets are injected at runtime and never present in source control or client bundles.
  • · Audit writes are on the critical path for state-changing actions.
  • · Design intent, not running code: identity, persistence, server-enforced RBAC and the audit store are roadmap items in this MVP.

Defense in depth (production design)

Layered controls, each independently useful. Documented target posture, not controls operating in this demo.

  1. Perimeter

    WAF, rate limiting, request size caps, TLS termination.

  2. Identity

    SSO with MFA, short-lived sessions, least-privilege roles.

  3. Application

    Deny-by-default authorization, schema validation, safe error handling.

  4. Data

    Encryption at rest, network isolation, scoped service credentials.

  5. Detection

    Structured audit events, anomaly alerting, retention for investigation.

  6. Process

    Peer review, dependency scanning, documented incident response.

RBAC model (documented design)

Deny by default. Roles are additive within a role, never across roles. Server-side enforcement is deferred in this MVP — the UI shows a fixed demo session.

RolePurposePermissions
AdminPlatform ownership and configuration.
  • · Manage users and roles
  • · Configure integrations and policies
  • · Read all records
  • · Cannot alter audit history
Security AnalystDay-to-day detection and response.
  • · Triage and update incidents
  • · Assign remediation tasks
  • · Read assets and vulnerabilities
  • · Request AI-assisted triage
AuditorIndependent assurance and evidence review.
  • · Read compliance mappings and evidence
  • · Read audit log
  • · Export reports
  • · No write access to operational records
ViewerRead-only situational awareness.
  • · Read dashboards
  • · Read non-sensitive summaries
  • · No exports
  • · No access to audit log

Encryption & secret management strategy (target architecture)

Established primitives only — no homemade cryptography. KMS, mTLS and managed secret storage are production design; the MVP stores nothing and holds no secrets.

  • In transit: TLS 1.2+ (1.3 preferred) with modern cipher suites, HSTS, and certificate lifecycle automation.
  • At rest: provider-managed AES-256 with KMS-held keys and scheduled rotation; backups inherit the same protection.
  • Credentials: password hashing and token issuance delegated to the identity provider (Argon2id/bcrypt, signed JWT/OIDC).
  • Secrets: injected from a managed secret store at runtime, scoped per environment, never committed, never exposed to the client bundle, rotated on personnel change.
  • Explicit non-goal: the platform implements no custom cryptographic algorithm, key derivation, or protocol.

Logging & monitoring (target architecture)

Evidence quality is a first-class requirement. The MVP demonstrates event content only; collection, redaction and immutable retention are production design.

  • Structured events: actor, role, action, entity, result, source address, correlation ID and UTC timestamp.
  • Coverage: authentication, authorization denials, record changes, exports, configuration changes and AI triage requests.
  • Redaction: secrets, tokens and sensitive payload fields are filtered before emission.
  • Integrity: append-only writes and replication to a store the application cannot modify.

Threat model summary

STRIDE-aligned analysis of the target architecture; mitigations listed are planned production controls. Assets in scope: asset inventory, vulnerability findings, incident records, audit trail, identities and secrets.

ThreatTrust boundaryMitigation
Credential theft against analyst accounts (Spoofing)Internet → Web tierSSO with enforced MFA, short-lived tokens, anomalous-login detection, session binding.
Privilege escalation via over-broad roles (Elevation of privilege)Web tier → Application tierDeny-by-default RBAC, server-side authorization on every action, separation of duties.
Injection through unvalidated payloads (Tampering)Application tier → Data tierSchema validation at the boundary, parameterized queries, output encoding.
Audit log tampering to hide activity (Repudiation)Application tier → Audit storeAppend-only writes, no application delete path, off-host replication, retention policy.
Secret leakage through code or logs (Information disclosure)Build pipeline → RuntimeManaged secret store injection, secret scanning in CI, redaction in log pipeline.
Resource exhaustion on public endpoints (Denial of service)Internet → EdgeEdge rate limiting, request size caps, autoscaling with circuit breakers.
Prompt injection or over-trust in AI triage outputAnalyst → AI assist serviceAdvisory-only output, no autonomous actions, input treated as untrusted data, mandatory human acknowledgement.

Architecture decision records

Major tradeoffs, made explicit.

  1. ADR-001 · Server-rendered React application with typed routing

    Decision: Use TanStack Start with file-based typed routes rather than a client-only SPA.

    Tradeoff: Adds a server runtime to operate, but delivers SSR performance, per-route metadata, and a natural place to enforce authorization server-side rather than in the browser.

  2. ADR-002 · Role-based access control over per-object ACLs

    Decision: Four coarse roles (Admin, Security Analyst, Auditor, Viewer) with deny-by-default.

    Tradeoff: Less granular than ABAC, but far easier to reason about, review and audit — the dominant requirement for a compliance-facing system. ABAC can be layered later for data residency.

  3. ADR-003 · No custom cryptography

    Decision: Rely exclusively on platform and library primitives: TLS 1.2+ in transit, provider KMS-backed AES-256 at rest, vetted password hashing (Argon2id/bcrypt) in the identity provider.

    Tradeoff: Less control over key handling internals, in exchange for peer-reviewed implementations and removal of an entire class of self-inflicted cryptographic defects.

  4. ADR-004 · Append-only audit trail

    Decision: Audit events are written once with no application-level update or delete path, and replicated to a separate retention store.

    Tradeoff: Storage grows monotonically and corrections require compensating entries, but non-repudiation and evidentiary value are preserved.

  5. ADR-005 · AI assistance is advisory only

    Decision: The triage assistant produces an explainable recommendation; it cannot change incident state.

    Tradeoff: Forgoes automation speed to keep a qualified human accountable for every security decision, which is the defensible posture for regulated environments.

  6. ADR-006 · Synthetic data for the portfolio build

    Decision: Ship deterministic synthetic seed data instead of connecting live telemetry.

    Tradeoff: Not a production integration, but it removes all data-handling risk and keeps demos and tests reproducible.

Deployment approach (target architecture)

Cloud-native, reproducible, least privilege. Today the repository ships CI running lint, tests and build; the remaining items are production design.

  • Build: reproducible CI build with dependency and secret scanning; artifacts are immutable and versioned.
  • Runtime: edge-deployed serverless application tier with autoscaling and no long-lived host credentials.
  • Environments: development, staging and production are fully isolated with separate secrets and data stores.
  • Change control: peer-reviewed pull requests, automated tests as a merge gate, and traceable deployments.
  • Recovery: managed backups with periodic restore rehearsal and documented RPO/RTO targets.