Bonjour,
Bon, dans mon constant effort de ne pas mourir idiot, j'aimerais savoir s'il existe un guide, une doc ou des conseils en ce qui concerne les catastrophes informatiques. En fait, je cherche peu l'équivalent des plans catastrophes de la protection civile mais à une échelle bien moindre (un réseau d'entreprise). Du genre, quand une intrusion est détectée, appuyer cliquer sur le gros bouton rouge, ou un truc du genre. En fait, quelles sont les règles à suivre lorsque l'on constate un problème informatique (quel qu'il soit !).
Journal Situation de crise et informatique
25
août
2003
# Re: Situation de crise et informatique
Posté par PloufPlouf (site web personnel) . Évalué à 1.
quelques idées (que j'applique)
en cas d'intrusion constaté en temps reelle c'est là que j'appuierais moi
apres t'epluche les log pour trouver comment c'est arrivé...
sinon sauvegarde reguliere, sur disque et sur bande, perso je sors de la bande de la semaine des locaux et celle du mois est en double...
firewall, antivirus sur le serveur de mail (mis a jours, a chaque alerte)
mot de passe qui expirent, et education de tes utilisateurs (patience et longueur de temps...)
physiquement, portes fermées, verous, alarme
[^] # Re: Situation de crise et informatique
Posté par jmfayard . Évalué à 0.
# Re: Situation de crise et informatique
Posté par Fabien Jakimowicz . Évalué à 1.
Apres un bon epluchage de logs, bash history, checksum md5 et fichier dont la date semble incoherente ...
# Re: Situation de crise et informatique
Posté par rootix . Évalué à 2.
Rien ne remplace une bonne sauvegarde dans un endroit sûr et avec de manière régulière, le déplacement des cassettes dans une armoire anti-incendie, et aussi chez soit à la maison ou dans une banque si tes données sont très confidentielles.
Il y a des livres très bien fait sur ça, renseigne-toi.
Une sonde informatique réclame beaucoup de CPU et d'espace disque vu la quantité de donnée à analyser, pèse le pour et le contre.
Ce sujet est très vaste pour être aborder ici.
Bon courage !
# A ne pas oublier également..
Posté par mcben . Évalué à 3.
Néanmoins et s'il s'agit d'une infrastructure critique notamment, il est bon de préparer un plan de restauration des données.
Des idées en vrac: s'entrainer à rétablier les données rapidement, rédaction de procédure, définition des priorités (quelle machine à restaurer en premier), écriture de script de restauration automatique, définir des degrés de gravité (jusqu'à quel point ne pas réinstaller complètement la machine), etc..
J'ai un pote qui a fait un stage à la sncf à lille (dans le bunker avec toute l'infrastructure informatique régionale, voire nationale), au service sécurité..
Et croyez-moi, sa mission principale n'était pas de mettre à jour les antivirus et checker les logs du (des?) firewalls.. Avec son équipe, il était chargé d'imaginer toutes les situations qui pouvaient se produire (incendie, explosion, vol, etc..) et de voir (et compter) jusqu'à quel degré il était rentable de se prémunir contre ces problèmes, pour ensuite faire des recommandations à la DG.
Parce que avoir un taux de fiabilité de 99%, c'est pas super difficile, et pas trop cher... Par contre, pour passer à 99,99% puis à 99,999%, là, tu peux allonger la monnaie.
Je pense également à un truc tout con, vis à vis des utilisateurs finaux, genre la secrétaire, et les mots de passe.. On dit toujours qu'il faut des mots de passe complexes, avec des lettres, des chiffres, des signes de ponctuation, afin qu'il ne soit pas présents dans les dictionnaires.
Seulement, ne vaut-il pas mieux laisser les utilisateurs finaux adopter des mots de passe simple (genre le nom de leur chat) mais que seul ceux-ci connaissent et gardent confidentiel, plutôt qu'un mot de passe de la mort qui tue, écrit en bleu fluo sur un post-it collé au coin de leur écran ?
[^] # Re: A ne pas oublier également..
Posté par redfish . Évalué à 1.
Un compromis peut-être de laisser l'utilisateur choisir son mdp, mais d'imposer une longueur de 10-12 caractères ( avec lettres + chiffres ), et d'imposer son renouvellement tous les x mois ( quoique sur ce point, tu risques d'avoir quelques retours de mécontents ).
R.
[^] # Re: A ne pas oublier également..
Posté par jmfayard . Évalué à 0.
Une bonne méthode classique pour avoir un mot de passe à la fois facile à retenir et résistant aux attaques par dictionnaires est de se choisir une phrase et d' en prendre les initiales.
Exemple :
Longtemps Je Me Suis Couché De Bonne Heure
==> Ljmscdbh , puis tant qu'à faire
s/de/2/ s/a/@/ s/et/&/ , ....
D'où Ljmsc2bh
Bref, un peu de pédagogie et ça passe.
[^] # Re: A ne pas oublier également..
Posté par Pierre . Évalué à 1.
c'est du vécu?
[^] # Re: A ne pas oublier également..
Posté par mcben . Évalué à 1.
J'ai exagéré sur le bleu fluo, mais en stage dans une petite agence commerciale FT, 3 postes dans le bureau, avec chacun un post-it récapitulant les mots de passe des 3 machines.
+ le super mot de passe pour accéder à l'appli de compta (vous savez, le truc d'intranet qui tourne sous OS/2 et qui fait tout, de la prise de commande, à la gestion comptable, en passant par la gestion des stocks, etc..)
Bref, moi qui était la pour 2 mois à faire de l'access tout bidon, j'aurai pu m'amuser à la pause du midi.. hum.
[^] # Re: A ne pas oublier également..
Posté par cozon (site web personnel) . Évalué à 2.
et aussi les utilisateurs qui me donnent leur mot de passe sans qu'on leur demande quand on vient les dépanner.
une mention spéciale à une utilisatrice qui devait changer de mot de passe tous les mois, ne jamais remettre un mot de passe déjà utilisé, utiliser des chiffres et des lettres, et avoir une longueur mininale de 4 ou 6 caractères : en février 1999, son mot de passe était fevrier99, en mars mars1999, etc ....
tout ça pour dit que la sensibilisation des utilisateurs, c'est bien.
# Re: Situation de crise et informatique
Posté par Maillequeule . Évalué à 4.
En gros, calculer combien de temps on peut travailler sans un service ou un serveur donné. Une heure ? Une journée ? Une semaine ?
85 % des entreprises qui ont connu un crash/destruction d'un serveur de fichiers principal déposent le bilan dans les 6 mois : Et on vous refuse encore un lecteur de bande parce que ca coute cher ?
Ensuite il faut partir d'un principe simple : Combien de temps me faut-il pour remonter le même serveur, avec un niveau de service suffisant pour travailler, même en mode dégradé.
A partir de là on peut avoir l'esprit un peu tranquille : On peut repartir de zéro. L'analyse des logs, le nez dans les alertes de sondes d'intrusion (4 Go / jour, pour quoi faire ?), c'est le plus souvent du pipeau.
Une DMZ, c'est du jetable. Il faut pouvoir tout jeter et reinstaller en moins de x heures (perso on compte en minutes).
L'analyse post-mortem, c'est pour plus tard :)
Multiplier, dupliquer, sauvegarder, faire des masters ... C'est déjà un meilleur départ. A condition de s'assurer (pas comme toi, là bas à gauche), que les sauvegardes sont restaurables aussi sur une machine d'une autre marque avec un lecteur d'un modèle pas identique. Parce qu'en cas d'incendie ... rien ne vous dit que vous aller trouver le lecteur de vos rêves. Rigolez pas, ca donne des sueurs les lecteurs qui "bougent" avec le temps et ne savent lire que ce qu'ils ont écrit. J'en tremble encore.
J'en vois un autre au fond qui garde toutes les docs d'installation des machines sous forme electronique uniquement ... Rigolez pas, c'est un classique.
Bref, je vis comme si demain tout devait partir en fumée, et malgré tout l'esprit tranquille.
Les outils existent, ce serait dommage de ne pas en profiter.
M
# Re: Situation de crise et informatique
Posté par Pooly (site web personnel) . Évalué à 1.
hein, perso :
Raid 1 + réplication + UPS + backup.
les crashs de disque durs en série, c'est pas qu'en cauchemar.... (argh!!!)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.