Protección de informes y recursos

  • Artículo

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, es probable que quiera usar los permisos heredados de una carpeta primaria. Establecer la seguridad en informes y recursos individuales solo debe ser necesario en un par de escenarios. Estos escenarios son los siguientes:

  • Si quiere ocultar el informe o recurso de los usuarios que no necesitan saber que existe
  • Para aumentar el nivel de acceso de un informe o elemento.

Estos objetivos no se excluyen mutuamente. Puede restringir el acceso a un informe a un conjunto más reducido de usuarios y proporcionar a todos o a parte de ellos privilegios adicionales para administrar el informe.

Es posible que necesite 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 varias personas están autorizadas a acceder, el informe continúa disponible solamente para esos usuarios. Este resultado puede ocurrir 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 publicado

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 script, el script se ejecuta cuando el usuario abre 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 los informes y recursos que se procesan como HTML, es importante recordar que los informes se procesan con plena confianza y que se pueden enviar al cliente scripts posiblemente malintencionados. En función de la configuración del explorador, el cliente ejecuta el código HTML en el nivel de confianza que se haya 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. Como existe la posibilidad de que se publique contenido malintencionado, debe limitar los usuarios que pueden publicar contenido a 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 script

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. Debe tener en cuenta el siguiente escenario que es un ataque potencial de inyección de script de representación 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. Ese vínculo especifica el valor del parámetro con el formato javascript:<malicious script here> y envía ese vínculo a otra persona en un ataque por señuelo.

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 selecciona el vínculo en el informe publicado o exportado, podrían ejecutarse scripts malintencionados.

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 los datos con los hipervínculos no crean vínculos de los que se pueda sacar provecho negativo. Por ejemplo, no base un hipervínculo en una expresión que concatene los 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 los 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, use una lista de valores disponibles (también conocida como lista de valores válidos) y asegúrese de que los usuarios que ejecuten el informe solamente dispongan de los permisos necesarios para ver los datos del mismo. Cuando se define un parámetro de tipo String, el usuario ve un cuadro de texto que admite cualquier valor. Una lista de valores disponibles limita los valores que se pueden especificar. Si asocia el parámetro de informe a un parámetro de consulta y no utiliza una lista de valores disponibles, un usuario del informe puede escribir sintaxis SQL en el cuadro de texto. Esta acción podría abrir el informe y el servidor a un ataque por inyección de código SQL. Si el usuario tiene permisos suficientes para ejecutar la nueva instrucción SQL, podría provocar resultados no deseados en el servidor.

Es posible que un parámetro de informe no esté asociado a un parámetro de consulta y los valores de parámetro se incluyan en el informe. En ese caso, 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 después otro usuario ve el informe y selecciona el contenido del parámetro representado, el usuario podría ejecutar accidentalmente el script o el vínculo malintencionados.

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

Nota

En versiones anteriores de la documentación, se incluía un ejemplo de cómo crear una consulta dinámica como una expresión. Este tipo de consulta genera vulnerabilidad a los ataques por inyección de código SQL y, por lo tanto, no se recomienda.

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 más información, vea Protección de carpetas.

Contenido relacionado

Creación y administración de asignaciones de roles
Concesión de permisos en un servidor de informes en modo nativo
Protección de elementos de orígenes de datos compartidos
Almacenamiento de credenciales en un origen de datos de Reporting Services