Vue d'ensemble

Recommandations générales pour stocker les mots de passe de manière sécurisée

Si un mot de passe doit être stocké dans un fichier de configuration, il est essentiel de restreindre l'accès au fichier aux seuls utilisateurs autorisés et d'empêcher toute consultation accidentelle qui pourrait exposer des secrets en clair. À partir de la version 3.6.0 du Wrapper, le Wrapper effectue une vérification de sécurité sur les fichiers contenant des données sensibles afin de s'assurer que leurs permissions de fichier sont suffisamment restrictives.

Pour protéger correctement vos données et aider le Wrapper à identifier les fichiers sensibles, suivez ces bonnes pratiques :

Tout d'abord, isolez vos mots de passe dans un fichier d'inclusion dédié, qui ne doit être ouvert que lors de la mise à jour des mots de passe, et non lors des modifications courantes de la configuration. Le Wrapper vérifiera les permissions de ce fichier d'inclusion. Pour garantir que le fichier est vérifié dès le premier lancement et pour déclencher une erreur s'il est manquant ou spécifié avec un chemin incorrect, utilisez la directive @include.required (ou définissez @include.default_mode=required).

Le processus Wrapper a besoin d'un accès en lecture pour charger votre fichier d'inclusion, assurez-vous donc que le compte utilisateur exécutant le Wrapper dispose des permissions de lecture appropriées. Idéalement, accordez l'accès en lecture strictement à ce compte, et limitez la connexion interactive de ce compte aux administrateurs uniquement. Sous Unix, la variable RUN_AS_USER du script Shell peut être utilisée pour s'exécuter avec un utilisateur de substitution. Sous Windows, la propriété wrapper.ntservice.account peut être définie pour spécifier le compte à utiliser lors de l'exécution en tant que service.

Enfin, le Wrapper prend en charge une notation « cipher » pour marquer une valeur de propriété (ou une partie de celle-ci) comme sensible. Cette notation commence par un délimiteur d'ouverture « % », suivi du texte sensible (qui peut éventuellement être obfusqué), d'une barre verticale (« | »), de l'identifiant de la méthode de traitement ou de décodage, et d'un délimiteur de fermeture « % ». Consultez Encoder les mots de passe et les données sensibles pour des informations détaillées sur cette notation et sur la façon de la générer avec l'une des méthodes d'obfuscation disponibles. L'utilisation de cette notation cipher est essentielle pour un traitement sécurisé : elle empêche les valeurs sensibles d'apparaître en clair dans les fichiers journaux ou les lignes de commande Java, et sert également de marqueur déclenchant une vérification des permissions du fichier contenant.

NOTE

Comment le Wrapper aide-t-il à vérifier les permissions des fichiers ?

La version 3.6.0 du Wrapper dispose d'un mécanisme pour aider à définir des permissions appropriées sur les fichiers contenant des données sensibles.

À chaque démarrage du Wrapper, les fichiers suivants seront vérifiés :

  • fichiers de configuration contenant des valeurs masquées ou obfusquées (avec la notation %...|<cipher_name>%)
  • fichiers de paramètres contenant des valeurs masquées ou obfusquées (avec la notation %...|<cipher_name>%)
  • fichiers sécurisés supplémentaires listés avec les propriétés wrapper.secure_file.additional.<n> (édition Standard)

La gestion des permissions de fichier fonctionne de manière assez différente entre Windows et Unix, et donc la façon dont le Wrapper vérifie les permissions diffère également selon la plateforme :

  • Sous Windows, les permissions de fichier peuvent être accordées à une liste illimitée d'utilisateurs ou de groupes. Le Wrapper adopte une approche stricte en exigeant que tous les utilisateurs disposant de permissions sur le fichier soient explicitement autorisés dans le fichier de configuration du Wrapper.

    De plus, certains utilisateurs considérés comme non sécurisés sont mis sur liste noire et ne peuvent pas être autorisés (voir la section ci-dessous).

  • Sous Unix, les permissions de fichier peuvent être définies pour trois classes différentes : le propriétaire, le groupe et les autres utilisateurs.

    Le Wrapper a des politiques de sécurité différentes pour chaque classe :

    • Il n'y a aucune restriction pour le « propriétaire ». Il peut s'agir de n'importe qui avec n'importe quelles permissions.

    • Si la classe « groupe » a un mode lecture-écriture, le nom du groupe doit être explicitement autorisé dans le fichier de configuration du Wrapper.

      De plus, certains groupes trop larges sont mis sur liste noire et ne peuvent pas être autorisés (voir la section ci-dessous).

    • La classe « autres » doit toujours avoir un mode ni en lecture ni en écriture (zéro).

