Autenticação e Autorização em Federação de Nuvens

Transcrição

1 Autenticação e Autorização em Federação de Nuvens Ioram S. Sette 1, Carlos A. G. Ferraz 1,2 1 Centro de Informática Universidade Federal de Pernambuco (UFPE) 2 Centro de Estudos e Sistemas Avançados do Recife (CESAR) {iss,cagf}@cin.ufpe.br Abstract. Clouds Federation, or inter-clouds, is a trend for small and medium cloud service providers, enabling them to increase their potential capacity and, as a result, improving the quality of the cloud services offered to their customers. Nevertheless, in order to ensure privacy to user s data and services, it s necessary that cloud providers identify users and their resources in a unique way and apply the same authorisation policies and rules on them. This work proposes an authentication and authorisation model for federated clouds. This model must meet some requirements in order to grant a consistent experience for cloud federation users. Resumo. Federação de nuvens é uma tendência para pequenos e médios provedores, possibilitando que estes aumentem o potencial de suas capacidades e, por consequência, melhorem a qualidade dos serviços de nuvem oferecidos a seus usuários. No entanto, para garantirem a privacidade dos dados e serviços do usuário hospedados em diferentes provedores, é necessário que estes provedores identifiquem da mesma forma os usuários seus recursos, e apliquem as mesmas regras e políticas de autorização sobre eles. Este trabalho propõe um modelo de autenticação e autorização para federações de nuvens. Este modelo deve atender vários requisitos que garantam uma experiência uniforme aos usuários da federação. 1. Introdução e Motivação Desde a criação do paradigma Computação em Nuvens, o tema Federações de Nuvens vem ganhando relevância. Segundo Celesti et al. (2010a e 2010c), existirão três etapas na história da Computação em Nuvem: 1) a monolítica, onde ilhas isoladas de serviços de nuvem são providos por grandes provedores; 2) a cadeia de fornecimento vertical, onde provedores de nuvem subcontratam serviços de outros provedores, por exemplo, em caso de transbordo; e 3) a federação horizontal ou federações de nuvens ou internuvem, onde pequenos e médios provedores são federados para obterem economias de escala, uso eficiente de seus recursos, e aumentar suas capacidades. Neste contexto, Celesti et al. (2010a e 2010c) definem os conceitos de nuvem lar, provedor que provê interfaces para o usuário e contrato com o mesmo, e nuvem estrangeira, provedor federado com a nuvem lar e também pode armazenar recursos do usuário sem que o mesmo tenha relacionamento com as mesmas. O projeto CICN (Centro de Inovação em Computação em Nuvem) coordenado pelo Laboratório Nacional de Computação Científica (LNCC) propôs uma abordagem 519 c 2014 SBC Soc. Bras. de Computação

