46 lines
2.3 KiB
Markdown
46 lines
2.3 KiB
Markdown
# Security boundaries (platform-level)
|
|
|
|
This document describes the baseline security boundaries expected across StellaOps modules. Module dossiers may impose stricter requirements.
|
|
|
|
## Authentication and authorization
|
|
|
|
All externally reachable services are expected to enforce:
|
|
1. Token validation (short-lived, tenant-scoped access tokens).
|
|
2. Sender constraints where configured (DPoP / mTLS).
|
|
3. Scope-based authorization (least privilege).
|
|
4. Tenant isolation: requests and data access are filtered by tenant context.
|
|
|
|
### Hard gates (typical examples)
|
|
|
|
Exact gates are module-specific, but common patterns include:
|
|
- **Authority**: nonce-based sender constraints (DPoP), strict token lifetimes, tenant-scoped issuance, and rate limiting.
|
|
- **Signing/attestation services**: narrow scopes, service identity requirements (often mTLS), and verification of the artifact being signed/attested (for example digest checks) before producing evidence.
|
|
|
|
Authoritative references:
|
|
- `docs/security/scopes-and-roles.md`
|
|
- `docs/modules/authority/architecture.md`
|
|
- `docs/modules/signer/architecture.md`
|
|
- `docs/modules/attestor/architecture.md`
|
|
|
|
## Network segmentation (typical deployment)
|
|
|
|
- **Front door / ingress**: TLS termination, rate limiting, and WAF controls.
|
|
- **Gateway layer**: authenticated routing and tenant resolution; exposes only required service surfaces.
|
|
- **Private service network**: internal service-to-service traffic (least privilege, explicit allowlists).
|
|
- **Stateful infrastructure**: PostgreSQL, Valkey, object storage, message brokers (not directly internet-exposed).
|
|
|
|
Deployment bundles under `deploy/` are the authoritative source of concrete network layouts.
|
|
|
|
## Data protection
|
|
|
|
- TLS for in-transit protection (including internal traffic where required by the profile).
|
|
- Secrets must not be embedded in documentation examples; use a secrets provider (file, Docker secrets, Kubernetes secrets, vault).
|
|
- Evidence artifacts should be written to content-addressed or immutable stores where replay/audit requires it.
|
|
|
|
## Auditability
|
|
|
|
The platform is designed for audits:
|
|
- Deterministic outputs for the same inputs.
|
|
- Evidence artifacts (SBOM slices, advisories/VEX observations, explain traces) linkable to digests.
|
|
- Structured logs and correlation IDs for tracing request paths across services.
|