Sécurité de
l’Infrastructure
Jean-Noël Colin
jean-noel.colin@fundp.ac.be
Agenda
Introduction Single System High Availability Connectivité
Disaster Recovery Data management Monitoring
Contract matters
Introduction
Qu’est-ce que l’infrastructure?
Matériel
Ordinateurs (postes individuels, serveurs) Stockage
Backup
Imprimantes
…
Réseau Datacenter
Loi de Murphy: “si quelque chose peut mal tourner, alors cette chose finira infailliblement par mal tourner”
Loi de Moore (1965):
le nombre de transistors dans une puce double tous les 24 (18) mois.
Introduction
Introduction
Les capacités de stockage augmentent plus vite que la loi de Moore
Kryder dans Scientific American, 2005:
Capacité et performance des différents composants augmentent, mais pas au même rythme
Impact sur les systèmes et les applications
Croissance annuelle (%)
Complexité CPU 50
Capacité mémoire 60
Vitesse accès mémoire 10
Capacité disque 60
Vitesse disque 25
Vitesse réseau 40
Introduction
Objectifs de sécurité pour l’infrastructure Confidentialité
Probablement moins important...
Plus lié au contrôle d’accès
Integrité Availabilité
Continuité du business
IT en support au business
Continuité des opérations IT
Autres termes:
RAS – Reliability, Availability, Serviceability
Introduction
Disponibilité impactée par
Organisation du travail: heures de bureau ou 24x7?
Intervention planifiée
Opération de maintenance Panne:
deux mesures:
MTBF – Mean Time Between Failure MTTR – Mean Time To Repair
Disponibilité = MTBF/(MTBF + MTTR) MTTR plus facile à améliorer que MTBF
Meilleur matériel/vendeur Meilleur contrat de support
Introduction
Fiabilité
Probabilité qu’un système ou un composant sera disponible sur une période de temps donnée
Maintenabilité
Mesure de la facilité avec laquelle un système peut être maintenu ou réparé
Aussi simple que possible, aussi
complexe que nécessaire
Fiche produit Sun Storage J4400
Array
Introduction
Introduction
1.2M hrs MTBF
≈ 136 ans
Introduction
Menaces Panne
Erreur humaine Acte intentionnel
Catastrophe naturelle
Principes généraux (parfois difficiles à concilier) Robustesse
Minimiser la probabilité de panne Viser la simplicité: KISS
Redondance
Eviter les ‘Single Points of Failure’
Granularité des observations
Différents niveaux: composant - système
Introduction
Redondance
Il ne suffit pas de dupliquer...
il faut aussi gérer...
Gestion des pannes Basculement (failover)
Gérer l’état sur les composants dupliqués
Vue simplifiée de l’ordinateur
Système isolé
Système isolé
Fiabilité du matériel
Système isolé
Processeur (CPU)
Multiples CPU
Multiples cartes CPU Activer/déactiver
Hot swap
Memoire
Détection d’erreur Correction d’erreur
“Memory scrubbing”
Système isolé
Bus système et backplane
Interconnection des composants Reprise sur panne limitée
Requiert simplicité et robustesse Interfaces I/O
Connexions vers le monde extérieur Duplication possible
‘Failover’ manuel ou automatique
Possibilité de vitesse de transfert accrue Hot swap?
Cables et connexions
Longueur, étiquettage, placement
Système isolé
Système isolé
Alimentation
Configuration n + 1, n + 2 Ventilateur = maillon faible
Alimentation redondantes (jusqu’aux lignes) UPS
Interventions sur le matériel
Peuvent causer de nouveaux problèmes Nécessitent
soin
formation outils
ex: tapis anti-statique
Système isolé
Stockage de données
Support magnétique Parties mobiles
Risque de panne relativement élevé
Données stockées dans des fichiers
Fichiers stockés sur disque et organisés en système de fichiers (file system)
Disque données vs disque système Que faire en cas de panne disque?
Restaure le contenu du backup
Système isolé
Système de fichiers
Définit comme les données sont physiquement organisées sur le disque Fonctionalités
Journaling, liens, support de la casse des caractères, chiffrement
Meta-données
Nom, dates (création, modification), permissions, contrôle d’intégrité
Allocation de l’espace Limites
Taille (fichier, filesystem, nom de fichiers…), nombre d’entrées
FAT, NTFS, VxFS, UFS, EXT3, ReiserFS, ZFS, QFS…
Système isolé
HSM - Hierarchical Storage Management
Motivations
Patterns d’accès aux données
Différents ratios Capacité/Coût selon le medium Besoin en croissance constante
Idée
Choisir le medium en fonction du pattern d’accès
Exemple: SamFS
Système isolé
RAID
Redundant Array of Inexpensive Disks
<> SLED – Single Large Expensive Disk Différents niveaux combinables
Exploite 3 mécanismes
Mirroring Striping
Contrôle de parité
Système isolé
Raid 0 - Striping
Pas de redondance
Répartit la charge sur plusieurs disques Contrôleur unique?
Permet d’aller au-delà de la capacité individuelle d’un disque Deux paramètres
#disks (largeur du stripe)
#Bytes per chunk (taille du stripe) Difficile à optimiser:
trop petit: utilisation équitable des disques, mais fichiers éclatés entre plusieurs chunks trop grand: overhead minimum lors de l’accès aux données, mais utilisation non
équitable des disques,
Panne d’un seul disque implique perte de données
Système isolé
Système isolé
Raid 1 - Mirroring
Redondance
Disque 1 et Disque 2 sont identiques
Ecriture plus lente
Lecture plus rapide si concurrence Coût de stockage doublé
En cas de panne, remplacement du disque et re-construction du miroir
Système isolé
Système isolé
Raid 5 – Striping + contrôle de parité n-way RAID 5:
n-1 data chunk + 1 chunk de parité
Lecture efficace: distributée entre les disques Ecriture peu efficace
Nécessite reads + 2 writes
Taille d’écriture importante ➪ pas besoin de lecture
Efficacité de l’utilisation de l’espace (n-1)/n
En cas de panne, remplacement du disque et reconstruction des chunks perdus
Opération lente car nécessite de relire l’entièreté du stripe
Système isolé
Système isolé
Raid 10 – Stripe de miroirs Résumé
RAID #disques Efficacité Fiabilité Reconstr uction
Seq.
Read
Rnd Read
Seq.
Write
Rnd.
Write
0 2,3… n 0 ∞ ++ + ++ +
1 2 n/2 ++ + + + 0 0
5 3,4… (n-1)/n + - + + - -
10
Système isolé
Software RAID et Volume Manager
Veritas Volume Manager, LVM, DiskSuite…
Configuration définit le lien entre les volumes logiques et les volumes physique
Configuration doit être sauvegardée de manière sûre (plusieurs fois sur des appareils différents)
Volume Manager joue le rôle de ‘driver’ pour les couches supérieures Consomme des ressources
Hardware RAID Controller
Contrôleur spécialisé/disques connectés directement
Plus efficace car toutes les opérations sont réalisées en hardware
Système isolé
Appareil dédié au stockage
Solution complète et intégrée, incl. CPU et mémoire Fonctionnalités avancées
Snapshot
Split mirror ou Copy on write Remote copy
EMC, SUN/StorageTek
Système isolé
Système isolé
Virtualisation
Infrastructure virtualisée
Partage de ressources entre plusieurs ‘clients’
Ex: Timesharing, mémoire virtuelle, volumes logiques, réseaux virtuels
Motivations
Cost-effectiveness: nombreux systèmes sous-utilisés Consolidation
Gain d’espace Maintenabilité Gain d’énergie
High-Availability
Cluster pour high-availability
Redondance au niveau du système
Solution aux pannes hardware et OS
Solution aux problèmes d’environnement en cas de DRP
Service dissocié d’un hôte physique, mais attaché à un hôte logique Types de clusters
Cluster Failover
Le service bascule d’un noeud à l’autre Cluster en distribution de charge
Le service est exécuté sur plusieurs hôtes simultanément
Cluster Failover
Storage Storage
Service A
Host B Host A
High-Availability
High-Availability
Cluster failover
Configuration du cluster Etat partagé
Communication Inter-node Heartbeat
Quorum device Intégration d’un service
Comment démarrer/arrêter/vérifier?
Ressources nécessaires: volumes logiques, adresses IP...
Noeud préféré Basculement
Timeout, ping-pong Syndrôme de ‘Split brain’
Dépendances entre services
High-Availability
Cluster Load-balancing
Principalement pour des services stateless
Web servers, directory services (LDAP, AD, DNS…) Fermes de serveurs
Répartir la charge des requêtes entrantes entre différents serveurs offrant le même service
Algorithme de distribution peut être simple (round-robin, déterministe) ou plus complexe, intégrant par ex. les caractéristiques des noeuds
DNS Load balancing, IP load balancing, reverse proxies
Connectivité
Réseau
Menaces
Disponibilité
Panne de composants Interruption de liaison Confidentialité
Ecoute passive (eavesdropping) Contrôle d’accès
Integrité
Modification des communications Brouillage
Connectivité
Réseau
Disponibilité
Redondance NIC
Segment network Fournisseurs
Type de connexion
Connectivité
Réseau
Confidentialité
le réseau est la porte d’entrée vers le serveur...
et vers l’organisation...
Firewall
Filtrage de paquets Inspection stateful Passerelle applicative DMZ
VPN
Tunnel sécurisé sur un lien non-sécurisé utilisateurs nomades
Datacenter
Solution complète
Installations
Sol surélevé, cablage, contrôle d’accès
Moyens mis en oeuvre
HVAC - Heat, Ventilation, Air Conditioning
Densité des systèmes accroit le problème de chaleur Placement des racks
Flot d’air dans la pièce Température: 18°C
Dimensionnement de l’AirCo
Composant critique Redondance!
Datacenter
Datacenter
Moyens mis en oeuvre Incendie
Détection
CO2, Halon, FM-200, Inergen
Alimentation
UPS
Connexions redondantes Générateurs diesel
Ne pas mettre tous les systèmes sous tension en même temps!
Dépendances entre systèmes
Quel(s) système(s) est(sont) impactés si le système X tombe en panne?
Datacenter
Procédures de gestion
ITIL – Information Technology Infrastructure Library
IT Service Delivery IT Service Support
Service desk, Incident Management, Problem Management, Configuration Management, Change Management, Release Management
Staff dédié
Objectifs
Répondre à un incident majeur
Inondation, typhon, tremblement de terre, attaque terroriste, incendie...
Corruption de système(s) ou de données Erreur applicative ou humaine
Solution: Site de Disaster Recovery Site Et les procédures…
Site DR souvent limité mode dégradé Définir les composantes du DR
Tous les services n’ont pas besoin de DR Que doit-on protéger?
Quelle est la priorité des services?
Quelles sont les ressources nécessaires?
Disaster Recovery
Disaster Recovery
Incident et reprise
Data recovery point Disaster occurrence
Disaster noticed Disaster declaration Disaster Recovery System Active Primary System Functional
Time
Don’t forget this one!
RPO
RTO
Disaster Recovery
Quelques statistiques
Une perte de données importante implique la fermeture de la société dans 43% des cas
Une indisponibilité de 10 jours n’est en général pas récupérable
La plupart des pertes de données ont une cause humaine (45%), 2% sont causés par des catastrophes naturelles, le reste par des pannes
Disaster Recovery
Différences avec HA
Implication du côté ‘métier’
Plus seulement un problème IT
Indisponibilité plus longue Composants impactés
plus nombreux, plus grande taille
Risque et coût plus élevés Processus différents
Opérations manuelles
Disaster Recovery
Approche générale
Définition des objectifs
Identification des systèmes
Définition des objectifs de récupération (RTO, RPO), staff et responsabilités
Design high-level de la solution Design technique de la solution Implémentation de la solution
Définition des procédures et formation Test, Test, Test
Evaluation et mise à jour
Disaster Recovery
Site primaire et de backup (DR)
Propriété de la société?
Accord mutuel?
Externalisé?
Où placer les sites?
Ni trop près, ni trop loin
Eviter les risques identiques (ex: zone d’activité sismique)
Disaster Recovery
Synchronisation des sites
Hot stand-by
Site DR est une copie exacte du site primaire
Cold stand-by
Nécessite une restauration de données
Possibilité d’héberger l’infrastructure de backup pour une restauration rapide (et conservation plus sûre)
Système partagé
Disaster Recovery
Synchronisation longue distance
Mirroring asynchrone Restauration de backup Log shipping
Cluster longue distance Synchronisation de fichiers
Sécurité des données
Données = ressource critique Objectifs
Reprise après panne
Récupération d’une version antérieure
Deux opérations
Sauvegarder Restauration
Sécurité des données
Sauvegarde
Copie des données d’un medium vers un autre Quand?
Fréquence
A quel moment?
Quoi?
Backup système Backup fichiers
Backup bases de données Full/Incremental
Sécurité des données
Sauvegarde Où?
On-site: copie locale Off-site: copie distance Conditions de stockage Restauration
de données préalablement sauvegardées Test, Test, Test
souvent oublié, jusqu’à ce que...
Mantra: LOCKSS
Truc: utiliser un réseau séparé pour le backup
Surveillance
La sécurité de l’infrastructure nécessite surveillance
qualité de la surveillance
éviter faux négatif/faux positifs seuil d’alerte
Outils
Patrol, OpenView, Nagios…
Sondes spécifiques
alerte
Email sms
équipe de support
procédures de reporting et d’escalation
Et les contrats...
Choix d’un produit/vendeur
Ligne de produit: flexible, modulaire, à la pointe Roadmap?
Visite de site
Ouverture/Possibilité d’intégration Partenariats existants
Equipe/ressources locales Organisation de support
Et les contrats...
Contrat de support
conclu avec vendeurs hardware et software différents niveaux de support (et de prix) SLA – Service Level Agreement
définit le service
définit les exigences en matière de disponibilité
y compris les aspects de performance exigences réalistes!!
indisponibilité cumulée maximum sur une période fréquence d’indisponibilité maximum sur une période indisponibilité maximum par incident
Et les contrats...
SLA – Service Level Agreement
différencié selon l’importance de la panne (minor/major outage) définit les plages d’indisponibilité planifiée
définit les responsabilités et les procédures
définit les mécanismes de reporting et d’escalation définit les pénalités en cas de non-respect
entre partenaires internes ou avec un tiers
