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.
