Módulo 1: Threat Modeling Andes Cargo

1. Introducción a la guía: de "funciona" a "es seguro"

Descripción

Si completaste aws-core-services-guide, terraform-and-iac-guide y cicd-and-gitops-on-aws-guide, ya tienes algo real: la infraestructura completa de Andes Cargo —un bucket S3, dos roles IAM, una función Lambda, una tabla DynamoDB— declarada en Terraform dentro de andes-cargo-infra/, corriendo a través de un pipeline de GitHub Actions (ci.yml, apply.yml, drift.yml) que ejecutaste con act contra LocalStack. El plan sale limpio. El apply termina con Apply complete!. El pipeline queda en verde, Job succeeded. Todo funciona.

Esta guía —Seguridad Cloud y Guardrails— parte de una pregunta incómoda que ninguna de las tres guías anteriores contestó todavía: ¿"funciona" es lo mismo que "es seguro"? La respuesta corta, que vas a probar con evidencia concreta en la lección 2, es no. Un plan limpio confirma que Terraform va a hacer exactamente lo que el HCL describe. No confirma que lo que el HCL describe sea seguro. Un apply exitoso confirma que AWS aceptó cada llamada. No confirma que esas llamadas dejaron los permisos correctos, las credenciales bien guardadas, o el artefacto de despliegue sin manipular. Un pipeline en verde confirma que ningún paso falló. No confirma que nadie revisó si algo debería haber fallado.

Conexión con el módulo

Este Módulo 1 no construye ningún candado todavía —eso empieza en el Módulo 2—. Su trabajo es distinto y, en cierto sentido, más urgente: instalar la disciplina de pensar como atacante antes de escribir una sola línea de política. Las lecciones 2 y 3 dan el vocabulario (por qué verde no es sinónimo de seguro, y qué es STRIDE, el framework que vas a usar durante toda la guía). Las lecciones 4 y 5 aplican ese vocabulario a la infraestructura real de Andes Cargo —no a un ejemplo de libro de texto—. La lección 6 retoma, desde un ángulo nuevo, un incidente que ya conoces si viniste de terraform-and-iac-guide o cicd-and-gitops-on-aws-guide. Las lecciones 7 y 8 son los dos entregables reales de este módulo: un documento de modelo de amenazas y un mapa de riesgos que van a gobernar, fila por fila, el resto de esta guía.

Qué asume esta guía (y qué no vuelve a explicar)

Esta guía no es un punto de entrada al ecosistema de AWS de Andes Cargo. Asume, sin volver a explicarlo:

De aws-core-services-guide: qué es IAM de una sola cuenta —usuarios, grupos, roles, políticas, mínimo privilegio como concepto—, y los cuatro servicios que sostienen el caso (S3, DynamoDB, Lambda, IAM).
De terraform-and-iac-guide: qué es HCL, el ciclo init/plan/apply/destroy, el state como fuente de verdad, y el proyecto andes-cargo-infra/ completo —doce recursos, dos módulos hijos (modules/s3-bucket/, modules/iam-role/)— tal como quedó al cerrar esa guía.
De cicd-and-gitops-on-aws-guide: qué es un workflow de GitHub Actions, act como motor de ejecución local, el patrón plan-en-PR/apply-en-merge, y los tres archivos .github/workflows/ci.yml, apply.yml, drift.yml corriendo contra LocalStack con credenciales dummy (test/test) leídas desde un .secrets gitignorado.

Si algo de esa lista no te suena firme, esta es la señal de volver a la guía correspondiente antes de seguir. Ninguna lección de aquí en adelante vuelve a explicar qué es un resource de Terraform, un job de GitHub Actions, o una trust policy de IAM —solo cómo endurecerlos.

Lo que esta guía sí enseña, y que ninguna de las tres anteriores cubrió a fondo: modelado de amenazas y STRIDE; identidad federada OIDC construida de verdad, no solo nombrada; gestión de secretos con SSM Parameter Store y Secrets Manager; policy-as-code preventivo ejecutado con conftest/OPA; escaneo estático de infraestructura como código con Trivy y Checkov; cadena de suministro de software —SBOM y firma de artefactos con cosign/Sigstore—; y la distinción entre guardrails detectivos y preventivos.

El mapa completo: los 8 módulos de esta guía

   SEGURIDAD CLOUD Y GUARDRAILS — LOS 8 MÓDULOS

   M1  Threat modeling               ← estás aquí: STRIDE, THREAT-MODEL.md, el mapa de riesgos
   M2  Identidad federada y mínimo privilegio    OIDC construido, roles endurecidos
   M3  Gestión de secretos                       SSM Parameter Store, Secrets Manager
   M4  Policy-as-code con conftest               Rego real sobre el plan, antes del apply
   M5  Escaneo de IaC y dependencias              Trivy, Checkov, hallazgos reales
   M6  Cadena de suministro: SBOM y firma          sbom.cyclonedx.json, cosign, 100% offline
   M7  Guardrails detectivos vs. preventivos       CloudTrail, SCP, permission boundaries
   M8  Capstone: el security gate de Andes Cargo   conftest → Trivy → cosign, encadenados

