Protección de autenticación resistente al phishing: guía paso a paso para implementar autenticación basada en certificados en Entra ID

La autenticación basada en certificados (CBA) es una mejora importante respecto a los inicios de sesión tradicionales con contraseña o la MFA TOTP/OTP convencional. Permite un acceso resistente al phishing y sin contraseña a Microsoft Entra ID (antes Azure AD), además de proteger recursos y servicios críticos. Esta guía explica la implementación de CBA para usuarios finales y aplicaciones (service principals), basándose en la documentación oficial de Microsoft y prácticas del sector.

Nota: el ejemplo original muestra cómo habilitar CBA resistente al phishing para el grupo de administradores de Intune en respuesta a la amenaza reciente del actor Handala, denominado “Stryker”.

Ante amenazas cada vez más sofisticadas, depender únicamente de contraseñas o MFA OTP/TOTP supone un riesgo. CBA de Microsoft Entra ID permite que usuarios y aplicaciones validen su identidad con certificados digitales X.509, reduciendo la exposición al phishing y al robo de credenciales. Esta guía cubre dos casos: autenticación de usuarios (por ejemplo, acceso de empleados a Microsoft 365) y autenticación de aplicaciones o herramientas de automatización mediante service principals.

Parte 1: configurar CBA para la autenticación de usuarios

Este proceso establece la confianza entre su PKI y Microsoft Entra ID, y define cómo se asignan los certificados a las cuentas de usuario.

Requisitos previos

• PKI configurada: necesita una PKI empresarial para emitir certificados a los usuarios.
• Certificados de usuario: deben incluir el User Principal Name (UPN) en el campo Subject Alternative Name (SAN), como RFC822Name (formato de correo) u otro identificador admitido.
• Acceso administrativo: inicie sesión en Microsoft Entra admin center con, como mínimo, el rol Privileged Authentication Administrator.
• Certificate Revocation Lists (CRL): las CA deben publicar CRL en URL accesibles desde Internet para que Microsoft Entra ID pueda comprobar la revocación.

Paso 1: configurar las autoridades de certificación

Microsoft Entra ID debe confiar en las CA que emiten los certificados de usuario. Puede cargar sus certificados de CA en un almacén de confianza basado en PKI.

1. En Entra admin center, vaya a Identity → Identity Secure Score → Public key infrastructure (PKI).
2. Haga clic en + Create PKI, asigne un nombre visible (por ejemplo, “Contoso PKI”) y créelo.
3. Seleccione el contenedor PKI, haga clic en + Add certificate authority y cargue el archivo de certificado de CA raíz o intermedia (`.cer`).
4. Indique si es una Root CA.
5. Introduzca las URL públicas de Certificate Revocation List (CRL) y, opcionalmente, Delta CRL.
6. Compruebe que la opción Issuer hints esté habilitada (valor predeterminado) para filtrar los certificados que se muestran al usuario.
7. Haga clic en Save y repita el proceso para todas las CA de la cadena.

Nota: en despliegues PKI grandes, puede utilizar Upload PKI para cargar de una vez un archivo `.p7b` con todos los certificados CA.

Paso 2: habilitar y configurar CBA en el tenant

Después de establecer la confianza en las CA, habilite el método de autenticación CBA y defina la asignación de certificados a cuentas.

1. Vaya a Protection → Authentication methods → Certificate-based authentication.
2. En la pestaña Enable and target, habilite la política y seleccione los usuarios o grupos autorizados a usar CBA (por ejemplo, “Intune Admin Group” o “All Users”).
3. Configure Username binding (Mapping), que vincula un campo del certificado con un atributo de usuario de Entra ID. Microsoft recomienda asignaciones de alta afinidad que usan propiedades únicas y no reutilizables.
4. Abra la pestaña Configuration. En Username binding, haga clic en Add rule.
5. Para una asignación de alta afinidad, seleccione IssuerAndSerialNumber o SHA1PublicKey y asígnelo a un atributo como CertificateUserIds. Debe rellenar el atributo correspondiente en el objeto de usuario de Entra ID.
6. Para configuraciones de menor afinidad, asigne PrincipalName o RFC822Name (SAN) del certificado al atributo userPrincipalName de Entra ID.
7. En Authentication binding, defina si la autenticación con certificado cuenta como factor único o multifactor. Por ejemplo, puede establecer que certificados con una clave por encima de un umbral (como RSA de 2048 bits) cuenten como autenticación multifactor (MFA).
8. Revise la configuración y haga clic en Save.

