Protección de informes y recursos

Puede establecer la seguridad para informes y recursos individuales a fin de controlar el grado de acceso de los usuarios a estos elementos. De manera predeterminada, solo los usuarios que pertenezcan al grupo integrado Administradores pueden ejecutar informes, ver recursos, modificar propiedades y eliminar elementos. Para los demás usuarios se deben crear asignaciones de roles que concedan acceso a un informe o recurso.

Acceso basado en roles a informes y recursos

Para concecer acceso a informes y recursos, puede permitir que los usuarios hereden las asignaciones de roles existentes en una carpeta primaria o crear una nueva asignación de rol en el propio elemento.

En la mayoría de los casos, probablemente querrá usar los permisos que se heredan de una carpeta primaria. Establecer la seguridad en informes y recursos individuales solo debe ser necesario si desea ocultar el informe o recurso de los usuarios que no necesitan saber que existe el informe o recurso, o para aumentar el nivel de acceso de un informe o elemento. Estos objetivos no son mutuamente excluyentes. Puede restringir el acceso a un informe a un conjunto más pequeño de usuarios y proporcionar a todos o algunos de ellos privilegios adicionales para administrar el informe.

Es posible que tenga que crear varias asignaciones de roles para lograr los objetivos. Por ejemplo, supongamos que tiene un informe que desea poner a disposición de los usuarios Ana y Pablo, y del grupo Directores de recursos humanos. Ana y Pablo deben ser capaces de administrar el informe, pero los miembros de Directores de recursos humanos solo necesitan ejecutarlo. Para adaptarse a todos estos usuarios, deberá crear tres asignaciones de roles diferentes: una para convertir a Ana en administradora de contenido del informe, otra para convertir a Pablo en administrador de contenido del informe y una última para permitir tareas de solo vista al grupo Directores de recursos humanos.

Una vez que haya establecido la seguridad para un informe o recurso, esta configuración permanecerá con el elemento incluso si lo mueve a otra ubicación. Por ejemplo, si mueve un informe al que solo unas pocas personas tienen autorización para acceder, el informe sigue estando disponible solo para esos usuarios, incluso si lo mueve a una carpeta que tiene una directiva de seguridad relativamente abierta.

Mitigación de ataques por inyección de CÓDIGO HTML en un informe o documento publicados

En Reporting Services, los informes y recursos se procesan con la identidad de seguridad del usuario que ejecuta el informe. Si el informe contiene expresiones, script, elementos de informe personalizados o ensamblados personalizados, el código se ejecuta con las credenciales del usuario. Si un recurso es un documento HTML que contiene un script, el script se ejecutará cuando el usuario abra el documento en el servidor de informes. La posibilidad de ejecutar script o código en un informe es una característica relevante, pero conlleva ciertos riesgos. Si el código es malintencionado, el servidor de informes y el usuario que ejecuta el informe son vulnerables a los ataques.

Al conceder acceso a informes y a recursos que se procesan como HTML, es importante recordar que los informes se procesan en plena confianza y que podría enviarse un script potencialmente malintencionado al cliente. En función de la configuración del explorador, el cliente ejecutará el CÓDIGO HTML en el nivel de confianza especificado en el explorador.

Para mitigar el riesgo de ejecutar script malintencionado, tome las siguientes precauciones:

• Sea selectivo a la hora de decidir quién puede publicar contenido en un servidor de informes. Dado que existe la posibilidad de publicar contenido malintencionado, debe limitar los usuarios que pueden publicar contenido en un pequeño número de usuarios de confianza.

• Todos los publicadores deben evitar publicar informes y recursos que procedan de fuentes desconocidas o que no sean de confianza. Si es necesario, abra el archivo en un editor de texto y compruebe si hay script y direcciones URL sospechosos.

Parámetros de informe e inyección de scripts

