Compartilhar via

Planejar a segurança do fluxo de trabalho e o gerenciamento de usuários (SharePoint Foundation 2010)

  • Artigo

 

Aplica-se a: SharePoint Foundation 2010

Tópico modificado em: 2011-03-09

Antes de implantar fluxos de trabalho no Microsoft SharePoint Foundation 2010 para os usuários, os administradores talvez tenham preocupações com questões de segurança, como a divulgação de informações ou a elevação de privilégios. Este artigo destaca alguns aspectos do comportamento do fluxo de trabalho relacionados à segurança e levanta outras questões que os administradores e desenvolvedores de fluxo de trabalho devem considerar ao planejarem a configuração e o desenvolvimento de fluxos de trabalho.

Neste artigo:

Listar funções e responsabilidades de gerentes, administradores e desenvolvedores

Estas são algumas ações comuns de fluxo de trabalho e as responsabilidades relacionadas, que explicam a função de administradores e de desenvolvedores em fluxos de trabalho em execução.

Desenvolvedores de fluxo de trabalho

Desenvolver cronograma e modelo de fluxo de trabalho   Os desenvolvedores de fluxos de trabalho são responsáveis por codificar o assembly que contém a lógica de negócios que será executada em um item do SharePoint item. Esse assembly é chamado de cronograma de fluxo de trabalho. Eles também são responsáveis por empacotar os formulários e o assembly em um recurso ou modelo de fluxo de trabalho.

Administradores de site

Gerenciar configurações de fluxo de trabalho da Administração Central   Os administradores de site podem controlar o fluxo de trabalho em geral, como resultados de alertas de tarefa e configurações de participantes externos no site da Administração Central do SharePoint.

Recursos de Implantar Fluxo de Trabalho   Os administradores de site podem instalar recursos de fluxo de trabalho em um conjunto de sites para disponibilizá-los para associação.

Administradores de listas (qualquer um com permissões Gerenciar Lista ou Designer da Web)

Adicionar fluxos de trabalho   Os administradores de lista devem associar (adicionar) um modelo de fluxo de trabalho a uma lista ou a um tipo de conteúdo, de acordo com as necessidades comerciais da lista ou do tipo de conteúdo. Essa associação torna o modelo de fluxo de trabalho disponível para usuários finais, que podem então selecionar valores e configurações padrão.

Remover fluxos de trabalho   Os administradores de lista podem remover as associações do fluxo de trabalho de uma lista ou de um tipo de conteúdo, ou impedir a execução de novas instâncias.

Terminar um fluxo de trabalho   Se uma instância de fluxo de trabalho falhar, os administradores de lista poderão interromper a instância de um fluxo de trabalho em execução, como quando uma instância do fluxo de trabalho produz um erro ou não inicia, usando o link Termine este fluxo de trabalho na página Status do Fluxo de Trabalho. Essa ação é reservada aos administradores.

Executando fluxos de trabalho como um administrador

O conceito de segurança mais importante a se ter em mente é o de que fluxos de trabalhos são executados como parte da conta do sistema no SharePoint Foundation 2010, através das configurações de pool de aplicativos de identidade no computador do servidor e no domínio. Isso significa que os fluxos de trabalhos têm permissões de administrador dentro do SharePoint Foundation 2010. No servidor, os fluxos de trabalho têm as mesmas permissões que o pool de aplicativos, que frequentemente tem permissões de administrador. Essas permissões permitem que os fluxos de trabalho executem ações que os usuários comuns não podem executar, como encaminhar um documento a um local específico ou a uma central de registros, ou adicionar uma conta de usuário ao sistema.

Essa configuração, de que fluxos de trabalho têm permissões de administrador, não pode ser alterada. O cronograma do fluxo de trabalho (ou seja, o código do fluxo de trabalho) é responsável por detectar as ações do usuário e, com base nessas ações, continuar ou reverter as alterações, ou representar um usuário para simular suas permissões.

Ao implantar os fluxos de trabalhos, os administradores devem entender as ações que os fluxos de trabalho executarão para avaliarem os possíveis riscos associados à elevação da permissão e ajudar o desenvolvedor do fluxo de trabalho a reduzir qualquer preocupação com segurança.

Definições de configuração do fluxo de trabalho

O SharePoint Foundation 2010 tem algumas configurações que os administradores devem definir conforme suas necessidades de segurança.

