Fortalecimiento del medio ambiente

1) Objetivo y marco

El refuerzo (hardening) del entorno prod es un conjunto sistemático de prácticas que reducen la probabilidad de incidentes y daños de los mismos. Enfoque: API-perímetro, datos de clientes/pagos, CI/CD, plataforma de contenedores, accesos, control de cambios, observabilidad y cumplimiento regulatorio.

Principios clave:

Security by Design & Default: privilegios mínimos necesarios, impagos seguros.
Fideicomiso Cero: no confiar ni en la red ni en las identidades sin verificación.
Defence-in-Depth: protección en niveles (red → servicio → aplicación → datos).
Inmutabilidad de los artefactos: «build once, run many».
Huellas E2E y auditabilidad: quién, cuándo, qué ha cambiado y por qué.

2) Modelo de amenazas y activos críticos

Activos: cuentas y tokens de pago, datos de PII/pasaporte, balanzas de juego/RNG, claves de encriptación, secretos de integración, pipelines de debloy, imágenes de contenedores.
Vectores: vulnerabilidades de dependencia, fugas de tokens, configuración de nube/K8s incorrecta, SSRF/RCE en API, cadena de suministro (compromiso CI/CD/repositorio), acceso de información privilegiada, tráfico DDoS/bot.
Escenarios: retiro de fondos por entidad no autorizada, sustitución de coeficientes/balances, drenaje de bases, captura de paipline, edición manual en venta.

3) Arquitectura de red y aislamiento

Segmentación: VPC/VNet individuales para prod/stage/dev. Dentro de prod, subredes para edge (LB/WAF), API, DB, análisis, servicios administrativos.
Política «explícitamente permitida»: deny-all entre subredes, sólo abrimos los puertos/direcciones deseados.
mTLS entre servicios, la rotación de certificados está automatizada.

Ejemplo K8s NetworkPolicy (deny-all + allow-list):

yaml apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata:
name: default-deny namespace: prod spec:
podSelector: {}
policyTypes: ["Ingress","Egress"]
apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata:
name: allow-api-to-db namespace: prod spec:
podSelector:
matchLabels: {app: db}
ingress:
- from:
- podSelector: {matchLabels: {app: api}}
ports: [{protocol: TCP, port: 5432}]

4) Identidades y acceso (PAM/JIT)

SSO + MFA para todos los accesos de personas.
RBAC&ABAC: roles a nivel de nube, clúster, espacio de nombres y aplicaciones.
PAM: jump/bastion, acceso JIT (tiempo limitado), grabación de sesión.
Break-glass: cuentas selladas con clave de hardware, emisión registrable.
Escáneres regulares de «quién tiene acceso a qué», rugiendo una vez cada 30 días.

5) Secretos y llaves

Almacén de secretos (Vault/KMS/Secrets Manager), eliminamos los secretos de Git.
KMS/HSM para claves master; KEK/DEK, rotación automática.
Políticas TTL: tokens de vida corta (OIDC/JWT), cuentas temporales para CI.
Cifrado: en reposo (AES-256/GCM), en vuelo (TLS 1. 2 +/mTLS), columnas PII/datos de tarjetas - clave separada.

6) Supply chain и CI/CD hardening

Aislamiento de runner's para prod (self-hosted en una red privada).
Firma de artefactos (Sigstore/cosign), verificación de la firma en el deploe.
SBOM (CycloneDX/SPDX), SCA/VA en cada commit y antes de su lanzamiento.
Políticas «no tag latest», sólo etiquetas inmutables.
Principio de 4 ojos: code review obligatorio y change approval.
Infrastructure as Code: Terraform/Helm с policy-as-code (OPA/Conftest).

Ejemplo de OPA-regle (prohibición de public S3/Storage):

rego package iac. guardrails

deny[msg] {
input. resource. type == "storage_bucket"
input. resource. acl == "public-read"
msg:= sprintf("Public bucket forbidden: %s", [input. resource. name])
}

7) Contenedores y Kubernetes

Base de imagen mínima (distroless), rootless, read-only FS, drop CAPs.
Control de administración: prohibición privilegiada, hostPath, hostNetwork.
Pod Security Standards: baseline/restricted для prod ns.
ImagePolicyWebhook: omitir sólo imágenes firmadas.
Políticas de Runtime (Falco/eBPF): alertas a syscalls anómalos.
Quota/LimitRange: proteger los nodos de los «vecinos ruidosos».

8) API-perímetro: WAF, Rate Limits, Bot/DDoS

API Gateway: autenticación (OAuth2/JWT/HMAC), normalización, mTLS, validación schema.
WAF: reglas básicas + casta bajo métricas de negocio.
Rate limits: global/por IP/por clave de cliente; «tokens» y burst.

Ejemplo de NGINX-rate-limit:

nginx limit_req_zone $binary_remote_addr zone=api:20m rate=10r/s;

server {
location /api/ {
limit_req zone=api burst=30 nodelay;
proxy_pass http://api_backend;
}
}

Bot management: señales de comportamiento, device fingerprint, challenge.
DDoS: CDN/edge-scrubbing, autoscaling, «dark-launch» para fiches calientes.

9) Políticas de configuración e impagos seguros