2 um pouco diferente. Para obter vantagens similares às propostas pela internuvem, a ideia foi criar o egov, uma camada de middleware sobre nuvens privadas de órgãos e empresas públicas, onde os usuários das mesmas não têm conhecimento de qual nuvem utilizam. Esta camada gerencia e distribui os acessos dos usuários às federações de nuvens [Gomes 2013]. Nos dois modelos, existe a necessidade das nuvens pertencentes à federação identificarem unicamente seus usuários e recursos, bem como proverem mecanismos de autorização que apliquem políticas e regras equivalentes. Caso contrário, usuários podem experimentar comportamentos diferentes quando acessam uma ou outra nuvem. Para garantir o acesso de uma mesma base de usuários às diversas nuvens pertencentes à federação, propõe-se que estas nuvens formem uma Federação de Identidade [Celesti et al. 2010a; Celesti et al. 2010b; Celesti et al. 2010c; Sanchez et al. 2012]. Neste modelo, os provedores de nuvem confiam nos provedores de identidade (Identity Providers - IdPs) para autenticar os usuários e garantir suas identidades. Como o gerenciamento de identidades é delegado aos IdPs, os usuários são identificados da mesma forma nas nuvens membros da federação [Khan et al. 2011; Ghazizadeh et al. 2012; Chadwick et al. 2013]. No entanto, este modelo não resolve o problema da autorização, isto é, não garante que as mesmas políticas e regras de autorização sejam aplicadas nas nuvens da federação. Federação de Autorização pode ser definido como um conjunto de sistemas que possuem relação de confiança entre si e compartilham políticas e regras de autorização. Quando a Federação de Autorização também compartilha de mesma base de usuários, existe uma Federação de Autenticação e Autorização. Chadwick et al. (2012) definem um serviço para autorização para provedores de nuvens baseado em ABAC (Attribute-Based Access Control) capaz de mesclar resultados de vários Pontos de Decisão de Políticas (PDP) diferentes. No entanto, este modelo não se aplica a Federações de Nuvem. O objetivo deste trabalho é propor um modelo para Federação de Autenticação e Autorização no contexto de Federações de Nuvens. Este artigo se divide em 4 seções. A seção 2 apresenta os requisitos necessários para uma Federação de Autenticação e Autorização em Federações de Nuvens. A seção 3 apresenta um modelo que atende aos requisitos identificados. Por fim, a seção 4 apresenta conclusões e trabalhos futuros. 2. Requisitos para Autenticação e Autorização em Federações de Nuvens No contexto de uma Federação de Nuvens, os requisitos necessários (marcados com um asterisco) e desejáveis para uma Federação de Autenticação e Autorização são listados a seguir: 1. *Receber de provedores de nuvem (Cloud Service Providers - CSPs) re quisições de autenticação delegada e de autorização com granularidade fina, de forma segura; 2. Oferecer serviços de autenticação e autorização independentes; 3. *Ser capaz de identificar usuários e prover os mesmos atributos a todos os CSPs; 4. Ser capaz de combinar atributos de identidade de múltiplas autoridades de atributos; 520 c 2014 SBC Soc. Bras. de Computação

3 5. *Ser capaz de aplicar o mesmo conjunto de políticas em todos os CSPs; 6. *Garantir que o conteúdo dos dados e de serviços não serão informados a sujeitos não autorizados; 7. Não ser ponto único de falha; 8. Permitir que proprietários de dados e serviços controlem a autorização; 9. *Suporte operações de migração e replicação (detalhadas a seguir); 10. Ser extensível a controle de uso (usage control model - UCON) e criptografia baseada em atributos (Attribute-Based Encryption - ABE). Em um contexto de Federação de Nuvens, recursos como arquivos de dados e/ou máquinas virtuais (VMs) podem ser transferidos de uma nuvem para outra por motivo de transbordo ou balanceamento de recursos. Desta forma, duas operações citadas no requisito 9 são apresentadas: migração e replicação de recursos entre nuvens. A migração de recursos é uma operação onde um recurso hospedado em uma nuvem é transferido para outra nuvem. Esta operação pode ser explícita, caso o usuário ou administrador tenha conhecimento sobre as nuvens pertencentes à federação, ou implícita, realizada automaticamente pelo sistema, caso o mesmo identifique que não possui mais infraestrutura disponível para hospedar o recurso. Por recurso, podemos considerar qualquer entidade de usuário hospedada no provedor de nuvem, por exemplo, arquivos num sistema de armazenamento, ou máquinas virtuais, num sistema de computação elástica. A replicação de recursos entre nuvens aumentam a garantia de disponibilidade e desempenho em seus acessos. Por exemplo, cópias de arquivos podem ser mantidas em diferentes provedores, ou instâncias de uma mesma máquina virtual podem ser executadas em diferentes provedores. Neste caso, o usuário controla o acesso a partir da nuvem de origem onde o recurso foi criado, e o sistema mantém o sincronismo das réplicas nas nuvens estrangeiras. 3. Modelo para Autenticação e Autorização em Federações de Nuvens Nesta seção, um modelo de Federação de Autenticação e Autorização para Federações de Nuvens é proposto. Este modelo deve atender aos requisitos definidos na seção 2.2. O modelo, representado na Figura 1, combina uma Federação de Identidades (ou de autenticação) com uma Federação de Autorização de arquitetura distribuída e mecanismo de controle de acesso baseado em atributos (ABAC), que permite regras com granularidade fina. As conexões devem usar protocolos como SSL para garantir o sigilo dos dados trafegados. Os requisitos 1 e 2 são atendidos por estas características. Os CSPs membros da Federação de Nuvens também participam de uma Federação de Identidade (ou de Autenticação). Portanto, a autenticação dos usuários é delegada aos IdPs federados. A integração com os IdPs são realizadas normalmente através de um módulo ou serviço de identidade (Cloud Identity Service), interno à arquitetura dos provedores [Sette et al. 2013; Sette et al. 2014]. Os trabalhos citados descrevem a integração de um provedor Openstack a provedores de Identidade através dos protocolos OpenID Connect e SAML. Neste modelo, o usuário deve se autenticar com seu IdP antes de acessar o CSP. Desta forma, problemas típicos da centralização, como ser um ponto único de compromisso ou de falha podem acontecer. Por exemplo, se o 521 c 2014 SBC Soc. Bras. de Computação