Paso 3: aplicar CBA mediante Conditional Access (opcional, recomendado)

Para dejar de depender de contraseñas, puede crear una política Conditional Access que exija CBA para aplicaciones específicas.

1. Vaya a Protection → Conditional Access → Policies y haga clic en + New policy.
2. En Assignments, seleccione los usuarios o grupos y las aplicaciones cloud que desea proteger (por ejemplo, Office 365).
3. En Access controls → Grant, seleccione Require multi-factor authentication (que CBA puede satisfacer) o Require authentication strength. Puede crear una intensidad de autenticación personalizada que exija específicamente CBA.
4. Establezca Enable policy en On y haga clic en Create.

Con estos pasos, los usuarios con un certificado válido y de confianza instalado en su dispositivo (por ejemplo, en el almacén de certificados de Windows) podrán iniciar sesión en aplicaciones como Microsoft 365 sin contraseña o con el requisito de MFA satisfecho.

Parte 2: CBA para aplicaciones (service principals)

Los scripts de automatización y las aplicaciones suelen necesitar autenticarse en Azure. El uso de un certificado es una alternativa más segura que almacenar una contraseña.

Paso 1: preparar el certificado

Puede crear un certificado autofirmado para pruebas o usar uno existente emitido por su PKI. Debe incluir la clave privada y estar en un formato admitido (`.pem` o `.cer` para la clave pública).

• Para crear un certificado autofirmado de prueba, use Azure CLI u OpenSSL.
• Si utiliza uno existente, tenga a mano la clave pública (`.cer`).
• Para convertir un archivo PKCS#12 (`.pfx`) al formato PEM requerido, use OpenSSL:

openssl pkcs12 -in yourcert.pfx -clcerts -nodes -out cert.pem -passin pass:

Paso 2: crear el service principal con el certificado

Puede crear un service principal y cargar su certificado mediante Azure CLI. Inicie sesión en Azure CLI y ejecute uno de estos comandos:

Para crear un certificado autofirmado y un service principal:

az ad sp create-for-rbac --name MyAppWithCert --create-cert --years 2

El comando muestra `appId` y la ubicación del archivo `.pem` que contiene el certificado y la clave privada.

Para usar un certificado público existente (`.cer` o `.pem`):

az ad sp create-for-rbac --name MyAppWithCert --cert @/path/to/publiccertificate.cer

Importante: al usar un certificado existente, cargue solo la clave pública (archivo `.cer`) en Azure AD. La clave privada debe permanecer protegida en el equipo local o en un almacén seguro como Azure Key Vault.

Anote `appId` (client ID) y `tenantId`; los necesitará para autenticarse.

Paso 3: usar el certificado para la autenticación

Las aplicaciones pueden usar la clave privada del certificado para autenticarse. Por ejemplo, para iniciar sesión con Azure CLI mediante el service principal:

az login --service-principal --username APP_ID --password /path/to/cert-with-privatekey.pem --tenant TENANT_ID

También puede utilizar el certificado con PowerShell o mediante bibliotecas como MSAL (Microsoft Authentication Library). La aplicación necesita acceso a la clave privada para crear una aserción de autenticación firmada.

Conclusión

Implementar CBA en Microsoft Entra ID puede reforzar considerablemente la seguridad de la organización. Al reducir la dependencia de contraseñas para usuarios y aplicaciones, y complementar o sustituir la MFA TOTP/OTP tradicional, se avanza hacia una autenticación resistente al phishing y sin contraseña. Tanto si se implementa para empleados que acceden a Microsoft 365 como para scripts DevOps automatizados, estos pasos ofrecen una ruta para gestionar identidades de forma más segura.