Permissões necessáriass para iniciar um fluxo de trabalho

Além de impedir a elevação de permissões no código, os administradores de lista podem restringir o nível de permissão necessário para iniciar um fluxo de trabalho durante o processo de associação. Os administradores podem selecionar entre dois níveis de permissão para iniciar uma associação de fluxo de trabalho específica: Editar Item ou Gerenciar Lista.

A configuração padrão para associar um fluxo de trabalho é permitir que os usuários com permissões Editar Item iniciem manualmente um fluxo de trabalho. Isso significa que qualquer usuário autenticado do SharePoint Foundation 2010 na lista que tenha permissões Editar Item pode iniciar uma instância dessa associação de fluxo de trabalho. Se, durante a criação do fluxo de trabalho, o administrador selecionar a opção que exige que o usuário tenha permissões Gerenciar Listas para iniciar o fluxo de trabalho, apenas os administradores de listas poderão iniciar uma instância dessa associação.

Como os fluxos de trabalho são projetados para serem usados por parceiros padrão, a maioria dos fluxos de trabalho não exige a restrição às permissões Gerenciar Listas. No entanto, os administradores podem usar essa configuração para fluxos de trabalho como o de descarte de documentos, no qual o administrador quer que apenas algumas pessoas executem as ações de descarte.

Configurações da Administração Central

As configurações a seguir podem ser encontradas na página Administração Central: basta clicar em Gerenciamento de Aplicativos e, na seção Aplicativos Web, clicar em Gerenciar aplicativos Web. Na página de aplicativos Web, selecione o aplicativo Web a ser configurado e, no grupo Gerenciar da faixa de opções, clique em Configurações Gerais e selecione Fluxo de Trabalho. A página Configurações de Fluxo de Trabalho será aberta e as seguintes configurações serão exibidas:

  • Fluxos de trabalho Definidos pelo Usuário

  • Notificações da Tarefa do Fluxo de Trabalho

Habilitar fluxos de trabalho definidos pelo usuário

Por padrão, os fluxos de trabalho definidos pelo usuário são habilitados para todos os sites no aplicativo Web, conforme mostrado na seção Fluxos de Trabalho Definidos pelo Usuário da página Configurações de Fluxo de Trabalho. Quando essa opção é selecionada, os usuários podem definir fluxos de trabalho em um editor de fluxo de trabalho como o editor de fluxo de trabalho do SharePoint Designer 2010. Os usuários que definem esses fluxos de trabalho devem ter permissões Gerenciar Lista no site onde eles estão implantando o fluxo de trabalho.

Notificação de tarefa para usuários sem acesso ao site

Na página Configurações de Fluxo de Trabalho, na seção Notificações da Tarefa do Fluxo de Trabalho, é possível definir opções para enviar notificações sobre tarefas de fluxo de trabalho pendentes a usuários que não têm acesso ao site.

-
Usuários internos

No SharePoint Foundation 2010, é possível resolver os nomes de usuários internos no serviço de diretório que não são membros do site ou que não têm acesso àquela tarefa. Nesse caso, um administrador pode selecionar a opção **Alertar usuários internos que não tiverem acesso ao site quando atribuídos a uma tarefa de fluxo de trabalho?** na seção **Notificações da Tarefa do Fluxo de Trabalho** para definir se esses usuários recebem uma notificação de tarefa por email. Essa opção significa que os usuários são avisados quando lhe atribuem uma tarefa de fluxo de trabalho. Essa opção é habilitada por padrão, e a mensagem de email que os usuários recebem contêm um link no qual eles podem clicar para solicitar o acesso ao site (os administradores ainda precisam conceder o acesso). Essa mensagem de email talvez contenha informações sobre o documento. Essas informações podem incluir o título do documento e instruções do proprietário do fluxo de trabalho. Se houver uma preocupação com a divulgação de informações associada a usuários internos que não são membros do site, os administradores talvez optem por desabilitar a configuração **Alertar usuários internos que não tiverem acesso ao site quando atribuídos a uma tarefa de fluxo de trabalho?**.

  • Usuários externos

    Os usuários externos que não estão no serviço de diretório, mas aos quais foi atribuído um endereço de email SMTP correto também podem ter tarefas do fluxo de trabalho atribuídas a si. Como os usuários externos terão dificuldade em acessar o documento, o SharePoint Foundation 2010 inclui uma configuração, Permitir que usuários externos participem do fluxo de trabalho, enviando uma cópia do documento?, que permite enviar notificações de tarefa por email, com o documento anexado, aos usuários externos. Quando essa opção é habilitada, a tarefa é atribuída ao proprietário do fluxo de trabalho, e o usuário externo poderá concluir a tarefa enviando um email ao proprietário.

    A opção Permitir que usuários externos participem do fluxo de trabalho, enviando uma cópia do documento? é desabilitada por padrão. Mas essa configuração pode ser útil em situações em que a participação externa é necessária, como em aprovações de documentos comerciais que envolvem clientes externos. Os administradores que habilitam essa opção (selecione Sim) devem verificar se o cronograma do fluxo de trabalho aceita a configuração para participação externa. Por exemplo, quando uma tarefa é criada para um usuário externo, o fluxo de trabalho personalizado deve especificar o endereço de email externo na propriedade OnBehalfEmail, no objeto SPWorkflowTaskProperties usado para inicializar a tarefa). Vários fluxos de trabalho internos do SharePoint Foundation 2010 tem suporte para essa configuração.

    Os desenvolvedores de fluxos de trabalho personalizados que pretendem habilitar essa funcionalidade devem trabalhar com os administradores para determinar se há riscos de divulgação de informações em anexar o documento real a uma mensagem externa. Os administradores devem avaliar as vantagens e os riscos de se habilitar essa opção.

