Implementación segura (2003 System)

Actualización: noviembre 2007

Cuando se crea una solución de Visual Studio Tools para Office, la directiva de seguridad local se actualiza automáticamente para permitir que se ejecute el código en el proyecto. Sin embargo, al implementar la solución, debe actualizar explícitamente la directiva de seguridad en cada uno de los equipos en los que se vaya a utilizar la solución para que el código de ensamblado pueda ejecutarse y tener acceso al modelo de objetos de Office.

Para las personalizaciones de nivel de documento, si implementa el documento en una ubicación de red, también debe actualizar la directiva de seguridad del documento. 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. Para obtener más información sobre las personalizaciones de nivel de documento, vea Arquitectura de las personalizaciones de nivel de documento.

Nombres seguros y certificados

La forma recomendada para implementar soluciones con seguridad es asignar un nombre seguro a los ensamblados, firmarlos con un certificado Authenticode (x.509) o efectuar ambas acciones para mejorar la seguridad y la administración. Los nombres seguros y las firmas Authenticode proporcionan un mayor grado de seguridad puesto que es muy difícil que alguien modifique el código sin invalidar también el nombre seguro o la firma. Las firmas Authenticode tienen ventajas adicionales:

• Las firmas Authenticode pueden tener marcas de hora.

• Los certificados se pueden revocar.

• El certificado proporciona la identidad del editor.

Para obtener más información acerca de los ensamblados con nombre seguro, vea Ensamblados con nombre seguro y Crear y utilizar ensamblados con nombre seguro.

Para obtener más información acerca de las firmas Authenticode, vea Implementación y firma Authenticode.

Elegir el nivel de seguridad

Debe sopesar las ventajas de seguridad de las reglas estrictas respecto a las ventajas administrativas de las reglas poco estrictas, y elegir un nivel adecuado de confianza. Por ejemplo, si las soluciones siempre se van a implementar en un servidor denominado \\appserver\ y siempre van a estar firmadas con el certificado corporativo, elija una regla que sólo confíe en este certificado corporativo en \\appserver\. De esta forma se incrementa la protección contra los usuarios malintencionados que roban el certificado y publican el código en Internet (el código no es de confianza a menos que su origen sea \\appserver\). También significa que si desea almacenar ensamblados en un servidor distinto en el futuro, tendrá que actualizar la directiva de seguridad una vez más.

Si no está seguro de dónde se van a implementar las soluciones, lo razonable es confiar en el certificado o el nombre seguro cuyo origen sea el equipo y la intranet locales. Si piensa distribuir el código a través del Web, también puede utilizar la zona Sitios de confianza de las opciones de seguridad de Internet Explorer. No debe confiar en el certificado desde la zona Internet, la zona Sitios restringidos o con seguridad máxima (Todo el código), a menos que tenga razones empresariales para actuar de esta forma. Si lo hace, tome las precauciones oportunas para garantizar la seguridad del código aunque caiga en manos de usuarios malintencionados. Para obtener más información, vea Seguridad de acceso a código.

Para obtener información sobre posibles amenazas, vea Consideraciones de seguridad específicas para soluciones de Office.

Otorgar derechos de acceso al ensamblado

Una opción de implementación para las personalizaciones de nivel de documento es implementar el documento localmente en el equipo de cada usuario y el ensamblado en una ubicación de red. De forma similar, para los complementos de nivel de aplicación puede implementar el ensamblado de complemento en una ubicación de red. El ensamblado no se ejecutará en una solución de Office a menos que sea de confianza. Firme digitalmente el ensamblado y conceda acceso de escritura a la ubicación sólo a los administradores del sistema (y a cualquiera que deba modificar el ensamblado). Para obtener más información sobre cómo proteger el ensamblado antes de la implementación, vea Consideraciones de seguridad sobre ensamblados.

Puede utilizar la herramienta de configuración de Microsoft .NET Framework 2.0 o la herramienta Directiva de seguridad de acceso del código (Caspol.exe) para establecer una directiva empresarial que conceda confianza al ensamblado.

Para obtener más información acerca de la herramienta de configuración de .NET Framework, vea Herramienta Configuración de .NET Framework (Mscorcfg.msc). Para obtener más información sobre Caspol.exe, vea Herramienta de la directiva de seguridad de acceso a código (Caspol.exe) y Configurar directivas de seguridad mediante la herramienta Directiva de seguridad de acceso a código (Caspol.exe).

Antes de implementar un ensamblado en su ubicación final (o actualizar un ensamblado implementado), estudie la directiva de seguridad y determine el tipo de evidencia que va a utilizar para minimizar el riesgo. Para obtener más información, vea Requisitos de seguridad para ejecutar las soluciones de Office (2003 System).

Proteger documentos en la red

