Sean Deuby

E, no caso das palavras-passe, cada uma - especialmente cada palavra-passe esquecida - é um pequeno risco de segurança que se esconde nas sombras. Pode pensar que se livrou deles (ou pelo menos reduziu-os a uma quantidade controlável), mas eles continuam a aparecer. E como todos sabemos, as aplicações SaaS, quer sejam aplicações pessoais ou sociais como o Facebook ou os milhares de aplicações empresariais actualmente em utilização, 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 das circunstâncias, o utilizador conhece o seu ID de utilizador e a sua palavra-passe para a aplicação. (Certamente sabiam antes de serem obrigados a aceder à aplicação através do portal do utilizador da empresa). Isto significa que podem sempre contornar o portal e iniciar sessão directamente. Se se tratar de uma nova aplicação a entrar em funcionamento, alguns fornecedores de IDaaS suportam que o administrador carregue as credenciais do utilizador para que este não as conheça e tenha de utilizar o portal - mas isto só funciona para a integração de novas aplicações. Alguns fornecedores de IDaaS têm uma capacidade limitada para alterar a palavra-passe de algumas aplicações e alguns podem ofuscar o URL de início de sessão da aplicação, mas estes são uma pequena minoria. Para piorar a situação, navegadores como o Chrome ou suplementos de navegador como o LastPass oferecem facilmente a possibilidade de guardar a palavra-passe do utilizador quando este inicia sessão. E porque é que o utilizador comum não quereria guardar a palavra-passe para não ter de a introduzir novamente?

Por último, e mais importante, as aplicações SaaS não estão ligadas ao sistema de gestão do ciclo de vida da identidade empresarial. O que é que isto significa? Significa que se despedir um funcionário e desactivar 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 desactivação é replicada para o serviço IDaaS, o utilizador não pode aceder a quaisquer recursos da nuvem que exijam o serviço IDaaS, como aplicações federadas (Salesforce, Office 365). Isso é bom e deixa o pessoal da segurança feliz.

Mas as aplicações SaaS de preenchimento de formulários não dependem das suas credenciais empresariais como as aplicações SaaS federadas. Quando essa conta de utilizador do AD DS é desactivada ou eliminada, nada acontece nessa aplicação SaaS. Não faz ideia do que aconteceu na empresa. A menos que alguém tome a acção explícita de auditar as aplicações a que o utilizador tem acesso e as desactive manualmente em cada aplicação, o utilizador pode entrar. Porquê? Tudo o que o utilizador precisa é do seu ID de utilizador, palavra-passe e o URL de início de sessão da aplicação.

Devo salientar que estes problemas não são culpa do fornecedor de IDaaS; estão a fazer o melhor que podem, utilizando várias técnicas de fumo e espelho, para suavizar as falhas inerentes ao cenário de início de sessão de aplicações SaaS de 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 para gerar e guardar automaticamente a palavra-passe do utilizador para que este não a saiba.
  • 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.