NOTE

On peut légitimement se poser la question suivante : N'est-ce pas une faille de sécurité qu'une simple propriété de configuration puisse autoriser un utilisateur ou un groupe arbitraire à accéder à un fichier sécurisé ?

Eh bien, il est important de comprendre que l'autorisation d'un compte spécifique dans la configuration ne modifie pas les permissions réelles des fichiers. Les propriétés wrapper.secure_file.check.windows.allowed_account.<n> sont conçues pour détecter les problèmes avant même le démarrage du Wrapper et vous aider à corriger les permissions de fichier le plus tôt possible lors de la première configuration. Même si un attaquant ajoutait son propre compte plus tard, cela ne modifierait pas les permissions réelles du fichier, qui à ce stade devraient déjà avoir été configurées correctement.


Veuillez utiliser les propriétés suivantes pour autoriser explicitement des comptes ou des groupes dans votre fichier de configuration :


Lorsqu'un fichier se trouve sur un volume dont le format ne prend pas en charge les permissions de fichier, les vérifications de sécurité ci-dessus ne peuvent pas être effectuées. Par défaut, de tels volumes sont considérés comme non sécurisés, mais ce comportement peut être modifié avec les propriétés suivantes :


Si l'une des conditions ci-dessus n'est pas remplie pour l'un des fichiers vérifiés, le comportement par défaut du Wrapper est d'afficher des messages indiquant comment les permissions doivent être ajustées, puis de s'arrêter.

Ce comportement peut toutefois être personnalisé avec les propriétés suivantes :


Les éditions Standard et Professional fournissent les propriétés suivantes pour lister des fichiers supplémentaires dont les permissions doivent également être vérifiées :

Propriété wrapper.secure_file.check.windows.allowed_account.<n>
Compatibilité :3.6.0
Éditions :Édition ProfessionnelleÉdition StandardÉdition Community
Plateformes :WindowsMac OSX (Non pris en charge)Linux (Non pris en charge)Alpine Linux (Non pris en charge)FreeBSD (Non pris en charge)Solaris (Non pris en charge)IBM z/Linux (Non pris en charge)

Ces propriétés peuvent être utilisées pour spécifier une liste de comptes autorisés lors de la vérification des permissions des fichiers sécurisés sous Windows.

Par souci de simplicité, ces propriétés s'appliquent à tous les fichiers sécurisés. Ainsi, si différents fichiers accordent des permissions à différents comptes, ces propriétés doivent former une liste commune de comptes autorisés pour tous les fichiers sécurisés.

Le nom du compte doit être écrit au format : {DomainName}\{UserName}.

Si le compte appartient au domaine intégré (local), vous pouvez spécifier le nom d'utilisateur au format : .\{UserName}.
Cette notation rend votre configuration plus portable lors du déploiement sur plusieurs machines.

Notez que les comptes suivants sont intrinsèquement non sécurisés et ne peuvent pas être autorisés :

  • Everyone

  • ANONYMOUS LOGON

  • Authenticated users

  • Guests

  • Users

Supposons qu'un fichier contenant des mots de passe ait été créé avec des permissions pour NT AUTHORITY\SYSTEM, BUILTIN\Administrators et DESKTOP-06SJR11\john. Comme le fichier contient des mots de passe, il est considéré comme sensible et le journal suivant sera affiché :

