A primeira parte deste artigo, teve como tema a definição do que é Gestão de Identidades, requisitos fundamentais e processos típicos da implantação de um sistema de Gestão de Identidades e Acessos.
Agora, abordaremos sobre algumas funcionalidades adicionais, de características mais avançadas de projetos e sistemas de gestão de identidades e da interoperabilidade com Single Sing-On.
Em resumo, este artigo tem por objetivo apresentar mais informações, casos experienciados em projetos e dicas de uso sobre os seguintes tópicos:
- Perfis de Negócio (RBAC)
- Regras de Provisionamento de Perfis Padrão
- Níveis de Risco de Perfis
- Segregação de Funções
- Workflows de Aprovação Distribuídos
- Mútiplos Fatores de Autenticação (MFA)
- Single Sign-on
Perfis de Negócio (RBAC)
Uma das grandes vantagens de se implantar um sistema de GIA é a possibilidade de passar a trabalhar com Perfis de Negócio, implementando, o que é conhecido em inglês como Role Based Access Control (RBAC).
Usando Perfis de Negócio, é possível ‘empacotar’ uma grande quantidade de direitos de acesso (perfis de acesso) em múltiplos sistemas e solicitar/aprovar/revogar esse pacote em uma só ação.
Tipicamente, um Perfil de Negócio empacota os direitos de acesso necessários para desempenhar um cargo ou função dentro de uma empresa.
Não necessariamente, um Perfil de Negócio precisa conter todos os direitos necessários para todas as variações de um determinado cargo pois podem haver especificidades por localidade, departamento, empresa do grupo, entre outras.
Exemplos práticos de perfis de negócio
Por isso, é perfeitamente válido usar um Perfil de Negócio chamado “Vendedor”, que contenha todos os acessos comuns a essa função.
Portal de Autosserviço e solicitação de acessos
Já os acessos específicos para Vendedor de Varejo, Vendedor de Atacado etc. podem ser solicitados pelo Portal de Autosserviço (Reset de Senha).
Essas solicitações podem ser feitas pelo próprio vendedor, por seu gestor, pelo RH ou por outras pessoas autorizadas nos fluxos do Sistema de Gestão de Identidades e Acessos (GIA).
Outro exemplo para ganhar agilidade e reduzir erros é usar o Perfil de Negócio para os cargos mais comuns na empresa.
Em uma situação, por exemplo, em uma implantação da qual participei em uma empresa com milhares de funcionários, o perfil mais comum era o de Conferente.
Essa função, inclusive, tinha rotatividade acima da média e gerava muito trabalho manual de concessão e revogação de acessos.
Assim, mapeamos todos os direitos necessários para essa função e os empacotamos em um perfil de negócio. Com isso, simplificamos os processos, eliminamos trabalho manual e reduzimos falhas operacionais na manipulação dos acessos.
Além disso, como veremos no item sobre Regras de Provisionamento de Perfis Padrão, automatizamos a concessão dos direitos.
Dessa forma, quando um novo Conferente chega para assumir a função, todos os acessos já estão provisionados.
Para concluir, fica uma dica: adote Perfis de Negócio (RBAC) em ondas.
Comece por aqueles que trazem os ganhos mais alinhados com os objetivos do seu projeto. Por exemplo:
- Se o seu principal motivador é aumentar a segurança: comece pelos perfis que aprovam transações financeiras, perfis que têm acesso a dados sensíveis, seguindo para demais perfis com poder de aprovação em fluxos de trabalho (materiais, entrada/saída etc).
- Se o seu principal motivador é aumentar agilidade e produtividade: comece pelos perfis dos cargos que mais ocorrem na sua empresa, pelos perfis cujos cargos têm maior rotatividade, seguindo para aqueles mais propensos a gerar erros manuais.
Regras de Provisionamento de Perfis Padrão
A automação do provisionamento de perfis padrão é uma das funcionalidades que mais contribui para aumentar a agilidade, aumentar a satisfação dos usuários de TI e reduzir erros operacionais.
E a combinação das regras de provisionamento com perfis de negócio tem potencial para eliminar grande número de chamados de TI.
Em inglês, as regras que definem o provisionamento automático de perfis padrão é, normalmente, chamada de entitlement.
Embora o termo ainda seja usado de uma forma ampla e não ainda com um significado estrito quando se analisa como um sistema de Gestão de Identidades e Acessos implementa o conceito.
Para usar as regras de provisionamento de perfis padrão é necessário elaborar um mapeamento de perfis que tenha como resultado quais são os perfis de acesso e/ou perfis de negócio necessários para cada função na organização.
Por que é necessário mapear todos os cargos da empresa?
Na verdade, não é necessário mapear todas as funções e cargos da empresa. Você pode mapear apenas as funções mais alinhadas com os seus riscos organizacionais ou ações de melhoria.
Para exemplificar: você pode ter uma demanda da empresa para acelerar o provisionamento para vendedores em campo para que comecem a vender assim que são contratados.
De posse desse objetivo, você deve fazer o seguinte:
- Mapear os perfis necessários;
- Identificar quais dados cadastrais serão disparadores da concessão;
- Garantir que esses dados estão sendo recebidos das fontes de identidades (p. Ex., sistema de folha de pagamento);
- Criar as regras no sistema de GIA.
Em seguida, é só correr para o abraço 🙂
Aproveite a oportunidade para medir quanto tempo levava para o vendedor ter os acessos antes do uso das regras e depois e dar publicidade a esse ganho para as partes interessadas.
Níveis de Risco de Perfis
Uma das formas de aumentar a segurança da empresa é ter clareza sobre o nível de risco dos acessos que as pessoas possuem.
Por exemplo, um perfil que autoriza um pagamento é claramente um perfil de maior risco do que um perfil que permite digitar um pedido de compra.
A atribuição de níveis de risco aos perfis, tipicamente, é resultado de uma análise de risco com análise de impacto para o negócio no caso de uso doloso dos direitos de acesso.
A atribuição de níveis de risco aos perfis permite:
- Que perfis de maior risco sejam assim identificados pelos aprovadores quando estiverem ponderando uma solicitação;
- Que indicadores de nível de risco sejam calculados para identificar, por exemplo, contas de usuário de maior risco.
Um sistema de Gestão de Identidades e Acessos pode ser usado para tratar alguns dos riscos identificados, por exemplo, mediante o uso de segregação de funções.
Outros riscos podem ser mitigados por sistemas correlatos como, por exemplo, o uso de múltiplos fatores de autenticação para aumentar o nível de assertividade na autenticação das pessoas.
Segregação de Funções
Talvez a medida mais importante em sistemas que autorizam ou executam transações financeiras seja a segregação de funções.
Esse conceito é antigo e tem um objetivo claro: evitar que uma única pessoa execute funções que coloquem em risco a empresa ou a si mesma.
Por exemplo, não é recomendado que a mesma pessoa possa cadastrar um pedido de compra e aprovar o pagamento desse pedido no sistema.
Alguém com esses dois poderes se torna um alvo típico de fraudadores. O objetivo deles é obter acesso a essa conta para cometer fraudes sem precisar comprometer uma segunda ou terceira conta.
Implementação da Segregação de Funções
A segregação de funções começa quando a organização identifica essas situações de risco, passa quando mapeia perfis de acesso distintos para funções distintas e termina quando configura uma matriz de segregação, na qual indica os perfis que não pode conceder a uma mesma pessoa.
A organização informa essa matriz ao sistema de Gestão de Identidades e Acessos para que ele possa identificar situações de violação das regras de segregação.
Quando identificar, o sistema de GIA deve, então, interceptar esses fluxos e redirecionar para aprovação adicional, tipicamente, de um gestor de risco.
O sistema HORACIUS IAM, por exemplo, permite que o gestor de risco documente a necessidade de violação da segregação de funções e a eventual existência de controles compensatórios.
Tipicamente, pequenas unidades da empresa possuem pessoas que acumulam funções, e isso pode justificar a necessidade de violar a segregação. Além disso, a empresa utiliza limites de alçada como controles compensatórios para limitar o risco nessas situações.
A organização pode implementar o controle de segregação de funções em dois níveis:
No mesmo sistema: quando a matriz de segregação considera somente as transações executadas em um sistema.
Em múltiplos sistemas: quando a matriz de segregação considera transações que podem ser executadas em mais de um sistema, tipicamente integra o controle de segregação de funções com um modelo RBAC (Role-Based Access Control), ou controle de acesso baseado em funções e cargos.
Workflows de Aprovação Distribuídos
Na minha experiência profissional com gestão de identidades, esta é a funcionalidade que vejo mais subutilizada nas empresas.
A tendência, tanto dentro de TI quanto nas demais áreas da organização, é considerar os sistemas de informação como propriedade da área de TI, o que se estende também aos dados e informações desses sistemas.
No entanto, os verdadeiros ‘donos’ dos dados são as áreas de negócio da empresa.
São essas áreas que criam, manipulam, transmitem e removem os dados conforme suas necessidades para executar os negócios da empresa..
O papel da TI na gestão de acessos
É muito comum que a área de TI seja responsável por permitir o acesso a uma pasta de rede para uma pessoa que entra em um novo projeto.
No entanto, o ato de executar a configuração que permite o acesso é, normalmente, confundido com o poder sobre a decisão.
Vemos isso até na linguagem utilizada, pois é comum ouvir-se: “vou pedir pra TI o acesso à pasta do projeto”. Mas quem define se uma pessoa vai ter direito de acesso à pasta de um projeto é a gerente desse projeto. Por que ela precisa de TI?
Normalmente, você executa a ordem dada, uma tarefa que um sistema de Gestão de Identidades e Acessos poderia facilmente realizar, desde que a TI o tenha parametrizado.
Workflows distribuídos e a mudança cultural
Com workflows distribuídos, podemos permitir que as diferentes áreas da empresa autorizem os direitos de acesso conforme as suas necessidades sem depender de TI.
Com o provisionamento automático, os donos dos dados atribuem ou retiram os direitos conforme determinam.
Ao TI, compete a atribuição de criar e manter as parametrizações no sistema de Gestão de Identidades e Acessos que dão essa agilidade ao negócio.
Dessa maneira, um gerente de projeto pode conceder e revogar acesso a uma pasta de rede de projetos conforme as novos membros entram e saem da equipe.
Um gestor financeiro pode conceder perfis de aprovação por tempo determinado para uma pessoa cobrir as férias de outra. Tudo isso sem abrir um chamado em TI.
Durante os projetos em que participei, observei frequentemente o desconforto das áreas de negócio ao assumir esses tipos de aprovações.
Reconheço que ainda precisamos conscientizar essas áreas sobre as vantagens dos fluxos de aprovação distribuídos.
Por isso, entendo que a empresa deve tratar esse tema com especial cuidado.
O ideal é iniciar o processo com áreas de negócio que já identificaram claramente as vantagens e estão dispostas a abrir mão da “bengala” oferecida por TI.
Acreditamos que, com a evolução na facilidade de uso dos sistemas de GIA e com o aumento no número de nativos digitais nas empresas, o uso de workflows distribuídos tende a crescer.
Múltiplos Fatores de Autenticação (MFA)
Uma boa implantação de Gestão de Identidades e Acessos exige que as pessoas se autentiquem de forma eficiente e eficaz.
Com o advento de sistemas em nuvem, cada vez mais as empresas precisam conviver com ambientes híbridos, com múltiplas contas de acesso para a mesma pessoa e com diferentes requisitos de autenticação.
Uma das formas de aumentar a eficácia da autenticação e aumentar a segurança de contas com acesso a perfis de alto risco é usar mais de um fator de autenticação.
Tipicamente, essas senhas protegem as contas de acesso aos sistemas.
Essa senha, de uso pessoal e intransferível, assegura que a Ana é realmente quem diz ser para o sistema de informação que está acessando.
No entanto, terceiros podem descobrir, compartilhar, furtar, roubar, vazar ou extraviar qualquer senha.
Isso permite que outra pessoa ou robô se passe pela Ana, o que pode levar ao furto de dados, destruição de dados e realização de transações, tudo como se fosse a Ana quem estivesse realizando essas ações.
Todo esse comportamento fica registrado como se a Ana estivesse fazendo as ações fraudulentas.
Para aumentar a eficácia da autenticação, podemos usar, além da senha, mais um fator de autenticação. Isso tornará muito mais difícil comprometer a segurança da conta da Ana.
Atualmente, os seguintes fatores estão sendo usados com sucesso no mercado, com diferentes níveis de aceitação pelos usuários e diferentes objetivos:
Token via SMS
Este fator está se tornando muito popular e seu uso consiste em o sistema exigir um código após a senha. O usuário recebe esse código no seu telefone celular via mensagem de texto (SMS) e digita o código na tela de login.
Token via aplicativo no celular:
Administradores de sistemas e sistemas de internet banking estão usando mais esse fator.
Semelhante ao token via SMS, a única diferença é que um aplicativo no próprio celular gera o token com base na data e hora do aparelho.
Biometria
Este fator está usando em situações em que a presença física do usuário ocorre e/ou é obrigatória.
Leitor de impressão digital é o mais usado atualmente, mas também existem usos bem conhecidos de leitor de íris do olho, biometria da palma da mão, e de reconhecimento facial.
Você também pode usar um segundo fator de autenticação após autenticar um usuário, com o objetivo de autorizar uma transação crítica.
Um sistema de transferência eletrônica de fundos (TED), tipicamente, exige um segundo fator de autenticação antes de aprovar uma transação desse tipo, por exemplo.
Desenvolvedores de sistemas devem atentar para a possibilidade de usar esse tipo de fator de segurança em seus sitemas, uma vez que é fácil incorporar a um sistema novo e, muitas vezes, difícil de incorporar a um sistema legado.
Use uma chamada genérica de web service para se conectar a um serviço externo.
Dessa forma, você sempre fará a mesma chamada; apenas precisará alterar o servidor com o MFA no futuro, caso mude a tecnologia, o fabricante ou deseje usar outro fator de autenticação.
Single Sign-On (SSO)
Muitas vezes visto como o “Santo Graal” da autenticação de usuários, o SSO é uma solução que enfrenta cada vez menos resistência. Com o passar dos anos, ele também vem acumulando cada vez mais vantagens.
Os principais objetivos de uma implantação de SSO são:
-
Proporcionar uma boa experiência de uso dos sistemas, ao eliminar as telas de solicitação de senha quando a pessoa navega de uma aplicação para outra no mesmo computador.
-
Aumentar a segurança, ao estabelecer um nível mínimo de qualidade de autenticação para todos os sistemas da empresa. Isso é feito com o uso de protocolos de autenticação padrão de mercado, testados e aprovados por organismos internacionais.
Hoje já existem soluções bem testadas no mercado para implementar SSO em ambientes Windows, em aplicativos web e dentro da suíte de aplicativos de um mesmo fabricante.
Em geral, os maiores desafios de uma implantação de SSO surgem na integração com sistemas legados.
Esses sistemas não foram projetados para suportar esse tipo de autenticação. Ainda assim, existem soluções para esses cenários.
Uma combinação vencedora é fazer uma composição com:
- Um sistema de GIA para o provisionamento.
- Um servidor de diretório padrão LDAP.
- Um servidor de SSO com suporte a SAML, MFA e outros protocolos de autenticação de mercado.
Bem, se você chegou até aqui, agradeço pela sua atenção e espero que tenha aproveitado. Procurei transmitir minha experiência de mais de 10 anos nessa área com dicas simples e diretas que você poder aplicar no seu dia-a-dia.
Fica aqui o convite para você conhecer um pouco mais sobre o nosso sistema HORACIUS IAM
Veja como podemos auxiliá-lo a ganhar agilidade e aumentar a segurança na sua empresa.
Por fim, se você gostou desse artigo, você vai gostar de ler:
- Principais métricas para o processo de Gestão de Identidades e Acessos – IAM
- Importância da autenticação multifator (MFA) na proteção de contas online
- Principais riscos mitigados pela Gestão de Identidades e Acessos – IAM – Parte 1
