Comprendre les risques liés à la journalisation Serilog et C# en production
Serilog est l'un des frameworks les plus populaires pour la journalisation en C#, reconnu pour sa flexibilité, sa prise en charge des données structurées et ses puissants récepteurs. Cependant, cette même flexibilité engendre des risques cachés. Une configuration Serilog trop verbeuse ou mal paramétrée peut exposer involontairement :
- Clés API ou jetons capturés dans les journaux d'exceptions
- Chemins de fichiers internes ou traces de pile révélant des détails d'architecture
- Données sensibles des requêtes/réponses provenant d'API
Ce qui semble être des données de débogage utiles pendant le développement peut se transformer en fuite de données en production.
Lorsque les niveaux de journalisation C# sont définis trop élevés (Verbeux or Déboguer), ils peuvent capturer des informations secrètes provenant de variables d'environnement ou d'objets sérialisés. Ce risque croît de façon exponentielle dans les environnements cloud ou mutualisés où les journaux sont centralisés et partagés entre plusieurs services.
Pièges courants de Serilog pouvant entraîner une exposition des données
Explorons les erreurs de configuration et d'utilisation de Serilog les plus fréquentes qui entraînent une exposition des données dans les projets .NET réels.
1. Enregistrement par défaut des données sensibles
⚠️Exemple non sécurisé, à des fins pédagogiques uniquement. Ne pas utiliser en production.
/ Insecure Serilog usage
Log.Information("User logged in with token {token}", user.Token);
Cela permettra de stocker les jetons d'authentification directement dans vos journaux, souvent récupérables à partir d'agrégateurs de journaux ou de stockage cloud.
Version sécurisée :
// Secure: never log tokens or secrets
Log.Information("User {userId} logged in successfully", user.Id);
Note pédagogique : Filtrez ou masquez les champs sensibles avant de les consigner dans les journaux.
2. Journalisation excessivement verbeuse en production
Les développeurs partent souvent Niveau minimum ajuster à Verbeux en configuration Serilog de production :
⚠️Exemple non sécurisé, à des fins éducatives uniquement :
// Insecure Serilog configuration
.LogLevel.MinimumLevel.Verbose();
Cela peut permettre de capturer les traces de pile, les charges utiles brutes ou les chaînes de connexion.
Version sécurisée :
// Secure Serilog configuration
.MinimumLevel.Information()
.Enrich.FromLogContext();
Note pédagogique : Définissez les niveaux de journalisation sur Infos ou de production supérieure.
3. Données de requête et de réponse non filtrées
Certains développeurs configurent le middleware Serilog pour enregistrer l'intégralité des corps des requêtes/réponses :
⚠️Exemple non sécurisé, à des fins éducatives uniquement :
// Insecure example
app.UseSerilogRequestLogging();
Bien que pratique, cette méthode peut entraîner l'affichage d'en-têtes sensibles ou de charges utiles JSON dans les journaux.
Une approche sûre consiste à implémenter des filtres personnalisés :
app.UseSerilogRequestLogging(options =>
{
options.MessageTemplate = "Handled {RequestPath}";
});
Note pédagogique : Nettoyez toujours les journaux de requêtes et masquez les en-têtes comme Autorisation.
3. Pratiques de journalisation C# non sécurisées CI/CD et Nuage Pipelines
Se connecter CI/CD est tout aussi risqué qu'en productionLorsque les développeurs utilisent la journalisation C# pendant la compilation ou le déploiement, des secrets et des informations d'identification peuvent fuiter dans les journaux.
⚠️Exemple non sécurisé, à des fins éducatives uniquement :
# .github/workflows/deploy.yml
- name: Deploy app
run: dotnet publish /p:ApiKey=$DEPLOY_KEY
env:
DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
# Never expose real tokens, credentials or internal URLs in pipelines
Si la pipeline comprend un Journal.Information() Lors de l'appel à l'impression des valeurs de configuration, Serilog pourrait consigner les informations suivantes : CLÉ_DE_DÉPLOIEMENT involontairement.
Version sécurisée :
- name: Deploy app securely
run: dotnet publish /p:Environment=Production
Note pédagogique : Ne jamais consigner ni afficher les secrets contenus dans les variables d'environnement.
Les plateformes de journalisation centralisées amplifient ce problème. Lorsque les journaux de plusieurs services fusionnent, une simple configuration Serilog mal paramétrée peut exposer des secrets provenant de plusieurs environnements.
Configuration Serilog sécurisée et stratégies de journalisation sûres
Pour configurer Serilog de manière sécurisée, les développeurs doivent traiter les journaux comme faisant partie intégrante de leur environnement. posture de sécuritéIl ne s'agit pas uniquement d'outils de débogage. Voici une liste de vérification pratique pour éviter les fuites de mémoire dans votre configuration de journalisation C#.
Liste de contrôle de sérilog sécurisé
- complet » Niveau minimum à Infos ou de production supérieure.
- Utilisez des filtres pour masquer ou ignorer les propriétés sensibles (par exemple, les mots de passe, les jetons, les en-têtes).
- Évitez d'enregistrer des objets entiers ; enregistrez plutôt les identifiants, les horodatages ou les références hachées.
- Faites pivoter et chiffrez régulièrement les fichiers journaux.
- Utilisez des récepteurs sécurisés (points de terminaison HTTPS, stockage protégé ou services de journalisation dans le cloud).
- Appliquer des limites de rétention pour éviter la surexposition.
Validez la configuration Serilog par une analyse automatisée avant le déploiement.
Exemple de filtrage sécurisé :
var logger = new LoggerConfiguration()
.Filter.ByExcluding(e => e.MessageTemplate.Text.Contains("token"))
.WriteTo.File("logs/app.log", rollingInterval: RollingInterval.Day)
.CreateLogger();
Note pédagogique : Utilisez des filtres et des intervalles glissants pour réduire les risques d’exposition des données.
Automatisation de la validation des journaux et de l'analyse des secrets dans le cadre du DevSecOps
DevSecOps moderne pipelines devrait valider automatiquement la configuration Serilog et le contenu des journaux avant la fusion ou le déploiement. L'automatisation permet de détecter rapidement les schémas de journalisation C# non sécurisés et les fuites de secrets.
Exemple d'intégration :
- name: Run log security validation
run: |
dotnet test --filter Category=LoggingSecurity
xygeni validate --rules logging
# Never expose real tokens or internal URLs in pipelines
Cela garantit :
- Aucun journal ne contient d'identifiants ni de jetons.
- Le niveau de journalisation est approprié à l'environnement.
- Des filtres sont configurés dans chaque profil Serilog.
By intégrer l'analyse des journaux dans CI/CDLes équipes éliminent ainsi l'une des causes les plus courantes, mais souvent négligées, d'exposition des données.
Détection d'exposition secrète avec Xygeni Secrets Security
Xygéni Secrets Security Au-delà des simples expressions régulières ou de la correspondance de modèles, il effectue une analyse contextuelle du code de journalisation Serilog et C# pour découvrir les configurations non sécurisées et les expositions secrètes dans les référentiels, les builds et les environnements.
Xygeni détecte :
- Identifiants ou clés API codés en dur dans les journaux de connexion.
- Journalisation détaillée en production Sérilog fichiers de configuration.
- Exposition de données sensibles via la journalisation structurée.
- Destinations de destination non sécurisées, telles que les fichiers publics ou les transports non chiffrés.
Exemple de commande :
xygeni scan --detect secrets --context serilog
Contrairement aux scanners passifs, Xygéni valide le comportement de journalisation, met en corrélation les résultats avec les métadonnées de déploiement et applique automatiquement les politiques dans CI/CD.
Si des journaux C# non sécurisés ou des modèles Serilog sont détectés, le système bloque l'exécution. commit or pipeline étape par étape, transformant l'hygiène de la journalisation en une barrière de sécurité DevSecOps proactive qui empêche l'exposition des données avant que le code n'atteigne la production.
Note pédagogique : Intégrer Xygéni pre-commit hooks et pipeline Des mesures d'application pour détecter rapidement les vulnérabilités et bloquer automatiquement les configurations non sécurisées.
La journalisation sécurisée fait partie du codage sécurisé.
La journalisation doit améliorer l'observabilité, et non affaiblir la sécurité. Mauvaise configuration Sérilog ou dangereux Journalisation C# peut exposer silencieusement des informations d'identification, des données d'environnement ou des points de terminaison internes.
Pour construire des systèmes plus sûrs :
- Traitez votre Sérilog configuration dans le cadre de votre modèle de menaces.
- Appliquez des filtres, faites pivoter les journaux et contrôlez les niveaux de verbosité.
- Valider les configurations de manière automatisée CI/CD contrôles.
- Utilisez le Xygeni Secrets Security détecter, valider et bloquer en permanence les schémas non sécurisés.
Xygéni détecte les configurations de journalisation non sécurisées, valide les risques d'exposition de secrets et applique une application automatique dans CI/CD pipelines, transformant la connexion sécurisée en un pratique DevSecOps continue qui protège votre code, vos identifiants et vos données dès la conception.
