Segurança em Projetos

Este documento centraliza as informações sobre a segurança em projetos que seguem o padrão 3PUP.

Os níveis de segurança são balizados por necessidades de negócio e também pelas características das ferramentas utilizadas nos projetos, com ênfase central nos produtos Atlassian Jira (gerência de atividades), Atlassian Confluence (wiki corporativa), Atlassian FishEye (visualizador de repositório versionado), Atlassian CrowD (autenticador e autorizador) e diretórios corporativos nos padrões mais comuns, como Active Directory e LDAP.

Política de Liberdade

Todo o fundamento de segurança em um ambiente é balizado pela política de liberdade da organização, as quais indicam qual o nível de acesso primário (ou seja, quando nada é especificado) para o conteúdo. Assim, as organizações podem ser caracterizadas como tendo políticas restritivas ou permissivas.

Em organizações norteadas por políticas restritivas, exceto explicitamente documentado, tudo é restringido.

Em organizações norteadas por políticas permissivas, exceto explicitamente documentado, tudo é permitido.

Política de Liberdade em Projetos 3PUP

A opção por um determinado tipo de política de liberdade é influenciado por diversos fatores, cada qual possuindo um peso em virtude do tipo de negócio da organização. Organizções bancárias, por exemplo, tendem a obtar por políticas restritivas, uma vez que as informações financeiras envolvidas geralmente têm impacto estratégico no negócio. Já projetos em software livre, por exemplo, geralmente possuem políticas permissivas, pois o objetivo central é disseminar a informação.

Considerando os fatores que influenciam o 3PUP, a política de liberdade adotada é a a permissiva.

Modelos de Segurança

Idealmente, a segurança em projetos pode ser aplicada com base nos papéis desempenhados pelos envolvidos. Assim, níveis diferenciados de acesso poderiam ser alocados para gerentes, diretores, gestores, estagiários, etc. Ainda, poderiam ser elencadas as áreas de atuação dos envolvidos, dando margem a gerentes financeiros, gerentes administrativos, diretores de marketing, etc. Independente ao uso vinculado de cargos e áreas, podemos asumir esses elementos apenas como sendo papéis desempennados por alguma pessoa, ou mesmo um serviço (sistema externo) que interage no projeto.

Para alcançar níveis detalhados de gerenciamento de permissões, as ferramentas devem ter suporte a modelos extremamente granulares, podendo vincular perfis, áreas e permissões em níveis elementares.

Infelizmente, esse modelo de segurança nem sempre é bem desenvolvido nas soluções de mercado, e por isso, elas acabam optando por modelos mais simples, como aqueles encontrados em diretórios corportativos, como LDAP ou Active Directory.

Nesses modelos, o conceito de papel (ou role, no jargão de TI) é substituído pela aglutinação de elementos (usuário) em conjuntos maiores, que são os grupos. Um grupo poderia ser então algo como gerentes ou gerentes_do_financeiro ou diretores_de_marketing. Ao leigo, isso soaria como conceitos iguais. Entretanto isso não é verdade.

Grupos são apenas aglutinações de usuários. Papéis ou Roles (vamos adotar esse teremo de agora em diante),  representam a vinculação entre um usuário ou grupo e sua função no sistema. Para ficar mais claro esse conceito, observe a figura abaixo:

TODO: Colocar figura com um sistema e suas operações a esquerda e a direta usuarios e grupos. No meio da figura, colocar os papeis, e fazer entao ligacao entre os elementos.

Nessa figura, fica clara a possibilidade de um mesmo usuário (ou grupo) possuir roles diferentes em sistemas diferentes. Assim, as roles resolvem problemas comuns que seriam encontrados em um sistema de segurança baseado somente em grupos e usuários, que seria a necessidade de um mesmo grupo (ou usuário) precisar desempenhar papéis diferentes em sistemas diferentes (em outras palavras, o problema seria a proliferação de grupos no mecanismo de controle, como o Active Directory, LDAP ou outra ferramenta). 

Modelos de Segurança nas Ferramentas Adotadas pelo 3PUP

Mesmo tendo noção que o modelo de segurança baseado em roles é muito mais interessante, como dito, nem todas ferramentas o suportam. Assim, é importante analisar as ferramentas adotadas no 3PUP.

