Plan de seguridad del flujo de trabajo y administración de usuarios (SharePoint Foundation 2010)

  • Artículo

 

Se aplica a: SharePoint Foundation 2010

Última modificación del tema: 2011-03-09

Antes de implementar flujos de trabajo en Microsoft SharePoint Foundation 2010 para usuarios, es posible que a los administradores les preocupen temas de seguridad como la divulgación de información o el aumento de privilegios. En este artículo se destacan algunos aspectos del comportamiento del flujo de trabajo relacionados con la seguridad y con otros problemas que los administradores y programadores de flujos de trabajo deberían considerar cuando configuran y desarrollan flujos de trabajo.

En este artículo:

Roles y responsabilidades del administrador de listas, el administrador y el programador

A continuación se describen algunas acciones comunes de flujos de trabajo y las responsabilidades relacionadas, que explican el rol de los administradores y los programadores en los flujos de trabajo en ejecución.

Programadores de flujos de trabajo

Desarrollar la programación y la plantilla de flujo de trabajo   Los programadores de flujos de trabajo se encargan de crear el código del ensamblado que contiene la lógica empresarial que se ejecutará en un elemento de SharePoint. Este ensamblado se denomina programación de flujo de trabajo. También son responsables de empaquetar los formularios de flujo de trabajo y el ensamblado en una característica o en una plantilla de flujo de trabajo.

Administradores de sitios

Administrar la configuración de flujo de trabajo en Administración central   Los administradores de sitios pueden controlar la configuración de flujo de trabajo general, como la configuración de alertas de tarea y de participantes externos desde el sitio web de Administración central de SharePoint.

Implementar características del flujo de trabajo   Los administradores de sitios pueden instalar características del flujo de trabajo en una colección de sitios a fin de que se encuentren disponibles para la asociación.

Administradores de listas (cualquiera con permisos de administrador de listas o diseñador web)

Agregar flujos de trabajo   Los administradores de listas deben asociar (agregar) una plantilla de flujo de trabajo a una lista o tipo de contenido, de acuerdo con las necesidades empresariales de la lista o tipo de contenido. Esta asociación hace que la plantilla de flujo de trabajo esté disponible para usuarios finales, quienes después podrán seleccionar una configuración y valores predeterminados.

Quitar flujos de trabajo   Los administradores de listas pueden quitar asociaciones de flujo de trabajo de una lista o un tipo de contenido, o bien impedir que se ejecuten sesiones nuevas.

Terminar un flujo de trabajo   Si se produce un error en una sesión de flujo de trabajo, los administradores de listas pueden detenerla durante su ejecución, por ejemplo, cuando una sesión de flujo de trabajo da error o no se inicia, mediante el vínculo Terminar este flujo de trabajo en la página Estado del flujo de trabajo. Esta acción se reserva para los administradores.

Ejecución de flujos de trabajo como administrador

El concepto de seguridad más importante que hay que tener en cuenta es que el flujo de trabajo se ejecuta como parte de la cuenta del sistema en SharePoint Foundation 2010, con la configuración de identidad del grupo de aplicaciones en el equipo y dominio del servidor. Esto significa que en SharePoint Foundation 2010, los flujos de trabajo tienen permisos de administrador. En el servidor, los flujos de trabajo tienen los mismos permisos que el grupo de aplicaciones, que suele tener permisos de administrador. Estos permisos permiten que los flujos de trabajo ejecuten acciones que los usuarios comunes no pueden realizar, como enrutar un documento a una ubicación o a un centro de registros específico, o agregar una cuenta de usuario al sistema.

Esta configuración de flujos de trabajo con permisos de administrador no puede cambiarse. Corresponde a la programación del flujo de trabajo (es decir, al código del flujo de trabajo) detectar acciones de usuarios y, de acuerdo con esas acciones, continuar o deshacer los cambios, o suplantar al usuario para imitar los permisos de ese usuario.

Al implementar flujos de trabajo, los administradores deben comprender las acciones que realizará el flujo de trabajo de modo que puedan evaluar los posibles riesgos asociados con el aumento de permisos en un flujo de trabajo y colaborar con el programador para mitigar cualquier problema relacionado con la seguridad.

Opciones de configuración del flujo de trabajo

SharePoint Foundation 2010 incluye algunas opciones de configuración que los administradores deben establecer de acuerdo con las necesidades de seguridad.

Permisos requeridos para iniciar un flujo de trabajo

