Seguridad en la nube (Cloud Security)

Por: Artiko
owaspseguridadcloudiacpolicy-as-codecontenedores

Seguridad en la nube (CS)

La sección Cloud Security del checklist cubre 4 puntos que asumen que la infraestructura ya no es un servidor que alguien configura a mano, sino código y automatización.

1. Acceso Just-In-Time (JIT)

En vez de otorgar permisos permanentes (“este ingeniero siempre tiene acceso de administrador a producción”), el acceso JIT concede privilegios elevados solo por el tiempo necesario para una tarea puntual, con aprobación y registro de auditoría.

# AWS STS: credenciales temporales con duración acotada (1 hora)
aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/AccesoTemporalProduccion \
  --role-session-name debug-incidente-482 \
  --duration-seconds 3600

Servicios equivalentes: AWS IAM Identity Center con permission sets temporales, Azure AD Privileged Identity Management (PIM), o herramientas de terceros como Teleport y HashiCorp Boundary.

sequenceDiagram
    participant Ing as Ingeniero
    participant PIM as Sistema JIT
    participant Rec as Recurso en la nube
    Ing->>PIM: Solicita acceso elevado (motivo, duración)
    PIM->>PIM: Aprobación (automática o manual)
    PIM-->>Ing: Credenciales temporales
    Ing->>Rec: Opera con permisos elevados
    Note over PIM,Rec: Acceso expira automáticamente

2. Imágenes de contenedor verificadas, de un registro privado

Las imágenes base deben provenir de un registro privado y confiable, y estar escaneadas en busca de vulnerabilidades conocidas antes de llegar a producción — no descargadas de Docker Hub público sin verificación.

# Escaneo con Trivy antes de publicar la imagen
trivy image --severity HIGH,CRITICAL --exit-code 1 mi-registro.privado/mi-app:1.4.0
# Preferir imágenes distroless o alpine mínimas sobre imágenes "full" innecesarias
FROM gcr.io/distroless/nodejs20-debian12
COPY --from=build /app/dist /app
CMD ["/app/server.js"]

El pipeline de CI/CD debería bloquear el push a producción si el escaneo encuentra vulnerabilidades críticas sin mitigar, y las imágenes deben firmarse (por ejemplo con Cosign/Sigstore) para verificar su procedencia.

3. Infrastructure as Code para aprovisionamiento automatizado

Provisionar infraestructura a mano (clicks en una consola web) es difícil de auditar, de reproducir y de revisar. IaC convierte la infraestructura en código versionado, revisable en Pull Request igual que cualquier otro cambio.

# Terraform: la configuración segura queda declarada, no depende de la memoria de nadie
resource "aws_s3_bucket" "uploads" {
  bucket = "mi-app-uploads-prod"
}

resource "aws_s3_bucket_public_access_block" "uploads" {
  bucket                  = aws_s3_bucket.uploads.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Con IaC, un bucket nuevo hereda automáticamente las mismas restricciones que todos los demás, porque nace del mismo módulo — no de una configuración manual que alguien podría olvidar replicar.

4. Policy as Code

Las políticas de seguridad (qué recursos se pueden crear, con qué configuración, quién puede asumir qué rol) también se codifican y se evalúan automáticamente, en vez de depender de una revisión manual o de la buena voluntad de cada equipo.

# Open Policy Agent (OPA): rechaza buckets S3 públicos en el plan de Terraform
package terraform.s3

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_s3_bucket_acl"
  resource.change.after.acl == "public-read"
  msg := sprintf("El bucket %s no puede tener ACL público", [resource.address])
}

Herramientas típicas: Open Policy Agent / Conftest para validar planes de Terraform en el pipeline, HashiCorp Sentinel, o AWS Service Control Policies (SCPs) para poner límites organizacionales que ningún equipo puede saltarse aunque tenga permisos de IAM amplios.

flowchart LR
    PR[Pull Request con cambio de IaC] --> Plan[terraform plan]
    Plan --> OPA[Policy as Code evalúa el plan]
    OPA -->|cumple políticas| Apply[terraform apply]
    OPA -->|viola política| Block[Bloquea el merge]

Este es el punto donde Secure by Default deja de ser una checklist manual y se convierte en un gate automatizado: nadie puede desplegar una configuración insegura aunque quiera, porque la política la rechaza antes de llegar a producción.