• Atlassian Jira: O Jira permite um modelo híbrido e muito granular de permisões. Ele suporte o conceito de roles e também de grupos. Ainda, permite agrupar roles em níveis mais altos ainda, formando o conceito de esquemas de segurança. Assim usuários e grupos podem ser atrelados a roles diversas; cada role pode estar associada a várias operações dentro do sistema e ao final, as roles são aglutinadas em esquemas de segurança, os quais são vinculados a um projeto. Como mecanismo de extensão, o Jira ainda permite criar a chamada "segurança horizontal", que significa que uma tarefa de projeto pode ser visualizada por uma role específica, a qual pode ou não fazer parte do esquema de segurança e ser composta de grupos, usuários ou mesmo outras roles.
• Atlassian Confluence: O Confluence é menos flexível que o Jira, e permite somente o controle de acesso através de grupos ou usuários. A vantagem é que o Confluence pode reusar os grupos e usuários do Jira de forma simples e transparente.
• Atlassian FishEye: O FishEye permite o controle de segurança por grupos e usuários, e não permite compartilhar essas informações com o Jira nem com o Confluence.
• Atlassian Crowd: É um centralizador de segurança para todos os sistemas da Atlassian ou mesmo produtos externos. Ele reusa grupos e usuários de serviços como LDAP e Active Directory e permite que o Jira, Confluence e o FishEye valam-se desses usuários e grupos para definir suas permissões. Assim, toda a gerência de usuários e grupos fica no Crowd.
• JForum: É um sistema para fóruns de discussao construido em java. Possui modo hibrido para controle de usuarios, grupos. Por padrao, seus usuarios e grupos sao definidos na propria ferramenta. Mas tambem suporta a integracao de usuarios e grupos definidos na ferramenta Atlassian Crowd (o que eh interessante pra os casos onde o JForum eh instalado dentro da Wiki Confluence, por exemplo). Ja as permissoes, estas sempre sao definidas dentro da propria ferramenta JForum.
• Subversion: O subversion, ou simplesmente SVN é a ferramenta de versionamento de conteúdo padrão no modelo 3PUP. Ele é balizado por grupos e usuários, e pode compartilhar essas informações de diretórios corporativos como LDAP e Active Directory.

Usuários e Grupos Padrões

Independente do suporte da ferramenta, grupos e usuários são o denominador comum de qualquer modelo de segurança.

Após análise cuidadosa de todos os aspectos dos projetos, o seguinte modelo padrão de grupos e usuários é utilizado:

NOTA 1: A utilização de prefixos e sufixos é utilizada para facilitar o gerenciamento de usuários e grupos em bloco.

NOTA 2: Embora não mostrado, todos usuários devem, obrigatoriamente, pertencerem aos grupos padrões jira-users e confluence-users. Estes não são mostrados na tabela para evitar a poluição visual.

NOTA 3: Valors iniciados por $ (cifrão) denotam nomes de variáveis que devem ser substituídos pelo valor final adequado. Caso nomes de variáveis sejam compostos, use a sintaxe camelCase, iniciando sempre com a letra minúscula.

Usuários

Grupos

Configurações Adicionais em Ferramentas

Esta seção mostra as peculiaridades para configuração da segurança em cada uma das ferramentas adotadas pela metodologia 3PUP.

Atlassian Jira

Segurança Horizontal

Como digo, a segurança horizontal visa restringir um elemento que corresponde a uma linha de informação, quando considerarmos dados provenientes de uma tabela, por exemplo. Seria como dizer que, dado uma tabela onde todos tem acesso a ela, uma linha específica pode ou não ser mostrada a um usuário, grupo ou role específico conforme a necessidade.

Como exemplo, imagine um projeto genérico de adminsitração de ambiente, onde devem ser gerenciadas prospecções de negócio em diversos clientes. Deseja-se que cada cliente possa acompanhar as tarefas de prospecção que estão sendo desenvolvidas em sua empresa. Assim, fica claro que todas as empresas clientes devem ter acesso a este projeto genérico de administração. Entretanto, é conveniente (talvez por fins estratégicos de concorrência) que ao logarem no sistema, os clientes somente possam ver as suas prospecções, e não as dos outros clientes. Para resolver esta situação, usa-se a  chamada segurança horizontal.

A segurança horizontal permite dar acesso ao projeto para todos os usuários ao mesmo tempo que permite restringir o acesso a uma tarefa em específico para um usuário, grupo ou role particular.

No Jira, isso é implementado através do conceito de Security Levels. Um Security Level nada mais é do que  um conjunto de usuários, grupos ou roles. Diversos conjuntos desses podem ser agrupados, formando um Security Level Scheme, o qual então é ligado a um projeto em particular. Para saber mais sobre Security Levels, acesse TODO.

No 3PUP, define-se os seguintes Security Levels:

Security Level Scheme: Parceria LM2 (TODO - Revisar e finalizar)

Grupos e Permissões

O controle de acesso em projetos baseados na metodologia 3PUP é definido por roles padrões, que são ligadas aos perfis definidos nos projetos.

Na figura anexa (TODO (para marcelo.mrack de marcelo.mrack - revisar esta figura), um exemplo de configuração de permissões no Confluence, que não suporta roles e sim faz a configuração por grupos.
__

DICA: Para mais informações sobre os níveis de permissões, acesse http://www.atlassian.com/software/jira/docs/latest/project_role_management.html.