Características flags/kill-switches para desactivar rápidamente las funciones de riesgo.
Config-as-Code con validación de circuitos, canario/azul-verde para confecciones.
Time-to-Revoke como KPI cuando se retiran las configuraciones/claves.

10) Datos y privacidad

Clasificación: PII/finanzas/registros operativos/telemetría.
Minimización: almacenar sólo lo que desee, anonimización/seudonimización.
Backups: cuenta/proyecto independiente, encriptación, ensayos regulares de DR.
Reglas de salida: same-method, velocity-limites, risk-scoring, 4-eyes.
Legal Hold/Retén: gráficos de almacenamiento, eliminación administrada.

11) Observabilidad, alertas y respuesta

Tríada: registros (sin secretos), métricas (SLO/SLA), tracks (W3C).
Señales de seguridad: entradas exitosas/fallidas, escaladas de privilegios, cambios de secretos, desviaciones de tráfico.
SIEM + SOAR: correlación y playbucks semiautomáticos.
Incidentals playbooks: DDoS, filtración de secretos, compromiso runner 'a, lanzamiento de rollback, «congelación» de pagos.
MTTD/MTTR como métricas básicas de la operatividad.

12) Gestión de cambios y versiones

Change Advisory Board (ligero) para cambios de alto riesgo.
Pre-prod gates: pruebas, seguridad, perfume, migraciones DB.
Canary/Blue-Green/Shadow deployes, rollback automático por SLO.
Prohibición de revisiones directas en la venta: cambios sólo a través de la línea de pago.

13) Vulnerabilidades y parches

Política de parches: crítica - ASAP; alta - dentro de los días N.
Volver a escanear después de la ficción; Pesaje CVE por exposición.
Chaos-security: ejercicios periódicos de «table-top» y ataques de «equipo rojo» en ventanas resaltadas.

14) Cumplimiento y auditoría

Marcos de control: PCI DSS (pagos), SOC 2, ISO 27001.
Artefactos: matriz de control, registros de cambios, informes de escaneo, resultados de pruebas DR, revisión de acceso.
Preparación continua: «evidence as code» - los artefactos se recogen automáticamente de las líneas de paipeline y los sistemas.

15) Economía y confiabilidad

Guardrails por valor: cuotas, presupuestos, alertas, apagado automático de recursos no utilizados.
Capacidad: planificación orientada a SLO, pruebas de carga, «días de caos».
Prioridades de recuperación: RTO/RPO por servicio, mapa de dependencia.

16) Anti-patrones

Secretos v.env en Git, "administración" común para todos, "SSH directo en prod', fixes manuales en contenedores, etiquetas" latest ", un clúster común para todo, baquetas públicas, CI-runner con Internet outbound en la red prod, registros con PII, falta kill-switch para fiches" calientes ".

17) Lista de comprobación de inicio rápido (90 días)

0-30 días

Habilitar MFA/SSO, rugido de accesos; directivas de red deny-all; Secrets Manager/KMS; prohibición privilegiada en K8s; incluir WAF/Rate-limit; alertas de entrada/escalada básicas.

31-60 días

Firma de imagen + ImagePolicy; SBOM + SCA в CI; canary/rollback; Correlación SIEM; playbucks IR; JIT/PAM; copia de seguridad con la prueba DR.

61-90 días

OPA-guardrails para IaC; eBPF/Falco; Gestión de bots; periodic access-review; Ejercicio chaos-security; auditoría de las confecciones y del costo-guardrails.

18) Métricas de madurez

Accesos:% de cuentas con MFA, edad promedio de los tokens, tiempo de revocación.
Pipeline:% de imágenes firmadas/SBOM, cobertura SAST/DAST.
Plataforma: cuota de pod's con FS read-only, PSS-restricted, cobertura de NetworkPolicy.
Perímetro:% API con reglas rate-limit/WAF, respuesta promedio a DDoS.
IR: MTTD/MTTR, frecuencia «table-top», porcentaje de ensayos DR exitosos.
Cumplimiento: porcentaje de controles con pruebas automáticas.

19) Aplicación: plantillas de políticas

AWS SCP (prohibición de baquetas públicas)

json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "DenyPublicS3",
"Effect": "Deny",
"Action": ["s3:PutBucketAcl","s3:PutBucketPolicy"],
"Resource": "",
"Condition": {"StringEquals": {"s3:x-amz-acl": "public-read"}}
}]
}

Kubernetes PodSecurity (namespace-label)

yaml apiVersion: v1 kind: Namespace metadata:
name: prod labels:
pod-security. kubernetes. io/enforce: restricted pod-security. kubernetes. io/audit: restricted

OPA para contenedores (prohibición privilegiada)

rego package k8s. admission deny[msg] {
input. request. object. spec. containers[_].securityContext. privileged == true msg:= "Privileged containers are not allowed in prod"
}

20) Conclusión

El fortalecimiento del entorno prod es un proceso continuo. Priorizar las medidas con la máxima reducción del riesgo: accesos y secretos, aislamiento en red, firma de artefactos y control de paipline, protección de la API perimetral, observabilidad y disciplina de cambio. El resto se incrementa iterativamente, fijando las métricas de madurez y la economía de control.

Fortalecimiento del medio ambiente