GH GambleHub

Politique Firewall et ACL

1) Objectifs et principes

Firewall/ACL est le contrôle du plan de données : qui, où, quand et par quel protocole. Principes de base :
  • Least privilège : n'autoriser que le nécessaire (allow explicite, impulsicit deny).
  • Segmentation : isolation des environnements (prod/stage/dev), tenants, contours critiques (PCI/KMS/DB).
  • Contrôle egress : le trafic sortant est limité aux listes FQDN/IP et aux endpoint'ami privés.
  • Identity-aware (L7) : les décisions sont prises sur une entité authentifiée (SPIFFE/OIDC) et pas seulement sur IP.
  • Infrastructure as Code : règles en tant que code, révision/CI/CD, audit des changements.

2) Taxonomie : où et ce que nous filtrons

2. 1 Couches et état

L3/L4 stateless : ACL classique (CIDR, protocole, port).
L3/L4 stateful : security groups/NSG, surveillent les connexions.
L7-aware : proxy/WAF/mesh RBAC (méthodes, voies, JWT-clims, SNI).
Inline vs out-of-band : inline-faervol route le trafic ; out-of-band - analyse/alerte.

2. 2 Contours

Perimeter: edge/WAF/Anti-DDoS.
Core: transit hub / меж-VPC/VNet.
Workload: SG/NSG на VM/ENI/POD.
App-level: Envoy/Istio/NGINX policy, service-to-service mTLS.

3) Modèles cloud

AWS

Security Group (SG): stateful на ENI/instance/LB.
ACL réseau (NACL) : stateless sur le sous-réseau, ordre des règles, entrées bidirectionnelles.
AWS Network Firewall/GWLB : inspection L7/IDS.
Recommandation : « SG - contrôle principal, NACL - clôture à gros grains/feuille de deny ».

Azure

NSG (stateful), ASG (groupes d'applications par tag), Azure FW pour les L7/IDS, Private Endpoints.
Recommandation : NSG sur Sabnet + NIC, balises de service via ASG.

GCP

VPC Firewall Rules (stateful), Hierarchical FW (organisationnel/papillon), Cloud Armor (L7), Private Service Connect.
Recommandation : org-level guardrails + projet allow.

4) Conception des règles : modèles

4. 1 Kits de base

Deny all egress → est autorisé par FQDN/IP à : référentiels par lots, registres d'artefact, API tierces (via des sorties privées/fixes).
L'Est-Ouest est un minimum : les services ne communiquent qu'avec les dépendances nécessaires.
Accès Admin : via bastion/JIT avec MFA, enregistrement des sessions.

4. 2 Tags et groupes

Utilisez labels/tags au lieu d'IP : « bou », « service », « tier », « tenant », « pci = true ».
Mise à jour de la stratégie lors de la modification de la balise - sans modification manuelle des grilles IP.

4. 3 Cycle de vie

Propose → Evaluate (staging) → Enforce (prod), avec dry-run/logs de succès.
Obsolescence : TTL/owner pour chaque règle, contrôle automatique des non utilisés.

5) Kubernetes et service-mesh

5. 1 NetworkPolicy (L3/L4)

Le minimum est « interdire tout sauf le bon ».

yaml apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata: { name: deny-all, namespace: core }
spec:
podSelector: {}
policyTypes: ["Ingress","Egress"]
kind: NetworkPolicy metadata: { name: api-egress }
spec:
podSelector: { matchLabels: { app: api } }
egress:
- to:
- namespaceSelector: { matchLabels: { ns: db } }
ports: [{ protocol: TCP, port: 5432 }]
- to:
- ipBlock: { cidr: 10. 100. 0. 0/16 } # Private endpoints ports: [{ protocol: TCP, port: 443 }]

5. 2 L7 RBAC в mesh (Istio/Envoy)

mTLS + autorisation par JWT/clims/scopes/paths.