Los parámetros de informe proporcionan la flexibilidad para todo el diseño y ejecución del informe. Sin embargo, esta misma flexibilidad puede, en algunos casos, ser usada para atraer ataques por señuelo. Para reducir el riesgo de ejecución accidental de scripts malintencionados, abra los informes representados exclusivamente desde orígenes de confianza. Se recomienda tener en cuenta el siguiente escenario que es un posible ataque de inyección de scripts de representador HTML:

1. Un informe contiene un cuadro de texto con la acción de hipervínculo establecida en el valor de un parámetro que podría contener texto malintencionado.

2. El informe se publica en un servidor de informes o se hace disponible de cualquier otra forma de manera que el valor del parámetro del informe se puede controlar desde la URL de una página web.

3. Un atacante crea un vínculo a la página web o al servidor de informes que especifica el valor del parámetro con el formato "javascript:<script malintencionado aquí>" y envía ese vínculo a otra persona en un ataque de engaño.

Mitigación de ataques por inyección de scripts en un hipervínculo de un informe o documento publicados

Los informes pueden contener hipervínculos incrustados en el valor de la propiedad Action en un elemento de informe o parte de un elemento de informe. Los hipervínculos se pueden enlazar a datos que se recuperan de un origen de datos externo cuando se procesa el informe. Si un usuario malintencionado modifica los datos subyacentes, el hipervínculo podría hacer peligroso el scripting. Si un usuario hace clic en el vínculo del informe publicado o exportado, se podría ejecutar un script malintencionado.

Para mitigar el riesgo de incluir vínculos en un informe que inadvertidamente ejecuten script malintencionado, enlace solo hipervínculos a datos de fuentes de confianza. Compruebe que los datos de los resultados de la consulta y las expresiones que enlazan datos a hipervínculos no crean vínculos que se pueden aprovechar. Por ejemplo, no base un hipervínculo en una expresión que concatene datos de varios campos de conjunto de datos. Si es necesario, vaya al informe y use "Ver origen" para comprobar scripts sospechosos y URLS.

Mitigación de ataques por inyección de código SQL en un informe con parámetros

En cualquier informe que incluya un parámetro de tipo String, asegúrese de usar una lista de valores disponibles (también conocida como lista de valores válidos) y asegúrese de que cualquier usuario que ejecute el informe tenga solo los permisos necesarios para ver los datos del informe. Cuando se define un parámetro de tipo String, se presenta al usuario un cuadro de texto que puede tomar cualquier valor. Una lista de valores disponibles limita los valores que se pueden especificar. Si el parámetro de informe está asociado a un parámetro de consulta y no usa una lista de valores disponibles, es posible que un usuario de informe escriba la sintaxis SQL en el cuadro de texto, lo que podría abrir el informe y el servidor en un ataque por inyección de CÓDIGO SQL. Si el usuario tiene permisos suficientes para ejecutar la nueva instrucción SQL, puede generar resultados no deseados en el servidor.

Si un parámetro de informe no está asociado a un parámetro de consulta y los valores de parámetro se incluyen en el informe, es posible que un usuario del informe escriba la sintaxis de expresión o una dirección URL en el valor del parámetro y represente el informe en Excel o HTML. Si otro usuario ve el informe y hace clic en el contenido del parámetro representado, el usuario puede ejecutar accidentalmente el script o vínculo malintencionado.

Para reducir el riesgo de ejecución accidental de scripts malintencionados, abra los informes representados exclusivamente desde orígenes de confianza.

Protección de informes confidenciales

Los informes que contienen información confidencial deberían protegerse en el nivel de acceso a datos requiriendo que los usuarios proporcionen credenciales para tener acceso a datos confidenciales. Para más información, consulte Especificar información de credenciales y conexión para los orígenes de datos de informes. También puede proteger una carpeta para que no resulte accesible a usuarios no autorizados. Para obtener más información, vea Proteger carpetas.

Véase también

(asignar-y-gestionar-roles.md)
Configurar el acceso al Generador de informes
Concesión de permisos en un servidor de informes en modo nativo
Proteger elementos de origen de datos compartidos
Almacenamiento de las credenciales en un origen de datos de Reporting Services