IAM | Identity and Access Management
Por Marcio Roberto Ramirez
Contratamos um funcionário. Aqui começam os procedimentos de segurança da informação nas empresas.
Na verdade, até antes, para alguns tipos de empresa, por exemplo: empresas onde seu serviço fim é ou tem a ver com serviços de segurança ou que detém algum tipo de relação com a credibilidade no serviço prestado. Assim, mesmo antes de contratar é necessário verificar antecedentes criminais do candidato, etc. Mas o foco do assunto aqui é manter a segurança da informação para quem já está dentro do domínio da empresa, e no âmbito de acesso aos recursos computacionais, na forma eletrônica.
Assim, na disciplina do domínio: Controle de Acesso do capítulo do CBK (Common Body of Knowledge) da Segurança da Informação, devemos saber quais usuários podem acessar quais recursos, quais operações este usuário pode desempenhar e controlar, e monitorar seu uso para verificar se os controles de segurança estão corretos.
Se temos um processo bem estabelecido de segurança na empresa, onde identificamos o que estamos protegendo, qual a criticidade da informação, separação por grupos de acesso, domínios, e níveis de acesso por grupos e individualmente, apoiados em uma Política de Segurança bem estabelecida e conhecida, podemos então segregar o usuário contratado onde ele deve estar, e logicamente, os sistemas da empresa possuem métodos de autenticação e autorização de acesso que irão deter e guiar este usuário para as funções corretas, protegendo a informação de acesso indevido.
Bem, isto é o que deveria ocorrer e de forma única na empresa. Mas geralmente os sistemas das empresas são independentes, cada um possui o seu mecanismo de autenticação e autorização com o seu cadastro de usuário local. Sendo assim, o cadastramento do novo funcionário é realizado em cada sistema que ele terá acesso, tendo múltiplos cadastros na empresa. Isto já é o primeiro passo da falta de controle e possibilidade de brechas de segurança, pois não permitem a identificação única desta pessoa, e não possibilitam mecanismos de rastreabilidade do acesso.
Na maioria das empresas, a rede de computadores é gerenciada pelo Microsoft Active Directory (AD), num sistema hierárquico de domínios e subdomínios, ou mesmo na arquitetura de floresta, onde cada domínio representa um campo desta floresta, mas de forma interligada.
O AD, permite a criação de Políticas de acesso aos computadores por usuários, com a criação de grupos, níveis de acesso, horário permitido e proibido, tipos de mecanismo de autenticação nas estações, podendo ser até com Certificados Digitais X.509v3 em SmartCards ou Tokens Criptográficos, incrementando um duplo fator de autenticação.
Então bastaria cadastrarmos este novo usuário no AD, definirmos ele no grupo e seus níveis de segurança, e pronto. O problema é que o AD vai no limite do Windows residente nas estações de trabalho e não dos demais sistemas como ERP e outros. Embora possa ser integrado com chamadas programáticas ao AD, sistemas diversos como ERP e outros dependem desta implementação, e muitos podem não conter; ou ainda precisam implementar o mecanismo de Login da sua forma; realizando a chamada ao AD por dentro, mudando a experiência de uso do usuário para cada aplicação acessada, e muitos não possuem mecanismos de autenticação fortes como Certificado Digital, apenas usuário e senha, restringindo assim o fator de segurança a um nível só.
A solução para este problema é a adoção de mecanismos de acesso baseados em Single Sign On (SSO), mas, de uma forma mais interoperável, onde cada aplicação não necessita do cadastro local do usuário, e nem de acesso ao AD para a obtenção das autorizações de que o usuário possui, mas confia na credencial de acesso obtida pelo SSO. Mas para tal, as aplicações devem repassar o gerenciamento de usuários à uma aplicação centralizada, que possa gerenciar a identidade do usuário de forma unificada, e nesta, definirmos o nível de direito de acesso por aplicação, e ainda, por funcionalidade. E, para não voltarmos ao problema de diversos cadastros; e como não iremos mudar o Windows das estações; temos que ter integração com o AD.
O SSO, deve implementar o Login com diversos tipos de mecanismos de autenticação, como: usuário e senha, Certificado Digital, Certificado Digital com Chaves Privadas residentes em SmartCards ou Tokens, OTP, Biometria, e outros, de acordo com o nível de acesso requerido pela aplicação, ou melhor, pelo critério definido na Política de Segurança para esta aplicação. Assim, o gerenciamento passa a ser do Security Officer da empresa, e de forma centralizada, e não mais definido e restringido pela aplicação.
O usuário terá uma experiência única de Login para todas as aplicações acessadas na empresa, e as aplicações receberão do SSO a credencial de acesso autenticada para este usuário e com os direitos de autorização de acesso por funcionalidade.
Como extrapolamos a funcionalidade do SSO para conhecer a identidade do usuário e controlar a permissão da autenticação e autorização, ele passa a se chamar de IDP (Identity Provider), ou traduzindo na forma literal, Provedor de Identidades. Sim, este é o conceito: um serviço que provê a identidade de uma pessoa, de forma normalizada e unificada, não importando o tipo de credencial apresentada para a autenticação, e retornando um token de acesso contendo a permissão de acesso e os níveis de autorização.
Atualmente podemos observar IDPs como o Microsoft Azure, que implementam o protocolo SAML (Security Assertion Markup Language) como método de troca de tokens de acesso, contendo a credencial de acesso do usuário na chamada e a permissão e autorização na resposta. E outros como o OpenID do Google, que conceitualmente funcionam da mesma forma.
O conceito de Gerenciamento de Identidades de acesso ou IAM (Identity and Access Management); aplicação centralizada de usuários com a gestão de direitos de acesso e integrado com o IDP; permite a operação das regras e políticas de segurança definidas pelo Security Officer de forma a termos um menor custo na operação, com um TCO interessante, quando comparado com os custos da operação de controle atuais, e com a vantagem de colocar a empresa em um patamar de controle adequado do gerenciamento de riscos de segurança.
Venho acompanhando este cenário de IDP e IAM desde 2007 com o padrão WS-Trust e SAML da OASIS, e atualmente diversas soluções estão surgindo neste cenário, como o IDM (Identity Management) da Oracle, IBM-IAM da IBM, OpenIDM (open source), WS02 Identity Server da WSO2, NetIQ IDM da NetIQ, e outras, incluindo nacionais. Todas necessitam de projetos de integração e customização com a realidade de cada empresa, e principalmente a customização nas aplicações das empresas para incorporarem as chamadas ao IDP e interpretação do token de resposta.
Indo um pouco mais além, quando aplicamos um IAM com regras de autenticação no Login com credenciais de acesso por Certificados Digitais X.509v3, e ainda mais, se este necessitar ser um Certificado Digital ICP-Brasil, temos um outro desafio ainda não coberto pela maioria das soluções, mas que podem ser aplicadas.
O ponto crucial são as questões: necessidade de gerenciamento do ciclo de vida dos Certificados Digitais entregues aos usuários, incluindo a solicitação, emissão e entrega, e posterior revogação (no caso de dispensa do funcionário), e ainda se houver a entrega de SmartCards ou Tokens, a gestão também sobre estes dispositivos, pois tanto o Certificado quanto eles, possuem tempo útil de vida, devendo então, haver uma gestão sobre isso.
Se for aplicado ainda, Política de Segurança com o sigilo de informações confidenciais e restritas; aliás este é um assunto bastante interessante e pouco utilizado nas empresas que abordarei em outro artigo; temos então que aumentar gerenciamento de ativos, incluindo a gestão sobre as chaves dos usuários utilizadas, promovendo procedimentos de backup em armazenamento seguro, ou até mesmo a aplicação de HSM (Hardware Secure Module) para isso. Mas, o mais importante é saber que a chave é da pessoa, que está no dispositivo ativo e válido, não foi perdida ou furtada, ainda é válida e possui backup se for o caso.
Notas:
Microsoft Active Directory e Microsoft Azure são marcas registradas da Microsoft.
OpenID é marca registrada do Google.
SAML: Protocolo definido pela OASIS Standard, 1 Dec 2004
Oracle IDM é marca registrada da Oracle,
WS02 Identity Server é marca registrada da WSO2,
NetIQ IDM é marca registrada da NetIQ
*Marcio Roberto Ramirez
Consultor Sr em PKI e Desenvolvimento de Sistemas de Segurança. Com pós-graduação em informática no Mackenzie, desenvolvendo produtos e soluções de PKI, Autoridade Certificadora e protocolos de segurança desde 1996.
