Procedimientos recomendados sobre seguridad para soluciones de Office (2003 System)
Actualización: noviembre 2007
Se aplica a |
---|
La información de este tema sólo se aplica a los proyectos y versiones especificados de Visual Studio Tools para Office de Microsoft Office. Tipo de proyecto
Versión de Microsoft Office
Para obtener más información, vea Características disponibles por aplicación y tipo de proyecto. |
Cuando planee la directiva de seguridad para las personalizaciones de nivel de documento y los complementos de nivel de aplicación, considere los aspectos siguientes.
Agregar condiciones a la directiva de seguridad
Microsoft .NET Framework proporciona dos maneras principales de implementar la directiva:
Generar un archivo de Windows Installer (.msi) mediante la herramienta Configuración de .NET Framework. Para obtener más información, vea Implementar la directiva de seguridad.
Modificar directamente la directiva creando secuencias de comandos para la herramienta de la directiva de seguridad de acceso a código (Caspol.exe). Para obtener más información, vea Configurar directivas de seguridad mediante la herramienta Directiva de seguridad de acceso a código (Caspol.exe).
Utilizando un archivo de Windows Installer, puede realizar una evaluación más predecible de la directiva porque todo el nivel de directiva (normalmente Empresa o Equipo) se copia en el equipo del usuario final; sin embargo, esto puede crear conflictos si los distintos grupos de una compañía desean publicar la directiva independientemente de los demás o si los individuos necesitan realizar cambios en sus directivas.
Utilizar Caspol.exe para modificar la directiva permite a distintas personas actualizar la directiva independientemente, pero no se puede garantizar que cualquier cambio concreto de la directiva vaya a tener el efecto deseado debido a las interacciones desconocidas entre los diferentes grupos de código. Por ejemplo, si un departamento implementa un cambio de directiva que concede plena confianza a un sitio de intranet determinado, ese departamento espera que todo el código procedente de ese sitio es de confianza. Pero si otro departamento implementa una directiva con un atributo Exclusive que deniega el acceso a ese sitio, no se ejecutará ningún código. Para obtener más información sobre el atributo Exclusive, vea Administración con atributos de grupo de código y Cómo: Hacer que un grupo de código sea exclusivo o de nivel final.
Los administradores deben equilibrar la previsibilidad de los archivos de Windows Installer con la flexibilidad de Caspol.exe para decidir cómo actualizar la directiva.
Hay que tener en cuenta que, aunque también es posible escribir código administrado para manipular directamente la directiva a través de las API de Microsoft .NET Framework, es complicado crear la directiva correctamente de esta manera, por lo que no se recomienda esta práctica.
Comprobar la directiva actual
Si no se ejecuta un ensamblado, puede investigar la posible causa revisando los permisos asignados a ese ensamblado. Microsoft .NET Framework proporciona dos maneras de comprobar la directiva actual para un ensamblado:
Con el Asistente Evaluar un ensamblado que se incluye en la herramienta de configuración Microsoft .NET Framework 2.0. Para obtener información sobre cómo tener acceso a este asistente, vea Cómo: Realizar tareas comunes de directivas de seguridad mediante la herramienta Configuración de .NET Framework (Mscorcfg.msc).
Ejecutando los siguientes comandos en Caspol.exe:
caspol -all -lg caspol -rsg path_to_assembly
Para obtener más información sobre los comandos de Caspol.exe, vea Herramienta de la directiva de seguridad de acceso a código (Caspol.exe).
Estas herramientas muestran la directiva de seguridad aplicada al ensamblado y cómo la evidencia del ensamblado se asigna a esas reglas en Common Language Runtime (CLR). Esto indica si la directiva se ha configurado correctamente y si el ensamblado coincide con los grupos de código correctos. Los problemas principales que se han detectado con esta técnica incluyen los siguientes:
Se agregó una regla de red (por ejemplo, asignar plena confianza a http://servidor/) a la zona MiPC cuando debería estar en IntranetLocal, o se agregó a IntranetLocal cuando debería estar en SitiosDeConfianza.
Hay un error en el nombre de archivo o la dirección URL.
A la ruta de acceso del directorio le falta el asterisco (*), que indica que todos los archivos y subcarpetas situados bajo esa carpeta deben incluirse en la directiva.
Para obtener más información, vea Resolver cuestiones de directivas de seguridad mediante Caspol.exe.
Establecer la directiva predeterminada para la empresa
Visual Studio permite a las empresas definir su propia directiva predeterminada. Normalmente, cuando realiza un restablecimiento en la directiva de seguridad, la directiva toma los valores predeterminados que están presentes cuando se instala Framework. Usando la directiva predeterminada específica de la empresa, una operación de restablecer restaura la directiva básica tal y como está definida por esa empresa concreta. Por ejemplo, la empresa podría agregar un editor de confianza al nivel Empresa y bloquea todo el código procedente de la zona Internet.
Para obtener más información sobre cómo volver a la directiva predeterminada, vea Cómo: Restablecer los valores predeterminados de directivas de seguridad mediante Caspol.exe y Herramienta Configuración de .NET Framework (Mscorcfg.msc). Para obtener más información sobre la directiva de seguridad predeterminada, vea Directiva de seguridad predeterminada.
Recomendaciones generales
Tenga en cuenta las instrucciones siguientes al decidir la directiva para sus soluciones de Office:
Utilice siempre grupos de código con nombre en lugar de confiar en sus números (por ejemplo, utilice Zona_MiPC en lugar de 1.1). Aunque los usuarios pueden cambiar el nombre de un grupo (por ejemplo, cambiando el nombre de Internet a MiPC), es menos probable que cambiar los números.
Sea lo más restrictivo posible sobre el código al que se aplicará una regla. Nunca agregue reglas al grupo All_Code del nivel Equipo; agréguelos siempre a una Zona u otro subgrupo de Zonas. Es mejor no tener reglas para el código que no se espera.
Aplique primero las reglas más ampliamente aplicables, por ejemplo, empiece por zona, a continuación sitio y luego editor; en lugar de editor, luego sitio y después zona. De ese modo, las reglas de una determinada zona se pueden aplicar a un código específico y no se aplicarán a todo el código desde el editor hasta que se haya comprobado si las restricciones son necesarias.
Si deja de existir un grupo primario, por ejemplo el grupo LocalIntranet_Zone, debe volver a crearlo. Tenga en cuenta que debe hacerlo con el conjunto de permisos Nada. El conjunto de permisos Nada impide que se apliquen los permisos predeterminados que el administrador ha desactivado eliminando el grupo de código. Por ejemplo, si el administrador elimina LocalIntranet_Zone, todo el código de la intranet local deja de ejecutarse. Cuando vuelva a crear el grupo de código y utilice el conjunto de permisos Nada, no se agrega ningún permiso que no estuviera antes.
Desactive las advertencias de cambio de directiva en los archivos de procesamiento por lotes y recuerde volver a activarlos después si estaban activadas originalmente. De ese modo, los archivos de proceso por lotes no se detendrán a esperar los datos proporcionados por el usuario. Esta configuración afecta a todos los usuarios, no sólo al usuario actual. Para obtener más información, vea Cómo: Suprimir advertencias de cambio de directiva mediante Caspol.exe.
Al utilizar Caspol.exe, especifique explícitamente el nivel de directiva que modificar (Empresa, Equipo o Usuario); no se base en el valor predeterminado. Podría darse el caso de que los valores predeterminados no fuesen correctos para la directiva que se está modificando. Para obtener más información, vea Niveles de la directiva de seguridad.
No utilice los atributos Exclusive ni Level-Final a menos que sea absolutamente necesario, porque pueden provocar un comportamiento inesperado si se agrega un nuevo grupo de código. Para obtener más información, vea Atributos de grupo de código.
Vea también
Conceptos
Requisitos de seguridad para ejecutar las soluciones de Office (2003 System)
Consideraciones de seguridad específicas para soluciones de Office