Requisitos de seguridad para ejecutar las soluciones de Office (2003 System)

Actualización: noviembre 2007

Las personalizaciones de nivel de documento y los complementos de nivel de aplicación incorporan las características de seguridad disponibles en .NET Framework. De este modo, la solución puede aprovechar un intervalo de pruebas en el que basar las decisiones relacionadas con la confianza.

Para implementar y ejecutar una solución de Microsoft Office, debe otorgar plena confianza a los ensamblados en la directiva de seguridad de cada usuario final. En el caso de las personalizaciones, si el documento está en una ubicación de red en vez de encontrarse en el equipo del usuario, también debe conceder plena confianza al documento. Para obtener información sobre el establecimiento de la directiva de seguridad en los equipos de los usuarios finales, vea Implementar la directiva de seguridad.

Las soluciones de Microsoft Office agregan una restricción de seguridad personalizada que implica la no aceptación de la prueba basada en zonas o en todo el código; esto significa que las aplicaciones de Microsoft Office no ejecutarán ningún ensamblado que esté en el equipo local, la red o Internet hasta que se conceda permiso (confianza) al ensamblado en la directiva de seguridad.

Microsoft Office Outlook incluye un guardián del modelo de objetos que ayuda a evitar que el código en el que no se confía tenga acceso al modelo de objetos de Outlook. El guardián del modelo de objetos también puede hacer que Outlook muestre advertencias al usuario final cuando se ejecuta el código. Para obtener información sobre cómo evitar estas advertencias, vea Consideraciones de seguridad específicas para soluciones de Office.

Niveles de confianza

Los niveles de confianza de seguridad de .NET Framework son estos tres:

• Plena confianza. Este nivel concede al código permiso para realizar cualquier acción que pueda realizar el usuario actual. Todo el código debe tener plena confianza para ejecutarse en las soluciones de Office.

• Confianza parcial. Este nivel es un conjunto de permisos restringido que concede sólo los permisos especificados. El código de confianza parcial no se ejecutará en las soluciones de Office.

• No es de confianza. Este nivel no concede ningún permisos, por lo que no se ejecuta el código.

El conjunto de permisos requerido corresponde al nivel de plena confianza; las soluciones de Office no ejecutan extensiones de código administrado con confianza parcial o que no sean de confianza. Para obtener más información sobre los conjuntos de permisos, vea Conjuntos de permisos con nombre.

Tipos de prueba

Los tipos de prueba de seguridad de .NET Framework son los siguientes:

• Todo el código.

• Directorio de la aplicación.

• Caché de ensamblados global (GAC).

• Hash.

• Editor.

• Sitio.

• Nombre seguro.

• Dirección URL.

• Zona.

• Personalizado. (msosec.dll para las soluciones de Office. Para obtener más información, vea Cómo: Conceder permisos a documentos y libros en ubicaciones compartidas (2003 System).)

Para obtener más información, vea Prueba.

Visual Studio utiliza la prueba de la dirección URL para conceder plena confianza a los proyectos cuando el usuario los genera. Cuando Visual Studio genera un proyecto de Visual Studio Tools para Office, modifica la directiva de seguridad de nivel de usuario para conceder plena confianza a las ubicaciones de compilación de los proyectos de Office. Cuando se ejecuta la personalización o el complemento, el cargador presenta la dirección URL de la ubicación del ensamblado al sistema de directivas, que concede plena confianza a las ubicaciones específicas.

Por lo general, este nivel de seguridad es suficiente cuando se trabaja en el propio equipo, pero podría suponer un problema de seguridad si se utiliza esta prueba cuando se implementa la solución. Antes de implementar el ensamblado, se le debe otorgar una forma de prueba más estricta. Hay dos razones para utilizar una forma de prueba más estricta:

• Si desea conceder plena confianza a una ubicación Web, usuarios malintencionados que tengan acceso a esa ubicación pueden reemplazar el ensamblado por su propio código y engañar a la gente para que lo ejecute.

• La directiva predeterminada de nivel de equipo concede confianza parcial a todos los sitios Web, pero como se requiere plena confianza, configurar una directiva de nivel de usuario para conceder plena confianza a una dirección URL es insuficiente.

Si decide utilizar la prueba de dirección URL, asegúrese de establecer la directiva en la bifurcación Zona de intranet del nivel de directiva de equipo, no el nivel de directiva de usuario. Además, otorgue plena confianza sólo a las ubicaciones en las que sabe que únicamente pueden escribir personas de confianza. Una directiva mejor es utilizar una combinación de ubicación y prueba criptográficamente estricta, como un nombre seguro. Los nombres seguros siempre deben utilizarse junto con información de ubicación, con el fin de que se pueda revisar de forma segura cualquier aplicación con nombre seguro que se vea comprometida.

