Cómo funciona Credential Guard

Kerberos, NTLM y Credential Manager aíslan los secretos mediante la seguridad basada en virtualización (VBS). Versiones anteriores de secretos almacenados de Windows en su memoria de proceso, en el proceso de autoridad de seguridad local (LSA).lsass.exe Con Credential Guard habilitado, el proceso LSA del sistema operativo se comunica con un componente denominado proceso LSA aislado que almacena y protege esos secretos, LSAIso.exe. Los datos almacenados por el proceso LSA aislado están protegidos mediante VBS y no son accesibles para el resto del sistema operativo. LSA usa llamadas a procedimiento remoto para comunicarse con el proceso LSA aislado.

Por motivos de seguridad, el proceso LSA aislado no hospeda ningún controlador de dispositivo. En su lugar, solo hospeda un pequeño subconjunto de binarios del sistema operativo que solo son necesarios para la seguridad. Todos los archivos binarios están firmados con un certificado en el que vbs confía y las firmas se validan antes de iniciar el archivo en el entorno protegido.

Esta es una introducción de alto nivel sobre cómo el LSA se aísla mediante la seguridad basada en virtualización:

Diagrama de la arquitectura de Credential Guard.

Límites de protección de Credential Guard

Algunas maneras de almacenar credenciales no están protegidas por Credential Guard, como:

  • Software que administra credenciales fuera de la protección de la característica de Windows
  • Cuentas locales y cuentas de Microsoft
  • Credential Guard no protege la base de datos de Active Directory que se ejecuta en controladores de dominio de Windows Server. Tampoco protege las canalizaciones de entrada de credenciales, como Windows Server que ejecuta puerta de enlace de Escritorio remoto. Si usa un sistema operativo Windows Server como equipo cliente, obtendrá la misma protección que al ejecutar un sistema operativo cliente Windows.
  • Registradores de pulsaciones de teclas
  • Ataques físicos
  • No impide que un atacante con malware en el equipo use los privilegios asociados a cualquier credencial. Se recomienda usar equipos dedicados para cuentas de alto valor, como profesionales de TI y usuarios con acceso a recursos de alto valor en su organización.
  • Paquetes de seguridad de terceros
  • Cuando Credential Guard está habilitado, NTLMv1, MS-CHAPv2, Digest y CredSSP no pueden usar las credenciales de sesión iniciadas. Por lo tanto, el inicio de sesión único no funciona con estos protocolos. Sin embargo, las aplicaciones pueden solicitar credenciales o usar credenciales almacenadas en el almacén de Windows, que no están protegidas por Credential Guard con ninguno de estos protocolos.

    Precaución

    Se recomienda que las credenciales valiosas, como las credenciales de inicio de sesión, no se usen con los protocolos NTLMv1, MS-CHAPv2, Digest o CredSSP. Si estos protocolos deben usarse por dominio o Microsoft Entra usuarios, se deben aprovisionar credenciales secundarias para estos casos de uso.

  • Las credenciales proporcionadas para la autenticación NTLM no están protegidas. Si se pide a usuario que escriba las credenciales para la autenticación NTLM y obedece a esta solicitud, dichas credenciales se podrán leer desde la memoria LSASS. Estas mismas credenciales también son vulnerables a los registradores de claves.
  • Los vales de servicio kerberos no están protegidos por Credential Guard, pero el vale de concesión de vales de Kerberos (TGT) está protegido
  • Cuando Credential Guard está habilitado, Kerberos no permite la delegación de Kerberos sin restricciones ni el cifrado DES, no solo para las credenciales iniciadas, sino también para las credenciales que se han pedido o guardado.
  • Cuando Credential Guard está habilitado en una máquina virtual, protege los secretos frente a ataques dentro de la máquina virtual. Sin embargo, no proporciona protección contra ataques del sistema con privilegios originados en el host.
  • Los comprobadores de contraseñas almacenadas en caché de inicio de sesión de Windows (normalmente denominados credenciales almacenadas en caché) no califican como credenciales porque no se pueden presentar a otro equipo para la autenticación y solo se pueden usar localmente para comprobar las credenciales. Se almacenan en el registro en el equipo local y proporcionan validación para las credenciales cuando un equipo unido a un dominio no se puede conectar a AD DS durante el inicio de sesión del usuario. Estos inicios de sesión almacenados en caché, o más específicamente, la información de la cuenta de dominio almacenada en caché, se pueden administrar mediante la configuración de directiva de seguridad Inicio de sesión interactivo: número de inicios de sesión anteriores que se almacenarán en caché si un controlador de dominio no está disponible

Pasos siguientes