4 IdP do usuário estiver indisponível, o serviço de nuvem não pode ser acessado. No entanto, estas desvantagens são contrapostas e justificadas por vantagens como a redução de credenciais para os usuários e a possibilidade de mecanismos de autenticação mais sofisticados. A federação de identidade garante que os usuários sejam apresentados de forma única aos provedores de nuvens federados, atendendo o requisito 3. O requisito 4 pode ser implementado pelo módulo de identidade do provedor, sendo necessário que este componente tenha como saber que os atributos pertençam a um mesmo usuário. Figura 1. Modelo para Federação de Autenticação e Autorização em Federação de Nuvens De forma análoga, os CSPs membros da Federação de Nuvens também formam uma Federação de Autorização, de forma a garantir os requisitos 5 e 6. Porém, diferente da Federação de Identidade, a arquitetura distribuída apresentada na Figura 1 permite o sincronismo de regras e políticas de acesso. Esta arquitetura foi inspirada no modelo do serviço de nomes da Internet (DNS), onde as regras de autorização são armazenadas no provedor de origem dos recursos, de forma análoga ao DNS autoritativo, e, quando a regra não está presente, ela é encontrada na rede e armazenada em cache no provedor local, de maneira análoga ao DNS recursivo. Desta forma, a solução ganha em desempenho, uma vez que as regras e políticas de autorização acabam, na maior parte das vezes, estando armazenadas localmente, e também em não haver um ponto único de falhas, uma vez que a solução é distribuída. O requisito 7 está, desta forma, atendido. 522 c 2014 SBC Soc. Bras. de Computação

5 Cada provedor de nuvem possui um serviço de autorização, responsável pela decisão de liberação da ação solicitada pelos demais serviços (ex.: serviço de computação ou de armazenamento). O serviço de autorização utiliza um sistema ABAC composto pelos módulos definidos na arquitetura XACML (extensible Access Control Markup Language). Os serviços da nuvem que recebem requisições de acesso devem garantir que, para cada requisição, o serviço de autorização seja consultado através de um Ponto de Aplicação de Políticas (PEP, do inglês Policy Enforcement Point). O Ponto de Decisão de Políticas (PDP) faz interface com o PEP, recebendo a requisição de acesso e respondendo com uma permissão ou negação. Para tomar sua decisão, o PDP verifica políticas e regras de acesso armazenadas nos Pontos de Recuperação de Políticas (PRP). As regras e políticas sobre os recursos do usuário devem ser definidas apenas pelos usuários proprietários destes recursos, conforme o requisito 8. No entanto, regras globais podem ser definidos por administradores do projeto (tenant) ou do provedor de nuvem. Neste caso, o conceito de projeto e as regras precisam ser propagadas aos outros provedores federados. As regras e políticas de autorização são definidas através do Ponto de Administração de Políticas (PAP). Elas recebem como parâmetros atributos do sujeito (quem deseja o acesso), do objeto alvo, ou do ambiente, que são informados ao PDP pelo Ponto de Informação de Políticas (PIP). Os atributos do objeto são provenientes de seus metadados, enquanto os atributos do usuário são adquiridos através do módulo de identidade do CSP, provenientes dos provedores de identidade (IdPs). Conforme previsto no requisito 9, operações de migração e replicação de dados devem ser suportadas. Durante operações de migração de dados ou VMs, os metadados e as regras e políticas de autorização referentes ao objeto também são migrados para o novo CSP (Cloud Service Provider). Funciona como se o provedor de origem daquele objeto fosse alterado para o novo provedor de destino. Já nas operações de replicação, apesar da réplica estar hospedada em um provedor diferente do provedor de origem, as regras de acesso devem permanecer no provedor de origem. Desta forma, quando um acesso é realizado a estes objetos, o PRP deve buscar na federação qual provedor tem autoridade sobre estes objetos e recuperar as regras (de acesso) referentes aos mesmos. As regras serão mantidas em um cache de políticas e regras por tempo definido pelo dono dos objetos. Desta forma, garante-se que as regras aplicadas às réplicas sejam as mesmas aplicadas aos objetos originais. De acordo com o requisito 10, este modelo pode ser facilmente extensível. Para permitir um controle de uso (UCON), a verificação de acesso deve ser realizada várias vezes durante o acesso e obrigações podem ser efetuadas também durante a execução. A extensão para um mecanismo de criptografia baseada em atributos (ABE) também é possível, uma vez que utilizamos um controle de acesso baseado em atributos (ABAC). No entanto, é necessária uma reflexão sobre como trafegar chaves criptográficas entre provedores federados de forma segura, caso necessário. 4. Conclusões Num modelo de Federação de Nuvens, usuários possuem apenas uma interface para acessar e usar seus dados e serviços, que podem estar hospedados em mais de um provedor de nuvem de forma transparente aos mesmos. 523 c 2014 SBC Soc. Bras. de Computação

