CERTA
|
CERTA Centre d'Expertise Gouvernemental de |
 |
|
Affaire suivie par : CERTA Objet : Bonnes pratiques concernant
l'hébergement mutualisé
Gestion du document
Une gestion de version détaillée se trouve
à la fin de ce document. Table des matières
1 L'hébergement mutualisé externaliséPour des raisons financières ou techniques, beaucoup d'organisations sont tentées par l'externalisation de tout ou partie de leur système d'information.Ce document s'adresse aux RSSI qui ont à externaliser une partie de leur système d'information, dans le but de les aider à définir le cahier des charges vu sous l'angle du traitement d'incident. Ce document se bornera donc à expliciter les clauses et aborder les pratiques permettant de pouvoir, par la suite, analyser un système de façon optimale lors d'un incident affectant une ressource dont l'hébergement est mutualisé. Il présuppose une réflexion globale sur l'analyse des enjeux relatifs à l'externalisation de l'hébergement et l'établissement de prescriptions de sécurité différentes, auxquelles le co-hébergement ajoute des vulnérabilités particulières. 1.1 Qu'est-ce que l'hébergement mutualisé ?L'hébergement mutualisé (ou mutualized hosting en anglais) consiste à héberger plusieurs ressources sur une seule et même machine, la plupart du temps gérée par une société externe. Dans la majorité des cas, les ressources mutualisées de la sorte sont des «ressources communicantes» telles que des sites web, des serveurs de messagerie, ou des ressources lourdes telles que des bases de données.Dans ce type de solution, les clients n'ont pas accès directement aux serveurs ou aux ressources mutualisées en tant qu'administrateur. La configuration est réalisée puis gérée par un hébergeur ou une société tierce. 1.2 Pourquoi cohéberger et quelles limites ?Le choix de l'hébergement mutualisé est principalement motivé par la réduction de l'investissement nécessaire à la gestion de la ressource. En effet :
En contre-partie, les ressources cédées à l'hébergeur (site web, solution de messagerie, bases de données, etc.) ne sont plus totalement maîtrisées. Au delà de la prise en compte d'objectifs de sécurité spécifiques exprimés par le prescripteur pour sa ressource, l'environnement général de l'application est également exposé dans la mesure où :
2 Risques et traitements d'incidents2.1 Risques inhérents à l'hébergement mutualiséL'informatique ne permet pas de concevoir des systèmes exempts de vulnérabilités. De plus, le fait d'être étroitement lié à d'autres ressources, en général de façon non maîtrisée, tend à augmenter ce risque et à en ajouter de nouveaux.En effet, les attaques ciblant une des ressources mutualisées (réseau, logiciel, matériel) pourront avoir un impact sur l'ensemble des ressources co-hébergées. De plus, si une opération de maintenance sur une des ressources provoque des effets de bord (indisponibilité, incompatibilité, etc.), l'ensemble des ressources sera touché, ce qui peut, à terme, inciter l'hébergeur à ne plus procéder aux mises à jour. Un bref aperçu, non exhaustif, des risques liés au co-hébergement et de leurs répercussions suivant trois critères (disponibilité, intégrité, confidentialité) est le suivant :
On voit donc que les risques auxquels s'expose une ressource sont augmentés de façon significative par la mutualisation de celle-ci dans un environnement non-maîtrisé. 2.2 Obstacle à la réponse aux incidents de sécurité informatiqueDans le cas d'un incident, l'hébergement mutualisé introduit par nature des obstacles à la réponse.Par exemple, le client est rarement prévenu par l'hébergeur. L'hébergeur rétablit l'apparence de la normalité, dans le respect des délais contractualisés, quand ils existent. Ce procédé est bien entendu contraire à la marche à suivre en cas d'incident (Cf. document du CERTA numéro CERTA-2002-INF-002). En effet, cette démarche peut détruire beaucoup de traces utiles à une analyse ultérieure permettant de retrouver le moyen utilisé pour réaliser la compromission. De plus, la machine n'est pas analysée en profondeur et la partie invisible de la compromission peut être, elle, toujours présente. Ces deux éléments conduisent souvent à de nouvelles compromissions et à l'utilisation de la ressource à des fins malveillantes. D'autre part, lorsque l'administration propriétaire de la ressource hébergée, ou un organisme tel que le CERTA, traite une compromission, le travail de cet organisme se heurte souvent à certains problèmes :
2.3 Cas concrets rencontrés par le CERTA2.3.1 Serveur web mutualiséLe CERTA a traité la compromission d'un site web sensible. Après analyse, il est apparu que la vulnérabilité exploitée par l'utilisateur mal intentionné était due à une version ancienne et vulnérable d'un forum de discussion (mis en œuvre par le logiciel PHPbb) hébergé par un autre site web (cf. figure1).Le site d'une administration et le site affectés étaient hébergés sur le même serveur. Or, la vulnérabilité exploitée avait permis à l'attaquant d'obtenir les droits de l'administrateur sur le serveur. Ainsi, l'ensemble des sites co-hébergés sur la machine étaient impactés par l'attaque, et l'utilisateur mal intentionné disposait, entre autres, d'un contrôle total sur le site de l'administration, non vulnérable. Dans ce cas, la partie visible de la compromission avait pris la forme d'une défiguration, mais il n'est pas exclu qu'il y ait eu vol d'informations sensibles (mots de passe, messages électroniques, bases de données, etc.), ce qui a été constaté dans des cas similaires. 2.3.2 Firewall mutualiséMême si ce cas est original, il est tout aussi représentatif des problèmes les plus fréquents rencontrés par le CERTA.Dans ce cas, chaque site web était hébergé sur une machine différente. En revanche, le pare-feu par lequel passait tous les flux de consultation était mutualisé entre tous les sites (cf. figure2). Un des sites était visé par une tentative d'attaque par déni de service. L'attaque, bien que visant le site web, a provoqué un déni de service sur le pare-feu mutualisé, rendant injoignables l'ensemble des ressources, y compris celles hébergées sur des serveurs différents. Lorsque le CERTA, à des fins d'analyse, a voulu récupérer les journaux d'événements du pare-feu (ou au moins une extraction de ces journaux), la réponse a été négative en raison des accords de confidentialité liant l'hébergeur à ses clients. 3 RecommandationsD'une façon générale, une analyse de risques devrait être systématiquement conduite, afin de mesurer les enjeux d'un co-hébergement. Une plate-forme dédiée, gérée par l'organisme lui-même, peut dans certains cas s'avérer utile au vu des besoins de sécurité nécessaires.Si toutefois le choix de l'externalisation d'un hébergement mutualisé est retenu, il convient de bien analyser les conséquences potentielles d'attaques dans tous les cas de figure, et de contractualiser les actions permettant un traitement efficace d'un incident. En cas de recours à un co-hébergement, cinq domaines méritent ainsi de faire l'objet de prescriptions explicites, en coordination avec le service juridique :
La note CERTA-2002-INF-002 du CERTA ("Les bons réflexes en cas d'intrusion sur un système d'information") peut aider à effectuer cette analyse de risque. 3.1 Journaux d'événementsLes journaux d'événements sont essentiels dans l'analyse d'un système. Des accords doivent donc être trouvés entre le client et le prestataire, afin de s'assurer de la possibilité d'accéder aux journaux d'événements, soit dans le cas d'un incident, soit à des fins de suivi de la (les) ressource(s). Il conviendra de préciser les conditions d'accès à ces journaux :
3.2 Suivi de la ressource co-hébergéeOutre le contrôle des journaux d'événements, le fait de pouvoir disposer d'indicateurs sur l'historique de la ressource hébergée peut être appréciable. Ainsi, il est possible de dégager les principaux événements relatifs à l'utilisation de la ressource, ce qui permet d'avoir accès à des évenements ayant précédé une éventuelle crise. Les indicateurs appréciables sont (liste non exhaustive) :
De la même manière, il est préférable que le client connaisse au préalable l'origine et/ou la teneur des ressources co-hébergées, ce qui permettra d'étayer son analyse de risque. Dans le meilleur des cas, il conviendra d'opter pour une solution hybride du co-hébergement. Celle-ci consiste à n'héberger sur un serveur donné qu'un ensemble de ressources, appartenant toutes à la même organisation, ou fruit d'une communauté d'intérêt. Il sera alors plus facile d'obtenir un accord écrit de la communauté sur l'accès à la machine pour analyse en cas d'incident. 3.3 Prévention d'une attaqueUne partie du contrat passé avec l'hébergeur doit prévoir le cas d'éventuelles attaques informatiques. La réactivité en cas d'incident étant extrêmement importante, il conviendra de faire figurer dans le contrat les points suivants :
3.4 Réaction sur incidentEn cas d'incident, le client seul doit avoir le contrôle total sur la marche à suivre. Ainsi, le contrat doit prévoir que :
3.5 Réversibilité du contrat de cohébergementLa ressource ne doit en aucun cas être bloquée par le contrat d'hébergement mutualisé.Ainsi, une clause de réversibilité doit apparaître dans le contrat. Cette clause doit permettre au client de reprendre la gestion de sa (ses) ressource(s). Cette clause pourra en particulier être activée pour des raisons de sécurité (changement dans l'actionnariat du prestataire, de délocalisation des sites d'hébergement, etc.). Le prestataire s'engage à apporter son assistance durant toute la période de migration. Le prestataire s'engage à garantir la sécurité des données et des applications qui lui ont été confiées lors de leur transfert. Le prestataire s'engage enfin à restituer et/ou à tenir à disposition tout élément correspondant à un extrait de l'ancien environnement d'hébergement (journaux d'événements déportés, sauvegardes, etc.) pendant une période à déterminer. 4 ConclusionsAu seul examen des termes financiers et organisationnels, il est vrai que l'hébergement mutualisé peut être une offre attractive.En revanche, les avantages apparents offerts par une telle solution peuvent être mis à défaut par une plus grande exposition aux risques de compromission. Les conséquences d'un éventuel incident de sécurité informatique se voient aggravées par la dégradation technique des conditions de traitement et des délais de réaction accrus. Il convient donc d'analyser avec l'attention nécessaire les conditions devant accompagner une décision d'hébergement mutualisé et de contractualiser un certain nombre de paramètres afin d'optimiser le contrôle de la (ou des) ressource(s) soumise(s) à hébergement en cas d'incident. En tout état de cause, une solution d'hébregement dédiée doit être privilégiée dans la mesure du possible. 5 Documentation
Gestion détaillée du document
CERTA 2010-01-20 |
|
||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
![\includegraphics[width=0.9\columnwidth]{web_multi_hohst}](img1.png)
![\includegraphics[width=0.9\columnwidth]{firewall_multi_host}](img2.png)