Comment définir une politique de sauvegarde?

Bonjour,

Tout est dans le titre, je travaille dans une société qui est train de déployer une politique de sécurité. Nous partons de zéro.

Je doit définir la politique de sauvegarde de la boite.
Je recherche donc les bonnes pratiques dans le "domaine" et que doit contenir un tel document (en français si possible).

Les obligations de chacun des acteurs sont définis mais pour la partie "concrète", j'ai un peu de mal ne venant pas du métier d' "exploitation":
- les préconisations pour les sauvegardes en Production?
- les préconisations pour les sauvegardes en Recette?
- les préconisations pour les sauvegardes en Développement?

Merci pour votre aide

Cordialement

Pimos :ccool:

En complément:
J'ai consulté déjà les sites du:
- Cigref
- Clusif
- ANSSI

Bonjour,

Il faut que tu consultes le bon sens.

Exemple : sauver tous les disques durs de tous les PCs utilisateurs tous les soirs --> pas raisonnable : trop de donnees personnelles, trop volumineux, completement inutile.
Monter des disques reseaux sur lesquels les gens vont stocker leurs donnees pro : necessaire.
Avoir un serveur de stockage en RAID (niveau a definir selon le besoin et la volumetrie) : necessaire
Faire une sauvegarde de ces serveurs de stockage : Necessaire

Sauver les serveurs de prod : ca depend de ce qu'il y a dessus. Si c'est un site web statique, ca ne sert a rien de faire une copie tous les soirs, il doit y en avoir une copie sur un serveur sauvegarde.
A toi d'analyser la periode de donnees qui peut etre perdue, et les contraintes qui vont avec.

Bref, chaque cas est different, et le bon sens doit gouverner.

OK, merci pour ton retour. Je vais donc essayer d’apporter un élément de réponse pour le forum.

Nous allons demander aux MOE (à faire valider par les MOA) de définir les éléments à sauvegarder : instance de base, serveur physique/virtuel, répertoire, ….

Et pour chaque éléments de le qualifier de « stratégique, critique, modéré, faible ou nul » en fonction des risques suivants :
- L’impact financier
- Perte de chiffre d’affaire
- Perte de Marge
- Processus métier
- Perte de temps de travail
- Mouvement sociaux
- Sécurité du personnel
- Perte d’image vis-à-vis du client
- Image de marque
- Juridique
= Je ne peux pas fournir le tableau mais cette liste donne déjà une bonne idée.

En fonction du niveau définis, on va alors appliquer la règle de sauvegarde approprié :
La journalisation des données ne sera pas mis en application dans notre contexte
Le système de sauvegarde mis en place devra respecter le délai légal de conservation des données et les directives PSSI en terme de sécurité.
- nv1-----------------------------
La sauvegarde de la parie fonctionnelle devra être réalisée toutes les heures.
La sauvegarde devra être accessible rapidement.
La restauration pourra être réalisée de façon partielle pour la partie fonctionnelle.
Une sauvegarde fonctionnelle et technique complète devra être réalisée tous les jours.
Une sauvegarde fonctionnelle et technique complète devra être externalisée tous les jours.
- nv2-----------------------------
Une sauvegarde fonctionnelle et technique complète devra être réalisée tous les jours.
Une sauvegarde fonctionnelle et technique complète devra être externalisée tous les jours.
- nv3-----------------------------
Une sauvegarde fonctionnelle devra être réalisée tous les jours.
Une sauvegarde technique devra être réalisée à chaque évolution technique.
Une sauvegarde fonctionnelle complète devra être externalisée tous les jours.
Une sauvegarde technique devra être externalisée à chaque évolution technique.



ça te semble cohérent? :)

Oui, mais je crains que tu ne te retrouves avec trop de choses a sauvegarder.

Je m'explique : si tu demandes a une personne si un document est critique, soit elle n'a rien a voir avec le document, et elle te dit non, soit elle est liee a ce document, et elle te repond qu'il est ultra-critique que la moindre modification soit sauvergardee en temps reel sur 42 sites distincts. Et j'exagere a peine.

Demander un niveau de criticite, c'est bien, mais il est absolument necessaire de limiter les gens, a moins bien sur que vous n'ayez, pour le moment, trop de place, et que donc vous puissiez, pour le moment, tout sauver.

