Sécurité, secrets et exploitation sûre

Secrets locaux du projet

Lino enregistre automatiquement les secrets locaux nécessaires à l'application générée. Les mots de passe de base de données, Redis et RabbitMQ, la clé JWT, les API keys et les autres valeurs sensibles restent dans les User Secrets de l'application, au lieu d'être créés dans des fichiers versionnés.

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

Les commandes restent utiles pour la maintenance : utilisez secret list pour auditer les clés configurées, secret set pour modifier ou enregistrer des valeurs locales, secret remove pour supprimer une clé et secret clear pour effacer tous les secrets locaux du projet.

Ce flux est intégré au projet généré. Lorsque vous ajoutez des ressources comme Redis, RabbitMQ, authentification, autorisation, SMTP, API keys ou tokens de téléchargement, Lino garde les valeurs sensibles hors du code source et prépare l'application à les recevoir comme configuration d'environnement.

Vous pouvez aussi inspecter les secrets locaux avec les outils de la plateforme .NET et Aspire, le cas échéant, comme dotnet user-secrets list ou des ressources Aspire équivalentes. La commande Lino existe pour rendre ce flux plus direct dans le contexte du projet généré.

Paramètres dans Aspire

L'AppHost d'Aspire coordonne des ressources comme les bases de données, Redis, RabbitMQ, APIs, workers et web apps. Dans les projets générés, Lino enregistre les valeurs sensibles comme paramètres Aspire afin que l'application les traite comme des dépendances externes, et non comme des données fixes dans le code source.

Cela inclut les mots de passe de base de données, Redis, RabbitMQ et d'autres valeurs nécessaires à l'infrastructure locale. L'AppHost transmet ces paramètres aux ressources correspondantes en utilisant le modèle de secret d'Aspire, par exemple avec des paramètres marqués comme sensibles.

Le gain pratique est que le secret cesse d'être un détail perdu dans des fichiers de configuration et devient une partie du modèle d'exécution de la solution. Quand vous exécutez l'application via Aspire, les services reçoivent les dépendances dont ils ont besoin sans vous demander de copier manuellement des mots de passe dans chaque projet.

Cette conception aide aussi le déploiement. Quand Aspire publie des artefacts, le besoin de ces paramètres demeure : dans Docker Compose, par exemple, des placeholders et fichiers d'environnement peuvent apparaître pour être renseignés dans le bon environnement ; dans d'autres targets, le même principe guide le passage de configuration sensible vers la plateforme.

Rate limiting

Le rate limiting réduit les abus, le brute force et la consommation indue de ressources. Lino configure déjà des policies par défaut et applique des helpers aux endpoints générés afin que les APIs publiques, authentifiées, internes et sensibles ne naissent pas sans limite d'utilisation.

C'est important parce qu'une API peut authentifier correctement et subir tout de même un abus de volume. Login, refresh token, inscription et récupération de mot de passe sont des flux sensibles ; par défaut, Lino les sépare des endpoints courants afin qu'ils aient des limites plus conservatrices.

• Utilisez les policies générées lors de la création de nouveaux endpoints.
• Conservez des limites différentes pour les endpoints sensibles et les endpoints courants.
• Combinez le rate limiting avec l'authentification, la validation et la protection contre les bots si nécessaire.
• Traitez 429 Too Many Requests comme la réponse attendue lorsque la limite est dépassée.

Sécurité JWT

Quand l'authentification est ajoutée, Lino génère la base d'émission, de lecture et de validation des JWT, tout en gardant la clé de signature hors du code source. Le token identifie l'utilisateur et porte les claims essentiels sans transformer le JWT en base de données portable.

• Gardez la clé de signature dans User Secrets en développement et dans un fournisseur sécurisé en production.
• Préservez la validation d'issuer, audience, expiration et algorithme configurée dans le projet.
• Incluez uniquement les claims nécessaires au flux authentifié.
• En multi-tenancy, utilisez le contexte utilisateur et tenant que Lino fournit déjà.

La clé de signature du JWT est un secret critique, et Lino traite déjà cette valeur comme une configuration sensible. Quand vous créez de nouveaux environnements, pipelines ou déploiements, gardez la même règle : la clé ne doit pas apparaître dans un commit, une image Docker, un log, un fichier public ou un exemple réel de configuration.

JWT ne remplace pas non plus l'autorisation dans le domaine. Les claims aident à prendre des décisions, mais les opérations critiques doivent encore considérer l'état actuel, le statut utilisateur, les permissions actives et le contexte de la requête. La partie générée fournit la base ; votre responsabilité en faisant évoluer le système est de ne pas créer de raccourcis qui ignorent ce flux.

API keys et tokens de téléchargement

Lino traite les API keys et les tokens temporaires comme des credentials à portée limitée. Lorsqu'un flux doit libérer un accès temporaire à un fichier, un package ou une intégration, la base générée privilégie des tokens courts et spécifiques au lieu de réutiliser des credentials larges.

• Utilisez une expiration courte pour les liens et tokens temporaires.
• Associez le token à l'utilisateur, au tenant et à la ressource lorsque le flux dispose de ce contexte.
• Enregistrez l'utilisation pour l'audit lorsque l'accès concerne des artefacts sensibles.
• Révoquez les tokens lorsque la ressource ou la permission change.

Les APIs protégées par clé utilisent le modèle d'autorisation et de rate limiting généré par Lino. Une clé créée pour l'automatisation d'intégration ne doit pas devenir un laissez-passer pour les appels administratifs, et un token temporaire de téléchargement ne doit pas remplacer les permissions de l'utilisateur authentifié.

Lorsque vous créez de nouveaux flux de téléchargement ou d'intégration, gardez la même idée : portée explicite, expiration, métadonnées utiles et policy de rate limiting appropriée. Ainsi, l'accès temporaire reste auditable et prévisible, au lieu de devenir un credential libre circulant dans le système.

Fournisseurs de secrets en production

User Secrets résout le développement local. En production, conservez la même séparation en utilisant le fournisseur sécurisé de la plateforme : Azure Key Vault, AWS Secrets Manager, Google Secret Manager, HashiCorp Vault, Kubernetes Secrets ou variables d'environnement protégées par l'orchestrateur.

Lino prépare l'application à recevoir une configuration sensible depuis l'extérieur du code. Le passage en production est une décision d'environnement : les noms et paramètres continuent d'exister, mais les valeurs proviennent du coffre, du pipeline ou de l'orchestrateur utilisé par votre infrastructure.

En production, des pratiques opérationnelles s'ajoutent aussi, comme la rotation, la ségrégation par environnement, les permissions par application et l'audit des accès. User Secrets ne remplace pas ces contrôles ; il couvre l'expérience locale sans placer de secrets dans le dépôt.

• Séparez par environnement : développement, staging et production ne doivent pas partager de credentials.
• Séparez par application : chaque service ne doit recevoir que les secrets dont il a besoin.
• Planifiez la rotation : les clés JWT, SMTP, API keys et mots de passe de base de données ont besoin d'une procédure de remplacement.
• Auditez l'accès : enregistrez qui peut lire ou modifier les secrets sur la plateforme.