Seguridad, secrets y operación segura

Secrets locales del proyecto

Lino registra automáticamente los secrets locales necesarios para la aplicación generada. Las contraseñas de base de datos, Redis y RabbitMQ, la clave JWT, las API keys y otros valores sensibles quedan en User Secrets de la aplicación, en lugar de nacer en archivos versionados.

lino secret list
lino secret set
lino secret remove
lino secret clear

Los comandos siguen siendo útiles para mantenimiento: use secret list para auditar claves configuradas, secret set para cambiar o registrar valores locales, secret remove para eliminar una clave y secret clear para limpiar todos los secrets locales del proyecto.

Este flujo está integrado con el proyecto generado. Cuando agrega recursos como Redis, RabbitMQ, autenticación, autorización, SMTP, API keys o tokens de descarga, Lino mantiene los valores sensibles fuera del código fuente y prepara la aplicación para recibirlos como configuración de entorno.

También puede inspeccionar secrets locales con herramientas de la plataforma .NET y Aspire, cuando corresponda, como dotnet user-secrets list o recursos equivalentes de Aspire. El comando de Lino existe para hacer este flujo más directo dentro del contexto del proyecto generado.

Parámetros en Aspire

El AppHost de Aspire coordina recursos como bases de datos, Redis, RabbitMQ, APIs, workers y web apps. En los proyectos generados, Lino registra valores sensibles como parámetros de Aspire para que la aplicación trate esos valores como dependencias externas, no como datos fijos en el código fuente.

Esto incluye contraseñas de base de datos, Redis, RabbitMQ y otros valores necesarios para la infraestructura local. El AppHost pasa estos parámetros a los recursos correspondientes usando el modelo de secrets de Aspire, por ejemplo con parámetros marcados como sensibles.

La ganancia práctica es que el secret deja de ser un detalle perdido en archivos de configuración y pasa a formar parte del modelo de ejecución de la solución. Al ejecutar la aplicación con Aspire, los servicios reciben las dependencias que necesitan sin exigir que copie contraseñas manualmente en cada proyecto.

Este diseño también ayuda al deploy. Cuando Aspire publica artefactos, la necesidad de estos parámetros sigue existiendo: en Docker Compose, por ejemplo, pueden aparecer placeholders y archivos de entorno que deben completarse en el ambiente correcto; en otros targets, el mismo principio orienta el paso de configuración sensible a la plataforma.

Rate limiting

Rate limiting reduce abuso, brute force y consumo indebido de recursos. Lino ya configura policies predeterminadas y aplica helpers en los endpoints generados para que las APIs públicas, autenticadas, internas y sensibles no nazcan sin límite de uso.

Esto importa porque una API puede autenticar correctamente y aun así sufrir abuso de volumen. Login, refresh token, registro y recuperación de contraseña son flujos sensibles; por defecto, Lino los separa de endpoints comunes para que tengan límites más conservadores.

• Use las policies generadas al crear endpoints nuevos.
• Mantenga límites diferentes para endpoints sensibles y endpoints comunes.
• Combine rate limiting con autenticación, validación y protección contra bots cuando sea necesario.
• Trate 429 Too Many Requests como respuesta esperada cuando se exceda el límite.

Seguridad en JWT

Cuando se agrega autenticación, Lino genera la base para emitir, leer y validar JWT, manteniendo la clave de firma fuera del código fuente. El token identifica al usuario y carga claims esenciales sin convertir el JWT en una base de datos portátil.

• Mantenga la clave de firma en User Secrets durante el desarrollo y en un proveedor seguro en producción.
• Preserve la validación de issuer, audience, expiración y algoritmo configurada en el proyecto.
• Incluya solo los claims necesarios para el flujo autenticado.
• En multi-tenancy, use el contexto de usuario y tenant que Lino ya proporciona.

La clave de firma del JWT es un secret crítico, y Lino ya trata este valor como configuración sensible. Al crear nuevos ambientes, pipelines o deploys, mantenga la misma regla: la clave no debe aparecer en commits, imágenes Docker, logs, archivos públicos ni ejemplos reales de configuración.

JWT tampoco reemplaza la autorización en el dominio. Los claims ayudan a tomar decisiones, pero las operaciones críticas todavía necesitan considerar el estado actual, el estado del usuario, los permisos activos y el contexto de la solicitud. La parte generada proporciona la base; su responsabilidad al evolucionar el sistema es no crear atajos que ignoren este flujo.

API keys y tokens de descarga

Lino trata API keys y tokens temporales como credenciales de alcance limitado. Cuando un flujo necesita liberar acceso temporal a un archivo, paquete o integración, la base generada favorece tokens cortos y específicos en lugar de reutilizar credenciales amplias.

• Use expiración corta para links y tokens temporales.
• Asocie el token al usuario, tenant y recurso cuando el flujo tenga ese contexto.
• Registre el uso para auditoría cuando el acceso involucre artefactos sensibles.
• Revoque tokens cuando cambie el recurso o el permiso.

Las APIs protegidas por clave usan el modelo de autorización y rate limiting generado por Lino. Una clave creada para automatización de integración no debe convertirse en pase libre para llamadas administrativas, y un token temporal de descarga no debe reemplazar los permisos del usuario autenticado.

Al crear nuevos flujos de descarga o integración, mantenga la misma idea: alcance explícito, expiración, metadatos útiles y policy de rate limiting adecuada. Así el acceso temporal sigue siendo auditable y previsible, en lugar de convertirse en una credencial suelta circulando por el sistema.

Proveedores de secrets en producción

User Secrets resuelve el desarrollo local. En producción, mantenga la misma separación usando el proveedor seguro de la plataforma: Azure Key Vault, AWS Secrets Manager, Google Secret Manager, HashiCorp Vault, Kubernetes Secrets o variables de entorno protegidas por el orquestador.

Lino prepara la aplicación para recibir configuración sensible desde fuera del código. El paso a producción es una decisión de ambiente: los nombres y parámetros siguen existiendo, pero los valores pasan a venir del vault, pipeline u orquestador usado por su infraestructura.

En producción también entran prácticas operativas como rotación, segregación por ambiente, permisos por aplicación y auditoría de acceso. User Secrets no reemplaza esos controles; cubre la experiencia local sin poner secrets en el repositorio.

• Separe por ambiente: desarrollo, staging y producción no deben compartir credenciales.
• Separe por aplicación: cada servicio debe recibir solo los secrets que necesita.
• Planifique rotación: claves JWT, SMTP, API keys y contraseñas de base de datos necesitan un procedimiento de cambio.
• Audite acceso: registre quién puede leer o cambiar secrets en la plataforma.