Protección ampliada para la autenticación con Reporting Services

La protección ampliada es un conjunto de mejoras de las versiones recientes del sistema operativo Microsoft Windows. La protección ampliada mejora cómo protegen las aplicaciones las credenciales y la autenticación. La propia característica no proporciona directamente protección contra ataques específicos como el reenvío de credenciales, sino que proporciona una infraestructura para aplicaciones, como Reporting Services, con el fin de aplicar la protección ampliada para la autenticación.

Las principales mejoras de autenticación que forman parte de la protección extendida son la vinculación de servicio y la vinculación de canal. La vinculación de canal utiliza un token de vinculación de canal (CBT) para verificar que el canal establecido entre dos puntos finales no se vio comprometido. El enlace de servicio usa nombres principales de servicio (SPN) para validar el destino previsto de los tokens de autenticación. Para obtener información general sobre la protección ampliada, vea Autenticación de Windows integrada con protección ampliada.

SQL Server Reporting Services (SSRS) admite y aplica la protección ampliada que se ha habilitado en el sistema operativo y se ha configurado en Reporting Services. De forma predeterminada, Reporting Services acepta solicitudes que especifican la autenticación Negotiate o NTLM y, por tanto, puede beneficiarse de la compatibilidad con la protección ampliada del sistema operativo y de las características de protección ampliada de Reporting Services.

Habilitación del cifrado con protección ampliada

Se aplica a: SQL Server

Para mejorar la seguridad al usar autenticación de Windows, establezca Protección ampliada en Obligatorio y Forzar cifrado en Sí en Administrador de configuración de SQL Server.

Estas opciones proporcionan la configuración más segura para SQL Server.

Actualice las cadenas de conexión para dar cabida a estos cambios.

Para obtener más información, consulte:

• Conexión al motor de base de datos con protección ampliada
• Configuración del Motor de base de datos de SQL Server para cifrar conexiones
• TDS 8.0
• Conexión a SQL Server mediante cifrado strict

Información general sobre la protección ampliada de Reporting Services

SSRS admite y aplica la protección ampliada que se ha habilitado en el sistema operativo. Si el sistema operativo no admite la protección ampliada o si no se ha habilitado la característica en él, se producirá un error de autenticación de la característica de protección ampliada de Reporting Services. La protección ampliada de Reporting Services también requiere un certificado TLS/SSL. Para más información, vea Configuración de conexiones TLS en un servidor de informes en modo nativo

Los problemas comunes debidos a cambios en la configuración de la protección ampliada o a una configuración incorrecta no se manifiestan mediante mensajes de error o cuadros de diálogo evidentes. Los problemas relacionados con la configuración y la compatibilidad de la protección ampliada dan como resultado errores de autenticación y errores en los registros de seguimiento de Reporting Services.

Actualizar

• La actualización de un servidor de Reporting Services a SQL Server 2016 agrega opciones de configuración con valores predeterminados al archivo rsreportserver.config. Si la configuración ya se ha realizado, la instalación de SQL Server 2016 la conservará en el archivo rsreportserver.config.

• Cuando se agregan parámetros de configuración al archivo de configuración rsreportserver.config, el comportamiento predeterminado es desactivar la característica de protección ampliada de Reporting Services y el usuario debe habilitarla de la forma descrita en este artículo. Para obtener más información, vea la sección de configuración de este artículo.

• El valor predeterminado del parámetro RSWindowsExtendedProtectionLevel es Off.

• El valor predeterminado del parámetro RSWindowsExtendedProtectionScenario es Proxy.

• El Asesor de actualizaciones no comprueba si el sistema operativo o la instalación actual de Reporting Services tienen habilitada la compatibilidad con la protección ampliada.

Lo que no cubre la protección ampliada de Reporting Services

La característica de protección ampliada de Reporting Services no es compatible con las siguientes áreas y escenarios de características:

• Los autores de las extensiones de seguridad personalizadas de Reporting Services deben agregar soporte para la protección ampliada a su extensión de seguridad personalizada.

• Los componentes de terceros agregados o usados en la instalación de Reporting Services se deben actualizar por dichos proveedores para que admitan la protección ampliada. Para obtener más información, póngase en contacto con el otro proveedor.

Escenarios y recomendaciones para la implementación

En los siguientes escenarios se ilustran las distintas implementaciones y topologías, así como la configuración recomendada para protegerlas con la protección ampliada de Reporting Services.

Directo

Este escenario describe la conexión directa con un servidor de informes, por ejemplo, el entorno de una intranet.

