Tenancy and Multi-Tenancy
Tenant Isolation Strong tenant binding at resource IDs prevents cross-tenant access. Resource IDs should include tenant identifier. Global incrementing IDs leak information and enable enumeration. UUIDs or tenant-scoped IDs should be used. Per-tenant encryption keys provide cryptographic isolation. Key isolation limits blast radius of key compromise. Per-tenant resource budgets prevent noisy neighbor issues. Budgets ensure fair resource allocation. Tenant context should be validated on every request. Validation prevents tenant confusion attacks. Tenant Data Isolation Database-level tenant isolation provides strongest separation. Separate databases per tenant eliminate cross-tenant queries. Schema-level isolation uses separate schemas per tenant. Schema isolation is more efficient than database isolation. Row-level security (RLS) filters data by tenant. RLS is most efficient but requires careful implementation. Tenant isolation should be tested. Testing validates isolation effectiveness.Identity and Authentication
Workload Identity Workload identity authenticates services to each other. Workload identity eliminates static credentials. Mutual TLS (mTLS) provides cryptographic workload identity. mTLS authenticates both client and server. SPIFFE (Secure Production Identity Framework For Everyone) provides workload identity standard. SPIFFE enables interoperability. Service mesh provides workload identity infrastructure. Mesh handles certificate distribution and rotation. User Identity User identity should be provided by Identity Provider (IDP). Centralized IDP ensures consistent authentication. OIDC (OpenID Connect) and SAML provide federated authentication. Federation enables single sign-on. Identity context should propagate through service calls. Propagation enables authorization at each service. Subject and tenant should be included in traces and logs. Inclusion enables audit and troubleshooting.Service Boundaries and Contracts
Network Boundaries Deny-by-default network policies prevent unauthorized communication. Default-deny requires explicit allows. Service-to-service communication should be authenticated. Authentication prevents impersonation. Network segmentation isolates sensitive services. Segmentation limits lateral movement. API Contracts Schema-validated APIs reject malformed requests. Validation prevents injection and parsing attacks. Versioned contracts enable backward compatibility. Versioning prevents breaking changes. API contracts should be documented and enforced. Documentation enables correct usage. Backpressure and Timeouts Backpressure prevents overload by rejecting requests when at capacity. Backpressure prevents cascading failures. Timeouts prevent indefinite waiting. Timeouts should be set based on expected latency. Circuit breakers prevent calling failed dependencies. Circuit breakers enable graceful degradation. Data Contracts Data classification defines sensitivity levels. Classification drives protection requirements. Data retention policies define lifecycle. Retention policies ensure compliance. Allowed data flows define permitted data movement. Flow restrictions prevent data leakage. Row-level security and column-level security enforce fine-grained access control. Fine-grained control limits exposure. Database views provide abstraction and access control. Views hide sensitive columns.API Gateways and Service Mesh
API Gateway Responsibilities API gateways enforce authentication and authorization at edge. Edge enforcement provides first line of defense. Rate limiting at gateway prevents abuse. Rate limiting should be per-client and global. Schema validation at gateway rejects malformed requests. Validation prevents attacks from reaching services. Request transformation at gateway normalizes inputs. Normalization prevents encoding attacks. Business logic should not be in gateway. Gateway should focus on cross-cutting concerns. Service Mesh Responsibilities Service mesh provides mTLS between services. mTLS encrypts and authenticates service communication. Service mesh enforces authorization policies. Policy enforcement is transparent to services. Service mesh provides observability. Observability includes metrics, traces, and logs. Service mesh should not contain business logic. Mesh is infrastructure, not application. Gateway vs Mesh Gateway handles north-south traffic (external to internal). Gateway is entry point. Mesh handles east-west traffic (service to service). Mesh is internal communication. Both gateway and mesh should enforce security. Defense-in-depth requires multiple layers.State Management and Consistency
Idempotency Idempotency keys identify duplicate requests. Idempotency enables safe retries. Idempotent operations produce same result when executed multiple times. Idempotency prevents duplicate side effects. Idempotency should be designed into APIs. Retrofitting idempotency is difficult. Outbox Pattern Outbox pattern ensures exactly-once message delivery. Outbox uses transactional outbox table. Messages are written to outbox in same transaction as business data. Transaction ensures atomicity. Background process publishes messages from outbox. Publishing is separate from business transaction. Deduplication prevents duplicate message processing. Deduplication uses message IDs. Sagas and Compensations Sagas coordinate distributed transactions. Sagas use compensating transactions for rollback. Saga orchestration uses central coordinator. Orchestration provides visibility. Saga choreography uses events. Choreography is more decoupled. Compensating transactions undo completed steps. Compensation enables rollback. Integrity Checks Critical workflows should include integrity checks. Integrity checks detect tampering. Cryptographic signatures prove authenticity. Signatures prevent repudiation. Checksums detect corruption. Checksums validate data integrity.Supply Chain Security
Artifact Signing All artifacts including containers and binaries should be signed. Signing proves authenticity. Signature verification should occur before deployment. Verification prevents tampered artifacts. Signing keys should be protected. Key compromise enables artifact tampering. Build Provenance SLSA (Supply chain Levels for Software Artifacts) provides provenance framework. SLSA defines build integrity levels. Provenance documents build process. Provenance enables verification. Hermetic builds are reproducible and isolated. Hermetic builds prevent tampering. Build attestations prove build properties. Attestations enable policy enforcement. Dependency Management Software Bill of Materials (SBOM) documents dependencies. SBOM enables vulnerability tracking. Allow-list registries prevent malicious packages. Allow-lists provide supply chain security. Dependency pinning prevents unexpected updates. Pinning ensures reproducibility. Vulnerability scanning identifies vulnerable dependencies. Scanning should be continuous.Security Observability
Distributed Tracing Security context should be included in traces. Context includes user, tenant, and permissions. Trace propagation should preserve security context. Propagation enables end-to-end visibility. Traces should be tamper-evident. Tamper-evidence prevents trace manipulation. Structured Logging Logs should be structured for machine parsing. Structure enables automated analysis. PII (Personally Identifiable Information) should be tagged. Tagging enables PII handling. Sensitive data should be redacted from logs. Redaction prevents data leakage. Log levels should be appropriate. Excessive logging impacts performance. Audit Logging Audit logs should be tamper-evident. Tamper-evidence enables trust. Audit logs should be append-only. Append-only prevents deletion. Audit logs should include who, what, when, where. Complete audit trail enables investigation. Audit logs should be centralized and protected. Centralization enables analysis. Protection prevents tampering.Secure Architecture Principles
Least Privilege Services should have minimum required permissions. Least privilege limits blast radius. Permissions should be granted explicitly. Explicit grants prevent accidental exposure. Defense in Depth Multiple security layers provide redundancy. Redundancy ensures security even if one layer fails. Security should be enforced at multiple points. Multiple enforcement points prevent bypass. Fail Secure Failures should default to secure state. Fail-secure prevents security bypass during failures. Security checks should fail closed. Fail-closed denies access on error. Separation of Concerns Security logic should be separate from business logic. Separation enables security review. Cross-cutting security concerns should be centralized. Centralization ensures consistency.Conclusion
Secure software architecture defines constraints and invariants ensuring security holds under load and change through tenancy isolation, identity propagation, service boundaries, state management, and supply chain security. Security engineers design boundaries and contracts that make insecure behavior difficult or impossible. Success requires strong tenant isolation, workload and user identity, deny-by-default boundaries with schema-validated contracts, API gateways and service mesh for cross-cutting concerns, idempotency and integrity checks, and signed artifacts with provenance. Organizations that invest in secure architecture prevent entire classes of vulnerabilities.References
- OWASP Application Security Verification Standard (ASVS)
- NIST SP 800-204 Security Strategies for Microservices
- CNCF Security TAG Patterns and Best Practices
- SPIFFE and SPIRE Documentation
- SLSA Framework
- Cloud Provider Well-Architected Frameworks (AWS, Azure, GCP)