Différences

Ci-dessous, les différences entre deux révisions de la page.

--- ccub:gestion_des_changements [2024/09/02 06:37] – - Imported by DokuWiki Advanced Plugin cardynal
+++ ccub:gestion_des_changements [Date inconnue] (Version actuelle) – supprimée - modification externe (Date inconnue) 127.0.0.1
@@ Ligne 1: / Ligne 1: @@
-====== Procédure de gestion des changements ======
-===== Politique de gestion des changements =====
-Sont concernées par cette politique toutes actions pouvant avoir un impact sur la sécurité de l'information. Encadrer la gestion du changement permet de conserver la maitrise de la sécurité du SMSI, limite l'exposition aux vulnérabilités et aux menaces critiques. Cette procédure s'applique à l'ensemble des changements touchant les systèmes de production, qu'il s'agisse de répondre à la demande d'un utilisateur, de déployer un environnement, de la mise en oeuvre d'un projet ou du traitement d'un incident.
-Sont exclus de la gestion des changements :
-  * Les changements apportés à un environnement de test
-  * Les interventions visant à revenir à un état nominal de fonctionnement, comme par exemple le forçage du retour sur l'équipement primaire après une bascule ou l'application de mises à jour système vers une version approuvée.
-===== Rôles et responsabilités =====
-===== Qualification du changement =====
-Sont considérés comme mineurs les changements ciblés sur une seule organisation utilisatrice ou réalisés selon un mode opératoire maîtrisé, comme par exemple une extension des ressources allouées sans impact sur l'architecture générale.
-Tous les autres changements sont considérés comme majeurs.
-===== Cas d'un changement mineur =====
-FIXME : à revoir
-  * Une demande de service et déposée par un utilisateur ou une demande de changement est déposée par un administrateur.
-  * L'administrateur évalue le changement. S'il détermine que la demande est mineure et parfaitement explicite, il valide le ticket pour exécution.
-  * L'administrateur effectue le changement et documente son exécution dans le ticket de demande de service.
-  * Si l'exécution du changement implique de cloner de données des utilisateurs, celles-ci doivent être copiées vers le bac à sable qui convient (/work/sandbox) et effacées en fin d'intervention.
-  * Mise à jour des documents pérennes (matrice des flux et filtrages, schémas)
-  * Le ticket de demande de service est clôturé par l'administrateur lui-même.
-===== Cas d'un changement majeur =====
-  * L'administrateur qualifie la demande de service comme un changement majeur ou un projet, auquel cas la procédure de [[ccub:securite_dans_les_projets|sécurité de l'information dans la gestion de projet]] s'applique également.
-  * Le responsable de production crée un ticket de changement.
-  * Le responsable de production assigne le ticket à un chargé d'instruction qui :
-    * évalue les opérations à effectuer pour apporter le changement
-    * décrit le mode de retour arrière lorsque celui-ci est pertinent
-    * propose une plage horaire pour la réalisation du changement
-    * FIXME - Ajouter le test de sécurité si nécessaire
-    * lie le ticket de changement à l'historique des actifs impactés
-  * Mise à jour des documents pérennes (matrice des flux et filtrages, schémas)
-  * Le changement est approuvé par le COPIL SMSI et assigné à un intervenant
-  * L'intervenant exécute le changement dans la plage horaire proposée et documente son exécution dans le ticket de changement. En cas de contretemps il peut proposer une nouvelle plage horaire, auquel cas on repassera par l'étape d'approbation.
-  * Le ticket est clôturé lors de la prochaine réunion du COPIL SMSI.
-===== Cas du patch d'urgence =====
-Un patch d'urgence est un changement à réaliser aussi rapidement que possible. Ce mode de changement permet d'effectuer une modification en production sans autorisation préalable du COPIL SMSI.
-Le caractère urgent d'un changement est justifié si:
-  * La perte de service ou le problème à corriger concerne un grand nombre d'utilisateurs
-  * La réalisation de la demande permet de réduire ou supprimer une vulnérabilité critique.
-En ce cas le ticket de changement doit être créé a posteriori, et au plus tard sous 2 jours ouvrés, pour une régularisation de l'opération effectuée, en indiquant clairement dans son intitulé qu'il concerne un patch.