Además de impedir el aumento de permisos en el código, los administradores de listas pueden restringir el nivel de permisos que se necesita para iniciar un flujo de trabajo durante el proceso de asociación. Los administradores pueden elegir entre dos niveles de permisos para iniciar una asociación específica de flujo de trabajo: Editar elemento o Administrar lista.

La configuración predeterminada de la asociación de un flujo de trabajo permite que los usuarios con permisos para editar elementos puedan iniciar un flujo de trabajo manualmente. Esto significa que todos los usuarios de SharePoint Foundation 2010 autenticados en la lista con permisos para editar elementos pueden iniciar una sesión de esta asociación de flujo de trabajo. Si durante la creación del flujo de trabajo, el administrador selecciona la opción que requiere que el usuario tenga permisos de administración de listas para iniciar el flujo de trabajo, solo los administradores de listas podrán iniciar una sesión de esta asociación.

Dado que los flujos de trabajo están diseñados para que los usen colaboradores estándar, la mayoría de los flujos de trabajo no requieren la restricción de permisos de administración de listas. No obstante, los administradores pueden usar esta configuración para algunos flujos de trabajo, como por ejemplo, un flujo de trabajo de eliminación de documentos donde solo determinadas personas puedan ejecutar las acciones de eliminación.

Configuración de Administración central

Para encontrar las siguientes opciones en la página Administración central, haga clic en Administración de aplicaciones y, en la sección Aplicaciones web, haga clic en Administrar aplicaciones web. En la página Aplicaciones web, seleccione la aplicación web que desea configurar y, en el grupo Administrar de la cinta de opciones, haga clic en Configuración general y, a continuación, seleccione Flujo de trabajo. Se abrirá la página Configuración del flujo de trabajo y se mostrarán las siguientes opciones:

  • Flujos de trabajo definidos por el usuario

  • Notificaciones de tareas de flujo de trabajo

Habilitar flujos de trabajo definidos por el usuario

De forma predeterminada, los flujos de trabajo definidos por el usuario se encuentran habilitados para todos los sitios en una aplicación web, como se muestra en la sección Flujos de trabajo definidos por el usuario de la página Configuración del flujo de trabajo. Cuando se selecciona esta opción, los usuarios pueden definir flujos de trabajo en un editor de flujos de trabajo, como el editor de SharePoint Designer 2010. Los usuarios que definen estos flujos de trabajo deben tener permisos de administración de listas en el sitio en el que desean implementar el flujo de trabajo.

Notificación de tarea para usuarios sin acceso al sitio

En la página Configuración del flujo de trabajo, en la sección Notificaciones de tareas de flujo de trabajo, se pueden establecer opciones para enviar notificaciones de tareas pendientes del flujo de trabajo a los usuarios que no tienen acceso al sitio.

-
Usuarios internos

En SharePoint Foundation 2010, es posible resolver el conflicto de nombres de usuarios internos en el servicio de directorio que no son miembros del sitio o que no tienen acceso a esa tarea. En este caso, un administrador puede seleccionar la opción **¿Desea avisar a los usuarios internos sin acceso al sitio cuando se les asigne una tarea de flujo de trabajo?**, en la sección **Notificaciones de tareas de flujo de trabajo**, para establecer que esos usuarios reciban una notificación de tarea por correo electrónico. Esta opción significa que los usuarios reciben una alerta cuando se les asigna una tarea de flujo de trabajo. Esta opción está habilitada de forma predeterminada y el mensaje de correo electrónico que reciben los usuarios contiene un vínculo en el que pueden hacer clic para solicitar acceso al sitio (los administradores aún deben conceder acceso). Es posible que este mensaje de correo electrónico incluya información sobre el documento. Esta información puede ser el título del documento y las instrucciones del propietario del flujo de trabajo. Si preocupa la divulgación de información a usuarios internos que no sean miembros del sitio, los administradores pueden deshabilitar la opción **¿Desea avisar a los usuarios internos sin acceso al sitio cuando se les asigne una tarea de flujo de trabajo?**.

  • Usuarios externos

    Es posible asignar tareas de flujo de trabajo a usuarios externos que no están incluidos en el servicio de directorio pero que tienen asignada una dirección de correo electrónico SMTP de formato correcto. Dado que para los usuarios externos resulta difícil tener acceso al documento, SharePoint Foundation 2010 incluye una opción de configuración, ¿Permitir a los usuarios externos participar en el flujo de trabajo enviándoles una copia del documento?, que permite enviar a los usuarios externos una notificación de tarea por correo electrónico con el documento adjunto. Cuando esta opción está habilitada, la tarea se asignará al propietario del flujo de trabajo y el usuario externo podrá completarla enviando un mensaje de correo electrónico al propietario.

    De forma predeterminada, la opción ¿Permitir a los usuarios externos participar en el flujo de trabajo enviándoles una copia del documento? se encuentra deshabilitada. No obstante, esta configuración puede resultar útil en aquellas situaciones que requieran participación externa, como la aprobación de documentos empresariales que cuenten con clientes externos. Los administradores que habilitan esta configuración (seleccionan Sí) deben comprobar que la programación del flujo de trabajo admita la configuración de participante externo. Por ejemplo, cuando se crea una tarea para un usuario externo, el flujo de trabajo personalizado debe especificar la dirección de correo electrónico externa en la propiedad OnBehalfEmail, en el objeto SPWorkflowTaskProperties usado para inicializar la tarea. Varios flujos de trabajo integrados en SharePoint Foundation 2010 admiten esta configuración.

    Los programadores de flujos de trabajo personalizados que desean habilitar esta función deben colaborar con los administradores para determinar si existen riesgos de divulgación de información asociados al adjuntar el documento en sí a un mensaje de correo electrónico externo. Los administradores deben evaluar los riesgos y beneficios cuando habilitan esta configuración.

