Por que gestão de identidade é tão importante no momento?

Às vezes, somos nossos piores inimigos. Uma pesquisa realizada pela Microsoft, em 2007, muito divulgada, mostrou que um funcionário habitual precisa decorar ao menos sete logins. Agora estamos acumulando aplicativos SaaS e móveis enquanto concedemos status de confiança e acesso à rede a parceiros, sem conhecer direito sua segurança – e apenas perguntamos a um CIO, cuja organização enfrentou brechas, como o problema foi resolvido. Ainda assim, apenas 27% dos 438 profissionais de tecnologia do negócio entrevistados pela recente pesquisa Identity Management, da InformationWeek EUA, disseram que as empresas têm o que consideramos implantações abrangentes de Identity Management (IdM), definidos como programas internos de IdM, além de uso interdisciplinar para parceiros e fornecedores externos. O aumento no número de adoções foi minúsculo desde a última entrevista sobre IdM, em 2009.

Se feita corretamente, a implantação de gerenciamento de identidade emprega uma mistura de software e processos para alcançar um único e simples objetivo: garantir que as pessoas sejam quem dizem ser e, então, dar a cada uma o nível adequado de acesso. O IdM engloba cinco pontos essenciais: autenticação, provisionamento e desaprovisionamento de usuário, mapa de função, configuração de identidade de serviços de diretório e armazenamento, e auditoria e relatório. Esses pontos, mais assinatura criptografada e outras tecnologias de permissão, determinam inteoperabilidade segura entre funcionários, clientes e parceiros.

Em 2009, o foco estava na federação interdisciplinar com fornecedores externos, em que cada negócio age tanto como emissor quanto como consumidor de credenciais de identidade; o objetivo era permitir acesso por meio de sign-in único a todos os membros da federação. Hoje, empresas como Facebook e Twitter avançam nesse conceito, adotando o método ?bring your own identity? (traga sua própria identidade) ou BYOI, de que falarei mais para frente.

Fornecedores estão, finalmente, se comprometendo com padrões, como OAuth. É empolgante. Mas, no final das contas, ainda é preciso verificar se quem acessa dados sigilosos realmente é quem diz ser. E isso ainda é um desafio.

Vale a pena

O desejo pelo gerenciamento de identidade existe desde que se começou a usar controle de acesso e diretório baseado em função. A ideia de um único ponto em que se define o usuário, sua função, a que ele tem acesso, a combinação de nome de usuário e senha faz muito sentido, até mesmo para o executivo menos tecnológico.

Todo mundo gosta de ter uma forma rápida e certeira de restringir o acesso caso um funcionário deixe a empresa para trabalhar na concorrência. E, em teoria, com esse repositório local, sempre que a TI precisar de um novo aplicativo, a equipe de desenvolvimento pode, simplesmente, acessar o diretório de armazenamento e usar o sistema de IdM para oferecer autenticação e autorização. Pronto.

Mas temos um problema: o mundo é uma bagunça. O ROI do gerenciamento de identidade é diretamente dependente da rigidez com que a área de TI integra aplicativos e serviços com o programa de IdM. Cada ponto do software que não estiver completamente conectado, ou se estiver apenas parcialmente, requer um conjunto único de processos de autenticação e autorização, e isso significa customização cara. No final, acaba tendo com lacunas.

Como é muito difícil centralizar tudo em apenas um sistema de gerenciamento de identidade, empresas buscam produtos da federação que estejam no topo dos sistemas IdM e prometam fornecer integração. Por exemplo, com a federação é possível (teoricamente) usar o Active Directory para login em sistemas operacionais, mas implantar Oracle IdM para bancos de dados.

O problema aqui é que gestão de identidade precisa ir além de logins internos e identidades. Muitas empresas permitem que fornecedores e terceiros acessem dados sigilosos. No entanto, quando se tentar ligar tecnologia da federação com um terceiro, você pode esquecer a possibilidade de ter produtos IdM se comunicando na mesma língua, devido a ausência de padrões amplamente adotados.

Para piorar a situação, a maioria dos sistemas de rede e aplicativos ainda não consegue se comunicar com produtor IdM e ponto: em nossa pesquisa, apenas 18% daqueles que implementaram autenticação de aplicativos cloud/SaaS no programa de IdM disseram que esses aplicativos se integram com os diretórios em uso; 49% tiveram gastos com desenvolvimento customizado para integrar com fornecedores de SaaS, e 44% fornecem acesso a usuário e lidam com senhas manualmente.

Mesmo com tanta frustração, a federação não está morta – apenas hibernando. Nos próximos dois anos, esperamos ver alguns jogadores fortes em campo, como Ping Identity, Microsoft e Oracle (Sun) aderindo aos padrões e se destacando no mercado.

Enquanto isso, entre os entrevistados ignorando completamente IdM, 70% disseram que é porque não veem necessidade. Nenhum outro fator sequer atingiu dois dígitos. Isso sugere que fornecedores ocupados com renovações, redefinição de preços e renomeação de produtos e insistindo em facilidade de uso estão perdendo tempo. Apenas 5% citaram complexidade e 4% o alto custo.

Nossa mensagem para esses 70%: vocês estão se enganando. Entendemos porque a TI tem certo receio de IdM, devido a falta de suporte a integração e padrões. Mas enfrentamos ameaças sérias enquanto, simultaneamente, jogamos serviços em nuvem e dispositivos pessoais no bolo. Analise o perfil de seu funcionário como usuário do Facebook, Gmail e uma variedade de outros aplicativos baseados em web. Provavelmente, cada um deles tem entre sete e 15 combinações nome/senha; enquanto isso, sua empresa está, possivelmente, usando ou considerando usar serviço em nuvem que, por definição, não estão sendo legais com o Active Directory.