La seguridad de AlpinaShop se ha construido a trozos. En 03-01 se cerró el firewall. En 03-04 se diseñó IAM con grupos, roles personalizados y cuentas de servicio sin claves. En 03-05 se puso Cloud Armor delante. En 03-06 llegaron Secret Manager y las claves gestionadas por el cliente. En 03-07 se publicó con TLS. En 06-02 se protegió la rama principal. En 07-03 se levantó un perímetro alrededor de los datos.

Cada pieza se decidió bien en su momento. Y nadie ha mirado nunca el conjunto.

Esa es la diferencia entre tener controles de seguridad y tener seguridad. Un atacante no ataca el firewall: ataca el eslabón más débil de una cadena que tú nunca has recorrido entera. Y en una empresa de cuarenta personas con tres personas técnicas, ese eslabón casi nunca es el que uno se imagina — no es una vulnerabilidad exótica en el kernel, es una clave JSON de hace dos años que sigue en el portátil de un becario que ya no trabaja aquí.

Esta lección es la revisión completa. Recorre la arquitectura capa por capa, aplica los principios que hacen que las capas se sostengan, revisa la cadena de suministro del software —que es hoy el vector de ataque que más crece—, cierra el ciclo de los datos, monta detección y respuesta, aclara qué parte del cumplimiento normativo es de Google y cuál es tuya, y termina con dos cosas que no suelen aparecer en los cursos: un checklist de endurecimiento que se puede ejecutar, y la lista honesta de la deuda de seguridad que AlpinaShop todavía tiene, priorizada.

Aviso, y va en serio. Esta lección es formación, no una auditoría. El modelo que se presenta es sólido y aplicable, pero cualquier arquitectura que trate datos personales, de pago o de salud debe ser revisada por un profesional de seguridad y de cumplimiento normativo antes de ir a producción, y con la periodicidad que exija el sector. Ningún curso, ninguna lista de comprobación y ninguna herramienta automática sustituye ese trabajo.

1. Defensa en profundidad aplicada a AlpinaShop
2. Los seis principios que sostienen todo lo demás
3. Confianza cero y BeyondCorp, con IAP como implementación práctica
4. Identidad: revisión completa del diseño IAM
5. Elevación temporal de privilegios y federación
6. Cadena de suministro del software
7. Datos: clasificación, cifrado, seudonimización y borrado
8. Detección: Security Command Center y los logs de auditoría
9. Respuesta: las dos primeras horas de un incidente
10. Cumplimiento: qué aporta Google y qué sigue siendo tuyo
11. Checklist de endurecimiento
12. La deuda de seguridad de AlpinaShop, priorizada

Defensa en profundidad significa que ningún control es el único. Si uno falla, otro detrás limita el daño. No es acumular herramientas: es diseñar de forma que el fallo de cualquier capa no sea catastrófico.

La forma de comprobar si la defensa en profundidad es real es hacerse la pregunta del fallo único en cada capa:

Las filas con respuesta dudosa son deuda, y van al apartado 12. Esa es la utilidad real del ejercicio: no confirmar lo que está bien, sino encontrar lo que no.

Las herramientas cambian; los principios no. Estos seis explican por qué cada decisión del curso fue la correcta.

Cada identidad tiene exactamente los permisos que necesita para su función, y ni uno más.

La aplicación honesta duele un poco: significa que cuando alguien pide "dame Editor para probar una cosa", la respuesta es no y hay que dedicar quince minutos a averiguar qué permiso necesita de verdad. El atajo de decir que sí es lo que ha llenado el mundo de proyectos donde todos son editores.

La herramienta que lo hace llevadero es el Recommender de IAM (03-04), que compara permisos concedidos con permisos usados en 90 días:

Quien construye no despliega solo; quien despliega no aprueba solo; quien administra no audita.

En AlpinaShop: Dani escribe el código, Cloud Build lo construye, Marta aprueba producción, y los logs de auditoría los custodia un proyecto al que ninguno de los dos puede escribir (07-07). Ninguna persona puede, por sí sola, poner código en producción y borrar la evidencia.

Lo que no está explícitamente permitido, está prohibido.

Se ha aplicado sistemáticamente: el firewall de 03-01 con denegación implícita; Cloud Run con --no-allow-unauthenticated; el ingress restringido al balanceador; el perímetro de VPC-SC; las políticas de organización de 07-07. La alternativa —permitir por defecto y bloquear lo malo conocido— es una carrera que se pierde siempre.

Cuando algo se comprometa —no si—, ¿hasta dónde llega?

Es el principio que justifica separar en proyectos, dar cuentas de servicio distintas a cada carga, y no reutilizar credenciales. La pregunta operativa: si esta credencial se filtra hoy, ¿qué puede hacer el que la tenga? Si la respuesta es larga, el diseño está mal.