Divulgação de informações em listas de histórico de tarefas e fluxos de trabalho

Como tarefas e itens de lista de histórico podem conter dados sobre usuários e as ações que eles executam em documentos, os itens podem divulgar informações confidenciais. Por exemplo, um fluxo de trabalho de aprovação de promoção pode coletar comentários sobre tarefas aos quais uma organização gostaria que apenas o proprietário do fluxo de trabalho e o participante da tarefa tivessem acesso.

Listas de tarefa e de histórico são listas típicas em um site. Portanto, por padrão, todos os leitores podem visualizar tarefas e itens de histórico. Os administradores e desenvolvedores devem determinar as informações que não podem ser divulgadas e decidir se é necessário proteger itens de tarefa e de histórico criados no fluxo de trabalho.

A proteção desses itens pode ser feita de várias maneiras. Os administradores podem, por exemplo, definir permissões no nível de lista. Se a divulgação deve ser particular, ou seja, não deve estar disponível publicamente, mas para um grupo específico de pessoas, os administradores podem criar uma nova tarefa ou lista de histórico, e definir permissões para a lista que sejam dirigidas a esse grupo. Se os administradores não quiserem que ninguém veja os eventos do histórico em uma página de status do fluxo de trabalho, eles poderão remover as permissões de visualização da lista de histórico do fluxo de trabalho de onde a página de status obtém suas informações. Os usuários que não tiverem permissões para exibir a lista de histórico em si ou qualquer item da lista receberão um erro de Acesso Negado quando abrirem qualquer página de status que obtenha dados dessa lista de histórico.

Se forem necessárias restrições mais refinadas, os desenvolvedores de fluxo de trabalho poderão definir permissões por item quando criarem tarefas ou itens de histórico. A atividade CreateTask tem uma propriedade SpecialPermissions que concede apenas permissões especificadas para acessar a tarefa recém-criada. Como a atividade LogToHistoryList não tem essa propriedade, para definir permissões por item em itens da lista de histórico, os administradores devem usar o modelo de objeto no SharePoint Foundation 2010. As permissões por item podem afetar negativamente o desempenho e só devem ser usadas se for necessário.

As tarefas e os itens de histórico não precisam ser tratados da mesma maneira. Os administradores podem misturar e combinar permissões de lista e permissões em nível de item.

Ataques de falsificação e violação das listas de histórico de tarefas e fluxos de trabalho

Qualquer parceiro pode modificar tarefas ou itens do histórico se não houver restrições nessas listas. Isso significa que usuários mal-intencionados podem modificar descrições de tarefa para dar instruções incorretas aos participantes ou levá-los a clicar em links mal-intencionados. Para alterar os resultados percebidos de um processo, usuários mal-intencionados também podem adicionar eventos de histórico falsos ou imprecisos, ou até modificar eventos de histórico para torná-los falsos ou imprecisos.