Para las personalizaciones de nivel de documento, el documento también dispone de una prueba basada en la ubicación; así resulta más difícil que usuarios malintencionados manipulen el código de confianza y creen documentos que lo utilicen para fines no deseados. Si un documento que tiene extensiones de código administrado no está en una ubicación de plena confianza, no ejecuta el ensamblado. De forma predeterminada, la zona Mi PC es de plena confianza, por lo que los documentos del equipo del usuario pueden ejecutar el código, pero la zona Internet no es de plena confianza.

Los documentos con extensiones de código administrado no utilizan la seguridad de macros de Office, que se basa en el almacén de certificados de Office. La seguridad de macros no está relacionada con la seguridad de ensamblados.

Para obtener información sobre la seguridad en .NET Framework, vea Conceptos básicos sobre la seguridad de acceso a código o, más general, Seguridad en .NET Framework y Información general acerca de la administración de directivas de seguridad.

Información general sobre seguridad de ensamblados

Información general sobre seguridad de documentos

Seguridad en el equipo de desarrollo

Cuando el programador crea un proyecto de Office en Visual Studio, se agrega de forma predeterminada la ruta completa de acceso al ensamblado (incluido el nombre del ensamblado) a la directiva de seguridad de .NET Framework en el nivel de usuario. De este modo el ensamblado recibe plena confianza. Los ensamblados a los que se hace referencia que están situados en la carpeta de resultados del proyecto también reciben plena confianza cuando se genera el proyecto.

Si no se cambia la configuración predeterminada, Visual Studio Tools para Office comprueba la directiva de seguridad en la memoria caché cada vez que genera la solución. Si los ensamblados no tienen plena confianza, Visual Studio Tools para Office la concede. Esto permite al proyecto retener la confianza aunque se cambie el nombre al ensamblado o se mueva el proyecto a otra ubicación.

Si cambia la configuración de confianza predeterminada (establece la propiedad Ubicación de los ensamblados de confianza en false), Visual Studio no concede plena confianza a los ensamblados y el código no se ejecuta. Para volver a ejecutar el código, cambie la propiedad Ubicación de los ensamblados de confianza a true y vuelva a generar la solución. También puede establecer una regla global que permita que todos los códigos que se ejecuten en la carpeta y subcarpetas de proyectos tengan plena confianza.

Para obtener información sobre cómo establecer opciones de confianza para un proyecto y conceder plena confianza a las carpetas, vea Cómo: Conceder permisos a carpetas y ensamblados (2003 System).

Almacenamiento en caché de directivas de seguridad

Common Language Runtime almacena en memoria caché la directiva de seguridad para cada proceso. Visual Studio comprueba esta memoria caché cuando se generan proyectos para ver si los ensamblados tienen plena confianza. Si los ensamblados ya tienen plena confianza cuando se inicia Visual Studio, Visual Studio no crea una directiva para ellos durante el proceso de generación.

Si cambia la directiva de seguridad relacionada con su proyecto mientras Visual Studio se está ejecutando, Visual Studio no detecta el cambio. Si el cambio realizado impide que se ejecute el proyecto, la aplicación produce una excepción de seguridad porque Visual Studio no vuelve a crear la directiva para conceder plena confianza a los ensamblados. Para que Visual Studio pueda detectar los cambios en las directivas de seguridad, se debe cerrar y volver a abrir Visual Studio.

Soluciones creadas con versiones anteriores

Cada versión de Microsoft .NET Framework instalada en un equipo tiene asociada una directiva de seguridad. Las soluciones de Visual Studio Tools para Office comprueban la directiva de seguridad de la versión de .NET Framework para la que se crearon. Si se crea una solución con Visual Studio Tools para Office, versión 2003, ésta siempre comprueba la versión 1.1 de .NET Framework para la directiva de seguridad. Si se crea una solución con Visual Studio 2005 Tools para Office, ésta siempre comprueba la versión 2.0 de .NET Framework para la directiva de seguridad.

Las soluciones de Visual Studio Tools para Microsoft Office System 3.0 comprueban la versión 3.5 de .NET Framework, pero las soluciones para Office 2003 se pueden establecer para utilizar .NET Framework 2.0. Para obtener más información, vea Cómo: Cambiar la versión de .NET Framework de destino. 

Proyectos creados en red

Aunque se pueden crear proyectos en una ubicación compartida de red, no se pueden ejecutar en la red hasta que se les conceda plena confianza en el nivel de equipo. De forma predeterminada, Visual Studio Tools para Office utiliza la prueba de la dirección URL en el nivel de usuario. Debe conceder manualmente plena confianza al ensamblado en el nivel de equipo.

