Sur Terre et dans l'espace...... où l'échec n'est pas une option RAPPORT D'AUDIT - SÉCURITÉ ET PERFORMANCES DES SERVEURS SERVICES DE CONSEIL SERVICE AUDIT
Cette page est laissée vide volontairement
Rapport d'audit - Sécurité et Performances des Détails du Document Catégorie Niveau de Classification Langue Services de Conseil FR - Français Date de Rédaction jeudi 16 mai 2013 Date de Génération @ 23:06:30 Auteur(s) Division Validation Technique Validation Managériale Acceptation Client Guillaume REMBERT Guillaume REMBERT Guillaume REMBERT Service Audit Validation Client Nom Entreprise Fonction Date Liste de Distribution Avant-Propos Avertissement Autorité de Publication Copyrights Ce document est un exemple de rapport d'audit sur la sécurité et les performances des serveurs. Euryece Telecom ne fait aucune assertion et ne donne aucune garantie, expresse, implicite ou légale, concernant notamment, mais non limité à : l exactitude, l actualité ou l exhaustivité des renseignements fournis, l absence de tout défaut et d'erreurs. En aucun cas, Euryece Telecom ne sera responsable des dommages prévisibles ou imprévisibles, directs ou indirects, découlant de tout ce qui précède et suit, ou de l utilisation autorisée ou non autorisée du présent document et des renseignements qui y figurent, ou de l accès autorisé ou non autorisé à ceux ci, notamment de toute mesure prise ou omission commise par une personne à cet égard. Sans en limiter la portée, Euryece Telecom ne sera en aucun cas responsable des dommages particuliers, indirects, consécutifs ou punitifs. Euryece Telecom 16 Place du Général de Gaulle 59 000 Lille FRANCE Tous droits réservés Euryece Telecom & Guillaume REMBERT Ce travail est licencié sous licence «Creative Common Attribution-ShareAlike 3.0 Unported» (CC BY-SA 3.0)
Cette page est laissée vide volontairement
Page 5 de 31 LISTE DES CHANGEMENTS Version Date Nom Détails 0.01 G. REMBERT Version initiale
Page 6 de 31 TABLE DES MATIÈRES 1 INTRODUCTION...8 2 DOCUMENTS APPLICABLES ET RÉFÉRENCES...9 2.1 Documents Applicables...9 2.2 Documents de Référence...9 3 TERMES, DÉFINITIONS ET ABRÉVIATIONS...10 4 CONTEXTE...11 4.1 Parties Prenantes...11 4.1.1 Acteurs Internes...11 4.1.2 Acteurs Externes...11 4.2 Problème...12 4.2.1 Besoins et exigences...12 4.2.2 Cas d'utilisation...13 4.2.3 Environnements associés...14 4.2.4 Moyens Existants...15 5 MESURES...16 5.1 Performances...16 5.1.1 Réseau...16 5.1.2 Stockage...19 5.1.3 Calcul...22 5.1.4 Charge...23 5.1.5 Disponibilité...25 5.2 Sécurité...26 5.2.1 Vulnérabilités apparentes du serveur...26 5.2.2 Sécurité des sites web...26 5.2.3 Sécurité des Informations...27 5.2.4 Sécurité remarques hors du périmètre d'intervention...27 6 ANALYSES...28 6.1 Performances...28 6.1.1 Réseau...28 6.1.2 Stockage...29 6.1.3 Calcul...30 6.1.4 Charge...30 6.2 Sécurité...30 6.2.1 Serveur...30 6.2.2 Sites web...30 6.2.3 Informations...31 6.2.4 Hors périmètre...31
Page 7 de 31 LISTE DES FIGURES (1)Acteurs ENTREPRISE... 11 (2)Acteurs Externes... 11 (3)Evolution de la fréquentation du site en fonction de l'heure...12 (4)Cas d'utilisation du service web... 13 (5)Environnements du service web...14 (6)Occupation du disque système... 19 (7)Occupation du disque Stockage...19 (8)Occupation du dossier web... 19 (9)Performances en écriture, mesurées en Kilo-Octets par seconde, en fonction de la taille du fichier et de la taille de l'enregistrement... 21 (10)Performances en ré-écriture, mesurées en Kilo-Octets par seconde, en fonction de la taille du fichier et de la taille de l'enregistrement... 21 (11)Performances en lecture, mesurées en Kilo-Octets par seconde, en fonction de la taille du fichier et de la taille de l'enregistrement... 21 (12)Performances en relecture, mesurées en Kilo-Octets par seconde, en fonction de la taille du fichier et de la taille de l'enregistrement... 21 (13)Performances en lectures aléatoires, mesurées en Kilo-Octets par seconde, en fonction de la taille du fichier et de la taille de l'enregistrement...21 (14)Performances en écritures aléatoires, mesurées en Kilo-Octets par seconde, en fonction de la taille du fichier et de la taille de l'enregistrement...21 LISTE DES TABLES 1.Documents Applicables... 9 2.Documents de Référence... 9 3.Acronymes... 10 4.Définitions... 10 5.Détails de la configuration technologique actuelle...15
Page 8 de 31 1 INTRODUCTION Dans le cadre de la mise en place d'un plan de reprise d'activité, un audit et des mesures ont été réalisés pendant la semaine du X au X. Ce document est un exemple de ce qui fut réalisé. Pour de nombreuses raisons, de nombreux détails ont été volontairement retirés de ce document.
Page 9 de 31 2 DOCUMENTS APPLICABLES ET RÉFÉRENCES 2.1 Documents Applicables Référence Document N Titre [AD1] ET-LEG-OCON-X Aspects Juridiques Contrat de services 1. Documents Applicables 2.2 Documents de Référence Référence Document N Titre [RD1] WebDev 17 17-1 - 1211 Serveur D'Application WebDev 17 2. Documents de Référence
Page 10 de 31 3 TERMES, DÉFINITIONS ET ABRÉVIATIONS Acronyme ANSSI Signification BGP «Border Gateway Protocol» BP BS Agence Nationale de la Sécurité des Systèmes d'information Besoin Primaire Besoin Secondaire CPU «Central Processing Unit» DDR «Double Data Rate» FLOPS «Floating Point Operation Per Second» FTP «File Transfer Protocol» GTR Garantie de Temps de Rétablissement IP «Internet Protocol» I-SCSI «Internet Small Computer System Interface» MIPS «Million Instructions Per Second» NAS «Network Attached Storage» NTFS «New Technology File System» OS «Operating System» RAID «Redundant Array of Independent Disks» RAM «Random Access Memory» RPM «Revolutions Per Minute» SAN «Storage Area Network» SAS «Serial Attached SCSI» SCSI «Small Computer System Interface» SMTP «Simple Mail Transfer Protocol» VM «Virtual Machine» 3. Acronymes Terme Définition 4. Définitions
Page 11 de 31 4 CONTEXTE 4.1 Parties Prenantes 4.1.1 Acteurs Internes (1)Acteurs ENTREPRISE 4.1.2 Acteurs Externes (2)Acteurs Externes
Page 12 de 31 4.2 Problème 4.2.1 Besoins et exigences fait appel à des services d'hébergement de serveurs dans le cadre de son activité commerciale. Besoins primaires : - BP1 : fournir à ses clients des solutions sous le modèle SAAS («Software As A Service»), c'est-à-dire à l'aide d'un simple accès web via un navigateur internet, - BP2 : gérer la messagerie électronique liée aux applications web l'entreprise. Besoins secondaires : - BS1 : fournir à ses clients un espace de test permettant d'évaluer les dernières innovations de l'entreprise, - BS2 : fournir à ses clients un espace de stockage distant pour simplifier le partage des données. La mission actuelle est liée aux besoins BP1 et BS1, c'est à dire, la mise en place d'un service web. Les exigences de niveau de service d', vis-à-vis de celui-ci sont, selon [AD1] : - % de disponibilité (H à H à ), - utilisateurs simultanés en pic de charge. NB : Suite aux analyses approfondies, la période de disponibilité nécessaire est étendue de H à H. (3)Evolution de la fréquentation du site en fonction de l'heure
Page 13 de 31 4.2.2 Cas d'utilisation (4)Cas d'utilisation du service web On peut distinguer principalement 4 cas d'utilisation : - L'installation d'un service web par le département technique, - La mise à jour d'un service web par le département technique, - La démonstration d'un service web par le département commercial, - L'utilisation d'un service web par les clients.
Page 14 de 31 4.2.3 Environnements associés (5)Environnements du service web On peut différencier les environnements suivants : - EHx : Environnement Hébergeur 1, 2,, N (le lieu physique du(es) serveur(s) ainsi que le raccordement à internet associé), - EI : Environnement Internet (les différents réseaux des fournisseurs d'accès à internet ainsi que leurs interconnexions on parle de points d'appairage - «peering»), - EC : Environnement Client (le lieu physique d'utilisation du service web ainsi que le raccordement à internet associé), - EF : Environnement Fournisseur (le lieu physique d'administration et démonstration du service web ainsi que le raccordement à internet associé).
Page 15 de 31 4.2.4 Moyens Existants Aujourd'hui, ENTREPRISE fait appel aux services de X afin d'héberger leur service web. Aspects contractuels et financiers X X Aspects technologiques Configuration Centre Physique Matériel Accès au Réseau Accès à Internet Hyperviseur(s) Machine(s) Virtuelle(s) Applicative Services Réseau CPU RAM OS HDD Réseau Détails 5. Détails de la configuration technologique actuelle X Aspects Humains X Aspects écologiques
Page 16 de 31 5 MESURES 5.1 Performances 5.1.1 Réseau Protocoles réseau : Ces tests ont été réalisés à l'aide de la commande «ipconfig» et «ping» : IP v4 : ping google.fr IP v6 : ping -6 google.fr Débits : Ces tests ont été réalisés à l'aide de l'outil Iperf http://iperf.fr/, entre un serveur dédié X et le serveur X, en laissant les paramètres par défaut : Commande sur le serveur : iperf -s Commande sur le client : iperf -c machine.domaine.racine -r Le // @ H et le // @ H, des débits utiles TCP symétriques, compris entre et MBits/sec ont été mesurés.
Page 17 de 31 Délais : Ces tests ont été réalisés à l'aide de l'outil ping, entre un serveur dédié X et le serveur X, ainsi qu'entre une connexion classique X et le serveur X. Commande utilisée : ping machine.domaine.racine Le // @ H, depuis, les résultats sont les suivants : --- machine.domaine.racine ping statistics --- packets transmitted, received, % packet loss, time ms rtt min/avg/max/mdev = /// ms Afin de pouvoir comparer, le test a également été réalisé entre la X et le serveur X : ping machine.domaine.racine Le // @ H, les résultats sont les suivants : --- machine.domaine.racine ping statistics --- packets transmitted, received, % packet loss, time ms rtt min/avg/max/mdev = /// ms
Page 18 de 31 Gigue : Ces tests ont été réalisés à l'aide de l'outil Iperf http://iperf.fr/, entre un serveur dédié X et le serveur de X, en modifiant les paramètres par défaut : Commande sur le serveur : iperf -s -u -b 50000000 Commande sur le client : iperf -c machine.domaine.racine -u -b 50000000 -r Le // @ H, un débit utile UDP de, et Mbits/sec ont été testés. La réception des données envoyés par le serveur sur le serveur, est jusqu'à Mbits/sec (limite d'envoi du serveur ) : - Mbits/sec, gigue de ms, paquets perdus sur (%), - Mbits/sec, gigue de ms, paquets perdus sur (%), - Mbits/sec, gigue de ms, paquets perdus sur (%). L'envoi de données depuis le serveur X jusqu'au serveur X, est X : - Mbits/sec, gigue de ms, paquets perdus sur (%), - Mbits/sec, gigue de ms, paquets perdus sur (%), - Mbits/sec, gigue de ms, paquets perdus sur (%).
Page 19 de 31 5.1.2 Stockage Capacités de stockage : On compte X disques dur virtuels, dont la capacité de stockage formatée relevée le // est : - X: X Go / X Go de libre, - C : Système d'exploitation : Go / Go libre, - D : Stockage : Go / Go libre. L'analyse de l'occupation des disques a été réalisée à l'aide de l'outil WinDirStat - http://windirstat.info/. (6)Occupation du disque système (7)Occupation du disque Stockage (8)Occupation du dossier web
Page 20 de 31 Performances Entrées et Sorties : Ces tests ont été réalisés à l'aide de l'outil Iozone http://www.iozone.org/, dans un répertoire dédié du disque à tester (D:). Test généraliste : iozone.exe -Ra -g 4G > FichierMesuresGeneralistes.txt Test spécialisé : iozone.exe -R -l 4 -u 4 -r 4k -s 2G > FichierMesuresSpecialisees.txt Note 1 : L'utilisation des options «-l PMin» et «-u PMax» permet de régler le nombre minimal PMin et maximal PMax de processus simultanés. Note 2 : L'utilisation de l'option -g 4G permet de mesurer les performances réelles du disque, en paramétrant des tests à l'aide de fichiers supérieurs à la taille des différents caches présents - système (fortement liée à la taille de la mémoire RAM présente), contrôleurs physiques,... Note 3 : L'utilisation de l'option -r -s 2G permet de mesurer les performances réelles du disque, en paramétrant des tests à l'aide de fichiers supérieurs à la taille du cache système (fortement liée à la taille de la mémoire RAM présente). L'analyse et exploitation graphique a été réalisée à l'aide de l'outil GnuPlot http://www.gnuplot.info/ et du script dédié fourni avec Iozone :./Generate_Graphs fichiermesures.txt Le // @ H, les performances généralistes de lecture et écriture ont été mesurées et sont présentées dans la suite du document. L'enregistrement est disponible dans le fichier : - ET-SRV-CLT-AUD-IOPerfsMeasurments_.txt Le // @ H, les performances spécifiques de lecture et écriture ont été mesurées. On constate un débit moyen en nouvelle écriture de Moctets / sec, de Moctets / sec en ré-écriture. Le débit moyen en nouvelle lecture et en relecture est de Moctets/sec. Les accès aléatoires sont de Moctets/sec en lecture et de Moctets/sec en écriture. L'enregistrement est disponible dans le fichier : - ET-SRV-CLT-AUD-IOPerfsMeasurments_.txt
Page 21 de 31 - Écriture de nouveaux fichiers selon la taille des blocs (9)Performances en écriture, mesurées en Kilo-Octets par seconde, en fonction de la taille du fichier et de la taille de l'enregistrement - Ré-écriture de fichiers existants déjà selon la taille des blocs, ne nécessitant plus l'écriture des métadonnées associées (10)...Performances en ré-écriture, mesurées en Kilo-Octets par seconde, en fonction de la taille du fichier et de la taille de l'enregistrement - Lecture de fichiers existants selon la taille des blocs (11)...Performances en lecture, mesurées en Kilo-Octets par seconde, en fonction de la taille du fichier et de la taille de l'enregistrement - Re-lecture de fichiers précédemment lus selon la taille des blocs (12)...Performances en relecture, mesurées en Kilo-Octets par seconde, en fonction de la taille du fichier et de la taille de l'enregistrement - Lecture de fichiers avec accès aléatoires en fonction de la taille des blocs (13)...Performances en lectures aléatoires, mesurées en Kilo-Octets par seconde, en fonction de la taille du fichier et de la taille de l'enregistrement Écriture de fichiers avec accès aléatoires en fonction de la taille des blocs (14)...Performances en écritures aléatoires, mesurées en Kilo-Octets par seconde, en fonction de la taille du fichier et de la taille de l'enregistrement
Page 22 de 31 5.1.3 Calcul La mesure des capacités de calcul d'un système consiste à évaluer les performances du (des) processeur(s) pour réaliser des instructions. Les indicateurs de performance de base sont la fréquence de fonctionnement (mesurée en Hertz) et le nombre d'opérations par seconde (mesuré en MIPS et FLOPS). On différencie les processeurs selon leur architecture et le jeu d'instruction utilisé. Il s'agit ici de l'architecture la plus courante pour les serveurs et ordinateurs personnels : x86, avec un jeu d'instructions de 64 bits. Certains utilitaires et sites web réalisent des comparatifs basés sur de nombreux tests spécialisés. Dans le cadre de cet audit, le site http://www.cpubenchmark.net a été utilisé afin de. Il reste à discuter avec les développeurs des cas d'utilisation type à mettre en place pour mesurer les besoins en termes de ressources des applications.
Page 23 de 31 5.1.4 Charge Dans notre cas, il faut différencier deux tests de charge différents : - 1 : Le test des performances du serveur IIS et du réseau qui a été effectué à l'aide du site www.blitz.io : «-p 1-1000:120 -r ireland http://www.siteweb.racine», la page chargée avait une taille de KB, - 2 : Le test des performances du serveur d'application WebDev et de l'application web déployée. Il existe un outil dédié WDTestSite, néanmoins, il reste limité à un test de 100 utilisateurs simultanés. L'utilisation d'autres outils est également envisageable, comme Jmeter : http://jmeter.apache.org. Note : Il est nécessaire de modifier les paramètres de WebDev qui sont limités par défaut Configuration Nombre de Maximum de Connexions. Selon [RD1], il est possible d'estimer par calcul théorique la configuration nécessaire : - 400 ko RAM / client ==> Pour clients : Mo de RAM minimum, - 1 Mo de HDD / client ==> Pour clients : Go de HDD.
Page 24 de 31 Test 1 - // @ H : Test 2 - // @ H : Test 3 // @ H : Aperçu des performances de la machine : On constate que le point bloquant dans ce cas d'utilisation est.
Page 25 de 31 5.1.5 Disponibilité Des tests de disponibilité du service web ont été effectués toutes les minutes, pendant X jours, H et min à l'aide du site web Pingdom Tools (début le // :: et fin le // ::). X Les temps de réponse sont de millisecondes en moyenne, ils s'élèvent jusqu'à ms et descendent à ms dans le meilleur des cas.
Page 26 de 31 5.2 Sécurité 5.2.1 Vulnérabilités apparentes du serveur X L'identification des ports ouverts sur une machine a été réalisée à l'aide de l'outil nmap : nmap machine.domaine.racine Une recherche des failles à l'aide d'openvas a été effectuée le // à H (configuration du scan : tous les ports ainsi que les 1000 principaux ports UDP). Les principaux problèmes reportés sont : 5.2.2 Sécurité des sites web Les sites web : ont été inspectés à l'aide de Nikto - http://www.cirt.net/nikto2. Les failles de sécurité identifiées sont les suivantes :
Page 27 de 31 5.2.3 Sécurité des Informations Concernant les plans de reprise d'activité actuels, suite à, il apparaît que : - en cas de panne de la machine virtuelle, un délai de XH est nécessaire entre la détection de la panne et sa correction (configuration de l'environnement et restauration des données), - en cas de panne d'un routeur réseau, un délai de X minutes est nécessaire pour la restauration de la connexion au réseau, - en cas de panne d'un serveur physique, un délai de X minutes est nécessaire pour le redémarrage de la machine virtuelle. Afin de surveiller la disponibilité de leurs installations, utilise et. 5.2.4 Sécurité remarques hors du périmètre d'intervention
Page 28 de 31 6 ANALYSES 6.1 Performances 6.1.1 Réseau Concernant le débit pic nécessaire : Total maximal de données à transférer simultanément : Mégaoctets / X Utilisateurs. Il convient donc, afin de pouvoir supporter un pic de charge, tout en garantissant un délai de réponse raisonnable (3 secondes), d'être capable de fournir un débit supérieur à Mbits/secs.
Page 29 de 31 6.1.2 Stockage La capacité de stockage du système est largement suffisante pour les besoins. Suite à la revue de l'audit et la formation associée, les besoins définis pour le stockage des services web sont : - X Go pour, - X Go pour, L'utilisation de Go est largement suffisante pour couvrir les besoins de stockage des services web à moyen terme (X ans) ainsi que pour permettre l'installation d'un système d'exploitation. Les besoins liés aux sauvegardes sont les suivants : - : retour en arrière de X ans maximum, sauvegarde tous les jours en incrémentiel, sauvegarde complète chaque mois, - : retour en arrière de X mois maximum, sauvegarde toutes les demi-journées en incrémentiel, sauvegarde complète chaque mois, - : retour en arrière de un jour maximum, sauvegarde toutes les minutes en incrémentiel. Service Web Stockage sauvegardes complètes Stockage sauvegardes incrémentielles Il faut donc prévoir une capacité de stockage totale supérieure à Go pour les sauvegardes.
Page 30 de 31 6.1.3 Calcul 6.1.4 Charge Selon les estimations théoriques, il est nécessaire de prévoir pour les applications : - 400 ko RAM / client ==> Pour clients : Mo de RAM minimum, En ajoutant la mémoire RAM recommandée du système d'exploitation, il faut prévoir X Go de RAM. 6.2 Sécurité 6.2.1 Serveur 6.2.2 Sites web L'ANSSI tient à jour une liste de prestataires de services de confiance qualifiés : http://www.ssi.gouv.fr/fr/produits-et-prestataires/prestataires-de-services-de-confiance-qualifies/
Page 31 de 31 6.2.3 Informations 6.2.4 Hors périmètre