Comment enregistrer les modifications apportées au serveur ?

Vous devez absolument mettre en place un processus de gestion des changements, surtout si plusieurs personnes ont la possibilité d'apporter des modifications au niveau du système dans votre environnement. Cela permet également à la direction d'approuver les changements potentiels, mais l'inconvénient est que cela induit une certaine latence dans le processus de changement si vous ne pouvez pas effectuer de changements à la volée.

Parmi les moyens de suivre les changements, on peut citer la validation des événements dans votre SEM (en supposant que vous disposiez d'un gestionnaire d'événements de sécurité) ou des outils tels que Nessus (qui, avec beaucoup de travail, permet d'auditer votre environnement pour trouver les changements).

Il s'agit d'une réponse plus localisée, basée sur *nix. Je n'ai pas trouvé de bons outils pour l'émuler sous Windows.

Il y a plusieurs façons de mettre cela en œuvre ... et de le rattraper lorsque vous l'oubliez.

Les systèmes de contrôle de révision tels que subversion, git, cvs ou RCS sont un bon moyen de suivre l'historique d'un fichier de configuration. Si vous ne souhaitez pas installer un système de contrôle de révision sur vos serveurs de production, vous pouvez stocker les répertoires des fichiers de configuration localement ou à distance en utilisant quelque chose comme rsnapshot vous donnera la plupart des avantages d'un RCS, mais vous perdrez la possibilité d'auditer ou de laisser des journaux commit (bien que cela puisse être contourné avec des commentaires à l'intérieur des fichiers eux-mêmes).

Pour vous aider à ne pas oublier d'enregistrer les modifications, un rapport automatisé sur les changements de configuration via une commande nocturne cron a été mis en place. fil de fer est un bon début. Une fois que la base de données de Tripwire a été constituée avec l'état actuel des fichiers, toute modification apportée à ces derniers entraînera l'envoi d'un courrier électronique lors de l'exécution suivante. Vous continuerez à recevoir ce courrier jusqu'à ce que la base de données soit mise à jour, ce qui permettra de "réinitialiser" le tripwire.

J'utiliserais un système de suivi des problèmes tel que flyspray (n'importe lequel fera l'affaire, mais j'aime bien flyspray pour les choses qui ne relèvent pas de la programmation). Avant que quelqu'un ne touche à une configuration, l'amélioration/le problème doit être enregistré. Lorsque vous le corrigez ou le mettez en œuvre, les changements sont consignés dans le ticket.

Un wiki peut être utile pour documenter la configuration actuelle, mais il est facile de le rendre obsolète - et sa mise à jour semble demander plus d'efforts, selon l'OMI.

Vous ne trouverez pas de système automatisé pour faire cela - bien que vous puissiez probablement le configurer de manière à ce que les modifications apportées à certains fichiers de configuration soient automatiquement envoyées par courrier électronique au gestionnaire de problèmes si vous le souhaitez.

Je pense qu'il s'agit simplement d'une bonne politique, d'outils à faibles barrières et de discipline.

Nous avons créé quelque chose d'artisanal pour assurer le suivi des journaux de modifications dans notre environnement ; ce n'est pas quelque chose de très compliqué, et cela fonctionne assez bien.

• Une politique d'autosurveillance est mise en place : toute modification qui, selon vous, s'écarte d'une configuration prête à l'emploi ou peut potentiellement causer des problèmes, doit être documentée dans le système de journal des modifications.
  • Le revers de la médaille, c'est que si vous cherchez à résoudre un problème, recherchez les entrées récentes ou connexes du journal des modifications.
• Connectez-vous au système et choisissez le serveur, le service ou le composant matériel que vous modifiez.
  • les composants sont préalablement introduits dans le même système avec des informations "démographiques" de base (emplacement, fournisseur, numéro de série, service responsable)
• Choisissez parmi une liste déroulante de catégories de base
  • Temps d'arrêt imprévu
  • Parcheando
  • Maintenance du matériel
  • Installation du logiciel
• Détaillez ce que vous avez fait, vu, observé
• une copie est envoyée au responsable et stockée sous forme de fichiers XML qui sont indexés par un moteur de recherche.
• Profit

Comme je l'ai dit, rien d'extraordinaire. Il utilise le CGI PERL (écrit il y a un milliard d'années) et un moteur de recherche Google pour l'indexation.

Lacunes :

• Les groupes de services sont difficiles à utiliser. Par exemple, vous venez d'ajouter le même correctif aux 25 contrôleurs de domaine ; nous n'avons pas de groupe "Contrôleur de domaine", nous devons donc tous les sélectionner manuellement.
• Ne s'intègre pas au matériel, aux logiciels ou aux rapports d'erreurs du journal des événements pour faciliter la résolution des problèmes.
• dans le même ordre d'idées, la saisie manuelle de toutes les données "démographiques", comme je l'ai dit plus haut

Quoi qu'il en soit, si après tout cela vous êtes intéressé par le code, faites-le moi savoir et je pourrai probablement l'obtenir pour le partager.

Comme nous l'avons dit, il s'agit souvent d'une question culturelle - après tout, certains ateliers de développement ne s'embarrassent plus de commentaires (l'auto-documentation du code est un mot à la mode aujourd'hui !) et d'autres utilisent un système de contrôle des versions comme le Saint Graal des enregistrements historiques. Il est évident que ces systèmes ne sont pas parfaits.

La seule véritable façon de résoudre ce problème est donc d'en faire une solution culturelle. Veillez à ce que tous les motifs de changement soient consignés dans un système de suivi des bogues (ou une base de connaissances, ou un wiki), et à ce que tous les changements soient consignés dans un système de contrôle des changements.

Nous avons des clients dans le domaine des services d'urgence, chaque modification apportée à leur système est enregistrée, et chaque fois que nous nous connectons à leur système, nous devons l'enregistrer. Pour certains d'entre eux, nous devons d'abord demander l'autorisation par téléphone (et je suppose qu'ils l'enregistrent aussi !). Tous les Le changement est enregistré et le fait de modifier le système du client sans l'enregistrer constitue une infraction disciplinaire.

Cela semble onéreux, mais ce n'est pas le cas. Vous prenez rapidement l'habitude de vous ajouter au journal des accès et au journal des modifications - ce n'est pas pire que d'avoir à écrire un commentaire lors de l'enregistrement d'une modification de code.

Je recommande l'utilisation d'un bugtracker pour le contrôle des changements, car il est généralement facile à mettre à jour (j'utilise Mantis).