Escenario	Diagrama del escenario	Cómo proteger
Comunicación de TLS directa. El servidor de informes exige la vinculación de canal entre el cliente y el servidor de informes.	1) Aplicación cliente 2) Servidor de informes	Establezca RSWindowsExtendedProtectionLevel en Allow o Require. Establece RSWindowsExtendedProtectionScenario en Direct. -Service Binding no es necesario porque se utiliza el canal TLS para Channel Binding.
Comunicación HTTP directa. El servidor de informes impone la vinculación del servicio entre el cliente y el servidor de informes.	1) Aplicación cliente 2) Servidor de informes	Establezca RSWindowsExtendedProtectionLevel en Allow o Require. Establece RSWindowsExtendedProtectionScenario en Any. -No existe ningún canal TLS; por tanto, no es posible aplicar la vinculación de canal de forma obligatoria. -El enlace de servicio se puede validar. Sin embargo, no es una defensa completa sin el enlace de canal y el enlace de servicio por sí mismo solo protegerá contra amenazas básicas.

Equilibrio de carga del proxy y de la red

Las aplicaciones cliente se conectan a un dispositivo o software que realiza TLS y pasa por las credenciales al servidor para la autenticación, por ejemplo, una extranet, Internet o una intranet segura. El cliente se conecta a un proxy o todos los clientes usan un proxy.

Ocurre lo mismo cuando usa un dispositivo de equilibrio de carga de red (NLB).

Escenario	Diagrama del escenario	Cómo proteger
Comunicación HTTP. El servidor de informes impone la vinculación de servicio entre el cliente y el servidor de informes.	1) Aplicación cliente 2) Servidor de informes 3) Proxy	Establezca RSWindowsExtendedProtectionLevel en Allow o Require. Establece RSWindowsExtendedProtectionScenario en Any. -No hay ningún canal TLS, por lo tanto no es posible exigir la vinculación de canal. -El servidor de informes se debe configurar para saber el nombre del servidor proxy con el fin de asegurarse de que se aplica el enlace de servicio correctamente.
Comunicación HTTP. El servidor de informes aplica el enlace de canal proxy del cliente y el enlace de servicio del cliente al servidor de informes.	1) Aplicación cliente 2) Servidor de informes 3) Proxy	Establecer RSWindowsExtendedProtectionLevel a Allow o Require. Establece RSWindowsExtendedProtectionScenario en Proxy. -Está disponible un canal TLS con el proxy; por lo tanto, se puede aplicar la vinculación de canal con el proxy. -También se puede aplicar la vinculación de servicio. -El nombre del proxy debe ser conocido por el servidor de informes, y el administrador del servidor de informes debe crear una reserva de URL para este, con un encabezado de host, o configurar el nombre del proxy en la entrada del Registro de Windows BackConnectionHostNames.
Comunicación HTTPS indirecta con un proxy seguro. El servidor de informes exige la vinculación de canal del proxy y la vinculación de servicio entre el cliente y el servidor de informes.	1) Aplicación cliente 2) Servidor de informes 3) Proxy	Establecer RSWindowsExtendedProtectionLevel a Allow o Require. Establece RSWindowsExtendedProtectionScenario en Proxy. - El canal TLS con el proxy está disponible; por lo tanto, se puede aplicar la vinculación de canal con el proxy. -También se puede aplicar el enlace de servicio. -El nombre del proxy debe ser conocido por el servidor de informes y el administrador del servidor de informes debería crear una reserva de URL para él con un encabezado de host, o bien configurar el nombre del proxy en la entrada del Registro de Windows BackConnectionHostNames.

Puerta de enlace

En este escenario se describen las aplicaciones cliente que se conectan a un dispositivo o software que realiza TLS y autentica al usuario. Después, el dispositivo o software suplanta el contexto del usuario o un contexto de usuario distinto antes de efectuar una solicitud al servidor de informes.

Escenario	Diagrama del escenario	Cómo proteger
Comunicación HTTP indirecta. La puerta de enlace exige la vinculación del canal entre el cliente y la puerta de enlace. Hay una vinculación del servicio de puerta de enlace con el servidor de informes.	1) Aplicación cliente 2) Servidor de informes 3) Dispositivo de puerta de enlace	Establezca RSWindowsExtendedProtectionLevel en Allow o Require. Establece RSWindowsExtendedProtectionScenario en Any. -El enlace de canal desde el cliente al servidor de informes no es posible, ya que la puerta de enlace realiza una suplantación de contexto y, por ello, crea un nuevo token NTLM. -No hay ninguna conexión TLS desde el Gateway hasta el servidor de informes; por tanto, no se puede aplicar la vinculación de canal. -Se puede exigir la vinculación de servicios. -Su administrador debe configurar el dispositivo Gateway para exigir la vinculación de canal.
Comunicación HTTPS indirecta con una puerta de enlace segura. La puerta de enlace exige la vinculación de canal entre el cliente y la puerta de enlace, y el servidor de informes exige la vinculación de canal entre la puerta de enlace y el servidor de informes.	1) Aplicación cliente 2) Servidor de informes 3) Dispositivo de puerta de enlace	Establezca RSWindowsExtendedProtectionLevel en Allow o Require. Establece RSWindowsExtendedProtectionScenario en Direct. -El enlace de canal desde el cliente al servidor de informes no es posible ya que la puerta de enlace suplanta un contexto y, por tanto, crea un nuevo token NTLM. -TLS desde la puerta de enlace hasta el servidor de informes significa que se puede aplicar la vinculación de canal. -No se requiere la vinculación de servicio. -Su administrador debe configurar el dispositivo Gateway para exigir la vinculación de canal.