Estar dentro de la VPC no es una credencial.

El modelo clásico —perímetro duro, interior blando— falla porque en cuanto alguien entra, lo tiene todo. Se desarrolla en el apartado 3.

Diseña como si ya estuvieran dentro.

Cambia las prioridades: se invierte tanto en detectar y limitar como en prevenir. Es lo que justifica los logs de auditoría inmutables, las alertas de comportamiento anómalo y el ensayo de la respuesta a incidentes.

BeyondCorp es el modelo de seguridad que Google adoptó internamente tras el ataque conocido como Operación Aurora en 2009, y que dio origen al término confianza cero.

En Google Cloud, la implementación práctica es IAP (Identity-Aware Proxy), que ya se usó en 03-04 y que aquí conviene mirar como pieza de arquitectura.

Lo que hace IAP, y por lo que merece la pena:

• La aplicación nunca ve tráfico no autenticado. El rechazo ocurre en el borde de Google.
• No hay VPN que mantener, ni concentrador que se cae, ni cliente que instalar.
• Funciona igual desde la oficina y desde casa, lo que elimina el incentivo de saltarse el control.
• Se combina con niveles de acceso por contexto: dispositivo corporativo verificado, disco cifrado, pantalla bloqueada, país permitido.

Y su límite honesto: IAP protege el acceso a aplicaciones HTTP y a SSH/RDP por túnel. No es un sustituto de la segmentación de red ni de IAM: es una capa más.

Aplicado a AlpinaShop, resuelve el problema del ejercicio de 07-03 —Lucía trabajando desde casa— mejor que ninguna lista de IP:

Se lee así: puede entrar quien use un equipo propiedad de la empresa, cifrado, con bloqueo de pantalla, con sistema operativo actualizado, desde España, Francia o Portugal. La IP ha dejado de importar, que es exactamente el punto.

La identidad es el nuevo perímetro. En una nube bien montada, la inmensa mayoría de los incidentes graves empiezan por una credencial, no por un puerto abierto.

Owner, Editor y Viewer existen desde antes de que IAM tuviera roles granulares y no deberían usarse nunca en producción:

Auditoría inmediata:

Lo que hay que encontrar y por qué:

La cuenta por defecto de Compute merece un párrafo propio porque es, con diferencia, el fallo más extendido de Google Cloud. Existe en todos los proyectos, históricamente venía con Editor, y cualquier VM, función o servicio que no especifique otra cuenta la hereda. Una vulnerabilidad en tu aplicación web pasa de "leer una base de datos" a "administrar el proyecto entero". La política de organización automaticIamGrantsForDefaultServiceAccounts (07-07) lo previene en proyectos nuevos; en los existentes hay que arreglarlo a mano.

Nadie es Owner de producción. Es la decisión de 03-04 que más discusión genera y la que más valor tiene: si nadie puede saltarse los controles, los controles son reales. Para las emergencias existe el procedimiento de acceso de ruptura de cristal del apartado 5, que es auditado y temporal.

La regla, ya establecida en 03-04 y que aquí se cierra:

Una clave JSON de cuenta de servicio descargada es una contraseña permanente sin caducidad que cualquiera puede copiar.

Alternativas, en orden de preferencia:

Búsqueda de claves existentes en toda la organización:

--managed-by=user es la clave del comando: filtra las claves descargables y descarta las que gestiona Google internamente, que son inofensivas y llenarían la salida de ruido.

Marta necesita compute.securityAdmin para tocar el firewall. Lo usa una vez al mes. El resto del tiempo, ese permiso solo aporta riesgo: si le roban la sesión un martes cualquiera, el atacante puede abrir el firewall.

Privileged Access Manager (PAM) resuelve esto con permisos que se piden, se justifican, se aprueban y caducan solos.

Lo que cambia:

Y el matiz importante para una pyme: si el aprobador es la única persona que puede aprobar y está de vacaciones, el proceso bloquea una emergencia. Tiene que haber un camino de ruptura de cristal: un derecho con aprobación automática, duración de una hora, y alerta inmediata al canal de seguridad cuando se usa. No se impide; se hace ruidoso. Es la misma filosofía que el procedimiento de emergencia de Terraform en 06-07: cuando no puede haber control preventivo, tiene que haber control detectivo.

Workload Identity Federation permite que una identidad externa —GitHub Actions, un clúster de otra nube, un proveedor OIDC— obtenga credenciales de corta duración de Google Cloud sin clave alguna. AlpinaShop ya lo usa desde 06-02.

El punto de seguridad que casi todo el mundo configura mal es la condición de atributos:

