Le port SSH que je n’avais pas vu

J’ai exécuté mon outil de contrôle sur mon propre environnement Azure, en m’attendant surtout à vérifier que l’outil fonctionnait.

Je connaissais cet environnement. J’en avais construit une partie, suivi les déploiements et corrigé plusieurs problèmes. Avec plus de quinze ans d’IT derrière moi, l’exercice ressemblait à une formalité de mise au point.

Le signal observé

Le scan a observé 52 ressources et produit 76 constats. Parmi eux figurait une règle réseau autorisant SSH depuis Internet vers une machine du laboratoire.

La mienne.

Le constat portait sur la configuration : une règle d’autorisation présente dans un groupe de sécurité réseau. Il ne démontrait ni la joignabilité effective de la machine, ni l’aboutissement d’une connexion. Cette distinction compte, et je la maintiens telle quelle dans le rapport.

Pourquoi le système se comportait ainsi

Ce résultat n’était pas la preuve d’un manque de connaissance. Je savais qu’une règle d’accès d’administration ne devait pas rester aussi largement ouverte. Le problème se trouvait ailleurs.

Concevoir correctement, déployer correctement et vérifier l’état courant sont trois responsabilités différentes. L’expérience aide sur les deux premières. Elle ne dispense pas de la troisième. Entre la configuration attendue et la configuration réellement présente, la boucle n’était pas refermée — et rien dans mon processus ne la refermait automatiquement.

La décision

J’ai restreint la règle, mais ce n’est pas la décision intéressante. La décision structurante a été de refuser deux raccourcis qui m’étaient offerts.

Le premier consistait à traiter ces 76 constats comme un argument commercial. Je les ai au contraire rattachés explicitement à un environnement m’appartenant, à un instant donné. L’option écartée était plus vendeuse ; elle aurait transformé une mesure en statistique inventée.

Le second consistait à requalifier le constat en « faux positif » parce que la machine était de laboratoire. Le contrôle avait observé ce qu’il devait observer. Ajuster la sévérité selon le confort de l’opérateur vide un outil de contrôle de sa fonction.

La vérification

Après correction, j’ai rejoué le scan sur le même périmètre et conservé les deux exécutions. Le constat a disparu de la seconde. C’est cette paire d’artefacts — et non ma parole sur la correction — qui constitue la trace exploitable.

Cinq questions déterminent désormais si un résultat est réutilisable :

• Quel périmètre a réellement été observé ?
• Quelle procédure a été exécutée ?
• Quel artefact conserve le résultat ?
• Quelqu’un d’autre peut-il le rejouer ?
• Quelles limites empêchent d’aller plus loin dans la conclusion ?

Ce que ce cas permet d’affirmer

Une seule chose, mais solidement : un environnement familier peut conserver une règle d’administration ouverte, et seul un contrôle exécuté l’a rendue visible.

Ce cas ne permet pas d’affirmer qu’un parc Azure moyen présente ce défaut, ni d’en déduire un taux quelconque. Une architecture peut être cohérente et son état réel incorrect ; une équipe peut être compétente et manquer un écart. La vérification ne remet pas en cause l’expérience — elle l’empêche de devenir une certitude non contrôlée.

Vérifier ce point dans votre environnement

az graph query --first 1000 --output json -q "
Resources
| where type =~ 'microsoft.network/networksecuritygroups'
| mv-expand rule = properties.securityRules
| extend p = rule.properties
| where tostring(p.access) =~ 'Allow'
    and tostring(p.direction) =~ 'Inbound'
    and tostring(p.protocol) in~ ('*', 'Tcp')
| extend sources = iff(coalesce(array_length(p.sourceAddressPrefixes), 0) > 0,
                       p.sourceAddressPrefixes,
                       pack_array(p.sourceAddressPrefix)),
         ports = iff(coalesce(array_length(p.destinationPortRanges), 0) > 0,
                     p.destinationPortRanges,
                     pack_array(p.destinationPortRange))
| mv-expand source = sources to typeof(string)
| mv-expand port = ports to typeof(string)
| extend parts = split(port, '-')
| where source in~ ('*', 'Internet', '0.0.0.0/0', '::/0')
| where port in ('*', '22')
    or (array_length(parts) == 2
        and toint(parts[0]) <= 22
        and toint(parts[1]) >= 22)
| project id, subscriptionId, resourceGroup,
          nsg = name, rule = tostring(rule.name),
          priority = toint(p.priority), source,
          destinationPort = port
| order by subscriptionId asc, nsg asc, priority asc
"

Cette requête détecte des règles configurées ; elle ne démontre ni leur application effective ni la joignabilité d’une machine. Azure Resource Graph limite une page à 1 000 résultats : si un jeton de continuation est retourné, poursuivez avec --skip-token jusqu’à son absence avant de conclure sur la couverture.

Ce que cela change à l’échelle d’un grand compte

Sur une souscription de laboratoire, cet écart est une anecdote. Sur un parc de plusieurs dizaines de souscriptions, il change de nature : ce n’est plus une règle mal configurée, c’est l’absence d’un contrôle périodique et opposable.

• Couverture, pas échantillon. La question utile n’est pas « avons-nous des ports d’administration ouverts » mais « sur quel pourcentage du parc la réponse a-t-elle été mesurée, et à quelle date ». Une requête Resource Graph transverse répond ; un audit par sondage non.
• Rattachement au référentiel. Le constat relève du pilier Sécurité du Well-Architected Framework. Formulé comme un contrôle daté avec son périmètre, il devient un élément de dossier réutilisable en comité. Formulé comme « le réseau est sécurisé », il n’est opposable à personne.
• Séparation des rôles. Resource Graph peut rester sous Reader. L’inspection des NSG effectifs requiert une action supplémentaire, non destructive ; un rôle personnalisé limité à cette action évite d’accorder Contributor.
• Prévention plutôt que correction. Corriger une règle traite une occurrence. Une politique de refus au niveau du groupe d’administration traite la classe entière. Le rapport doit distinguer les deux, sinon la même ligne réapparaîtra au prochain scan.

C’est la logique du sprint de preuve : produire un constat daté, rejouable et rattaché à un pilier, plutôt qu’une appréciation générale.

Frontière de preuveExécution en laboratoire. Cette analyse décrit une exécution sur un environnement appartenant à Geek Guru, sur 52 ressources observées. Le constat porte sur une règle réseau observée dans la configuration ; il ne prouve pas qu’une connexion SSH a abouti. Les 76 constats décrivent cet environnement à un instant donné : ils ne constituent ni un audit client, ni une statistique générale sur Azure. Les requêtes proposées ci-dessus sont fournies comme point de départ et doivent être adaptées à votre nommage et à vos exclusions.