Sortie du Wrapper : 
wrapper  | The file 'C:\mayapp\conf\wrapper.conf' contains sensitive data but its permissions are too open.
wrapper  |   Problematic Permissions:
wrapper  |     NT AUTHORITY\SYSTEM    : Either allow this account in the configuration or remove the read and write file permissions.
wrapper  |     BUILTIN\Administrators : Either allow this account in the configuration or remove the read and write file permissions.
wrapper  |     DESKTOP-06SJR11\john   : Either allow this account in the configuration or remove the read and write file permissions.
wrapper  |
wrapper  |   If you want to run the Wrapper as a Windows Service, please add '.\LocalSystem' to the list of allowed accounts.
wrapper  |   If you want to run the Wrapper as a Console Application, please add 'DESKTOP-06SJR11\john' to the list of allowed accounts.
wrapper  |
wrapper  |   The Wrapper will stop.

La première action à entreprendre est de supprimer toutes les permissions qui ne sont pas nécessaires : cliquez avec le bouton droit sur le fichier, sélectionnez Propriétés, allez dans l'onglet Sécurité, cliquez sur Modifier, sélectionnez un utilisateur ou un groupe, cliquez sur Supprimer. Par exemple, vous pouvez supprimer « john ».

Si les permissions restantes sont nécessaires, vous devrez les autoriser explicitement dans la configuration du Wrapper comme suit :

Exemple : 
wrapper.secure_file.check.windows.allowed_account.1=NT AUTHORITY\SYSTEM
wrapper.secure_file.check.windows.allowed_account.2=BUILTIN\Administrators

Après le redémarrage du Wrapper, le message ne devrait plus apparaître et il devrait démarrer votre application normalement.


AVERTISSEMENT

Windows a souvent l'héritage des permissions activé. Cela signifie que si un fichier est créé, il héritera automatiquement des permissions de son dossier parent. Des permissions supplémentaires peuvent être ajoutées, mais toute tentative de suppression d'une permission héritée entraînera le message suivant :

Pour supprimer une permission héritée, vous devez soit stocker le fichier dans un dossier parent dont l'héritage des permissions est désactivé, soit désactiver l'héritage des permissions pour le fichier lui-même.

Propriété wrapper.secure_file.check.unix.allowed_group.<n>
Compatibilité :3.6.0
Éditions :Édition ProfessionnelleÉdition StandardÉdition Community
Plateformes :Windows (Non pris en charge)Mac OSXLinuxAlpine LinuxFreeBSDSolarisIBM z/Linux

Ces propriétés peuvent être utilisées pour spécifier une liste de groupes autorisés lors de la vérification des permissions des fichiers sécurisés sur les systèmes Unix.

La propriété de groupe ne peut être définie que pour un seul groupe sur un système Unix, mais ces propriétés forment une liste de groupes autorisés pour tous les fichiers sécurisés. Si vous devez autoriser plusieurs groupes pour des fichiers sécurisés distincts, vous pouvez les lister en ajoutant autant de propriétés wrapper.secure_file.check.unix.allowed_group.<n> que nécessaire, en n'oubliant pas d'incrémenter l'index <n> pour chaque groupe.

Notez que les groupes suivants sont trop larges et donc non autorisés :

  • users

  • other

  • everyone

  • staff

Supposons qu'un fichier contenant des mots de passe ait été créé avec la propriété et les permissions suivantes :

ls -la ../conf/wrapper-secure.conf 
-rw-rw-r-- 1 john team 9489 Nov 21 17:00 ../conf/wrapper-secure.conf
Sortie du Wrapper : 
wrapper  | The file '/home/john/wrapper/conf/wrapper.conf' contains sensitive data but its permissions are too open.
wrapper  |   Problematic Permissions:
wrapper  |     Permission '04' ('r--') was granted to others. It must be '00'.
wrapper  |     Permission '060' ('rw-') was granted to group 'team' but this group was not allowed in the configuration.
wrapper  | 
wrapper  |   When the Wrapper is intended to be run by a single user, it is best to set the
wrapper  |    ownership of secured files to that user and remove all other permissions.
wrapper  |    To allow multiple users to access your secure files, you can grant read
wrapper  |    permissions to a group that only a restricted list of users belong to,
wrapper  |    but this group must be explicitly allowed in the Wrapper configuration.
wrapper  | 
wrapper  |   The Wrapper will stop.

