Guía Completa de Cloud governance y compliance

A medida que las organizaciones migran cargas de trabajo criticas a la nube, mantener el control sobre los recursos, los costos y el cumplimiento normativo se convierte en un desafio creciente. Cloud governance no es solo un conjunto de políticas escritas en un documento; es la disciplina de establecer controles automatizados, estrategias de organización y mecanismos de auditoria que garantizan que la infraestructura cloud opera dentro de los límites definidos por la empresa y los reguladores.

Que es Cloud Governance

Cloud governance comprende las políticas, procesos y herramientas que una organización utiliza para gestionar y controlar sus recursos en la nube. Abarca cuatro pilares fundamentales:

• Gestión financiera: Control de costos, presupuestos y optimización de gasto
• Gestión de seguridad: Políticas de acceso, cifrado, protección de datos
• Gestión operativa: Estandares de despliegue, naming conventions, tagging
• Gestión de compliance: Cumplimiento de regulaciones y marcos normativos

Sin governance efectivo, los entornos cloud tienden a sufrir de shadow IT, costos descontrolados, configuraciones inseguras y dificultad para pasar auditorias.

AWS Organizations y Service Control Policies (SCPs)

AWS Organizations es la pieza central de governance en AWS. Permite agrupar multiples cuentas en una estructura jerarquica con Organizational Units (OUs), aplicando políticas de control a nivel organizacional.

Estructura Recomendada de OUs

Root
├── Security OU
│   ├── Log Archive Account
│   └── Security Tooling Account
├── Infrastructure OU
│   ├── Networking Account
│   └── Shared Services Account
├── Workloads OU
│   ├── Production OU
│   │   ├── App A Prod Account
│   │   └── App B Prod Account
│   └── Non-Production OU
│       ├── App A Dev Account
│       └── App A Staging Account
└── Sandbox OU
    └── Developer Sandbox Accounts

Service Control Policies

Las SCPs actuan como guardrails a nivel de cuenta, restringiendo las acciones que pueden realizarse incluso si un usuario o rol tiene permisos IAM explicitos. Son políticas de tipo “deny” que establecen los límites maximos de permisos.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDisablingCloudTrail",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyLeavingOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    },
    {
      "Sid": "RestrictRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "sts:*",
        "organizations:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "eu-west-1"
          ]
        }
      }
    }
  ]
}

Esta SCP de ejemplo previene que cualquier cuenta de la organización deshabilite CloudTrail, abandone la organización o cree recursos fuera de las regiones permitidas.

Azure Policy y Governance

En Azure, el equivalente se logra mediante Azure Policy, Management Groups y Azure Blueprints. Azure Policy permite definir reglas que se evaluan contra los recursos en tiempo real.

{
  "properties": {
    "displayName": "Require tag on resource groups",
    "policyType": "Custom",
    "mode": "All",
    "parameters": {
      "tagName": {
        "type": "String",
        "metadata": {
          "description": "Name of the tag required"
        }
      }
    },
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.Resources/subscriptions/resourceGroups"
          },
          {
            "field": "[concat('tags[', parameters('tagName'), ']')]",
            "exists": "false"
          }
        ]
      },
      "then": {
        "effect": "deny"
      }
    }
  }
}

Estrategias de Tagging

Una estrategia de tagging consistente es la base de la governance efectiva. Sin tags adecuados, es imposible atribuir costos, identificar propietarios o aplicar políticas de ciclo de vida.

Tags Obligatorios Recomendados

Tag	Proposito	Ejemplo
Environment	Identificar el entorno	production, staging, dev
Owner	Equipo o persona responsable	platform-team
Project	Proyecto o aplicación	payment-service
CostCenter	Centro de costos para facturación	CC-1234
ManagedBy	Como se gestiona el recurso	terraform, manual
DataClassification	Sensibilidad de los datos	confidential, public

Enforcement de Tags con Terraform

# Modulo que fuerza tags obligatorios
variable "required_tags" {
  type = map(string)
  validation {
    condition = alltrue([
      for tag in ["Environment", "Owner", "Project", "CostCenter"] :
      contains(keys(var.required_tags), tag)
    ])
    error_message = "Missing required tags: Environment, Owner, Project, CostCenter"
  }
}

resource "aws_instance" "example" {
  ami           = var.ami_id
  instance_type = var.instance_type

  tags = merge(var.required_tags, {
    Name      = "${var.project}-${var.environment}-web"
    ManagedBy = "terraform"
  })
}

Control de Costos

El descontrol de costos es una de las consecuencias mas visibles de la falta de governance. Estas son las prácticas esenciales:

AWS Budgets y Alertas

resource "aws_budgets_budget" "monthly" {
  name              = "monthly-budget"
  budget_type       = "COST"
  limit_amount      = "5000"
  limit_unit        = "USD"
  time_unit         = "MONTHLY"
  time_period_start = "2025-01-01_00:00"

  notification {
    comparison_operator       = "GREATER_THAN"
    threshold                 = 80
    threshold_type            = "PERCENTAGE"
    notification_type         = "FORECASTED"
    subscriber_email_addresses = ["[email protected]"]
  }

  notification {
    comparison_operator       = "GREATER_THAN"
    threshold                 = 100
    threshold_type            = "PERCENTAGE"
    notification_type         = "ACTUAL"
    subscriber_email_addresses = ["[email protected]", "[email protected]"]
  }
}

