Recursos · Checklist

Plataforma cloud de startup: 25 puntos que miramos

Es la lista con la que empezamos cualquier revisión. La publicamos para que puedas pasarla tú mismo en una tarde. Está pensada para equipos B2B de producto en sus primeros años en producción: una startup cuyo equipo crece más rápido que su plataforma. No es una auditoría de seguridad ni cubre todo; cubre lo que más veces falla en esa fase.

Los 25 puntos que miramos llevan por qué importan, la señal de alarma y dónde mirarlo en AWS, Azure y Google Cloud.

Haz la autoevaluación (sin dejar datos)

A

Accesos y cuentas

  1. Quién es el dueño de la cuenta y cómo se protege.

    Por qué importa
    Si pierdes la cuenta raíz o el administrador global, pierdes la empresa técnica.
    Señal de alarma
    La cuenta raíz tiene claves de acceso o se usa a diario; hay un único administrador; el email de la cuenta es de una persona.
    Dónde mirarlo
    AWS: usuario raíz con MFA, sin access keys y con email de rol. Azure/Entra: al menos dos Global Admin con MFA y una cuenta de emergencia (break-glass). GCP: Organization Admin y Billing Admin asignados a grupos, no a una persona.

  2. Acceso humano por SSO y baja de personas.

    Por qué importa
    Cada ex empleado con acceso es un riesgo y un coste.
    Señal de alarma
    Usuarios locales con contraseña; nadie sabe quién tiene qué; la baja de una persona no incluye la nube.
    Dónde mirarlo
    AWS IAM Identity Center; Entra ID con acceso condicional; Cloud Identity o Google Workspace con grupos en GCP. Revisa el último inicio de sesión de cada usuario.

  3. Credenciales de larga duración y secretos.

    Por qué importa
    Una clave filtrada en un repositorio es uno de los incidentes más habituales.
    Señal de alarma
    Access keys de IAM de más de 90 días, claves JSON de service accounts de GCP, secretos en variables de entorno o en el repositorio.
    Dónde mirarlo
    AWS credential report y Secrets Manager / Parameter Store; Azure Key Vault y Managed Identity; GCP Secret Manager y Workload Identity en lugar de claves JSON. Busca secretos en el histórico del repositorio con una herramienta de escaneo.

  4. Mínimo privilegio.

    Por qué importa
    Los permisos de «todo» convierten cualquier fallo en un desastre.
    Señal de alarma
    Políticas con Action: * y Resource: *, Owner/Contributor de suscripción para desarrolladores, roles básicos Owner/Editor de GCP en uso.
    Dónde mirarlo
    AWS IAM Access Analyzer; Azure RBAC y Defender for Cloud/Advisor; GCP IAM Recommender.

  5. Separación de producción y pruebas.

    Por qué importa
    Evita que un script mal lanzado toque el entorno equivocado.
    Señal de alarma
    Producción y staging en la misma cuenta, suscripción o proyecto y con los mismos permisos.
    Dónde mirarlo
    AWS: cuentas separadas bajo Organizations. Azure: suscripciones separadas bajo management groups. GCP: proyectos separados bajo carpetas.

B

Entrega y despliegue

  1. Se despliega desde un pipeline, no desde un portátil.

    Por qué importa
    Es lo que evita el «solo yo sé desplegar».
    Señal de alarma
    Despliegues manuales; pasos que solo conoce una persona; nadie sabe qué versión corre en producción.
    Dónde mirarlo
    Repositorio y herramienta de CI/CD (GitHub Actions, GitLab CI, Azure DevOps, Cloud Build, CodePipeline). Pregunta: ¿puede desplegar alguien que no sea el autor, en menos de 30 minutos y siguiendo un documento?

  2. El pipeline entra en la nube sin claves guardadas.

    Por qué importa
    Las claves del CI son un objetivo habitual.
    Señal de alarma
    AWS_SECRET_ACCESS_KEY o un JSON de service account guardados como secreto del CI.
    Dónde mirarlo
    Federación OIDC desde GitHub/GitLab hacia roles de AWS IAM, credenciales federadas de Azure o Workload Identity Federation de GCP.

  3. La rama principal está protegida.

    Por qué importa
    Evita que un cambio sin revisar llegue a producción.
    Señal de alarma
    Se puede hacer push directo a main; sin tests obligatorios; revisión opcional.
    Dónde mirarlo
    Reglas de protección de rama, revisión obligatoria y checks de estado requeridos.

  4. Hay vuelta atrás y las migraciones de datos la permiten.

    Por qué importa
    Desplegar sin saber volver es el origen del miedo a desplegar.
    Señal de alarma
    No hay un procedimiento de rollback escrito; las migraciones de base de datos borran columnas en el mismo despliegue que el código que dejaba de usarlas.
    Dónde mirarlo
    Estrategia de despliegue (rolling, blue/green, canary) y migraciones compatibles hacia atrás en dos pasos.

  5. La infraestructura está en código y el estado está protegido.

    Por qué importa
    Sin IaC no hay reproducibilidad ni revisión.
    Señal de alarma
    Recursos creados a mano en la consola; el código y la realidad han divergido (drift); el estado de Terraform está en un portátil.
    Dónde mirarlo
    Terraform/OpenTofu, CloudFormation/CDK, Bicep, Pulumi. El estado, en un backend remoto (S3 con bloqueo, Azure Storage, GCS), cifrado y con versionado. Ejecuta un plan y mira cuántos cambios inesperados salen.

