GH GambleHub

Políticas de Firewall y ACL

1) Objetivos y principios

Firewall/ACL es el control del plano de datos: quién, dónde, cuándo y en qué protocolo camina. Principios básicos:
  • Privilegio Least: permitir sólo lo necesario (allow explícito, implícito deny).
  • Segmentation: aislamiento de entornos (prod/stage/dev), tenantes, contornos críticos (PCI/KMS/DB).
  • Control Egress: el tráfico saliente está limitado a las listas FQDN/IP y a las listas privadas endpoint.
  • Identidad-aware (L7): las decisiones se toman sobre una entidad autenticada (SPIFFE/OIDC), no sólo sobre IP.
  • Infraestructura como código: reglas como código, revisión/CI/CD, auditoría de cambios.

2) Taxonomía: dónde y qué filtramos

2. 1 Capas y estado

L3/L4 stateless: ACL clásicas (CIDR, protocolo, puerto).
L3/L4 stateful: grupos de seguridad/NSG, rastrean las conexiones.
L7-aware: proxy/WAF/mesh RBAC (métodos, rutas, JWT-claims, SNI).
Inline vs out-of-band: el faerwall en línea enruta el tráfico; out-of-band - análisis/alerta.

2. 2 Contornos

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) Modelos en la nube

AWS

Security Group (SG): stateful на ENI/instance/LB.
ACL de red (NACL): estado en subredes, orden de reglas, registros bidireccionales.
AWS Network Firewall/GWLB: L7 inspección/IDS.
Recomendación: «El SG es el control principal, el NACL es una valla/hoja de deny de grano grande».

Azure

NSG (stateful), ASG (grupos de aplicaciones por etiquetas), Azure FW para L7/IDS, Private Endpoints.
Recomendación: NSG en sabnet + NIC, etiquetas de servicio a través de ASG.

GCP

VPC Firewall Rules (stateful), Hierarquical FW (organizacional/carpeta), Cloud Armor (L7), Private Service Connect.
Recomendación: org-level guardrails + diseño allow.

4) Diseño de reglas: patrones

4. 1 Conjuntos básicos

Deny all egress → permitimos por FQDN/IP a: repositorios por lotes, registros de artefactos, API de terceros (a través de salidas privadas/fijas).
East-West mínimo: los servicios sólo se comunican con las dependencias necesarias.
Acceso Admin: a través de bastión/JIT con MFA, grabación de sesiones.

4. 2 Etiquetas y grupos

Utilice labels/tags en lugar de IP: 'env', 'service', 'tier', 'tenant', 'pci = true'.
Actualización de la directiva cuando se modifica una etiqueta: no se editan manualmente las cuadrículas IP.

4. 3 Ciclo de vida

Propose → Evaluate (staging) → Enforce (prod), con logotipos dry-run/hits.
Obsolescencia: TTL/owner para cada regla, verificación automática no utilizada.

5) Kubernetes y servicio de mesh

5. 1 NetworkPolicy (L3/L4)

El mínimo es «prohibir todo menos lo necesario».

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 + autorización por JWT/claims/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) Controles egresos y perímetros privados

Prefiera PrivateLink/Private Service Connect a PaaS/registros/repositorios.
El resto se realiza a través de NAT/proxy con allowlist FQDN y IP fijas (para allowlist de terceros).
Bloquee la salida directa de pods/VM a Internet; excepciones sólo a través de la puerta de enlace egress.

7) Reglas DNS y SNI conscientes

Split-horizon: las zonas interiores no resuelven en el exterior.
FW/Proxy con soporte FQDN/SNI para HTTPS salientes (SNI allow).
Fije la pinning en los dominios específicos de los proveedores; supervise los cambios en su IP.

8) Registros, auditoría, observabilidad

Habilite los logs flow (VPC/VNet/NSG/NACL), envíelos a SIEM.
Correlacione con las aplicaciones a través de 'trace _ id' en los logs.
Métricas: hit/miss reglas, top-talkers, drop-rates, asimetría de tráfico, «egresos de fugas».
Informes: «reglas no utilizadas», «los permisos más amplios».

