{"id":7411,"date":"2025-08-13T15:25:43","date_gmt":"2025-08-13T18:25:43","guid":{"rendered":"https:\/\/itconnect.lat\/portal\/?p=7411"},"modified":"2025-08-13T15:25:43","modified_gmt":"2025-08-13T18:25:43","slug":"zero-trust-0001","status":"publish","type":"post","link":"https:\/\/itconnect.lat\/portal\/zero-trust-0001\/","title":{"rendered":"Zero Trust: Evaluando las Brechas de Seguridad 2025"},"content":{"rendered":"
\n

1: Introducci\u00f3n: La Paradoja de la Confianza en la Era del “Zero Trust”<\/h2>\n

1.1. El Cambio de Paradigma: De Per\u00edmetros Fortificados a Identidades Verificadas<\/h3>\n
\"Zero<\/a>
Zero Trust<\/figcaption><\/figure>\n

Durante d\u00e9cadas, el modelo de seguridad de la informaci\u00f3n empresarial se ha basado en una analog\u00eda arquitect\u00f3nica: el castillo y el foso. En este paradigma, se constru\u00eda un per\u00edmetro de red robusto y fortificado, y se asum\u00eda que cualquier entidad dentro de sus muros era inherentemente confiable.<\/p>\n

Las Redes Privadas Virtuales (VPN) se convirtieron en el puente levadizo tecnol\u00f3gico de este modelo, proporcionando un t\u00fanel cifrado para que los usuarios remotos pudieran cruzar el foso y acceder a la totalidad de la red corporativa interna.<\/p>\n

Sin embargo, la transformaci\u00f3n digital, impulsada por la adopci\u00f3n masiva de la nube, la movilidad de la fuerza laboral y los entornos de trabajo h\u00edbridos, ha disuelto eficazmente este per\u00edmetro.<\/p>\n

Los datos y las aplicaciones ya no residen en un \u00fanico centro de datos, sino que est\u00e1n distribuidos en m\u00faltiples proveedores de nube, y los usuarios acceden a ellos desde cualquier lugar del mundo.\u00a0 \u00a0<\/span><\/p>\n

Este nuevo panorama ha expuesto las limitaciones fundamentales del modelo de VPN tradicional. Al otorgar acceso a nivel de red, una VPN comprometida se convierte en una puerta de entrada para que los atacantes se muevan lateralmente sin restricciones, explorando y explotando recursos internos con relativa facilidad.<\/p>\n

Adem\u00e1s, las VPN a menudo act\u00faan como un cuello de botella de rendimiento, enrutando todo el tr\u00e1fico a trav\u00e9s de un concentrador central, lo que degrada la experiencia del usuario y no se escala eficientemente en arquitecturas de nube distribuidas.\u00a0 \u00a0<\/span><\/p>\n

En respuesta a estas deficiencias, la industria ha adoptado un nuevo paradigma de seguridad conocido como “Confianza Cero” (Zero Trust). Formalizado en marcos como la Publicaci\u00f3n Especial 800-207 del Instituto Nacional de Est\u00e1ndares y Tecnolog\u00eda (NIST), el modelo de Confianza Cero opera bajo un principio fundamental y riguroso: “nunca confiar, siempre verificar”.<\/p>\n

Este enfoque descarta la noci\u00f3n de un per\u00edmetro de confianza; asume que las amenazas pueden existir tanto dentro como fuera de la red y, por lo tanto, cada solicitud de acceso, sin importar su origen, debe ser autenticada, autorizada y validada de forma continua.<\/p>\n

El Acceso a la Red de Confianza Cero (ZTNA) ha surgido como la tecnolog\u00eda principal para implementar este principio en el contexto del acceso remoto, reemplazando r\u00e1pidamente a las VPN como la soluci\u00f3n preferida para conectar de forma segura a los usuarios con las aplicaciones.\u00a0 \u00a0<\/span><\/p>\n

1.2. La Promesa de ZTNA: Acceso de M\u00ednimo Privilegio y Superficie de Ataque Reducida<\/h3>\n

La propuesta de valor fundamental de ZTNA reside en su capacidad para redefinir radicalmente el control de acceso. A diferencia de las VPN, que conectan a un usuario a una red, las soluciones ZTNA conectan a un usuario verificado directamente con una aplicaci\u00f3n espec\u00edfica.<\/p>\n

Este enfoque intr\u00ednsecamente granular aplica el principio de m\u00ednimo privilegio, asegurando que los usuarios solo reciban el nivel de acceso estrictamente necesario para realizar sus funciones, y nada m\u00e1s.<\/p>\n

Si las credenciales de un usuario fueran comprometidas, el “radio de explosi\u00f3n” del incidente se contendr\u00eda dr\u00e1sticamente, ya que el atacante solo podr\u00eda acceder a las aplicaciones expl\u00edcitamente autorizadas para ese usuario, eliminando la capacidad de movimiento lateral a trav\u00e9s de la red corporativa.\u00a0 \u00a0<\/span><\/p>\n

Adem\u00e1s, las arquitecturas ZTNA est\u00e1n dise\u00f1adas para reducir la superficie de ataque de una organizaci\u00f3n. Al colocar las aplicaciones detr\u00e1s de un agente de ZTNA, se vuelven invisibles en la Internet p\u00fablica, protegidas de escaneos y ataques no solicitados.<\/p>\n

La seguridad se ve reforzada por la validaci\u00f3n continua de la postura del dispositivo.<\/p>\n

Antes de conceder el acceso, el sistema ZTNA verifica la identidad del usuario, la identidad del dispositivo y su estado de seguridad (por ejemplo, si el sistema operativo est\u00e1 actualizado, si el software antimalware est\u00e1 en ejecuci\u00f3n, etc.), y esta validaci\u00f3n se repite peri\u00f3dicamente durante toda la sesi\u00f3n.<\/p>\n

Esta combinaci\u00f3n de acceso a nivel de aplicaci\u00f3n, aplicaci\u00f3n del principio de m\u00ednimo privilegio y verificaci\u00f3n continua de la postura del dispositivo representa, en teor\u00eda, un avance significativo en la seguridad del acceso remoto.\u00a0 \u00a0<\/span><\/p>\n

1.3. Tesis Central: La Grieta en los Cimientos de la Confianza<\/h3>\n

A pesar de la robusta promesa te\u00f3rica de ZTNA, una investigaci\u00f3n pionera presentada en la conferencia de ciberseguridad DEF CON 33 por los investigadores de seguridad David Cash y Richard Warren de la consultora brit\u00e1nica AmberWolf ha revelado una realidad preocupante.<\/p>\n

Su campa\u00f1a de investigaci\u00f3n de siete meses descubri\u00f3 vulnerabilidades cr\u00edticas en las soluciones ZTNA de varios de los principales proveedores de ciberseguridad del mundo, incluidos Zscaler, Netskope y Check Point.<\/p>\n

Los hallazgos, que van desde omisiones completas de autenticaci\u00f3n y suplantaci\u00f3n de identidad entre organizaciones hasta escaladas de privilegios locales, no son meramente errores de software aislados.<\/p>\n

Colectivamente, representan una grieta sist\u00e9mica en los cimientos mismos del ecosistema ZTNA.\u00a0 \u00a0<\/span><\/p>\n

La tesis central de este informe es que estas vulnerabilidades demuestran un peligroso desajuste entre la comercializaci\u00f3n de la “Confianza Cero” y la realidad de su implementaci\u00f3n.<\/p>\n

Las fallas descubiertas no son el resultado de vectores de ataque novedosos y complejos espec\u00edficos de ZTNA, sino de fallas en la higiene de seguridad fundamental: validaci\u00f3n criptogr\u00e1fica inadecuada, uso de credenciales est\u00e1ticas y no revocables, y exposici\u00f3n de datos sensibles.<\/p>\n

Esto sugiere que la confianza que las organizaciones depositan en sus proveedores de ZTNA, y en la marca “Zero Trust” en s\u00ed misma, puede estar peligrosamente fuera de lugar.<\/p>\n

La industria, en su prisa por adoptar la pr\u00f3xima generaci\u00f3n de seguridad de acceso, puede estar pasando por alto el hecho de que estas plataformas, a pesar de su sofisticaci\u00f3n conceptual, son susceptibles a errores de implementaci\u00f3n de primer orden.<\/p>\n

Este an\u00e1lisis explorar\u00e1 en profundidad las vulnerabilidades t\u00e9cnicas, deconstruir\u00e1 sus implicaciones estrat\u00e9gicas y ofrecer\u00e1 recomendaciones para que las organizaciones naveguen por este panorama de confianza rota.<\/p>\n

2: An\u00e1lisis T\u00e9cnico Profundo de las Vulnerabilidades Descubiertas<\/h2>\n

La investigaci\u00f3n de AmberWolf sac\u00f3 a la luz un conjunto de vulnerabilidades de alta gravedad que afectan a los componentes centrales de las plataformas ZTNA de varios l\u00edderes del mercado. Estos hallazgos, resumidos en la siguiente tabla, pintan un cuadro alarmante de las debilidades fundamentales en productos que se comercializan como el pin\u00e1culo de la seguridad de acceso.<\/p>\n

\n
\n
\n
\n\n\n\n\n\n\n\n\n\n
Proveedor<\/td>\nProducto\/Componente Afectado<\/td>\nDescripci\u00f3n de la Vulnerabilidad<\/td>\nIdentificador CVE\/Estado<\/td>\nImpacto Principal<\/td>\n<\/tr>\n<\/thead>\n
Netskope<\/b><\/td>\nCliente \/ Plataforma<\/td>\nOmisi\u00f3n de autenticaci\u00f3n en la inscripci\u00f3n de IdP mediante “OrgKey” est\u00e1tica y no revocable.<\/td>\nCVE-2024-7401<\/td>\nEvasi\u00f3n de autenticaci\u00f3n, Suplantaci\u00f3n de identidad.<\/td>\n<\/tr>\n
Netskope<\/b><\/td>\nCliente \/ Plataforma<\/td>\nSuplantaci\u00f3n de identidad de usuarios entre organizaciones utilizando una OrgKey<\/code> y cualquier clave de inscripci\u00f3n.<\/td>\nPendiente<\/td>\nEvasi\u00f3n de autenticaci\u00f3n, Violaci\u00f3n de aislamiento de inquilinos.<\/td>\n<\/tr>\n
Netskope<\/b><\/td>\nCliente (Windows)<\/td>\nEscalada de privilegios local a nivel de SYSTEM<\/code> al forzar la comunicaci\u00f3n con un servidor no autorizado.<\/td>\nPendiente<\/td>\nEscalada de privilegios, Compromiso del endpoint.<\/td>\n<\/tr>\n
Zscaler<\/b><\/td>\nPlataforma ZIA<\/td>\nOmisi\u00f3n de la autenticaci\u00f3n SAML debido a la validaci\u00f3n incorrecta de la firma criptogr\u00e1fica en las aserciones.<\/td>\nCVE-2025-54982<\/td>\nEvasi\u00f3n de autenticaci\u00f3n completa, Acceso no autorizado a recursos internos.<\/td>\n<\/tr>\n
Check Point<\/b><\/td>\nServicio Perimeter 81<\/td>\nCredenciales SFTP codificadas de forma r\u00edgida que exponen registros de clientes y material JWT.<\/td>\nNo asignado<\/td>\nExposici\u00f3n de datos multi-inquilino, Potencial evasi\u00f3n de autenticaci\u00f3n.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
2.1. Netskope: Fallas Sist\u00e9micas en la Autenticaci\u00f3n y el Endpoint<\/span><\/div>\n<\/div>\n<\/div>\n<\/div>\n

La investigaci\u00f3n sobre los productos de Netskope revel\u00f3 m\u00faltiples vectores de ataque que comprometen tanto el proceso de autenticaci\u00f3n basado en la nube como la seguridad del cliente instalado en el endpoint.<\/p>\n

2.1.1. CVE-2024-7401: La “OrgKey” Est\u00e1tica y la Evasi\u00f3n de Autenticaci\u00f3n<\/h4>\n

La vulnerabilidad m\u00e1s documentada, identificada como CVE-2024-7401, reside en el proceso de inscripci\u00f3n del cliente de Netskope cuando se utiliza el modo de Proveedor de Identidad (IdP).<\/p>\n

El problema se centra en el uso de una OrgKey<\/code>, un token est\u00e1tico que funciona como un par\u00e1metro de autenticaci\u00f3n fundamental durante la inscripci\u00f3n del cliente.<\/p>\n

La naturaleza de esta clave es el n\u00facleo del problema: es est\u00e1tica, lo que significa que no cambia, y, lo que es m\u00e1s cr\u00edtico, no puede ser revocada por una organizaci\u00f3n si se filtra.\u00a0 \u00a0<\/span><\/p>\n

Seg\u00fan el aviso de seguridad de la propia Netskope (NSKPSA-2024-001), un actor malicioso que obtenga esta OrgKey<\/code> puede usarla para inscribir un nuevo cliente de Netskope no autorizado en el inquilino de una organizaci\u00f3n v\u00edctima.<\/p>\n

Al hacerlo, el atacante puede suplantar a cualquier usuario dentro de esa organizaci\u00f3n, eludiendo por completo los controles de autenticaci\u00f3n y obteniendo acceso a los recursos protegidos por la plataforma ZTNA. Este mecanismo crea un punto \u00fanico de fallo persistente y de alto impacto. \u00a0<\/span><\/p>\n

2.1.2. Suplantaci\u00f3n de Identidad entre Organizaciones<\/h4>\n

La investigaci\u00f3n de AmberWolf llev\u00f3 la explotaci\u00f3n de la OrgKey<\/code> un paso m\u00e1s all\u00e1, descubriendo una falla a\u00fan m\u00e1s grave con implicaciones para la arquitectura multi-inquilino. Demostraron que un atacante que posea una OrgKey<\/code> no revocable puede combinarla con cualquier<\/i> clave de inscripci\u00f3n, incluso una perteneciente a un inquilino completamente diferente, para lograr una omisi\u00f3n total de la autenticaci\u00f3n.\u00a0 \u00a0<\/span><\/p>\n

Este hallazgo es particularmente devastador porque rompe el aislamiento l\u00f3gico que se supone que debe existir entre los diferentes clientes en una plataforma SASE (Secure Access Service Edge) multi-inquilino.<\/p>\n

Permite a un atacante con conocimiento de la OrgKey<\/code> de la Organizaci\u00f3n A y una clave de inscripci\u00f3n de la Organizaci\u00f3n B (que podr\u00eda obtenerse, por ejemplo, a trav\u00e9s de una cuenta de prueba) suplantar a un usuario en la Organizaci\u00f3n A.<\/p>\n

Esto no solo es una evasi\u00f3n de autenticaci\u00f3n, sino una violaci\u00f3n fundamental de la confianza y la segregaci\u00f3n de datos que los proveedores de la nube deben garantizar.<\/p>\n

2.1.3. Escalada de Privilegios a SYSTEM (CVE Pendiente)<\/h4>\n
\"Zero<\/a>
Zero Trust<\/figcaption><\/figure>\n

M\u00e1s all\u00e1 de las fallas de autenticaci\u00f3n en la nube, la investigaci\u00f3n tambi\u00e9n identific\u00f3 una vulnerabilidad cr\u00edtica de escalada de privilegios local (LPE) en el cliente de Netskope para Windows. El cliente de ZTNA, por su naturaleza, opera con altos privilegios en el sistema operativo para poder interceptar y enrutar el tr\u00e1fico de red. Esta vulnerabilidad permite a un atacante con bajos privilegios en una m\u00e1quina local forzar al cliente de Netskope a comunicarse con un servidor no autorizado (rogue server) controlado por el atacante.\u00a0 \u00a0<\/span><\/p>\n

Al explotar esta confianza fuera de lugar en la comunicaci\u00f3n con el servidor, el atacante puede manipular el comportamiento del cliente para ejecutar c\u00f3digo con privilegios de SYSTEM<\/code>, el nivel m\u00e1s alto de acceso en un sistema Windows.<\/p>\n

Este hallazgo es crucial porque demuestra que el agente ZTNA, lejos de ser solo un conducto pasivo, es una pieza de software privilegiada que puede convertirse en un potente vector de ataque para comprometer completamente el endpoint que se supone que debe proteger.\u00a0 \u00a0<\/span><\/p>\n

2.2. Zscaler: El Enga\u00f1o de la Firma SAML (CVE-2025-54982)<\/h3>\n

La vulnerabilidad descubierta en la plataforma de Zscaler, rastreada como CVE-2025-54982, representa un fallo de libro de texto en la implementaci\u00f3n de un protocolo de autenticaci\u00f3n federada.<\/p>\n

La falla fue clasificada como una “verificaci\u00f3n incorrecta de la firma criptogr\u00e1fica” dentro del mecanismo de autenticaci\u00f3n SAML (Security Assertion Markup Language) del lado del servidor.<\/p>\n

Con una puntuaci\u00f3n CVSS de 9.6 (Cr\u00edtica), esta vulnerabilidad permit\u00eda un abuso de autenticaci\u00f3n completo.\u00a0 \u00a0<\/span><\/p>\n

El protocolo SAML se basa en la confianza digital establecida a trav\u00e9s de firmas criptogr\u00e1ficas. Un Proveedor de Identidad (IdP) leg\u00edtimo firma una “aserci\u00f3n” SAML con su clave privada, y el Proveedor de Servicios (SP), en este caso Zscaler, debe verificar esa firma utilizando la clave p\u00fablica del IdP correspondiente para confirmar la autenticidad de la aserci\u00f3n.<\/p>\n

La investigaci\u00f3n de AmberWolf revel\u00f3 que la plataforma de Zscaler no realizaba esta validaci\u00f3n crucial correctamente.<\/p>\n

El sistema verificaba que la aserci\u00f3n SAML\u00a0estuviera<\/i> firmada, pero no verificaba que estuviera firmada por el IdP <\/span>correcto<\/i> y de confianza.<\/span> \u00a0<\/span>Este descuido permiti\u00f3 a un atacante ejecutar el siguiente flujo de ataque :\u00a0 \u00a0<\/span><\/p>\n

    \n
  1. Generar su propio par de claves y certificado autofirmado.<\/li>\n
  2. Crear una aserci\u00f3n SAML maliciosa, nombrando a cualquier usuario v\u00edctima en el campo <NameID><\/code>.<\/li>\n
  3. Firmar esta aserci\u00f3n falsificada con su propia clave privada.<\/li>\n
  4. Enviar la aserci\u00f3n firmada al endpoint SAML de Zscaler.<\/li>\n<\/ol>\n

    Debido a la validaci\u00f3n de firma defectuosa, la plataforma de Zscaler aceptaba la aserci\u00f3n falsificada como v\u00e1lida y emit\u00eda un token de acceso leg\u00edtimo para la cuenta del usuario v\u00edctima.<\/p>\n

    Este token pod\u00eda ser utilizado para obtener acceso completo tanto a los proxies web como, lo que es m\u00e1s importante, a los servicios de “Acceso Privado” (Private Access) de Zscaler, que enrutan el tr\u00e1fico a los recursos corporativos internos.<\/p>\n

    En esencia, un atacante sin credenciales pod\u00eda hacerse pasar por cualquier usuario de la organizaci\u00f3n y acceder a la red interna. Zscaler respondi\u00f3 r\u00e1pidamente, aplicando un parche del lado del servidor una vez notificado.\u00a0 \u00a0<\/span><\/p>\n

    2.3. Check Point (Perimeter 81): Fuga de Credenciales y Violaci\u00f3n de la Confianza Multi-Inquilino<\/h3>\n

    La vulnerabilidad en el servicio Perimeter 81, adquirido por Check Point en 2023 , expuso una falla de seguridad fundamental relacionada con la gesti\u00f3n de secretos. Los investigadores de AmberWolf descubrieron credenciales SFTP codificadas de forma r\u00edgida (hard-coded) dentro del servicio.\u00a0 \u00a0<\/span><\/p>\n

    Estas credenciales est\u00e1ticas proporcionaban acceso no autorizado a un servidor SFTP que serv\u00eda como repositorio para los registros de los clientes de m\u00faltiples inquilinos.<\/p>\n

    La exposici\u00f3n de estos registros ya es una grave violaci\u00f3n de la privacidad y la confidencialidad. Sin embargo, el impacto se magnifica por el contenido de estos registros. Los investigadores encontraron que los archivos de registro conten\u00edan material de autenticaci\u00f3n sensible, espec\u00edficamente JSON Web Tokens (JWTs).\u00a0 \u00a0<\/span><\/p>\n

    Los JWTs son tokens de portador que, si se capturan, pueden ser reutilizados por un atacante para autenticarse en el servicio Perimeter 81 haci\u00e9ndose pasar por el usuario leg\u00edtimo al que pertenece el token.<\/p>\n

    Por lo tanto, esta vulnerabilidad no solo representaba una exposici\u00f3n masiva de datos de m\u00faltiples clientes, sino que tambi\u00e9n proporcionaba a un atacante el material necesario para llevar a cabo evasiones de autenticaci\u00f3n.<\/p>\n

    Este tipo de fuga de datos entre inquilinos es una de las violaciones m\u00e1s graves posibles en un entorno de servicios en la nube, ya que socava por completo el modelo de confianza y aislamiento en el que se basan los clientes.\u00a0 \u00a0<\/span><\/p>\n

    El an\u00e1lisis de estas vulnerabilidades revela un patr\u00f3n com\u00fan y preocupante. Aunque ZTNA se basa en el principio de “nunca confiar, siempre verificar” para las solicitudes de acceso de los usuarios, los proveedores parecen haber fallado en aplicar esta misma filosof\u00eda rigurosa a los componentes internos de sus propias plataformas.<\/p>\n

    La plataforma de Zscaler confiaba impl\u00edcitamente en la existencia de una firma SAML sin verificar su origen. El proceso de inscripci\u00f3n de Netskope confiaba impl\u00edcitamente en una clave est\u00e1tica como un autenticador v\u00e1lido.<\/p>\n

    La arquitectura de Check Point Perimeter 81 confiaba impl\u00edcitamente en credenciales codificadas de forma r\u00edgida.<\/p>\n

    Esta iron\u00eda expone un punto ciego cr\u00edtico: la seguridad de una arquitectura ZTNA depende no solo de c\u00f3mo verifica a los usuarios, sino tambi\u00e9n de c\u00f3mo se verifica a s\u00ed misma.<\/p>\n

    3: Deconstruyendo los Vectores de Ataque: Tecnolog\u00edas Subyacentes<\/h2>\n

    Para comprender plenamente la gravedad de las vulnerabilidades descubiertas, es esencial deconstruir las tecnolog\u00edas y los modelos de seguridad subyacentes que fueron explotados. Las fallas no ocurrieron en el vac\u00edo; se aprovecharon de debilidades en la implementaci\u00f3n de protocolos de autenticaci\u00f3n est\u00e1ndar de la industria y explotaron las diferencias arquitect\u00f3nicas entre los modelos de acceso heredados y los modernos.<\/p>\n

    3.1. SAML e IdP: El Eslab\u00f3n Roto en la Cadena de Autenticaci\u00f3n Federada<\/h3>\n

    El Security Assertion Markup Language (SAML) es un est\u00e1ndar abierto basado en XML que permite la autenticaci\u00f3n y autorizaci\u00f3n seguras entre diferentes dominios, siendo la base para muchas implementaciones de Inicio de Sesi\u00f3n \u00danico (SSO). El proceso de autenticaci\u00f3n SAML involucra a tres actores principales :\u00a0 \u00a0<\/span><\/p>\n

      \n
    1. El Principal (o Sujeto):<\/b> Generalmente, el usuario final que intenta acceder a un recurso.<\/li>\n
    2. El Proveedor de Identidad (IdP – Identity Provider):<\/b> El sistema que gestiona y autentica la identidad del usuario (por ejemplo, Okta, Azure AD, Google). Su funci\u00f3n es verificar que los usuarios son quienes dicen ser.\u00a0 \u00a0<\/span>\n
      \n
      <\/div>\n<\/div>\n<\/li>\n
    3. El Proveedor de Servicios (SP – Service Provider):<\/b> La aplicaci\u00f3n o servicio al que el usuario desea acceder (en este caso, la plataforma ZTNA de Zscaler).<\/li>\n<\/ol>\n

      El flujo de trabajo se basa en una relaci\u00f3n de confianza. Cuando un usuario intenta acceder al SP, este redirige al usuario al IdP para su autenticaci\u00f3n.<\/p>\n

      Una vez que el usuario se autentica con \u00e9xito en el IdP, el IdP genera un documento XML llamado aserci\u00f3n SAML<\/b>.<\/p>\n

      Esta aserci\u00f3n contiene informaci\u00f3n sobre el usuario (como su direcci\u00f3n de correo electr\u00f3nico y roles) y, lo m\u00e1s importante, est\u00e1\u00a0firmada digitalmente<\/b> con la clave privada del IdP.<\/span>\u00a0 \u00a0<\/span><\/p>\n

      El usuario es entonces redirigido de vuelta al SP, llevando consigo esta aserci\u00f3n firmada. La seguridad de todo el sistema depende de un paso cr\u00edtico: el SP debe validar la firma digital de la aserci\u00f3n utilizando la clave p\u00fablica del IdP, que ha sido preconfigurada en el SP durante el establecimiento de la confianza. Esta verificaci\u00f3n criptogr\u00e1fica garantiza dos cosas:\u00a0 \u00a0<\/span><\/p>\n