Para las personalizaciones de nivel de documento, si el documento se encuentra en un servidor o en un recurso compartido de red, se debe dar plena confianza a la dirección URL del documento. Este procedimiento funciona mejor para plantillas o documentos individuales que pueden modificar personas de confianza. Debe asegurarse de que los usuarios que no sean de confianza no tengan permisos para modificar o reemplazar el documento del recurso compartido.

Si un administrador desea permitir que los usuarios puedan tener acceso a los documentos que están en un recurso compartido público, como un portal de SharePoint, debe modificar la directiva para que incluya un nuevo código de grupo para los documentos. El grupo de código no codifica la condición de pertenencia que busca documentos de Office como evidencia y permite que los administradores decidan en consecuencia (del mismo modo que los administradores deben agregar un grupo de código para confiar explícitamente en el ensamblado). Para obtener más información, vea Cómo: Conceder permisos a documentos y libros en ubicaciones compartidas (2003 System).

Distribución de correo electrónico

De forma predeterminada, para las personalizaciones de nivel de documento, el ensamblado no se ejecuta si el documento se abre directamente desde un mensaje de correo electrónico. Sin embargo, el documento se puede guardar en el disco duro local y, a continuación, se puede abrir normalmente. Si el documento contiene una ruta de acceso completa a un ensamblado de plena confianza en su manifiesto de aplicación, la solución funcionará.

Es posible, aunque no aconsejable, habilitar documentos en la carpeta temporal de Outlook para hospedar el código. Esto representa un riesgo de seguridad bajo a medio porque, si existe un punto débil en un ensamblado implementado al que se ha otorgado plena confianza, un usuario malintencionado puede aprovechar esa debilidad adjuntando un documento que señale al ensamblado en un mensaje de correo electrónico y animar al destinatario a que lo abra. Si tiene éxito, el atacante podría, por ejemplo, tener acceso al sitio de una intranet segura con las credenciales del usuario de destino. Observe que el ensamblado seguiría necesitando que se le otorgase plena confianza explícitamente; de este modo, un atacante no podría crear ningún documento ni ningún ensamblado de su elección y engañar al usuario para que lo ejecutase.

Cambiar la directiva de seguridad

Si el administrador ajusta los permisos de un documento o de un ensamblado, los usuarios deben salir y reiniciar todas las aplicaciones de Office para que los cambios surtan efecto.

A veces el proceso de aplicación de Office continúa ejecutándose después de que el usuario sale de la aplicación, lo cual evitará que entren en vigencia los cambios en la directiva de seguridad. Compruebe el Administrador de tareas y asegúrese de que la aplicación de Office no está en la lista de procesos activos.

El resto de las aplicaciones que hospedan aplicaciones de Office también pueden impedir que se apliquen los nuevos permisos. Los usuarios deben salir de todas las aplicaciones, autónomas o no, incluido Internet Explorer, que Office utiliza cuando se modifican las directivas de seguridad.

Evitar que las personalizaciones de nivel de documento ejecuten código

Los administradores pueden utilizar el Registro para evitar que se ejecuten en un equipo todas las personalizaciones de nivel de documento. Cuando se abre un documento de Word o un libro de Excel que tiene extensiones de código administrado, el motor en tiempo de ejecución de Visual Studio Tools para Office comprueba si existe una entrada con el nombre Disabled en una de las siguientes claves del Registro en el equipo:

• HKEY_CURRENT_USER\Software\Microsoft\VSTO

• HKEY_LOCAL_MACHINE\Software\Microsoft\VSTO

Para evitar que las personalizaciones de nivel de documento ejecuten código, cree una entrada Disabled en una de estas claves del Registro, o en ambas, y especifique uno de los siguientes tipos de datos y valores para Disabled:

• REG_SZ o REG_EXPAND_SZ que se establece en cualquier cadena distinta de "0" (cero).

• REG_DWORD que se establece en cualquier valor distinto de 0 (cero).

Los usuarios pueden seguir abriendo documentos y realizando cambios mientras las personalizaciones de nivel de documento estén deshabilitadas, pero el código del ensamblado no se ejecutará. Para permitir que las personalizaciones de nivel de documento ejecuten código, establezca las dos entradas de Disabled en 0 o elimine las entradas del Registro.

Vea también

Tareas

Cómo: Implementar soluciones de Office (2003 System)

Cómo: Quitar extensiones de código administrado de documentos (2003 System)

Cómo: Implementar el uso sin conexión de documentos (2003 System)

Conceptos

Modelos de implementación (2003 System)

Implementar personalizaciones de nivel de documento (2003 System)

Implementar soluciones de Office (2003 System)

Implementar complementos de nivel de aplicación (2003 System)

Otros recursos

Seguridad en las soluciones de Office (2003 System)

Solución de problemas de soluciones de Office