 |
|
|
| |
|
|
|
| L'hébergement mutualisé et le problème de la souplesse |
| A la différence de l'hébergement sur serveur dédié, cette approche limite les possibilités en matière de configuration applicative, les clés d'administration demeurant entre les mains du prestataire.
(11/10/2005) |
|
A la différence de l'hébergement sur serveur dédié, le mode mutualisé ne permet pas aux clients d'accéder à l'intégralité des possibilités de configuration système et serveur. Par définition, les clés d'administration de ce type d'environnement demeurent en effet entre les mains du prestataire, les serveurs matériels sous jacents étant partagés entre plusieurs utilisateurs.
Face à cette limitation, les clients ont tendance à placer la barre très haut en matière de services de paramétrage applicatif. Pour eux, la possibilité de bénéficier d'une interface de configuration satisfaisante, couvrant à la fois base de données et langage de script, est fondamentale, notamment dans la mesure où ils choisissent la plupart du temps une telle prestation pour supporter des applications de type site Web dynamique.
"Il est difficile de donner les clés de la plate-forme d'hébergement à un client. Les risques en matière d'intégrité applicative et l'impact potentiel d'une erreur sur le reste de l'environnement sont trop importants", note Ghislain Seguy, Directeur associé de Nexen Services. Même son de côche chez OVH. "Mais il est vrai aussi que les clients en mutualisés ont
bien conscience qu'ils ne peuvent avoir accès à tous, c'est la règle du jeu", pondère
Germain Masse,
responsable des centres d'hébergement de la société.
Chaque hébergeur met en avant sa méthode visant à renforcer la sécurité de ses serveurs. Ainsi Nexen Services évite d'autoriser l'accès direct au dispositif .htaccess, dont l'utilisation est jugée trop problématique. Quant à OVH, il a choisi de mettre de côté le safemod de PHP (pour s'appuyer directement sur les noms d'utilisateur). Objectif : réduire les risques de faille liés à l'implémentation de nouvelles bibliothèques de scripts.
| Le déploiement de nouvelles fonctions est jugé complexe |
Pour les mêmes raisons, la mise en oeuvre de nouvelles fonctions applicatives ou même d'évolutions de briques existantes (telles PHP ou mySQL) est présentée comme complexe par les hébergeurs interrogés.
"Il est nécessaire d'étudier les conséquences de l'opération en matière de sécurité, mais également de s'assurer de la compatibilité ascendante pour éviter d'éventuelles répercussions sur des fonctions associées", détaille Ghislain Seguy.
Pour faire face aux enjeux liés à l'évolution de leur offre en matière de services d'infrastructure et de configuration, les hébergeurs mettent en avant des processus de déploiement en plusieurs étapes. "On commence par mettre les nouvelles versions de langage de scripts ou de base de données en test, avant de les généraliser, ce qui laisse au client le temps de s'organiser", indique,
Germain Masse. Et Ghislain Seguy d'ajouter : "Nous informons les clients des fonctions qui peuvent être touchées lors de la migration afin qu'ils puissent prendre les mesures qui s'imposent."
Chez OVH, de nouvelles options applicatives conçues pour permettre l'installation de modules de portail et de gestion de contenu (Mambo et SPIP) sont en cours d'élaboration. Des projets qui engendrent de nouveaux chalenge autour de la sécurité pour le prestataire. "Il est notamment nécessaire d'assurer la maintenance de ces logiciels en matière de correctifs", précise sur ce point
Germain Masse.
|
|
|
|
|
|
|
Dossier 