Comment enregistrer les modifications apportées au serveur ?

Au pays de Linux, les gens poursuivent plusieurs stratégies différentes :

• Systèmes de contraintes de configuration comme cfengine ou Marionnette ou chef . Elles sont similaires aux GPO de Windows. L'intérêt est que toute la configuration du serveur est intentionnellement documentée en un seul endroit et que vous savez à quelle granularité (salle des serveurs, groupe, serveur spécifique) la politique est mise en œuvre. Cela ne vous évitera pas de vous demander ce qui a bien pu changer il y a six mois, mais cela vous permettra de supprimer la configuration d'un serveur et de la reconstruire à partir de zéro. Vous pourriez mettre les politiques cfengine et Puppet sous contrôle de révision pour répondre à la question.

• Contrôle de la révision de /etc . En général, les programmes Linux stockent leur configuration à un seul endroit, /etc. Les plus audacieux commencent à écrire des scripts pour mettre /etc sous contrôle de révision. L'un de ces programmes que je connais est etckeeper :

  Description: store /etc in git, mercurial, bzr or darcs The etckeeper program is a tool to let /etc be stored in a git, mercurial, bzr or darcs repository. It hooks into APT to automatically commit changes made to /etc during package upgrades. It tracks file metadata that version control systems do not normally support, but that is important for /etc, such as the permissions of /etc/shadow. It's quite modular and configurable, while also being simple to use if you understand the basics of working with version control.

L'un des problèmes dans cette situation est qu'il s'agit en fait d'un problème mixte de processus commercial et de technologie. Et le problème est bien plus important que le simple suivi des modifications apportées par un administrateur. Il faut également être attentif aux changements inattendus et assurer une bonne coordination entre les administrateurs ou les unités afin qu'une modification apportée à un contrôleur AD n'affecte pas les autorisations d'une base de données sur un serveur départemental. En d'autres termes, votre question est une gigantesque boîte de Pandore :)

Dans mon organisation, cela fait environ un an que nous avons commencé à mettre en place des processus et des systèmes pour résoudre ce problème. En ce qui concerne les processus d'entreprise, nous avons formé une équipe de gestion du changement. Selon les procédures normalisées, tous les changements apportés aux environnements de production sont coordonnés par l'intermédiaire de cette équipe. Ils compilent tous les changements, avec leur portée, les systèmes concernés, les services affectés, etc. Elle veille à ce que les changements soient bien documentés et à ce qu'il y ait des plans de déploiement et de retour en arrière. Ils organisent des réunions hebdomadaires (ouvertes) pour examiner les changements à venir dans l'environnement, puis envoient des courriers électroniques détaillant tous ces changements. L'objectif final de ce processus est de faire en sorte que tous les informaticiens soient au courant de tout ce qui se passe. Cela permet d'éviter, par exemple, qu'un administrateur système installe un correctif du noyau et redémarre un système, ce qui aurait pour effet de mettre hors service la base de données de l'horloge.

Pour ce qui est de l'aspect technologique, je ne peux parler que des gars d'Unix/Linux puisque je n'ai pas affaire à Windows. Ils ont mis en place Puppet, de Reductive Labs, pour la gestion de la configuration de tous ces systèmes. Il s'agit simplement d'un système client/serveur dans lequel on définit une configuration de machine sur le serveur, et le client tire ces chances de temps en temps (30 minutes par défaut). En outre, si des modifications sont apportées aux fichiers gérés localement, elles sont également annulées à ce moment-là. Nous l'utilisons pour gérer les services en cours d'exécution, les configurations de pare-feu, l'autorisation des utilisateurs, etc.

Je vous recommande également de vous intéresser à un organisme comme TippingPoint. Il s'agit d'un service client qui surveille la configuration du système et envoie des alertes en cas de changement. C'est ce qui nous rend le plus heureux, nous les spécialistes de la sécurité. Il est largement utilisé pour suivre les modifications malveillantes ou non publiées.

J'ai travaillé dans 4 ou 5 entreprises, je ne me souviens plus très bien.

Nous avons tous eu ce problème. Aucun d'entre nous ne l'a résolu à 100 %, mais dans l'entreprise où je travaille actuellement, nous avons ce que je pense être la meilleure stratégie à ce jour.

Sharepoint/Wiki/Evernote/PINs

• Sharepoint
  • Vous pouvez vous plaindre autant que vous voulez... il a des caractéristiques de liste très intéressantes.
  • Listes d'adresses IP
  • inventaire
  • comptes de service et utilisation
  • journaux de notification des modifications
• Wiki
  • Comment faire
  • listes de tâches à long terme
• Evernote
  • mon partenaire et moi l'utilisons pour mettre tout ce que nous ne voulons pas dans Wiki
  • plus de conseils pratiques de nature technique
  • des notes à gratter que nous devons tous les deux voir
  • comptabilité des tâches pour la semaine
  • listes de tâches des entrepreneurs
  • Le clipper d'evernote facilite la capture d'écran des paramètres AD/droits
  • disponible partout
• NIP
  • Répertoire des mots de passe

Il existe probablement de meilleurs outils pour certaines de ces tâches, mais c'est ce que nous utilisons :

• Suivre les changements de configuration et les mises à niveau/rattrapages pour chaque serveur dans une base de données. wiki privé
• Conservez également les modes d'emploi et un registre des problèmes et des solutions dans le wiki.
• Utilisation Sharepoint ou Google Docs pour conserver des copies autorisées d'éléments tels que les listes d'adresses IP statiques
• utiliser Subversion pour suivre les modifications apportées aux fichiers de configuration

Pour Windows, consultez la série System Center de Microsoft ou tout autre concurrent dans le domaine de la gestion de la configuration et des services pour cette plate-forme.

Les changements doivent être acheminés par une routine de gestion des changements décente qui les approuve et les enregistre avant qu'ils ne soient réellement effectués. Pour commencer, cette procédure peut être entièrement manuelle. Avec certains des outils les mieux intégrés, vous pouvez demander à l'outil d'effectuer les changements réels et d'obtenir une journalisation "automatique" vers une base de données de configuration centrale - plutôt que d'aller à mains nues dans la console d'un serveur individuel, en fouillant dans les paramètres à la main pour essayer de résoudre un problème à la manière d'un cow-boy.