Esa condición parece restrictiva y no lo es tanto: si alguien crea una organización de GitHub llamada alpinashop, entra. Y aunque no fuera así, cualquier rama o pull request del repositorio podría desplegar en producción.

repository_id es numérico e inmutable: no se puede suplantar renombrando. Este es el detalle que separa una federación segura de una que solo lo parece.

Es el vector que más ha crecido en los últimos años, y el que menos atención recibe en las pymes. No hace falta atacar tu aplicación si se puede atacar una biblioteca que tu aplicación instala.

Y el paso que convierte el escaneo en un control: fallar la compilación si hay vulnerabilidades críticas con parche disponible.

El matiz de fixedVersion no es un tecnicismo: bloquear por vulnerabilidades sin parche disponible paraliza el desarrollo sin mejorar la seguridad, porque no hay nada que hacer salvo cambiar de dependencia. Se bloquea lo que se puede arreglar; lo demás se registra, se valora el riesgo y se decide.

Sin shell, un atacante que consiga ejecución de código no puede lanzar sh, ni curl, ni wget. No es invulnerable, pero la mayoría de las herramientas de post-explotación dejan de funcionar.

Y la reproducibilidad, que es lo que hace verificable todo lo anterior:

Las tres líneas que importan: digest en lugar de etiqueta, --require-hashes para que una dependencia manipulada haga fallar la instalación, y USER 1000 para no ejecutar como root.

SLSA (Supply-chain Levels for Software Artifacts) es un marco con niveles de garantía sobre cómo se construyó un artefacto. Cloud Build genera procedencia verificable de forma nativa:

La procedencia responde con firma criptográfica a: qué commit exacto, qué instrucciones de compilación, qué máquina, qué momento. Sirve para lo que en un incidente es una pregunta de horas: ¿esta imagen que está corriendo en producción se construyó desde nuestro código, o alguien la publicó a mano?

Ya se presentó en 07-01. Aquí es donde encaja: es el control que impide que llegue a producción una imagen que no pasó por el proceso.

Y aplica a Cloud Run, no solo a GKE, lo que lo hace directamente relevante para AlpinaShop tras 07-02:

Assured Open Source Software es un servicio por el que Google distribuye paquetes de código abierto que él mismo usa: los compila en su infraestructura, los escanea, los firma y les da procedencia SLSA.

Su valor es acotado y conviene decirlo: cubre un catálogo de paquetes populares de Java y Python, no todo lo que instalas. Para AlpinaShop, con una decena de dependencias comunes, la mayoría estarían cubiertas. No es una bala de plata; es reducir la superficie donde tienes que confiar ciegamente.

No se puede proteger lo que no se sabe qué es. La clasificación de AlpinaShop:

La cuarta fila es la mejor decisión de seguridad de todo el curso, y no es técnica: el dato que no guardas no se puede filtrar. AlpinaShop no almacena números de tarjeta porque la pasarela devuelve un token. Eso elimina de golpe el alcance completo de PCI-DSS sobre su infraestructura.

En 04-07 se presentó DLP —hoy Sensitive Data Protection— para el gobierno del dato. Aquí se usa como control de seguridad: encontrar datos personales donde no deberían estar.

Dos decisiones del fichero:

• includeQuote: false: no guardar el fragmento encontrado. Guardar el número de tarjeta detectado en la tabla de hallazgos sería crear una segunda copia del problema. Un error real y frecuente.
• SPAIN_DNI_NUMBER: existen detectores específicos por país. Usar solo los genéricos deja fuera lo más relevante en España.

Lo que se encuentra siempre, y AlpinaShop no fue excepción: correos electrónicos en campos de texto libre de comentarios, teléfonos en el campo "observaciones del pedido", y direcciones completas en logs de aplicación de hace meses. Ninguno era intencionado. Los tres son datos personales a efectos del RGPD.

Google cifra todo en reposo por defecto, sin configurar nada. CMEK (03-06) añade que la clave la controlas tú en Cloud KMS:

El "botón rojo" que da CMEK. Si se detecta una intrusión en curso, deshabilitar la clave hace ilegibles los datos cifrados con ella en segundos, incluso para quien tenga permisos de lectura. Es una capacidad de contención que sin CMEK no existe.

Con su contrapartida, que hay que decir claramente: si pierdes la clave, pierdes los datos. Definitivamente. Por eso KMS impide el borrado inmediato e impone un periodo de destrucción programada.

Para que Lucía analice comportamiento de compra no necesita saber quién es cada cliente:

Tres técnicas en cinco líneas: hash con sal para que el mismo cliente sea el mismo cliente_id sin poder revertirlo; generalización del código postal a los dos primeros dígitos, que da la provincia sin señalar el barrio; y omisión de nombre, dirección y teléfono, que no aportan nada al análisis.