La première action à entreprendre est de supprimer les permissions pour la classe « other », par exemple en utilisant la commande suivante : chmod o-r ../conf/wrapper.conf.

Dans la plupart des cas, les permissions de groupe devraient également être supprimées, mais des scénarios tels que plusieurs utilisateurs appartenant au même groupe et autorisés à exécuter le Wrapper sont possibles. Si les permissions pour le groupe « team » doivent être conservées, vous pouvez l'ajouter à la liste des groupes autorisés en utilisant la configuration suivante :

Exemple : 
wrapper.secure_file.check.unix.allowed_group.1=team

Après le redémarrage du Wrapper, le message ne devrait plus apparaître et il devrait démarrer votre application normalement.

Propriété wrapper.secure_file.check.windows.allow_unsecured_volumes
Compatibilité :3.6.0
Éditions :Édition ProfessionnelleÉdition StandardÉdition Community
Plateformes :WindowsMac OSX (Non pris en charge)Linux (Non pris en charge)Alpine Linux (Non pris en charge)FreeBSD (Non pris en charge)Solaris (Non pris en charge)IBM z/Linux (Non pris en charge)

Cette propriété permet de stocker des fichiers contenant des données sensibles sur des volumes dont le format ne prend pas en charge les permissions de fichier.

Sous Windows, les systèmes de fichiers tels que FAT32 ou exFAT ne prennent pas en charge les permissions de fichier. Cela signifie que quiconque a accès au volume peut accéder aux fichiers qu'il contient.

Sauf si vous savez que l'accès au volume lui-même est sécurisé (par exemple, lorsqu'il n'est monté que par des utilisateurs autorisés), il est recommandé de stocker les fichiers contenant des données sensibles sur un volume avec un système de fichiers (comme « NTFS ») qui prend en charge les permissions et de restreindre ces permissions à l'essentiel.

Par défaut, le stockage de fichiers sensibles sur des volumes non sécurisés n'est pas autorisé (la valeur par défaut est FALSE).

Si un fichier sensible est trouvé sur un volume non sécurisé, le Wrapper affichera le message suivant puis s'arrêtera :

Sortie du Wrapper : 
wrapper  | The file 'A:\wrapper-secret.conf' is located on a volume whose format does not support file permissions. Anyone with access to the volume can read the file.
wrapper  |   Use 'wrapper.secure_file.check.windows.allow_unsecured_volumes=TRUE' or move the file to a different volume.
wrapper  |
wrapper  |   The Wrapper will stop.

Le Wrapper n'affichera plus ce message et sera autorisé à démarrer si wrapper.secure_file.check.windows.allow_unsecured_volumes est défini à TRUE.

Exemple (autoriser le stockage de fichiers sensibles sur des volumes non sécurisés) : 
wrapper.secure_file.check.windows.allow_unsecured_volumes=TRUE

Propriété wrapper.secure_file.check.unix.allow_unsecured_volumes
Compatibilité :3.6.0
Éditions :Édition ProfessionnelleÉdition StandardÉdition Community
Plateformes :Windows (Non pris en charge)Mac OSXLinuxAlpine Linux (Non pris en charge)FreeBSDSolaris (Non pris en charge)IBM z/Linux

Cette propriété permet de stocker des fichiers contenant des données sensibles sur des volumes dont le format ne prend pas en charge les permissions de fichier.

Sur les systèmes Unix, les systèmes de fichiers tels que FAT32 ou NTFS ne prennent pas en charge les permissions de fichier. Cela signifie que quiconque a accès au volume peut accéder aux fichiers qu'il contient. C'est le cas, par exemple, des volumes hébergés sur un serveur Windows et partagés avec des systèmes Linux.

Sauf si vous savez que l'accès au volume lui-même est sécurisé (par exemple, lorsqu'il n'est monté que par des utilisateurs autorisés), il est recommandé de stocker les fichiers contenant des données sensibles sur un volume avec un système de fichiers (comme « ext4 ») qui prend en charge les permissions et de restreindre ces permissions à l'essentiel.

Par défaut, le stockage de fichiers sensibles sur des volumes non sécurisés n'est pas autorisé (la valeur par défaut est FALSE).