Prácticas de Optimización

• Right-sizing: Revisar periódicamente el uso de instancias y ajustar tipos/tamaños
• Reserved Instances / Savings Plans: Comprometer uso estable con descuentos de hasta 72%
• Políticas de apagado: Apagar recursos de desarrollo fuera del horario laboral
• Limpieza de recursos huerfanos: Eliminar EBS volumes, EIPs y snapshots sin usar

Compliance: SOC 2, ISO 27001, HIPAA

El cumplimiento normativo en la nube requiere controles técnicos y administrativos específicos segun el framework:

SOC 2

SOC 2 se centra en cinco Trust Service Criteria: seguridad, disponibilidad, integridad del procesamiento, confidencialidad y privacidad. En la nube, los controles tipicos incluyen:

• Cifrado en reposo y en transito para todos los datos
• Logging centralizado con retención mínima definida
• Control de acceso basado en roles con revision periodica
• Gestión de incidentes documentada y probada

ISO 27001

ISO 27001 requiere un Sistema de Gestión de Seguridad de la Información (SGSI). La implementación en cloud implica:

• Inventario completo de activos cloud
• Evaluación de riesgos documentada
• Controles del Anexo A mapeados a servicios cloud
• Auditorias internas regulares

HIPAA

Para organizaciones que manejan datos de salud en la nube:

• BAA (Business Associate Agreement) firmado con el proveedor cloud
• Cifrado obligatorio de PHI (Protected Health Information)
• Audit trails completos de acceso a datos de pacientes
• Controles de acceso estrictos con MFA obligatorio

Policy-as-Code: OPA y Sentinel

Policy-as-code permite definir las políticas de governance como código versionado, ejecutable y testeable, eliminando la ambiguedad de las políticas documentadas en texto plano.

Open Policy Agent (OPA)

OPA es un motor de políticas general que evalua consultas contra datos estructurados. En el contexto de cloud governance, se usa frecuentemente con Conftest para validar configuraciones de Terraform y Kubernetes.

# policy/terraform.rego
package terraform.aws

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_s3_bucket"
  not resource.change.after.server_side_encryption_configuration
  msg := sprintf("S3 bucket '%s' must have encryption enabled", [resource.name])
}

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_instance"
  not resource.change.after.tags.Environment
  msg := sprintf("Instance '%s' is missing required 'Environment' tag", [resource.name])
}

# Validar plan de Terraform contra politicas OPA
terraform plan -out=tfplan
terraform show -json tfplan > tfplan.json
conftest test tfplan.json --policy policy/

HashiCorp Sentinel

Sentinel esta integrado directamente con Terraform Cloud/Enterprise y evalua políticas antes de aplicar cambios:

# sentinel/require-tags.sentinel
import "tfplan/v2" as tfplan

required_tags = ["Environment", "Owner", "Project"]

main = rule {
  all tfplan.resource_changes as _, rc {
    rc.type is "aws_instance" implies
    all required_tags as tag {
      rc.change.after.tags contains tag
    }
  }
}

Audit Logging

La capacidad de auditar quien hizo que, cuando y desde donde es un requisito transversal a todos los marcos de compliance.

AWS CloudTrail

CloudTrail registra todas las llamadas a la API de AWS. La configuración mínima de governance incluye:

• Trail multi-región habilitado en la cuenta de log archive
• Logs almacenados en S3 con cifrado KMS y retención de al menos 1 anio
• CloudTrail Lake o Athena para consultas ad-hoc
• Alertas via EventBridge para acciones criticas (cambios en IAM, deshabilitación de logging)

Centralización de Logs

resource "aws_cloudtrail" "organization_trail" {
  name                       = "organization-trail"
  s3_bucket_name             = aws_s3_bucket.cloudtrail_logs.id
  is_organization_trail      = true
  is_multi_region_trail      = true
  enable_log_file_validation = true
  kms_key_id                 = aws_kms_key.cloudtrail.arn

  event_selector {
    read_write_type           = "All"
    include_management_events = true
  }
}

Implementación Gradual de Governance

La implementación de governance no debe intentarse de una sola vez. Una hoja de ruta práctica seria:

1. Fase 1 - Visibilidad: Habilitar CloudTrail, configurar AWS Config, implementar tagging básico
2. Fase 2 - Guardrails: Desplegar SCPs preventivas, configurar budgets y alertas
3. Fase 3 - Automatización: Implementar policy-as-code, automatizar remediation de recursos no conformes
4. Fase 4 - Compliance continuo: Dashboards de compliance, auditorias automatizadas, reportes periodicos

Conclusion

Cloud governance y compliance no son proyectos con fecha de finalización, sino disciplinas que evolucionan junto con la infraestructura y las regulaciones. La combinación de herramientas nativas del proveedor cloud (Organizations, SCPs, AWS Config), políticas como código (OPA, Sentinel) y estrategias organizacionales (tagging, estructura de cuentas, control de costos) permite construir un entorno cloud que es simultaneamente agil y controlado. El éxito radica en la automatización: las políticas que dependen de procesos manuales inevitablemente se degradan con el tiempo.

Recursos

• AWS Well-Architected Framework - Security Pillar
• Azure Cloud Adoption Framework - Governance
• Open Policy Agent Documentation
• HashiCorp Sentinel Documentation
• SOC 2 Compliance Guide for Cloud
• AWS Organizations Best Practices