Divulgación de información en las listas de tareas y de historial del flujo de trabajo

Dado que los elementos de las listas de tareas y de historial pueden contener datos sobre los usuarios y las acciones que éstos realizan en los documentos, es posible que estos elementos divulguen información confidencial. Por ejemplo, un flujo de trabajo de aprobación de promociones podría recopilar comentarios en sus tareas que una organización desea que sean vistos únicamente por el propietario del flujo de trabajo y por cada participante individual de la tarea.

Las listas de tareas y de historial son listas que normalmente están en el sitio. De forma predeterminada, por lo tanto, todos los lectores pueden ver las tareas y los elementos de historial. Los administradores y los programadores deben determinar cuál es la información que no debe divulgarse y decidir si proteger los elementos de tarea y de historial creados por el flujo de trabajo.

La protección de estos datos puede llevarse a cabo de diversas maneras. Por ejemplo, los administradores pueden establecer permisos a nivel de lista. Si la divulgación debe ser confidencial, es decir que no debe estar disponible para el público pero sí para un grupo específico de personas, los administradores pueden crear una lista nueva de tareas o de historial, y establecer permisos para la lista que está dirigida a dicho grupo. Si los administradores no desean que nadie vea los eventos de historial en una página de estado de flujo de trabajo, pueden quitar los permisos para ver la lista de historial de flujo de trabajo de la que una página de estado extrae información. Los usuarios que no disponen de permisos para ver la lista de historial o cualquier elemento de la lista, recibirán el error Acceso denegado cuando abran cualquier página de estado que extraiga datos de esa lista de historial.

Si se requieren restricciones más precisas, los programadores de flujos de trabajo pueden establecer permisos cuando creen tareas o elementos de historial. La actividad CreateTask tiene una propiedad SpecialPermissions que solo concede permisos específicos para tener acceso a la tarea recién creada. La actividad LogToHistoryList no tiene tal propiedad, de modo que para establecer permisos por elemento en los elementos de la lista de historial, los administradores deben usar el modelo de objetos (OM) en SharePoint Foundation 2010. Los permisos por elemento pueden afectar negativamente al rendimiento y no deben usarse a menos que sean necesarios.

Las tareas y los elementos de historial no deben tratarse de la misma manera. Los administradores pueden combinar diferentes permisos de listas y permisos a nivel de elementos.

Ataques de suplantación de identidad y alteración en las listas de tareas y del historial de flujo de trabajo

Cualquier colaborador puede modificar las tareas y los elementos de historial, si no existen restricciones en esas listas. Esto significa que los usuarios malintencionados pueden modificar descripciones de tareas para proporcionar a los participantes instrucciones incorrectas o hacer que éstos hagan clic en vínculos malintencionados. Además, los usuarios pueden agregar o modificar los eventos de historial que son falsos o inexactos para cambiar los resultados percibidos de un proceso.

