Modelos de gestão de identidades na cloud

A Cloud Computing é uma das tendências que mais tem crescido no setor das Tecnologias de Informação (TI). Cada vez mais aplicações e servidores migraram para a

CAPÍTULO 3: FEDERAÇÃO E GESTÃO DE IDENTIDADES

 Redução de custos: não é preciso comprar memória ou servidores, é possível ter tudo na Cloud;

 Escalabilidade: a alocação de recursos pode ser maior ou menor, dependendo da requisição, isto é, pode ser aumentada ascendentemente para requisições de pico, e descendentemente para as mais leves;

 Manutenção: a manutenção do SW e das infraestruturas físicas ficam a cargo de quem fornece esses serviços, plataformas ou infraestruturas.

Assim, com o aumento do número de utilizadores que utilizam a Cloud, é preciso que exista uma gestão segura e confiável das identidades. Com isto, surgiram alguns modelos de gestão de identidades na Cloud (Avram, 2014).

3.4.2.1. MODELO DE GESTÃO DE IDENTIDADE NA CLOUD

Neste modelo, o SP faz a função de autenticação e de autorização, sendo responsável pela gestão de identidades e pelo acesso dos utilizadores às aplicações que estão na Cloud. A figura 8 ilustra este modelo.

Os dados pessoais dos utilizadores são guardados no domínio do SP que está na

Cloud. Algumas empresas como a Google usam este modelo na sua Cloud e assim mantêm e

oferecem o seu próprio gestor de identidades para o seu Software as a Service (SaaS). Este modelo tem como vantagem a certeza de que as empresas podem contar apenas com a gestão de identidades que está no SP. Assim, há redução dos custos para os utilizadores que não têm que se preocupar com a manutenção dos seus dados, uma vez que é feita pelo SP. Mas por outro lado, as empresas e os utilizadores têm menos controlo sobre a disposição dos seus dados (Zwattendofer, Zefferer, & Stranacher, 2014).

3.4.2.2. MODELO DE GESTÃO DE IDENTIDADE PARA A CLOUD

No modelo de identidade para a Cloud, o IDP tem como funções a gestão das identidades e a autenticação dos utilizadores. Aqui, ao contrário das aplicações, o IDP não está na Cloud, o que evita que os dados dos utilizadores sejam divulgados. O SP só tem de saber se o utilizador está autenticado, com base nos dados que lhe são enviados pelo IDP e autorizá-lo a aceder às aplicações e aos recursos. Assim, os dados são transferidos para a

Cloud e essa mesma transferências entre o IDP e o SP é realizada através de alguns padrões

bem conhecidos como o SAML, OpenID ou o OAuth (Zwattendofer, Zefferer, & Stranacher, 2014). A figura 9 ilustra este modelo.

CAPÍTULO 3: FEDERAÇÃO E GESTÃO DE IDENTIDADES

Alguns SP’s que estão na Cloud, como a Google, dependem de alguns padrões acima mencionados para que lhe sejam fornecidos as identidades dos utilizadores. A vantagem deste modelo é que permite o uso de sistemas de gestão de identidades de uma organização ou empresa. Em vez de a gestão das identidade ser realizada na Cloud pelo SP, é executada pelo IDP que está fora da Cloud. Isso pode provocar um problema de interoperabilidade em que pode existir dificuldade de um sistema comunicar com outro. Além disso, o SP pode não suportar o IDP que está fora da Cloud e que é necessário para a autenticação dos utilizadores, causando um aumento nos custos e nos esforços de implementação. Outro problema que pode surgir é a troca dos atributos entre o SP e o IDP, em que o primeiro pode não entender os atributos que foram enviados pelo IDP. É necessário o mapeamento dos atributos entre eles (Zwattendorfer, Stranacher, & Tauber, 2013).

3.4.2.3 MODELO DE GESTÃO DE IDENTIDADES ENTRE CLOUDS

