Proteger informes y recursos

Actualizado: 14 de abril de 2006

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, sólo 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 funciones que concedan acceso a un informe o recurso.

Acceso a informes y recursos basado en funciones

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

Es posible que en la mayoría de los casos se usen los permisos heredados de una carpeta primaria. Establezca la seguridad en un informe o recurso individual sólo si desea ocultar el informe o el recurso a los usuarios que no necesitan saber que existe, o para aumentar el nivel de acceso para 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 funciones para lograr sus 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 sólo necesitan ejecutarlo. Para adaptarse a todos estos usuarios, deberá crear tres asignaciones de funciones 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 sólo 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 sólo varias personas están autorizadas a tener acceso, el informe continúa estando disponible sólo para esos usuarios, incluso si lo mueve a una carpeta con una directiva de seguridad relativamente abierta.

Mitigar los 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, secuencias de comandos, 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 secuencias de comandos, éstas se ejecutarán cuando el usuario abra el documento en el servidor de informes. La posibilidad de ejecutar secuencias de comandos 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.

A la hora de 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 pueden enviarse al cliente secuencias de comandos posiblemente malintencionadas. El cliente ejecutará el código HTML en el nivel de confianza que se haya configurado en el explorador.

Para mitigar el riesgo de ejecutar secuencias de comandos malintencionadas, 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 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 secuencias de comandos y direcciones URL sospechosas.

Mitigar 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, utilice 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 sólo 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 el parámetro de informe está asociado a un parámetro de consulta y no se utiliza una lista de valores disponibles, un usuario del informe podría escribir sintaxis SQL en el cuadro de texto y exponer 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.

Si un parámetro de informe no está asociado a un parámetro de consulta y los valores de parámetro están incluidos en el informe, un usuario del informe podría escribir sintaxis de expresiones o una dirección URL en el valor de parámetro y representar el informe en Excel o HTML. Si, después, otro usuario ve el informe y hace clic en el contenido del parámetro representado, existe la posibilidad de que ejecute inconscientemente la secuencia de comandos o el vínculo malintencionados.

Para mitigar el riesgo de ejecutar secuencias de comandos malintencionadas por accidente, sólo deben abrirse informes representados que procedan de fuentes de confianza.

Para obtener más información acerca de los ataques por inyección de código SQL y cómo mitigarlos, vea Seguridad integrada y permisos elevados.

[!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.

Proteger 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 obtener más información, vea Especificar información de conexión y credenciales. También puede proteger una carpeta para que no resulte accesible a usuarios no autorizados. Para obtener más información, vea Proteger carpetas.

Vea también

Tareas

Cómo especificar credenciales almacenadas para un origen de datos (Management Studio)

Conceptos

Seguridad integrada y permisos elevados
Crear, modificar y eliminar asignaciones de funciones
Función Publicador
Asignaciones de funciones para el acceso al Generador de informes
Administrar permisos y seguridad para Reporting Services
Proteger elementos de orígenes de datos compartidos

Otros recursos

Trabajar con parámetros en Reporting Services

Ayuda e información

Obtener ayuda sobre SQL Server 2005

Historial de cambios