Combinación

En este escenario se describen los entornos de Extranet o Internet en los que el cliente conecta un proxy en combinación con un entorno de intranet donde un cliente se conecta al servidor de informes.

Escenario	Diagrama del escenario	Cómo proteger
Acceso indirecto y directo desde el cliente al servicio del servidor de informes sin TLS en las conexiones del cliente al proxy ni en las conexiones del cliente al servidor de informes.	1) Aplicación cliente 2) Servidor de informes 3) Proxy 4) Aplicación cliente	Establezca RSWindowsExtendedProtectionLevel en Allow o Require. Establece RSWindowsExtendedProtectionScenario en Any. -Se puede aplicar el enlace de servicio desde el cliente al servidor de informes. -El nombre del proxy debe ser conocido por el servidor de informes y el administrador del servidor de informes debería crear una reserva de URL para él con un encabezado de host, o bien configurar el nombre del proxy en la entrada del Registro de Windows BackConnectionHostNames.
Acceso indirecto y directo desde el cliente al servidor de informes donde el cliente establece una conexión TLS al proxy o al servidor de informes.	1) Aplicación cliente 2) Servidor de informes 3) Proxy 4) Aplicación cliente	Establezca RSWindowsExtendedProtectionLevel en Allow o Require. Establece RSWindowsExtendedProtectionScenario en Proxy. -Se puede usar la vinculación de canal -El servidor de informes debe saber el nombre del proxy y el administrador del servidor de informes debe crear una reserva de direcciones URL para el proxy, con un encabezado de host o configurar el nombre de proxy en la entrada del Registro de Windows BackConnectionHostNames.

Configurar la protección ampliada de Reporting Services

El archivo rsreportserver.config contiene los valores de configuración que controlan el comportamiento de la protección ampliada de Reporting Services.

Para más información sobre el uso y la edición del archivo rsreportserver.config, vea El archivo de configuración RSReportServer.config. La configuración de la protección ampliada también se puede cambiar e inspeccionar mediante las API WMI. Para más información, vea Método SetExtendedProtectionSettings (WMI MSReportServer_ConfigurationSetting).

Cuando se produce un error de autenticación de la configuración, se deshabilitan los tipos de autenticación RSWindowsNTLM, RSWindowsKerberos y RSWindowsNegotiate en el servidor de informes.

Configuración de la protección ampliada de los servicios de informes

La tabla siguiente proporciona información sobre los valores de configuración que aparecen en rsreportserver.config para la protección ampliada.

Entradas del ejemplo en el archivo de configuración rsreportserver.config :

<Authentication>  
         <RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel>  
         <RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionLevel>  
</Authentication>  

Vinculación de servicio y SPN incluidos

El enlace de servicio usa nombres principales de servicio (SPN) para validar el destino previsto de los tokens de autenticación. Reporting Services usa la información de reserva de dirección URL para compilar una lista de los SPN que se consideran válidos. La información de reserva de direcciones URL para validar tanto las reservas de SPN como las de URL permite a los administradores del sistema gestionar ambas desde una única ubicación.

La lista de SPN válidos se actualiza cuando se produce una de las siguientes acciones:

• Se inicia el servidor de informes.
• Se cambian las opciones de configuración para la protección ampliada.
• El dominio de aplicación se recicla.

La lista válida de los SPN es específica de cada aplicación. Por ejemplo, el Administrador de informes y el servidor de informes tendrán cada uno una lista distinta de los SPN válidos calculados.

La lista de los SPN válidos calculados para una aplicación la determinan los siguientes factores:

• Cada reserva de URL.

• Cada SPN recuperado del controlador de dominio para la cuenta de servicio correspondiente a Reporting Services.

• Si una reserva de URL incluye caracteres comodín ('*' o '+'), Report Server agrega cada entrada de la colección de hosts.

Orígenes de la colección de hosts.

La siguiente tabla enumera las posibles fuentes de la colección Hosts.

Para más información, consulte Registrar un nombre de entidad de seguridad de servicio (SPN) para un servidor de informes y Acerca de las reservas y del registro de URL (Administrador de configuración del servidor de informes).

Contenido relacionado

• Conectar al motor de base de datos con protección ampliada
• Introducción a la protección ampliada para la autenticación
• Autenticación de Windows integrada con protección ampliada
• Seguridad de Microsoft Advisory: Protección ampliada para la autenticación
• Registro de seguimiento del servicio del servidor de informes
• Archivo de configuración RSReportServer.config
• Método SetExtendedProtectionSettings (WMI MSReportServer_ConfigurationSetting)
• Puede plantear sus dudas en el foro de Reporting Services.