6 Este trabalho se propõe a definir um modelo para autenticação e autorização aplicável a Federações de Nuvens, que permita que os provedores compartilhem de uma mesma base de usuários, e que as mesmas regras e políticas de autorização sejam aplicadas por estes provedores. Objetos dos usuários podem ser migrados de um provedor para outro ou replicados entre provedores sem que o usuário perceba. O modelo proposto é baseado em Federação de Autenticação e Autorização, com uma arquitetura de autorização distribuída baseada em ABAC. Este modelo atendeu a diversos requisitos necessários e desejáveis que foram elencados neste artigo. Como trabalho futuro, este modelo será implementado, testado e validado em uma Federação de Nuvens formada por provedores que utilizam a plataforma Openstack. Referências Celesti, A. et al. (2010a) How to Enhance Cloud Architectures to Enable Cross- Federation In: 3rd International Conference on Cloud Computing, p IEEE. Celesti A. et al. (2010b) Security and Cloud Computing: InterCloud Identity Management Infrastructure In: Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, p IEEE. Celesti A. et al. (2010c) Three-Phase Cross-Cloud Federation Model: The Cloud SSO Authentication In: Second International Conference on Advances in Future Internet, p IEEE. Chadwick, D. W., Casenove, M. and Siu, K. (2013) My private cloud granting federated access to cloud resources In: Journal of Cloud Computing, p SpringerOpen. Chadwick, D. W. and Fatema, K. (2012) A privacy preserving authorisation system for the cloud, In: Journal of Computer and System Sciences, i.78, p Elsevier. Gazizadeh, E. et al. (2012) A trusted based model for federated identity architecture to mitigate identity theft, In: 2012 International Conference for Internet Technology And Secured Transactions, p IEEE. Gomes, A. T. A. (2013) CICN - Centro de Inovação em Computação em Nuvem, FINEP/0615/11. Khan, R. H., Ylitalo, J. and Ahmed, A. S. (2011) OpenID authentication as a service in OpenStack, In: 7th International Conference on Information Assurance and Security, p IEEE. Sánchez, R. et al. (2012) Enhancing Privacy and Dynamic Federation in IdM for Consumer Cloud Computing In: IEEE Transactions on Consumer Electronics, vol. 58, i.1, p IEEE. Sette, I. S. and Ferraz, C. A. G. (2013) Integrando Openstack com Provedores de Identidade OpenID Connect e SAML: Uma Análise Comparativa In: XIII Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais, p , SBC. Sette, I. S. and Ferraz, C. A. G. (2014) Integrando Plataformas de Nuvens a Federações de Identidade In: Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos, p SBC. 524 c 2014 SBC Soc. Bras. de Computação