Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Modification du lien vers la bonne page de config du Synchronizer + orthographe


Concepts


Shinken Entreprise met tout en œuvre pour Pour limiter les risques de perte de données :, nous avons mis en place un certain nombre de garde-fous

  • Avertissements en cas d'oubli de sauvegarde de la clé (shinken-healthcheck et commandes d'administration)
  • Vérification de la cohérence entre la configuration décrite dans les fichiers et la base de données du Synchronizer. Voici deux exemples de situation pouvant mener à des problème de cohérence :

    • L'encadré ci-contre vous explique de quoi il s'agit
    • La section ci-dessous Vérification de la cohérence de la configuration détaille les différents cas
    • Si vous remplacez la clé de chiffrement par une nouvelle clé sans passer par les commandes d'administration des données sensibles, les données n'auront pas été migrées et le Synchronizer sera donc incapable de démarrer avec la nouvelle clé.
    • Si vous restaurez une base shinken chiffrée avec shinken-restore et que vous ne restaurez pas la bonne clé, le Synchronizer le signalera et refusera de démarrer.

  • Solution de secours en cas de perte de la clé
  • En cas d'incohérences et de risques de pertes de données, le Synchronizer refusera de démarrer et les outils de mener à bien leurs actions. Ils afficheront également les détails de ces incohérences.





Panel
titleshinken-healthcheck



Info
titleIncohérence des données

Lorsque le Synchronizer démarre, il lit la configuration dans des fichiers et l'applique.

La configuration appliquée est sauvegardée dans la base de données.

Lors que la configuration est modifiée par les commandes d'administration des données sensibles ou par d'autres biais, ces fichiers de configuration sont mis à jour, mais tant que le Synchronizer n'est pas redémarré, celui-ci ne prend pas en compte la nouvelle configuration.

C'est alors qu'il peut y avoir une incohérence, qui

peut

pourrait mettre en péril vos données si le Synchronizer démarrait et appliquait la configuration des fichiers sans vérification.


Refus de démarrage du Synchronizer en cas de problème

Lorsque le Synchronizer ne peut pas démarrer à cause de problèmes liés au chiffrement de données sensibles, il affichera l'un des messages d'erreurs suivants :

Encryption is activated but there no key file is defined in the configuration

Le Synchronizer est configuré pour chiffrer la les données, et aucune clé n'est définiemais l'entrée protect_fields__encryption_keyfile  dans le fichier de configuration du Synchronizer est manquante ou vide.

Solution: Utilisez la commande commande shinken-healthcheck pour  pour vérifier si la base est effectivement chiffrée et le nom de la clé utilisée.

Cela restaurera les bons champs dans le fichier automatiquement, sans que vous ayez a manipuler le fichier.

Note: Si vous n'utilisez que les commandes d'administration des champs protégés, cette erreur ne devrait pas se produire.

Explication technique

Le paramètre protect_fields__activate_encryption a une valeur de 1 (chiffrement activé) mais le paramètre protect_fields__encryption_keyfile (spécifiant le nom du fichier contenant la clé de chiffrement) n'est défini dans aucun fichier de configuration utilisé par le Synchronizer.

Cannot read the protected fields secret file <fichier> : <cause>

Le fichier contenant la clé de chiffrage chiffrement n'est pas lisible pour la raison indiquée dans le message d'erreur.

Il peut s'agir du fait que le fichier n'existe pas  pas ou bien que l'utilisateur Linux le compte Linux "shinken" sous lequel fonctionne le Synchronizer n'a pas les droits d'accès au fichier.

  • Si c'est un problème de droits Linux, assurez-vous que le Synchronizer est exécuté avec le bon utilisateur Linux ou utilisez les commandes Linux chown ou chmod pour remédier au problèmeredonnez au fichier indiqué dans le message d'erreur des droits permettant à l'utilisateur Linux de le lire (et uniquement cet utilisateur).
  • Si le fichier n'existe pas vous pouvez le restaurer avec la commande shinken-protected-fields-keyfile-restore.

The key contained in the keyfile does not have the right structure

Le fichier contenant la clé de chiffrage est lisible, mais chiffrement ne contient pas d'information utilisable par le Synchronizer. Il peut s'agit d'un fichier corrompu, auquel cas utilisez la commande commande shinken-protected-fields-keyfile-restore  pour regénérer régénérer un fichier contenant les bonnes informations.

The Protected Fields key file was modified

