Dominique RINGARD Architecte Réseau, Télécom, Sécurité et Système d Informations

Transcription

1 Dominique RINGARD Architecte Réseau, Télécom, Sécurité et Système d Informations XV ème Congrès de la Société Française d Informatique des Laboratoires VITTEL Mai 2015» 1

2 Petit Quizz Assertion Vrai Faux PRA & PCA ne s'appliquent qu'aux équipements informatiques Une copie bande à bande est acceptable dans un PRA/PCA Un cluster est efficace en PCA Un cluster est efficace en PRA Le calcul de la disponibilité n'inclut pas les arrêts planifiés 2

3 Introduction 3

4 Contexte Tout peut arriver Y compris l'improbable Le PRA concerne t'il les moyens informatiques, les réseaux télécoms ou les plateaux techniques également? Le support "follow the sun" est un PCA en fonctionnement permanent. On ne peut pas tout protéger, ni se protéger de tout, quelque soit le budget. La malveillance est le risque plus compliqué à protéger 4

5 Plan de Continuité d'activité Données x h Besoins Perte de données admissible? Interruption de service admissible? Méthodes Redondance massive (matérielle, géographique) Configurations froide, chaude, tiède? Référence CLUSIF Plan de Continuité d Activité Reprise 5

6 Objectifs du PRA / PCA Concepts 6

