MetaDefender ICAP 5.13.0: Gestiona más tráfico sin ampliar la infraestructura

La seguridad de los archivos en el perímetro de la red solo funciona si es capaz de seguir el ritmo. Cuando una pasarela web segura inspecciona todos los archivos que pasan por ella (ya sea a través de descargas, cargas o contenido web), la capa de seguridad debe seguir siendo transparente: invisible para los usuarios, estable bajo carga y no debe ser motivo de ninguna irregularidad en una auditoría de cumplimiento.

Se trata de realidades operativas que resultan cada vez más difíciles de gestionar a medida que aumenta el tráfico, se endurecen las políticas de acceso y se amplía el alcance de las auditorías. MetaDefender ICAP Server .13.0 aborda directamente tres de ellas.

Una de las cosas que suele abrumar a los equipos cuando implementan ICAP es que un solo usuario que navega por Internet a través de una pasarela segura puede generar decenas, o incluso cientos, de ICAP en rápida sucesión. Cada imagen, script, documento y descarga supone una solicitud de inspección de archivos independiente que llega al servidor de forma simultánea.

Con un tráfico moderado, la mayoría de las implementaciones gestionan esto sin problemas. A medida que aumenta la concurrencia, el cuello de botella suele encontrarse en las operaciones relacionadas: el almacenamiento de los resultados en la base de datos, el vaciado de los registros y la gestión del estado de los subprocesos.

Cuando hay una gran concurrencia, el procesamiento de las solicitudes y el registro de los resultados en el mismo canal se convierten en el cuello de botella, lo que limita el rendimiento precisamente cuando la demanda es mayor.

MetaDefender ICAP Server .13.0 separa esas operaciones. Ahora, los subprocesos de análisis transfieren las operaciones de escritura en la base de datos y la generación de registros a procesos en segundo plano específicos en cuanto finaliza un análisis, para luego pasar inmediatamente a la siguiente solicitud. El resultado es que el rendimiento de la inspección se adapta mejor al tráfico, sin necesidad de añadir hardware ni ampliar el tamaño de los grupos de subprocesos.

Especialmente relevante para: equipos que gestionan pasarelas web seguras, en las que una sola sesión de usuario puede generar decenas de solicitudes simultáneas de análisis de archivos. Cuanto mayor sea el tráfico, mayor será la importancia de este cambio.

El cierre de sesión único SAML es uno de los aspectos que con mayor frecuencia se descuidan en las implementaciones de SSO. Por lo general, los equipos dedican recursos a configurar la autenticación, incluyendo el establecimiento de confianza, la validación de aserciones y la creación de sesiones. En cambio, el proceso de cierre de sesión suele recibir menos atención, y un cierre de sesión parcial puede parecer que funciona correctamente a simple vista.

Es importante comprender esta laguna: cuando un usuario cierra sesión en una aplicación que solo borra su sesión local, la sesión del IdP permanece activa. Esa sesión puede reutilizarse de forma silenciosa. Un usuario que vuelva a la página de inicio de sesión puede volver a autenticarse automáticamente, sin tener que volver a introducir sus credenciales y sin necesidad de autenticación multifactorial (MFA). En entornos con estaciones de trabajo compartidas o cuentas con privilegios elevados, se trata de una vía de acceso que persiste más allá de lo previsto.

MetaDefender ICAP Server .13.0 incorpora compatibilidad total con el cierre de sesión único (SLO) de SAML. Al cerrar la sesión, MetaDefender ICAP Server una solicitud de cierre de sesión directamente al proveedor de identidad, finaliza la sesión en el origen y exige una nueva autenticación antes de restablecer el acceso. El comportamiento de redireccionamiento tras el cierre de sesión también es configurable.

Para los equipos sujetos a auditorías de control de acceso o a políticas de «confianza cero», esto hace que la finalización de la sesión se ajuste a lo que exige una implementación completa de SAML.