ITIL v3 et le catalogue des services en sécurité SI – partie 3

Au sujet de ces plages d’arrêt justement, nous avons vu que certaines se font plutôt la nuit. Un lecteur me faisait remarquer récemment que pas mal de fournisseurs refusent d’intervenir la nuit, ce qui est en partie vrai. D’une part, c’est le genre de contrainte que l’on met dans un cahier des charges avant la conclusion du marché, et d’autre part en cas d’impossibilité il n’y a pas de miracle : il s’agit simplement d’une contrainte avec laquelle MOA et DSI vont devoir composer.

Autres informations nécessaires dans ce tableau de service : les fameux RTO (Return Time Objective, ou temps contractuel de délai de remise en service) et RPO (ou Return Point Objective, ou fraicheur des données suite une opération de restauration de base). Le cas du RPO est le plus simple : pour ce qui concerne les bases de données métier, elles sont maintenant journalisées ce qui assure un RPO quasi nul (à la transaction non-validée près). Encore faut-il tester régulièrement les restaurations, ce qui est une autre histoire et nécessite plusieurs articles dédiés (le cas de la sauvegarde des journaux de transaction est un vrai délice d’auditeur externe…).

Le cas du RTO est piégeur : s’il fallait restaurer une petite base de données, à compter du lancement technique de l’opération cela peut nécessiter un temps court, moins de 2h dans la plupart des cas. Mais s’il fallait restaurer toute la base patients (et surtout ses satellites, serveurs de comptes rendus, base IPP, base des actes, le tout sans erreur de synchronisation), très honnêtement cette opération est tellement complexe que je ne l’ai jamais vue réalisée de bout en bout. Cela étant il faut contractualiser sur ce RTO, et une durée de 4h à 2j (dans le pire des cas) est ce que l’on observe sur le terrain.

Enfin, parce que l’on est dans de la Qualité, il manque deux éléments pour parfaire le dispositif. D’abord, ce tableau doit être régulièrement réévalué : nouvelles lignes, modifications d’informations existantes, etc. Le point d’entrée est idéalement le RSSI, en lien avec un correspondant côté MOA et un côté DSI. Enfin, tout incident SI doit faire l’objet d’une analyse post-mortem avec analyse des causes, la mise à jour dudit tableau pouvant être nécessaire.

 J’allais oublier : ce fameux tableau a vocation à être publié très largement : l’Intranet, une copie en local sur les PC diffusée par SCCM ou tout autre dispositif fera l’affaire pourvu que personne ne puisse dire qu’il n’y a pas accès, de l’agent de catégorie C au DG.

Cédric Cartau
[email protected]

[1]/article/1809/itil-v3-et-le-catalogue-des-services-en-securite-si-partie-1.html 

[2] /article/1815/itil-v3-et-le-catalogue-des-services-en-securite-si-partie-2.html