Illustration en six étapes, infrastructure fictive. Une plateforme web comprend un point d'entrée HTTPS, une application, un service interne, une base de données, une interface d'administration et des sauvegardes. La carte situe chaque composant dans sa zone : Internet, zone publique, zone applicative, zones internes, administration, stockage séparé. Le relevé montre que l'interface d'administration répond depuis tout Internet : un accès trop ouvert. Les flux nécessaires sont écrits, puis, en simulation, l'administration est restreinte au périmètre prévu de l'équipe ; le site public reste accessible. Quatre essais vérifient ensuite les accès autorisés et refusés. Restreindre un accès ne remplace ni les mises à jour, ni l'authentification forte, ni le suivi des journaux.
La carte d'exposition · plateforme web d'une entrepriseinfrastructure et règles fictives
Zone 1 · hors de votre contrôle
Internet
Visiteurs du site
Tout autre réseau
Zone 2 · publique
Point d'entrée HTTPSserveur frontal, selon l'architectureà examinerexposé · prévunon exposé directementinterne · non exposéexposé△ trop ouvertlimité au périmètre prévu
Zone 3 · applicative
Application webjoignable via le point d'entréeà examinerexposé · prévunon exposé directementinterne · non exposéexposé△ trop ouvertlimité au périmètre prévu
Zones 4 et 5 · internes
Service interne et base de donnéesfile de traitements ; aucun accès direct à la baseà examinerexposé · prévunon exposé directementinterne · non exposéexposé△ trop ouvertlimité au périmètre prévu
Stockage séparé
Sauvegardescopies chiffrées, restauration testéeà examinerexposé · prévunon exposé directementinterne · non exposéexposé△ trop ouvertlimité au périmètre prévu
Zone 6 · administration
Interface d'administration et accès techniquesréservés à l'équipe d'exploitation
Accessible depuisà déterminertout Internetle périmètre prévu : réseau de l'équipe
à examinerexposé · prévunon exposé directementinterne · non exposéexposé△ trop ouvertlimité au périmètre prévu
Registre des fluxconstaté sur la configurationrègles écrites pour chaque flux
FluxConstatéRègle attendue
Visiteurs → point d'entrée (HTTPS)à relever→ autorisé⊘ refusé△ trop ouvertà écrire→ public
Vérificationaprès les restrictions4 essais, résultats attendus
Visiteur → site en HTTPSà vérifieraccessible ✓
Internet → interface d'administrationà vérifierrefusé ✓
Équipe, depuis le périmètre prévu → administrationà vérifieraccessible ✓
Internet → base de donnéesà vérifierrefusé ✓
Restreindre un accès ne remplace ni les mises à jour, ni l'authentification forte, ni le suivi des journaux.
Symboles : → autorisé · ⊘ refusé · △ trop ouvert. Simulation : aucune connexion à un serveur réel.
01 Cartographie
02 Points exposés
03 Accès trop ouvert
04 Flux nécessaires
05 Restrictions appliquées
06 Vérification
Une plateforme, six zones, six étapes
Cartographie · Les composants de la plateforme et leurs zones sont posés sur la carte.
Points exposés · Deux composants répondent depuis Internet : le point d'entrée, prévu, et l'administration.
Accès trop ouvert · L'interface d'administration est joignable depuis tout Internet, alors qu'elle ne sert qu'à l'équipe.
Flux nécessaires · Pour chaque flux, la règle attendue est écrite : public, interne, périmètre prévu ou refusé.
Restrictions appliquées · Simulation : l'administration n'est plus joignable que depuis le périmètre prévu. Le site reste public.
Vérification · Les accès autorisés et refusés sont testés. Les autres mesures restent nécessaires.
Ce que voit Internet de votre plateforme :souvent plus que prévu.
Un site ne se résume pas à ses pages. Derrière, des serveurs, des services, des interfaces d'administration et des accès techniques s'accumulent au fil des projets. Certains répondent depuis Internet sans que personne ne l'ait décidé.
Inventorier
les serveurs, les services et les accès techniques, y compris anciens.
Situer
chaque composant dans sa zone : publique, applicative, interne, administration.
Repérer
ce qui est exposé sans raison, ou depuis un périmètre trop large.
Prioriser
selon l'impact et l'effort, en commençant par les accès les plus sensibles.
Cette page parle des composants d'infrastructure. Faire fonctionner le service relève de l'hébergement et de la maintenance ; constater relève de l'audit ; protéger les requêtes, de la sécurisation des applications et API ; gérer les droits des utilisateurs, de l'authentification et des accès ; encadrer les informations, de la protection des données.
Des zoneset des flux écrits,avantde fermer quoique ce soit.
Fermer au hasard casse des services ; laisser ouvert par habitude expose. Nous écrivons d'abord ce qui doit circuler, et pourquoi.
Des zones identifiées
Publique, applicative, interne, administration, stockage : chaque composant a sa place et sa frontière.
Un registre des flux
Pour chaque flux : qui, vers quoi, pourquoi, et s'il est autorisé ou refusé.
Filtrage et segmentation
Mis en œuvre selon l'architecture retenue : règles de filtrage, réseaux séparés, accès distant chiffré lorsqu'il est pertinent.
Des exceptions tracées
Un accès temporaire a un titulaire, un motif et une date de fin.
Une règle écrite permet de vérifier ; une règle implicite finit par être contournée.
Un service,cinq niveaux d'exposition :des mesures cohérentes,pas un seul bouton.
La même plateforme fictive. Pour chaque situation : le composant, son exposition, la règle attendue, la mesure proposée, qui valide, ce qui change, comment on le vérifie et ce qui reste à faire.
Zone 6 · administrationInterface d'administration
État : Exposition signalée · à corriger
Exposition initiale
Joignable depuis tout Internet, protégée par un mot de passe seulement.
Règle attendue
L'administration est réservée au périmètre prévu, avec une authentification renforcée.
Restreindre l'accès au réseau de l'équipe (accès distant chiffré ou adresses autorisées, selon l'architecture) et exiger une authentification renforcée.
Validation nécessaire
Le responsable technique et l'équipe d'exploitation valident la liste des personnes et des lieux d'accès.
État après intervention
Pas encore : il apparaît après la validation.
Vérifications
Depuis Internet : refusé · à vérifier
Depuis le périmètre prévu : accessible · à vérifier
Site public : inchangé · à vérifier
Limites restantes
Ces mesures réduisent l'exposition sans garantir l'absence de faille : l'interface elle-même doit rester à jour et ses comptes être revus.
Sans JavaScript, voici chaque situation telle qu'elle se présente, avant toute intervention.
Situation
Exposition initiale
Mesure proposée
Limites
A. Configuration maîtrisée
Site public en HTTPS ; administration limitée au réseau de l'équipe.
Aucune modification : la carte des flux est documentée et comparée à la configuration réelle.
Une configuration maîtrisée aujourd'hui doit être revérifiée après chaque changement d'architecture ou de prestataire.
B. Administration trop exposée
Joignable depuis tout Internet, protégée par un mot de passe seulement.
Restreindre l'accès au réseau de l'équipe (accès distant chiffré ou adresses autorisées, selon l'architecture) et exiger une authentification renforcée.
Ces mesures réduisent l'exposition sans garantir l'absence de faille : l'interface elle-même doit rester à jour et ses comptes être revus.
C. Service interne accessible
Joignable depuis l'extérieur, alors qu'il ne sert qu'à l'application.
Limiter l'écoute du service au réseau interne et filtrer son port depuis l'extérieur, après vérification des composants qui l'utilisent.
Une limitation réseau ne remplace pas les autres protections du service : son authentification et ses mises à jour restent nécessaires.
D. Correctif système à appliquer
Une mise à jour de sécurité est disponible pour un composant du système.
Préparer, vérifier la compatibilité, tester en préproduction, intervenir au créneau convenu avec un retour arrière prêt, puis vérifier.
Une mise à jour peut avoir des effets de bord et ne corrige que ce qu'elle annonce ; elle n'est jamais installée sans préparation.
E. Accès d'un ancien prestataire
Actif, alors que le prestataire n'intervient plus depuis sept mois.
Vérifier l'utilité de l'accès, le désactiver après décision, retirer sa clé, conserver la trace et examiner les secrets qu'il connaissait.
Tant que les secrets connus de l'ancien prestataire ne sont pas renouvelés, l'intervention n'est pas terminée.
Exposer le nécessaire. Le public voit le site, pas les outils.
Une mesure n'est jamais seule. Filtrer, mettre à jour, authentifier, journaliser.
Une personne valide. Chaque changement a un responsable et un retour arrière.
Vérifier après coup. Ce qui doit marcher marche, ce qui doit être refusé l'est.
Infrastructure, comptes et règles fictifs. Simulation : aucune commande sur un serveur réel, aucune procédure d'attaque.
Les accès techniqueset les configurations,là où tout commence.
La plupart des expositions viennent d'un accès resté ouvert ou d'un réglage par défaut. Nous les reprenons un par un.
Accès d'administration
Réservés au périmètre prévu, avec un accès distant chiffré lorsqu'il est pertinent et une authentification renforcée.
Une infrastructure durcie ne garantit pas l'absence de vulnérabilité dans l'application : celle-ci relève de la sécurisation des applications et API.
Aucune surveillance permanente ni réponse à incident à toute heure n'est incluse d'office : elles se définissent, si besoin, dans un contrat dédié.
Une mesure n'existeque si elle est vérifiée.
Après chaque changement, ce qui doit marcher doit marcher, et ce qui doit être refusé doit l'être.
Tester les accès
Les accès autorisés et refusés, depuis l'extérieur et depuis le périmètre prévu.
Restaurer pour de vrai
Une sauvegarde n'est fiable qu'une fois restaurée avec succès.
Relire les journaux
Après une intervention, pour repérer un effet inattendu.
Documenter
La carte des flux et les mesures appliquées, pour la prochaine revue.
Responsabilités et accompagnement
01
Cartographier un périmètre
Une plateforme, ses zones, ses flux et ses accès, avec vos équipes et vos prestataires.
02
Appliquer les mesures retenues
Par priorité, avec validation et retour arrière à chaque intervention.
03
Vérifier et planifier la revue
Essais d'accès, restauration testée, date de la prochaine revue.
Pour un regard extérieur sur l'existant, avant ou après, un audit de sécurité web remet des constats et des recommandations.
Pour l'ensemble de nos expertises, voir la cybersécurité.
Questions fréquentes sur la sécurisation des infrastructures
Point de départ, pare-feu, administration, mises à jour, hébergeur, données.
Par quoi commencer pour sécuriser un serveur web ?
Par savoir ce qui est exposé : l'inventaire des serveurs, des services qui répondent depuis Internet et des accès d'administration. Les mesures les plus utiles viennent ensuite, dans l'ordre : fermer ce qui n'a pas à être ouvert, restreindre l'administration, mettre à jour, vérifier les sauvegardes.
Un pare-feu suffit-il à protéger notre plateforme ?
Non. Un filtrage limite les flux, ce qui est utile, mais un service autorisé peut rester vulnérable. Il faut aussi des mises à jour, des accès d'administration restreints, des comptes revus, des sauvegardes testées et des journaux réellement relus. C'est l'ensemble qui réduit l'exposition.
Comment sécuriser l'accès à l'administration de nos serveurs ?
En le réservant au périmètre prévu, avec un accès distant chiffré lorsqu'il est pertinent, une authentification renforcée et des comptes nominatifs revus régulièrement. Les règles qui encadrent les droits des personnes relèvent de l'authentification et de la gestion des accès.
Faut-il appliquer toutes les mises à jour dès leur sortie ?
Les correctifs de sécurité sont prioritaires, mais ils se préparent : sauvegarde vérifiée, compatibilité contrôlée, test en préproduction, créneau convenu et retour arrière prêt. Une mise à jour peut avoir des effets de bord ; l'appliquer sans préparation crée un autre risque.
Notre hébergeur s'occupe-t-il déjà de la sécurité ?
En partie, selon le contrat : souvent l'infrastructure physique et le réseau de base, rarement vos configurations, vos accès et vos mises à jour applicatives. Nous clarifions qui fait quoi, et l'hébergement, la maintenance et l'infogérance peuvent prendre en charge l'exploitation courante.
Une infrastructure sécurisée protège-t-elle aussi nos données ?
Elle y contribue : accès restreints, sauvegardes chiffrées, journaux. Mais elle ne dit rien de ce qui est collecté, de la durée de conservation ni des échanges avec des prestataires : ces sujets relèvent de la protection des données.
Le plande sécurisationde votre infrastructure :neuf repères,un responsablepar mesure.
Plan de sécurisation · votre infrastructure · zones, flux et repères à annoter
Une zone après l'autre, de l'extérieur vers l'intérieur, puis le cartouche des responsabilités.
Internetvisiteurs, autres réseaux
Zone publique
Point d'entréece que voit Internet3
3Repère 3 : Qu'est-ce qui doit rester accessible publiquement ?
Zone applicative
Applications et serveurssites, applications, systèmes16
1Repère 1 : Quels sites et applications doivent être protégés ?
6Repère 6 : Quels composants et configurations faut-il maintenir ?
Zone interne
Services internes et baseéchanges entre composants25
2Repère 2 : Quels serveurs et services sont utilisés ?
5Repère 5 : Quels flux internes sont nécessaires ?
Administration
Accès techniques et supervisionéquipe, prestataires, journaux47
7Repère 7 : Quels journaux et alertes sont pertinents ?
Stockage séparé
Sauvegardescopies, restauration8
8Repère 8 : Comment organiser sauvegardes et restauration ?
Trait plein : zones publiques · double trait : zones internes · tirets : administration. Repère 9 : le cartouche.
Légende des repères
1Quels sites et applications doivent être protégés ?
2Quels serveurs et services sont utilisés ?
3Qu'est-ce qui doit rester accessible publiquement ?
4Quels accès d'administration existent ?
5Quels flux internes sont nécessaires ?
6Quels composants et configurations faut-il maintenir ?
7Quels journaux et alertes sont pertinents ?
8Comment organiser sauvegardes et restauration ?
9Qui intervient, vérifie et suit les corrections ?
Cartouche · repère 9 · qui intervient, vérifie et suit
Qui intervient, vérifie et suit les corrections ?
Responsable technique
à renseigner
Exploitation
à renseigner
Prestataires
à renseigner
Vérification
à renseigner
Prochaine revue
à renseigner
Nous annotons ce plan avec vous : ce qui doit rester public, ce qui doit rester interne, qui administre, comment on met à jour et comment on vérifie. Les mesures en découlent, selon votre architecture.
Un schéma d'architecture, un contrat d'hébergement, une liste d'accès ? Mentionnez-les : nous partirons de ce que vous avez.
Vos cookies, votre choix
Avec votre accord, nous mesurons la fréquentation du site pour l'améliorer.Sans accord, aucun cookie de mesure n'est déposé.Modifiable à tout moment : « Gestion des cookies », en bas de page. En savoir plus