En quoi le RSSI peut-il être utile pour les
sauvegardes ?
On a tendance à croire que les sauvegardes sont une problématique exclusive de la
production. Il ne faut pourtant pas oublier les contraintes du métier, qui doivent être en
principe à l’origine des sauvegardes. Dans les faits, on est en présence de deux élans :
d’une part celui des besoins réels de sauvegarde/restauration, directement issus des
métiers, et d’autre part celui des pratiques effectives de sauvegarde/restauration, issues
de processus purement techniques mis en place progressivement par les informaticiens,
au fur et à mesure de l’évolution du SI. Ces deux élans ont tendance à diverger l’un de
l’autre, alors qu’ils sont censés converger sans cesse. Cette évolution divergente conduit
à trois risques très concrets.
Omission : les sauvegardes sont un processus technique, mis en place par des
architectes et opérés par des administrateurs. Elles sont enrichies progressivement, à
mesure que le SI évolue, et il arrive fréquemment que certains éléments du SI soient
oubliés du processus de sauvegarde, si bien qu’en cas d’incident sur ces éléments, il
est très difficile de les restaurer.
Mauvaise durée de rétention : un second risque est de ne pas retenir suffisamment
longtemps les sauvegardes. Une fois de plus, il faut considérer non seulement les
besoins techniques, mais aussi les besoins métier pour décider la durée de rétention
des sauvegardes. On ne se rend compte de cette inadéquation que le jour où on a
besoin de restaurer une information qui n’existe plus.
Impossibilité de restaurer : un troisième risque très répandu consiste à ne pas savoir
restaurer une information que l’on croyait pourtant bien sauvegardée. Cela arrive avec
les informations que l’on est rarement amené à restaurer.
Face à ces problèmes, en quoi le RSSI peut-il être utile ? Par son positionnement
transverse au niveau du SI, le RSSI est à la fois tourné vers le métier, tout en restant au
contact de la technique. Il est obligé d’avoir une vision d’ensemble et une partie de son
travail consiste à modéliser différents aspects du SI. Il a donc les compétences
appropriées pour vérifier l’adéquation entre les pratiques techniques de
sauvegarde/restauration et les besoins réels.
Pour réaliser ce travail, il commencera par dresser une cartographie précise des
sauvegardes, ce qui lui permettra ensuite de vérifier que les restaurations sont effectives.
Ce travail conduira à ce que les sauvegardes soient un processus fiable. Ainsi, en cas de
sinistre majeur, de perte accidentelle de données ou en cas de destruction malveillante
d’informations, les équipes de la DSI auront la possibilité de reconstruire facilement les
données sinistrées.
sauvegardes ?
On a tendance à croire que les sauvegardes sont une problématique exclusive de la
production. Il ne faut pourtant pas oublier les contraintes du métier, qui doivent être en
principe à l’origine des sauvegardes. Dans les faits, on est en présence de deux élans :
d’une part celui des besoins réels de sauvegarde/restauration, directement issus des
métiers, et d’autre part celui des pratiques effectives de sauvegarde/restauration, issues
de processus purement techniques mis en place progressivement par les informaticiens,
au fur et à mesure de l’évolution du SI. Ces deux élans ont tendance à diverger l’un de
l’autre, alors qu’ils sont censés converger sans cesse. Cette évolution divergente conduit
à trois risques très concrets.
Omission : les sauvegardes sont un processus technique, mis en place par des
architectes et opérés par des administrateurs. Elles sont enrichies progressivement, à
mesure que le SI évolue, et il arrive fréquemment que certains éléments du SI soient
oubliés du processus de sauvegarde, si bien qu’en cas d’incident sur ces éléments, il
est très difficile de les restaurer.
Mauvaise durée de rétention : un second risque est de ne pas retenir suffisamment
longtemps les sauvegardes. Une fois de plus, il faut considérer non seulement les
besoins techniques, mais aussi les besoins métier pour décider la durée de rétention
des sauvegardes. On ne se rend compte de cette inadéquation que le jour où on a
besoin de restaurer une information qui n’existe plus.
Impossibilité de restaurer : un troisième risque très répandu consiste à ne pas savoir
restaurer une information que l’on croyait pourtant bien sauvegardée. Cela arrive avec
les informations que l’on est rarement amené à restaurer.
Face à ces problèmes, en quoi le RSSI peut-il être utile ? Par son positionnement
transverse au niveau du SI, le RSSI est à la fois tourné vers le métier, tout en restant au
contact de la technique. Il est obligé d’avoir une vision d’ensemble et une partie de son
travail consiste à modéliser différents aspects du SI. Il a donc les compétences
appropriées pour vérifier l’adéquation entre les pratiques techniques de
sauvegarde/restauration et les besoins réels.
Pour réaliser ce travail, il commencera par dresser une cartographie précise des
sauvegardes, ce qui lui permettra ensuite de vérifier que les restaurations sont effectives.
Ce travail conduira à ce que les sauvegardes soient un processus fiable. Ainsi, en cas de
sinistre majeur, de perte accidentelle de données ou en cas de destruction malveillante
d’informations, les équipes de la DSI auront la possibilité de reconstruire facilement les
données sinistrées.