Security Architecture
Threat Modelling
Identify threats before they become incidents. Use STRIDE per component:
| Threat | Definition | Example | Mitigation |
|---|---|---|---|
| Spoofing | Impersonation | Fake login credentials | MFA, certificate-based auth |
| Tampering | Data modification | Altering DB queries in transit | TLS, integrity checks |
| Repudiation | Denial of action | User claims they didn't place order | Audit logs, digital signatures |
| Info disclosure | Data exposure | API returns sensitive fields | Encryption, access control |
| Denial of service | Overwhelming the system | DDoS attack | Rate limiting, auto-scaling |
| Elevation of privilege | Unauthorised access | User edits another user's data | RBAC, input validation |
How to run a threat modelling session
Walk through each STRIDE category for every component in your architecture diagram. For each threat, decide: Accept, Mitigate, Transfer (e.g., insurance, WAF), or Avoid (redesign). Document the outcome in your ADR.
Zero Trust
Trust no one by default. Verify every request regardless of origin.
| Principle | Implementation |
|---|---|
| Network segmentation | Micro-segmentation limits lateral movement |
| Identity-first | Every request authenticated and authorised |
| Least privilege | Minimum permissions needed for each role |
| Continuous verification | Re-evaluate trust on every request |
Security Checklist
- Encrypt data at rest and in transit (TLS 1.3+, AES-256)
- Hash and salt passwords (bcrypt, Argon2)
- Use API keys or OAuth2 — never share credentials
- Implement rate limiting and input validation
- Keep dependencies updated (automated scanning)
Data Architecture
Data Modelling
| Model | Best For | ACID | Schema | Examples |
|---|---|---|---|---|
| Relational | Structured, complex queries | Yes | Fixed | PostgreSQL, MySQL |
| Document | Flexible JSON documents | Configurable | Dynamic | MongoDB, Couchbase |
| Key-Value | High throughput, simple lookups | Limited | None | Redis, DynamoDB |
| Graph | Relationships, recommendations | Varies | Flexible | Neo4j, Dgraph |
| Time-series | Metrics, logs, events | Limited | Fixed | InfluxDB, TimescaleDB |
Storage Tiers
| Tier | Access Pattern | Medium | Cost |
|---|---|---|---|
| Hot | Frequently accessed | SSD, in-memory cache | High |
| Warm | Less frequent | Standard disk | Medium |
| Cold | Archival | Object storage (S3 Glacier) | Low |
Data Governance
- Classification — tag data by sensitivity (public, internal, confidential, restricted)
- Retention policies — how long to keep data, when to purge
- Audit logging — who accessed what, when
- GDPR / CCPA compliance — right to access, right to deletion, data portability
Compliance is not optional
Data governance requirements vary by industry (finance, healthcare, public sector) and geography (GDPR in EU, CCPA in California, LGPD in Brazil). Determine applicable regulations early — retrofitting data controls is expensive.