Couches de sécurité dans l'infrastructure

(Section : Technologie et infrastructure)

Résumé succinct

La sécurité est un système de couches : chaque couche retient et détecte les attaques si la précédente a donné une défaillance. Pour iGaming, c'est particulièrement critique : flux de paiement, PII, intégrations de partenaires et charges de pointe. Ci-dessous, un cadre defense-in-depth qui relie le réseau, l'identité, les applications, les données et les processus opérationnels en un seul programme géré.

1) Modèle de menace et principes de base

Threat Modeling : STRIDE/kill chain pour les flux clés (login, dépôt, pari, retrait, backoffice).
Zero Trust : « ne pas faire confiance par défaut », droits minimaux, vérification sur chaque hop.
Least Privilège & Segregation of Duties : les rôles sont atomiques, les opérations sensibles sont séparées.
Secure by Default : ports fermés, politiques deny-all, défauts sécurisés.
Auditabilité : tous les accès/modifications sont dans l'audit centralisé.

2) Réseau et périmètre

Objectif : empêcher les déplacements latéraux et gérer le risque de manière isolante.

Segmentation/zones : Edge (CDN/WAF) → API → services → données (DB/KMS) → admin/bacoffis.
VPC/VNet isolation + sous-réseaux pour les services publics/privés ; Contrôle NAT/egress (y compris egress-allowlist aux fournisseurs de jeux/PSP).
mTLS partout (mesh/Ingress), TLS 1. 2 +/HSTS/cryptoconfiguration claire.
WAF/bot-management/DDoS sur le périmètre ; anti-scoring pour le stuffing credential.
Sécurité DNS : split-horizon, DNSSEC, tolérance aux pannes, cache-pinning pour les domaines critiques.

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) Identité et accès (IAM/PAM)

Objectif : chaque accès est justifié, limité et vérifié de manière transparente.

SSO + MFA pour les personnes et les machines ; Clés matérielles pour les comptes privilégiés.
RBAC/ABAC pour nuage/K8s/bacoffice ; SCIM - marche/arrêt automatique.
Accès JIT (temporaire), break-glass avec audit renforcé.
Comptes de service avec jetons à courte durée de vie (OIDC/JWT), audit des secrets clients.
Bastion/mise en miroir des commandes : accès aux bases de données/nœuds - uniquement via bastion et sessions d'enregistrement.

4) Secrets et clés

Objectif : éliminer les fuites et fournir un cycle de vie contrôlé des clés.

KMS/HSM (clé maître), rotation régulière ; séparation des clés par zone/cible.
Stockage de secrets (Vault/Cloud KMS Secrets) avec dynamic-creds et lease.

• At rest (DB/baquets/snapshots) avec encryption envelope.
• In transit (TLS/mTLS).
• Tokenization pour les données de paiement ; Flux PAN-safe et 3-domain security (PCI DSS).

hcl path "kv/prod/payments/" {
capabilities = ["read","list"]
}
path "database/creds/readonly" {
capabilities = ["read"]
}

5) Sécurité des conteneurs et Kubernetes

Objectif : minimiser la surface d'attaque au niveau de la rantime.

Images : minimum de base, pas de compilateurs/shells ; signatures (cosign) et SBOM.
Admission-contrôle (OPA/Gatekeeper/Kyverno) : interdiction « : latest », « privilégié », « hostPath », « root ».
Runtime-политики: Seccomp/AppArmor, `readOnlyRootFilesystem`, `drop ALL` capabilities + allow-list.
Secrets comme volume/bou du gestionnaire de secrets ; sans bake-in dans l'image.
PodSecurity (или Pod Security Admission): enforce restricted.
Registres : privés, avec vérification des vulnérabilités (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

Objectif : faire confiance aux artefacts de la commite à la production.

Politiques de Branch : code-revue, branches protégées, contrôles obligatoires.
Signature d'artefacts et de provenances (SLSA/COSIGN), balises immuables (images immuables).
SBOM (CycloneDX/SPDX), Dependabot/Renovate et Pinning des dépendances.
Isolation CI : runners éphémères, secrets uniquement en jobs protégés, no-platext.
Gates CD : quality/SAST/licences/politiques du vendeur ; promotion uniquement via GitOps.

7) Sécurité des applications (API/Web/mobile)

Objectif : prévenir les attaques logiques et techniques.

AuthN/AuthZ: OAuth2/OIDC/JWT; Court TTL, rotations de clés, contrôle audience/issuer.
Input Security : validation/normalisation, protection contre les injections, modèles avec paramètres.
CSP/HSTS/XFO/XSS-Protection, CORS strict, limitation des MIME/tailles à charger.
Rate limit/quotas, idempotency-keys pour les paiements/décaissements.
Ficheflagi : kill-switch rapide pour les fonctions dangereuses.

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) Données, PII et conformité (y compris PCI)

Objectif : taxe minimale, accès minimal, transparence maximale.

Data-zones/классы: `public/internal/confidential/pii/pci`. Balises dans les coffres et les logs.
Minimisation du PII : pseudonyme de 'player _ id', tokenisation des détails de paiement.
Politiques de stockage : chaud/froid, WORM pour l'audit ; Suppression automatique par TTL.
Accès : uniquement par le biais de rôles et attributs convenus (région/objectif).
Segmentation PCI : segment isolé, journaux d'accès, scans réguliers/ASV.

