Security layers in infrastructure
(Section: Technology and Infrastructure)
Brief summary
Security is a system of layers: each layer holds back and detects attacks if the previous one failed. For iGaming, this is especially critical: payment flows, PII, partner integrations and peak loads. Below is the defense-in-depth framework, which connects the network, identity, applications, data and operational processes into one managed program.
1) Threat model and fundamentals
Threat Modeling: STRIDE/kill chain for key flows (login, deposit, bid, withdrawal, backfile).
Zero Trust: "do not trust by default," minimum rights, check on every hop.
Least Privilege & Segregation of Duties: Roles are atomic, sensitive operations separated.
Secure by Default: closed ports, deny-all policies, secure defaults.
Auditability: all accesses/changes - in centralized audit.
2) Network and perimeter
Purpose: avoid lateral movement and manage risk isolatively.
Segmentation/zones: Edge (CDN/WAF) → API → services → data (DB/KMS) → admin/backhoe.
VPC/VNet isolation + subnets for public/private services; NAT/egress control (including egress-allowlist to PSP/game providers).
mTLS everywhere (mesh/Ingress), TLS 1. 2 +/HSTS/clear crypto configuration.
WAF/bot management/DDoS on the perimeter; anti-scoring for credential stuffing.
DNS security: split-horizon, DNSSEC, fault tolerance, cache pinning for critical domains.
yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: { name: api-deny-all, namespace: prod }
spec:
podSelector: { matchLabels: { app: api } }
policyTypes: [Ingress, Egress]
ingress: [] # deny-all egress:
- to:
- namespaceSelector: { matchLabels: { name: prod } }
podSelector: { matchLabels: { app: payments } }
ports: [{ protocol: TCP, port: 8080 }]
3) Identity and Access (IAM/PAM)
Purpose: Every access is justified, restricted and transparently audited.
SSO + MFA for people and cars; hardware keys for privileged accounts.
RBAC/ABAC for cloud/K8s/backoff; SCIM - automatic on/off.
JIT access (temporary), break-glass with enhanced audit.
Service Accounts with short-lived tokens (OIDC/JWT), client secrets audit.
Bastion/command mirroring: access to production databases/nodes - only through bastion and write sessions.
4) Secrets and keys
The goal is to eliminate leaks and provide a manageable key lifecycle.
KMS/HSM (wizard key), regular rotation; division of keys into zones/targets.
Vault/Cloud KMS Secrets with dynamic-creds and lease.
- At rest (DB/buckets/snapshots) with envelope encryption.
- In transit (TLS/mTLS).
- Tokenization for payment data; PAN-safe threads and 3-domain security (PCI DSS).
hcl path "kv/prod/payments/" {
capabilities = ["read","list"]
}
path "database/creds/readonly" {
capabilities = ["read"]
}
5) Security of containers and Kubernetes
Purpose: to minimize the attack surface at the runtime level.
Images: minimal basic, no compilers/shells; signatures (cosign) and SBOM.
Admission control (OPA/Gatekeeper/Kyverno): prohibition ': latest', 'privileged', 'hostPath', 'root'.
Runtime-политики: Seccomp/AppArmor, `readOnlyRootFilesystem`, `drop ALL` capabilities + allow-list.
Secrets as volume/env from the secret manager; without bake-in in the image.
PodSecurity (или Pod Security Admission): enforce restricted.
Registers: private, with vulnerability checking (SAST/DAST/CSA).
yaml apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sAllowedRepos metadata: { name: only-internal-registry }
spec:
repos: ["registry.internal.local/"]
6) Supply-chain и CI/CD
Purpose: Trust artefacts from commit to production.
Branch-policies: code-review, protected branches, mandatory checks.
Artifact signature and provenance (SLSA/COSIGN), immutable tags (immutable images).
SBOM (CycloneDX/SPDX), Dependabot/Renovate and pinning dependencies.
CI isolation: ephemeral runners, secrets only in protected jobs, no-plaintext.
CD-gates: quality/SAST/licenses/vendor-policies; promotion only through GitOps.
7) Application security (API/web/mobile)
Objective: to prevent logical and technical attacks.
AuthN/AuthZ: OAuth2/OIDC/JWT; short TTL, key rotations, audience/issuer checks.
Input Security: validation/normalization, injection protection, templates with parameters.
CSP/HSTS/XFO/XSS-Protection, strict CORS, downloadable MIME/size limit.
Rate limit/quotas, idempotency-keys for payments/disbursements.
Ficheflags: fast kill-switch for dangerous features.
nginx add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: https:;" always;
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options DENY;
8) Data, PII and compliance (including PCI)
Objective: minimum collection, minimum access, maximum transparency.
Data-zones/классы: `public/internal/confidential/pii/pci`. Tags in vaults and logs.
PII minimization: pseudonymization of 'player _ id', tokenization of payment details.
Storage policies: hot/cold, WORM for audit; automatic TTL deletion.
Access: only through agreed roles and attributes (region/target).
PCI segmentation: isolated segment, access logs, regular scans/ASVs.
9) Edge layer: CDN/WAF/DDoS/bot protection
The goal: to weed out "garbage" to the platform core.
CDN: geo-blocks, cache strategies, layer-7 protection.
WAF: basic signatures + custom rules for API (JSON schemes, prohibition of non-standard methods).
Bots: behavioral analytics, device fingerprint, rate-limit/captcha for anomalies.
TLS/ALPN: turn off old ciphers, turn on OCSP stapling.
10) Monitoring, telemetry and SecOps
Target: See attacks and react before incident.
Observability: metrics/logs/trails with 'trace _ id' and audit fields.
SIEM/SOAR: event correlation (authentication, IAM changes, WAF triggers, access to secrets).
Detection rules: 401/403 spikes, role-escalation, mass payouts, geo anomalies.
Scanning: SAST/DAST/IAST, CSPM/KSPM, regular pene tests and bug bounties.
Anti-fraud: scoring transactions/behavior, velocity filters, sanctions lists.
11) Reliability, reserve and business continuity
Goal: Survive the crash without data loss and SLAs.
Replication and PITR for databases, frequent snapshots with test recovery.
DR plan: RTO/RPO, region failover scripts, switching tests.
Secrets in DR: independent keys/KMS replica, emergency rotation process.
Formal guides: recovery checklists and game-day exercises.
12) Operational processes and culture
The goal is for security to be "default."
Security by PR: Mandatory security-review for sensitive changes.
Release policies: Night/peak windows closed; pre-flight checklists.
Secure Runbooks - instructions with secure parameters, auditing actions.
Training: phishing simulations, incident training, live tabletop sessions.
13) Checklists (short)
Network and Perimeter
- All ingress per WAF/CDN; DDoS enabled
- mTLS between services; deny-all network policies
- Egress-allowlist to external providers
Identity
- SSO+MFA; JIT and break-glass with audit
- RBAC/ABAC, SCIM-Deactivate Layoffs
- Service Accounts with Short Tokens
K8s/containers
- Image signatures + SBOM; prohibition ': latest'
- Seccomp/AppArmor, read-only FS, drop caps
- Gatekeeper/Kyverno policies and deny lists
Secrets/Keys
- Vault/KMS, rotations, key splitting
- Encryption at rest/in transit
- Tokenization for Payments
CI/CD и supply-chain
- Ephemeral runners; secrets only in protected jobs
- SAST/DAST/licenses; artifact signatures
- GitOps promotion, quality gates
Data/PII/PCI
- Classification of data and tags in repositories
- Retention/WORM policies; access by role
- PCI segment isolation, ASV scans
SecOps
- SIEM/SOAR rules, escalations alerts
- Anti-fraud and velocity filters
- DR Plan, RTO/RPO Tests
14) Examples of "hard" policies
Kyverno: Banning privileged containers
yaml apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: { name: disallow-privileged }
spec:
rules:
- name: no-priv match: { resources: { kinds: ["Pod"] } }
validate:
message: "Privileged containers are not allowed"
pattern:
spec:
containers:
- securityContext:
privileged: "false"
OPA (Rego): ban 'hostNetwork'
rego package kubernetes.admission
violation[msg] {
input.request.kind.kind == "Pod"
input.request.object.spec.hostNetwork == true msg:= "hostNetwork is not allowed"
}
15) Anti-patterns
"Protect the perimeter" without internal mTLS/segmentation → lateral movement.
Secrets in CI env variables, uploading to logs.
Images': latest ', no signatures and SBOM.
Allow-all policy in the cluster; common neimspaces for everything.
Encryption "on paper" without real rotation of keys and recovery tests.
Rely on WAF instead of logic correction and data validation.
No DR exercises/tabular scenarios - the plan is "gathering dust."
16) How to start (90-day plan)
1. Week 1-2: Asset/Data Inventory, Classification, Flow Map
2. Week 3-4: Enable mTLS/deny-all network policies, WAF/DDoS/bot filters.
3. Week 5-6: Vault/KMS, key rotations, payment tokenization.
4. Week 7-8: Gatekeeper/Kyverno, Seccomp/AppArmor, 'privileged '/' hostPath' bans
5. Week 9-10: Image Signatures, SBOM, CI/CD Gates, GitOps Promotion.
6. Week 11-12: SIEM/SOAR rules, escalation alerts, anti-fraud.
7. Week 13: DR Exercise, Runabook Update and Compliance Status (PII/PCI).
Results
Security layers are the architecture of solutions, not a set of checkboxes. Combine network segmentation and Zero Trust, strict IAM, secure containers/K8s, managed secrets and crypto, protected pipelines, edge defense and SecOps observability. Then, even in the event of attacks and crashes, the platform will maintain data integrity, PII/PCI confidentiality, and the availability of key streams - deposits, bids, and withdrawals - at any peak hours.