#	Módulo	Qué construye	Pieza nueva en `andes-cargo-infra/`
1	Threat modeling de Andes Cargo	El vocabulario (STRIDE) y el primer entregable real	`THREAT-MODEL.md`, `RISK-MAP.md`
2	Identidad federada y mínimo privilegio IAM	OIDC de punta a punta hasta el límite $0, roles recortados	`modules/oidc-provider/`
3	Gestión de secretos	El `.secrets` plano heredado, reemplazado por servicios gestionados	`secrets.tf`
4	Policy-as-code con `conftest`	Políticas Rego que evalúan el `plan` antes de aplicarlo	`policy/*.rego`
5	Escaneo de IaC y dependencias	Trivy y Checkov corridos de verdad sobre el proyecto real	`.trivyignore`, comentarios `#checkov:skip=`
6	Cadena de suministro: SBOM y firma	El SBOM del handler y la firma del artefacto de despliegue	`sbom.cyclonedx.json`, `cosign.key`/`cosign.pub`
7	Guardrails detectivos vs. preventivos	La distinción central de vocabulario, con honestidad de qué corre en LocalStack Hobby	permission boundary, intento de CloudTrail
8	Capstone: el security gate	Los tres jobs nuevos encadenados en `ci.yml`/`apply.yml` heredados	jobs `policy-check`, `iac-scan`, `verify-artifact`

Fíjate en la progresión: primero piensas como atacante (M1), después construyes identidad de verdad (M2) y le quitas secretos al repositorio (M3), después instalas dos capas de revisión automática —tus propias reglas (M4) y las de la comunidad (M5)—, después aseguras que el artefacto que se despliega es el que se revisó (M6), después nombras con precisión qué de todo esto detecta y qué de todo esto previene (M7), y cierras encadenando las tres piezas ejecutables en un solo gate que un cambio malo no puede cruzar (M8).

El mapa de este módulo: las 8 lecciones

#	Lección	Qué practicas
1	Introducción (esta)	El mapa completo, qué se hereda de las tres guías anteriores, qué existe al cerrar el M8
2	Verde no es sinónimo de seguro	Qué confirma —y qué NO confirma— un `plan`/`apply`/pipeline en verde; el movimiento de mercado "build in"
3	Qué es el modelado de amenazas y STRIDE	Las seis categorías, cada una con analogía cotidiana antes del ejemplo técnico
4	Manos a la obra: mapeando la superficie de ataque	Ejecutado (representativo): `awslocal iam list-roles`, `list-attached-role-policies`, `s3api get-bucket-policy`, `lambda get-policy` contra la infraestructura heredada
5	Aplicando STRIDE a Andes Cargo	Siete riesgos reales, uno por categoría (con Information Disclosure aparecido dos veces), cada uno con evidencia del inventario del M1.4
6	El radio de explosión, revisitado	El incidente Claude Code `destroy`, desde el ángulo de qué control automatizado lo hubiera detenido
7	Manos a la obra: escribiendo `THREAT-MODEL.md`	Ejecutado (el documento): el modelo de amenazas completo, la fuente que gobierna la guía
8	Proyecto: el mapa de riesgos de Andes Cargo	Ejecutado (el documento): `RISK-MAP.md`, la matriz de siete filas que apunta cada riesgo a su módulo

Lo genuinamente nuevo de esta guía

Ningún módulo de esta guía declara un recurso HCL de negocio nuevo, ni reescribe un solo workflow desde cero. El bucket sigue llamándose andes-cargo-shipment-docs, la tabla sigue siendo Shipments con partition key shipmentId, la función sigue siendo process-shipment-manifest, y los roles siguen siendo LambdaManifestProcessorRole y AppServerRole. Lo nuevo, siempre en la capa de seguridad, nunca en la de negocio:

THREAT-MODEL.md y RISK-MAP.md, en la raíz de andes-cargo-infra/ — los dos entregables de este módulo.
modules/oidc-provider/ — módulo Terraform nuevo del Módulo 2.
secrets.tf — del Módulo 3, reemplazando el .secrets plano.
policy/ — las políticas Rego del Módulo 4.
.trivyignore y comentarios #checkov:skip= — del Módulo 5, cada supresión con su razón documentada al lado.
sbom.cyclonedx.json, cosign.key (gitignorado) y cosign.pub (committeado) — del Módulo 6.
.github/workflows/ci.yml y apply.yml extendidos, no reescritos, con tres jobs nuevos — el security gate del Módulo 8.