Conforme detalhado anteriormente, as listas de tarefa e de histórico são listas normais em um site. Por padrão, não há nenhuma restrição de permissão em listas de tarefa ou de histórico. Para evitar os ataques de falsificação ou violação, os administradores devem determinar as vulnerabilidades existentes e restringir o acesso às colunas de uma lista (por exemplo, converter colunas vulneráveis como descrições de tarefa em somente leitura, para que apenas o fluxo de trabalho possa defini-las na criação de itens), definir permissões especiais na lista ou definir permissões em nível de item nos itens de uma lista.

Questões de segurança na lista de histórico de fluxo de trabalho

Uma vantagem importante dos fluxos de trabalho é a sua capacidade de controlar as informações do processo para fornecer visibilidade dentro do processo. A lista de histórico do fluxo de trabalho é um repositório dessas informações, onde a página de status do fluxo de trabalho pode pesquisar dados relacionados a uma instância de fluxo de trabalho e disponibilizar essas informações aos usuários. Os usuários podem ver todos os itens aos quais eles têm acesso na lista de histórico.

No entanto, como a lista de histórico do fluxo de trabalho controla as informações, os usuários podem pressupor que ela possa ser usada como uma trilha de auditoria para eventos. Não é o caso, pois o histórico de fluxo de trabalho não é um recurso de segurança. As listas de histórico são listas padrão do SharePoint usadas para armazenar eventos visíveis para qualquer usuário e sem qualquer permissão especial associada a eles. Por padrão, os usuários podem modificar e adicionar eventos caso tenham permissões de edição e adição no site. Para realizar auditorias nos eventos, use o recurso Log de Auditoria do SharePoint. Somente os administradores têm acesso a esse log, que não requer ações extras para protegê-lo contra ataques de violação.

Para proteger melhor a lista de histórico, os administradores podem restringir as permissões de edição e adição à lista, de forma que apenas os administradores da conta do sistema (por exemplo, administradores de fluxo de trabalho) e administradores de lista possam adicionar itens. Os administradores de lista devem ter permissões de adição para registrar eventos como os de "Terminar este fluxo de trabalho". Se as permissões de edição e adição forem restritas na lista de histórico, os usuários ainda vão precisar obter permissões de exibição para ver as informações de status.

Tipo de Etapa de Representação de Usuário para fluxos de trabalho declarativos

O tipo de Etapa de Representação de Usuário pode ser usado para executar seções de fluxos de trabalho declarativos pela pessoa que criou o fluxo de trabalho em vez do iniciador do fluxo de trabalho. Declarativo significa um modelo que você usa para criar o fluxo de trabalho e definir os parâmetros para ele sem escrever código.

No SharePoint Foundation 2010, fluxos de trabalho declarativos sempre são executados no contexto de usuário do iniciador de fluxo de trabalho, a menos que uma etapa de representação seja encontrada. Se uma etapa de representação for encontrada, o fluxo de trabalho declarativo será executado no contexto do associador de fluxo de trabalho. As tarefas de fluxo de trabalho padrão respeitam as permissões do SharePoint ao representar o usuário que iniciou um fluxo de trabalho quando este é executado. Esse arranjo mantém tudo relativamente protegido no SharePoint Foundation 2010, mas bloqueia vários cenários nos quais um designer de fluxo de trabalho com altos níveis de permissão queira criar um fluxo de trabalho poderoso que possa ser concluído com êxito por usuários com níveis de permissão mais baixos.

Por meio de um formulário seguro e com escopo para elevação de privilégio, ações de site podem ser automatizadas através do fluxo de trabalho. Isso reduz a carga de um administrador de site do SharePoint. A automação de um processo de alta segurança é útil em cenários de aprovação e publicação, nos quais as ações existentes são habilitadas para representar outra pessoa que não seja o iniciador do fluxo de trabalho.