9) Gestión como código (IaC) y verificación

Terraform/CloudFormation + políticas modulares por plantilla.
Política como Código (OPA/Gatekeeper/Conftest): prohibición de '0. 0. 0. 0/0 ', requisito' description/owner/ttl', prohibición de mezclar prod/dev.
CI: lente, estatanálisis, simuladores de alcance (reachability analyzer), vista de plan, revisión de mandato.

10) Pruebas de viabilidad y caos

Muestras synthetic de diferentes subredes/AZ/regiones: TCP/443, puertos DB/corredores específicos.
Deny temporal para comprobar las rutas DR: desactivar la dependencia → debe funcionar retries/circuit/fallback.
MTU/MSS: asegúrese de que no haya fragmentación en los perimeters (especialmente IPsec/NAT-T).

11) Rendimiento y confiabilidad

Evite el cuello de botella centralizado: escale horizontalmente inline-FW (GWLB/scale sets).
ECMP/AS-path/BGP para la distribución entre hubs.
Perfiles de inspección TLS: incluir puntos (caro), guardar las huellas de las llaves por separado, cumplir con el cumplimiento.

12) Ejemplos de confecciones (referencias, abreviado)

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) Antipatternas

`0. 0. 0. 0/0 'en ingress/egress «temporalmente» → permanece para siempre.
«Copos de nieve» (correcciones manuales en la consola) sin código ni revisión.
SG/NSG comunes para prod/stage/dev; mezcla de subredes críticas y no críticas.
La falta de control de egresos y el fin de cuentas privado → la fuga de claves/secretos hacia el exterior.
Ignorando el DNS/SNI: se permitió la IP del proveedor - mañana cambió y abrió todo el rango.
No flow logs y runbook's → forensic es imposible.

14) Especificidad de iGaming/finanzas (PCI/regulación)

CDE PCI en un segmento/VRF separado, sin Internet; acceso a PSP/logs - a través de conexión privada/proxy con mTLS y HMAC.
Residencia de datos: PII/Eventos de pago - dentro del país/región; interregional - sólo agregados/anónimos.
KMS/Vault/HSM: subredes/SG individuales, sólo clientes mTLS con certificados cortos.
Auditoría WORM: registros FW/flow en almacenamiento inmutable (Object Lock), retoque ≥ mínimo reglamentario.
Partners (PSP/KYC): FQDN allowlist, egress IP estática, monitoreo de SLA por proveedores.

15) Lista de comprobación prod

  • Modelo de segmentación único (hub-and-spoke, VRF), CIDR sin intersecciones.
  • Deny-by-default на egress; endpoints privados a PaaS/repositorios.
  • Stateful SG/NSG para workload, NACL/route-filters - en subredes/hubs.
  • K8s: NetworkPolicy «deny-all», mesh mTLS + L7 RBAC.
  • Etiquetas/grupos en lugar de IP; owner/TTL/description de cada regla.
  • IaC + Policy-as-Code; CI con simulación de alcanzabilidad; una revisión obligatoria.
  • Flow logs habilitados; dashboards top-talkers, drop-rates; alertas a la «fuga de egresos».
  • Bastion/JIT para acceso administrativo; MFA; registro de sesiones.
  • Runbook 'y: cómo agregar/disparar una regla sobre cómo trabajar en un incidente; revisiones periódicas de las reglas «muertas».
  • Para PCI/finanzas: aislamiento CDE, auditoría WORM, FQDN-allow para PSP/KYC, egresos estáticos IP.

16) TL; DR

Construya la protección por capas: SG/NSG stateful en worcload, NACL/route-filters en subredes, L7 RBAC en mesh/proxy, WAF/edge en el perímetro. El valor predeterminado es deny-by-default, egress sólo a través de puntos controlados o endpoints privados. Describir las reglas como código, verificarlas con políticas y simuladores de alcance, recopilar registros de flujo. Para iGaming/finanzas, agregue segmentación PCI, auditoría WORM y FQDN-allow riguroso a PSP/KYC.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Telegram
@Gamble_GC
Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.