El compromiso de $0, y la honestidad exacta que exige esta guía

Las tres guías anteriores de este ecosistema pudieron ejecutar casi todo contra LocalStack sin decir nunca "esto es representativo" salvo por la ausencia puntual de un LOCALSTACK_AUTH_TOKEN en este entorno de escritura. Esta guía es distinta, y vale la pena que lo sepas desde esta primera lección: la seguridad real en AWS —autenticación, autorización, auditoría— depende de mecanismos que un emulador gratuito, por diseño, no reproduce con el mismo rigor que una cuenta real.

Lo que SÍ corre de verdad, con herramientas $0 reales, sostiene la mayoría de los módulos: conftest (motor del M4), Trivy y Checkov (motor del M5), y cosign (motor del M6) —ninguna requiere cuenta de pago, tarjeta, ni conexión a un registro—. Vas a instalar y correr las cuatro con salida literal, no simulada.

Lo que queda representativo, con la razón técnica exacta declarada en el momento en que aparece (nunca escondida al final de una lección):

La validación real de un token OIDC contra AWS (M2.6). LocalStack sí implementa la operación sts:AssumeRoleWithWebIdentity a nivel de API, y esta guía sí la ejecuta —pero la funcionalidad que evaluaría de verdad si ese token tiene permiso, IAM Policy Enforcement, está documentada explícitamente como "Included in Plans: Base, Ultimate" — no en el plan gratuito Hobby/Community que usa todo este ecosistema.
El enforcement de IAM en general (M2.7, M7.3): misma razón exacta. Esta guía construye y lee las políticas; no puede probar el bloqueo contra una llamada real.
Guardrails detectivos a escala (GuardDuty, AWS Config con reglas continuas): no confirmados en el plan gratuito de LocalStack (M7.4).
Organizations, Control Tower, SCPs multi-cuenta (M7.6): fuera del alcance $0 y fuera del caso Andes Cargo, que sigue siendo una sola cuenta.

También en este entorno específico de escritura —sin LOCALSTACK_AUTH_TOKEN exportado— el contenedor de LocalStack no arranca, exactamente el mismo límite que ya viste, con el mismo mensaje de error honesto (Could not connect to the endpoint URL), en cicd-and-gitops-on-aws-guide Módulo 4, lección 7. La lección 4 de este módulo retoma esa misma honestidad para los comandos awslocal de inventario: la salida que vas a leer ahí es la que produciría cada comando contra la infraestructura ya aplicada, reconstruida campo por campo a partir del HCL real y de las verificaciones que terraform-and-iac-guide ya confirmó —nunca inventada, siempre etiquetada.

Errores comunes

Asumir que este módulo ya construye algún candado (de expectativa). Qué pasa: alguien termina la lección 8, con THREAT-MODEL.md y RISK-MAP.md escritos, y espera que AppServerRole ya tenga permisos más estrechos, o que exista alguna política Rego corriendo. Cómo detectarlo: si buscas en este módulo un cambio real al HCL o al pipeline de Andes Cargo. Cómo corregirlo: este módulo produce documentos, no controles. Es el mapa que gobierna dónde se construye cada candado —M2 en adelante—, no el candado mismo. Confundir "identificar un riesgo" con "haberlo resuelto" es, de hecho, exactamente el tipo de falso sentido de seguridad que la lección 2 de este módulo nombra.

Tratar los cuatro casos representativos como una debilidad de esta guía, no como honestidad (de lectura). Qué pasa: alguien lee "LocalStack Hobby no valida esto de verdad" y concluye que la guía es incompleta o poco seria. Cómo detectarlo: si tu reacción a un bloque etiquetado "(representativo)" es descartar la lección completa. Cómo corregirlo: la alternativa a declarar el límite exacto no es "una guía más completa" —es una guía que finge que algo corrió cuando no corrió, exactamente el antipatrón que esta guía entera existe para combatir. Cada caso representativo viene con la fuente verificada de por qué es representativo, nunca con una promesa vaga.

Saltarse una de las tres guías anteriores porque "esta ya explica lo que hace falta" (de flujo). Qué pasa: alguien sin terraform-and-iac-guide intenta seguir el M1.4 de esta guía y no reconoce ningún nombre de recurso, o sin cicd-and-gitops-on-aws-guide no entiende por qué existe un .secrets gitignorado. Cómo detectarlo: si un nombre como LambdaManifestProcessorRole o un archivo como ci.yml te resulta desconocido. Cómo corregirlo: vuelve a la guía correspondiente. Esta guía asume las tres completas, sin excepción, desde esta primera lección.

Ejercicios

Ejercicio 1 — Explica, en tus propias palabras, la tesis central de este módulo. Sin usar todavía el término "STRIDE" (lo formalizas en la lección 3), describe en dos o tres frases por qué un pipeline de Andes Cargo que corre en verde desde hace tres guías podría, de todas formas, no ser seguro.

