Partager via


Fonctionnement de Credential Guard

Kerberos, NTLM et Credential Manager isolent les secrets à l’aide de la sécurité basée sur la virtualisation (VBS). Les versions précédentes de Windows stockait les secrets dans sa mémoire de processus, dans le processus lsass.exeLSA (Local Security Authority).

Avec Credential Guard activé, le processus LSA dans le système d’exploitation communique avec un composant appelé processus LSA isolé qui stocke et protège ces secrets, LSAIso.exe. Les données stockées par le processus LSA isolé sont protégées à l’aide de VBS et ne sont pas accessibles au reste du système d’exploitation. L’autorité de sécurité locale utilise des appels de procédure distante pour communiquer avec le processus LSA isolé.

Pour des raisons de sécurité, le processus LSA isolé n’héberge aucun pilote de périphérique. Au lieu de cela, il héberge uniquement un petit sous-ensemble de fichiers binaires du système d’exploitation nécessaires à la sécurité, et rien d’autre. Tous les fichiers binaires sont signés avec un certificat approuvé par VBS, et les signatures sont validées avant de lancer le fichier dans l’environnement protégé.

Limites de protection de Credential Guard

Certaines méthodes de stockage des informations d’identification ne sont pas protégées par Credential Guard, notamment :

  • Lorsque Credential Guard est activé, NTLMv1, MS-CHAPv2, Digest et CredSSP ne peuvent pas utiliser les informations d’identification de connexion. Par conséquent, l’authentification unique ne fonctionne pas avec ces protocoles. Toutefois, les applications peuvent demander des informations d’identification ou utiliser des informations d’identification stockées dans le coffre Windows, qui ne sont pas protégées par Credential Guard avec l’un de ces protocoles

    Attention

    Il est recommandé que les informations d’identification précieuses, telles que les informations d’identification de connexion, ne soient pas utilisées avec les protocoles NTLMv1, MS-CHAPv2, Digest ou CredSSP.

  • Le logiciel gérant les informations d’identification en dehors de la protection de fonctionnalité.
  • Les comptes locaux et les comptes Microsoft.
  • Credential Guard ne protège pas la base de données Active Directory s’exécutant sur les contrôleurs de domaine Windows Server. Il ne protège pas non plus les pipelines d’entrée d’informations d’identification, tels que Windows Server exécutant la passerelle Bureau à distance. Si vous utilisez un système d’exploitation Windows Server comme PC client, il bénéficie de la même protection que lors de l’exécution d’un système d’exploitation client Windows
  • Les enregistreurs de frappe.
  • Les attaques physiques
  • N’empêche pas un attaquant avec un programme malveillant sur le PC d’utiliser les privilèges associés à toutes les informations d’identification. Nous vous recommandons d’utiliser des PC dédiés pour les comptes à valeur élevée, tels que les professionnels de l’informatique et les utilisateurs ayant accès à des ressources de grande valeur dans votre organisation
  • Packages de sécurité non-Microsoft
  • Les informations d’identification fournies pour l’authentification NTLM ne sont pas protégées. Si un utilisateur est invité à entrer des informations d’identification pour l’authentification NTLM et les entre, ces informations d’identification sont vulnérables à la lecture à partir de la mémoire LSASS. Ces mêmes informations d’identification sont également vulnérables aux enregistreurs d’événements de clés.
  • Les tickets de service Kerberos ne sont pas protégés par Credential Guard, mais le ticket d’octroi de ticket Kerberos (TGT) est protégé
  • Lorsque Credential Guard est activé, Kerberos n’autorise pas la délégation Kerberos ou le chiffrement DES sans contrainte, non seulement pour les informations d’identification de connexion, mais également pour les informations d’identification à l’invite ou enregistrées.
  • Quand Credential Guard est activé sur une machine virtuelle, il protège les secrets contre les attaques à l’intérieur de la machine virtuelle. Toutefois, il ne fournit pas de protection contre les attaques système privilégiées provenant de l’hôte
  • Les vérificateurs de mot de passe windows mis en cache (communément appelés informations d’identification mises en cache) ne sont pas éligibles en tant qu’informations d’identification, car ils ne peuvent pas être présentés à un autre ordinateur à des fins d’authentification et ne peuvent être utilisés que localement pour vérifier les informations d’identification. Ils sont stockés dans le Registre sur l’ordinateur local et permettent de valider les informations d’identification lorsqu’un ordinateur joint à un domaine ne peut pas se connecter à AD DS lors de l’ouverture de session de l’utilisateur. Ces ouvertures de session mises en cache, ou plus spécifiquement les informations de compte de domaine mises en cache, peuvent être gérées à l’aide du paramètre de stratégie de sécurité Ouverture de session interactive : nombre de connexions précédentes à mettre en cache si un contrôleur de domaine n’est pas disponible

Étapes suivantes