GESTÃO DE IDENTIDADES: GERENCIANDO ACESSOS E

GESTÃO DE IDENTIDADES: GERENCIANDO ACESSOS E GARANTINDO A SEGURANÇA DA INFORMAÇÃO 1 Ane de Oliveira dos Santos Pandolfo <anesantos@terra.com.br> Alexandre Timm Vieira <xanditv@gmail.com> - Orientador Universidade Luterana do Brasil (ULBRA) Curso Superior em Tecnologia de Redes de Computadores RESUMO Campus Canoas Av. Farroupilha, 8001 Bairro São Luis CEP 92425-900 Canoas - RS 29 de novembro de 2010 Este artigo descreve a dificuldade de uma empresa em organizar a liberação de acesso para seus colaboradores. Para resolver esta dificuldade foi identificada a necessidade de implementar uma ferramenta que tenha o conceito de Gestão de Identidade, onde seja disponibilizado um usuário único para o colaborador e que este libere acesso a todas as aplicações destinadas ao cargo do colaborador, garantindo mais agilidade e segurança na liberação e revogação de acessos. Palavras-chave: Gestão de Identidade; Usuário único. ABSTRACT Title: Identity management: Ensuring access and managing information security This article describes the difficulty of organizing a company to release access to its employees. To solve this problem, was identified the need to implement a tool that has the concept of Identity Management, where a single User is made available to the employee and that him to grant access for all applications to the employee s role, ensuring more agility and security in release and revocation of access. Key-words:Identity Management; Single User. 1 INTRODUÇÃO Com a crescente dependência dos processos de negócios à tecnologia e sistemas de informação, e a consequente necessidade de acessos para colaboradores (funcionários, estagiários e terceiros), é natural que as empresas enfrentem certa dificuldade quando o assunto é gestão de acessos, afinal, é preciso se preocupar em liberar as ferramentas necessárias para que o colaborador desempenhe suas atividades de negócio, mas de modo que isso não interfira na segurança dos dados da empresa. Pesquisas realizadas em diversas empresas, demonstram que na abordagem tradicional de gestão e usuários, entre a entrada de um novo colaborador na empresa e a efetiva concessão de acessos a todo ativos computacionais, relacionados às suas atividades, decorrem até cinco dias, período no qual a empresa está arcando com os custos do colaborador sem poder contar com seu trabalho (Controle de Acesso, disponível em: https://wik.sicredi.net. Acesso em 25/09/2010). Adicionalmente, a manutenção desses acessos também oferece desafios, pois após liberado o acesso inicial, o funcionário pode ser transferido para outro departamento ou receber uma promoção e, consequentemente não exercerá a mesma função e suas permissões de acesso deverão ser alteradas. Para garantir a integridade dos dados, a empresa precisa de uma equipe pronta para identificar qualquer tipo de alteração que envolva troca de função, e que faça as devidas correções em tempo hábil para que os colaboradores não fiquem sem os acessos necessários ou, ainda, que não permaneça com os acessos correspondentes a sua função anterior, favorecendo ocorrência de fraudes. É neste cenário que a Gestão de Identidades ganha força. Neste contexto, uma solução para o 1 Artigo elaborado como Trabalho de Conclusão do Curso em Tecnologia em Redes de Computadores, submetido ao Curso de Redes de Computadores da Universidade Luterana do Brasil, Campus Canoas. 1

problema apresentado é a liberação, implícita, de todas as permissões necessárias através de um perfil de função, vinculado ao cargo do colaborador, solução conhecida como Role Based Acces Control (RBAC), onde a liberação de acessos é feita de acordo com o perfil de função do colaborador. Sendo assim, a cada alteração de cargo, obrigatoriamente o perfil será alterado e, automaticamente, os acessos antigos serão revogados e novos acessos concedidos. Especificamente, pretende-se com esse trabalho e através de um estudo de caso específico, demonstrar como é possível unir a agilidade na liberação e gestão de acessos, garantindo privacidade aos dados da empresa, através de controles mais rigorosos para o uso dos recursos de TI com base em contas únicas para usuários, solução proposta pelo Single Singn-on (SSO), onde será aplicada uma Gestão de Identidades. O objetivo principal deste projeto é liberar os acessos de acordo com o cargo dos colaboradores e, para isso, será feito um estudo identificando o que cada cargo deve acessar e, esses acessos, serão atribuídos implicitamente aos perfis denominados perfis de função. A Seção 2 descreve a fundamentação teórica do projeto. A seguir, a Seção 3 apresenta o ambiente atual da empresa que necessita de uma Gestão de Identidades e na Seção 4, são descritos os requisitos e a forma como foi implementada a Gestão de Identidades na empresa. Por fim, são apresentadas as conclusões com base em todo o trabalho realizado. 2 FUNDAMENTAÇÃO TEÓRICA Este capítulo tem por objetivo fundamentar um conjunto de recursos necessários para implementação de uma gestão de identidade, que será destinada a uma empresa de grande porte do setor financeiro. 2.1 Conceito A Gestão de Identidades é bastante ampla e pode fazer referência a administração de dados de uma empresa, de um sistema de uma rede ou de um país. No ambiente de Tecnologia da Informação, a Gestão de Identidades está voltada a estabelecer papéis e privilégios individuais aos usuários de uma rede, fornecendo aos gestores ferramentas e tecnologias que permitam o total controle aos acessos de seus subordinados. Seu objetivo principal é eliminar a administração de acessos descentralizados, definindo uma identidade digital para cada colaborador. Esta identidade disponibilizará um perfil, que definirá o papel do colaborador dentro da organização da empresa, fazendo com que apenas as tecnologias pertinentes a sua função sejam liberadas. O gerenciamento de identidades é formado por processos e tecnologias (SANTOS, 2007, p 3), que ajudam a monitorar os acessos desde a inclusão de um colaborador no sistema, conhecido como Zero-day start, ou seja, no momento de sua contratação, até a total revogação de seus acessos, momento este conhecido como Zero-day stop, que significa sua demissão. Durante todo tempo em que colaborador permanecer na empresa, ele terá um único usuário e uma única senha para todo e qualquer acesso necessário para o desempenho de sua função. Para implementar o gerenciamento de identidades, são indispensáveis o uso de Diretivas para definir os limites e padrões a serem seguidos para cumprir as normas e práticas definidas pela empresa; Processos, onde serão descritas as etapas a serem seguidas para a conclusão das tarefas, e as Tecnologias, que são as ferramentas utilizadas para atingir os objetivos de forma mais precisa, respeitando os limites das diretivas. 2.2 Identidade A forma como representamos digitalmente uma pessoa, em uma organização, é chamada de Identidade. Esta representação é feita através de um identificador único unido a outros atributos como um número de documento, nome completo, data de nascimento, etc., conforme Quadro 1. Os dados que compõem a identidade devem ser vinculados a atributos, para que possam ter vinculo com o sistema que irá utilizá-los. 2

Quadro 1- Identificador e atributos de uma Identidade Digital Atributo Valor Nome Ane Santos CPF 99900088800 Data de Nascimento 20121979 2.3 Através da autenticação o colaborador identifica-se perante o sistema computacional, de forma que este possa confiar na veracidade desta informação. Na forma mais simples, faz-se esta identificação através de um login, de usuário, e a confirmação através de uma senha. Há também outras formas de autenticação mais evoluídas, que podem inclusive dispensar a informação direta do login de usuário como biometria, Smartcards ou token (SANTOS, 2007). 2.3.1 Biometria A biometria consiste em identificar o colaborador por seus traços físicos, utilizando-se de dispositivos capazes de analisar as características físicas e comportamentais de cada usuário. A identificação pode ser através de varias formas tais como impressão digital, reconhecimento facial e análise de retina ou da Iris. Impressão Digital: Esta é uma tecnologia muito popular, normalmente atribuída ao uso de catracas, onde imagem do dedo do colaborador é capturada e transformada em um vetor e este por sua vez, atribuí o vetor a um valor. O valor é armazenado e ao receber solicitação de acesso, através de uma leitura de radiotransferência, os dados são confrontados e se forem compatíveis, o acesso será liberado (RAMOS et al., 2007, p 102). Reconhecimento Facial: A imagem do usuário é capturada e armazenada, ao receber uma solicitação de acesso, o sistema captura uma nova imagem e compara com a imagem anteriormente armazenada. Se as imagens forem iguais, o acesso é liberado. Segundo Ramos et al. (2007), esta tecnologia é utilizada pela indústria de antiterrorismo e tem grande potencial de crescimento. Retina: Para essa tecnologia é feita uma análise nas veias internas do globo ocular. Além de causar desconforto para o colaborador, a grande desvantagem deste método é que em caso de doenças a autenticação pode ser prejudicada. Por exemplo: conjuntivite (RAMOS et al., 2007, p 102). Iris: Muito semelhante a autenticação por da retina, porém, é feita uma análise na íris do globo ocular. Este método é extremamente preciso e segundo Ramos et al. (2007), já é utilizado em diversos bancos da Ásia, como sistema de autenticação em caixas eletrônicos. 2.3.2 Smartcards O smartcard é um cartão plástico, que possui um chip acoplado, onde estarão armazenadas todas as informações necessárias para efetuar a autenticação. Ele pode ser um Cartão por Contato, como um cartão de crédito, onde o usuário necessita de um leitor, onde irá inserir o cartão e ativar o chip; um Cartão sem Contato, como por exemplo, um crachá, onde o cartão é envolto por uma antena em formato de bobina e por aproximação, são emitidos sinais eletromagnéticos que ativarão o chip; ou um Cartão Híbrido, onde seu funcionamento pode ser por contato ou por aproximação e pode conter um chip único ou um chip para as duas interfaces (RAMOS et al, 2007, p 101). 2.3.3 Token Os tokens são pequenos dispositivos móveis, associados a um computador, juntamente com a identificação do colaborador (SANTOS, 2007, p 33). Esta autenticação é baseada em posse (RAMOS et al., 3

2007, p 95), uma vez que há um objeto e este é entregue ao colaborador. Estes dispositivos são utilizados para transações bancárias através da internet, onde é gerada uma nova senha a cada acesso. 2.4 Depois de efetuada a autenticação do usuário do colaborador, seus acessos devem ser controlados e a este processo damos o nome de. Este controle pode ser feito através do Mandatory Access Control (MAC), do Discretionary Access Control (DAC), do Controle de Acessos Baseado em Função (RBAC), entre outros (SANTOS, 2007, p 44-49). 2.4.1 Mandatory Access Control (MAC) O MAC permite atribuir níveis e segurança para todos os recursos da rede e atribuir um nível de isolamento para cada usuário, garantindo que eles terão acesso apenas às aplicações liberadas pela empresa. São permitidas alterações nos níveis de segurança do MAC, mas essa função é delegada apenas ao administrador e não ao dono dos recursos. Segundo SANTOS (2007), o MAC é utilizado em aplicações de alta segurança, como, por exemplo, aplicações militares. 2.4.2 Discretionary Access Control (DAC) O propósito do DAC é limitar acesso a arquivos, permitindo ao responsável pelo recurso, definir quais colaboradores devem ter acesso a ele. Segundo RAMOS (2007), apesar de correta, esta prática enfrenta alguns problemas, pois geralmente o responsável pelo recurso é um colaborador e ele pode não possuir conhecimentos técnicos, suficientes, para configurar as restrições. Outro ponto, é que em grandes ambientes acaba aumentando a complexidade no controle de acesso, devido ao grande número de usuários. 2.4.3 Role Based Acces Control (RBAC) Este método é semelhante ao DAC, porém o RBAC foi desenvolvido para que o controle de acesso seja baseado na função de cada colaborador, individualmente (SANTOS, p 27, 2007). Ele possui permissões por papéis funcionais, ou seja, as atribuições não são atribuídas ao usuário do colaborador e sim, ao cargo que este colaborador possui. 2.5 Auditoria Com o processo de auditoria, é possível atribuir aos colaboradores, individualmente, a responsabilidade por suas ações. Este processo se dá através de logs de acessos, gerados diretamente no sistema, onde os usuários e os acessos realizados por eles são identificados. 2.6 Single Singn-on (SSO) A tecnologia de Single Singn-on (SSO) tem por objetivo simplificar o processo de autenticação dos usuários, fazendo com que após o primeiro logon, os usuários possam acessar qualquer aplicação a qual tenham permissão de acesso (RAMOS et al, p 105, 2007). Uma grande desvantagem desta tecnologia é o custo elevado, o que acaba por impactar em soluções de grande porte e a principal vantagem do uso do SSO é a autenticação única, permitindo login único para N aplicações, conforme Figura 1. Dentre os tipos de SSO podemos citar o Enterprise SSO, o WAN e o Kerberos. 2.6.1 Enterprise SSO Após o colaborador autenticar seu usuário em uma aplicação, esta autenticação é armazenada em um serviço de diretório e a cada nova solicitação de acesso, para o mesmo usuário, o Enterprise identifica o pedido e a autenticação que o usuário já havia feito, é repassada para a nova solicitação e o acesso liberado. Esta tecnologia também é conhecida como Legacy (RAMOS et al, p 106, 2007) 2.6.2 Web Access Management (WAN) Esta aplicação utiliza cookies de sessão, permitindo que o colaborador autentique uma vez e acesse diversos aplicativos web (RAMOS et al, p 106, 2007). 4

2.6.3 Kerberos Este protocolo é utilizado na autenticação de usuários em redes. Ele permite autenticação de usuários em meios de comunicação inseguros, prevenindo intercepção e ataques do tipo replay (RAMOS et al, p 106, 2007). Colaborador solicita acesso Já autenticou? NÃO Aplicação solicita autenticação SIM Acessa normalmente a aplicação Solicita acesso a outra aplicação NÃO Já estava autenticado? SIM Continua acessando a aplicação FIM Figura 1 - Fluxo de autorização do SSO 3 AMBIENTE ATUAL Este projeto será desenvolvido para uma empresa que possui128 cooperativas de crédito, com mais de 1.000 pontos de atendimento, em 10 estados brasileiros e dentre essas unidades, estão distribuídos cargos de Gerente, Caixa, Estagiário e Terceiros. Independentemente do cargo, os colaboradores possuem acesso liberado a Internet, envio e recebimento de e-mail e acesso a mídias removíveis, o que ocasiona grande probabilidade de fraudes, vazamento de informações e um grande risco de contaminação por vírus. A rotina de trabalho dos colaboradores da cooperativa envolve o acesso a alguns sistemas externos, como o SISBACEN2, porém as maiorias dos sistemas utilizados são de responsabilidade da própria empresa. Dos sistemas internos, a grande maioria utiliza um repositório LDAP central onde são cadastrados os usuários, bem como grupos e entidades organizacionais aos quais estão vinculados. Os acessos aos sistemas 2 Acesso aos sistemas do Banco Central. Neste, assim como os demais sistemas externos, a empresa não administra o cadastro de usuários como um todo, mas apenas os usuários a ela delegados. 5

externos possuem usuários independentes, pois devido ao fato do sistema não ser de responsabilidade da empresa, a liberação de aceso é descentralizada, o que resulta em um usuário e senha para cada aplicação externa. 3.1 Cadastro A vida útil do colaborado, na empresa começa logo após sua última entrevista, momento este em que o gestor informa quais documentos o colaborador deve entregar para ser contratado. A partir deste momento o processo de cadastro inicia, conforme Figura 2, e só encerra quando o colaborador for desligado. Durante este processo, além do gestor imediato, serão envolvidas várias áreas e equipe, como o departamento de Recursos Humanos (RH), Segurança da Informação e o Help Desk. O gestor contrata o colaborador para uma nova vaga e informa quais documentos devem ser entregues para efetuar a contratação. Estes documentos são entregues ao RH que então efetua o cadastro do novo colaborador no sistema conhecido como Vetor RH, atribuindo ao cadastro uma matrícula, que irá receber todos os dados de seu cadastro como Nome, CPF, Empresa, Área, Cargo e Gestor. Após concluir o cadastro no RH, é enviado um e-mail para a equipe de Segurança da Informação, informando a matrícula que foi atribuída a este colaborador e solicitando os acessos básicos para que ele comece a desempenhar sua função. A equipe responsável pelo cadastro inicial utilizará a matrícula para ter acesso aos dados, já cadastrados no RH. Nesta etapa, o cadastro do colaborador será feito no Lightweight Directory Access Protocol (LDAP), através do LDAP Admin, ferramenta web, utilizada para liberar os acessos básicos para que o colaborador inicie seu trabalho (Internet, E-mail Corporativo e Intranet). No LDAP Admin serão informados os seguintes dados: Matrícula, Empresa e área, onde o colaborador exercerá suas funções. Quando esses dados forem salvos no LDAP, o cadastro do colaborador será vinculado um usuário e através dele, o colaborador terá acesso liberado para acessar o e-mail corporativo da empresa e acesso liberado à Internet. Ao finalizar o cadastro, o LDAP Admin gera uma senha provisória para o novo usuário cadastrado, mas por medida de segurança esta senha é desconsiderada, pois o profissional responsável pelo cadastro irá enviar um e-mail para o gestor informando o usuário de seu novo colaborador e é uma política interna da empresa que senhas não sejam enviadas por e-mail. No e-mail que o gestor irá receber constam as orientações sobre o cadastramento da senha inicial que deverão ser repassadas ao colaborador. O cadastro da senha inicial é feito através de contato telefônico, com a equipe de Help Desk da empresa. O próprio colaborador deve ligar, pois com base em informações pessoais, cadastradas no sistema do RH, será feita uma identificação positiva e após os dados serem informados corretamente, é fornecida uma senha provisória. De posse da senha provisória, o colaborador acessa o site denominado Troca Senha, disponibilizado pela empresa e define sua senha pessoal. Todo o processo, desde o cadastramento do colaborador no RH até seu gestor receber o usuário e as informações para cadastrar a senha, tem um tempo mínimo de 48 horas úteis. Caso ele inicie suas atividades antes deste prazo, não poderá desempenhar plenamente as funções para as quais foi contratado. 6

Usuário Recursos Humanos VetorRH Gestor Imediato/ Usuário Chave Help Desk Segurança de Informações LDAP Admin LDAP entrega documentos Cadastra Funcionário Informa Admissão Solicita cadastro LDAP Usuário Criado e Senha Criada Insere Registro Notifica criação de Usuário Solicita redefinição de senha Solicita redefinição de senha Redefine a senha Retorna Senha Temporária Retorna Senha Temporária Figura 2 - Cadastro de uma identidade para um novo colaborador Quanto aos terceiros, via de regra seu vínculo dá-se através de uma empresa, assim sendo, a relação passa a ser cível e não trabalhista, motivo pelo qual não são cadastrados no sistema de RH. O cadastro nesse caso é enviado diretamente pelo gestor do Terceiro para a área de Segurança da Informação, e a partir daí tem-se o mesmo fluxo de cadastramento do colaborador, conforme Figura 2. Toda responsabilidade, tanto na solicitação quanto na revogação de acessos, é do gestor do Terceiro. 3.2 Senha Cada colaborador possui uma senha pessoal para acesso às diversas aplicações da empresa, e esta senha pode ser alterada a qualquer momento pelo próprio colaborador, através de uma aplicação Web interna chamada Troca Senha, acesso feito por Secure Sockets Layer (SSL). Já a senha cadastrada pelo Help Desk é uma senha de controle, identificada pelo sistema como uma senha provisória, cujo único acesso permitido será ao site do Troca Senha, para definição da senha pessoal. Este funcionamento é apresentado na Figura 3, e consiste inicialmente na informação pelo usuário de login, senha atual e nova senha ; a seguir o aplicativo verifica no diretório LDAP se a senha atual informada corresponde à senha pessoal ou à senha provisória e, caso positivo, grava no diretório a nova senha. Em caso de esquecimento de senha, o colaborador deve entrar em contato novamente com o Help Desk, informar os dados solicitados pelo atendente e após receber a senha provisória, repetir o processo de cadastro de senha través do site Troca Senha. 7

Usuário TrocaSenha LDAP Solicita troca senha Solicita login, senha atual e nova senha Informa login, senha atual e nova senha Verifica senha atual com senha controle Responde Sucesso ou Falha [Sucesso] Seta nova senha como senha usuário e apaga senha controle [Sucesso] Notifica senha trocada com sucesso [Falha] Verifica senha atual com senha usuário Responde Sucesso ou Falha [Sucesso] Seta nova senha como senha usuário [Sucesso] Notifica senha trocada com sucesso [Falha] Notifica senha não pode ser trocada Figura 3 - Colaborador definindo sua senha pessoal 3.3 Acessos Após ter cadastrado sua senha inicial, o colaborador está apto a solicitar os acessos pertinentes a sua função e para esse procedimento, será utilizado o Workflow disponibilizado na Intranet da empresa, conhecido como sistema de Informações Cadastrais (InfCad). Através dele o colaborador visualiza todas as aplicações e perfis disponíveis na empresa, e efetua sua solicitação. O acesso pode ser feito pelo próprio colaborador, utilizando seu usuário e senha ou pelo gestor imediato, neste caso consultando os geridos por ele. Quando o próprio colaborador faz a solicitação, ela seguirá um fluxo serial de aprovações, passando pelo gestor imediato do colaborador, denominado Aprovador de 1º Nível. Se aprovada, passará para o 2º nível de aprovação e se for rejeitada, o fluxo será encerrado. Se a solicitação for feita pelo gestor imediato, a aprovação passa diretamente para o Aprovador de 2º Nível, que é o responsável pelo recuso ao qual está sendo solicitado o acesso, geralmente alguém da área de Desenvolvimento. Ao final do processo de aprovação e a solicitação ter sido aprovada em 1º e 2º nível, a solicitação de acesso segue para área de Segurança da Informação, através de um sistema web, denominado Service Desk e o acesso é liberado manualmente, se for reprovada, o fluxo será encerrado, conforme Figura 4. 8

Gestor da Aplicação Gestor Imediato Usuário InfCad Primeiro Aprovador Segundo Aprovador Sistema Service Desk Desenvolvimento solicita cadastro de perfil demanda desenvolvimento implementa novo perfil solicita recursos exibe recursos baseado no usuário solicita acesso a um recurso solicita permissão concede acesso solicita permissão concede acesso Provê acesso revisa acessos remove acessos revisados abre tíquetes sobre problemas informa sobre o andamento do tíquete abre tíquetes sobre problemas informa sobre o andamento do tíquete Figura 4 - Fluxo de solicitação de acesso através do Workflow Esta solicitação não tem prazo para conclusão, a liberação dos acessos adicionais, depende da disponibilidade do gestor em aprovar os acessos solicitados por seu colaborador. 3.4 Na autenticação o colaborador fornecerá suas credenciais de acesso (usuário, senha e em alguns casos, token). O sistema fará a validação dessas credenciais e, caso corretas, passará para a fase de autorização. 3.4.1 Aplicações customizadas Consistem em aplicativos desenvolvidos internamente ou de aplicativos externos que sofreram customização. Aplicações Web: A autenticação das aplicações Web dá-se através do Oracle SSO. Neste processo, ao solicitar acesso a uma aplicação, o usuário é direcionado para uma página de login da própria solução da Oracle SSO onde deve fornecer login e senha. O Oracle SSO verifica então no diretório LDAP e, estando corretas as credenciais, informa à aplicação que a autenticação foi realizada com sucesso e para qual usuário. No memento em que a aplicação fizer o direcionamento ao Oracle SSO, caso este detecte, através de um cookie já havia sido feito uma autenticação, a aplicação é informada imediatamente que a autenticação foi realizada com sucesso, sem que seja digitado novamente o login e senha. A Figura 5 demonstra em detalhes o funcionamento da autenticação com o Oracle SSO. 9

Usuário Aplicação Web Aplicação Legada Demais Aplicações Método de Conexão API PL/SQL API Java LDAP Base Usuários Sisbacen solicita acesso solicita dados solicita acesso solicita dados solicita acesso solicita dados [SQL] requisita dados [SQL] requisita dados [SQL] retorna dados [SQL] retorna dados [Java] requisita dados [Java] requisita dados [Java] retorna dados [Java] retorna dados [LDAP] requisita dados [LDAP] retorna dados [Local] requisita dados [Local] retorna dados retorna dados retorna dados retorna dados decide pela autorização decide pela autorização decide pela autorização solicita acesso retorna Sucesso ou Falha Figura 5 - Processo de de aplicações Web Aplicações Não Web: Na autenticação das aplicações não web o login e senha devem ser informados na própria aplicação, que os repassa para uma store procedure de uso geral desenvolvida em PL/SQL que faz a verificação no diretório LDAP. 3.4.2 Aplicações de Mercado As aplicações de mercado não são passíveis de customização e sua integração ao cadastro corporativo de usuários depende de sua capacidade de integração ao LDAP. A empresa possui dois serviços de diretório LDAP: o corporativo, baseado numa árvore LDAP própria hospedada em OID e OpenLDAP, e o AD, que consiste numa árvore LDAP específica. Das diversas aplicações de mercado utilizadas, destacamos algumas que ilustram o universo da empresa como um todo. Estações Windows: A autenticação das estações Windows no site central dá-se através de um domínio Microsoft, implementado sobre Active Directory. Estando logados em uma estação do domínio, diversos recursos, como impressoras e compartilhamento de rede. As estações localizadas nas filiais não fazem parte do domínio, elas possuem usuários locais. Acesso à Internet: Dá-se através de um proxy, que solicita ao browser a autenticação no momento do primeiro acesso a uma página externa. Nas estações Windows que pertencem ao domínio a autenticação dá-se através do protocolo NTLM, reaproveitando as credenciais fornecidas no login da estação e para as demais estações, o browser abre uma janela solicitando o fornecimento de login e senha e os repassa ao proxy. Em qualquer um dos casos, as credenciais estando válidas, o proxy segue para a etapa de autorização. E-mail: No site central, ma matriz, há um servidor Exchange integrado ao domínio Microsoft. No cliente de email (Outlook, Thunderbird, ou mesmo o Webmail) o usuário informa seu login e senha, que são validados pelo Exchange no AD. Já nas filiais, há um servidor Linux com o serviço de e-mail Postfix. Da mesma forma que no Exchange, o usuário informa seu login e senha no cliente de email, porém este faz a validação em um LDAP local, ao invés do AD.Em qualquer 10

dos casos, se as credenciais estiverem válidas, o acesso à caixa postal do usuário é liberado. Servidores Unix: Os servidores Unix utilizam o LDAP Corporativo para autenticação de usuários. A integração é feita através da parametrização no sistema operacional, que no caso dos servidores Linux, esta parametrização é feita em dois pontos: o o Na configuração Pluggable Authentication Modules (PAM), onde informa-se que deverá ser utilizada autenticação LDAP No arquivo /etc/ldap.conf, onde deve ser informados os parâmetros de conexão ao serviço de diretório, como hostname do servidor LDAP, base DN, filtros de pesquisa, etc. Quando um usuário tenta acessar o servidor, via console ou Secure Shell (SSH), o sistema operacional solicita login e senha e, através do PAM, valida-os contra o LDAP Corporativo. Em caso de sucesso, passa à etapa de autorização. VPN: A solução de Virtual Private Network (VPN) utilizada na empresa consiste na solução CheckPoint. O sistema de autenticação da VPN inclui, além do login e senha, a utilização de token da Vasco: trata-se de um dispositivo com dimensões de um chaveiro que é fornecido ao colaborador. Este dispositivo possui um visor de LCD que apresenta um número de seis dígitos (token) periodicamente alterado.quando o colaborador tenta conectar na VPN, são apresentados dois campos: User e Password. No primeiro o colaborador digita seu login LDAP e no segundo a senha pessoal seguida do código apresentado naquele instante no token. O servidor CheckPoint repassa essas informações para um servidor de autenticação da Vasco, que separa o token da senha pessoal (considera que os últimos 6 caracteres do campo Password são o token), verifica se o token está correto e em caso positivo, repassa o login e a senha pessoal para um servidor Radius, que por sua vez faz a validação no LDAP Corporativo. Caso esta última validação seja concluída com sucesso, o usuário será autenticado. 3.5 A autorização é um passo subsequente à autenticação e consiste em garantir que o usuário é quem diz ser (garantia dada pela autenticação), definir quais acessos ele deve ter no recurso em questão. Na empresa, a autorização é feita pela associação de usuários a grupos e entidades, associação essa denominada Perfil. Através de um perfil diz-se não apenas que o usuário X pertence ao grupo Caixa, mas também que ele pertence ao grupo Caixa na filial Y, por exemplo, o que implica em direitos de acessos diferentes do que teria se pertencesse ao grupo Caixa de outra filial. A vinculação a entidades não é utilizada por todas as aplicações: seu uso restringe-se às aplicações de negócio customizadas. Há basicamente três tipos de autorização utilizados na empresa: 3.5.1 em aplicações customizadas Consiste na autorização das aplicações desenvolvidas internamente ou que sofreram customização para a empresa. Via de regra, consiste na chamada de uma stored procedure PL/SQL desenvolvida especificamente para cada aplicação, que contém a regra de negócio específica e verifica no LDAP os acessos do usuário naquela aplicação. Caso seja relevante para a aplicação, esta stored procedure pode informar a entidade ao qual o perfil está vinculado. Adicionalmente, a stored procedure pode retornar também informações cadastrais. Apesar de não ser uma responsabilidade da etapa de autorização, essa implementação agrega uma funcionalidade muito útil às aplicações. 3.5.2 em aplicações integradas ao LDAP através de parametrizações Consiste em autorizar, através de parametrizações, aplicações que suportam integração ao LDAP. Este procedimento é feito através de uma interface de administração da aplicação, onde são definidos parâmetros de conexão (endereço IP e porta do servidor LDAP, base DN para usuários e grupos e filtros de pesquisa). Em algumas aplicações também são definidos perfis de acesso e estes vinculados a grupos do LDAP(Tivoli, disponível em http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/topic/com.ibm.tivoli. itws.doc_8.5.1.1/awsadmst.pdf/ Acesso em 15/11/2010). 11

3.5.3 em aplicações não integradas ao LDAP Algumas aplicações, apesar de terem sua autenticação integrada ao LDAP, não suportam a integração no nível de autorização. Nestes casos, é necessário realizar a autorização na própria aplicação, através de sua própria interface de administração. O LDAP é utilizado para autenticação, mas o cadastro de grupos e o vinculo dos usuários nos grupos de acesso, deve ser feito através da própria ferramenta (The Bugzilla Guide, disponível em http://www.bugzilla.org/docs/3.6/en/pdf/bugzilla-guide.pdf. Acesso em 20/11/2010). Na figura 6, é possível identificar a autenticação e a autorização das aplicações da empresa: Estações Windows Proxy Internet Servidores UNIX VPN Firewall-1 CheckPoint AD LDAP RADIUS VACMAN (Vasco) Exchange Postfix PL/SQL Oracle Oracle SSO E-mail Matriz E-mail Filial Aplicações customizadas NÃO web Aplicações web customizadas Figura 6 e 3.6 Revogação de acessos Durante o tempo em que o colaborador estiver na empresa, ele pode receber uma promoção, ser transferido de área ou até mesmo demitido. Em todos os casos, ele não pode permanecer com os acessos antigos, ou seja, seu cadastro deve voltar para a área de Segurança da Informação e esta executar as atualizações necessárias no LDAP Admin, para atualizar seu cadastro no LDAP, revogando os acessos antigos e concedendo novos ou revogando completamente os acessos. 3.6.1 Promoção A promoção geralmente ocorre dentro da mesma área, o colaborador apenas recebe um cargo hierarquicamente mais alto, se comparando o cargo anterior e com isso, ele deverá ter mais privilégios. Este processo deve iniciar no gestor do colaborador. O gestor informa ao Administrativo sobre a promoção do colaborador e este departamento efetua a alteração de cargo no sistema de RH. Após concluir o cadastro, o colaborador é orientado a solicitar seus novos acesso no InfCad e se não for possível, é envido um e-mail para a área de Segurança da Informação efetuar as alterações manualmente no LDAP Admin. Nesta alteração são removidos todos os acessos antigos e inseridos os novos acessos solicitados, conforme Figura 7. 12

Gestor Imediato Usuário Recursos Humanos InfCad Segurança de Informações LDAPAdmin LDAP Notifica promoção Solicita novos acessos ao Usuário Solicita novos acessos ao Usuário Registra novos acessos Solicita novos acessos ao Usuário Solicita novos acessos ao Usuário Valida novo cargo Configura novos acessos Notifica Gestor Registra novos acessos Notifica usuário Figura 7 - Processo de solicitação de acessos, em caso de promoção Após esta solicitação chegar para a equipe de Segurança da Informação, a atualização cadastral tem o prazo de 24 horas úteis para ser efetuada, mas é comum o colaborador perceber que está sem os acessos necessários até 15 dias após sua promoção. 3.6.2 Transferência Vários acessos da empresa são liberados de acordo com a área do colaborador, neste caso, ao ser transferido de área, mesmo permanecendo com o mesmo cargo o colaborador deve perder os acessos a área antiga e novos acessos, de acordo com a nova área, devem ser liberados e este processo também deve iniciar pelo gestor do colaborador. O gestor informa ao Administrativo sobre a transferência do colaborador, que deverá efetuar a alteração de área no sistema de RH e, após concluir o cadastro, enviar um e-mail para a área de Segurança da Informação contendo a nova matrícula e com a nova área para que os dados sejam atualizados no LDAP. Os dados são atualizados, revogando os acessos antigos e cadastrando o novo cargo. Como em um cadastro inicial, após concluir atualização cadastral, os dados do colaborador são enviados para o novo gestor e ele deve orientar o colaborador a cadastrar uma nova senha e entrar no InfCad para solicitar os acessos à sua nova área. O processo é idêntico ao cadastro de um novo colaborador, conforme Figura 2 e após a liberação da senha, o colaborador deve entrar novamente no InfCad para solicitar seus novos acessos. 3.6.3 Demissão Assim como nos casos de contratação, transferências e promoções são de responsabilidade do gestor imediato informar o RH sobre a demissão de um colaborador para que providenciem a revogação de seus acessos, porém, essa informação só chega para a equipe de Segurança da Informação após encerrarem os cálculos rescisórios e este processo pode se estender por até 15 dias. Para estes casos, o gestor pode optar por retirar os acessos através do InfCad ou informar o desligamento do colaborador diretamente à equipe de Segurança da Informação, que a partir desta informação efetua a revogação de acessos no LDAP Admin, que por sua vez irá replicar esta informação para o LDAP, conforme Figura 8. Para os casos em que o gestor solicita a revogação de acessos através do InfCad, apenas os acessos que possuem vinculo com o LDAP serão revogados, para os demais, a revogação deve ser solicitada ao responsável pela aplicação, que após receber esta solicitação, envia a solicitação de revogação para a equipe de Segurança da Informação efetuar o cancelamento dos acessos manualmente. 13

Gestor Recursos Humanos Vetor RH InfCad Segurança de Informações LDAP Admin LDAP notifica a demissão do Colaborador registra a demissão notifica a demissão do Colaborador Desabilita o usuário notifica a demissão do Colaborador Remove acessos Desabilita Usuário Registra alterações Figura 8 - Revogação de acessos no LDAP Admin 3.7 Limitações e restrições identificadas Devido ao grande crescimento da cooperativa, surgiram algumas dificuldades na manutenção e controle de acesso a ferramentas utilizadas por colaboradores, tais como: Atraso: O atraso na liberação do usuário e senha, e dos acessos iniciais, prejudica o desempenho das funções do colaborador, pois foi identificado que em alguns casos o colaborador já na empresa, mas seus acessos ainda não foram liberados. Política de Senha: Não foi identificada uma obrigatoriedade de política de senha. O LDAP Admin escolhe uma senha aleatória e esta fica exposta a um atendente do Help Desk e este procedimento vai contra o item 11.3.1 Uso de senhas, da ABNT NBR ISO/IEC 27002. Alterações Manuais: Toda e qualquer alteração manual está sujeita a falhas e há um grande risco de o colaborador perder temporariamente seus acessos ou ter mais acessos que seu cargo permite, pois não foi identificado um mapeamento de acessos, onde identifique o que cada perfil deve ter, o próprio colaborador deve solicitar os acessos de acordo com sua necessidade. Revisão de Acessos: Não foi localizado um fluxo onde o gestor revise os acessos de seus colaboradores ou terceiros, permitindo assim que recursos fiquem liberados, mesmo que o usuário não precise mais utilizá-los. Aprovadores: Não foi identificado um controle efetivo sobre os aprovadores do InfCad. Alguns fluxos possuem os aprovadores configurados no código HardCodec e para cada alteração de aprovador, é necessária uma release do InfCad. Outro ponto, é que após aprovação do Segundo Nível o acesso não é incluído automaticamente, a solicitação é encaminhada para inclusão manual e se a solicitação for feita indevidamente, não há como desistir do acesso, uma vez aprovada, a inclusão é feita e, após receber o acesso, deve ser solicitada sua exclusão, o que raramente acontece e o acesso fica liberado. Demissões: O desligamento do colaborador pode ser informado ao RH, após o afastamento do mesmo e até que sejam feitos os cálculos rescisórios, a solicitação formalizada com a área de Segurança da Informação e os acessos revogados, o colaborador permanece com todos os acessos liberados. Não se tem conhecimento de um fluxo onde todas as áreas de Tecnologia da Informação sejam informadas sobre o desligamento de um colaborador e neste caso, alguns acessos podem permanecer liberados, mesmo o colaborador estando desligado. 4 SOLUÇÃO PROPOSTA Analisando os problemas encontrados e na tentativa de resolvê-los, foi identificada a necessidade de rever os procedimentos para liberação de acesso e que para isso, seria necessário realizar várias implementações para adaptar a ferramenta as reais necessidades da empresa. Grande parte das ferramentas utilizadas, são customizadas e devido a isso, foi feito um levantamento de custo X benefícios e o tempo para execução deste projeto, com isso, chegaram a conclusão que seria mais lucrativo e teria menos impacto para 14

os negócios, contratar uma empresa especializada nesse assunto, do que alocar colaboradores da própria empresa para implementar as melhorias na ferramenta atual. Foi feita uma pesquisa de mercado e a empresa que apresentou um produto que mais se adapta a realidade da cooperativa, foi a CA Technologies. A ferramenta apresentada por eles, a CA Directory, é um diretório de base, que fornece elevados níveis de disponibilidade, escalabilidade e desempenho. Com esta ferramenta é possível criar, modificar e excluir contas, gerenciando acessos e permissões em várias aplicações, desde mainframes até aplicativos web. 4.1 CA Directory Este serviço é considerado um diretório de base, que atende às rigorosas exigências dos aplicativos de negócio, gerenciando serviços da Web, com um repositório seguro de informações de serviços com padrões baseados na detecção e pesquisa Universal Description, Discovery and Integration (UDDI) e na integração Directory Service Markup Language (DSML) para Extensible Markup Language (XML). Fornece uma base para serviços on-line na qual é possível efetuar autenticações de usuários instantaneamente, gerenciando e personalizando o trabalho. Sua replicação é em tempo real, a escalabilidade praticamente ilimitada, o roteamento e distribuição em alta velocidade. Possui integração com servidores LDAP e uma arquitetura baseada em padrões e em configurações dinâmicas. 4.2 CA Identity Manager (IM) Esta solução oferece administração de usuários delegada, ou seja, a responsabilidade pela aprovação dos acessos de um colaborador é exclusivamente de seu gestor e o auto-atendimento de usuários, sendo assim, o próprio colaborador pode solicitar seus acessos e acompanhar o processo de aprovação. Permite ainda um gerenciamento de identidades para criar, modificar e excluir contas ou acessos, com base na relação dos usuários, desde mainframes até aplicativos web. A ferramenta visa melhorar os controles de auditoria, estabelecendo um ponto central para administração de contas de usuários, desde o seu cadastro inicial, até a total revogação dos acessos. O objetivo é facilitar o Gerenciamento de acessos e habilitar processos de revisões e melhorias contínuas, que é a principal meta da implantação de controles de conformidade às regulamentações e frameworks como ISO 27001, Sarbanes-Oxley (SOX), PCI DSS, ISO 9001, COBIT e outros aplicáveis ao negócio. O CA Identity Manager contempla um Workflow, mais flexível, onde os fluxos de aprovações e os processos são implementados com mais facilidade, de forma sustentável e extensível para a conseqüente integração com novos serviços ou sistemas, pois ao longo do tempo, com o crescimento da empresa, os controles relacionados ao gerenciamento de identidades, papéis e perfis se tornam mais trabalhosos se forem executados manualmente. IDM Provision Store: Neste local foi importada a estrutura do LDAP, com as empresas e áreas da estrutura da cooperativa. Object Store: Neste local foram definidos os aprovadores e regras do Workflow, assim foi possível substituir o InfCad. User Store: Neste local foram armazenados os dados de todos os usuários da empresa. 4.2.1 CA SiteMinder (Web Access Manager) Este sistema gerencia e centraliza a autenticação e a autorização dos usuários, através de login único e centralizado. As autenticações e autorizações são baseadas em políticas de acessos a aplicações, federalização de identidades e serviços de auditoria. 4.2.2 CA R&CM (Role and Compliace Manager) Este sistema é responsável pela gestão de perfis e garante que através de conectores, as aplicações e SQL ou Oracle, serão provisionadas para o AD, Exchange, etc. Esta gestão será coerente e ampla, de acordo com as necessidades, individuais de cada colaborador. O R&CM é flexível e através dele é possível estabelecer políticas de segurança de identidades entre sistemas e automatizar processos, como geração de relatórios de acessos, atendendo as necessidades de auditorias. 15

4.2.3 PUPM (Privileged User Password Management) Este recurso utiliza o conceito cofre de senha, fornecendo segurança no acesso à contas privilegiadas, armazenando as senhas em uma base temporária para utilização única ou de acordo com a necessidade. O suporte a este recurso é disponibilizado para um grande número de servidores, aplicativos e dispositivos, em um ambiente físico ou virtual. No primeiro momento este recurso não será utilizado pela empresa, mas está disponível ma ferramenta para ser implementado a qualquer momento. 4.3 Projeto Para que a implementação do CA Identity Manager fosse feita com sucesso, o projeto foi divido em 4 partes: Planejamento, Desenvolvimento, Homologação e Produção. 4.3.1 Planejamento O primeiro passo foi identificar e corrigir os erros da estrutura atual, para que os dados inseridos no novo sistema refletissem a estrutura atual da empresa, com dados corretos. Todo esse trabalho foi feito em conjunto com várias equipes, para isto, a empresa formou um comitê composto por responsáveis pela padronização das áreas (RH), responsáveis pela organização dos perfis de função e as responsabilidades atribuídas a cada um (Padronização Organizacional), responsáveis pelo controle de acesso (Segurança da Informação) e também os responsáveis pelos testes (Gestão de Problemas). 4.4 Cadastros Todos os dados, referentes a colaboradores, constantes no RH foram exportados para uma planilha em formato CSV e esta encaminhada para a equipe de testes, que importou os dados para o IDM de homologação. Neste primeiro momento, foram feitos testes com base no ambiente atual. Como todos os testes ocorreram de forma positiva, o próximo passo foi cadastrar as novas áreas da empresa no sistema de RH e começar a implementação da liberação de acessos de acordo com o cargo dos colaboradores. O cadastramento no IDM começou com as novas áreas dos colaboradores, o qual foi feito pela equipe de cadastros, da área de Segurança da informação, diretamente no User Store. Após o cadastro das novas áreas, o departamento administrativo forneceu uma nova listagem com todos os colaboradores e suas respectivas empresas, áreas, gestores e cargos, atualizados. Os cadastros dos usuários foram, novamente, exportados do sistema do RH para uma planilha CSV e importados através de um script para o User Store. 4.4.1 Perfis Após o cadastro das novas áreas e colaboradores, foi disponibilizada a atualização dos cargos e os papéis destinados a cada cargo, determinando os acessos que devem ser atribuídos a eles. De posse destes dados, foram cadastrados os perfis no User Store e implementadas as regras que definem os papéis, conforme o exemplo do Quadro 2. O cadastro das regras garante que nas próximas solicitações, o colaborador já terá todos os acessos pertinentes a seu trabalho, liberados em uma única solicitação de perfil. Quadro 2 Exemplo de cargos e acessos permitidos Cargo E-mail Internet Controle de Ponto Seguros Consórcios Mídias Inclusão Inclusão Gerente 6 Mb Ilimitado Sim Alteração Alteração Sim Remoção Remoção Caixa 3 Mb 3 horas Consulta Consulta Consulta Não Estagiário 1 Mb 1 hora Não Não Não Não Terceiro Não Não Não Não Não Não 16

4.4.2 Aplicações As aplicações já existentes na empresa foram recadastradas no IDM e cada uma teve seu responsável cadastrado, o que faz com que a cada nova solicitação, após passar pela aprovação do 1º nível (gestor imediato), a solicitação será encaminhada diretamente para o aprovador de 2º nível correto (responsável pela aplicação), conforme Figura 9. Figura 9 Cadastro dos sponsors (responsáveis) 4.5 Homologação Após definidas e configuradas as permissões de acesso e todo o sistema aplicado em um ambiente de homologação, desenvolvido pela própria empresa, foram feitos teste em um ambiente virtual, ou seja, durante 15 dias, ao ser cadastrado um novo colaborador, o departamento de RH efetuou dois cadastros para um colaborador, um cadastro no ambiente de produção, conforme Figura 2 e outro no ambiente de homologação do Identity Manager. 4.5.1 Cadastro de Colaborador Ao contratar um novo colaborador, o próprio gestor informa os dados no IM, conforme Figura 10, que através do Workflow, serão enviados ao Sistema de RH para que a equipe aprove a inclusão no sistema. Ao aprovar a contratação, um usuário será gerado para este colaborador e enviado através do IM para seu gestor. R&CM Consulta Perfis Role Store Oracle ou SSL Provisiona para os perfis GESTOR IDM Provisioning Provisiona para o LDAP Provisioning Store Informa contração Envia dados para provisionamento Aprovadores Object Store Vetor RH Insere dados IDM Usuários User Store 17

Figura 10 Solicitando acesso inicial 4.5.2 Senha Ao receber o usuário, o gestor do colaborador deve orientar que o colaborador acesse o IM em sua máquina e informe seus dados pessoais, que será identificado como uma identificação positiva e sua senha provisória gerada. Esta senha permite que o colaborador faça o primeiro acesso a sua máquina apenas para cadastrar sua senha pessoal. No momento do cadastro da senha pessoal o sistema solicita que o colaborador preencha um formulário com algumas perguntas e respostas, conforme Figura 11. Em casos de perda de senha, não é mais necessário o contato com o Service Desk, o colaborador pode acessar o IM em qualquer máquina e responder estas perguntas, para que a senha seja gerada novamente. Este foi customizado e as perguntas definidas pela equipe de Segurança da Informação, para garantir que sejam complexas, evitando que qualquer usuário possa respondê-las e ter acesso a senha do colaborador. Figura 11 Cadastrando ou recuperando senha 4.5.3 Acessando aplicações A autenticação e autorização nas aplicações, no IM, são feitas através do SiteMinder. Como a empresa possui aplicações de mercado, com usuários diferentes, foi feita uma correlação com o CPF dos colaboradores, pois este foi o único atributo, em comum, identificado entre as identidades. Quando solicitar acesso a um recurso o colaborador estará solicitando ao SiteMinder que, por sua vez, autentica e autoriza o acesso, tanto nas aplicações customizadas, quanto de mercado. Para o colaborador todo este processo é transparente, ele vai continuar digitando seu login e senha na aplicação e, automaticamente, será direcionado para o SiteMinder. Através do CPF do colaborador, o SiteMinder identifica se o usuário possui autorização para acessar o recurso solicitado e após esta validação, se o usuário estiver autorizado, o acesso é autenticado e liberado, conforme Figura 12 e, se não estiver autorizado, retorna erro ao colaborador. O importante neste processo é que o colaborador terá um único usuário para todas as aplicações, se houver uma aplicação com usuário diferente do padrão, o SiteMinder localiza a aplicação e direciona o usuário, sem a necessidade de efetuar um novo logon. 18

COLABORADOR Solicita acesso a aplicação SiteMinder Politicas Policy Store Windows Internet E-mail Aplicações VPN UNIX Figura 12 e através do SiteMinder 4.6 Resultados dos testes Os resultados esperados nos testes da homologação era que, ao solicitar acesso às aplicações, o sistema validasse o perfil do colaborador de acordo com seu cargo e liberasse todos os acessos vinculados a sua função, porém foi identificado que em um único cargo existem várias funções, por exemplo, o cargo de Gerente, subdivide-se em Gerente de Regional e Gerente de Unidade de Atendimento, isso implica em ter o mesmo cargo com funções diferentes. Para evitar que colaboradores tenham acessos além de suas funções, foi definido que serão criados perfis básicos, identificando o que as funções possuem em comum e liberando apenas estes acessos, os demais acessos devem ser solicitados individualmente, através do Workflow, até que sejam corrigidos os cargos e criados novos perfis de acordo com cada um. 4.7 Produção Após 15 dias de testes, foi enviado um manual sobre o uso da nova ferramenta e também um comunicado informando quando o InfCad seria desabilitado e quinze dias após o envio do comunicado, foram canceladas as solicitações de novos acessos a partir do InfCad, ficando disponível apenas as solicitações através do Identity Manager (IM). 4.7.1 Acessos Para os colaboradores que já possuíam acessos liberados, não houve impacto, porém para os novos colaboradores, em alguns casos, estavam liberados apenas os acessos básicos e foi preciso solicitar os acessos adicionais através do Workflow que seguiu o seguinte fluxo. O colaborador deve requisitar o acesso através do IM e a solicitação é encaminhada para aprovação de 1º nível. Se for reprovada a solicitação é devolvida para que o colaborador verifique os comentários sobre a rejeição, finalize ou refaça sua solicitação. Se for aprovada, a solicitação é encaminhada para o aprovador de 2º nível, se este reprovar, volta a solicitação para o colaborador e se aprovar, a solicitação é finalizada e o acesso liberado, conforme Figura 13. 19

Solicita acesso no Identity Manager Aprovou? SIM Aprovou? SIM Acesso liberado Colaborador Aprovador de 1º Nível Aprovador de 2º Nível NÂO NÃO Retorna para o colaborador FIM Figura 13- Fluxo do Workflow 4.7.2 e Conforme teste executados na homologação a autorização e autenticação dos acessos, de acordo com o item 4.4.3 - Acessando aplicações, transcorreram normalmente. O colaborador solicita o acesso à aplicação e é direcionado para o SiteMinder, que por sua vez valida o CPF do colaborador e através dele identifica se o acesso está liberado ou não. Estando liberado, o acesso a aplicação é autenticado e autorizado. 5 CONCLUSÃO Com a implantação do CA Directory e a conciliação do SSO com o RBAC, foi possível resolver o principal problema da cooperativa: a gestão e o controle de acessos. Devido a grande quantidade de recursos descentralizados que acabavam por gerar um usuário para cada aplicação solicitada, sem uma gestão centralizada, a empresa perdeu o controle da liberação destes acessos, para quem estavam sendo liberados e de quem era a responsabilidade de aprovar as inclusões. Para resolver esta dificuldade foi implementado um sistema de Workflow, onde todos os colaboradores tiveram seus gestores atualizados e a cada aplicação um responsável definido, atribuindo a eles a responsabilidade de gestão e liberação de acessos. A partir da implementação desta nova ferramenta, foi possível efetuar a contratação de um colaborador e liberar seus acessos em até 24 horas após sua entrada no sistema de RH, garantindo que, ao chegar na empresa, o colaborador já tenha um usuário e seus acessos básicos liberados, para que desempenhe a função para qual foi contratado. O gestor recebeu total autonomia na gestão de seus subordinados, ficando sob sua responsabilidade a solicitação, transferência, revisão ou revogação de acessos, evitando que um colaborador tenha acesso a aplicações que não condizem com sua função ou, por outro lado, evita que este mesmo colaborador fique sem acesso, impedindo que ele execute plenamente suas atividades. Com a solução proposta pelo RBAC, foi possível atribuir aos cargos um perfil que identifica e libera os acessos de acordo com as atividades de cada colaborador, porém esse ponto necessita de um pouco mais de atenção, já que a empresa possui um cargo para uma ou mais funções. Esse problema será resolvido em outro projeto, onde será necessário um novo levantamento de todos os cargos cadastrados no RH e, posteriormente, junto com os gestores definidos os papeis de cada cargo e seus acessos, não descartando a possibilidade de cadastramento de novos cargos, para que eles se adaptem a função dos colaboradores. A autenticação e autorização das aplicações ficou por conta do SiteMinder que, através do CPF do colaborador localiza todas as aplicações vinculadas a seu usuário e, se a aplicação a qual o acesso está sendo solicitado estiver vinculada a este usuário, libera o acesso através do conceito do SSO, onde a autenticação é unificada e simplificada, sem que seja necessário informar novamente o usuário e senha. O sucesso do controle da Gestão de identidades, dá-se ao fato de a nova ferramenta utilizar um único usuário para autorizar e autenticar o acesso à aplicações facilitando a vida dos colaboradores e não colocando a TI como um empecilho, mas sim como um facilitador. Com base nos resultados obtidos e apresentados acima, é possível concluir que o objetivo do projeto foi atingido, pois agora na cooperativa e em suas unidades de atendimento, independentemente da quantidade de aplicações utilizada por seus colaboradores, é possível autenticar-se com um único usuário e senha. 20