Guide - AZ-500 Microsoft Azure Security Engineer Associate

Fournir un accès juste-à-temps (JIT) aux rôles privilégiés Azure AD, nécessitant approbation et justification.

Configurez Microsoft Entra Privileged Identity Management (PIM) pour le rôle. Définissez "Exiger l'approbation pour activer", spécifiez les approbateurs, activez "Exiger une justification lors de l'activation" et définissez une durée d'activation maximale.

Pourquoi: PIM est le service Azure natif pour l'élévation de rôle JIT. Le simple fait de rendre un utilisateur éligible n'est pas suffisant ; les paramètres de la politique appliquent le flux de travail d'approbation et de justification.

Référence

Appliquer l'MFA et un appareil conforme pour tous les utilisateurs accédant aux applications sensibles, mais exempter un groupe d'assistance spécifique de la règle de conformité des appareils.

Créez deux politiques d'accès conditionnel (CA). La politique 1 cible "Tous les utilisateurs" à l'exclusion du groupe d'assistance, nécessitant l'MFA et un appareil conforme. La politique 2 cible uniquement le groupe d'assistance, ne nécessitant que l'MFA.

Pourquoi: Une seule politique avec une exclusion supprimerait toutes les exigences pour le groupe exclu. Deux politiques ciblées garantissent que chaque groupe reçoit l'ensemble de contrôles correct et distinct.

Référence

Répondre automatiquement aux risques d'identité détectés : bloquer les connexions à haut risque et forcer la réinitialisation des mots de passe pour les utilisateurs à haut risque.

Configurez deux politiques Microsoft Entra ID Protection. Définissez la "Politique de risque de connexion" sur Bloquer l'accès à un niveau de risque Élevé. Définissez la "Politique de risque utilisateur" sur Exiger le changement de mot de passe à un niveau de risque Élevé.

