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

Sarah is describing a centralized logging solution – specifically, collecting and analyzing log data. The ELK stack (Elasticsearch, Logstash, Kibana) is commonly used for this purpose. This allows teams to proactively identify security incidents based on event patterns and anomalies, not simply patching vulnerabilities or encrypting data.

David's concern highlights that rate limiting alone doesn't address authentication. API keys introduce a separate attack vector (e.g., unauthorized access via key manipulation) that needs to be considered alongside rate limits. The core issue is not just the volume of requests but also how those requests are authenticated and authorized.

A WAF (Web Application Firewall) acts as a shield between the internet and your application. It inspects HTTP traffic and blocks malicious requests based on rules configured to mitigate common web vulnerabilities – like SQL injection or XSS. This is distinct from database management systems or simply monitoring performance.

While implementing OAuth 2.0 correctly is important, the security of tokens and their rotation are critical best practices. Tokens can be compromised if not properly managed – rotating them reduces the window of opportunity for attackers to exploit stolen credentials. This aligns with a defense-in-depth approach.

The principle of least privilege dictates that each component (service, user) should only have the minimum level of access required to perform its intended function. This limits the blast radius if a service is compromised – attackers can't leverage elevated privileges to move laterally across the system. It's about minimizing potential damage.

A DMZ (Demilitarized Zone) creates a buffer zone between an internal network and the public internet. Services placed in the DMZ are accessible from the outside world but are isolated from the sensitive resources of the internal network – reducing the attack surface. It's a key element of layered security.