achreftlili/architect/security-architecture

Security Architecture Skill

Purpose

Embed security into architecture from the start — not as an afterthought. Produce threat-aware designs with clear, implementable security controls.

---

Step 1 — Threat Modeling (STRIDE)

For every system, identify threats across these 6 categories:

| Threat | Question to ask | Example | |--------|----------------|---------| | Spoofing | Can someone pretend to be another user/service? | Weak auth tokens | | Tampering | Can data be modified in transit or at rest? | No request signing | | Repudiation | Can actions be denied? No audit trail? | Missing audit logs | | Information Disclosure | Can sensitive data leak? | Over-permissive API | | Denial of Service | Can the system be overwhelmed? | No rate limiting | | Elevation of Privilege | Can a user access more than allowed? | Broken authorization |

Produce a threat table for the system:

| Threat | Component | Risk (H/M/L) | Mitigation | |--------|-----------|--------------|------------| | Spoofing | API Gateway | High | JWT with short expiry + refresh tokens | | DoS | Public endpoints | Medium | Rate limiting per IP + per user |

---

Step 2 — Authentication Design

Choosing an Auth Strategy

| Scenario | Recommended approach | |----------|---------------------| | User-facing web/mobile app | OAuth2 + OIDC with a provider (Auth0, Cognito, Clerk) | | Service-to-service (internal) | mTLS or signed JWTs with short TTL | | Third-party API access | API keys with scopes | | Machine-to-machine | Client credentials flow (OAuth2) |

Never build your own auth from scratch. Use a proven identity provider.

JWT Standards

• Access token TTL: 15 minutes max
• Refresh token TTL: 7–30 days, rotated on use
• Sign with RS256 or ES256 (asymmetric) — never HS256 in distributed systems
• Validate: signature, expiry, issuer, audience — every request, every service

---

Step 3 — Authorization Model

Choose the right model:

| Model | Use when | |-------|----------| | RBAC (Role-Based) | Clear user roles, relatively static permissions | | ABAC (Attribute-Based) | Fine-grained rules based on resource + user attributes | | ReBAC (Relationship-Based) | Google Docs-style sharing, ownership chains |

Principle of Least Privilege: every user, service, and process gets only what it needs — nothing more.

Define authorization at the resource level, not just the route level.

---

Step 4 — Data Protection

Data at Rest

• Encrypt all sensitive data: AES-256 minimum
• Separate encryption keys from data — use a KMS (AWS KMS, HashiCorp Vault)
• Classify data: Public / Internal / Confidential / Restricted
• Never store: raw passwords (use bcrypt/argon2), unencrypted PII, secrets in code

Data in Transit

• TLS 1.2 minimum, TLS 1.3 preferred — everywhere, including internal services
• Certificate pinning for mobile clients accessing critical APIs
• Sign webhook payloads (HMAC-SHA256)

Secrets Management

• Never in code, config files, or environment variables in plaintext
• Use: AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager
• Rotate secrets automatically; alert on access anomalies

---

Step 5 — Network Security

Internet → WAF → Load Balancer → API Gateway → Services (private subnet)
                                                      ↓
                                               Databases (no public access)

• Services should never be directly internet-accessible
• Use private subnets for databases and internal services
• Apply network segmentation: services can only talk to what they need
• Implement WAF (Web Application Firewall) for public endpoints
• Rate limiting: per-IP and per-authenticated-user, at the gateway level

---

Step 6 — Security Checklist

Application

• [ ] Input validation on all user-supplied data (server-side, always)
• [ ] Parameterized queries / ORM — no string concatenation in SQL
• [ ] Output encoding to prevent XSS
• [ ] CSRF protection on state-changing web endpoints
• [ ] Security headers: CSP, HSTS, X-Frame-Options, X-Content-Type-Options

Infrastructure

• [ ] No publicly exposed databases or internal services
• [ ] Least-privilege IAM roles for all services
• [ ] Dependency scanning in CI/CD (Snyk, Dependabot)
• [ ] Container images scanned before deployment
• [ ] Audit logging: who did what, when, from where — immutable

Compliance Coverage

| Regulation | Key requirements | |-----------|----------------| | GDPR | Data minimization, right to deletion, DPA, breach notification 72h | | SOC2 | Security, availability, confidentiality controls + audit trail | | PCI-DSS | Cardholder data never stored raw; tokenize everything | | HIPAA | Encryption at rest + transit, BAA with vendors, audit logs |

---

Security Anti-Patterns (never do these)

• Rolling your own crypto or auth
• Trusting client-side data without server validation
• Using the same credentials across environments
• Long-lived tokens without rotation
• Secrets in environment variables or .env files in repos
• Security through obscurity as the only defense