[ Les questions à se poser avant de choisir un hébergeur ]
Sécurité des applications et de l’hébergement web : les contrôles à ne pas négliger
Un site web vitrine, un extranet, une boutique en ligne ou une application métier n’exposent pas les mêmes données et ne supportent pas les mêmes interruptions. Pourtant, la sécurité est encore trop souvent résumée à trois mots : certificat HTTPS, sauvegardes et hébergeur réputé.
Ces éléments sont nécessaires, mais ils ne suffisent pas. La sécurité d’un dispositif web dépend aussi du code de l’application, de ses composants, des comptes qui l’administrent, de sa configuration, des procédures de maintenance et de la capacité de l’organisation à réagir lorsqu’un problème survient.
Pour un décideur, la bonne question n’est donc pas « quel hébergeur est le plus sécurisé ? », mais plutôt : quelles données et quels services devons-nous protéger, contre quels risques, avec quelles mesures et quelles preuves ?
La sécurité commence par le niveau de risque accepté
Une interruption de quelques heures sur un site institutionnel n’a pas nécessairement les mêmes conséquences qu’une indisponibilité d’un extranet client ou d’un outil de prise de commande. De même, la compromission d’un formulaire de contact ne présente pas le même impact que l’exposition d’un fichier de clients, de salariés ou de partenaires.
Avant de comparer des solutions techniques, il est utile de formaliser quelques éléments :
- les données collectées et leur sensibilité ;
- les personnes qui peuvent accéder à l’application ;
- les comptes disposant de droits d’administration ;
- les services externes utilisés : paiement, messagerie, API, CDN ou outils d’analyse ;
- les conséquences d’une modification, d’une fuite ou d’une indisponibilité ;
- le délai acceptable pour rétablir le service et les données.
Cette première analyse évite de surdimensionner un site simple comme de sous-estimer une application métier. Elle permet aussi d’arbitrer les investissements : toutes les organisations n’ont pas besoin du même niveau de redondance, de supervision ou d’audit, mais toutes doivent savoir ce qu’elles cherchent à protéger.
Hébergement : une responsabilité partagée
Choisir un hébergement ne revient pas à transférer toute la responsabilité de la sécurité à un prestataire. L’hébergeur protège un périmètre précis : infrastructure physique, réseau, système ou plateforme, selon l’offre retenue. L’organisation et ses autres fournisseurs restent responsables d’autres éléments.
| Périmètre | Questions à poser |
|---|---|
| Infrastructure | Quels composants sont administrés par l’hébergeur ? Quelles sont les mesures de protection et de supervision ? |
| Application | Qui corrige les vulnérabilités du code, du CMS, des extensions et des bibliothèques utilisées ? |
| Accès | Qui possède les comptes administrateurs ? L’authentification multifacteur est-elle disponible ? Les droits sont-ils revus régulièrement ? |
| Données | Où sont-elles stockées ? Quels sous-traitants interviennent ? Quelles règles s’appliquent en cas de transfert ? |
| Continuité | Quelle est la fréquence des sauvegardes ? Les restaurations sont-elles testées ? Quels sont les délais et les limites contractuelles ? |
Les offres mutualisées, les serveurs virtuels, les plateformes administrées et l’infogérance ne couvrent pas le même périmètre. Une offre plus chère n’est pas automatiquement plus adaptée, et une certification ne garantit pas que l’application du client est correctement configurée. Il faut examiner le périmètre exact de l’engagement, les exclusions, les sous-traitants et les preuves disponibles.
Avant la mise en ligne : vérifier l’application
Une infrastructure correctement configurée ne corrige pas une faille dans l’application. Les risques courants concernent notamment les contrôles d’accès, les injections, les erreurs de configuration, l’authentification, les composants obsolètes et la journalisation insuffisante. L’OWASP Top 10 constitue une bonne base de dialogue avec une équipe technique, mais ce document de sensibilisation ne remplace ni un audit ni une analyse adaptée au projet.
Avant une mise en production, une organisation devrait pouvoir demander la vérification des points suivants :
- les comptes de test et les accès temporaires ont été supprimés ou désactivés
- chaque utilisateur dispose uniquement des droits nécessaires à sa fonction
- les secrets, mots de passe et clés d’API ne sont pas stockés dans le code ou dans un dépôt accessible
- les données saisies par les utilisateurs sont contrôlées et traitées de manière sûre
- les composants utilisés sont identifiés, maintenus et corrigés
- les environnements de développement, de test et de production sont séparés
- les interfaces d’administration sont limitées et protégées
- les événements importants peuvent être journalisés sans exposer de données inutiles
- un retour arrière est possible si le déploiement provoque un dysfonctionnement
La CNIL recommande d’intégrer la sécurité dès la conception, de réaliser des tests et de séparer les environnements. Cette approche a un coût : temps de revue, environnement de préproduction, maintenance des dépendances et parfois intervention d’un spécialiste. Elle est néanmoins moins coûteuse qu’une correction urgente après une compromission ou une interruption d’activité.
HTTPS, mises à jour et sauvegardes : les bases à maintenir
Le HTTPS protège les échanges entre le navigateur et le site lorsqu’il est correctement configuré. Il ne protège pas à lui seul une application vulnérable, un compte administrateur compromis ou une base de données mal exposée. Il faut donc le considérer comme un socle, non comme une garantie globale.
Les mises à jour constituent un autre contrôle essentiel. Un CMS, une extension, une bibliothèque ou un système non maintenu peut devenir une porte d’entrée. La responsabilité doit être clairement attribuée : qui surveille les alertes, qui teste les correctifs, qui les installe et dans quel délai ? Une mise à jour doit aussi être précédée ou suivie d’une vérification, car un correctif peut modifier un comportement fonctionnel.
Enfin, une sauvegarde n’est utile que si elle peut être restaurée. Il faut vérifier sa fréquence, sa durée de conservation, son isolement par rapport à l’environnement principal, la protection de ses accès et la capacité à restaurer à la fois les données, les fichiers et la configuration nécessaire au fonctionnement du service. Un test de restauration apporte une preuve que la simple présence d’un fichier de sauvegarde ne fournit pas.
Après le lancement : organiser une sécurité qui dure
La mise en ligne n’est pas la fin du projet. Les comptes changent, les composants évoluent, les fournisseurs modifient leurs offres et de nouvelles vulnérabilités sont publiées. Un minimum de pilotage doit donc être prévu :
- tenir un inventaire des domaines, applications, composants et fournisseurs
- revoir périodiquement les comptes et les droits d’administration
- suivre les mises à jour et les alertes de sécurité
- contrôler les certificats, les noms de domaine et les accès DNS
- tester les sauvegardes et la restauration à une fréquence définie
- réévaluer les risques après une évolution importante de l’application
Chaque contrôle doit avoir un responsable, une fréquence et un résultat attendu. La formule « la sécurité est assurée par notre prestataire » est trop vague pour guider une décision ou démontrer ce qui a réellement été vérifié.
Que faire lorsqu’un incident survient ?
Un site indisponible, un compte administrateur utilisé par un tiers ou une fuite de données exige une réaction organisée. Dans les premières heures, l’objectif n’est pas de chercher immédiatement un responsable, mais de limiter les dommages et de préserver les informations utiles à l’analyse.
- Qualifier : que s’est-il passé, depuis quand et quels services sont concernés ?
- Protéger : faut-il désactiver un compte, isoler une fonction ou interrompre temporairement un accès ?
- Préserver : qui conserve les journaux, les sauvegardes et la chronologie des actions ?
- Coordonner : quels sont les contacts de l’hébergeur, du développeur, du responsable informatique et de la direction ?
- Rétablir : quelle source est suffisamment fiable pour restaurer le service ?
- Tirer les leçons : quelle cause faut-il corriger et quelles mesures doivent être renforcées ?
Lorsque des données personnelles sont concernées, l’organisation doit également évaluer ses obligations au regard du RGPD et de son rôle dans le traitement. Les délais et les notifications dépendent de la nature de l’incident et de ses conséquences : ils ne doivent pas être appliqués mécaniquement sans analyse.
Cinq questions à poser avant de valider un dispositif web
Une direction n’a pas besoin de maîtriser tous les détails techniques pour exercer son rôle. Elle doit pouvoir obtenir des réponses claires à cinq questions :
- Quelles données et quels services devons-nous réellement protéger ?
- Qui est responsable de chaque contrôle : application, hébergement, accès, sauvegardes et réaction à incident ?
- Quelles preuves avons-nous avant la mise en ligne et après chaque évolution importante ?
- Quel risque résiduel avons-nous accepté, et pour quelle raison ?
- Pouvons-nous agir rapidement si un compte est compromis ou si le service devient indisponible ?
La sécurité d’une application web n’est donc pas un produit que l’on achète une fois pour toutes. C’est une combinaison de choix techniques, de responsabilités explicites, de contrôles réguliers et de décisions documentées. Cette méthode permet de choisir un hébergement plus lucidement, de dialoguer avec ses prestataires et de concentrer les efforts sur les risques qui auraient les conséquences les plus importantes pour l’organisation.