Ver solución

Una respuesta completa suena, más o menos, así: "Un pipeline verde confirma que cada paso que alguien definió tuvo éxito —el formato es correcto, la sintaxis es válida, AWS aceptó las llamadas—. Pero nadie definió, hasta ahora, ningún paso que preguntara '¿este cambio es seguro?': si una credencial vive en texto plano, si un rol tiene más permisos de los que usa, si el artefacto que se despliega es exactamente el que alguien revisó. El pipeline nunca falló por esas razones porque nunca las evaluó." La pieza clave: "verde" mide que el proceso definido se ejecutó sin errores, no que el proceso definido incluya las preguntas de seguridad correctas.

Ejercicio 2 — Ubica los cuatro entregables nuevos, sin mirar hacia atrás. De memoria, nombra los cuatro artefactos de la capa de seguridad —no de negocio— que este módulo y los siguientes agregan a andes-cargo-infra/, y en qué módulo aparece cada uno.

Ver solución

THREAT-MODEL.md y RISK-MAP.md (Módulo 1, este módulo); modules/oidc-provider/ (Módulo 2); secrets.tf (Módulo 3); policy/ con las políticas Rego (Módulo 4); .trivyignore y comentarios #checkov:skip= (Módulo 5); sbom.cyclonedx.json + cosign.key/cosign.pub (Módulo 6); y los tres jobs nuevos en ci.yml/apply.yml (Módulo 8). Si recordaste al menos cinco de los siete sin mirar la tabla, tienes clara la progresión de la guía.

Ejercicio 3 — Explica por qué esta guía no puede probar el enforcement de IAM contra LocalStack. Un colega pregunta por qué, si terraform-and-iac-guide y cicd-and-gitops-on-aws-guide corrieron casi todo de verdad contra LocalStack, esta guía necesita marcar tantos casos como "representativos". Responde citando la razón técnica exacta.

Ver solución

Porque la pieza específica que evaluaría si una llamada real viola una política —IAM Policy Enforcement— es una funcionalidad de LocalStack documentada explícitamente como incluida únicamente en los planes de pago Base y Ultimate, no en el plan gratuito Hobby/Community que usa todo este ecosistema desde aws-core-services-guide. No es que LocalStack Hobby "simule mal" la seguridad — es que directamente no incluye el motor que la aplicaría. Las tres guías anteriores pudieron ejecutar casi todo de verdad porque sus temas (declarar HCL, correr un workflow, aplicar un plan) no dependen de esa pieza; los temas centrales de esta guía —¿esta política realmente bloquea esta llamada?— sí dependen de ella.

Resumen y siguiente paso

En esta lección viste el mapa completo de los 8 módulos de esta guía, confirmaste qué se hereda sin repetirse de las tres guías anteriores del ecosistema (andes-cargo-infra/ completo, el pipeline ci.yml/apply.yml/drift.yml, el laboratorio LocalStack), y qué es genuinamente nuevo (siete artefactos de la capa de seguridad, ninguno de negocio). También viste, de entrada, el compromiso de honestidad de esta guía: qué corre de verdad con conftest/Trivy/Checkov/cosign, y qué queda representativo con su razón técnica exacta.

Antes de avanzar deberías poder: nombrar los 8 módulos en orden y qué construye cada uno; explicar por qué este Módulo 1 no construye ningún candado todavía; y decir, sin dudar, la razón técnica exacta detrás de los casos representativos de esta guía.

La lección 2 arranca con la evidencia: qué confirma —y qué no— un plan limpio, un apply exitoso y un pipeline en verde, con el propio ci.yml de Andes Cargo como prueba.

Recursos

terraform-and-iac-guide (NIEVA) — el prerequisito que deja andes-cargo-infra/ completo: doce recursos, dos módulos hijos, el THREAT-MODEL.md de esta guía se construye sobre esa base sin volver a explicarla.
cicd-and-gitops-on-aws-guide (NIEVA) — el prerequisito que deja ci.yml/apply.yml/drift.yml corriendo bajo act, y el .secrets gitignorado que esta guía reemplaza en el Módulo 3.
LocalStack Docs — IAM Policy Enforcement — la fuente exacta de por qué esta guía marca ciertos casos como representativos: "Included in Plans: Base, Ultimate", sin Hobby.
LocalStack — Pricing — cobertura de servicios por plan; IAM, Secrets Manager y SSM confirmados en Hobby, GuardDuty y Config no confirmados.
src/paths/aws-cloud-ecosystem/VALIDACION.md — la auditoría de mercado que fija el peso de esta guía: cadena de suministro en cero en la competencia, OIDC no enseñado en ningún temario revisado.

Siguiente →2. Verde no es sinónimo de seguro