Zero trust para APIs internas: cuando el perímetro no basta
Un pod comprometido dentro de la VPC puede llamar a toda API interna que confía solo en la ubicación de red. Zero trust para APIs internas significa que cada llamada service-to-service lleva identidad, autorización acotada y verificación — no solo una IP privada.
La brecha empezó dentro del perímetro. Un runner de CI comprometido, un token de servicio filtrado, un movimiento lateral desde un entorno de staging con rutas de red hacia producción — el atacante nunca tocó el load balancer público. Llamó directamente a APIs internas: http://billing-service.internal/api/v1/invoices, http://user-service.internal/admin/export. Sin autenticación. Sin autorización. Los servicios confiaban en la VPC. Zero trust para APIs internas rechaza esa suposición: la ubicación de red es una conveniencia de transporte, no prueba de identidad ni de intención.
La seguridad perimetral — firewalls, subredes privadas, VPN — mantiene afuera a desconocidos. No impide que insiders comprometidos, servicios mal configurados o atacantes de la cadena de suministro se muevan lateralmente. Las APIs internas son el punto débil de la mayoría de las arquitecturas porque los equipos aseguraron la puerta principal y dejaron las puertas del pasillo abiertas.
El modelo castillo-y-foso falla en east-west
Modelo tradicional: las APIs públicas autentican usuarios; las APIs internas confían en la red.
| Assumption | Reality |
|---|---|
| Solo nuestros servicios llaman APIs internas | Pods comprometidos, herramientas de debug, tráfico mal enrutado |
| El aislamiento VPC equivale a seguridad | Peering, clusters compartidos, staging con rutas a prod |
| Las APIs internas son bajo riesgo | Contienen PII, facturación, acciones de admin |
| mTLS es complejidad opcional | Es identidad criptográfica base para service-to-service |
El tráfico east-west — servicio A llamando a servicio B dentro del mismo cluster — suele superar en volumen al tráfico north-south. Asegurar solo el ingress ignora la mayor parte de la superficie de ataque.
"Es interno" no es un modelo de autorización. Es la ausencia de uno.
Los scopes OAuth y el diseño de autorización aplican también a servicios internos: un servicio de facturación que llama a user-service debe presentar credenciales acotadas exactamente a lo que necesita — no un god-token que lee todo registro de usuario porque "es todo interno".
Principios de zero trust para APIs internas
Zero trust no es un producto. Es un conjunto de restricciones aplicadas de forma consistente:
1. Nunca confiar, siempre verificar
Cada request — incluido service-to-service — debe presentar identidad verificable. Opciones: mTLS con certificados de servicio, JWTs firmados con TTL corto, identidad de workload SPIFFE/SPIRE. El caller demuestra quién es; el callee verifica antes de ejecutar.
2. Mínimo privilegio por llamada
La autorización no es binaria "interno vs externo". Una service account del worker de notificaciones obtiene users:read:email en user-service — no users:admin. El diseño de scopes refleja OAuth externo: grants estrechos, auditables, revocables.
3. Asumir brecha
Diseñar para que un servicio comprometido no pueda exfiltrar todo el datastore. Rate limits en endpoints sensibles, audit logs en rutas de admin, segmentación para que billing no llame rutas arbitrarias de user-service.
4. Cifrar y autenticar en tránsito
TLS en todas partes — incluso dentro del cluster. HTTP plano en *.cluster.local es conveniente y legible por cualquier proceso con acceso de red en el namespace.
5. Verificación continua
Credenciales de corta duración. Rotación de certificados. Revocación cuando un servicio se da de baja o se compromete. API keys estáticas de larga duración en variables de entorno son el equivalente interno de reutilizar contraseñas.
Capas de implementación, de pragmática a integral
Los equipos adoptan zero trust de forma incremental. Las capas se apilan:
| Layer | Mechanism | Effort | Coverage |
|---|---|---|---|
| Network policy | Kubernetes NetworkPolicy, security groups | Low | Limita qué pods hablan; sin identidad |
| mTLS | Service mesh (Istio, Linkerd) o cert-manager por servicio | Medium | Identidad criptográfica del caller |
| Token auth | JWT o token opaco por request, validado en gateway/sidecar | Medium | Identidad + scopes opcionales |
| Policy engine | OPA, Cedar, RBAC custom en capa API | Medium–High | Autorización granular |
| Service mesh policy | mTLS + políticas de autorización en mesh | High | East-west de punta a punta |
Punto de partida para la mayoría de equipos: autenticar llamadas internas antes de optimizar policy engines. Un API gateway interno compartido que valida JWTs de servicio supera a un mesh que nadie configuró bien.
Network policy sola es necesaria pero insuficiente — responde "¿puede el pod A alcanzar el puerto del pod B?" no "¿debería permitirse este request concreto?".
Anti-patrones comunes en APIs internas
God service tokens. Una INTERNAL_API_KEY en doce servicios. Comprometer una, controlar todas. Credenciales por servicio con permisos acotados.
Rutas admin sin auth admin. /internal/admin/reindex invocable desde cualquier pod del namespace. Superficie admin separada, auth más fuerte, audit log.
Confiar en X-Forwarded-User de callers internos. Cualquier servicio puede falsificar headers. La identidad de usuario debe venir de tokens validados, no de headers confiables en saltos internos.
Omitir auth en clusters "dev" que replican topología prod. Staging con datos de producción y sin auth interna es una brecha esperando un clic erróneo.
Cadena de suministro como caller interno. Webhooks de terceros e integraciones SaaS suelen aterrizar en colas internas. Tratarlos como no confiables hasta verificar — relacionado con ataques de cadena de suministro que apuntan a la confianza.
¿Cómo deberían desplegar zero trust para APIs internas los equipos?
Estas preguntas delimitan el primer sprint frente al programa completo.
¿Se requiere mTLS en cada llamada interna?
No siempre el día uno. Mínimo: alguna identidad criptográfica en rutas sensibles (facturación, PII, admin). Expandir a mTLS completo a medida que madura el mesh o la infra de certificados. Llamadas HTTP internas planas a endpoints de health de solo lectura tienen menor prioridad que llamadas que mutan estado financiero.
¿Cómo funcionan los scopes en llamadas service-to-service?
Reflejar OAuth de usuario: emitir service tokens con audience (aud), issuer (iss), scopes (billing:invoice:read) y expiración corta. El callee valida todos los claims. Documentar qué servicios pueden tener qué scopes — la misma disciplina que diseño de scopes OAuth.
¿Qué pasa con servicios legacy que no pueden añadir auth rápido?
API gateway o sidecar proxy delante del servicio legacy: terminar mTLS, inyectar header de identidad validada (firmado por gateway, no falsificable), el servicio legacy confía solo en requests originados en el gateway. Patrón puente hasta que exista auth nativa.
Una visión opuesta
La postura contraria sostiene que zero trust en APIs internas añade latencia, carga operativa y fricción de debugging — que el aislamiento VPC y las network policies bastan para equipos sin adversarios de nivel estatal.
El costo operativo es real. También lo es el movimiento lateral tras una sola credencial comprometida — algo que le pasa a startups y enterprises por igual. Zero trust pragmático empieza en rutas de alto valor: APIs admin, exports de PII, mutaciones de pago. El mesh completo puede esperar; "sin auth porque es interno" no puede.
La fricción de debug se gestiona con identidad de servicio en traces y audit logs estructurados — saber qué servicio llamó a qué endpoint es más fácil con identidad que con tráfico interno anónimo.
Lo que importa recordar
- La pertenencia a VPC no es identidad — verificar cada llamada a API interna.
- El tráfico east-west necesita la misma disciplina de auth que las APIs públicas.
- Los scopes de mínimo privilegio aplican a service accounts, no solo a usuarios.
- mTLS o tokens firmados son baseline; network policy sola es insuficiente.
- God internal API keys son un único punto de compromiso.
- Desplegar primero en rutas sensibles; puentear legacy con proxies de gateway.
Conclusión
El perímetro mantuvo afuera a atacantes hasta que uno entró. APIs internas diseñadas para trust-on-network se convierten en autopistas de movimiento lateral. Zero trust para APIs internas significa que cada llamada responde: ¿quién llama, tienen permiso para hacer esto, y el canal está protegido en integridad?
La auditoría empieza con inventario: listar endpoints internos, marcar cuáles requieren auth hoy, marcar cuáles contienen datos sensibles. La brecha entre esas listas es el roadmap. Cerrarla antes del compromiso, no después.