Fonctions et usages par métier
Sécuriser un serveur cloud : les bonnes pratiques essentielles pour une PME
Accès SSH, pare-feu, mises à jour, authentification forte, journaux, chiffrement : la liste des mesures de base pour sécuriser un serveur cloud en entreprise.
Sécuriser un serveur cloud commence par six mesures de base : n'ouvrir au réseau que les ports nécessaires, protéger les accès administrateurs par clés SSH et authentification multifacteur, appliquer rapidement les mises à jour, séparer les droits (moindre privilège), journaliser et surveiller, et sauvegarder hors du serveur. La très grande majorité des compromissions de PME exploitent des failles connues non corrigées, des mots de passe faibles ou des services exposés par erreur, pas des attaques sophistiquées. Dans le cloud, la sécurité est partagée : l'hébergeur protège l'infrastructure ; vous protégez ce que vous installez et configurez.
Le modèle de responsabilité partagée
Selon le type d'offre, la frontière de responsabilité change. Sur un hébergement mutualisé, l'hébergeur gère presque tout le système et vous gérez votre site et vos comptes. Sur un VPS ou une instance de cloud public, l'hébergeur sécurise le matériel, la virtualisation et le réseau de base ; vous gérez le système d'exploitation, les mises à jour, le pare-feu, les logiciels et les accès. Sur un service managé (base de données, plateforme applicative), l'hébergeur gère davantage, mais vous restez responsable des données, des identités et des configurations. Lisez la documentation de l'offre pour connaître précisément cette répartition.
Les mesures de base, une par une
1. Réduire la surface d'exposition. Configurez un pare-feu qui bloque tout par défaut et n'autorise que les ports indispensables (par exemple 80 et 443 pour un site web). N'exposez jamais une base de données directement sur Internet : elle doit n'être accessible que depuis le serveur d'application ou via un réseau privé. Restreignez l'accès d'administration à des adresses IP connues ou à un VPN.
2. Sécuriser l'accès d'administration. Utilisez des clés SSH plutôt que des mots de passe, désactivez la connexion directe du compte administrateur principal et activez l'authentification multifacteur sur la console de l'hébergeur. Un mot de passe de compte cloud compromis donne accès à l'ensemble de l'infrastructure.
3. Mettre à jour régulièrement. Appliquez les correctifs de sécurité du système et des applications. Activez les mises à jour de sécurité automatiques lorsque c'est possible, et planifiez les autres. Gardez un inventaire des versions utilisées.
4. Appliquer le moindre privilège. Créez des comptes distincts pour chaque personne et chaque service, avec uniquement les droits nécessaires. Évitez les comptes partagés et révoquez immédiatement les accès des personnes qui quittent l'équipe.
5. Journaliser et surveiller. Conservez les journaux d'accès et d'authentification, centralisez-les hors du serveur, et configurez des alertes en cas de tentatives de connexion anormales, de pics de consommation ou de modifications de configuration.
6. Chiffrer. Utilisez TLS pour toutes les communications publiques, chiffrez les sauvegardes et envisagez le chiffrement des disques pour les données sensibles. Conservez les secrets (mots de passe, clés d'API) dans un gestionnaire de secrets plutôt que dans le code ou des fichiers en clair.
7. Sauvegarder et tester. Suivez la règle 3-2-1 avec une copie hors du compte de production.
Tableau de priorisation
| Mesure | Effort | Effet sur le risque | Priorité |
|---|---|---|---|
| Authentification multifacteur sur la console cloud | Faible | Très élevé | Immédiate |
| Clés SSH et suppression des mots de passe | Faible | Élevé | Immédiate |
| Pare-feu restrictif | Faible à moyen | Élevé | Immédiate |
| Mises à jour automatiques de sécurité | Faible | Élevé | Immédiate |
| Sauvegardes hors site testées | Moyen | Très élevé (reprise) | Haute |
| Journalisation centralisée et alertes | Moyen | Moyen à élevé | Haute |
| Analyse de vulnérabilités périodique | Moyen | Moyen | Moyenne |
| Segmentation réseau et réseau privé | Moyen à élevé | Élevé | Moyenne |
Exemple d'évaluation d'un risque (illustratif)
Imaginons un serveur avec le port SSH ouvert à tout Internet et l'authentification par mot de passe activée. Les journaux montrent des milliers de tentatives de connexion automatisées par jour : c'est un phénomène banal. Si un compte utilise un mot de passe court, la probabilité d'une compromission n'est pas négligeable sur plusieurs mois. En passant aux clés SSH, en désactivant le mot de passe et en limitant l'accès aux adresses IP du bureau (ou via VPN), vous éliminez ce vecteur en moins d'une heure de travail, sans coût de licence. Pour une petite structure, ce type de gain rapide est le plus rentable.
Conformité et obligations
Pour des données personnelles, l'article 32 du RGPD impose des mesures de sécurité adaptées au risque, et l'article 33 une notification à la CNIL en cas de violation de données susceptible d'engendrer un risque, dans un délai de 72 heures après en avoir pris connaissance. Prévoyez donc une procédure d'incident : qui prévenir, comment isoler le serveur, comment conserver les preuves. La directive européenne NIS 2 élargit les obligations de cybersécurité à de nombreuses entreprises de secteurs variés ; vérifiez auprès de l'ANSSI l'état de sa transposition en France et si votre entreprise est concernée. Si vous hébergez des données de santé, les exigences de la certification HDS s'ajoutent ; consultez notre guide sur la conformité des hébergeurs.
Erreurs fréquentes
- Utiliser un seul compte administrateur partagé par toute l'équipe.
- Laisser des bases de données ou des interfaces d'administration accessibles depuis Internet.
- Stocker des clés d'accès dans un dépôt de code, même privé.
- Ne pas surveiller les journaux : les attaques sont alors découvertes des semaines plus tard.
- Ignorer les mises à jour d'extensions et de bibliothèques tierces, qui sont une source majeure de failles.
- Penser que « mon site est trop petit pour intéresser quelqu'un » : les attaques sont automatisées et opportunistes.
- Confier la sécurité à une seule personne sans documentation.
Quand faire appel à un professionnel
Après un incident avéré, pour un site traitant des paiements ou des données sensibles, ou pour une infrastructure dont l'arrêt serait coûteux, adressez-vous à un prestataire de détection et de réponse à incident ou à un auditeur de sécurité. Le dispositif national Cybermalveillance.gouv.fr oriente les victimes vers des prestataires de proximité.
FAQ
Quel est le premier geste à faire sur un nouveau serveur ?
Mettre à jour le système, créer un compte non administrateur avec clé SSH, désactiver l'accès par mot de passe, configurer le pare-feu, puis activer les sauvegardes.
Faut-il changer le port SSH par défaut ?
Cela réduit le bruit dans les journaux, mais ne remplace pas les clés SSH et le pare-feu : considérez-le comme un complément, jamais comme une protection principale.
Un antivirus est-il nécessaire sur un serveur Linux ?
Pas systématiquement, mais un outil de détection d'intrusion ou d'analyse de fichiers peut être utile si le serveur reçoit des fichiers de tiers. Les mises à jour et la configuration restent prioritaires.
Sources
- ANSSI – Cyber.gouv.fr — guides d'hygiène informatique et recommandations de configuration
- CNIL — sécurité des données personnelles et notification des violations
- Cybermalveillance.gouv.fr — assistance aux victimes et prévention