Neste modelo, tanto o IDP como as aplicações estão na Cloud, mas ao contrário do modelo do ponto 3.4.2.1, ambas são executadas por diferentes provedores de serviços de

Cloud e as identidades são fornecidas como um serviço da Cloud. A Google ou o Facebook

são dois exemplos, ao utilizar este modelo para os seus serviços de autenticação (Zwattendorfer, Stranacher, & Tauber, 2013). A figura 10 apresenta este modelo:

Uma empresa que decida implementar este modelo, tem como vantagens a escalabilidade, mas também as empresas podem escolher um IDP que lhes transmita confiança e que vai ser o responsável pela gestão das identidades e pela autenticação. Isto acontece porque há a separação dos provedores de serviços da Cloud. As organizações têm de ter cuidado ao selecionar os SP que pretendem usar, por causa da lei da proteção dos dados, em que cada SP possa ter, por estar alocado num servidor de um país diferente daquele onde está sedeada a organização, isto é, cada país pode ter uma maneira diferente de proteger os dados dos utilizadores (Zwattendofer, Zefferer, & Stranacher, 2014).

3.4.2.4 MODELO DE GESTÃO DE IDENTIDADES NA CLOUD COM UM IDP INTERMEDIÁRIO

Este modelo contém um gestor intermediário de identidades, isto é, fornece as identidades dos utilizadores aos IDP’s e SP’s que existem à sua volta. Com este modelo, separa-se os SP’s dos IDP’s, pois havendo um IDP intermediário, já não é preciso que cada SP fosse obrigado a configurar várias interfaces para vários provedores de identidade, diminuído a complexidade da comunicação entre os intervenientes e diminuindo os custos de implementação. Assim, basta configurar uma interface para o IDP (Huang et al., 2010).

Figura 11-Modelo de gestão de identidades na Cloud com um IDP intermediário. Fonte: (Zwattendofer,

CAPÍTULO 3: FEDERAÇÃO E GESTÃO DE IDENTIDADES

Com a Cloud, as questões com os recursos computacionais ou de escalabilidade ficam resolvidas, devido ao elevado número de ligações que existem neste modelo. Mas podem surgir desvantagens em que o utilizador e o SP são dependentes do funcionamento do IDP intermediário e este pode não suportar o IDP no qual o utilizador deseja efetuar a sua autenticação, fazendo com que o SP não autorize o acesso aos seus recursos. Outra desvantagem, é que os dados dos utilizadores podem passar pelo IDP intermediário, sem estarem cifrados. Isso pode levantar questões de privacidade (Zwattendorfer, Stranacher, & Tauber, 2013).

3.4.2.5 MODELO DE FEDERAÇÃO DE IDENTIDADES NA CLOUD COM VÁRIOS IDP’S INTERMEDIÁRIOS

Neste quinto modelo (figura 12), os utilizadores os IDP’s e os SP’s, não ficam dependentes de um único IDP intermediário. Com este novo modelo, os elementos intervenientes podem escolher o seu IDP intermediário e assim oferecer uma maior flexibilidade de escolha. Com isto, os esforços de autenticação ficam mais repartidos e cada um dos mediadores pode responder mais facilmente aos pedidos que lhe são enviados (Zwattendorfer, Stranacher, & Tauber, 2013).

É possível que um utilizador e um SP estabeleçam uma relação de confiança com os dois IDP’s, para além dos intermédios poderem estabelecer essa mesma confiança entre si. Para que o utilizador possa autenticar-se e possa aceder aos recursos no SP, tem que haver trocas de dados entre os intermédios. Assim, há 3 canais de comunicação entre estes intervenientes:

1. Entre IDP e o IDP intermediário nº2; 2. Entre os dois intermediários;

3. Entre o intermediário nº1 e o SP;

Para proteger esses canais, usam-se protocolo de identidade como o SAML ou o OAuth (Zwattendofer, Zefferer, & Stranacher, 2014).