Microsoft Azure
Objectif : lire un ou plusieurs abonnements Azure en lecture seule pour répondre à des questions que le portail Azure ne pose pas d'un coup d'œil :
- de quels services managés dépend une application ;
- quelles versions arrivent en fin de support imposée par Azure ;
- quels comptes de stockage autorisent l'accès anonyme ;
- quelles bases sont ouvertes à tout Internet.
Le connecteur se règle sur Connecteurs → Cloud → Microsoft Azure. Le résultat se consulte sur deux pages :
| Page | Menu | Contenu |
|---|---|---|
Cloud Azure (/azure/) |
Inventaire | L'inventaire |
Analyses Azure (/azure/analyses) |
Sécurité | Les constats d'hygiène et de sécurité |
Aucune action sur Azure
InfraRiver n'envoie à Azure que des lectures : une liste fermée de sept opérations, dont une seule requête POST (la requête Azure Resource Graph, qui est une lecture pure).
Il ne lit jamais le contenu : ni blob, ni ligne de base de données, ni valeur de secret Key Vault, ni les paramètres d'application d'un App Service (qui contiennent souvent des secrets).
Les actions qui renvoient une clé ou qui agissent (listKeys, runCommand, restart…) sont refusées par le connecteur avant même d'être envoyées.
Connecteur distinct d'Entra ID
Le connecteur Entra ID lit l'annuaire (utilisateurs, groupes, rôles d'administration). Celui-ci lit les ressources (machines virtuelles, bases, stockage, AKS…). Ils ont chacun leur page et leurs droits : un site qui n'a pas d'Azure n'a rien à accorder, et inversement. Une inscription d'application distincte pour chacun est recommandée.
Ce que le connecteur alimente
| Où | Quoi |
|---|---|
| Inventaire des serveurs | Les machines virtuelles et les instances de groupes identiques (dont les nœuds AKS), rapprochées des serveurs déjà connus par leur nom uniquement — jamais par l'adresse IP, car les plages privées d'un réseau virtuel et du réseau interne se recoupent. Deux machines qui portent le même nom d'ordinateur restent deux serveurs distincts (le début de l'identifiant de machine est ajouté) |
| Fiche d'un serveur | Pour une machine virtuelle Azure, un bloc Azure : abonnement, groupe de ressources, région et zone, taille, image, identité managée, services managés du namespace (avec leur fin de support) |
Inventaire Azure (/azure/) |
Régions, Namespaces, Ressources (avec une colonne « Constats » : le nombre de constats ouverts de la ressource, qui ouvre les analyses filtrées sur elle) ; compteurs d'inventaire seulement |
Analyses Azure (/azure/analyses) |
Les constats d'hygiène et de sécurité, leurs compteurs et leurs raccourcis |
| TopoMap | Sur la carte d'une application, le double-clic sur un serveur fait sortir son namespace cloud, puis les services managés qui le composent |
| EOLRIVER | Les versions des services managés et des images sont comparées aux cycles de vie publiés (AKS, PostgreSQL, MySQL, Redis, piles Python / Node.js / .NET / PHP, Ubuntu, Windows Server) |
Régions, namespaces, services managés
- Une région est un emplacement Azure (
francecentral,westeurope…) où un abonnement a des ressources ; seules les régions utilisées sont listées. Les régions à lire se limitent par liste (« Régions à inclure » / « à exclure »). - Le namespace par défaut est le groupe de ressources, le regroupement natif d'Azure. Deux autres modes : la valeur d'un tag (par défaut la clé
Application) ou l'abonnement. Les groupes de ressources créés par Azure pour un cluster AKS (MC_…) sont rattachés au namespace du cluster. En mode tag, une ressource sans le tag tombe dans (non tagué), un signal de gouvernance. Un namespace qui porte le même nom qu'une application d'InfraRiver la propose (jamais de lien imposé). - Les services lus : serveurs et bases SQL, PostgreSQL et MySQL (serveurs flexibles et serveurs uniques), Cosmos DB, Redis, comptes de stockage, registres de conteneurs (ACR), App Service et Functions (pile d'exécution), clusters AKS, Key Vault (propriétés de protection seulement), Event Hubs et Service Bus, disques, adresses IP publiques, groupes de sécurité réseau (NSG), plans Microsoft Defender for Cloud.
- Une requête qu'Azure refuse ou qui échoue s'affiche dans « Lectures impossibles » de l'abonnement ; le reste est lu normalement et rien n'est retiré de ce qui était déjà connu pour la famille qui n'a pas pu être lue. Un abonnement sur lequel l'inscription n'a plus de rôle n'est plus visible : il n'est pas lu, et ses données ne sont pas effacées.
Fin de support
Un service managé ne se patche pas : Azure impose ses montées de version. Les ressources qui portent une version sont comparées aux dates publiées (par EOLRIVER).
Le résultat est la catégorie Hygiène de versions de la page Analyses et la colonne « Support » de l'onglet Ressources.
Note
Le résultat n'est renseigné que si EOLRIVER est installé et a importé les produits Azure (synchronisation d'EOLRIVER en mode embarqué suffisante).
Les serveurs uniques PostgreSQL et MySQL, retirés par Azure, sont signalés à part en gravité critique.
Analyses (/azure/analyses)
| Catégorie | Constats |
|---|---|
| Hygiène de versions | version en fin de support, en support étendu payant, en maintenance seulement ; service « serveur unique » retiré par Azure |
| Exposition | accès anonyme aux blobs d'un compte de stockage ; serveur de base de données ouvert à tout Internet par une règle de pare-feu 0.0.0.0 – 255.255.255.255 ; Cosmos DB ou Key Vault accessible sans filtre ; NSG qui ouvre SSH, RDP, SQL, PostgreSQL… à tout Internet ; machine virtuelle avec IP publique et port d'administration ouvert ; API AKS sans plage autorisée ; registre en téléchargement anonyme |
| Chiffrement & transport | HTTPS non imposé (comptes de stockage, App Service) ; TLS minimal inférieur à 1.2 (stockage, SQL, Redis, Event Hubs / Service Bus) ; port Redis non chiffré ; SSL non imposé sur un serveur unique |
| Identité de la ressource | clé partagée de stockage autorisée ; utilisateur administrateur du registre ; comptes locaux AKS ; authentification par clé Cosmos DB ; authentification Entra seule non imposée sur SQL |
| Secrets | Key Vault sans protection contre la purge ou sans suppression réversible |
| Résilience | base ou cache sans redondance de zone (plus grave si l'étiquette Environment vaut production) ; sauvegardes non géo-redondantes |
| Gouvernance | ressource sans tag de namespace ; disque non attaché ; adresse IP publique non associée ; Defender for Cloud sur le niveau gratuit alors que l'abonnement contient des ressources concernées |
Naviguer dans les constats
Les cartes du haut comptent les constats à traiter par gravité. Une seconde rangée de raccourcis ouvre la liste filtrée. Les boutons de catégorie et les filtres de colonne affinent la liste.
Accepter un risque
Accepter le risque (droit de gestion des connecteurs) ouvre un formulaire qui demande :
- une justification (5 caractères au moins) ;
- une durée : 30 jours, 90 jours, 6 mois ou un an — une date de fin est obligatoire ;
- un motif : « Risque accepté » ou « Objet de test ».
Le constat passe sous « Acceptés » avec qui, quand et jusqu'à quand ; à l'échéance il revient dans « À traiter ». Rouvrir le remet tout de suite. Chaque acceptation et chaque réouverture est inscrite au journal d'audit.
Ce que l'analyse ne regarde pas
Un constat n'existe que si la donnée a vraiment été lue : une propriété qu'Azure ne renvoie pas ne donne ni constat ni fausse assurance.
Le cadre « Ce que cette analyse ne regarde pas (encore) » liste ce qui manque :
- abonnements ou requêtes dont la lecture a été refusée ;
- fin de support non évaluée ;
- ce que le rôle Reader ou Resource Graph ne permettent pas de lire : conteneurs de stockage, secrets et certificats de Key Vault, paramètre SSL des serveurs flexibles, NSG de sous-réseau, TLS minimal et FTP des App Service.
Warning
Une liste vide n'est donc jamais à lire comme « tout va bien ».
Mettre en place l'accès
- Dans Microsoft Entra ID, créez une inscription d'application pour InfraRiver (distincte de celle du connecteur Entra ID). Notez l'ID du tenant et l'ID client : ce ne sont pas des secrets.
- Sur la page de configuration, choisissez le mode d'authentification.
- En mode Certificat (recommandé), cliquez Générer un certificat : la clé privée reste chiffrée dans la base d'InfraRiver, le fichier téléchargé (partie publique) se téléverse dans l'inscription d'application (Certificats et secrets → Certificats). Azure met jusqu'à une minute à reconnaître un certificat qui vient d'être déposé : si le test de connexion répond « clé introuvable », relancez-le un instant plus tard.
- En mode Secret client, créez un secret dans l'inscription et collez sa valeur ; renseignez son échéance pour être prévenu 30 jours avant.
- Donnez à l'inscription le rôle intégré Reader (Lecteur) sur chaque abonnement à lire (ou sur un groupe d'administration) ; la page affiche la commande
az role assignment create. Pour un droit encore plus étroit, le bouton Rôle personnalisé (JSON) fournit un rôle généré à partir de la liste blanche, à importer côté Azure. - Enregistrez puis Tester : le test affiche le tenant, les abonnements visibles et si l'inscription est bien en lecture seule (avertissement orange si elle a un rôle plus large — Contributor, Owner, ou un rôle d'accès aux données —, jamais bloquant).
- Cochez Synchronisation automatique puis Synchroniser maintenant.
| Champ | Type | Description |
|---|---|---|
| ID du tenant | Texte | Identifiant (GUID) de l'annuaire. Le bouton Reprendre celui d'Entra copie la valeur déjà saisie pour le connecteur Entra ID (la valeur seulement, aucun secret n'est partagé). |
| ID client | Texte | Identifiant (GUID) de l'inscription d'application. |
| Mode d'authentification | Liste | Certificat (recommandé : aucun secret à faire tourner) ou secret client. |
| Certificat / Clé privée | Texte (PEM) | Collés, ou générés par le bouton. La clé privée est chiffrée, jamais réaffichée. |
| Secret client / Échéance | Mot de passe / date | Chiffré, jamais réaffiché ; seule l'échéance est montrée. |
| Hôte d'authentification, point d'accès Azure Resource Manager | Texte (avancé) | Pour les clouds souverains (US Government, Chine) ; Azure public par défaut. |
| Abonnements à lire | Texte | Identifiants séparés par des virgules ; vide = tous les abonnements visibles. |
| Régions à inclure / à exclure | Texte | Noms de région séparés par des virgules ; vide = toutes les régions utilisées. |
| Regrouper en namespaces par | Liste | Groupe de ressources (recommandé), tag ou abonnement. |
| Clé de tag du namespace | Texte | Application par défaut. |
| Intervalle de synchronisation | Nombre (minutes, 15-1440) | 360 par défaut. |
| Synchronisation automatique | Case à cocher | Décoché : aucun appel vers Azure. |
Ce que le connecteur ne fait pas encore
Ressources non lues :
- les instances des groupes identiques (donc les nœuds d'un cluster AKS) ;
- les équilibreurs de charge et passerelles d'application ;
- Azure Managed Redis (Azure Cache for Redis n'est plus créable ; sa lecture est prévue, celle d'Azure Managed Redis non).
Fonctions pas encore livrées :
- les attributions de rôle Azure (qui peut exécuter du code sur une machine virtuelle ou prendre le contrôle d'un abonnement) et donc les constats d'accès ;
- les dépendances entre ressources ;
- le coût ;
- le journal d'activité ;
- les recommandations de Defender for Cloud ;
- le multi-tenant.
Le contenu des conteneurs de stockage et les dates d'expiration des secrets de Key Vault ne sont pas lus : ils relèvent du plan de données, qui exige un droit que le rôle Reader n'accorde pas.
Qui voit quoi
- Les rôles qui lisent tout le parc voient tous les abonnements lus.
- Un rôle à périmètre restreint (voir Utilisateurs & permissions) ne voit que les machines virtuelles de ses serveurs et les services managés du même namespace (ou ceux du namespace rattaché à une application dont il est membre). Les services sans tag ne sont montrés qu'aux rôles qui voient tout. Cartes, constats et inventaire suivent la même règle, et les problèmes de lecture ne lui sont pas montrés.
- Sur la page de configuration, l'ID du tenant et l'ID client ne s'affichent en clair qu'aux utilisateurs qui peuvent gérer les connecteurs ; un lecteur n'en voit que les quatre derniers caractères.