Si utiliza únicamente la prueba de dirección URL para conceder plena confianza a una ubicación de red, usuarios malintencionados que tengan acceso a esa ubicación pueden reemplazar el ensamblado por su propio código y engañar a la gente para que lo ejecute. Considere las otras formas de prueba que puede utilizar en lugar de la prueba de dirección URL o además de ella. Para obtener más información, vea la sección Tipos de prueba de este tema.

Seguridad para los usuarios finales

Los usuarios finales abren los documentos con extensiones de código administrado tal como abrirían cualquier otro documento. Si el documento está en el equipo del usuario final o se le ha concedido confianza en un recurso compartido de red, Word o Excel intentan cargar y ejecutar el ensamblado. En el caso de los complementos, se cargan cuando el usuario inicia la aplicación de Microsoft Office.

La aplicación de Microsoft Office comprueba la directiva de seguridad y realiza una de las acciones siguientes:

• Si se han concedido permisos explícitamente al ensamblado y al documento (si corresponde), se permite la ejecución del ensamblado. Para obtener más información sobre el modo de establecer directivas de seguridad en equipos de usuarios finales, vea Implementar la directiva de seguridad.

• Si la única prueba para la determinación de permisos está basada en zonas o en todo el código, éste no se ejecuta y el usuario recibe un mensaje de error que indica que la directiva de seguridad actual está impidiendo la ejecución del código. El usuario debe ponerse en contacto con un administrador para configurar la directiva que permite al código ejecutarse.

La directiva de seguridad predeterminada de Visual Studio Tools para Office no permite ejecutar el código en personalizaciones. De forma predeterminada, la zona Mi PC es de plena confianza en la directiva de seguridad, pero la directiva de dominio de la aplicación para los documentos con extensiones de código administrado no permite la ejecución del código en dicha zona mientras no se le otorgue confianza explícitamente. Este enfoque es diferente del basado en la experiencia del desarrollador y de los usuarios finales, pero proporciona más seguridad al escritorio mediante la configuración predeterminada. Además, los usuarios finales no pueden cambiar las opciones de seguridad en Office con el fin de que se pueda ejecutar código que no sea de confianza. Sólo si se realizan cambios explícitos en la directiva de seguridad del entorno .NET es posible la ejecución de extensiones de código administrado.

Otorgar confianza a los documentos de Office

En la mayoría de las situaciones, los documentos de Office se ejecutan desde la zona Mi PC y no se requiere ninguna acción para que el documento se abra conforme a lo esperado. Sin embargo, el ensamblado deber seguir siendo de plena confianza para que la aplicación se pueda ejecutar. Si el documento ha llegado como elemento adjunto de un mensaje de correo electrónico, se debe guardar en alguna otra parte del equipo (como el escritorio del usuario) antes de que la solución se ejecute, aun cuando el documento apunte a un ensamblado de confianza. Esto se debe a que los elementos adjuntos están en la zona de Internet, que no tiene plena confianza.

Si el documento está ubicado en la red, el administrador también debe conceder permisos al documento. En el caso de documentos estáticos, como las plantillas, el administrador puede otorgar confianza al documento basada en la ruta completa de acceso (URL). En el caso de almacenamientos más generales donde muchos usuarios pueden cargar contenido arbitrario, como una lista de SharePoint, el administrador puede decidirse por otorgar confianza sólo a los documentos de Office situados en esa ubicación compartida. Para obtener más información, vea Cómo: Conceder permisos a documentos y libros en ubicaciones compartidas (2003 System).

Retirar la confianza de los ensamblados

Si el administrador detecta que hay un problema de seguridad en la organización, puede deshabilitar temporalmente la totalidad del código administrado mediante la aplicación de una directiva que no proporcione permisos para la ejecución de todo el código. Si se precisa una parte del código administrado, el administrador puede modificar la directiva de modo que sólo se habilite el código cuya ejecución sea necesaria mediante la elección de una única propiedad de dicho código (por ejemplo, ubicación, nombre seguro o firma) y la concesión de los permisos necesarios. El código administrado puede volver a habilitarse fácilmente con sólo revertir la directiva a su forma anterior una vez resuelto el problema de seguridad. Para obtener más información, vea Cómo: Quitar permisos a carpetas y ensamblados (2003 System).

Vea también

Conceptos

Implementación segura (2003 System)

Procedimientos recomendados sobre seguridad para soluciones de Office (2003 System)

Consideraciones de seguridad específicas para soluciones de Office

Proteger aplicaciones

Otros recursos

Seguridad en las soluciones de Office (2003 System)