Si un fichier sensible est trouvé sur un volume non sécurisé, le Wrapper affichera le message suivant puis s'arrêtera :

Sortie du Wrapper : 
wrapper  | The file '/mnt/myvolume/wrapper-secret.conf' is located on a volume whose format does not support file permissions. Anyone with access to the volume can read the file.
wrapper  |   Use 'wrapper.secure_file.check.unix.allow_unsecured_volumes=TRUE' or move the file to a different volume.
wrapper  | 
wrapper  |   The Wrapper will stop.

Le Wrapper n'affichera plus ce message et sera autorisé à démarrer si wrapper.secure_file.check.unix.allow_unsecured_volumes est défini à TRUE.

Exemple (autoriser le stockage de fichiers sensibles sur des volumes non sécurisés) : 
wrapper.secure_file.check.unix.allow_unsecured_volumes=TRUE

Propriété wrapper.secure_file.check.disable
Compatibilité :3.6.0
Éditions :Édition ProfessionnelleÉdition StandardÉdition Community
Plateformes :WindowsMac OSXLinuxAlpine LinuxFreeBSDSolarisIBM z/Linux

Cette propriété peut être utilisée pour désactiver la vérification des permissions des fichiers sécurisés. Notez toutefois que l'utilisation des comptes interdits listés en rouge dans les sections ci-dessus restera invalide et empêchera le Wrapper de démarrer.

La valeur par défaut est FALSE.

Exemple (désactiver la vérification des permissions des fichiers sécurisés) : 
wrapper.secure_file.check.disable=TRUE

Propriété wrapper.secure_file.check.loglevel
Compatibilité :3.6.0
Éditions :Édition ProfessionnelleÉdition StandardÉdition Community
Plateformes :WindowsMac OSXLinuxAlpine LinuxFreeBSDSolarisIBM z/Linux

Cette propriété peut être utilisée pour définir le niveau de journalisation des messages affichés lorsqu'un problème avec les permissions d'un fichier sécurisé a été détecté.

La valeur par défaut est FATAL si wrapper.secure_file.check.strict est TRUE, WARN sinon.

Exemple (changer le niveau de journalisation des messages en DEBUG) : 
wrapper.secure_file.check.loglevel=DEBUG

Propriété wrapper.secure_file.check.strict
Compatibilité :3.6.0
Éditions :Édition ProfessionnelleÉdition StandardÉdition Community
Plateformes :WindowsMac OSXLinuxAlpine LinuxFreeBSDSolarisIBM z/Linux

Cette propriété peut être utilisée pour définir si le Wrapper doit s'arrêter ou continuer lorsqu'un problème avec les permissions d'un fichier sécurisé a été détecté.

Il est recommandé de conserver cette propriété définie à TRUE afin que les problèmes de permissions soient détectés et résolus le plus tôt possible. Dans les cas où le Wrapper est configuré pour démarrer automatiquement sans interaction humaine (par exemple lors du démarrage en tant que service), il peut être utile de définir cette propriété à FALSE. Le Wrapper signalera toujours les problèmes de permissions avec un niveau de journalisation par défaut de WARN, et poursuivra son exécution. Il est recommandé que l'utilisateur qui consulte ensuite les journaux corrige les permissions de fichier dès que possible si des avertissements ont été signalés.

La valeur par défaut est TRUE.