Y la advertencia honesta: la seudonimización no es anonimización. Con la sal, el dato sigue siendo reidentificable y por tanto sigue siendo un dato personal a efectos del RGPD. Reduce el riesgo; no elimina la obligación.

El RGPD obliga a no conservar datos personales más de lo necesario, y a poder borrarlos a petición del interesado.

Y el borrado a petición, que es donde la mayoría de empresas descubre que su arquitectura no lo contemplaba:

Nótese el punto 1: los pedidos no se borran, se anonimizan, porque la normativa fiscal obliga a conservar las facturas. El derecho de supresión no es absoluto y colisiona con otras obligaciones legales; resolver esa colisión no es una decisión técnica y debe documentarse con asesoramiento jurídico.

SCC es el centro de seguridad de Google Cloud. Detecta configuraciones inseguras, vulnerabilidades y amenazas activas.

Qué detecta de verdad el nivel gratuito, que es el que va a usar una pyme:

Con Premium se añade Event Threat Detection, que analiza los logs en tiempo real buscando comportamiento —no configuración—: minería de criptomonedas en una VM, exfiltración de datos de BigQuery, uso de credenciales desde una geografía imposible, creación de una cuenta de servicio seguida inmediatamente de una concesión de permisos.

El criterio honesto para AlpinaShop: empezar con el nivel gratuito y atender de verdad sus hallazgos, que ya es más de lo que hace la mayoría. Premium se justifica cuando hay algo que vigilar activamente, un requisito de cumplimiento que lo exija, o alguien con tiempo para responder a lo que detecte. Comprar detección que nadie mira es peor que no comprarla, porque genera la sensación de estar protegido.

Se desarrollan a fondo en 07-07. Aquí, lo mínimo indispensable:

Que "acceso a datos" esté desactivado por defecto tiene una consecuencia que hay que asumir conscientemente: sin activarlo, no puedes saber quién leyó los datos de tus clientes. Para AlpinaShop, activarlo en alpinashop-datos y en los buckets con datos personales no es opcional si quiere responder a una brecha.

Tres consultas que hay que tener escritas antes de necesitarlas:

La tercera merece una alerta permanente: en una organización que federa identidades y usa impersonación, crear una clave JSON es un evento excepcional que siempre debe mirarse.

Aquí está lo que casi ningún curso incluye y lo que de verdad marca la diferencia. Un guion realista para un equipo de tres personas.

Escenario: son las 23:40 de un jueves de octubre, en plena campaña. Llega una alerta de SCC: "Anomalous IAM grant: la cuenta sa-informes-nocturnos ha concedido roles/owner a una cuenta externa".

No se toca nada todavía. El primer impulso —borrar la cuenta, cortar accesos— destruye evidencia y a veces avisa al atacante. Lo primero es responder tres preguntas:

1. ¿Es real o un falso positivo? ¿Hay un cambio programado esta noche? ¿Alguien está trabajando?
2. ¿Está en curso? ¿Sigue habiendo actividad de esa identidad ahora mismo?
3. ¿Qué alcance tiene? ¿Qué puede tocar esa credencial?

Si es real, cortar sin destruir. El orden importa:

El paso 3 es el que se olvida siempre. Deshabilitar una cuenta no invalida los tokens de acceso ya emitidos, que viven hasta una hora. Durante esa hora, el atacante sigue dentro aunque el panel diga que la cuenta está deshabilitada.

Las preguntas, en este orden:

La búsqueda de persistencia es la parte que más se descuida y la que hace que un incidente se repita a la semana siguiente:

Las 72 horas del RGPD para notificar a la autoridad de control no son negociables y el reloj empieza cuando tienes conocimiento, no cuando terminas la investigación. Es la razón número uno por la que hay que llamar al asesor jurídico en la primera hora, aunque todavía no se sepa el alcance.

Un incidente no es momento de improvisar. La carpeta que hay que tener escrita hoy:

• Teléfonos: interno, dirección, asesor jurídico, aseguradora, soporte de Google Cloud.
• El comando de contención ya escrito, probado y con permisos verificados.
• Un bucket de evidencia con retención bloqueada y creado fuera del proyecto que puede estar comprometido.
• Un canal de comunicación alternativo — si el correo corporativo está comprometido, no puedes coordinarte por correo.
• El acceso de emergencia probado: que Marta pueda entrar aunque su cuenta habitual esté bloqueada.
• Un simulacro al año. Media hora en una sala, sobre un escenario escrito. Descubre más agujeros que cualquier auditoría de configuración.

El reparto de 01-05, revisado ahora con todo el contexto:

Las certificaciones de Google —ISO 27001, ISO 27017, ISO 27018, SOC 1/2/3, PCI-DSS como proveedor, ENS en España, esquemas sectoriales— acreditan su infraestructura. Se descargan del Compliance Reports Manager.