yaml apiVersion: security. istio. io/v1 kind: AuthorizationPolicy metadata: { name: api-rbac }
spec:
selector: { matchLabels: { app: api } }
rules:
- from:
- source:
principals: ["spiffe://svc. payments"]
to:
- operation: { methods: ["POST"], paths: ["/v1/payouts"] }
when:
- key: request. headers[x-tenant]
values: ["eu-1","eu-2"]

6) Contrôle egress et périmètre privé

Préférez PrivateLink/Private Service Connect à PaaS/registres/référentiels.
Le reste egress via NAT/proxy avec allowlist FQDN et IP fixes (pour les allowlist tiers).
Bloquer la sortie directe des pods/VM sur Internet ; exceptions uniquement via la passerelle egress.

7) Règles DNS et SNI conscientes

Split-horizon : les zones intérieures ne résonnent pas de l'extérieur.
FW/Proxy avec prise en charge FQDN/SNI pour les HTTPS sortants (SNI allow).
Fixez le pinning sur des domaines fournisseurs spécifiques ; surveiller les modifications de leur PI.

8) Logs, audit, observabilité

Activer flow logs (VPC/VNet/NSG/NACL), envoyer au SIEM.
Corréler avec les applications via 'trace _ id'dans les logs.
Métriques : règles hit/miss, top-talkers, drop-rates, asymétrie du trafic, « fuites egress ».
Rapports : « règles inutilisées », « autorisations les plus larges ».

9) Gestion en tant que code (IaC) et contrôles

Terraform/CloudFormation + politiques modulaires par modèles.
Policy as Code (OPA/Gatekeeper/Conftest) : interdiction de "0. 0. 0. 0/0 ', exigence' description/owner/ttl ', interdiction du mélange prod/dev.
CI : lint, statanalyse, simulateurs de réalisabilité (analyseur de réachabilite), plan-visualisation, examen par les pairs.

10) Test de faisabilité et chaos

Échantillons synthétiques provenant de différents sous-réseaux/AZ/régions : TCP/443, ports spécifiques des OBD/courtiers.
Deny temporaire pour vérifier les chemins DR : Désactiver la dépendance des → devrait déclencher retries/circuit/fallback.
MTU/MSS : assurez-vous qu'il n'y a pas de fragmentation sur les périmeters (en particulier IPsec/NAT-T).

11) Performance et fiabilité

Évitez le goulot d'étranglement centralisé : mettez à l'échelle horizontalement inline-FW (GWLB/scale sets).
ECMP/AS-path/BGP pour la distribution entre les pôles.
Profils d'inspection TLS : inclure ponctuellement (cher), garder les empreintes clés séparées, respecter la conformité.

12) Exemples de configues (références, raccourcis)

12. 1 AWS SG: API → Postgres + S3 PrivateLink

hcl resource "aws_security_group" "api" {
name    = "sg-api"
description = "Ingress from ALB, egress to DB and PrivateLink"
vpc_id   = var. vpc_id

ingress { from_port=8080 to_port=8080 protocol="tcp" security_groups=[aws_security_group. alb. id] }
egress { from_port=5432 to_port=5432 protocol="tcp" security_groups=[aws_security_group. db. id] }
egress { from_port=443 to_port=443 protocol="tcp" prefix_list_ids=[aws_vpc_endpoint. s3. prefix_list_id] }
tags = { owner="team-api", env=var. env, ttl="2026-01-01" }
}

12. 2 Azure NSG: deny-by-default + allow bastion

bash az network nsg rule create -g rg -n allow-bastion --nsg-name nsg-app \
--priority 100 --direction Inbound --access Allow --protocol Tcp \
--source-address-prefixes 10. 0. 0. 10 --source-port-ranges "" \
--destination-port-ranges 22 --destination-address-prefixes 10. 1. 0. 0/16

12. 3 GCP hierarchical firewall: org-guardrail

yaml direction: INGRESS priority: 1000 action: deny enableLogging: true match:
layer4Configs: [{ ipProtocol: "all" }]
srcIpRanges: ["0. 0. 0. 0/0"]
targetResources: ["organizations/123456"]