Exemple (signaler toujours les problèmes de permissions, mais continuer l'exécution) : 
wrapper.secure_file.check.strict=FALSE

Propriété wrapper.secure_file.additional.<n>
Compatibilité :3.6.0
Éditions :Édition ProfessionnelleÉdition StandardÉdition Community (non prise en charge)
Plateformes :WindowsMac OSXLinuxAlpine LinuxFreeBSDSolarisIBM z/Linux

Les éditions Standard et Professional offrent la possibilité de lister des fichiers supplémentaires qui doivent être vérifiés selon les mêmes règles que pour les fichiers automatiquement détectés comme sensibles par le Wrapper. Cela peut être utile par exemple pour des fichiers sensibles qui ne sont pas lus par le Wrapper mais par l'application Java.

Composant <n> :

Chaque élément a un nom de propriété qui commence par « wrapper.secure_file.additional. » et le composant « <n> » du nom de propriété est un nombre entier commençant à « 1 ». Par défaut, la numérotation doit être séquentielle, sans lacunes. La propriété wrapper.ignore_sequence_gaps peut éventuellement être définie pour autoriser des lacunes dans la séquence.

Exemple (lister des fichiers supplémentaires dont les permissions doivent être vérifiées) : 
wrapper.secure_file.additional.1=../conf/db-credentials.xml
wrapper.secure_file.additional.2=../conf/settings.json

Propriété wrapper.secure_file.additional.<n>.required
Compatibilité :3.6.1
Éditions :Édition ProfessionnelleÉdition StandardÉdition Community (non prise en charge)
Plateformes :WindowsMac OSXLinuxAlpine LinuxFreeBSDSolarisIBM z/Linux

Indique si le fichier défini par wrapper.secure_file.additional.<n> doit exister (TRUE) ou est facultatif (FALSE).

Le Wrapper s'arrêtera avec une erreur si un fichier est requis mais n'est pas présent.

La valeur par défaut est TRUE.

NOTE

Définir cette propriété à TRUE exige uniquement que le fichier existe ; cela n'exige pas que le fichier soit accessible par l'utilisateur actuel.

La vérification des fichiers sécurisés est principalement destinée à détecter les fichiers avec des permissions trop permissives lors du premier lancement du Wrapper. Elle n'est pas conçue pour détecter des permissions trop restrictives.

Par exemple, il est courant que les permissions d'un fichier soient restreintes exclusivement à un compte de service pour une exécution sécurisée en tant que service Windows ou démon Unix. Il s'agit d'une bonne pratique de sécurité, et dans de tels cas, il est normal que le fichier soit inaccessible lors des vérifications de permissions lorsqu'il s'exécute sous un utilisateur différent dans la console.

Exemple : 
wrapper.secure_file.additional.1=../conf/db-credentials.xml
wrapper.secure_file.additional.1.required=TRUE

wrapper.secure_file.additional.2=../conf/settings.json
wrapper.secure_file.additional.2.required=FALSE

Référence : Sécurité

Configuration du chiffrement :

Fichiers sécurisés :

  • wrapper.secure_file.check.windows.allowed_account.<n> (3.6.0)  ⇧

    Liste les comptes (utilisateurs ou groupes) autorisés à lire les fichiers sécurisés sous Windows.

  • wrapper.secure_file.check.unix.allowed_group.<n> (3.6.0)  ⇧

    Liste les groupes autorisés à lire les fichiers sécurisés sous Unix.

  • wrapper.secure_file.check.windows.allow_unsecured_volumes (3.6.0)  ⇧

    Permet de stocker des fichiers sécurisés sur des volumes dont le format ne prend pas en charge les permissions de fichiers.

  • wrapper.secure_file.check.unix.allow_unsecured_volumes (3.6.0)  ⇧

    Permet de stocker des fichiers sécurisés sur des volumes dont le format ne prend pas en charge les permissions de fichiers.

  • wrapper.secure_file.check.disable (3.6.0)  ⇧

    Ignore la vérification des comptes ou groupes configurés comme "allowed" pour les fichiers sécurisés.

  • wrapper.secure_file.check.loglevel (3.6.0)  ⇧

    Contrôle le niveau de journalisation auquel les messages signalant des problèmes avec les fichiers sécurisés seront enregistrés.

  • wrapper.secure_file.check.strict (3.6.0)  ⇧

    Spécifie si le Wrapper doit s'arrêter lorsqu'une permission pour un fichier sécurisé est accordée à un compte ou un groupe qui n'était pas autorisé.

  • wrapper.secure_file.additional.<n> (3.6.0) ( Standard/Professionnel )  ⇧

    Liste des fichiers sécurisés supplémentaires pour lesquels les permissions d'accès seront vérifiées.

  • wrapper.secure_file.additional.<n>.required (3.6.1) ( Standard/Professionnel )  ⇧

    Spécifie si le fichier sécurisé supplémentaire est requis ou non.

Commandes :