Y aquí está el malentendido más caro del cumplimiento en la nube:

Que Google esté certificado en ISO 27001 no certifica tu empresa. Que su infraestructura sea apta para PCI-DSS no hace conforme tu tienda. Lo que te dan es que la capa de abajo ya está auditada, lo que reduce mucho tu alcance — pero tu configuración, tu código, tus procesos y tus personas siguen siendo tuyos y siguen siendo auditables.

Para AlpinaShop, como tienda online española:

La documentación que hay que tener, y que en una inspección se pide antes que cualquier configuración técnica:

1. Registro de actividades de tratamiento (art. 30 RGPD).
2. Contrato de encargado del tratamiento con Google Cloud.
3. Evaluación de impacto (EIPD) si hay tratamiento de alto riesgo.
4. Política de seguridad de la información, aunque sean cuatro páginas.
5. Procedimiento de respuesta a brechas, con los plazos del apartado 9.
6. Registro de accesos a datos personales — que es justo lo que dan los logs de acceso a datos.
7. Análisis de transferencias internacionales y garantías aplicadas.

Se repite porque importa: esta tabla es orientativa y docente. Un profesional de cumplimiento debe validar qué aplica a tu caso concreto, especialmente en lo relativo al RGPD, a las transferencias internacionales y al alcance de PCI-DSS.

Accionable sobre todo lo construido en el curso. La columna de estado es la de AlpinaShop hoy.

Resultado: 20 ✅, 11 ⚠️, 12 ❌. No está mal para una empresa de cuarenta personas. Y no es suficiente.

Ninguna empresa está al 100 %. Lo que distingue a una organización madura no es no tener deuda, sino saber cuál tiene, haberla priorizado y estar pagándola. Priorización por riesgo (probabilidad × impacto) frente a esfuerzo.

Los cuatro suman menos de dos días de trabajo y son lo que más reduce el riesgo. Empezar por aquí no es opinable.

Y esto también forma parte de la madurez: decidir no hacer algo, por escrito, con motivo.

Un riesgo aceptado y documentado no es un fallo de seguridad: es una decisión de gestión. Un riesgo que nadie ha mirado, sí.

• Confundir tener herramientas con tener seguridad. SCC activado y nadie mirando los hallazgos es peor que no tenerlo: genera falsa confianza.
• Dejar la cuenta por defecto de Compute con Editor. Es el fallo más extendido de Google Cloud y convierte cualquier vulnerabilidad en un compromiso total del proyecto.
• Crear claves JSON "para probar". Nunca se borran. Búscalas periódicamente con --managed-by=user.
• Federar identidad sin condición de atributos estricta. Sin repository_id y ref, cualquier rama o repositorio con el mismo nombre de organización puede desplegar en producción.
• Borrar la cuenta comprometida durante un incidente. Destruye evidencia. Se deshabilita.
• Olvidar que los tokens vivos sobreviven a la deshabilitación hasta una hora.
• Guardar el fragmento detectado por DLP. Crear una tabla con los números de tarjeta encontrados es duplicar el problema, no resolverlo.
• Creer que la seudonimización es anonimización. Con la sal, sigue siendo dato personal a efectos del RGPD.
• Pensar que las certificaciones de Google certifican tu empresa. Certifican la capa de abajo. Tu configuración es tuya.
• Bloquear compilaciones por vulnerabilidades sin parche disponible. Paraliza al equipo sin mejorar nada. Se bloquea lo que se puede arreglar.
• Activar todos los controles a la vez. VPC-SC, Binary Authorization y políticas de organización el mismo día es garantía de caída. Uno cada vez, en modo de prueba primero.
• Dejar el plan de respuesta para cuando haga falta. El incidente es el peor momento para escribirlo.
• Consejo: haz la pregunta del fallo único en cada capa. Es media hora y encuentra más que cualquier escáner.
• Consejo: la mejor medida de seguridad es el dato que no guardas. Antes de proteger un dato, pregunta si hace falta almacenarlo.
• Consejo: un simulacro de media hora al año descubre más agujeros reales que una auditoría de configuración.
• Consejo: escribe la deuda aceptada. Convierte un agujero en una decisión, y hace que se revise.

Escribe un script de auditoría que, sobre los cinco proyectos de AlpinaShop, detecte y reporte:

1. Cualquier vínculo con roles básicos (owner, editor, viewer).
2. Vínculos con allUsers o allAuthenticatedUsers en proyectos y en buckets.
3. Cuentas de servicio con claves gestionadas por el usuario, con su antigüedad.
4. Cuentas de servicio que no se han usado en 90 días.
5. Cuentas de servicio con roles de administrador.

