Configuration, mots de passe et Vault

01

1. Ce qui doit figurer dans le fichier .env

• URL du service, sélection du mode, fuseau horaire, noms des bases de données et autres paramètres non secrets.
• Référence complète de l'image avec résumé si le fichier est un composant à diffusion contrôlée.
• Fonctionnalités que cette version prend explicitement en charge et valide.
• Ne jamais inscrire votre mot de passe réel, votre clé privée, votre jeton d'accès, votre secret client ou votre identifiant de registre dans un fichier versionné Git.

02

2. Agencement recommandé sur l'hôte

/etc/sifybox/
├── env/
│   ├── release.env       # image + digest, bez hesel
│   └── site.env          # URL, režimy a nesekretní parametry
└── secrets/              # root:root, adresář 0700, soubory 0400
    ├── db_password
    └── oidc_client_secret

Remarque : Le fichier .env ne gère pas les secrets. La connexion au registre est assurée par un gestionnaire d'identifiants ou par une authentification Docker gérée avec un jeton de déploiement ; le secret Compose lui-même n'autorise pas le téléchargement d'images. Les données sensibles restent en dehors de Git, avec des permissions minimales et la rotation décrite.

03

3. Variante des secrets Docker

Norme cible — les noms de fichiers et la prise en charge des variables _FILE doivent être confirmés par le manifeste d'une version spécifique.

1. DERS fournira une liste des secrets attendus et une méthode confirmée pour les récupérer.
2. L'administrateur crée chaque secret en dehors de la procédure de paiement et définit la propriété et les autorisations.
3. Compose n'associera un secret qu'au service qui en a besoin.
4. L'application ne doit pas afficher la valeur au démarrage ni en cas d'erreur de validation.
5. La rotation est effectuée conformément au manuel d'exploitation du service et vérifiée par une nouvelle connexion.

04

4. Variante du coffre-fort HashiCorp

Norme cible — la méthode d'authentification, de renouvellement de bail et de rechargement doit être confirmée par le service et la version spécifiques.

1. Le service ou l'agent Vault s'authentifie avec une identité machine liée à un environnement spécifique ; il n'utilise pas de jeton personnel partagé.
2. Cette politique n'autorisera que les chemins et opérations spécifiques nécessaires à un service donné.
3. L'agent Vault écrit le secret dans un fichier tmpfs ou le fournit à l'application via un mécanisme pris en charge.
4. La restauration des données à court terme déclenchera un rechargement pris en charge ou un redémarrage contrôlé.
5. Les journaux d'audit du coffre-fort, les journaux d'audit des applications et les journaux opérationnels sont corrélés sans que la valeur secrète elle-même soit écrite.

05

5. Ordre de chargement et de validation

1. Charger uniquement les valeurs par défaut intégrées à la version pour les options non secrètes.
2. Charger release.env et site.env.
3. Extraire les secrets des fichiers ou de Vault ; la valeur secrète ne possède jamais de valeur par défaut universelle sécurisée.
4. Si une valeur obligatoire est manquante, terminez avant de commencer par le nom du paramètre, et non par son contenu.
5. Imprimer un résumé de configuration expurgé : mode, URL cible, version et source du secret, mais pas le secret lui-même.
6. Effectuez des tests de connectivité et n'acceptez les exigences opérationnelles qu'ensuite.

06

6. Rotation sans réécriture manuelle

• Chaque secret possède un propriétaire, une source, une date d'expiration et une méthode de récupération.
• Les données Dynamic Vault font l'objet d'un bail à renouvellement automatique.
• Les secrets clients OIDC sont modifiés en superposant les anciennes et les nouvelles valeurs, si cela est pris en charge par le fournisseur d'identité et l'application.
• La rotation d'urgence a sa propre procédure et est indépendante de la personne qui a initialement effectué l'installation.
• Après rotation, la fonction de service et l'audit sont vérifiés ; l'ancienne valeur n'est invalidée qu'après confirmation.