Estes são cenários de exemplo que demonstram o tipo de Etapa de Representação de Usuário:

  • Publicar em uma lista segura

    Jackie bloqueou a biblioteca de documentos Páginas para a face pública do seu site do SharePoint. Ela configurou um fluxo de trabalho de aprovação que, usando o Microsoft SharePoint Designer 2010, envia conteúdo de parceiros do site para aprovação. Jackie coloca suas ações de fluxo de trabalho em uma etapa de representação para que as ações de fluxo de trabalho sempre a representem, uma administradora de site, como a autora do fluxo de trabalho.

    Quando Connie (uma colaboradora) posta um rascunho de conteúdo na biblioteca Páginas do site e tenta publicar seu artigo, essa ação inicia o fluxo de trabalho de aprovação de Jackie de forma que a postagem possa ser revisada e aprovada. As tarefas são enviadas para os aprovadores no fluxo de trabalho em nome de Connie. Após a revisão e aprovação, o sistema define o status de moderação da postagem como "Aprovado", mesmo se Connie não tiver permissão para aprovar páginas.

  • Concedendo permissões a usuários

    Joanne configurou um fluxo de trabalho no SharePoint Designer 2010 que usa uma ação de representação de usuário "Adicionar Usuário ao Grupo" para conceder permissões de Design ao seu site. Como o fluxo de trabalho usa um escopo de representação, a ação de adicionar um usuário ao grupo sempre será executada em nome de Joanne.

    O restante do fluxo de trabalho permite que os parceiros visitem o site e preencham um formulário para registrar sua solicitação de acesso a uma lista.

    Por exemplo, um usuário separado, Olivier, recebe uma tarefa quando Connie, uma usuária, faz uma solicitação; quando ele aprova a tarefa, Connie é adicionada ao grupo Designer para o site, mesmo que nem Olivier nem Connie tenham permissões Gerenciar Listas no site de Joanne.

  • Modelos e propriedade a ser assumida

    William criou vários fluxos de trabalho no SharePoint Designer 2010 e os salvou como modelos para serem reutilizados na empresa, mas ele logo deixa a empresa. Sua conta é removida, seu status de administrador é revogado e agora os fluxos de trabalho do SharePoint Designer 2010 criados por William não são concluídos devido à perda das permissões de William.

    Um administrador do site do SharePoint pai, John, pode intervir em cada fluxo de trabalho sem precisar recriá-los no SharePoint Designer 2010. John assume a propriedade dos sintomas administrativos em cada modelo com problema. Depois de fazer isso, a publicação segura e a concessão de acesso ocorrerão sob o nome de John em vez de William — e nada mais foi alterado.

Estas são ações de fluxo de trabalho que podem ser representadas:

  • Definir status de aprovação de conteúdo (como proprietário)

  • Criar item de lista (como proprietário)

  • Atualizar item de lista (como proprietário)

  • Excluir item de lista (como proprietário)

  • Adicionar/remover/definir/herdar permissões de item de lista (como proprietário)

Como um administrador do SharePoint, você deve considerar os possíveis efeitos sobre a segurança decorrentes da incorporação da representação a fluxos de trabalho no site do SharePoint. Isso se aplica a novas ações, mas também a ações existentes, como a atualização de itens de lista.

Por exemplo, considere um modelo no qual ações de representação de usuário no fluxo de trabalho ainda pudessem ser executadas como o iniciador. Se um usuário tiver permissões de administrador somente sobre um site do conjunto de sites, ele poderá criar, de forma mal-intencionada, um fluxo de trabalho para obter direitos à Web pai do site. Tudo o que ele precisaria fazer seria persuadir o administrador a carregar um arquivo para uma biblioteca de documentos no site do usuário mal-intencionado para iniciar o ataque do fluxo de trabalho e comprometer toda a Web pai do site.

Esse risco causou o desenvolvimento da restrição "ações de representação de usuário sempre representam seu associador" no SharePoint Designer 2010. O associador é a pessoa que associa um fluxo de trabalho a uma determinada lista ou Web. Nos fluxos de trabalho declarativos do SharePoint Foundation 2010, o associador e o autor do fluxo de trabalho são a mesma pessoa; ou seja, o usuário que cria o fluxo de trabalho no SharePoint Designer 2010. No entanto, o associador também pode ser qualquer um que associe um modelo de fluxo de trabalho declarativo. A preocupação agora é que o autor/associador seja forçado a aceitar a responsabilidade por qualquer coisa que ocorra por causa de um tipo de Etapa de Representação de Usuário, porque as credenciais do autor/associador estão sendo usadas na elevação. Isso requer que os autores/associadores compreendam os fluxos de trabalho que projetam ou associam. Dessa forma, durante a criação do fluxo de trabalho, o SharePoint Designer 2010 oferece uma mensagem de advertência na página de criação do fluxo de trabalho ao autor/associador sobre o tipo de Etapa de Representação de Usuário.