C

Datos y recuperación

  1. Copias de seguridad automáticas, cifradas y fuera del fallo.

    Por qué importa
    El borrado accidental y el ransomware no se arreglan con alta disponibilidad.
    Señal de alarma
    Backups solo en el mismo proyecto y con las mismas credenciales que producción; sin retención definida.
    Dónde mirarlo
    AWS Backup o snapshots de RDS con copia a otra cuenta o región; Azure Backup con un almacén separado; backups de Cloud SQL y copias de buckets en otro proyecto en GCP.

  2. Se ha restaurado alguna vez.

    Por qué importa
    Una copia no probada es una hipótesis.
    Señal de alarma
    Nadie recuerda la última restauración; no hay RPO ni RTO escritos (cuánto dato aceptas perder y cuánto tiempo puedes estar caído).
    Dónde mirarlo
    Prueba trimestral de restauración en un entorno aparte, con el tiempo medido y documentado.

  3. Protección contra borrado.

    Por qué importa
    Un terraform destroy o un clic en la consola no deberían poder eliminar la base de datos.
    Señal de alarma
    Bases de datos y buckets sin protección.
    Dónde mirarlo
    AWS: deletion protection en RDS, versionado y Object Lock en S3. Azure: resource locks y soft delete. GCP: deletion protection y retention policy en buckets.

  4. Disponibilidad proporcionada al negocio.

    Por qué importa
    La mayoría no necesita multi-región; casi todos necesitan que un fallo de zona no los tumbe.
    Señal de alarma
    Base de datos de producción en una sola zona y sin plan; o, al revés, multi-región cara sin que nadie la haya pedido.
    Dónde mirarlo
    Multi-AZ en RDS, zone redundancy en Azure, regional/HA en Cloud SQL, y al menos dos instancias de la aplicación en zonas distintas.

  5. Versiones soportadas.

    Por qué importa
    Lo que sale de soporte se cobra extra o se rompe sin avisar.
    Señal de alarma
    Kubernetes, motor de base de datos o runtime fuera de soporte; imágenes base sin actualizar; latest en producción.
    Dónde mirarlo
    Versión de EKS/AKS/GKE y fechas de fin de soporte; versión del motor de RDS/Azure Database/Cloud SQL; imágenes de contenedor fijadas por versión o digest.

D