Para cada hallazgo, indica gravedad y acción recomendada. Explica además por qué el punto 4 es más importante de lo que parece.

Escenario. Un lunes por la mañana, un desarrollador externo publica en un foro público que ha encontrado un repositorio de GitHub de AlpinaShop con un fichero credenciales.json en el historial de commits. El fichero es una clave de sa-dataflow-pedidos, borrada del repositorio hace ocho meses pero presente en el historial. Esa cuenta tiene roles/bigquery.dataViewer sobre alpinashop_analitica y roles/storage.objectAdmin sobre alpinashop-datalake.

Escribe el plan de respuesta completo con marcas de tiempo: qué se hace en los primeros 10 minutos, en los primeros 30, en la primera hora y en las primeras 24 horas. Incluye los comandos, las decisiones de comunicación (con quién y cuándo), cómo se determina si hubo acceso indebido, y qué cambios estructurales se hacen después para que no vuelva a pasar.

La dirección de AlpinaShop aprueba 10 días de trabajo de Marta y 3.000 € para seguridad este trimestre. No hay más.

De la lista de deuda del apartado 12, elige qué se hace y qué no, justificando cada decisión con criterio de riesgo frente a esfuerzo. Elabora un plan por semanas y, lo más importante, escribe qué le dices a dirección sobre lo que queda sin hacer, en lenguaje que un director general entienda.

Solución 1 — Auditoría de identidad

Tabla de hallazgos, gravedad y acción:

Por qué el punto 4 es más importante de lo que parece. Una cuenta de servicio sin uso es un objetivo silencioso: nadie vigila su actividad, nadie notaría un uso anómalo, y como no se usa, nadie recuerda por qué existe ni qué permisos tiene. Además de eliminar superficie de ataque, la limpieza aporta algo más valioso: cada cuenta que se elimina reduce el ruido de la auditoría, y una lista de veinte cuentas de las que se entienden las veinte es infinitamente más segura que una de sesenta de las que se entienden veinte.

La técnica correcta es deshabilitar antes de borrar (gcloud iam service-accounts disable): si algo se rompe, se reactiva en un segundo; si se borró, hay que recrearla y reconstruir todos sus permisos. Treinta días de espera es un plazo razonable, porque captura los procesos mensuales.

Solución 2 — Diseñar la respuesta a un incidente concreto

T+0 a T+10 min — Valorar sin actuar.

La primera decisión: esto ya es público. A diferencia de una detección interna, aquí el atacante potencial no solo existe: hay un foro entero que sabe de la clave. La urgencia es máxima y el sigilo ya no aporta nada, lo que cambia el cálculo respecto al apartado 9.

Se busca una sola cosa: peticiones desde IP que no sean las de Dataflow. Si aparecen, el incidente pasa de "credencial expuesta" a "acceso confirmado", con implicaciones legales inmediatas.

T+10 a T+30 min — Contener.

La decisión difícil de estos veinte minutos: deshabilitar la cuenta rompe el pipeline de pedidos hacia BigQuery. Se hace igualmente. Ante una credencial pública con acceso al data lake, la analítica puede esperar unas horas. Y es exactamente la decisión que hay que haber pensado antes, no en caliente.

