Seguridad por capas en una aplicación Azure
La seguridad de una aplicación no debe depender de que una única tecnología esté configurada perfectamente. Cada capa reduce una parte del riesgo y limita el impacto si otra falla.
En IXATU Operations, la ruta prevista puede representarse así:
Usuario
↓
Microsoft Entra
↓
Web protegida
↓
API no pública
↓
red
↓
principal SQL mínimo
↓
queries SELECT
↓
Azure SQLAlrededor aparecen controles laterales: referencias a secretos, Managed Identity, AcrPull, promoción por digest, logs y aprobación humana.
Autenticación no es autorización
Microsoft Entra puede demostrar la identidad de una persona. Easy Auth puede proteger la entrada web y exigir un inicio de sesión válido.
Pero autenticación no es autorización. Saber quién es alguien no decide qué operaciones puede realizar ni a qué datos debe acceder.
La aplicación necesita reglas de autorización propias o claims adecuados para las capacidades que expone. Un usuario autenticado no recibe por defecto acceso administrativo o de producción.
Single-tenant no es una lista de personas
Configurar una aplicación como single-tenant limita las identidades a un directorio previsto. Es una frontera valiosa frente a cuentas de otros tenants.
Pero single-tenant no es una allowlist de personas. Puede haber muchas identidades válidas en ese directorio que no deban usar la aplicación.
La autorización debe expresar quién, qué rol o qué grupo puede entrar. Cuando la operación sea sensible, debe expresar además qué acción concreta puede ejecutar.
La web es la entrada pública prevista
Una web puede tener ingress external porque debe ser alcanzable por usuarios. Public network describe conectividad; public network no significa acceso anónimo.
Easy Auth, Entra y las reglas de aplicación siguen protegiendo la petición. La exposición de red no reemplaza esos controles, igual que la autenticación no vuelve privada la red.
Separar la web de la API permite publicar sólo la superficie necesaria. La web sirve la interfaz; la API conserva permisos y contratos distintos.
API internal reduce superficie
El ingress internal de Azure Container Apps evita una entrada pública directa y mantiene la API dentro de la topología prevista.
Sin embargo, internal ingress no garantiza un caller exclusivo. Otros actores con conectividad pueden alcanzar esa superficie si no existen controles adicionales.
La red responde desde dónde puede llegar tráfico. La identidad y la autorización responden quién llama y qué puede hacer. Las tres preguntas necesitan respuestas explícitas.
El artículo Docker, ACR y Container Apps desarrolla el papel del environment, los tipos de ingress y la separación entre web y API.
Managed Identity elimina secretos, no permisos
Managed Identity permite que un recurso de Azure obtenga tokens sin almacenar credenciales de larga duración en el código.
La identidad sigue necesitando roles. AcrPull le permite descargar una imagen de ACR; no debería conceder push ni administración si el runtime sólo necesita leer.
La misma disciplina se aplica a otros servicios. Eliminar una contraseña mejora el mecanismo, pero un rol excesivo sigue siendo autoridad excesiva.
Secretos fuera del código
Connection strings, tokens y claves no deben residir en Git, Dockerfiles ni imágenes. La plataforma puede mantenerlos como secrets y exponer referencias sólo al contenedor autorizado.
Los logs tampoco deben reconstruirlos. Una comprobación de configuración puede informar qué campo falta sin imprimir su valor.
Separar secrets por entorno evita que DEV necesite autoridad sobre PROD. También permite rotarlos sin reconstruir la imagen.
Read-only es una combinación de capas
El código puede limitar la API a consultas y usar ApplicationIntent=ReadOnly. Ninguna de esas decisiones equivale a un permiso de base de datos.
ApplicationIntent=ReadOnly no es permiso SQL. La última barrera debe ser un principal autorizado sólo para los SELECT necesarios.
Los SELECT explícitos reducen superficie y documentan datos usados. El adapter y la Anti-Corruption Layer impiden que el modelo histórico se extienda por toda la aplicación.
El artículo sobre la BBDD legacy desarrolla esta frontera, incluidos ODBC, Pydantic, mínimo privilegio y el Attention Board como discovery.
El artefacto también forma parte de la seguridad
Una imagen validada en DEV debe llegar a PROD por digest. Reconstruirla después de aprobarla rompe la cadena de evidencia.
Managed Identity y AcrPull controlan cómo el runtime obtiene ese artefacto. Entornos aislados y permisos de promoción controlan quién puede cambiar la revisión ejecutada.
La aprobación humana es un gate deliberado. La automatización prepara evidencia; una persona con autoridad acepta la mutación de PROD cuando el riesgo lo exige.
Qué ocurre cuando falla una capa
Si Easy Auth queda mal configurado, la autorización de aplicación todavía debe rechazar acciones no permitidas.
Si una ruta alcanza la API, el ingress, la identidad y sus contratos deben reducir lo que puede invocar.
Si un defecto intenta escribir, el principal SQL read-only debe denegar la operación.
Si un secreto aparece en un proceso indebido, sus permisos y alcance por entorno deben limitar el daño. La rotación debe poder invalidarlo sin reconstruir software.
Si una etiqueta se mueve, el despliegue por digest debe conservar el artefacto aprobado. Si una automatización propone cambiar PROD, el gate humano debe poder detenerla.
Defense in depth no promete que todas las barreras sean infalibles. Evita que una sola equivocación conceda de inmediato toda la autoridad del sistema.
Fronteras humanas para producción
Una lectura, un despliegue y una mutación de datos no tienen el mismo riesgo. La herramienta usada no determina la autorización necesaria; la determina el efecto.
La automatización web puede validar una ruta o preparar una operación. Cuando atraviesa MFA, cambia configuración o afecta datos de PROD, necesita supervisión, evidencia y autorización explícita.
Los logs deben registrar qué artefacto, identidad y decisión participaron sin incluir tokens, cookies o datos privados. La trazabilidad útil no requiere publicar secretos.
Ninguna capa sola es suficiente
Entra identifica. La autorización decide. El ingress y la red reducen exposición. Managed Identity evita credenciales estáticas. Los roles limitan autoridad. SQL aplica el mínimo privilegio.
Las consultas explícitas reducen datos, el digest fija el artefacto y la aprobación humana gobierna operaciones sensibles. Cada control responde a un fallo distinto.
La arquitectura segura no busca una caja con la etiqueta correcta. Busca una cadena donde el error de una capa encuentre otra frontera antes de alcanzar el activo que protegemos.