Não é tarefa fácil para qualquer Head de Segurança da Informação colocar para rodar controle de acesso baseado em papéis, isto é, implantar um modelo de RBAC (Role Based Access Control). As dificuldades para se alcançar esse ousado objetivo não se restringem à complexidade do modelo em si e acabam passando pela questão de Gestão de Recursos Humanos.
No mundo ideal, todos os papéis e responsabilidades da empresa são muito bem definidos e documentados. Cada um sabe exatamente o que fazer, o que esperar de seus colegas e o que seus colegas esperam de si, pois as fronteiras e as interfaces dos processos são claras. Todos os pacotes de papéis e responsabilidades estão mapeados para cargos específicos, de maneira que a Segurança da Informação consegue antecipar todas as necessidades de acesso dos colaboradores e garantir que todos tenham apenas os acessos essenciais para entregar seu trabalho.
Apesar de já ter enviado curriculum diversas vezes para o mundo ideal, nunca fui chamado para entrevista, então acabo sempre trabalhando no mundo real mesmo. Nele, os papéis e responsabilidades não são bem definidos e muito menos documentados. Normalmente temos várias pessoas que exercem funções diferentes em cargos idênticos e pessoas fazendo a mesma coisa com cargos diferentes.
Mesmo assim, é possível traçar um pareto desse problema e mapear acessos devidos, com base nos cargos, para cerca de 80% da empresa. O que precisamos é de um modelo de RBAC que lide bem com os 20% restantes, bem como uma solução simples para automatizar acessos para o que for possível para mapear.
O que apresento a seguir é um modelo razoavelmente fácil de implantar e que lança mão de um recurso que quase toda empresa tem: um AD. O conceito se aplica a qualquer solução de LDAP ou mesmo a um banco relacional, mas como o AD normalmente já está à mão e escala bem por ser um sistema distribuído, me parece ser uma boa opção.
São poucos passos a seguir para montar essa estrutura, que exigem uma boa noção de teoria de conjuntos e um bom programador.
O primeiro é estabelecer uma sincronização diária dos dados do seu sistema de RH com o AD, trazendo para o mesmo todos os atributos não-confidenciais de funcionários, tais como centro de custo, departamento, cargo, nível hierárquico, empresa do grupo a que pertence, escritório em que está alocado e vinculo com a empresa. Um VBScript ou um Powershell de poucas linhas resolve esse problema.
O segundo passo é montar grupos baseados nesses atributos. Estes grupos correspondem aos user roles que encontramos nas soluções de IDM do mercado, pois servem para agrupar usuários por critérios funcionais. Os membros destes grupos devem ser atualizados diariamente, a reboque da atualização dos atributos do AD. Alguns exemplos desses grupos:
[IDM USER CC 1001] – Colaboradores com atributo departmentNumber valendo 1001 e, portanto, pertencentes a esse centro de custo
[IDM USER CC 1002] – Colaboradores com atributo departmentNumber valendo 1002 e, portanto, pertencentes a esse centro de custo
[IDM USER NIVEL GERENTE] – Colaboradores com nível gerencial
[IDM USER NIVEL COLABORADOR] – Colaboradores com nível de analista
[IDM USER VINCULO FUNCIONARIO] – Funcionários
[IDM USER VINCULO TERCEIRO] – Terceiros
[IDM USER TODOS] – Todos os colaboradores da empresa
O terceiro passo é criar grupos para as aplicações cujo acesso se deseja controlar. Para cada aplicação e cada perfil de acesso, são necessários três grupos distintos que corresponderiam aos application roles das soluções de IDM. O primeiro é o grupo AUTO, destinado aos acessos que o colaborador deve receber automaticamente em função dos seus atributos no RH. O segundo, seria o grupo MANUAL, destinado aos acessos adicionais, concedidos mediante alguma autorização formal. O terceiro seria o grupo BLOQUEIO, destinado aos acessos que devem ser negados apesar dos atributos de RH indicarem que deveriam ser concedidos. Para uma aplicação fictícia chamada XPTO, com perfis de USUARIO e ADMINISTRADOR, teríamos os seguintes grupos:
[IDM APPL AUTO XPTO ADMIN]
[IDM APPL MANUAL XPTO ADMIN]
[IDM APPL BLOQUEIO XPTO ADMIN]
[IDM APPL AUTO XPTO USUARIOS]
[IDM APPL MANUAL XPTO USUARIOS]
[IDM APPL BLOQUEIO XPTO USUARIOS]
O quarto passo é ligar pessoas a aplicações incluindo grupos de usuários (IDM USER …) dentro dos grupos de aplicação de acesso automático (IDM APPL AUTO), incluindo pessoas e grupos de usuários dentro dos grupos de bloqueio (IDM APPL BLOQUEIO) e apenas pessoas nos grupos de acesso manual (IDM APPL MANUAL). O esquema fica assim:
A última peça do quebra cabeça é como calcular quem de fato deve ter acesso ao recurso desejado. A lógica geral é buscar recursivamente as pessoas no grupo AUTO, MANUAL e BLOQUEIO e dar acesso para as pessoas que aparecem em AUTO ou em MANUAL e ao mesmo tempo não aparecem em BLOQUEIO.
Imagine o seguinte cenário: Aplicação XPTO com os perfis de USUARIO e ADMINISTRADOR. Todos os colaboradores da empresa devem ter acesso exceto os terceiros. Os funcionários do centro de custo 1234 devem ser administradores da aplicação. Adicionalmente o colaborador Ticiano Benetti deve ter acesso de administrador por estar fazendo um estágio na área do centro de custo 1234. O colaborador João Ninguém, apesar de ser do centro de custo 1234, não deve ser administrador, pois está temporariamente alocado em um projeto específico.
Este cenário, com exceções para todos os lados, normalmente é difícil de montar dentro de um RBAC, mas no modelo proposto é bem intuitivo e fica assim:
Esse modelo me parece suficientemente robusto, pois os grupos do tipo AUTO endereçam os 80% nos quais o RBAC pode ser aplicado; os grupos do tipo MANUAL e BLOQUEIO servem para implantar as exceções e atender aos 20% que precisam de acessos fora do que o RBAC puro selecionaria; e todo e qualquer pedido de acesso feito ao time operacional da segurança fica fácil de atender, utilizando apenas os grupos MANUAL e BLOQUEIO.
Talvez a maior vantagem desse modelo seja a desoneração da revisão de acesso. Para sistemas integrados nesse modelo só precisamos fazer revisão dos acessos contidos nos grupos MANUAL e BLOQUEIO. Isso significa eliminar 80% do overhead do Security Officer em ficar gerando relatórios de acesso e batendo com os gestores e donos de sistema quem mantém e quem perde perfil.
É claro que ainda faltam os plugins para ligar esse cálculo de acesso aos sistemas em si e o esquema de reagir rápido a contratações e demissões. Mas estes são problemas técnicos, muito menos complexos de resolver do que a arquitetura de acesso para suportar exceções. Eu tenho trabalhado nesse modelo há algum tempo e ele tem me ajudado muito. Espero que ajude vocês.
Um abraço e até o próximo post!
Artigo publicado originalmente em Blog Ticiano Benetti