El punto 4 merece atención: si el perímetro hubiera estado aplicado en lugar de en modo de prueba (deuda #7), la clave filtrada no habría podido sacar un solo byte fuera de la organización. El incidente ilustra por qué un control a medias no es medio control.

T+30 min a T+1 h — Determinar si hubo acceso.

Y aquí aparece el problema que convierte este ejercicio en la mejor demostración de por qué la deuda #5 importa: los logs de acceso a datos están desactivados. AlpinaShop tiene los logs de actividad de administrador —sabrá si alguien cambió permisos— pero no puede saber si alguien leyó la tabla de pedidos.

Consecuencia práctica, y es grave: al no poder demostrar que no hubo acceso, jurídicamente hay que tratar el caso como si pudiera haberlo habido. Se pasa de "credencial expuesta sin evidencia de uso" a "posible brecha de datos personales cuyo alcance no se puede acotar". Eso cambia por completo la notificación a la AEPD.

Vías alternativas de evidencia, todas peores:

T+1 a T+2 h — Comunicar.

T+2 a T+24 h — Alcance y erradicación.

T+24 a T+72 h — Notificación. Si el asesor jurídico determina que hay riesgo para los derechos de los interesados, notificación a la AEPD dentro de las 72 horas. Al no poder descartar el acceso, lo más probable es que haya que notificar. La notificación describe: qué ocurrió, qué datos podrían estar afectados, qué medidas se han tomado, y por qué no se puede acotar el alcance — lo cual, dicho sea con claridad, es en sí mismo un hallazgo desfavorable sobre la organización.

Cambios estructurales después:

La reflexión final del ejercicio. La clave se subió hace ocho meses, se borró del repositorio, y todo el mundo pensó que el problema estaba resuelto. Borrar un fichero de Git no borra su historial: cualquiera con acceso al repositorio —o al repositorio público, o a un fork— podía recuperarlo con git log -p. Es un malentendido tan extendido que merece una regla:

Un secreto que ha estado en un repositorio, aunque sea un minuto, está comprometido. La única respuesta correcta es rotarlo. Borrarlo del historial es limpieza, no remediación.

Solución 3 — Priorizar con presupuesto limitado

Restricciones: 10 días de Marta, 3.000 €, un trimestre. Y una premisa que hay que respetar: Marta también tiene que operar la plataforma, así que 10 días de seguridad son 10 días reales, no elásticos.

Lo que se hace:

Sobran 2.100 €. Y aquí viene la propuesta que da más valor por euro:

Contratar una revisión externa de seguridad de medio día (~1.500-2.000 €) al final del trimestre, sobre la arquitectura ya endurecida.

El razonamiento: Marta ha construido esta plataforma y tiene los puntos ciegos de quien la construyó. Una mirada externa sobre un sistema ya ordenado encuentra cosas distintas de las que encontraría sobre uno desordenado — y por eso se contrata después de pagar la deuda de prioridad 1 y 2, no antes. Además aporta algo que dentro no se puede fabricar: un informe firmado por un tercero, que es lo que pide un cliente corporativo, una aseguradora o una inspección.

Lo que NO se hace, y por qué:

Lo que se le dice a dirección — y esta es la parte que más cuesta y más importa:

"Con estos diez días cerramos los cuatro agujeros que hoy nos exponen más: una contraseña permanente que perdimos hace más de un año y que sigue funcionando, una cuenta interna que da permiso para borrar cualquier cosa, un sistema automático que puede tocarlo todo, y la falta de aviso cuando alguien cambia permisos.

Además hacemos dos cosas que hoy no tenemos y que son obligación legal o de sentido común: saber quién accede a los datos de nuestros clientes —hoy no podríamos responder a esa pregunta ante la Agencia de Protección de Datos, y no poder responderla es en sí mismo un problema— y comprobar que nuestras copias de seguridad se pueden restaurar de verdad, que nunca lo hemos verificado. Y ensayamos qué haríamos si mañana pasa algo, porque el día del incidente es el peor día para improvisar.

Lo que queda sin hacer, y quiero que conste por escrito: no vamos a tener vigilancia activa de amenazas —si alguien entra sin hacer ruido, nos enteraríamos tarde—; no vamos a impedir técnicamente que se despliegue software no aprobado; los permisos administrativos seguirán siendo permanentes en lugar de temporales; y no vamos a contratar un ataque simulado profesional. Cada una de estas cuatro cosas es una decisión de presupuesto, no un descuido, y la revisamos el trimestre que viene.

Con lo que hacemos pasamos de un riesgo que yo calificaría de alto a uno medio. Llegar a bajo requiere una persona dedicada a seguridad o un servicio gestionado, y eso es una conversación distinta que conviene tener cuando seamos sesenta personas o cuando un cliente grande nos lo exija por contrato."

Los tres elementos que hacen buena esta comunicación, y que se pueden reutilizar en cualquier empresa: se habla de riesgos de negocio y no de nombres de productos; se dice explícitamente lo que queda sin cubrir en lugar de dejar que la dirección asuma que todo está resuelto; y se fija cuándo se revisa, lo que convierte un recorte presupuestario en una decisión consciente con fecha en lugar de en un silencio.

AlpinaShop ha pasado de tener controles de seguridad a tener seguridad revisada, y —lo que es más útil— a saber exactamente qué le falta.

Has aplicado defensa en profundidad capa por capa —borde, identidad, red, carga de trabajo, datos, detección— y sobre todo has aprendido la pregunta del fallo único, que es la herramienta más barata y más eficaz de toda la lección: para cada capa, si esto falla, ¿qué lo contiene? Las respuestas dudosas son la deuda.

Tienes los seis principios que explican todas las decisiones del curso: mínimo privilegio con el Recommender que lo hace llevadero, separación de funciones —Dani escribe, Cloud Build construye, Marta aprueba, y nadie puede desplegar y borrar la evidencia—, denegar por defecto, radio de explosión limitado con su pregunta operativa, no confiar en la red, y asumir la brecha.

Entiendes confianza cero y BeyondCorp con IAP como implementación práctica, y has visto que un nivel de acceso basado en el dispositivo —corporativo, cifrado, bloqueado, actualizado, desde una región permitida— resuelve el teletrabajo mucho mejor que cualquier lista de IP, porque hace que la IP deje de importar.

Has revisado la identidad a fondo: eliminar los roles básicos, el script que los encuentra, y los tres hallazgos que aparecen siempre —una persona con Owner, Cloud Build con Editor y, sobre todo, la cuenta por defecto de Compute con Editor, que es el fallo más extendido de Google Cloud y el que convierte cualquier vulnerabilidad de aplicación en un compromiso total. Conoces las alternativas sin claves para cada situación y el comando con --managed-by=user que encuentra las que quedan. Sabes montar elevación temporal con PAM —con el camino de ruptura de cristal que no impide sino que hace ruido— y federación de identidad con la condición de atributos por repository_id y ref que separa una federación segura de una que solo lo parece.

Dominas la cadena de suministro: escaneo que bloquea solo lo que tiene parche, imágenes base mínimas —con la tabla que va de python:3.12 a distroless— fijadas por digest y con --require-hashes, USER 1000 en lugar de root, procedencia SLSA que responde a "¿esta imagen salió de nuestro código?", Binary Authorization —que también aplica a Cloud Run— y Assured Open Source con su alcance honesto.

Has cerrado el ciclo de los datos: clasificación en cuatro niveles con la mejor decisión de seguridad del curso —no almacenar tarjetas, porque el dato que no guardas no se filtra—, descubrimiento con Sensitive Data Protection y detectores españoles, includeQuote: false para no duplicar el problema, CMEK con su "botón rojo" de deshabilitar la clave y su contrapartida irreversible, seudonimización con hash salado y generalización —que no es anonimización— y retención con el procedimiento de supresión que anonimiza los pedidos en lugar de borrarlos porque la obligación fiscal manda.

Sabes detectar: Security Command Center con sus tres niveles, lo que el gratuito encuentra de verdad, y el criterio honesto de que comprar detección que nadie mira es peor que no comprarla. Y tienes los cuatro tipos de log de auditoría con el dato que cambia todo — acceso a datos está desactivado por defecto, y sin él no puedes saber quién leyó los datos de tus clientes— junto con las tres consultas que hay que tener escritas antes de necesitarlas.

Tienes un guion de respuesta realista: diez minutos para valorar sin tocar nada, veinte para contener sin destruir evidencia —deshabilitar y no borrar, y revocar los tokens vivos que sobreviven una hora—, media hora para el alcance incluyendo la búsqueda de persistencia, y la comunicación con las 72 horas del RGPD contando desde el conocimiento y no desde la conclusión. Con la carpeta que hay que preparar hoy, incluido el canal de comunicación alternativo y el simulacro anual.

Sabes qué cumplimiento aporta Google y cuál sigue siendo tuyo, con el malentendido más caro aclarado: sus certificaciones acreditan la capa de abajo, no tu empresa. Y tienes la lista de los siete documentos que se piden antes que cualquier configuración técnica.

Y te llevas dos cosas que valen más que cualquier apartado teórico: el checklist de 43 controles con el estado real de AlpinaShop —20 ✅, 11 ⚠️, 12 ❌— y la deuda priorizada en tres bloques, con cuatro tareas de prioridad 1 que suman menos de dos días y son lo que más riesgo elimina. Más la lista de deuda aceptada conscientemente, porque un riesgo documentado es una decisión de gestión y un riesgo que nadie ha mirado es un agujero.

El ejercicio de la clave filtrada ha dejado la lección más incómoda de todas, y conviene llevársela literal: un secreto que ha estado en un repositorio, aunque sea un minuto, está comprometido; borrarlo del historial es limpieza, no remediación.

Y el ejercicio del presupuesto ha dejado la otra: la seguridad de una pyme no se decide con la lista de lo ideal, sino eligiendo diez días bien gastados y diciéndole a dirección, por escrito y en su idioma, lo que queda sin cubrir.

Dos hilos de esta lección quedan explícitamente abiertos. Uno apunta a 07-06: la restauración de copias nunca se ha probado, y aparece como riesgo crítico tanto en el checklist como en la priorización. El otro apunta a 07-07: las políticas de organización, los logs de auditoría inmutables en un proyecto separado y la revisión periódica de accesos son gobierno, y ahí se resuelven.

Pero antes hay una conversación que lleva siete módulos aplazándose. Cada lección ha añadido servicios; ninguna ha cerrado la factura. Esta misma lección ha propuesto activar los logs de acceso a datos —que cuestan—, ha descartado SCC Premium por precio, y ha repartido 3.000 € como si fueran mucho dinero, que para una empresa de cuarenta personas lo son. Ninguna de esas tres decisiones se puede tomar bien sin entender de dónde sale cada euro de la factura de AlpinaShop. La siguiente lección abre la factura entera, línea a línea, y la explica.