XIV Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2014
Autenticação e Autorização em Federação de Nuvens
Ioram S. Sette1, Carlos A. G. Ferraz1,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
XIV Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2014
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) requisiçõ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
XIV Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2014
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
XIV Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2014
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
XIV Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2014
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
XIV Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2014
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 CrossFederation” In: 3rd International Conference on Cloud Computing, p. 337-345. IEEE.
Celesti A. et al. (2010b) “Security and Cloud Computing: InterCloud Identity Management
Infrastructure” In: Workshops on Enabling Technologies: Infrastructure for
Collaborative Enterprises, p. 263-265. 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.
94-101. 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.1-16. 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.1359-1373. 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.376-381. 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.372-377. 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.95-103. 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.497-506,
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.617-630. SBC.
524
c
2014
SBC — Soc. Bras. de Computação