E, no caso das palavras-passe, cada uma delas — especialmente as que se esquecem — representa um pequeno risco de segurança que se esconde nas sombras. Podes pensar que te livraste delas (ou, pelo menos, que as reduziste a um número razoável), mas continuam a aparecer. E, como todos sabemos, as aplicações SaaS — quer sejam aplicações pessoais ou sociais, como o Facebook, quer sejam as milhares de aplicações empresariais atualmente em uso — fizeram com que este problema, bem... se multiplicasse rapidamente.
A maior razão pela qual as ofertas de gestão de identidade como serviço (IDaaS), como o Azure Active Directory, Okta e outros, são populares hoje em dia é porque fornecem um início de sessão único (SSO) para aplicações SaaS a partir do browser de um utilizador. Também proporcionam maior segurança através da gestão destes userids e passwords. O utilizador acede simplesmente a um portal da empresa que tem ícones que representam as aplicações e clica num ícone para iniciar sessão.
Embora esta capacidade seja uma melhoria em relação a um início de sessão não gerido, existem ainda riscos de segurança significativos que deve conhecer.
Luta com as palavras-passe SaaS: Abóbada e repetição
Em primeiro lugar, um pouco de informação sobre a forma como as aplicações IDaaS tratam as credenciais do sítio Web.
As maiores e mais populares aplicações SaaS empresariais actuais, como Salesforce, Workday, Concur e várias centenas de outras, suportam a federação de identidades, o que simplifica drasticamente o início de sessão numa aplicação e aumenta a sua segurança. No entanto, a grande maioria das aplicações SaaS no mercado requerem um ID de utilizador e uma palavra-passe para iniciar sessão a partir do browser do utilizador - uma tarefa complicada, repleta de palavras-passe esquecidas, palavras-passe demasiado simples e blocos de notas com palavras-passe escritas.
Os serviços IDaaS utilizam duas técnicas principais para tratar deste assunto para o utilizador. Em primeiro lugar, quando um utilizador inicia sessão num destes sites de "preenchimento de formulários", uma extensão de captura de palavra-passe no seu browser pergunta-lhe se deseja armazenar as suas credenciais no cofre de palavras-passe do serviço IDaaS. Em segundo lugar, da próxima vez que o utilizador quiser iniciar sessão na aplicação SaaS, a extensão do browser comunica com o serviço IDaaS para reproduzir as credenciais do utilizador nos campos userid e password, iniciando assim sessão sem qualquer acção da parte do utilizador.
As palavras-passe que escaparam
A guarda de palavras-passe simplifica muito o início de sessão nestas aplicações, especialmente se o utilizador tentar controlar tudo sozinho. Mas trata-se de uma abordagem à segurança que não é fácil de seguir por cinco razões.
- Em primeiro lugar, significa que as credenciais do utilizador são armazenadas no serviço de nuvem do fornecedor de IDaaS, o que é proibido pelas políticas de segurança de TI de muitas empresas.
- Em segundo lugar, independentemente do grau de encriptação dos créditos quando estão na nuvem, têm de ser transmitidos de forma clara para a aplicação SaaS durante o processo de reprodução. Não há forma de o contornar. Em terceiro lugar, as páginas de início de sessão do utilizador da aplicação estão sempre a mudar de layout, pelo que o fornecedor de IDaaS tem de tentar manter-se actualizado com milhares destas alterações para que a repetição da palavra-passe funcione correctamente.
- Em quarto lugar, na maioria dos casos, o utilizador conhece o seu nome de utilizador e palavra-passe para a aplicação. (Certamente que os conhecia antes de ser obrigado a aceder à aplicação através do portal de utilizadores da empresa.) Isto significa que podem sempre contornar o portal e iniciar sessão diretamente. Se se tratar de uma nova aplicação a entrar em serviço, alguns fornecedores de IDaaS permitem que o administrador carregue as credenciais do utilizador em seu nome, para que este não as conheça e, assim, seja obrigado a utilizar o portal – mas isto só funciona na integração de novas aplicações. Alguns fornecedores de IDaaS têm uma capacidade limitada de alterar a palavra-passe para algumas aplicações, e outros conseguem ocultar o URL de início de sessão da aplicação, mas estes são uma minoria ínfima. Para piorar a situação, navegadores como o Chrome ou extensões de navegador como o LastPass oferecem convenientemente a possibilidade de guardar a palavra-passe do utilizador quando este inicia sessão. E por que razão não iria o utilizador comum querer guardar a palavra-passe para não ter de a introduzir novamente?
Por fim, e mais importante ainda, as aplicações SaaS não estão integradas no sistema de gestão do ciclo de vida da identidade corporativa. O que é que isto significa? Significa que, se despedir um colaborador e desativar a sua conta no AD DS local, o utilizador deixa de poder iniciar sessão na rede da empresa ou aceder aos seus recursos. Quando essa desativação é replicada para o serviço IDaaS, o utilizador não consegue aceder a quaisquer recursos na nuvem que requeiram o serviço IDaaS, tais como aplicações federadas (Salesforce, Office 365). Isto é positivo e deixa a equipa de segurança satisfeita.
No entanto, as aplicações SaaS de preenchimento de formulários não dependem das suas credenciais empresariais, ao contrário do que acontece com as aplicações SaaS federadas. Quando essa conta de utilizador do AD DS é desativada ou eliminada, nada acontece no aplicativo SaaS em questão. Este não tem qualquer conhecimento do que aconteceu na empresa. A menos que alguém tome a iniciativa explícita de verificar a quais aplicativos o utilizador tem acesso e os desative manualmente em cada um deles, o utilizador consegue aceder. Porquê? Tudo o que o utilizador precisa é do seu ID de utilizador, palavra-passe e do URL de início de sessão do aplicativo.
Devo salientar que estas questões não são da responsabilidade do fornecedor de IDaaS; este está a fazer o melhor que pode, recorrendo a várias técnicas de engano, para disfarçar as falhas inerentes ao cenário de início de sessão em aplicações SaaS que envolvem o preenchimento de formulários.
Resumindo: Provisionar utilizadores para aplicações é relativamente simples. Desprovisioná-los é uma questão completamente diferente.
O que as organizações podem fazer
Este é um problema que é extremamente difícil de corrigir retroactivamente. Em vez disso, é preciso antecipar-se:
- Auditar as aplicações SaaS a que um utilizador tem acesso, armazenadas numa base de dados de direitos centralizada, para saber a que todos têm acesso. Este é muito mais um problema de política e processo do que um problema de tecnologia.
- Utilize a Política de Grupo para desactivar o gestor de palavras-passe do Chrome.
- Sempre que possível, utilize uma opção que permita gerar e armazenar automaticamente a palavra-passe do utilizador, para que este não a conheça.
- Quando a sua organização está a avaliar as aplicações SaaS, o início de sessão federado deve ser um requisito - e não um "bom ter". Certifique-se de que o ISV sabe disso. Apenas os requisitos do cliente (ou seja, as vendas) levam os ISVs a efectuar alterações.
Os fornecedores de IDaaS podem ser uma grande vantagem para os seus utilizadores ao fornecerem SSO a muitas aplicações SaaS através de um único portal de utilizador e de vários factores de forma. São também um grande benefício para a segurança da informação, porque fornecem algum grau de gestão centralizada a estas aplicações. No entanto, continua a ser necessário tomar medidas para tornar esta solução segura.