Operación

  1. Alertas que alguien atiende.

    Por qué importa
    Una alerta que nadie lee es ruido.
    Señal de alarma
    Cientos de alertas sin leer; nadie sabe a quién llegan; alertas basadas en CPU en lugar de síntomas.
    Dónde mirarlo
    CloudWatch, Azure Monitor, Cloud Monitoring u otra herramienta: alerta sobre tasa de errores, latencia y saturación de lo que el usuario nota, con un responsable y un canal. Define el horario de atención real; si no hay guardia, dilo.

  2. Logs y auditoría centralizados.

    Por qué importa
    Sin logs no hay forma de explicar un incidente.
    Señal de alarma
    Logs que se pierden al reiniciar; auditoría desactivada; retención infinita que cuesta una fortuna.
    Dónde mirarlo
    CloudTrail activado en todas las regiones y enviado a una cuenta separada; Azure Activity Log y diagnósticos; GCP Cloud Audit Logs (los de acceso a datos deben activarse). Fija la retención por tipo de log.

  3. Runbooks y respuesta a incidentes.

    Por qué importa
    A las 3 de la mañana (o el lunes a las 9) nadie debería improvisar.
    Señal de alarma
    No hay un documento de «qué hago si la base de datos está caída»; los incidentes no se revisan después.
    Dónde mirarlo
    Un runbook de una página por incidente probable y una revisión sin culpables tras cada incidente.

  4. Superficie expuesta.

    Por qué importa
    Lo que se expone sin querer se encuentra solo.
    Señal de alarma
    Puertos SSH/RDP o bases de datos abiertos a 0.0.0.0/0; buckets o blobs públicos; endpoints de base de datos públicos; certificados que caducan sin aviso.
    Dónde mirarlo
    AWS security groups y S3 Block Public Access; Azure NSG y acceso público a Storage; GCP firewall rules y public access prevention. Usa un bastión o acceso por SSM/Bastion/IAP en lugar de abrir puertos.

  5. Cuotas y límites.

    Por qué importa
    El pico llega y la nube te dice que no.
    Señal de alarma
    Cerca del límite de instancias, IPs, vCPU o de la cuota de la API; límites de autoscaling inventados sin medir.
    Dónde mirarlo
    AWS Service Quotas; Azure usage + quotas; GCP IAM & Admin > Quotas. Pide aumentos antes del lanzamiento, no durante.

E

Costes y traspaso

  1. Cada euro tiene dueño.

    Por qué importa
    Lo que no está etiquetado no se puede discutir.
    Señal de alarma
    Una parte relevante del gasto sin etiqueta o sin asignar a un equipo, entorno o producto.
    Dónde mirarlo
    AWS: tags de asignación de costes activados. Azure: tags y Cost Management. GCP: labels y exportación de facturación a BigQuery.

  2. Presupuestos y alertas de anomalías.

    Por qué importa
    La mayoría de los sustos de factura se podrían haber visto el segundo día.
    Señal de alarma
    Nadie ve la factura hasta que llega.
    Dónde mirarlo
    AWS Budgets y Cost Anomaly Detection; presupuestos y alertas de Azure Cost Management; Billing budgets and alerts de GCP.

  3. Desperdicio evidente.

    Por qué importa
    Es la primera mejora, y sin riesgo para el producto.
    Señal de alarma
    Volúmenes sin adjuntar, snapshots huérfanos, IPs públicas sin uso, balanceadores sin tráfico, entornos de pruebas encendidos las 24 horas, instancias sobredimensionadas, tráfico entre zonas o NAT sin revisar.
    Dónde mirarlo
    AWS Cost Explorer, Compute Optimizer y Trusted Advisor; Azure Advisor; GCP Recommender. Acción tipo: apagar fuera de horario, redimensionar, eliminar. No son cifras de ahorro: depende de tu cuenta.

  4. Compromisos de uso, solo tras limpiar.

    Por qué importa
    Comprar reservas sobre un gasto inflado fija el desperdicio durante años.
    Señal de alarma
    Compromisos adquiridos sin análisis de uso estable; o, al revés, uso estable durante meses sin ningún compromiso.
    Dónde mirarlo
    AWS Savings Plans/Reserved Instances; Azure Reservations/Savings Plan; GCP Committed Use Discounts. Orden: etiquetar, limpiar, redimensionar y solo entonces comprometer la parte estable.

  5. Si tu CTO se va mañana, ¿continúa el equipo?

    Por qué importa
    Es el riesgo que resume todos los demás.
    Señal de alarma
    Solo una persona sabe desplegar, restaurar y entender la factura; no hay inventario de servicios con responsable; la documentación está en la cabeza de alguien.
    Dónde mirarlo
    Inventario de servicios con propietario, runbooks de los cinco procedimientos críticos (desplegar, volver atrás, restaurar, rotar secretos y dar de baja a una persona) y una persona suplente para cada uno. Este es el punto que más nos importa.

Cómo usarla

Puntúa cada punto a mano (sí, parcial o no) o haz la autoevaluación, que lo hace por ti con 15 preguntas. Empieza por los «no» de los bloques A y C: accesos y recuperación primero. Si tu equipo puede responder 20 de 25 sin buscar, no nos necesitas. Si no, escríbenos; y si puede resolverlo solo, mejor.

Ir a la autoevaluación

Reserva 30 minutosO escríbenos

Guía orientativa: no sustituye una auditoría ni garantiza seguridad ni ahorro.