Revise ADR-004 to a service-role standard: every service is its own self-contained role with a required file set including SECURITY.md, uniform deploy mechanics, and a deferred shared-engine option (with revisit trigger) recorded in the ADR. Add the per-service security record: - docs/security/service-security-template.md — canonical SECURITY.md template (exposure, checklist status, service-specific hardening, residual risks) - roles/<service>/SECURITY.md is where each service records how it meets the bar; /security-review aggregates roles/*/SECURITY.md and cross-checks against config - service-checklist.md noted as the generic bar the record answers Wire-up: new-role runbook step writes SECURITY.md from the template; ADR-002 governance bullet points at it; CLAUDE.md role conventions require it and mandate one-role-per-service; STATUS records the convention as defined-not-yet-applied. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
53 lines
2.4 KiB
Markdown
53 lines
2.4 KiB
Markdown
# Per-service security record — template
|
|
|
|
Copy this file to `roles/<service>/SECURITY.md` and fill it in when building a
|
|
service role (ADR-004). It is the per-service security **record**: the generic bar
|
|
lives in `docs/security/service-checklist.md` (the questions); this file is *this
|
|
service's answers, plus service-specific measures*. Filling the **Checklist status**
|
|
section is how a service clears the bar (`docs/runbooks/new-role.md`).
|
|
|
|
The planned `/security-review` aggregates every `roles/*/SECURITY.md` and
|
|
cross-checks the claims here against the role's actual config (Compose template,
|
|
declared firewall ports), so keep this honest and current.
|
|
|
|
Delete this preamble in the copy and start from the heading below.
|
|
|
|
---
|
|
|
|
# Security — <service>
|
|
|
|
## Exposure
|
|
|
|
- **Published ports:** <ports> — and which are declared in the `group_vars` firewall vars
|
|
- **Auth surface:** <how it authenticates — e.g. behind reverse proxy + SSO, or app-native login>
|
|
- **Reachability:** <which VLANs / sources can reach it; internal-only vs LAN vs public>
|
|
- **Data sensitivity:** <what data it holds; backup/restore pointer>
|
|
|
|
## Checklist status
|
|
|
|
Each item from `docs/security/service-checklist.md`, with this service's status:
|
|
✅ met · ⚠️ deviation (link to `docs/security/accepted-risks.md`) · n/a.
|
|
|
|
- [ ] Secrets in vault; no default creds; nothing secret in git/images
|
|
- [ ] Non-root; no `privileged`/host-network unless justified; minimal mounts; caps dropped
|
|
- [ ] Ports declared in `group_vars`; behind reverse proxy + auth if exposed; least-privilege inter-service reach
|
|
- [ ] Image pinned (tag/digest), update path known
|
|
- [ ] Logs reviewable; backup/restore covered if stateful
|
|
|
|
## Service-specific hardening
|
|
|
|
Measures beyond the generic bar — the application's own relevant settings. Examples
|
|
of the *kind* of thing that belongs here (replace with this service's actual measures):
|
|
|
|
- App-level brute-force / rate-limiting protection enabled
|
|
- Trusted-domains / allowed-hosts restricted
|
|
- Unused features or remote-access modes disabled
|
|
- Server-side encryption / secure cookie / security-header settings
|
|
|
|
## Residual / accepted risks
|
|
|
|
Anything not done for this service — each with rationale and a revisit trigger.
|
|
Link global trade-offs to `docs/security/accepted-risks.md`; note service-local ones
|
|
here.
|
|
|
|
- <none yet, or: risk · rationale · revisit trigger>
|