9) Couche Edge : CDN/WAF/DDoS/bot-protection

Objectif : éliminer les « ordures » jusqu'au noyau de la plate-forme.

CDN : géo-blocs, stratégies de cache, protection contre layer-7.
WAF : signatures de base + règles de personnalisation sous API (schémas JSON, interdiction des méthodes non standard).
Bots : analyse comportementale, device fingerprint, rate-limit/captchi pour les anomalies.
TLS/ALPN : désactiver les anciens codes, activer le stapling OCSP.

10) Surveillance, télémétrie et SecOps

Objectif : voir les attaques et réagir avant l'incident.

Observabilité : métriques/logs/trajets avec 'trace _ id'et champs d'audit.
SIEM/SOAR : corrélation des événements (authentification, modifications IAM, WAF de déclenchement, accès aux secrets).
Règles de détection : surtensions 401/403, role-escalation, paiements de masse, anomalies géo.
Scan : SAST/DAST/IAST, CSPM/KSPM, tests pène réguliers et bug bounty.
Anti-fred : scoring transactionnel/comportement, filtres velocity, listes de sanctions.

11) Fiabilité, réserve et continuité des affaires

Objectif : survivre à une panne sans perte de données et SLA.

Réplication et PITR pour les bases de données, snapshots fréquents avec récupération de test.
Plan DR : RTO/RPO, scénarios d'échec de région, tests de commutation.
Secrets en DR : clés indépendantes/réplique KMS, processus de rotation d'urgence.
Hydes formels : chèques de récupération et exercices game-day.

12) Processus opérationnels et culture

Objectif : que la sécurité soit « par défaut ».

Security by PR : un examen de sécurité obligatoire pour les changements sensibles.
Politiques de libération : fenêtres de nuit/de pointe fermées ; pré-flight checklists.
Secure Runbooks : instructions avec des paramètres sécurisés, audit des actions.
Formation : simulations de phishing, formation sur les incidents, séances de tabletop « en direct ».

13) Listes de contrôle (brèves)

Réseau et périmètre

• Toutes les ingress par WAF/CDN ; DDoS inclus
• mTLS entre les services ; les politiques de réseau deny-all
• Egress-allowlist aux fournisseurs externes

L'identité

• SSO+MFA; JIT et break-glass avec audit
• RBAC/ABAC, SCIM-désactivation des licenciements
• Comptes de service avec des tokens courts

K8s/conteneurs

• Signatures d'images + SBOM ; interdiction ': latest'
• Seccomp/AppArmor, read-only FS, drop caps
• Gatekeeper/Kyverno politiques et listes deny

Secrets/clés

• Vault/KMS, rotations, séparation des clés
• Cryptage at rest/in transit
• Tokenization pour les paiements

CI/CD и supply-chain

• Les runners éphémères ; secrets uniquement dans les jobs protégés
• SAST/DAST/licences ; signatures des artefacts
• GitOps-promotion, gates de qualité

Données/PII/PCI

• Classification des données et balises dans les entrepôts
• Politiques de rétention/WORM ; accès par rôle
• Isolation du segment PCI, numérisation ASV

SecOps

• Règles SIEM/SOAR, alertes sur les escalades
• Filtres anti-frod et velocity
• Plan DR, tests RTO/RPO

14) Exemples de politiques « rigides »

Kyverno : interdiction des conteneurs privilégiés

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) : interdiction du « 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-modèles

« Protégeons le périmètre » sans mouvement latéral → mTLS/segmentation interne.
Secrets dans les variables CI, déchargement dans les logs.
Images ': latest', pas de signatures et SBOM.
Stratégie allow-all dans le cluster ; neimspace commun pour tout.
Chiffrement « sur papier » sans véritable rotation des clés et des tests de récupération.
S'appuyer sur le WAF au lieu de corriger la logique et de valider les données.
Pas d'exercice DR/scénarios de tableau - le plan est « poussiéreux ».

16) Comment commencer (plan de 90 jours)

1. Semaine 1-2 : inventaire des données, classification, carte des flux.
2. Semaine 3-4 : activer les stratégies de réseau mTLS/deny-all, WAF/DDoS/filtres bot.
3. Semaine 5-6 : Vault/KMS, rotation des clés, tokenization des paiements.
4. Semaine 7-8 : Gatekeeper/Kyverno, Seccomp/AppArmor, interdictions 'privilégiées '/' hostPath'.
5. Semaine 9-10 : signatures d'images, SBOM, gates CI/CD, GitOps-Promotion.
6. Semaine 11-12 : Règles SIEM/SOAR, alertes d'escalade, anti-frod.
7. Semaine 13 : Enseignement DR, mise à jour des runabooks et statut de conformité (PII/PCI).

Résultats

Les couches de sécurité sont une architecture de solution, pas un jeu de cases à cocher. Connectez la segmentation réseau et Zero Trust, l'IAM rigoureux, les conteneurs/K8s sécurisés, les secrets gérés et les cryptos, les piplines protégées, la défense edge et l'observabilité SecOps. Alors, même en cas d'attaques et de pannes, la plate-forme conservera l'intégrité des données, la confidentialité PII/PCI et la disponibilité des flux clés - dépôts, paris et conclusions - à toutes les heures de pointe.