Como se explicó anteriormente, las listas de tareas y de historial son listas normales en un sitio. De forma predeterminada, no existen restricciones de permiso en ninguna de estas listas. Para evitar los ataques de suplantación de identidad y de alteración, los administradores deben determinar qué puntos vulnerables existen y restringir el acceso a las columnas de una lista (por ejemplo, convertir las columnas vulnerables, como descripciones de tareas, en columnas de solo lectura para que únicamente el flujo de trabajo pueda establecerlas al crear elementos), establecer permisos especiales en la lista, o bien establecer permisos a nivel de elemento en los elementos.

Problemas de seguridad en la lista de historial del flujo de trabajo

Una ventaja clave de los flujos de trabajo es la capacidad de realizar un seguimiento de la información del proceso a fin de proporcionar visibilidad en un proceso. La lista de historial del flujo de trabajo es un repositorio para esta información donde una página de estado de flujo de trabajo puede buscar datos relacionados con una sesión del flujo de trabajo y poner esta información a disposición de los usuarios. Los usuarios pueden ver todos los elementos a los que tienen acceso en la lista de historial.

No obstante, dado que la lista de historial del flujo de trabajo realiza un seguimiento de la información, es posible que los usuarios asuman que ésta puede usarse como una pista de auditoría para eventos. Las listas de historial son listas estándar de SharePoint que se utilizan para almacenar eventos, que son visibles para cualquier usuario y que no tienen permisos especiales asociados a ellas. De forma predeterminada, los usuarios pueden modificar y agregar eventos si disponen de permisos para editar y agregar en el sitio. Para auditar eventos, se utiliza la característica Registro de auditoría de SharePoint. Solo los administradores pueden tener acceso a este registro y no se requiere trabajo adicional para protegerlo de los ataques de alteración.

Para proteger mejor la lista de historial, los administradores pueden restringir los permisos para editar y ver en la lista, de modo que solo los administradores con cuenta del sistema (por ejemplo, los administradores de flujos de trabajo) y los administradores de listas puedan agregar elementos. Los administradores de listas deben tener permisos para agregar, a fin de registrar los eventos "Terminar este flujo de trabajo". Si los permisos para editar y agregar están restringidos en la lista de historial, aún se debe conceder a los usuarios permisos de vista para que puedan ver la información de estado.

Paso de suplantación de usuario en flujos de trabajo declarativos

El tipo Paso de suplantación de usuario puede usarse para ejecutar secciones de flujos de trabajo declarativos por la persona que creó el flujo de trabajo en lugar de su iniciador. Declarativo significa que es un modelo que sirve para crear el flujo de trabajo y establecer sus parámetros sin escribir ningún código.

En SharePoint Foundation 2010, los flujos de trabajo declarativos siempre se ejecutan en el contexto de usuario del iniciador del flujo de trabajo, a menos que se presente el paso de suplantación. Si se presenta un paso de suplantación, el flujo de trabajo declarativo se ejecuta en el contexto del asociador del flujo de trabajo. Las tareas predeterminadas del flujo de trabajo respetan los permisos de SharePoint suplantando al usuario que inició un flujo de trabajo, cuando se ejecuta el flujo de trabajo. Esta disposición mantiene las tareas bastante seguras en SharePoint Foundation 2010, pero bloquea muchos escenarios en los que el diseñador de un flujo de trabajo con niveles de permiso elevados desea crear un flujo de trabajo eficaz que puede completarse satisfactoriamente por usuarios con niveles de permiso más bajos.

Mediante un formulario de elevación de privilegios seguro y con ámbito definido, las acciones del sitio pueden automatizarse por flujo de trabajo. Esto reduce la carga de un administrador de sitios de SharePoint. La automatización de un proceso de alta seguridad es útil en escenarios de publicación y de aprobación en los que las acciones existentes están habilitadas para suplantar a alguien que no sea el iniciador del flujo de trabajo.

