h1. 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.

h2. 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.

h2. 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.

h2. 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). 

h2. 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.
* *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.

h2. 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 de grupos e usuários é utilizado:
|| Tipo || Nome padrão || Grupo padrão || Exemplos || Descrição ||
| Usuário comum\\ | {nome}.{sobrenome} | _ Não aplicável_\\ | joao.netto\\
carlos.silva\\
jpaulo.silva | A utilização do formato nome.sobrenome é adotada para suportar o cenário de crescimento da base de usuários. Ainda, na eventualidade de repetições começarem a surtir, prefixos podem ser usados, preferencialmente a primeira inicial do nome seguido do segundo nome e depois, pelo sobrenome (terceiro exemplo, o onde o nome da pessoa provavelmente é João Paulo da Silva).\\
NOTA: Idealmente, todos usuários devem pertencer a uma empresa. Porém, nem sempre isso é possível, pois como em projetos de software livre, muitos integrantes são elementos dispersos, sem vínculo com nenhuma instituição.\\ |
| Usuário de nível cliente padrão da entidade\\ | user.{empresa}\\ | empresa-{nome} | user.trt4\\
user.herc | Este usuário deve ser criado toda vez que um grupo de empresa é criado. Esse usuário é utilizado pela empresa cliente do projeto para acompanhar as demandas de *todos* os seus projetos.\\
NOTA 1: Para empresas que não desejar dar permissões para este usuário acompanhar todos os projetos (pois são emnpresas clientes que adotam modelo restritivo), então é importante que essas empresas não divulguem as senhas de acesso de usuário para pessoas que não devem ter esse acesso.\\
NOTA 2: A utilizaçào de prefixos nos nomes facilita o gerenciamento, permitindo filtragem de usuários. |
| Grupo de usuários de entidades\\ | empresa-{nome} | _ Não aplicável_\\ | empresa-herc\\
empresa-lm2\\
empresa-trt4 | |
| Grupo de usuários diretores de entidades\\ | empresa-{nome}-directors | | | |
| Grupo de usuários de projeto de nível inferior\\ | {projeto}-users | | | |
| Grupo de usuários de projeto de nível intermediário\\ | {projeto}-developers | | | |
| Grupo de usuários de projeto de nível superior\\ | {projeto}-administrators | | | |
| Grupo de usuários de sistema\\ | confluence-users\\
jira-users\\
fisheye-users | | | |
| Usuários de sistema\\ | jira-admin\\
confluence-admin | | | |
| | | | | |
| | | | | |
\\ \\
* *Repositório 3pup* \- [http://3layer.no-ip.info/svn/3p/3pup/trunk/]
* *Repositório 3pup-demo* \- [http://3layer.no-ip.info/svn/3p/3pup-demo/trunk/]

h1. 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, um exemplo de configuração de permissões no Confluence, que não suporta roles e sim faz a configuração por grupos. !3layer - 3pup - docs - permissoes no confluence.PNG|thumbnail!
\_\_

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].