GH GambleHub

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.

Пример: Kubernetes NetworkPolicy (deny-all + allow-list):
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.

Encryption:
  • 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).
Example: Vault policy (fragment):
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).

Gatekeeper Constraint (example):
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 security headers (fragment):
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.

Contact

Get in Touch

Reach out with any questions or support needs.We are always ready to help!

Start Integration

Email is required. Telegram or WhatsApp — optional.

Your Name optional
Email optional
Subject optional
Message optional
Telegram optional
@
If you include Telegram — we will reply there as well, in addition to Email.
WhatsApp optional
Format: +country code and number (e.g., +380XXXXXXXXX).

By clicking this button, you agree to data processing.