Attention aussi a prevoir beaucoup de place libre : faire une sauvegarde quotidienne toutes les nuits c'est bien, mais si celle-ci dure plus de 8h, je te garantis des soucis dans maximum 6 mois : la sauvegarde prendra 10h, et on t'expliquera que c'est trop, et que non, elle ne peut pas demarrer plus tot ni finir plus tard.

ça me donne ce tableau:

http://www.developpez.net/forums/att...1&d=1356083408

Citation:

---

Envoyé par gangsoleil

Demander un niveau de criticite, c'est bien, mais il est absolument necessaire de limiter les gens, a moins bien sur que vous n'ayez, pour le moment, trop de place, et que donc vous puissiez, pour le moment, tout sauver.

---

Je suis tout à fait d’accord avec toi. Et j’ai reçu les premiers chiffrages pour la mise en place des sauvegardes et nous montons très vite à plusieurs 100ène de millier d’€.
Le frein sera donc financier et un arbitrage sera de toute façon réalisé par la direction et le RSSI.
Je suis dans le process de mise en place d’une politique, je dois donc proposer un « cadre ».

Concernant la volumétrie, nous proposons un répertoire de sauvegarde à chacun avec un quota. Après ils doivent faire des demandes de dérogation.

Merci pour ces échanges ça m'a débloqué.

- ne pas compter sur les utilisateurs ... sauf pour te faire des reproches
- garder plusieurs versions des documents ( 1 svg écrasant la précédente t’empêchera de couvrir les conneries des utilisateurs non observés immédiatement)
- définir ce qui doit être sauvegardé et par définition ce qui ne l'est pas ( exemple les mails sont sauvegardés mais pas les adrs mails non enregistrés en contacts qui sont du cache,les mp3 ne sont pas sauvegardés, les dossiers perso qui sont dans documents par exemple sont sauvegardés donc prob éventuel de confidentialité )

- Avoir un double des sauvegardes éventuellement à l'extérieur.

- Bien surveiller les logs ( en ayant conscience que ça protège pas de tous les probs )

- Impliquer les utilisateurs en leur permettant un contrôle de la sauvegarde ( accès en lecture seule, envoi des logs) : en cas de litige avec un utilisateur, celui-ci avait un moyen de contrôle qu'il n'a pas utilisé et ça permet un double contrôle.

Voir le sens de la sauvegarde ( le serveur se connecte sur chaque poste ou chaque poste se connecte au serveur si cas 1 il faut faire les vérifs sur chaque poste ). Réduire l'impact de plantage des svgs en éclatant la svg en plusieurs profil en cas de plantage du profil 1,le profil 2 peut s’exécuter qd même,au moins 1 partie sera sauvegardé ( ex:profil 1 document,profil 2 bureau )

Je te conseille les système de synchro,cela permet un accès simple à la sauvegarde sur lequel les users peuvent avoir accès.

Ces conseils pragmatiques peuvent te permettre d'établir un cahier des charges, en n'oubliant pas que tes contraintes techniques ne seront pas celles des utilisateurs ni celles du payeur, mais une fois les contraintes de tout le monde exposé, les décisions seront prises en conséquence et connus de tous.

Je me suis retrouvé dans une situation ou il y avait souhait de sauvegarder toutes les données sur Internet. J'avais une sauvegarde globale de 4 To dont au moins 1,5 To de données redondantes en provenance de plusieurs postes et sans possibilité de connaitre la bonne version donc prise de toutes les données. Donc 1ère sauvegarde de 4 To puis mise à jour entre 5 et 20 Go via ADSL, donc solution matériellement impossible. Les prétentions ont donc été revu à la baisse.

Merci pour ta réponse "chrtophe".

Je suis tout à fait contient de tes différentes alertes ayant touchés à l'exploitation d'une grosse application par le passé.

Et tes remarques sont axées (je pense) "postes de travail".
J'essaie de définir une politique de sauvegarde qui doit donc englober tous les domaines de sauvegarde du SI. Le domaine "postes de travail" en est un composant.

C'est plutôt la partie sauvegarde des applications de production, recette et dev qui me pose problème et pour la quelle le problème me semble très complexe.
Les serveurs étant hétérogènes avec une grosse dominance: "serveur SAP".
La politique doit fournir une cible idéale de processus de sauvegarde qui pourra accepter des dérogations en fonction des contraintes techniques et financiers.

Mais je n'ai peut être pas été suffisamment précis...


Bonne année 2013!!! Je vous souhaite à tous plein de bonnes choses. ;)