Cette erreur se produit dans deux cas lorsque la clé décrite dans les fichiers de configuration est différente de celle utilisée pour le chiffrement des données. Deux cas peuvent se produire :

  • Le nom de la clé a changé entre celui décrit dans le fichier contenant la clé, et celui que le Synchronizer a utilisé lors de sa dernière exécutionest différent. Dans ce cas le log contient les deux noms, ce qui devrait vous permettre de savoir ce qui s'est passé et de permet de restaurer la bonne clé avec la commande shinken-protected-fields-keyfile-restore
  • La clé elle-même a changé entre celle utilisée pour le chiffrage de la base de données lors de la dernière exécution du Synchronizer et celle définie dans le fichier de configuration, bien alors que le nom des deux clés soit le mêmereste identique. Cela signifie que le fichier contenant la clé a probablement été corrompu et la meilleure solution est de la restaurer avec la commande commande shinken-protected-fields-keyfile-restore


Info
Si cela s'avérait nécessaire, référez vous à la page Paramétrage de l'interface de Configuration pour connaitre les paramètres liés au chiffrement, même si nous vous déconseillons de les modifier manuellement.


Vous pouvez utiliser la commande suivante, qui vous donnera l'historique des cinq dernières modifications touchant le chiffrement des données :

Code Block
$ shinken-healthcheck --show-history

La copie d'écran montre que :

  • le 16 / 05 le chiffrage a été activé avec la clé nommée kn
  • le 22 / 05 la liste des propriétés chiffrées a été modifiée

Dans les deux cas, la clé n'était pas sauvegardée au moment de la migration.


Panel


Vérification de la cohérence de la configuration

Le Synchronizer et les outils d'administration des champs protégés vérifient la cohérence entre les fichiers de configuration et la base de données.


Les points suivants sont vérifiés

  • Statut du chiffrement (activé ou non)Le chiffrement est-il activé ?
  • Nom de la clé
  • Empreinte de la clé (la clé a-t'elle changé entre le fichier de configuration et celle utilisée pour le chiffrement courant de la base ?)

En fonction du risque de perte de données, cette vérification donnera lieu à une erreur ou pas.

Ce tableau décrit les différents cas.

Chiffrage activé dans
les fichiersBase chiffrée
la base

Chiffrage activé dans la configuration

IncohérenceConséquences
(error)(tick)
(error)
Clé différenteLors du redémarrage du Synchronizer, la base sera chiffrée avec la clé définie dans la configuration
(error)(tick)
(error)
Nom différentLors du redémarrage du Synchronizer, la base sera chiffrée avec la clé définie dans la configuration
(error)(tick)
(error)
Aucune incohérenceLors du redémarrage du Synchronizer, la base sera chiffrée avec la clé définie dans la configuration
(error)(error)Clé différenteAucune conséquence
(tick)(error)
(tick)
Clé différenteLe synchronizer refusera de démarrer car il ne dispose pas de la bonne clé pour
travailler
déchiffrer les données
(tick)(error)
(tick)
Nom différentLe synchronizer refusera de démarrer car il ne dispose pas de la bonne clé pour
travailler
déchiffrer les données
(tick)(error)
(tick)
Aucune incohérenceLe synchronizer démarrera et désactivera le chiffrement de la base
(tick)(tick)Clé différenteLe synchronizer refusera de démarrer car il ne dispose pas de la bonne clé pour travailler
(tick)(tick)Nom différentLe synchronizer refusera
de démarrer
de démarrer  car il ne dispose pas de la bonne clé pour travailler
(tick)(tick)Aucune incohérenceLe synchronizer démarrera et ne modifiera pas l'état de la base


En cas de perte de la sauvegarde de la clé

Si vous perdez la sauvegarde de votre clé ET la clé, il reste un recours si vous disposez d'un backup de la configuration effectué avec shinken-backup.

Le backup de la configuration contient une sauvegarde de votre clé, chiffrée avec une clé asymétrique. La partie chiffrement est fournie dans votre installation de Shinken, mais la partie permettant le déchiffrement est détenue exclusivement par Shinken Enterprise.

La commande /var/lib/shinken/libexec/tools/shinkenNous vous conseillons alors de vous référer à la documentation de la commande shinken-protected-fields-keyfile-rescue-from-backup permet d'extraire d'un backup Shinken une version chiffrée de la clé. Vous pouvez alors l'envoyer à votre support Shinken, qui vous renverra alors une sauvegarde de la clé que vous pourrez restaurer de la manière habituelle, avec shinken-protected-fields-keyfile-restore qui vous permettra de restaurer votre clé avec l'aide du support Shinken.


Warning

Cette solution ne doit être utilisée qu'en dernier recours et ne doit pas remplacer les sauvegardes dont vous êtes responsable.


Note

 La clé chiffrant vos données étant connue par des tiers, il est fortement recommandé de changer la clé de chiffrement utilisée ( Migration d'une base chiffrée vers une nouvelle clé shinken-protected-fields-keyfile-migrate ).