Escribe para buscar notas, herramientas y páginas...

Scorecard de madurez de plataforma: ¿dónde está tu infraestructura?

Diez áreas de control. Un gráfico radar. Tus tres principales gaps. Sin cuenta.

En cada área, mueve el control para reflejar tu estado actual en todos los proveedores cloud activos.

Consistencia de identidad
Cualquier ingeniero puede demostrar qué desplegó y cuándo, en todos los proveedores.
12345
Ausente
Claridad de red
Las rutas de tráfico entre proveedores y hacia internet están documentadas y se aplican.
12345
Ausente
Cobertura de IaC
Toda la infraestructura de producción está bajo control de versiones y es reproducible sin pasos manuales.
12345
Ausente
Observabilidad
Cada servicio de producción tiene un propietario nominado, un destino de logs y una vía de alerta.
12345
Ausente
Visibilidad de costes
Puedes atribuir el gasto a un equipo o proyecto en 24 horas, en cualquier proveedor.
12345
Ausente
Línea base de seguridad
Cada host y servicio cumple una línea base escrita y automatizada antes de llegar a producción.
12345
Ausente
Higiene de secretos
No existen credenciales de larga duración en código, imágenes o ficheros de configuración.
12345
Ausente
Preparación ante incidentes
Tu equipo puede responder a un incidente de producción sin necesitar al ingeniero que lo construyó.
12345
Ausente
Postura de cumplimiento
Puedes producir un rastro de auditoría de eventos de acceso y cambio en 1 día laborable.
12345
Ausente
Disciplina de decommission
Las cargas y el acceso retirados se eliminan en una ventana definida, no se dejan a la deriva.
12345
Ausente

Tu scorecard

Madurez global
Gráfico radar de madurez de plataformaGráfico radar con puntuaciones de madurez en 10 áreas de control. Consulta la tabla de datos más abajo para todos los valores.
Puntuaciones de cada área de control (1 = Ausente, 5 = Optimizado)
Área de controlPuntuaciónNivel de madurez
Consistencia de identidad1Ausente
Claridad de red1Ausente
Cobertura de IaC1Ausente
Observabilidad1Ausente
Visibilidad de costes1Ausente
Línea base de seguridad1Ausente
Higiene de secretos1Ausente
Preparación ante incidentes1Ausente
Postura de cumplimiento1Ausente
Disciplina de decommission1Ausente

Tus 3 prioridades principales

Cómo se ve un buen estado

  • Un IdP central federado a todos los proveedores cloud activos.
  • Cada entrada de acceso humano tiene un propietario nominado y una fecha de revisión.
  • Las service accounts usan OIDC o identidad de workload nativa del proveedor. Sin claves de larga duración.
  • Desprovisionar a un ingeniero que se va lleva menos de 10 minutos.
  • Revisiones de acceso con una cadencia definida (mínimo trimestral para producción).
  • Existe un diagrama de red, está bajo control de versiones y coincide con lo desplegado.
  • El egress de producción pasa por una ruta controlada, no directamente desde compute.
  • El tráfico entre entornos requiere configuración explícita, no red compartida.
  • Se usan private endpoints para servicios gestionados en producción.
  • Las reglas de security groups y firewall tienen propietarios nominados y se revisan ante cada cambio.
  • Cero infraestructura de producción se provisionó fuera de un cambio rastreado.
  • Se pueden levantar entornos nuevos desde código sin preguntar a quien construyó producción.
  • Los ficheros de state son remotos, con locking y control de acceso.
  • Las interfaces de módulos están estandarizadas entre proveedores.
  • CI ejecuta terraform plan y exige aprobación antes del apply.
  • Cada servicio en producción tiene un propietario de on-call nominado.
  • Los logs llegan a un almacén consultable y con retención (no solo a la instancia).
  • Al menos una alerta por servicio despertaría a alguien durante un incidente.
  • Puedes responder "¿este servicio está sano ahora?" sin entrar por SSH al host.
  • La retención de logs cumple tu requisito de cumplimiento (mínimo 90 días).
  • Cada recurso tiene tag de equipo y entorno, impuesto en el provisionamiento.
  • Un informe de costes diario o semanal desglosado por equipo, no solo por cuenta.
  • Las alertas de presupuesto saltan antes del sobrecoste, no después de que llegue la factura.
  • Los recursos idle y sin etiquetar se reportan con un propietario nominado a quien reclamar.
  • El gasto en compromisos y reservas se revisa frente al uso real con una cadencia definida.
  • Existe una línea base escrita: sin SSH de root, cifrado en reposo, sin puertos públicos sin justificación.
  • La línea base se prueba automáticamente en CI, no se revisa a mano antes de un release.
  • CIS benchmark activado en todos los proveedores activos, con hallazgos revisados semanalmente.
  • No existen credenciales de larga duración en repositorios de código, secretos de CI o imágenes.
  • El escaneo de vulnerabilidades corre con una cadencia, no solo en el despliegue inicial.
  • El escaneo de secretos corre en CI y bloquea merges si detecta credenciales.
  • Todos los secretos de aplicación se obtienen en runtime desde un almacén de secretos gestionado.
  • No existen IAM access keys para usuarios humanos. Todo el acceso humano usa identidad federada.
  • Las service accounts usan OIDC o workload identity. Sin claves rotadas a mano.
  • Puedes rotar cualquier secreto sin redesplegar una aplicación ni reconstruir una imagen.
  • Cada servicio de producción tiene un runbook escrito por alguien que no es el ingeniero principal.
  • La rotación de on-call incluye al menos dos personas por servicio.
  • Los runbooks se prueban al menos una vez por trimestre.
  • Las alertas van a una única plataforma de on-call, no a bandejas individuales.
  • Las revisiones post-incidente se escriben en 48 horas y se guardan en un lugar consultable.
  • Los logs de auditoría de management están activados en todos los proveedores y se retienen al menos 1 año.
  • Los logs se almacenan en una cuenta que las cargas de producción no pueden modificar.
  • Puedes responder quién cambió este recurso y cuándo en menos de 30 minutos.
  • En entornos regulados: los logs de auditoría alimentan un SIEM y se revisan con una cadencia.
  • Los controles del marco de cumplimiento están mapeados a controles implementados, no a asunciones.
  • Cada entorno levantado tiene un propietario nominado y una fecha de fin prevista.
  • A los ingenieros dados de baja se les retira todo el acceso cloud en 24 horas.
  • Los recursos no usados se reportan semanalmente.
  • Los entornos antiguos no se conservan por si acaso. Se hace backup de los datos y luego se tiran abajo.
  • El decommission es un trabajo rastreado, no un pensamiento posterior.

Contacto

Envíame un mensaje para iniciar una conversación o escríbeme directamente por email.