A continuación, se presentan ejemplos de escenarios que demuestran el tipo Paso de suplantación de usuario:

  • Publicación en una lista segura

    María ha bloqueado la biblioteca de documentos Páginas para la imagen pública de su sitio de SharePoint. Ha establecido un flujo de trabajo que, mediante Microsoft SharePoint Designer 2010, presenta contenido de los colaboradores del sitio para su aprobación. María ha colocado las acciones de su flujo de trabajo en un paso de suplantación de modo que las acciones del flujo de trabajo siempre la suplantarán, en calidad de administrador del sitio, como la autora del flujo de trabajo.

    Cuando Cecilia (una colaboradora) envía un borrador de contenido a la biblioteca Páginas del sitio e intenta publicar su artículo, esa acción hace que se inicie el flujo de trabajo de aprobación de María de modo que la entrada pueda revisarse y aprobarse. Las tareas se envían a los aprobadores del flujo de trabajo en nombre de Cecilia. Una vez efectuada la revisión y la aprobación, el sistema establece el estado de moderación de la entrada en "Aprobado", aunque Cecilia no tiene permiso para aprobar páginas.

  • Concesión de permisos a usuarios

    Patricia ha establecido un flujo de trabajo en SharePoint Designer 2010 que usa la acción de suplantación de usuario “Agregar usuario al grupo" para conceder permisos de diseño en su sitio. Dado que el flujo de trabajo usa un ámbito de suplantación, la acción de agregar a un usuario al grupo siempre se realizará en nombre de Patricia.

    El resto del flujo de trabajo permite a los colaboradores visitar el sitio y completar un formulario para registrar sus solicitudes de acceso en una lista.

    Por ejemplo, un usuario independiente, Diego, recibe una tarea cuando Cecilia, una usuaria, registra una solicitud. Cuando Diego aprueba la tarea, se agrega a Cecilia al grupo Diseñador del sitio, aunque ni Diego ni Cecilia tengan permisos de administración de listas en el sitio de Patricia.

  • Plantillas y apropiación de la propiedad

    Francisco creó varios flujos de trabajo en SharePoint Designer 2010 y los almacenó como plantillas para que se vuelvan a usar en toda la compañía. Sin embargo, poco después dejó de trabajar para la compañía. Su cuenta se eliminó y se revocó su estado de administrador, por lo que ahora no se pueden completar los flujos de trabajo de SharePoint Designer 2010 que Francisco creó porque se perdieron sus permisos.

    Un administrador de sitio primario de SharePoint, Juan, puede intervenir en cada flujo de trabajo, sin tener que volverlos a crear en SharePoint Designer 2010. Juan asume la propiedad de los síntomas administrativos en cada plantilla dañada. Después de hacer esto, la concesión de acceso y la publicación segura se producen en nombre de Juan en lugar de en nombre de Francisco; no ha sido necesario modificar nada más.

A continuación, se indican las acciones que pueden ser suplantadas:

  • Establecer el estado de aprobación del contenido (como propietario)

  • Crear elementos de lista (como propietario)

  • Actualizar elementos de lista (como propietario)

  • Eliminar elementos de lista (como propietario)

  • Agregar, quitar, establecer, heredar permisos de elementos de lista (como propietario)

Como administrador de SharePoint, debe considerar las posibles consecuencias para la seguridad que pueda tener la incorporación de la suplantación en flujos de trabajo en el sitio de SharePoint.

Por ejemplo, considere un modelo en el que las acciones de suplantación de usuario en el flujo de trabajo todavía pueden ejecutarse como el iniciador. Con solo tener permisos de administrador en un sitio de la colección de sitios, un usuario podría crear de forma malintencionada un flujo de trabajo para obtener derechos en el sitio web primario del sitio. Todo lo que el usuario malintencionado tendría que hacer es comenzar el ataque del flujo de trabajo y comprometer la seguridad de todo el sitio web primario del sitio.

Este riesgo exige el desarrollo de la restricción “las acciones de suplantación de usuario siempre suplantan a su asociador" en SharePoint Designer 2010. El asociador es la persona que asocia un flujo de trabajo a un sitio web o lista particular. En los flujos de trabajo declarativos de SharePoint Foundation 2010, el asociador es la misma persona que crea el flujo de trabajo, es decir, el usuario que construye el flujo de trabajo en SharePoint Designer 2010. No obstante, el asociador también puede ser alguien que asocia una plantilla de flujo de trabajo declarativo. La preocupación ahora es que el autor o asociador están obligados a aceptar la responsabilidad de todo debido al tipo Paso de suplantación de usuario, porque las credenciales del autor o asociador se están usando en la elevación. Esto requiere que el autor o asociador comprendan los flujos de trabajo que diseñan o asocian. Por lo tanto, durante la creación de un flujo de trabajo, SharePoint Designer 2010 previene al autor o asociador con un mensaje de precaución sobre el tipo Paso de suplantación de usuario, en la página de creación del flujo de trabajo.