Security Pattern Vocabulary

The API gateway as authentication boundary is the "perimeter authentication" pattern — enforce identity at the entry point so internal services can focus on their business logic rather than security plumbing.

This pattern is part of the broader "API gateway" security pattern set: the gateway also handles rate limiting (preventing DDoS and abuse), TLS termination (so internal traffic can use lighter protocols), and request logging (centralised audit trail). The internal trust model is the key design decision: after the gateway authenticates the caller, do internal services trust the gateway's forwarded identity header (simpler, requires network-level controls), or does each service re-validate a token (stronger, works across trust domains)? Zero-trust architectures lean toward re-validation; traditional perimeter models lean toward internal trust. The architect's choice should be explicit and documented.

Key vocabulary:
• API gateway — an infrastructure component that handles cross-cutting concerns (authentication, rate limiting, routing) for API traffic
• perimeter authentication — validating identity at the network entry point before requests reach internal services
• zero trust — a security model where no internal network location is inherently trusted; every request is authenticated and authorised

Environment variables and config files have a long history of becoming the source of credential leaks — through git commits, debug log output, crash dumps, and container image layers. A secrets manager eliminates these leak vectors.

Common secrets manager implementations: HashiCorp Vault (self-hosted), AWS Secrets Manager, GCP Secret Manager, Azure Key Vault. The "vault pattern" extends this to credential rotation: the secrets manager generates new credentials on a schedule, notifies consuming services, and the old credentials expire. This means even if credentials are exfiltrated, they become invalid quickly. The audit log capability is also crucial for incident response — "which services accessed the production database credentials in the 24 hours before the incident?" is answerable from a secrets manager audit trail, not from environment variables.

Key vocabulary:
• secrets manager — a service that stores, manages access to, and optionally rotates sensitive credentials and configuration
• credential rotation — the automated replacement of credentials on a schedule to limit the window of exposure if they are compromised
• secret sprawl — the anti-pattern where credentials are scattered across config files, environment variables, and source code repositories

Dynamic, short-lived credentials are the gold standard of secrets management — a stolen credential that expires in an hour has dramatically less value to an attacker than one that is valid indefinitely.

HashiCorp Vault's "dynamic secrets" feature is the canonical implementation: instead of creating a database user with a permanent password, Vault creates a new database user on each request with a 1-hour TTL. The service uses the credential for the duration of its work, and Vault revokes it after TTL expiry. This means: (1) credential dumps (stolen database password files) become largely worthless — the credentials are already expired; (2) credential rotation is continuous and automatic, not a quarterly manual task; (3) every credential issuance is audited, showing exactly which service requested access to which database at what time. The pattern works for any external service (AWS IAM, databases, certificates).

Key vocabulary:
• vault pattern — the architecture of using a centralised secrets manager to issue, rotate, and revoke credentials dynamically
• dynamic secrets — short-lived credentials generated on demand for a specific service and automatically revoked after their TTL
• TTL (time to live) — the duration a credential remains valid before automatic expiry and revocation

Defence in depth acknowledges that no single security control is perfect — every control has failure modes, vulnerabilities, or bypass conditions. Layering independent controls ensures that control failures don't produce system failures.

The principle comes from military strategy (multiple defensive lines) but is fundamental to security architecture. In cloud environments, defence in depth is implemented across multiple dimensions: (1) Network: VPC segmentation, security groups, NACLs, WAF; (2) Identity: MFA, short-lived tokens, privileged access management; (3) Data: encryption at rest, encryption in transit, data classification; (4) Application: input validation, output encoding, SAST/DAST; (5) Detection: SIEM, anomaly detection, audit logging. The architecture document should explicitly map threats to their layered controls so gaps are visible and each layer's effectiveness can be evaluated independently.

Key vocabulary:
• defence in depth — the security principle of stacking multiple independent controls so failure of one does not compromise the whole system
• layered security — implementing security controls at multiple architecture levels (network, identity, data, application, monitoring)
• security control — a specific mechanism (firewall rule, encryption, authentication) that reduces a specific security risk

The DMZ concept translates directly to cloud networking — public subnets accessible from the internet form the DMZ; private subnets accessible only from within the VPC form the internal zone; and the controls between them enforce the trust boundary.

In AWS terms: Public Subnet (DMZ) contains load balancers and NAT gateways — accessible from the internet via Security Groups. Private Subnet (Application Layer) contains EC2 instances or ECS services — not directly internet-accessible, only reachable from the public subnet. Data Subnet (Internal) contains RDS databases and ElastiCache — reachable only from the application layer. Each boundary has explicit Security Group rules defining what traffic is permitted. The DMZ principle limits what an attacker who compromises a public-facing component can do — they can reach the application layer but not jump directly to the database.

Key vocabulary:
• DMZ (demilitarized zone) — a network segment between the public internet and the internal trusted network, hosting public-facing services
• public subnet — the cloud equivalent of a DMZ; resources have internet-routable addresses and can receive inbound traffic
• private subnet — resources are not internet-accessible; reachable only from within the VPC or via explicit routing rules