Cybersecurity in Practice — How Production Platforms Are Actually Protected
Using a real compliance platform architecture as an example — here is every security layer from the internet edge to the database, and how they work together to form a defence-in-depth strategy.
Defence in Depth — Security Is Not One Lock, It Is Many Layers
No single security measure is enough. Instead, production platforms use multiple overlapping security layers — so that if one layer is bypassed, the next one catches the attacker. Think of it as a medieval castle: moat, outer wall, inner wall, keep, locked rooms, guarded vaults. Each layer makes it harder to reach what matters.
Let us walk through each security layer of a multi-tenant compliance platform — the kind that handles identity verification, sanctions screening, and government reporting for hundreds of firms.
Layer 1: Edge Security — The Outer Wall
CloudFront, WAF, DDoS protection — before traffic even reaches your servers
CloudFront is a Content Delivery Network — it distributes your application across edge locations worldwide. But it also acts as a security layer. AWS Shield (included with CloudFront) automatically protects against DDoS attacks. Shield Advanced (paid) provides additional protections including cost protection if a DDoS attack causes your AWS bill to spike.
WAF sits in front of your application and inspects every HTTP request. It blocks malicious requests before they reach your code.
What WAF blocks:
• SQL injection attempts (malicious database queries hidden in form fields)
• Cross-site scripting (XSS) — injecting JavaScript into web pages
• Known bad IP addresses and bot signatures
• Requests from specific countries (geo-blocking)
• Rate limiting — blocking IPs that send too many requests (potential DDoS or credential stuffing)
• OWASP Top 10 protection rules (pre-built rule set covering the most common web attacks)
Layer 2: Network Security — The Inner Walls
VPC isolation, private subnets, security groups, NACLs
Inside the VPC, traffic is controlled at every boundary. Application servers cannot talk to the internet directly. Databases are completely hidden from the outside world. Every communication path is explicitly allowed — everything else is denied by default.
# Security group rules for a compliance platform
# ALB Security Group (public-facing) Inbound: TCP 443 (HTTPS) from 0.0.0.0/0 ← Only HTTPS from the internet Outbound: TCP 8080 to ECS Security Group ← Only to application containers # ECS Application Security Group (private subnet) Inbound: TCP 8080 from ALB Security Group ← Only from the load balancer Outbound: TCP 5432 to RDS Security Group ← Only to PostgreSQL Outbound: TCP 6379 to Redis Security Group ← Only to Redis cache Outbound: TCP 443 to NAT Gateway ← For external API calls (DVS, DFAT) # RDS Database Security Group (data subnet) Inbound: TCP 5432 from ECS Security Group ← Only from application containers Inbound: NOTHING else ← No internet, no SSH, no direct access Outbound: NONE ← Database never initiates connections
The Key Principle: Default Deny
Security groups deny everything by default. You only open the exact ports, from the exact sources, that are required. If an attacker compromises the load balancer, they still cannot reach the database — because the database security group only accepts connections from the application containers, not from the load balancer.
Layer 3: Authentication and Authorisation
Keycloak, JWT tokens, RBAC, row-level security
Authentication — "Who Are You?"
Proving your identity. In a compliance platform, this is handled by Keycloak (an open-source identity and access management server) or AWS Cognito.
• User submits email + password → Keycloak verifies
• MFA challenge → code from authenticator app
• Keycloak issues a JWT (JSON Web Token) — a signed, tamper-proof token containing the user's identity, roles, and tenant ID
• Every subsequent API request includes this JWT in the Authorization header
• Supports SSO (Single Sign-On) via SAML 2.0 and OpenID Connect
Authorisation — "What Can You Do?"
Once authenticated, what actions are you allowed to perform? This is controlled by Role-Based Access Control (RBAC).
• Admin: Full platform access, user management, configuration
• Compliance Officer: Create/edit cases, submit reports, view screening results
• Reviewer: View cases, add notes, approve/reject — but cannot submit government reports
• Auditor: Read-only access to all cases and audit logs
• Checked at the API gateway AND at the method level in each microservice
Multi-Tenancy Security: Row-Level Security (RLS)
In a multi-tenant platform, Firm A must never see Firm B's data. This is enforced at the database level using PostgreSQL Row-Level Security (RLS). Every query automatically includes a WHERE tenant_id = current_tenant filter. Even if application code has a bug, the database will not return another tenant's data. For enterprise tenants, the platform uses separate database schemas per tenant — complete data isolation at the schema level.
Layer 4: Data Protection — Encryption Everywhere
At rest, in transit, and in the application layer
| Where | What | How |
|---|---|---|
| In Transit | All traffic between services | TLS 1.3 everywhere — browser to ALB, ALB to ECS, ECS to RDS. No plain HTTP. |
| At Rest (Database) | PostgreSQL, MongoDB, OpenSearch | AES-256 encryption via AWS KMS. Keys managed and rotated by AWS. |
| At Rest (Storage) | S3 buckets (documents, uploads) | Server-side encryption (SSE-S3 or SSE-KMS). Bucket policies block public access. |
| At Rest (Cache) | Redis / ElastiCache | Encryption at rest enabled. Auth token required for connections. |
| Secrets | Database passwords, API keys, JWT signing keys | AWS Secrets Manager. Rotated automatically. Never in code or environment variables. |
| Audit Trail | Compliance event log | SHA-256 hash chain — each event is hashed with the previous event, creating a tamper-proof chain (like a simplified blockchain). |
| Backups | Automated RDS snapshots, S3 versioning | Encrypted with the same KMS keys. Cross-region backup for disaster recovery. |
Layer 5: Infrastructure Access Control — AWS IAM
Who can touch the infrastructure itself
This is different from application-level authentication. AWS IAM controls who can manage the infrastructure — create databases, deploy containers, read secrets, modify security groups. This is about protecting the platform from its own engineers.
Least Privilege IAM Policies
- • Developers: Can deploy to staging but NOT to production
- • CI/CD pipeline role: Can deploy to production but cannot modify IAM
- • Database admin: Can manage RDS but cannot read S3 buckets
- • Auditor: Read-only access to CloudTrail and CloudWatch logs
- • No one has root account access. Root credentials are locked with MFA and physical security key.
Service-to-Service Authentication
- • ECS tasks use IAM Task Roles (not hardcoded credentials)
- • Each microservice has its own IAM role with specific permissions
- • CDD service can read from SQS queue but cannot modify RDS configuration
- • Screening service can call DVS API but cannot access S3 document storage
- • AWS CloudTrail logs every API call — who did what, when
Layer 6: Security Monitoring and Threat Detection
Detecting attacks in real time
AWS GuardDuty
Continuously analyses CloudTrail, VPC Flow Logs, and DNS logs for malicious activity. Detects things like: unusual API calls, cryptocurrency mining, compromised credentials, port scanning.
AWS Security Hub
Aggregates security findings from GuardDuty, Inspector, IAM Access Analyzer, and third-party tools into a single dashboard. Provides a security score and prioritised findings.
AWS CloudTrail
Logs every API call made to AWS services. Who created a database? Who changed a security group? Who accessed which secret? The audit trail for infrastructure activity.
AWS Config
Tracks configuration changes to AWS resources over time. Alerts when a resource drifts from its approved configuration (e.g., someone opens a security group too widely).
VPC Flow Logs
Records network traffic metadata (source, destination, port, accept/reject) for every network interface. Essential for forensic investigation after a security incident.
Application-Level Logging
Structured JSON logs with correlation IDs. Failed login attempts, access denied events, unusual query patterns — all logged and shipped to a centralised monitoring system.
Mapping to the Essential Eight
How the layers above satisfy Australia's cybersecurity framework
| Essential Eight Strategy | How This Platform Implements It |
|---|---|
| Application Control | Docker containers run only approved images from ECR. ECS task definitions define exactly what runs. No arbitrary code execution. |
| Patch Applications | CI/CD pipeline rebuilds containers with latest base images weekly. Dependency scanning (Snyk/Trivy) flags vulnerable libraries. Automated PRs for dependency updates. |
| Restrict Macros | Not applicable (web-based SaaS platform, no Microsoft Office macro exposure). File uploads are virus-scanned before processing. |
| User Application Hardening | Angular frontend enforces Content Security Policy (CSP) headers. No inline scripts. Strict CORS configuration. X-Frame-Options to prevent clickjacking. |
| Restrict Admin Privileges | Keycloak RBAC with least-privilege roles. AWS IAM with scoped policies. No shared admin accounts. Admin actions require MFA re-verification. |
| Patch Operating Systems | ECS Fargate manages the underlying OS — AWS patches it. For EC2 instances (if any), AWS Systems Manager automates patching. |
| Multi-Factor Authentication | Keycloak enforces MFA for all users. TOTP (authenticator app) at minimum. FIDO2/WebAuthn for high-security tenants. AWS console requires MFA for all IAM users. |
| Regular Backups | RDS automated daily snapshots (14-day retention). S3 versioning with lifecycle rules. Cross-region replication for disaster recovery. Backup restoration tested monthly. |
References
• ACSC Essential Eight — cyber.gov.au
• ACSC Blueprint for Secure Cloud — Blueprint for Secure Cloud
• NIST Cybersecurity Framework 2.0 — NIST CSF (PDF)
• AWS Reaching Essential Eight Maturity — AWS Prescriptive Guidance
Platform Engineering Series
This article is Part 8 of a 9-part series.
Note: The architecture examples in this series reference LexAML, a real-world AML/CTF compliance platform. The diagrams shown are high-level representations shared for educational purposes.
This content is compiled from various industry sources, official documentation, and practical experience gained across production environments. Your experience may differ based on your organisation, tech stack, and industry context.
We are continuously developing and fine-tuning this content. If something differs from your understanding, or if you have suggestions for improvement, we would genuinely appreciate hearing from you.
Reach out: sumit@getpostlabs.io