Em termos gerais, dividimos as identidades em duas grandes categorias de contas, que são as humanas (pessoais) e as não humanas.
Entre as humanas, distinguem-se as contas de funcionários internos, trabalhadores terceirizados; temporários ou prestadores; parceiros, clientes e fornecedores.
Já na categoria de identidades impessoais abrigamos todas aquelas contas que não identificam um agente humano, mas um dispositivo ou função do sistema, abrigando os quatro tipos principais, a seguir:
- Contas de sistemas ou de aplicações, criadas no processo de desenvolvimento como parte integrante da arquitetura, comumente chamadas identidades “embedded”.
- Contas de serviços (service accounts), empregadas na orquestração de transações entre elementos do processo.
- Contas de robôs (RPA).
- Identidades de máquina (contas de dispositivos), agregados de IoT.
Existem outras subclasses acessórias de identidades, como as “sponsor accounts”, contas de teste, contas de POC e contas de treinamento, as quais contém certas peculiaridades. Estas, porém, têm seu tratamento atrelado a uma esteira de Governança da Identidade abrangida de alguma forma pelas demais aqui abordadas.
RPA: O ELEMENTO COMPLICADOR
A primeira questão geral trazida para o debate sobre contas impessoais é exatamente sobre qual o tratamento adequado para estas identidades. Principalmente se considerando as exigências do modelo Zero Trust, segundo o qual o gerenciamento de identidades não admite a existência de contas soltas, desconhecidas ou independentes de políticas conscientemente praticadas.
E observando-se também os princípios de privilégio mínimo, no tocante ao espectro atendido pelos direitos de acesso, e de propriedade igualmente mínima, evitando-se as credenciais de longa duração.
Um complicador para esta questão é a recente expansão acelerada de contas impessoais através da implementação de RPAs. Se antes, as contas impessoais respondiam por só 10% do acervo de identidades em uma grande empresa, sendo que a maioria delas era representada por contas de sistema, agora, com a proliferação dos robôs, este equilíbrio se inverteu.
De tal modo que os robôs, juntamente com as demais contas impessoais, chegam hoje a representar 90% do total de identidades.
Trata-se de complicador não só numérico, mas principalmente exponencial. Enquanto as contas impessoais, em geral, são criadas para propósitos fixos e quase sempre restritos, fixos e permanentes, as contas de RPA apresentam diferencial de origem. Elas são, em vários aspectos, mais flexíveis, semelhantes às contas humanas, e têm, por exemplo, capacidade para aprender com o contexto, desenvolver novas habilidades e adquirir novas demandas de acesso.
Ainda assim, pensar numa abordagem de tratamento para contas impessoais, mesmo considerando esta nova realidade de RPAs, poderia ser menos complicado se a tarefa se limitasse a criar um modelo de governança valendo daqui para a frente.
Mas, como resolver essa questão, ou pelo menos, por onde começar, quando se pensa na balbúrdia dessas novas identidades impessoais mescladas, no mesmo ambiente, com o grande acervo de identidades legadas, projetadas para ( e em) ambientes díspares em relação aos atuais?
E identidades estas, muitas vezes, sem uma amarração planejada, muitas delas órfãs de um sponsor, ou de um owner, ou mesmo de alguma aplicação ou dispositivo, que já não se encontra operante. E mais: muitas destas identidades nem sequer se encontram inventariadas ou localizadas de forma consciente na estrutura de acesso.
Sem poder dar uma resposta única e definitiva, porque esta resposta não existe, o debate aponta que o início da caminhada pode vir a se basear numa articulação de PAM (Gerenciamento de Acessos Privilegiado) em sintonia com uma plataforma de governança e administração de identidade (IGA).
Com estes dois elementos, começam-se a se equacionar os mandamentos de privilégio mínimo necessário às finalidades específicas, claramente monitoradas por políticas de acesso, e de credenciais submetidas a prazos de duração igualmente restritos.
A tese inicial é, portanto, de que esta articulação seria capaz de garantir consciência e visibilidade para as identidades existentes e introduzir parâmetros para a sua organização em um modelo operacional racionalmente pensado.
Em outras palavras, com base nas funções dessas plataformas articuladas, as empresas podem, de fato, alicerçar o design de uma arquitetura de acesso com modelos de tratamento adequados para todas as categorias de identidades, pessoais e impessoais, passando a adaptar-se aos desígnios do Zero Trust e de suas premissas fundadoras, para resolver a equação segurança, experiência e compliance.
AUTENTICAÇÃO VIA INFRAESTRUTURA
Devido ao volume e complexidade, não é possível avançar no tratamento das identidades impessoais sem pensar em automatização, tanto quanto possível, da maior parte dos processos.
Uma vez estabelecidas as bases das políticas de privilégio e governança, parte-se para a busca de metodologias capazes de encaminhar esta automatização. O que implicará numa necessária revisão das metodologias autoritativas, bem como dos princípios norteadores da esteira de produção, acompanhamento e morte das identidades e seus respectivos direitos.
Em seu fundamento de se opor a modelos de credenciais permanentes, especialmente ás atreladas a identidades impessoais, uma das tendências da filosofia Zero Trust é a de trabalhar com a contextualização e dinamização dos fatores de autenticação.
Um bom exemplo disso é o emprego da autenticação mTLS (Mutual Transport Layer Security ), na qual as duas pontas do acesso realizam a checagem recíproca de suas premissas de legitimidade. O método é especialmente recomentado quando se pensa em computação híbrida e em fluxos de trabalho envolvendo a nuvem múltipla, mas é válido para qualquer ambiente.
O emprego de MTLS consiste em utilizar a própria infraestrutura como fator de autenticação de Serviço-a-Serviço ou Máquina a Máquina. De tal modo que uma máquina física ou virtual (ou um robô) possa ser automaticamente autenticada como sendo um elemento legítimo e identificado do ambiente. O mesmo valendo para os microsserviços que ocorrem no ambiente da nuvem.
Entre as duas pontas do acesso, cada uma das identidades se credencia diante de um sistema armazenamento de segredos que faz a intermediação da entrega de uma chave. De modo que, neste sistema, reside uma inteligência artificial disposta para conceder, ou negar, o segredo de acesso pontual para o serviço solicitado, orientando-se, obviamente, pelas normas e as premissas de privilégio embutidas no esquema político do PAM.