12. 4 Envoy RBAC (L7 allow)

yaml
- name: envoy. filters. http. rbac typed_config:
rules:
action: ALLOW policies:
payments-post:
permissions: [{ url_path: { path: "/v1/payouts", ignore_case: true } }]
principals: [{ authenticated: { principal_name: { exact: "spiffe://svc. payments" } } }]

13) Anti-modèles

`0. 0. 0. 0/0 'dans ingress/egress « temporairement » → reste pour toujours.
Flocons de neige (modifications manuelles dans la console) sans code ni révision.
Général SG/NSG pour prod/stage/dev ; mélange de sous-réseaux critiques et non critiques.
L'absence de contrôle egress et d'endpoint privé → les fuites de clés/secrets vers l'extérieur.
Ignorer DNS/SNI : permis l'IP du fournisseur - demain il a changé et ouvert toute la gamme.
Il n'y a pas de flow logs et de runbook → forenser impossible.

14) Spécificités de l'iGaming/Finance (PCI/réglementation)

CDE PCI dans un segment VRF/séparé, pas d'Internet ; Accès aux PSP/logs - via connectivité privée/proxy avec mTLS et HMAC.
Data Residency : PII/événements de paiement - dans le pays/région ; interrégionale - seulement les agrégats/anonymes.
KMS/Vault/HSM : sous-réseaux individuels/SG, clients mTLS uniquement avec certificats courts.
Audit WORM : logs FW/flow dans un stockage immuable (Object Lock), rétentions ≥ minimum réglementaire.
Partenaires (PSP/KYC) : FQDN allowlist, egress IP statique, surveillance des SLA par les fournisseurs.

15) Chèque-liste prod-prêt

  • Modèle unique de segmentation (hub-and-spoke, VRF), CIDR sans intersections.
  • Deny-by-default на egress; endpoints privés vers PaaS/stockage.
  • SG/NSG stateful pour workload, NACL/route-filters - sur le sous-réseau/hubs.
  • K8s: NetworkPolicy «deny-all», mesh mTLS + L7 RBAC.
  • Tags/groupes au lieu de IP ; owner/TTL/description à chaque règle.
  • IaC + Policy-as-Code; IC avec simulation de faisabilité ; examen peer obligatoire.
  • Flow logs inclus ; dashboards top-talkers, drop-rates ; alerte sur la « fuite egress ».
  • Bastion/JIT pour l'accès admin ; MFA; le journal des sessions.
  • Runbook "et : comment ajouter/retirer la règle, comment travailler en cas d'incident ; révisions régulières des règles « mortes ».
  • Pour PCI/Finance : isolation CDE, audit WORM, FQDN-allow pour PSP/KYC, egress IP statique.

16) TL; DR

Construisez la protection par couches : SG/NSG stateful sur workloades, NACL/route-filters sur sous-réseaux, L7 RBAC dans mesh/proxy, WAF/edge sur périmètre. La valeur par défaut est deny-by-default, egress uniquement via des points contrôlés ou des endpoints privés. Décrivez les règles comme un code, vérifiez-les avec des stratégies et des simulateurs d'accessibilité, collectez des flow-logs. Pour iGaming/Finance, ajoutez une segmentation PCI, un audit WORM et un FQDN-allow rigoureux à votre PSP/KYC.

Contact

Prendre contact

Contactez-nous pour toute question ou demande d’assistance.Nous sommes toujours prêts à vous aider !

Telegram
@Gamble_GC
Commencer l’intégration

L’Email est obligatoire. Telegram ou WhatsApp — optionnels.

Votre nom optionnel
Email optionnel
Objet optionnel
Message optionnel
Telegram optionnel
@
Si vous indiquez Telegram — nous vous répondrons aussi là-bas.
WhatsApp optionnel
Format : +code pays et numéro (ex. +33XXXXXXXXX).

En cliquant sur ce bouton, vous acceptez le traitement de vos données.