Pourquoi: Le risque de connexion concerne une tentative d'authentification unique (en temps réel), tandis que le risque utilisateur est un score cumulatif concernant l'identité elle-même (informations d'identification compromises). Ils nécessitent des actions de remédiation différentes.

Permettre aux utilisateurs d'un environnement d'identité hybride de réinitialiser leur mot de passe cloud et de le synchroniser avec l'Active Directory local.

Dans Microsoft Entra Connect, activez la fonctionnalité "Réécriture de mot de passe". Dans Azure AD, activez et configurez la réinitialisation de mot de passe en libre-service (SSPR) pour les utilisateurs ciblés.

Pourquoi: SSPR fournit l'interface utilisateur côté cloud pour la réinitialisation de mot de passe, tandis que la réécriture de mot de passe est le composant d'Entra Connect qui synchronise le nouveau hachage de mot de passe vers l'AD local.

Examiner périodiquement tous les accès des utilisateurs invités et supprimer automatiquement les invités qui ne sont plus approuvés ou sont inactifs.

Créez une révision d'accès dans Microsoft Entra ID Governance. Ciblez les utilisateurs invités dans tous les groupes, définissez un calendrier récurrent (par exemple, trimestriel), et activez "Appliquer automatiquement les résultats à la ressource". En option, révisez les utilisateurs inactifs.

Pourquoi: Les révisions d'accès sont l'outil de gouvernance dédié à la recertification périodique de l'accès. La fonction "Appliquer automatiquement les résultats" est essentielle pour boucler la boucle et automatiser la suppression.

Offrir aux partenaires externes un moyen en libre-service de demander un ensemble d'accès (groupes, applications, sites SharePoint) qui expire automatiquement après 90 jours.

Utilisez Microsoft Entra Entitlement Management. Créez une organisation connectée pour le partenaire. Créez un package d'accès contenant les ressources. Définissez une politique pour le package qui permet aux utilisateurs de l'organisation connectée de le demander, avec une expiration de 90 jours.

Pourquoi: La gestion des droits est conçue pour gouverner l'accès à grande échelle, en particulier pour les utilisateurs externes. Elle regroupe les ressources et automatise l'intégralité du cycle de vie de l'accès, de la demande et l'approbation à l'expiration et la suppression.

Une application de haute sécurité exige que les utilisateurs s'authentifient avec une méthode résistante au phishing et aux attaques de l'homme du milieu.

Appliquez des méthodes d'authentification comme les clés de sécurité FIDO2 ou Windows Hello for Business. Ces méthodes utilisent la cryptographie à clé publique et sont liées à l'appareil, empêchant le vol d'informations d'identification.

Pourquoi: Les méthodes comme les SMS, les appels vocaux ou les simples notifications push sont vulnérables au phishing. FIDO2 et WHfB utilisent des défis cryptographiques liés à l'origine de la requête, ce qui les rend résistants au phishing.

Un service d'arrière-plan s'exécutant sur une machine virtuelle doit lire tous les profils utilisateur de Microsoft Graph sans aucune interaction utilisateur.

Enregistrez l'application dans Microsoft Entra ID. Sous les permissions d'API, accordez-lui les permissions "Application" (et non "Déléguées") de Microsoft Graph pour `User.Read.All`. Un administrateur doit accorder le consentement d'administrateur.

Pourquoi: Les permissions d'application permettent à l'application d'agir en tant qu'elle-même, en utilisant sa propre identité (ID client/secret ou certificat). Les permissions déléguées nécessitent un contexte utilisateur connecté, ce qui n'est pas disponible dans une application démon non interactive.

Permettre à un pod d'un cluster AKS d'accéder en toute sécurité à Azure Key Vault sans utiliser d'informations d'identification stockées telles que des secrets client ou des certificats.

Utilisez Azure AD Workload Identity. Créez une identité managée attribuée par l'utilisateur, établissez une identité fédérée entre le compte de service K8s et l'identité managée, et accordez à l'identité managée l'accès à Key Vault.

Pourquoi: Workload Identity utilise la fédération OIDC pour échanger un jeton Kubernetes contre un jeton Azure AD, éliminant complètement le besoin de stocker, gérer ou faire pivoter des secrets dans le cluster.

Référence

Sécuriser un Azure Key Vault pour n'autoriser l'accès que depuis des VNets spécifiques, journaliser toutes les opérations et protéger contre la suppression accidentelle de clés critiques.

Configurez le pare-feu Key Vault pour autoriser l'accès depuis "Point de terminaison privé et réseaux sélectionnés". Activez la journalisation des diagnostics vers un espace de travail Log Analytics. Activez à la fois la suppression réversible et la protection contre la purge.

Pourquoi: La suppression réversible permet de récupérer après une suppression accidentelle, mais la protection contre la purge empêche même un utilisateur privilégié de supprimer définitivement le coffre ou son contenu pendant la période de rétention. Cette combinaison est essentielle pour protéger les clés TDE.

Un Azure App Service doit s'authentifier auprès d'une base de données Azure SQL pour récupérer des données, sans stocker les mots de passe des chaînes de connexion dans la configuration.

Activez une identité managée attribuée par le système sur l'App Service. Dans Azure SQL, créez un utilisateur contenu mappé au nom de l'identité managée de l'App Service et accordez-lui les rôles de base de données nécessaires (par exemple, db_datareader).

Pourquoi: L'identité managée fournit une identité pour la ressource Azure elle-même dans Azure AD. Azure gère automatiquement la création et la rotation des informations d'identification, éliminant les secrets stockés, ce qui est une pratique de sécurité majeure.

Chiffrer les disques managés de machines virtuelles Azure au repos à l'aide d'une clé contrôlée par votre organisation dans Azure Key Vault.

Créez une ressource de jeu de chiffrement de disque. Configurez-la pour utiliser une clé gérée par le client (CMK) de votre Azure Key Vault. Attribuez le jeu de chiffrement de disque aux disques managés de la machine virtuelle.

Pourquoi: Ceci est le chiffrement côté serveur (SSE) avec CMK, qui chiffre les données dans l'infrastructure de stockage. C'est plus simple qu'Azure Disk Encryption (ADE), qui utilise BitLocker/dm-crypt pour chiffrer les données à l'intérieur du système d'exploitation invité et est généralement utilisé pour les disques de système d'exploitation et de données ensemble.

Assurer que les images de conteneurs stockées dans Azure Container Registry (ACR) sont analysées pour détecter les vulnérabilités avant d'être déployées.

Activez Microsoft Defender for Containers. Cela analysera automatiquement les images dans ACR lorsqu'elles sont poussées, lorsqu'elles sont tirées, et de manière continue pour les vulnérabilités nouvellement découvertes.

Pourquoi: Cette pratique de sécurité "shift-left" identifie les vulnérabilités tôt dans le pipeline CI/CD. Defender for Containers offre cette capacité d'analyse nativement au sein de l'écosystème Azure.

Détecter et recevoir des alertes pour les attaques par injection SQL potentielles et les modèles d'accès anormaux sur une base de données Azure SQL.

Activez Microsoft Defender for SQL sur le serveur SQL logique. Cela fournit une protection avancée contre les menaces et une évaluation des vulnérabilités.

Pourquoi: Defender for SQL est le plan de protection de charge de travail dédié qui utilise l'analyse comportementale et le machine learning pour détecter les menaces comme l'injection SQL, les attaques par force brute et les accès inhabituels aux données, qui ne sont pas visibles par les outils au niveau du réseau.

Restreindre un compte de stockage à un VNet spécifique, mais autoriser tout de même les services Microsoft approuvés comme Azure Backup à y accéder.

Dans les paramètres réseau du compte de stockage, sélectionnez "Activé à partir des réseaux virtuels et adresses IP sélectionnés". Ajoutez le VNet/sous-réseau requis. Ensuite, cochez la case "Autoriser les services Microsoft approuvés à accéder à ce compte de stockage".

Pourquoi: L'exception des services approuvés crée un chemin sécurisé permettant à des services Microsoft spécifiques de contourner les règles du pare-feu du VNet. Sans cela, les services qui opèrent au nom de l'utilisateur (comme Sauvegarde ou Portail) seraient bloqués.

Protéger des colonnes de données sensibles spécifiques (par exemple, numéros de carte de crédit) dans une base de données Azure SQL, même des administrateurs de base de données (DBA) privilégiés.

Utilisez Always Encrypted. Le pilote de l'application cliente chiffre les données de manière transparente avant de les envoyer à la base de données, et les clés de chiffrement ne sont jamais révélées au moteur de base de données.

Pourquoi: Transparent Data Encryption (TDE) chiffre l'intégralité de la base de données au repos (sur disque), mais un DBA avec accès peut toujours voir les données. Always Encrypted fournit un chiffrement côté client, séparant ceux qui gèrent les données (DBA) de ceux qui peuvent les voir.

Traiter des données hautement sensibles sur une machine virtuelle Azure, en veillant à ce qu'elles restent chiffrées et protégées même en mémoire, contre l'hyperviseur et les opérateurs cloud.

Déployez une machine virtuelle Azure Confidentielle. Ces machines virtuelles utilisent des environnements d'exécution de confiance (TEE) basés sur le matériel, comme AMD SEV-SNP, pour créer un espace mémoire isolé et chiffré.

Pourquoi: Le chiffrement standard des machines virtuelles (comme ADE ou SSE) protège les données au repos. Le calcul confidentiel est la seule technologie qui protège les données *pendant leur utilisation* en mémoire, offrant le plus haut niveau de confidentialité et d'isolation des données dans le cloud.

Un App Service doit utiliser un secret de Key Vault comme paramètre d'application, sans modifier le code de l'application pour utiliser le SDK Key Vault.

Activez l'identité managée sur l'App Service et accordez-lui les permissions "Obtenir" sur les secrets dans Key Vault. Dans la configuration de l'App Service, créez un paramètre d'application avec la valeur formatée comme une référence Key Vault : `@Microsoft.KeyVault(SecretUri=...)`.

Pourquoi: Cette fonctionnalité permet à la plateforme App Service de résoudre la valeur du secret à l'exécution en utilisant l'identité managée. Le code de l'application lit simplement une variable d'environnement standard, faisant abstraction de l'interaction avec Key Vault.

Stocker les données liées à la conformité dans Azure Blob Storage dans un état WORM (Write-Once, Read-Many) pour une période de rétention de 7 ans.

Sur le conteneur de stockage, configurez une politique d'immuabilité. Utilisez une politique de rétention basée sur le temps définie sur 7 ans et verrouillez la politique. Une fois verrouillées, les données ne peuvent être ni modifiées ni supprimées par quiconque avant l'expiration de la période de rétention.

Pourquoi: Cette fonctionnalité est spécifiquement conçue pour répondre aux exigences de conformité réglementaire (par exemple, SEC 17a-4). Le verrouillage de la politique est l'étape critique qui la rend véritablement immuable.

Dans une application multi-locataire utilisant une seule base de données Azure SQL, assurez-vous que les utilisateurs d'un locataire ne peuvent voir que les données appartenant à leur propre locataire.

Implémentez la sécurité au niveau des lignes (RLS). Créez une politique de sécurité avec une fonction de prédicat qui filtre les lignes en fonction de l'ID de locataire de l'utilisateur, lequel est stocké dans le contexte de session ou dans une table de recherche utilisateur.

Pourquoi: RLS applique la logique d'accès directement au sein du moteur de base de données. C'est plus sécurisé et fiable que d'implémenter le filtrage au niveau de l'application, car il ne peut pas être contourné et est transparent pour le code de l'application.

Protéger les machines virtuelles de génération 2 contre les boot kits et les rootkits en assurant l'intégrité de toute la chaîne de démarrage, de l'UEFI au noyau du système d'exploitation.

Provisionnez la machine virtuelle avec le Lancement fiable activé. Cela active le démarrage sécurisé (Secure Boot), qui valide la signature de tous les composants de démarrage, et un module de plateforme fiable virtuel (vTPM) pour le démarrage mesuré et l'attestation.

Pourquoi: Le Lancement fiable s'attaque aux logiciels malveillants sophistiqués de bas niveau qui peuvent subvertir les contrôles de sécurité traditionnels au niveau du système d'exploitation. Il établit une racine de confiance matérielle pour la machine virtuelle.

Isoler le trafic entre les niveaux d'application (web, application, données) hébergés dans des sous-réseaux séparés.

Créez un groupe de sécurité réseau (NSG) dédié pour chaque sous-réseau. Dans chaque NSG, créez des règles de trafic entrant qui n'autorisent le trafic que depuis la plage d'adresses IP source du niveau précédent sur le port requis. (par exemple, le NSG du niveau application autorise TCP/8080 depuis le sous-réseau du niveau web).

Pourquoi: L'application d'un NSG unique, à moindre privilège, à chaque sous-réseau offre une défense en profondeur et un contrôle granulaire sur les flux de trafic est-ouest, ce qui est plus sécurisé qu'un NSG unique et complexe pour le VNet.

Dans une topologie hub-spoke, forcer tout le trafic entre les VNets de spoke à être inspecté par un NVA ou un pare-feu Azure dans le hub.

Sur chaque sous-réseau de spoke, créez une Route Définie par l'Utilisateur (UDR) pour les espaces d'adressage des autres spokes avec le type de saut suivant défini sur "VirtualAppliance" et l'IP du NVA/pare-feu. Activez le transfert IP sur la carte réseau du NVA.

Pourquoi: Par défaut, le peering VNet permet aux spokes de communiquer directement. Les UDRs outrepassent ce comportement de routage par défaut, forçant le trafic vers le point d'inspection central.

Fournir un service PaaS (par exemple, Azure SQL, Stockage) avec une adresse IP privée au sein de votre VNet, garantissant que le trafic ne transite jamais par l'internet public.

Créez un Private Endpoint pour le service PaaS dans votre VNet. De manière critique, dans les paramètres réseau du service PaaS, désactivez l'accès au réseau public pour bloquer le point de terminaison public.

Pourquoi: Un Private Endpoint amène le service *dans* votre VNet avec une IP privée. Un Service Endpoint optimise simplement la route via le backbone Azure vers une IP publique. La désactivation de l'accès public est nécessaire pour appliquer une communication uniquement privée.

Autoriser le trafic sortant des machines virtuelles vers un ensemble dynamique de points de terminaison de services Microsoft, comme Windows Update, sans maintenir manuellement des listes d'IP.

Dans Azure Firewall, créez une collection de règles d'application. Ajoutez une règle avec le type de FQDN cible défini sur "Balise FQDN" et sélectionnez la balise "WindowsUpdate".

Pourquoi: Les Balises FQDN sont des collections organisées de FQDN que Microsoft gère. C'est la bonne façon d'autoriser l'accès aux services PaaS dont les IPs sous-jacentes changent fréquemment. Les Balises de Service sont pour les règles basées sur IP.

Un pare-feu d'applications web (WAF) bloque le trafic légitime vers votre application en raison d'un faux positif dans une règle gérée (par exemple, injection SQL).

Dans la politique WAF, maintenez le WAF en mode Prévention. Trouvez la règle gérée qui bloque le trafic et configurez une exclusion pour l'en-tête de requête, le cookie ou le paramètre de corps spécifique qui provoque le faux positif.

Pourquoi: Les exclusions sont le moyen le plus précis de gérer les faux positifs. Elles vous permettent de maintenir la protection de la règle pour tout autre trafic tout en faisant une exception spécifique, ce qui est plus sécurisé que de désactiver toute la règle.

Fournir un accès RDP/SSH sécurisé aux machines virtuelles Azure sans exposer les ports de gestion à internet ni nécessiter d'adresses IP publiques sur les machines virtuelles.

Déployez Azure Bastion (SKU Standard pour les fonctionnalités avancées) dans un sous-réseau dédié du VNet. Accédez aux machines virtuelles via le portail Azure, qui se connecte via le service Bastion.

Pourquoi: Bastion agit comme une boîte de saut sécurisée, intermédiant la connexion RDP/SSH. La seule IP publique est sur le service Bastion lui-même, qui est renforcé et géré par Microsoft, réduisant considérablement la surface d'attaque de vos machines virtuelles.

Fournir aux développeurs un accès audité et limité dans le temps aux ports de gestion (RDP/SSH) sur les machines virtuelles de développement.

Activez Microsoft Defender for Cloud et configurez l'accès Just-in-Time (JIT) aux machines virtuelles. Les utilisateurs demanderont l'accès via Defender for Cloud, qui modifie dynamiquement les règles NSG pour autoriser l'accès pendant une durée limitée depuis une IP spécifique.

Pourquoi: JIT est une fonctionnalité clé de Defender for Cloud qui renforce la posture réseau des machines virtuelles en maintenant les ports de gestion fermés par défaut, ne les ouvrant qu'à la demande.

Appliquer les meilleures pratiques de sécurité, telles que l'interdiction des conteneurs privilégiés, sur un cluster Azure Kubernetes Service (AKS) au moment du déploiement.

Activez l'extension Azure Policy pour AKS. Attribuez l'initiative de politique intégrée nommée "Normes de sécurité de pod de cluster Kubernetes restreintes pour les charges de travail basées sur Linux".

Pourquoi: Ceci utilise Azure Policy comme contrôleur d'admission centralisé et à grande échelle pour Kubernetes, appliquant des garde-fous de sécurité et de conformité avant même la création des charges de travail dans le cluster.

Router tout le trafic sortant vers internet depuis un VNet Azure vers une appliance de sécurité sur site pour inspection avant qu'il n'atteigne internet.

Configurez un VPN site à site ou ExpressRoute. Créez une Route Définie par l'Utilisateur (UDR) pour le préfixe d'adresse 0.0.0.0/0, et définissez le saut suivant comme étant la passerelle de réseau virtuel.

Pourquoi: Ce modèle, connu sous le nom de tunneling forcé, outrepassera la route par défaut d'Azure vers internet et forcera tout le trafic sortant à traverser la passerelle vers le réseau sur site, garantissant qu'aucune machine virtuelle ne peut contourner les contrôles de sécurité de l'entreprise.

Inspecter le trafic TLS chiffré sortant des machines virtuelles pour détecter les menaces à l'aide d'Azure Firewall.

Déployez Azure Firewall Premium. Activez l'inspection TLS et la détection d'intrusion (IDPS). Configurez un certificat d'autorité de certification subordonnée sur le pare-feu et déployez sa clé publique sur les machines virtuelles clientes en tant qu'autorité de certification racine approuvée.

Pourquoi: Pour inspecter le trafic chiffré, le pare-feu doit effectuer une opération de type "homme du milieu". Cela nécessite la SKU Premium, l'IDPS pour la détection des menaces, et une infrastructure de certificats appropriée pour éviter les erreurs TLS sur les machines clientes.

Protéger toutes les applications exposées au public sur plusieurs VNets et abonnements contre les attaques DDoS volumétriques de manière rentable.

Créez un seul plan de protection Azure DDoS. Associez ce plan unique à tous les réseaux virtuels qui contiennent des adresses IP publiques nécessitant une protection.

Pourquoi: Un seul plan de protection DDoS peut couvrir jusqu'à 100 VNets, et vous payez un forfait mensuel pour le plan, et non par VNet ou par IP. Ce modèle centralisé est beaucoup plus rentable que le déploiement de plusieurs plans ou l'utilisation du SKU de protection par IP.

Lorsqu'un incident de gravité élevée est créé dans Microsoft Sentinel, désactivez automatiquement le compte utilisateur impliqué dans Azure AD et avertissez l'équipe de sécurité dans Teams.

Créez une règle d'automatisation qui se déclenche lors de la création d'un incident de gravité élevée. La règle doit appeler un Playbook (Logic App). Le playbook utilise le connecteur Azure AD pour désactiver l'utilisateur et le connecteur Teams pour publier un message.

Pourquoi: Ceci démontre le modèle SOAR (Security Orchestration, Automation, and Response). La règle d'automatisation est le moteur de déclenchement/condition, et le Playbook est le moteur d'action/workflow.

Référence

Appliquer un ensemble cohérent de politiques de sécurité et activer les plans Defender for Cloud sur un grand nombre d'abonnements Azure.

Organisez tous les abonnements sous un groupe d'administration. Attribuez l'initiative de politique Azure Security Benchmark et activez les plans Defender for Cloud requis au niveau du groupe d'administration.

Pourquoi: Les groupes d'administration sont l'outil principal pour la gouvernance à l'échelle de l'entreprise. Les politiques et les paramètres appliqués à ce niveau sont hérités par tous les abonnements enfants, assurant la cohérence et réduisant la charge administrative.

Créer une détection personnalisée dans Sentinel pour un utilisateur se connectant pour la première fois depuis un nouveau pays.

Créez une règle d'analyse de requête planifiée. Utilisez une requête KQL qui joint les `SigninLogs` récents avec un historique résumé des `SigninLogs` passés pour identifier les combinaisons UserPrincipalName/Pays jamais vues auparavant.

Pourquoi: Les règles de requête planifiées avec KQL sont la base de la détection de menaces personnalisée dans Sentinel, permettant une logique complexe et avec état qui va au-delà de la simple correspondance d'événements.

Conserver les journaux de sécurité dans Sentinel pendant 2 ans pour la conformité, mais ne garder que les 90 jours les plus récents disponibles pour des requêtes rapides et interactives afin de gérer les coûts.

Dans l'espace de travail Log Analytics, définissez la "Rétention interactive" à 90 jours. Définissez la "Rétention totale" (Archive) à 730 jours (2 ans). Configurez des politiques de rétention par table si nécessaire.

Pourquoi: Cette approche à plusieurs niveaux équilibre le coût et les capacités. Le niveau interactif est coûteux mais rapide. Le niveau d'archivage est très peu coûteux pour le stockage à long terme. Les données archivées peuvent toujours être interrogées via des tâches de recherche asynchrones ou restaurées temporairement.

Lors d'une investigation d'incident, vous devez visualiser rapidement les relations entre un utilisateur compromis, l'adresse IP d'où il s'est connecté et les ressources auxquelles il a accédé.

Depuis la page d'incident dans Microsoft Sentinel, ouvrez le graphique d'investigation. Utilisez le graphique pour explorer visuellement les entités et leurs connexions à travers différentes alertes et sources de journaux.

Pourquoi: Le graphique d'investigation est un puissant outil de visualisation qui cartographie l'histoire de l'attaque, rendant beaucoup plus facile de comprendre la portée et la chronologie d'un incident que par la corrélation manuelle d'événements dans les requêtes de journaux.

Détecter un attaquant qui a compromis un compte utilisateur et tente maintenant d'accéder à des ressources ou hôtes inhabituels au sein du réseau.

Assurez-vous que l'analyse du comportement des utilisateurs et des entités (UEBA) est activée dans Microsoft Sentinel et que les sources de données pertinentes (journaux Azure AD, Defender for Endpoint/événements de sécurité) sont connectées. Surveillez l'UEBA pour les détections d'anomalies liées au mouvement latéral.

Pourquoi: L'UEBA établit une base de référence du comportement normal pour chaque utilisateur et entité. Elle excelle à détecter les déviations qui indiquent un mouvement latéral, telles qu'un utilisateur accédant à un serveur pour la première fois ou utilisant des protocoles inhabituels, difficiles à repérer avec des règles statiques.

Réduire les coûts d'ingestion de Microsoft Sentinel pour les journaux volumineux et verbaux qui sont nécessaires pour la conformité mais pas pour l'analyse en temps réel.

Configurez le plan de table pour ces journaux sur "Journaux de base". De plus, utilisez des règles de collecte de données (DCR) avec des requêtes XPath ou d'autres transformations pour filtrer les événements bruyants et de faible valeur avant l'ingestion.

Pourquoi: Les Journaux de base offrent un coût d'ingestion nettement inférieur en échange de capacités de requête limitées et d'une rétention plus courte. Le filtrage à la source avec les DCRs est le moyen le plus efficace de réduire le volume en empêchant les données indésirables d'atteindre l'espace de travail.

Appliquer automatiquement un paramètre de sécurité, comme l'activation de "Transfert sécurisé requis" sur tous les comptes de stockage Azure existants et nouveaux.

Attribuez une politique Azure avec l'effet `DeployIfNotExists` ou `Modify`. Pour les ressources non conformes existantes, créez une tâche de correction à partir du volet de conformité de la politique pour appliquer le changement.

Pourquoi: Les politiques d'audit et de refus ne font que signaler ou bloquer la non-conformité. `DeployIfNotExists` et `Modify` avec des tâches de correction corrigent activement les mauvaises configurations, faisant de la politique un outil puissant pour la gouvernance automatisée et le renforcement de la sécurité.

Détecter les menaces d'exécution dans un cluster AKS, telles que l'exécution de processus suspects ou la connexion d'un conteneur à une IP malveillante connue.

Activez Microsoft Defender for Containers. Cela déploie un DaemonSet (agent Defender) sur chaque nœud du cluster, qui collecte les signaux de sécurité de l'hôte et des conteneurs pour fournir une détection des menaces en temps réel.

Pourquoi: Bien que l'analyse ACR offre une sécurité "shift-left", la protection au moment de l'exécution est cruciale pour détecter les menaces qui surviennent après le déploiement. Defender for Containers offre cette visibilité au niveau de l'hôte et de la charge de travail au sein du cluster.