7 Lexique(1) Simple Suggestion PCA (Plan Continuité d'activité) Assurer la haute disponibilité des applications PRA (Plan Reprise d'activité) Assurer le redémarrage ordonné des applications en cas de défaillance ou de sinistre Sécurité d Exploitation. Absolument mettre en Place une Politique d Authentication Mettre en place une Vraie Poltique de suivi de Mise à Jour des Logiciels: Serveurs Informatiques et Postes de Travail Routeurs, Switchs, Firewall, PABX, Les Applicatifs Métiers ( Suite Bureautique, Navigateurs Internet, Site Internet ( CMS), Antivirus Mettre en Place une Politique de Préventions pour prévenir les Incidents. Former les Utilisateurs Mettre en Place une solution de Remontées Automatiques d Evénements Absolument mettre en Place une Politique d Authentication des Utilisateurs & Rôles Mise en Place d une Solution Centralisée d Annuaire de Sécurité ( Active Directory ou LDAP ) 7

8 Lexique(2) RPO (Recovery Point Objective) Temps entre le dernier état cohérent des données et le sinistre RTO (Recovery Time Objective) Temps nécessaire pour remettre l application en production 8

9 RPO/RTO en chiffres Le RTO est au minimum le temps de restauration des données et de mise en service des serveurs, ce qui pour des environnements complexes peut vouloir dire plusieurs heures voire plusieurs jours. Le RPO dépend de la fréquence des sauvegardes. Dans le pire des cas, il peut atteindre un ou plusieurs jours (notamment pour les applications dont les fenêtres de sauvegarde sont longues et qui ne sont sauvegardées qu une fois par jour, voire moins). 9

10 Lexique (3) Les 5 "9" Echelle d'indisponibilité essentiellement informatique De x jours à x minutes par an S'applique aux interruptions non planifiées Exemple Microsoft: 99,95 (deux datacenter en Europe investissement 300 M$ par datacenter) Exemple Télécom : Les Systèmes de Gestion des Appels sont conçus pour apporter un service de 99,99999 soit au maximum: 5,26 minutes/an ou encore 6,05 secondes/semaine. Les opérateurs ont mise en place la transparance de ces événements. 10

11 Les "5 nines" en chiffres Disponibilité (%) Arrêt / an Arrêt / semaine 90% ("one nine") 36.5 jours 16.8 heures 95% jours 8.4 heures 99% ("two nines") 3.65 jours 1.68 heures 99.5% 1.83 jours 50.4 minutes 99.9% ("three nines") 8.76 heures 10.1 minutes 99.95% 4.38 heures 5.04 minutes 99.99% ("four nines") minutes 1.01 minutes % minutes secondes % ("five nines") 5.26 minutes 6.05 secondes 11

12 Lexique (4) SPOF (Single Point of Failure) Elément de l'architecture qui bloque tout s'il tombe en panne. Il n'est pas nécessaire de corriger tous les "spof" mais il est important de les recenser tous. Fondamental : Prévoir une réponse en cas de problème. Un "spof" identifié est moins critique La solidité d'une chaine est celle de son maillon le plus faible. 12

13 Mise en œuvre Réaliser une cartographie du Système d Informatique actuel Le documenter 13

14 Assurer la redondance des Utilities Electricité Groupe électrogène Approvisionnement Test régulier Réseaux et Télécom Moyens Concevoir par essence un Réseau Résilient, Redondant pour ses Eléments Critiques S inspirer du mode de fonctionnement d Internet S inspirer du mode de la philosophie du Cloud Computing et de la Virtualisation Moyens internes ou externes Moyens Informatiques Sauvegardes et Archivage sont essentielles mais ne constitue pas un PRA Formation est essentielle, voire indispensable Personnel S inspirer du mode de fonctionnement des DataCenters Définir et Mettre systématiquement en place des Contrats de Supports 14

15 Phases Définition des objectifs ou Audit Initial Inventaire des ressources critiques Coût de l'arrêt, coût de la perte. Pour Réaliser un Audit. Ne surtout pas hésiter à faire appel à un Consultant Exterieur compétent sur ce sujet Documenter, Documenter!!! Cahier des charges ou Cartographie ( A valider selon le résultat de l audit) Décisions Coût de la protection versus cout de la perte Construction du plan Evaluation et Tests Tous les 6 mois 15

16 Il faut tout envisager Que le site "disparaisse" Les pandémies Le piratage. C est le sujet critique en ce moment. Les attaques du Système d Informations depuis l Internet. Leur ampleur est devenue majeure Ex : Coût du piratage Téléphonique en France : > 2 Milliards d en Source : BEFTI Le sabotage 16

17 Les données Bonnes pratiques Encadrer les utilisateurs pour le stockage des données, leur gestion et leur archivages. ( Dans certains cas, les former à leur récupération sera un plus) Banalisation des moyens de production de données. Protéger les données et assurer la possibilité de l'utiliser. Les Serveurs et Postes de Travail Définir une politique d exploitation et de supervision de ceux-ci. Mettre à Jour Remplacer les Ordinateurs qui ne sont plus supportés par ( OS par exemple) Les Réseaux et les Télécoms Mettre en place une Supervision Interne de tous les équipements actifs Sécurité Infrastructure Réseaux Définir un Politique de Sécurité globale d accès aux éléments stratégiques du LBM Veiller à ce l ensemble des versions des logiciels soient systématiquement à jour 17

18 Exemples Crédit Lyonnais (sinistre de la salle des marchés en 1997) Coût : 1,6 Milliard d Euros. Source : L arrêt d un DataCenter : de plus en plus coûteux.. Source : Cisco Blog fr-datacenter/2013/12/12 Réseau ( Infiltration ou pénétration) Pillage des données : 80 % TPE & PME victimes en 2013 d un piratage de données( Source : Etude IDC) Télécoms ( Phreaking) Coût > 2 Milliards d en 2013 ( Source Befti) Sécurité ( Virus) Fuite de données vers Internet!!! 18

19 DataCenter Répartition des machines dans les racks ou deux Salles Machines différentes Utilisation de VM ( Machines Virtuelles) pour redémarrage "instantané«. Celles-ci peuvent maintenant être mise en cluster Utilisation de snapshot (machines & données) Chaque donnée est copiée au moins en double Mise à niveau par vagues sans arrêter la production 19

20 Bascule / Retour Ne jamais oublier que le plan de secours comporte 2 étapes La bascule en mode secours Le retour au mode nominal 20

21 Légendes "urbaines" Le cluster ne protège efficacement que des pannes matérielles Pannes logiciel? Pannes d'environnement (électricité, feu, conflit). Erreurs humaines 21

22 Le PRA ne protège pas Outil de sécurité Plantage Malveillance Une politique d Exploitation et de Supervision est l une des réponse Externalisation en est une autre 22

23 Deux processus clés Gestion de la sécurité Processus global de gestion Basé sur la gestion du risque Gestion du risque Processus spécifique Fournit les éléments de décision Intégré dans la gestion de la sécurité Objectifs de sécurité Gestion Du Risque Analyse de risque Évaluation du risque Traitement du risque Basé sur la roue de Demming Plan Act Niveau de sécurité Do Check Temps Monitoring Processus Itératif 23

24 Objectifs de sécurité Objectifs de sécurité Basé sur les objectifs du business La sécurité n est pas un but en soi Entreprise S Objectifs business Objectifs de sécurité T Plan de réalisation Plan de sécurité O Réalisation Mesures de sécurité Stratégique, Tactique, Opérationnel 24

25 Analyse de risque Identifier les risques auxquels est sujet l organisation Rendre explicite l ensemble des aléas Partir des objectifs business et de sécurité Utiliser la connaissance du domaine Essayer d être exhaustif Itération lors des cycles des mises à jour Décrire les risques Garder trace des risques Nécessaire à la gestion continue Itération lors des cycles des mises à jour 25

26 Évaluation du risque Estimation De la Probabilité De l Impact Trois grands types d évaluation Haut Moyen P Très élevé (5) Très faible (1) Faibl (2) e Modéré (3) Impact Important (4) Majeur (5) Bas Elevée (4) Normal (3) Méthode simplifiée (une dimension) PxI Faible (2) Méthode semi quantitative P et I évalués séparément Quantitative (basée sur les courbes de probabilité) P finement VITTEL évalué

27 Traitement du risque Décision à prendre concernant le risque Refus Optimisation Transfert Prise de risque Des mesures à prendre dans le cas de l optimisation Prévention Protection Les mesures doivent rentrer dans une stratégie globale de réduction du risque 27

28 Mesures IT Impliquée IT peut déléguer Rappel distinction entre moyen et fin (résultat) La sécurité est un état du système (une fin, un résultat) Une mesure est un moyen pouvant contribué à résultat Le moyen en lui-même ne garantit pas le résultat ISO (ISO 17799) Catalogue de mesure (moyens) Organisée selon 11 chapitres thématiques 5. Politique (règlement) 6. Organisation de la sécurité de l'information 7. Actifs 8. Ressources humaines 9. Sécurité physique 10. Communications et exploitation 11. Gestion d'accès 12. Acquisition, développement et maintenance 13. Incidents de sécurité 14. Continuité 15. Conformité Se place au niveau opérationnel S T O 28

29 Les solutions Pour faire face aux défaillances matérielles, les solutions sont nombreuses : redondances (disques, cpu, mémoire, alim, ) hot swap (disques, mémoire, alim, ) clustering même si parfois difficile à mettre en œuvre site de secours pour faire face à un sinistre majeur Contre la malveillance, les solutions existent également : anti-virus, firewall, gestion des accès, détection d intrusion, il reste encore souvent à mettre en œuvre et à gérer Et ne surtout pas omettre de former les utilisateurs Mais face à l incident «logiciel», quelles parades? Établir des contrats de supports TRES formalisés 29

30 Les solutions préventives Le renforcement des tests et des procédures de mise en production oui pour les développements spécifiques mais les LBM n ont pas la maîtrise du plan de test des éditeurs. Ne pas hésiter à échanger sur ce point avec les Partenaires éditeurs. Discuter en amont des plans de tests Stratégie pour appliquer les nouvelles versions Le dilemme : Attendre un certain temps pour éviter de créer de l instabilité ou appliquer dès que possible pour bénéficier des corrections? Les correctifs doivent sans doute être appliqués rapidement, les versions majeures peuvent attendre Une documentation très précise des consignes d exploitation et de reprise souvent bénéfique, permet d éviter certaines erreurs de manipulation et diminue les temps d indisponibilité Intégrer la sécurité dans la conception des applications 30

31 Les solutions au cas où(1)... Les procédures de gestion manuelles de l activité de l entreprise Parfois complexes ou impossibles à mettre en œuvre, la dépendance par rapport au SI augmente sans cesse. Faire le maximum de supprimer toutes les adhérences. ( Exemple : Dépendance vis-à-vis des opérateurs) C est une étape souvent négligée dans la mise en œuvre d une nouvelle solution informatique Les moyens de restauration rapides Ils permettent de réduire l indisponibilité en cas de nécessité de rechargement des données La robotisation totale des sauvegardes est bénéfique Attention à suivre l augmentation des volumes et la conséquence sur les temps de restauration 31

32 Les solutions au cas où (2)... La réplication des données Les données sont répliquées sur un système de secours Cela permet de gérer les problèmes de corruption bas niveau Les solutions existent pour les bases de données ou les fichiers Faut-il répliquer en temps réel pour ne rien perdre ou conserver un délai pour faire face à un incident du type corruption ou pollution de données? Faut-il laisser le système de secours en version N-1 du logiciel? La procédure et les conditions de bascule/retour doivent être définies précisément Les solutions de contournement ou «bypass» Elles consistent à mettre à disposition des utilisateurs un système en mode dégradé Ces solutions sont rarement prévues lors de la conception L activation en mode forcé doit être prévue car le système ne détecte pas toujours une panne «logicielle» qui n est pas toujours franche 32

33 Exemple d un LMB avec deux plateaux techniques Arrivée électrique 1 Brassage réseau 1 1 Cluster Par Baie Virtualisation Redondance Physique Logique Application Echange de messages Node Server Node Node CPU Mémoire CPU Mémoire CPU Mémoire Arrivée électrique 2 Brassage réseau 2 1 Cluster Par Baie Virtualisation Redondance Physique Logique RESEAU IP VPN MULTI-SITES ETENDU TRES HAUT DEBIT 33

34 Gestion de la sécurité Processus global de gestion Basé sur la gestion du risque Gestion du risque Processus spécifique Fournit les éléments de décision Intégré dans la gestion de la sécurité Haut Moyen Bas Les coûts P Très élevé (5) Elevée (4) Normal (3) Gouvernance Stratégique et Opérationnelle du Système d Informations. Grille de Critère de décision Très faible (1) Faibl (2) e Modéré (3) Impact Important (4) Majeur (5) Méthode simplifiée (une dimension) PxI Faible (2) Méthode semi quantitative P et I évalués séparément Quantitative (basée sur les courbes de probabilité) P finement évalué34

35 Mythes Le PRA dépend de la stratégie de sauvegarde et d archivages des données Le PCA dépend des mécanismes de réplication online La mise en place d une politique d Exploitation Interne apporte la prévention et une grande souplesse pour gérer le PCA et le PRA 35

36 Ne jamais négliger le facteur humain En cas de défaillance, la pression sur les équipes est forte. Il ne faut laisser aucune place à l'improvisation. D où un jeu de procédures le plus exhaustif possible et des répétitions pour les éprouver. Documenter, Documenter!!! Organiser des formations régulières sur les usages pour les utilisateurs. Développer la culture de l expérience utilisateur. Former, Former!!! 36

37 Moyens à disposition Site de secours Camions ( de plus en plus à envisager) Hébergement Cloud 37

38 Site de secours Si le site de secours est "trop près", il peut être affecté par la même interruption de moyens que le site principal. Si le site de secours est "trop loin", les liens télécom et les coûts peuvent être des freins potentiels. Les débits réseaux deviennent de moins en moins un problème Les technologies de Clusters de Machines Virtuelles sont maintenant opérationnelles 38

39 Site Mobile 39

40 Hébergement Cloud Le Cloud reporte une grande partie du PRA/PCA sur l'hébergeur. Seul frein, la volumétrie des données à transférer vers le Cloud Mettre en place une architecture de Sauvegarde et Archivage en local avec une réplication dans l hébergement Cloud. S assurer que l hébergement Cloud respecte bien l hébergement des données de santé 40

41 Conclusion La mise en place d une politique PCA et PRA minimaliste devient critique La solidité d une infrastructure Réseau, Télécom et Téléphonie y contribue de plus en plus Automatiser ou Robotiser les solutions de sauvegardes et d archivages de données Intégrer les nouveaux services du Cloud Computing Une bonne politique d exploitation et la supervision est le meilleur garant d un bon système d informations opérationnel et performant 41

42 Le principe de PRA/PCA s'applique au quotidien Si on vous vole votre PC portable ou votre gsm, comment retrouvez-vous vos données. Si vous n avez pas protégé vos données!!! 42

43 Merci de votre attention 43

44 Questions/Réponses 44