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

Artigo
03/07/2017

Aplica-se a: SharePoint Foundation 2010, SharePoint Server 2010

Tópico modificado em: 2016-11-30

Antes de implantar fluxos de trabalho no Microsoft SharePoint Server 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
Executando fluxos de trabalho como um administrador
Configurações do fluxo de trabalho
Divulgação de informações em listas de histórico de tarefas e de fluxo de trabalho
Ataques por falsificação e violação de listas de históricos de tarefas e fluxos de trabalho
Tipo de Etapa de Representação de Usuário para fluxos de trabalho declarativos

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

A seguir algumas ações de fluxo de trabalho comuns e as responsabilidades relacionadas, que explicam a função de administradores e 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 comercial que será executada em um item do SharePoint item. Esse assembly é chamado de um cronograma de fluxo de trabalho. Eles também são responsáveis por empacotar os formulários e o assembly do fluxo de trabalho 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, segundo as exigências 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 é que fluxos de trabalhos são executados como parte da conta do sistema no SharePoint Server 2010, através de 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 Server 2010. No servidor, os fluxos de trabalho têm as mesmas permissões do 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, 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 em um fluxo de trabalho e ajudar o desenvolvedor do fluxo a reduzir qualquer preocupação com segurança.

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

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

Permissões obrigatórias 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 as permissões Editar Item iniciem manualmente um fluxo de trabalho. Isso significa que qualquer usuário autenticado do SharePoint Server 2010 na lista daqueles que têm a permissão 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 deverá ter a permissão Gerenciar Listas para iniciar o fluxo de trabalho, apenas os administradores de listas poderão iniciar um fluxo de trabalho 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 um fluxo de trabalho de descarte de documentos, onde 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 da Administração Central clicando em Gerenciamento de Aplicativos e, na seção Aplicativos Web, clicando em Gerenciar aplicativos Web. Na página Aplicativos Web, selecione o aplicativo Web que deseja configurar 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 configurações a seguir serão exibidas:

Fluxos de trabalho definidos pelo usuário
Notificações de tarefa do fluxo de trabalho

Habilitar fluxos de trabalho definidos pelo usuário

Por padrão, os fluxos de trabalho definidos pelo usuários são habilitados em 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 Server 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 de 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 que 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 as instruções do proprietário do fluxo de trabalho. Se houver uma preocupação com a divulgação de informações associadas 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 que foram atribuídos com um endereço de email SMTP correto, também podem ser atribuídos com tarefas do fluxo de trabalho. Como os usuários externos terão dificuldade em acessar o documento, o SharePoint Foundation 2010 e o SharePoint Server 2010 incluem a opçã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 habilitarem 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 incorporados no SharePoint Server 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 ações que eles executam em documentos, os itens podem divulgar informações confidenciais. Por exemplo, alguns fluxo de trabalho de aprovação de promoção podem coletar comentários sobre tarefas que 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. 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 devem 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 podem 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 têm permissões para exibir a lista do histórico em si recebem um erro de Acesso Negado quando abrem qualquer página de status que obtém dados dessa lista de histórico.

Se forem necessárias restrições mais refinadas, os desenvolvedores de fluxo de trabalho podem 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 Server 2010. As permissões por item podem afetar negativamente o desempenho e só devem ser usadas se for mesmo 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 de nível de item.

Ataques por 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 às listas. Isso significa que usuários mal-intencionados podem modificar as descrições de tarefa para dar instruções incorretas aos participantes ou orientar os participantes de clicarem em links mal-intencionados. Para alterar os resultados percebidos de um processo, os 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 e 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 por falsificação ou violação, os administradores devem determinar as vulnerabilidades existentes e restringir o acesso às colunas de uma lista (por exemplo, tornar colunas vulneráveis como descrições de tarefa somente leitura para que apenas o fluxo de trabalho possa defini-las para criação de itens), definir permissões especiais na lista ou definir permissões de nível de item nos itens de uma lista.

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

Uma vantagem importante dos fluxos de trabalho é a sua capacidade de controlar as informações do processo para garantir 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, porque a lista de histórico do fluxo de trabalho controla as informações, os usuários podem pressupor que ela pode 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 associados a ele. 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 por 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 "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 declarativo

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 de pelo iniciador do fluxo de trabalho. Declarativo significa um modelo que você usa para criar o fluxo de trabalho e definir os parâmetros para o fluxo de trabalho sem escrever código.

No SharePoint Server 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''cã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 representarem o usuário que iniciou um fluxo de trabalho quando o fluxo de trabalho é executado. Esse arranjo mantém tudo relativamente protegido no SharePoint Server 2010, mas bloqueia vários cenários nos quais um designer de fluxo de trabalho com altos níveis de permissão deseja criar um fluxo de trabalho poderoso que possa ser concluído por usuários com níveis de permissão mais baixos.

Por meio de um formulário seguro e com escopo de elevação de privilégio, ações de site podem ser automatizadas através de 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 na qual as ações existentes são ativadas para representar alguém diferente do iniciador do fluxo de trabalho.

A seguir, os 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 uma aprovação de fluxo de trabalho 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 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 e quando ele aprova a tarefa, Connie é adicionada ao grupo Designer para o site, mesmo que nem Olivier nem Connie tenham permissões de gerenciar listas no site de Joanne.
Modelos e assumir a propriedade

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 sob o nome de William — e nada mais foi alterado.

A seguir, 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 de segurança da incorporação da representação à 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 ao site 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 todo o site pai do site.

Esse risco causou o desenvolvimento da restrição "ações de representação de usuário sempre representam sua associação" no SharePoint Designer 2010. O associador é a pessoa que associa um fluxo de trabalho a uma determinada lista ou site. Nos fluxos de trabalho declarativos do SharePoint Server 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.

Partilhar via