Projetos de Gestão de Identidade e Acesso (IAM) voltaram ao radar 
Por William Telles
Bons tempos onde alguns programavam em Clipper ou em COBOL, e o acesso às aplicações se dava através de uma tabela dentro do BD da aplicação responsável por guardar a identificação do usuário, sua senha (criptografada por programação, usando cifra de vigenere ou outra de substituição) e o seu nível de acesso à aplicação. Bons tempos ???
Graças à GDPR, projetos de Gestão de Identidade e Acesso (IAM) voltaram ao radar de algumas organizações, mas o que poucos se aventuram a fazer é rever o caminho percorrido para se chegar (novamente) a conclusão da imperiosa necessidade de se ter um ponto central de gestão de acessos à todos os ambientes e aplicações da organização, bem como um repositório central de identidades, ou apenas, bases autoritativas.
Afinal de contas, porque ter centralidade nesta gestão? Porque não deixar cada ambiente ou aplicação gerenciar seus usuários e seus níveis de acesso dentro da aplicação? Vamos pensar (ou repensar, caso prefira) juntos um pouco sobre isto.
Um sistema de informações é composto de aplicações, bancos de dados, ambientes de infraestrutura, e pessoas! Essas pessoas possuem atribuições específicas dentro deste contexto, e cada uma delas com responsabilidades específicas também.
Um DBA, por exemplo, realiza atividades que um usuário de aplicações não precisa fazer, logo, seus níveis de acesso devem ser diferentes dentro do ambiente de TI da organização. Isso parece óbvio pra você? Pois bem, infelizmente muitas organizações simplesmente não fazem a gestão de acessos e identidades para os ambientes de desenvolvimento e homologação, ou todos os analistas de infra possuem a senha de root dos servidores, por exemplo; e aí temos um problema muito sério!
Uma questão que o IAM auxilia na solução é a gestão de acessos privilegiados, mas como fazer esta gestão quando não há uma cultura de IAM na organização? Sem essa cultura disseminada em todos os níveis hierárquicos, os profissionais responsáveis pela sustentação da operação serão tratados (ou se sentirão) naturalmente como semi-deuses, intocáveis, dispensando qualquer necessidade de manutenção de trilhas de auditoria do trabalho executado por estes profissionais. Agora reflita: vai que alguém “dropa” uma tabela em um banco de produção, e por falta de Governança de Segurança da Informação não existam sequer processos nem responsáveis definidos pela averiguação do ocorrido. Resultado: impacto na operação e, consecutivamente, impacto na percepção da brand da organização, o que possivelmente irá acarretar impacto nos resultados operacionais.
A essa altura, talvez já tenha ficado evidente que o IAM é uma disciplina de Segurança da Informação com impacto direto nas áreas comercial, financeira e administrativa. Por isso, a Gestão de Identidades e Acessos evoluiu com o passar dos anos permitindo que a qualquer momento possam ser rastreados perfis de usuário de ambientes e aplicações averiguando se existe segregação de função, por exemplo. Aliás, aqui a coisa começa a ficar interessante, pois qual a área responsável dentro da organização por estabelecer a segregação de funções para a definição de perfis de usuário? A TI? Então voltamos ao paradoxal dilema universal de colocar “o cachorro pra tomar conta da linguiça”?
Talvez um grande problema seja como integrar todos os ambientes que precisam de gestão de identidades e acessos, considerando a heterogeneidade dos ambientes de TI nas organizações e a falta de cultura organizacional voltada à governança da segurança da informação, que incide diretamente sobre as responsabilidades das diversas áreas envolvidas e/ou comprometidas com a criação e manutenção de um programa sério de IAM; e aí naturalmente vão surgir questões tipo “Como unificar as bases autoritativas de identidades, permitindo a gestão dos funcionários e terceiros simultaneamente, por exemplo?” ou “Como gerenciar todos os acessos em todos os ambientes de modo que se possa chegar à excelência de um SSO (Single Sign On)?”.
Falando em governança, alguns setores da economia são regulados por normas de conformidade, e a maioria destas normas prevê o controle dos acessos aos ambientes e aplicações da organização. Frameworks como o COBIT auxiliam nesta compreensão, tanto que em sua versão 4.1 tratava sobre o assunto apenas nos processos do grupo DS5, mas na versão 5 existem questões nos DSS5 e DSS6.
Iniciar ou retomar um projeto de IAM em uma organização é acima de tudo uma questão de visão unificada, do Advisory Board aos Analistas de TI, passando pelos Analistas de Processos e Analistas de Negócio, da importância do tema para não só um justo e perfeito controle organizacional mas como garantia de compliance também, exigindo para isso, talvez, a construção de um framework próprio de IAM para os controles que a organização pretende implementar.
Mas isso fica para um próximo artigo. Forte abraço!
