Uma Proposta de Controle de Acesso como
Serviço para Federação de Identidades
Brasil
2018
Uma Proposta de Controle de Acesso como Serviço para
Federação de Identidades
Monografia de Graduação apresentada ao Departamento de Informática e Matemática Aplicada (DIMAP) da Universidade Federal do Rio Grande do Norte como requisito par-cial para a obtenção do grau de Bacharel em Engenharia de Software.
Universidade Federal do Rio Grande do Norte – UFRN Departamento de Informática e Matemática Aplicada – IMD
Bachalerado em Engenharia de Software
Orientador: Prof. Dr. Carlos Eduardo da Silva
Brasil
2018
Silva, Brunno Moreira da.
Uma proposta de controle de acesso como serviço para federação de identidades / Brunno Moreira da Silva. - 2018. 86f.: il.
Monografia (Bacharelado em Engenharia de Software)
-Universidade Federal do Rio Grande do Norte, Centro de Ciências Exatas e da Terra, Departamento de Informática e Matemática Aplicada, Curso de Engenharia de Software. Natal, 2018. Orientador: Carlos Eduardo da Silva.
1. Engenharia de software - Monografia. 2. Federação de identidades - Monografia. 3. Controle de acesso - Monografia. 4. FACS - Monografia. 5. XACML - Monografia. I. Silva, Carlos Eduardo da. II. Título.
RN/UF/CCET CDU 004.41
Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET
Uma Proposta de Controle de Acesso como Serviço para
Federação de Identidades
Monografia de Graduação apresentada ao Departamento de Informática e Matemática Aplicada (DIMAP) da Universidade Federal do Rio Grande do Norte como requisito par-cial para a obtenção do grau de Bacharel em Engenharia de Software.
Trabalho aprovado. Brasil, 27 de novembro de 2018:
Prof. Dr. Carlos Eduardo da Silva
Orientador
Prof. Dr. Silvio Costa Sampaio
Convidado 1
Prof. Ms. Itamir de Morais Barroca Filho
Convidado 2
Brasil
2018
Mãe, seu cuidado e dedicação incondicional foi o que deram, em alguns momentos, a esperança para seguir.
Pai, sua presença e companheirismo significou segurança e certeza de que não estou sozinho nessa caminhada.
Minha querida Josi, todo seu amor e confiança, seus olhos cheios de alegria e esperança tornam meus dias melhores e me encoraja e motiva a não desistir.
A Deus por ter me dado saúde e força para superar as dificuldades.
A esta universidade, seu corpo docente, direção e administração que oportunizaram a janela que hoje vislumbro um horizonte superior, eivado pela acendrada confiança no mérito e ética aqui presentes.
Ao meu orientador Carlos Eduardo da Silva, pelo seu suporte no pouco tempo que lhe coube, pelas suas correções e lições.
Aos meus pais, pelo amor, incentivo e apoio incondicional. A minha amada noiva, por sua presença e fé constante.
E a todos que direta ou indiretamente fizeram parte da minha formação, o meu muito obrigado.
possuídos por uma inabalável determinação conseguiremos superá-los. Independentemente das circunstâncias, devemos ser sempre humildes, recatados e despidos de orgulho.“ (Dalai Lama)
Em uma federação de identidades cada serviço é responsável por controlar o acesso dos usuários da federação, determinando quem pode acessar e seus privilégios. Nesse contexto, o Sistema de Controle de Acesso Federado (Federated Access Control System - FACS) foi proposto como um sistema de controle de acesso hierárquico para controlar o acesso de usuários a serviços em ambientes federados. Entretanto, o FACS foi desenvolvido com um alto acoplamento no que diz respeito a funcionalidade de gestão de políticas de controle de acesso para controlar o acesso dos usuários a recursos e serviços fornecidos pelo edudrive@RNP, além de não ser especificado uma forma para definição de políticas e os passos necessários para integração de outros serviços da federação. Com isso, é proposta a implementação de uma nova versão do FACS, com a introdução de XACML (eXtensible Access Control Markup Language) para a definição de políticas, fornecendo uma interface comum para gestão de políticas e permitindo a aplicação de um controle de acesso com granularidade fina para controlar o acesso de usuários a serviços em uma federação de identidades. Com esta proposta, a funcionalidade de gerenciamento de políticas de controle de acesso passa a ser delegada a um servidor de autorização e a nova versão do FACS desenvolvida é integrada ao CloudStack, produto utilizado no serviço de computação em nuvem da Rede Nacional de Ensino e Pesquisa, a fim de avaliar as mudanças propostas.
In a federation of identities each service is responsible for control the access of the users of the federation, determining who can access and its privileges. In this context, the Federated Access Control System (FACS) has been proposed as a hierarchical access control system to control users access to services in federated environments. However, the FACS was developed with a high degree of coupling with respect to access control policy management functionality to control users access to resources and services provided by edudrive@RNP, besides not being specified a means for definition of policies and the required steps for integration of others services in federation. Therefore, it is proposed to implementation of a new version of the FACS, introducing XACML (eXtensible Access Control Markup Language) for policy definition, providing a common interface for policy management and allowing the application of a fine-granularity access control to control the access of users to services in an identity federation. With this proposal, access control policy management functionality is now delegated to an authorization server and the new FACS version developed is integrated with CloudStack, product used in the cloud computing service of the Rede Nacional de Ensino e Pesquisa, in order to evaluate the proposed changes.
Figura 1 – Componentes Funcionais do ABAC (HU et al., 2014). . . 23
Figura 2 – Arquitetura padrão e fluxo de dados do XACML (OASIS, 2013).. . . . 25
Figura 3 – Representação esquemática da linguagem de políticas do XAMCL (OA-SIS, 2013). . . 28
Figura 4 – Arquitetura do FACS (DINIZ et al., 2015). . . 37
Figura 5 – Fluxo para políticas independentes de SP do FACS (DINIZ et al., 2015). 38 Figura 6 – Arquitetura do FACS integrada ao servidor de autorização. . . 41
Figura 7 – Arquitetura do CloudStack. . . 48
Figura 8 – Entidades do sistema de controle de acesso do CloudStack. . . 49
Figura 9 – Diagrama de Pacotes do FACS. . . 54
Figura 10 – Representação esquemática do ambiente de avaliação. . . 58
Figura 11 – Tela do PHP Proxy. . . . 59
Figura 12 – Tela principal do FACS para gerenciamento de políticas independentes de SP. . . 60
Figura 13 – Tela com mensagem de erro do PHP Proxy. . . . 61
Figura 14 – Tela de gerenciamento de domínios do CloudStack. . . 62
Figura 15 – Tela de gerenciamento de accounts do domínio do IdP2 do CloudStack. 62 Figura 16 – Tela do FACS para gerenciamento de solicitações de acesso de usuários de um Provedor de Identidade a um Provedor de Serviço. . . 63
Figura 17 – Tela do FACS para listagem de políticas para políticas independentes de SP do modo de acesso baseado em políticas. . . 64
Figura 18 – Tela do FACS para listagem de políticas dependentes de SP. . . 65
Figura 19 – Tela de gerenciamento de accounts do domínio do IdP4 do CloudStack. 65 Figura 20 – Tela de gerenciamento de uma account do CloudStack. . . . 66
Figura 21 – Mensagem de erro exibida pelo CloudStack a um usuário ao tentar realizar uma operação que exceda os limites de recursos definidos. . . . 66
Tabela 1 – Entidades a alguns de seus atributos definidos no padrão XACML. . . 24
Tabela 2 – Entidades e atributos permitidos definidos no perfil de políticas inde-pendentes de SP. . . 43
Tabela 3 – Entidades e atributos permitidos definidos no perfil de políticas depen-dentes de SP do FACS. . . 45
Tabela 4 – Entidades e atributos permitidos definidos no perfil de políticas depen-dentes de SP do CloudStack. . . 51
Tabela 5 – Estrutura utilizada para representação dos casos de testes. . . 61
Tabela 6 – Detalhes do teste realizado para o primeiro cenário. . . 61
Tabela 7 – Detalhes do teste realizado para o segundo cenário. . . 62
Tabela 8 – Detalhes do teste realizado para o terceiro cenário. . . 63
Tabela 9 – Detalhes do teste realizado para o quarto cenário. . . 64
ABAC Attribute Based Access Control
API Application Program Interface
AWS Amazon Web Services
CLI Command Line Interface
CAFe Comunidade Acadêmica Federada
CNC Computação em Nuvem para Ciência
FACS Federated Access Control System
FIM Federated Identity Management
GUI Graphical user interface
HTTP HyperText Transfer Protocol IaaS Infrastructure as a Service
IAM Identity and Access Management
IdM Identity Management
IdP Identity Provider
IS Identity Server
JSON JavaScript Object Notation
NIST National Institute of Standards and Technology
OAM&P Operations, Administration, Maintenance, and Provisioning
OASIS Organization for the Advancement of Structured Information Standards
PAP Policy Administration Point
PDP Policy Decision Point
PEP Policy Enforcement Point
REST Representational State Transfer
RNP Rede Nacional de Ensino e Pesquisa
SAML Security Assertion Markup Language
SBRC Simpósio Brasileiro em Redes de Computadores e Sistemas Distribuídos
SOA Service-Oriented Architecture
SOAP Simple Object Access Protocol
SP Service Provider
SSO Single Sign On
XACML eXtensible Access Control Markup Language
1 INTRODUÇÃO . . . 15 1.1 Problemática . . . 16 1.2 Objetivos . . . 17 1.3 Metodologia . . . 17 2 FUNDAMENTAÇÃO TEÓRICA . . . 19 2.1 Controle de Acesso . . . 19
2.1.1 Autenticação, Autorização e Auditoria . . . 20
2.1.2 Modelos, Mecanismos e Políticas . . . 20
2.2 XACML . . . 24 2.3 Gerenciamento de Identidades . . . 32 2.4 Considerações Finais . . . 34 3 FACS . . . 36 3.1 Visão Geral . . . 36 3.2 Arquitetura do FACS. . . 36 3.3 Limitações . . . 38
4 NOVA IMPLEMENTAÇÃO PROPOSTA PARA O FACS . . . 40
4.1 Abordagem Proposta . . . 40
4.2 Integração com WSO2 Identity Server . . . 46
4.3 Integração com CloudStack . . . 47
4.4 Implementação . . . 53 4.5 Considerações Finais . . . 56 5 AVALIAÇÃO . . . 58 5.1 Ambiente . . . 58 5.2 Cenários . . . 60 5.3 Discussão . . . 66 6 TRABALHOS RELACIONADOS . . . 68 7 CONCLUSÃO . . . 70 7.1 Contribuições . . . 70 7.2 Limitações . . . 71 7.3 Trabalhos Futuros . . . 71
APÊNDICES
75
APÊNDICE A – PERFIS XACML DEFINIDOS PARA O FACS . . 76
APÊNDICE B – POLÍTICAS XACML UTILIZADAS NA AVALIA-ÇÃO . . . 82
1 Introdução
Controle de acesso consiste no processo de proteger recursos e serviços providos por uma organização de acessos não autorizados, controlando o acesso de usuários a um sistema através da definição de políticas, modelos e mecanismos, para limitar as ações que
um usuário pode realizar sobre recursos em um sistema (SANDHU; SAMARATI, 1994).
Do ponto de vista de uma organização, o controle de acesso permite o compartilhamento de informações de forma segura, protegendo o acesso a seus recursos e serviços contra acessos inadequados ou indesejados, garantindo que somente usuários autorizados possam
efetuar o acesso a seus sistemas (HU; FERRAIOLO; KUHN, 2006).
Um sistema de controle de acesso é capaz de proteger o acesso a recursos de um sistema, limitando o acesso de usuários legítimos através dos processos de autenticação, que permite identificar um usuário e validar sua identidade, autorização, que define o que um usuário pode fazer no sistema, especificando quais recursos e serviços ele pode acessar, e auditoria, que consiste no processo de registro de todas as requisições e atividade dos usuários para análise posterior, permitindo observar o comportamento de cada usuário e
identificar algum acesso ou atividade suspeita (SANDHU; SAMARATI,1994).
Por outro lado, uma federação de identidades consiste de um modelo de gestão de identidades distribuído no qual é estabelecida uma relação de confiança mútua entre Provedores de Serviço (Service Provider - SP) e Provedores de identidades (Identity Provider - IdP). Um SP provê serviços a usuários da federação, enquanto que IdPs são responsáveis por gerenciar identidades e emitir informações de autenticação e autorização
de usuários (CHADWICK, 2009). Essa relação de confiança é chamada de federação e
permite o compartilhamento de recursos, serviços e informações entre organizações de diferentes domínios.
Num cenário geral, em uma federação, através da relação de confiança estabelecida entre IdP’s e SP’s, um usuário pertencente a uma instituição pode, através das credenciais de autenticação e autorização emitidas pelo seu IdP, acessar serviços providos por qualquer SP integrante. Assim, em um cenário básico, usuários provenientes de um IdP podem acessar qualquer serviço provido em uma federação. Enquanto que, em alguns cenários mais específicos, um SP precisa realizar o controle de acesso dos usuários da federação ao seu serviço, determinando a quais usuários e instituições o acesso será concedido. Isso ocorre, por exemplo, em um cenário no qual somente usuários de alguns IdPs tem acesso ao serviço oferecido, resultado de um acordo contratual entre as instituições ou quando uma instituição paga para que seus usuários possam acessar o serviço provido. Outro cenário, ainda mais específico, seria quando somente alguns usuários de alguns IdPs
podem acessar um serviço, decorrente por exemplo, do fato de o serviço estar em fase experimental, permitindo o acesso apenas de alguns usuários da federação para realizar testes e conhecer suas capacidades. Tais cenários podem ocorrer na prática, como no caso do projeto CNC (Computação em Nuvem para Ciência), um serviço de armazenamento em nuvem implantado na infraestrutura de redes da RNP (Rede Nacional de Ensino e
Pesquisa)1, e no serviço de computação em nuvem da RNP2.
Diante dessa situação, foi proposto o Federated Access Control System (FACS)
(DI-NIZ et al., 2015) como um sistema de controle de acesso hierárquico para permitir a
definição e delegação de políticas de controle de acesso entre administradores de IdP e SP para serviços da federação. Esse sistema foi proposto, tendo como objetivo principal, atender os cenários de controle de acesso mais específicos apresentados anteriormente. Para tanto, ele permite ao administrador de um Provedor de Serviço definir políticas de controle de acesso para determinar quais usuários da federação podem acessar o serviço e definir seus privilégios, além de permitir a delegação dessa capacidade a administradores de Provedores de Identidade. Entretanto, o FACS apresenta algumas limitações.
1.1
Problemática
Embora tenha sido proposto como uma solução para diversos SPs, o FACS foi inicialmente implementado para o edudrive@RNP, de forma que o sistema foi desenvolvido com um alto acoplamento no que diz respeito a funcionalidade de gestão de políticas de controle de acesso para controlar o acesso dos usuários a recursos e serviços fornecidos pelo edudrive@RNP. Assim, a integração com novos provedores de serviços, como o serviço de computação em nuvem da RNP, exigiria um alto custo de desenvolvimento, uma vez que cada um tem suas próprias caraterísticas, oferecendo diferentes recursos e serviços.
Além disso, em sua versão atual, embora seja baseado no Controle de Acesso Baseado em Atributos (Attribute Based Access Control - ABAC), não é especificado nenhum mecanismo para definição de políticas de controle de acesso, assim como a ausência de suporte para definição de políticas de Controle de Acesso com Granularidade Fina para outros Provedores Serviços. Por causa disso, a definição de políticas para novos provedores serviços teria que ser feita no formato especificado e compreendido por cada um, exigindo um maior esforço de desenvolvimento na integração de novos provedores serviços ao FACS. Assim, a adoção de um padrão, como a Linguagem de Marcação de Controle de Acesso Extensível (eXtensible Access Control Markup Language - XACML), estabeleceria um formato comum para definição de políticas de controle de acesso, facilitando a integração de diferentes provedores de serviços ao FACS.
1 O CNC foi renomeado para edudrive@RNP como parte da estratégia de lançamento do serviço pela
RNP<https://edudrive.rnp.br/>
Com a grande quantidade de provedores de serviços presentes em uma federação, uma demanda cada vez maior para integração de novas instituições que visam o com-partilhamento de recursos e serviços entre si e a necessidade de controlar o acesso dos usuários a serviços, definindo políticas de controle de acesso com granularidade fina e delegando o gerenciamento do controle de acesso. É exatamente nesse contexto que o FACS se apresenta como uma opção interessante.
1.2
Objetivos
A fim de superar as limitações apresentadas anteriormente, esse trabalho tem como objetivo geral implementar uma nova versão do FACS, utilizando um servidor de autorização para gerenciamento de políticas de controle de acesso.
Como objetivos específicos, pretende-se (1) realizar a introdução de XACML para definição de políticas de controle de acesso com granularidade fina; (2) externalizar o gerenciamento de políticas de controle de acesso através da integração do FACS a um servidor de autorização para delegar a funcionalidade de gerenciamento de políticas e; (3) integrar o FACS a outro Provedor de Serviço para controlar o acesso a seus recursos e serviços a fim de validar as mudanças propostas.
1.3
Metodologia
A fim de permitir a realização deste trabalho, inicialmente será realizado um estudo sobre conceitos básicos em Controle de Acesso e Gestão de Identidades, bem como modelos, mecanismos e tecnologias, como o Controle de Acesso Baseado em Atributos, o Modelo de Gestão de Identidades Federado e a tecnologia XACML. Tal estudo torna-se importante, devido a necessidade de conhecer as diferentes formas de controle de acesso que podem ser utilizadas por provedores de serviço, bem como entender o funcionamento do modelo de gestão de identidades federadas e as tecnologias que o implementam.
Em seguida, será feito um estudo sobre o FACS, analisando o cenário no qual ele foi proposto, sua arquitetura, funcionalidades e características, destacando seus problemas e limitações. Esse estudo fornecerá um melhor conhecimento sobre o sistema. Posteriormente uma nova versão do FACS, utilizando XACML e integrando a um servidor de autorização e a um Provedor de Serviço, será implementada.
Logo após, a fim de avaliar o novo sistema desenvolvido, será realizada uma avaliação experimental, testando a definição de políticas de controle de acesso no FACS em diferentes cenários de controle de acesso em uma federação. Por fim, será realizado um estudo da literatura a fim de identificar trabalhos que apresentem métodos e ferramentas de controle
de acesso em ambientes federados, apontando suas semelhanças e diferenças em relação ao FACS.
O restante deste trabalho está organizado da seguinte forma: O capítulo 2 apresenta um estudo dos temas envolvidos na realização deste trabalho, como Controle de Acesso, XACML e Gerenciamento de Identidades; O capítulo 3 aborda o FACS, apresentando suas principais funcionalidades e arquitetura, além de expor algumas das suas limitações; O capítulo 4 apresenta a solução para os problemas apresentados, detalhando a introdução de XACML e a implementação do novo FACS; O capítulo 5 avalia a solução proposta, discutindo alguns cenários para utilização do FACS integrado com XACML para definição de políticas de controle de acesso para o CloudStack; O capítulo 6 discute trabalhos relacionados; Por fim, o capítulo 7 apresenta algumas considerações do trabalho realizado.
2 Fundamentação Teórica
Este capítulo apresenta os conceitos e discussões dos assuntos de segurança
pertinen-tes para realização deste trabalho, com base nos trabalhos (SANDHU; SAMARATI,1994),
(SAMARATI; VIMERCATI, 2001), (HU; FERRAIOLO; KUHN, 2006), (ANSI, 2004)
e (OASIS, 2013). Na primeira seção são apresentados conceitos, mecanismos, modelos
e tecnologias relacionados a Controle de Acesso, destacando o modelo de Controle de Acesso Baseado em Atributos (Attribute Based Access Control - ABAC). Na segunda seção a Linguagem de Marcação de Controle de Acesso Extensível (eXtensible Access Control Markup Language - XACML) é abordada. Por fim, na terceira seção são abordados conceitos e modelos referentes a Gerenciamento de Identidades, apresentando o Modelo de Gestão de Identidades Federadas e tecnologias que o implementam.
2.1
Controle de Acesso
Controle de acesso consiste no processo de mediação de todas as solicitações de acesso a recursos e serviços em um sistema, determinando se elas devem ser concedidas ou negadas, garantindo que somente as solicitações autorizadas sejam permitidas
(SAMA-RATI; VIMERCATI, 2001). O Controle de Acesso procura limitar o acesso de usuários a
um sistema, restringindo as ações que usuários legítimos podem realizar diretamente e
impedindo ações de usuários não autorizados (SANDHU; SAMARATI, 1994).
Proteger o acesso a recursos em um sistema contra solicitações não autorizadas ou impróprias é um requisito de segurança fundamental para qualquer sistema que deseja garantir a confidencialidade, integridade e disponibilidade de seus serviços e informações. Confidencialidade é a garantia de que apenas entidades autorizadas terão acesso aos recursos protegidos, enquanto integridade garante a consistência das informações contra modificações não autorizadas e disponibilidade mantém o sistema sempre disponível para
usuários legítimos e autorizados (SAMARATI; VIMERCATI, 2001).
O nível de proteção a ser implantado em um sistema depende dos requisitos de segurança especificados no projeto. Em algumas aplicações, um controle de acesso simples é suficiente, como a concessão total de acesso uma vez que um usuário está autenticado. Contudo, outras aplicações com recursos mais sensíveis, como aplicações governamentais, empresas e grandes corporações, exigem um controle de acesso mais complexo e sofisticado com regras mais elaboradas, dependendo de múltiplos fatores e mecanismos de proteção
contra falhas (HU; FERRAIOLO; KUHN,2006).
compo-nente confiável e inviolável responsável por interceptar as requisições de acesso a recursos e aplicar as politicas de segurança especificadas. Assim, controlando todo o acesso no sistema, o controle de acesso procura prevenir a execução de atividades que possam levar a falhas de segurança e comprometam o funcionamento de um sistema, afetando a confidencialidade, integridade e disponibilidade dos serviços e informações fornecidos
(SANDHU; SAMARATI,1994).
2.1.1
Autenticação, Autorização e Auditoria
Contudo, controle de acesso não é uma solução completa e isolada para garantir a segurança dos recursos de um sistema, ele deve ser integrado a outros serviços de segurança. O controle de acesso depende e coexiste com os serviços de autenticação, autorização e
auditoria (SANDHU; SAMARATI,1994).
Autenticação é o serviço de segurança responsável por estabelecer corretamente a identidade dos usuários, verificando a autenticidade e validade da identidade fornecida por um usuário. Tal serviço consiste de um dos primeiros recursos que um sistema apresenta para proteger suas informações, sendo essencial para garantir o sucesso dos demais serviços, uma vez que autorização e auditoria são realizados com base na identidade do usuário interagindo com o sistema.
Autorização, por sua vez, estabelece regras de acesso a recursos, definindo os direitos de acesso dos usuários sobre os recursos do sistema. Acesso a recursos deve ser permitido somente quando explicitamente especificado e concedido. O comportamento padrão para acesso a recursos é negar. Assim, caso uma solicitação de acesso seja feita e uma regra não esteja devidamente especificada, a solicitação deve ser rejeitada (SANDHU; SAMARATI, 1994).
Por fim, auditoria monitora e registra todos os eventos relevantes que ocorrem no sistema, como tentativas de autenticação, requisições de acesso a recursos e execução de ações. As informações registradas são utilizadas posteriormente para investigar falhas de segurança, analisar o comportamento dos usuários a fim de identificar atividades suspeitas e avaliar possíveis brechas de segurança. Através da auditória é possível inibir os usuários a realizarem atividades que possam comprometer o funcionamento do sistema e
responsabiliza-los pelas suas ações (SANDHU; SAMARATI, 1994).
Este trabalho está focado em aspectos relacionados a autorização.
2.1.2
Modelos, Mecanismos e Políticas
O projeto, desenvolvimento e execução de um serviço de controle de acesso envolve os conceitos de políticas, mecanismos e modelos de segurança. Políticas são diretrizes gerais que especificam como o acesso deve ser determinado e controlado, determinando quem
pode acessar o que sobre quais circunstâncias, enquanto mecanismos representam funções de hardware e software que implementam as políticas, tornando possível a aplicação das regras por elas definidas. Modelos de segurança são representações formais de políticas, utilizados para, teoricamente, analisar, avaliar e provar limitações e capacidades de um
sistema de controle de acesso (SANDHU; SAMARATI,1994).
Políticas de controle de acesso são criadas a partir de políticas de segurança do ambiente do qual o sistema fará parte, que devem ser interpretadas e traduzidas em políticas de controle de acesso bem definidas e não ambíguas a serem aplicadas em um sistema. Contudo, muitas vezes políticas do mundo real são ambíguas e complexas, no qual decisões de acesso dependem da aplicação de diferentes regras e fatores, como leis, normas institucionais e condições ambientes (como data e local). Assim, políticas de controle de acesso devem ser especificadas visando abranger todos os requisitos de segurança estabelecidos, contemplando todas as políticas da organização e possíveis falhas
de segurança decorrentes do uso do sistema (SAMARATI; VIMERCATI, 2001).
A especificação de políticas e o projeto de um sistema de controle de acesso como um todo, requerem a identificação e mapeamento das entidades envolvidas, que são classificadas em sujeitos, objetos e ações. Os objetos representam os recursos a serem protegidos e as ações representam as operações disponíveis e permitidas de serem executadas sobre cada objeto. Os sujeitos representam entidades ativas, nas quais os usuários serão mapeados, responsáveis por iniciar atividades no sistema, solicitando acesso para executar ações sobre os objetos.
Políticas definidas no escopo de um sistema dificilmente teriam utilidade ou asse-gurariam a segurança de outro sistema, devido as diferentes características e requisitos de segurança de cada um, sendo específicas no contexto em que foram definidas. Assim como sujeitos, objetos e ações, que são exclusivos de cada ambiente, no qual sistemas distintos possuem diferentes recursos a serem protegidos, com diferentes operações que podem ser executadas sobre cada um e diferentes sujeitos que podem solicitar acesso (SANDHU;
SAMARATI, 1994).
Um aspecto importante no controle de acesso é o gerenciamento do controle de acesso em si. A especificação e definição de políticas administrativas estabelece quem está capacitado a gerenciar as permissões dos sujeitos sobre os objetos, ou seja, quem é responsável por definir e gerenciar as politicas de controle de acesso. Essas podem ser centralizadas quando uma autoridade central ou grupo é responsável por administrar as políticas de controle de acesso, hierárquica e descentralizado quando uma autoridade pode delegar capacidades administrativas a outros indivíduos, ou cooperativa quando a definição
de políticas depende da decisão de múltiplas autoridades (SANDHU; SAMARATI,1994).
Modelos fornecem uma representação simplificada de politicas, facilitando a
variedade de modelos são propostos pela literatura para atender as diferentes necessidades de controle de acesso de diversos sistemas em diferentes contextos. De uma forma geral, os principais modelos propostos pela literatura são o Controle de Acesso Baseado em Papeis (Role Based Access Control - RBAC) e o Controle de Acesso Baseado em Atributos
(Attribute Based Access Control - ABAC)1.
O RBAC requer a identificação de um conjunto de papeis, que representam as diferentes atividades e responsabilidades organizacionais que usuários tem no sistema. A cada usuário é atribuído um papel e a cada papel é atribuído um conjunto de privilégios que especificam as ações permitidas para cada objeto no sistema. Assim, o acesso é controlado com base no papel que um usuário possui no sistema, permitindo especificar as permissões de grupos de usuários ao invés de cada usuário individual. Nesse modelo, múltiplos papeis podem ser concedidos a um único usuário, representando as diferentes responsabilidades que ele possui, ou os papeis podem ser estruturados de uma forma hierárquica, no qual
permissões são herdadas (ANSI, 2004).
Por outro lado, o ABAC consiste de um modelo de controle de acesso no qual o acesso é controlado com base na avaliação de atributos dos sujeitos e objetos envolvidos em uma solicitação de acesso, bem como dos atributos da operação requisitada e condições ambiente no momento da solicitação. Tais atributos podem ser atribuídos às entidades no momento de sua criação e gerenciados posteriormente. Assim, o ABAC permite um controle de acesso mais granular e preciso, na medida em que políticas de controle de acesso são definidas contemplando os atributos associados a cada entidade envolvida, possibilitando uma maior combinação na definição de regras de acesso, as quais são limitadas apenas
pela linguagem computacional e atributos disponíveis (HU et al., 2014).
O modelo ABAC foi padronizado pelo NIST em (HU et al., 2014), o qual define
uma arquitetura padrão que um sistema ABAC deve adotar. Essa arquitetura define um conjunto de componentes funcionais, especificando seus relacionamentos e responsabilidades.
Assim, conforme pode ser visto na Figura 1, os componentes funcionais definidos são o
Ponto de Decisão de Política (Policy Decision Point - PDP), o Ponto de Aplicação de Política (Policy enforcement Point - PEP), o Ponto de Administração de Política (Policy Administration Point - PAP) e o Ponto de Informação de Política (Policy Information Point - PIP)2.
O PDP é o componente responsável pela tomada de decisões, determinando se uma determinada requisição de acesso a recursos no sistema deve ser concedida ou negada a partir da avaliação das políticas definidas com os atributos da requisição. O PEP é
1 Deste momento em diante utilizaremos os termos RBAC e ABAC para nos referirmos a Controle de
Acesso Baseado em Papeis e Controle de Acesso Baseado em Atributos
2 Deste momento em diante utilizaremos os termos PDP, PEP, PAP e PIP para nos referirmos a Ponto
de Decisão de Política, Ponto de Aplicação de Política, Ponto de Administração de Política e Ponto de Informação de Política
Figura 1 – Componentes Funcionais do ABAC (HU et al., 2014).
componente responsável por proteger o acesso a recursos em um sistema, interceptando ou recebendo as requisições de acesso a recursos por parte dos usuários e aplicando as decisões tomadas pelo PDP. O PAP é o componente responsável pelo gerenciamento das políticas de controle de acesso, que são armazenadas no Repositório de Políticas (Policy Repository), e por fornecer uma interface para gerenciamento de políticas. Por fim, o PIP é o componente responsável pelo gerenciamento dos atributos das entidades envolvidas no contexto do controle de acesso, que são armazenados no Repositório de Atributos (Attribute Repository), e sempre que o PDP precise de mais atributos para avaliar a requisição, ele consulta o PIP.
Além disso, também é definido um componente opcional, o Context Handler, responsável principalmente por coordenar a comunicação entre os demais componentes, definindo a ordem na qual políticas e atributos são recuperados e realizando a conversão das requisições na sua forma nativa para o formato canônico (ex.: XACML) e vice-versa. Por fim, em um cenário real, cada sistema emprega seu próprio serviço de controle de acesso, adotando e adaptando os modelos e mecanismos sugeridos na literatura a suas próprias necessidades para atender seus requisitos. O tipo de controle de acesso utilizado em um sistema pode ser resultado da adoção e adaptação de um único modelo, ou pode consistir da combinação de múltiplos modelos.
2.2
XACML
XACML (eXtensible Access Control Markup Language) é um padrão aberto baseado
em XML (eXtensible Markup Language), especificado e publicado pela OASIS3, que define
uma tecnologia para gerenciamento de controle de acesso, permitindo a gestão de direitos de acesso e avaliação e aplicação de políticas de controle de acesso. Baseado no ABAC, o controle de acesso em XACML é feito com base nos atributos das entidades envolvidas em um determinado contexto de autorização. Sua especificação, atualmente na versão 3
(OASIS, 2013), versão abordada e utilizada no presente trabalho, define toda a estrutura
necessária para gerenciamento e aplicação de políticas de controle de acesso, incluindo três artefatos principais: uma arquitetura de referência, uma linguagem para definição de políticas e uma linguagem para troca de mensagens de autorização.
Juntamente com a linguagem para troca de mensagens de controle de acesso e a linguagem para representação de políticas, é definido um conjunto padrão de entidades, seus atributos e tipos de dados, bem como funções para combinação de valores. As entidades definidas, também chamadas de categorias de atributos, são sujeito (subject), recurso (resource), ação (action) e ambiente (environment). Para cada uma dessas entidades é definido um conjunto de atributos que podem ser utilizados e seus tipos de dados. A
Tabela1 apresenta as entidades e alguns de seus atributos.
Tabela 1 – Entidades a alguns de seus atributos definidos no padrão XACML.
Entidade Atributo subject subject-id resource resource-id action action-id environment current-time current-date current-dateTime
A especificação da arquitetura de referência define um conjunto de componentes, suas funcionalidades, a sequência de troca de mensagens (fluxo de dados), bem como alguns poucos detalhes de implementação. Como XACML implementa o modelo ABAC, sua arquitetura contempla os mesmos componentes definidos pela publicação do NIST
(HU et al., 2014), possuindo as mesmas responsabilidades e funcionalidades, conforme
pode ser visto na Figura 2.
Assim, conforme a figura, o PAP deve fornecer uma interface para que as politicas sejam acessadas pelo PDP (Passo 1). Toda vez que um sujeito faz uma requisição ao sistema para executar uma ação sobre um recurso, essa requisição chega no PEP ou é interceptada por ele (Passo 2). O PEP, por sua vez, monta uma requisição no seu formato padrão
Figura 2 – Arquitetura padrão e fluxo de dados do XACML (OASIS, 2013).
com as informações da requisição, e envia ao Context Handler (Passo 3). Uma vez que a requisição enviada pelo PEP chega ao Context Handler, ele extrai os atributos e monta uma requisição XACML (XACML Request) para enviar ao PDP (Passo 4). Recebendo a XACML Request, o PDP é responsável por selecionar e aplicar as políticas definidas sobre os atributos da requisição, tomando a decisão de permitir ou negar a requisição em questão. As políticas são recuperadas do PAP, e caso precise de mais atributos o PDP solicita ao Context Handler (Passo 5) que, por sua vez, consulta o PIP para recuperar os atributos solicitados (Passo 6). O PIP por sua vez, é responsável por recuperar os atributos das entidades envolvidas, nesse caso, atributos do sujeito (Passo 7a), ambiente (Passo 7b) e recurso (Passo 7c), e retorna os atributos ao Context Handler (Passo 8).
Tendo tomado uma decisão, o PDP envia uma resposta XAMCL (XACML Response) para o Context Handler (Passo 11) que converte a requisição para o formato nativo do PEP e envia para ele (Passo 12). Por fim, o PEP aplica a decisão tomada pelo PDP, permitindo ou negando o acesso solicitado pelo sujeito e opcionalmente, caso presente, aplica obrigações estabelecidas (Passo 13).
A comunicação entre os componentes, mais especificamente entre o PDP e o Context Handler ou entre o PDP e o PEP (quando esses se comunicam diretamente), ocorre através da troca de mensagens em XML, no formato definido pela linguagem de requisição/resposta especificado no padrão XACML. Nessa linguagem, uma XAMCL Request consiste de um conjunto de atributos, suas categorias, tipos de dados e valores enviado ao PDP. Já uma XACML Response representa a decisão tomada pelo PDP e a resposta a uma XAMCL Request, podendo ser: Permitir (Permit), quando a solicitação de acesso é liberada; Negar (Deny), quando a solicitação de acesso é negada; Não Aplicável (Not Applicable), quando não foi possível encontrar nenhuma política que pudesse ser aplicada; Indeterminado (Indeterminate), quando ocorreu algum erro no processamento.
A Listagem 2.1 apresenta um exemplo de XACML Request. Essa requisição é
formada por um atributo de cada entidade. Na linha 1 é feita a declaração de um elemento padrão de um documento XML, indicando a versão do XML sendo utilizada. Na linha 2 é feita a declaração da requisição com o elemento Request, os atributos do tipo booleano obrigatórios CombinedDecision e ReturnPolicyIdList, e o atributo xmlns especificando o namespace do documento XML para a versão 3 do XACML. O atributo CombinedDecision é utilizado para informar ao PDP se ele deve combinar múltiplas decisões em uma única decisão. Já o atributo ReturnPolicyIdList especifica se a lista de políticas utilizadas para tomar a decisão deve ser retornada pelo PDP. Ambos os atributos são definidos para falso (false).
Das linhas 2 a 21 é feita a declaração dos atributos das entidades enviados na requisição. Cada elemento Attributes nas linhas 2, 7, 12 e 17 representa um conjunto de atributos de uma entidade específica. O atributo Category específica a entidade cujos atributos pertencem. No exemplo apresentado são enviados atributos do sujeito (urn:oasis :names:tc:xacml:1.0:subject-category:access-subject), ação (urn:oasis:names:tc:xacml:3.0:a ttribute-category:action), recurso (urn:oasis:names:tc:xacml:3.0:attribute-category:resource ) e ambiente (urn:oasis:names:tc:xacml:3.0:attribute-category:environment), nessa ordem.
Dentro do elemento Attributes são especificados os atributos de cada entidade, através do elemento Attribute, o qual representa um único atributo. Esse elemento é acompanhado por dois atributos, o IncludeInResult e AttributeId. O IncludeInResult é um atributo booleano que especifica se o atributo da entidade deve ser incluído na resposta da requisição, enquanto o AttributeId especifica o identificador do atributo sendo utilizado. No exemplo, é enviado um atributo para cada entidade, sendo o identificador do sujeito (u rn:oasis:names:tc:xacml:1.0:subject:subject-id), o identificador da ação (urn:oasis:names: tc:xacml:1.0:action:action-id), o identificador do recurso (urn:oasis:names:tc:xacml:1.0: resource:resource-id) e hora do ambiente (urn:oasis:names:tc:xacml:1.0:environment:cu rrent-time). O elemento AttributeValue dentro de cada elemento Attribute, nas linhas 4, 9, 14 e 19, especifica o valor de cada atributo, com o atributo DataType desse elemento
especificando o tipo de dados. Por fim, o valor de cada atributo na requisição é alice para o identificador do sujeito, access para o identificador da ação, history para o identificador do recurso e 12:36:25 para a hora do ambiente.
1 <?xml version="1.0" encoding="UTF-8"?>
2 <RequestCombinedDecision="false"ReturnPolicyIdList="false"xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
3 <AttributesCategory="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
4 <Attribute IncludeInResult="false" AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">
5 <AttributeValueDataType="http://www.w3.org/2001/XMLSchema#string">alice</AttributeValue>
6 </Attribute>
7 </Attributes>
8 <AttributesCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
9 <Attribute IncludeInResult="false" AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id">
10 <AttributeValueDataType="http://www.w3.org/2001/XMLSchema#string">access</AttributeValue>
11 </Attribute>
12 </Attributes>
13 <AttributesCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
14 <Attribute IncludeInResult="false" AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">
15 <AttributeValueDataType="http://www.w3.org/2001/XMLSchema#string">history</AttributeValue>
16 </Attribute>
17 </Attributes>
18 <AttributesCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:environment">
19 <Attribute IncludeInResult="false" AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-time">
20 <AttributeValueDataType="http://www.w3.org/2001/XMLSchema#time">12:36:25</AttributeValue>
21 </Attribute>
22 </Attributes>
23 </Request>
Listagem 2.1 – Exemplo de uma XACML Request.
A Listagem2.2apresenta um exemplo de XACML Response. Nesse exemplo o valor
retornado pelo PDP é Deny. Na linha 1 é feita a declaração da versão do XML sendo utilizada. Na linha 2 é feita a declaração da resposta com o elemento Response e o atributo xmlns especificando o namespace do documento XML para a versão 3 do XACML. Na linha 2 é declarado o resultado da resposta com o elemento Result. No escopo do elemento Result são declarado dois elementos, o Decision e o Status. O elemento Decision contém a decisão tomada pelo PDP, nesse caso Deny. Já o elemento Status é opcional e representa o status da requisição, indicando se ocorreu algum erro durante a avaliação da requisição e informações sobre o erro.
1 <?xml version="1.0" encoding="UTF-8"?>
2 <Response xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
3 <Result>
4 <Decision>Deny</Decision>
5 <Status>
6 <StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok" />
7 </Status>
8 </Result>
9 </Response>
Listagem 2.2 – Exemplo de uma XACML Response.
Assim como as mensagens trocadas, as políticas também são definidas em XML através da linguagem para definição de políticas de controle de acesso especificada pelo padrão XACML. Uma representação esquemática, demostrando o relacionamento dos
principais elementos dessa linguagem pode ser vista na Figura 3. Conforme visualizado na figura, alguns desses elementos são, uma Policy, que representa uma única política de controle de acesso, enquanto um PolicySet representa um conjunto de políticas de controle de acesso, contendo uma ou mais Policy(ies). Por sua vez, uma Policy deve apresentar uma ou mais Rule(s), a qual especifica uma única regra de acesso e possui um único Effect, podendo ser Permit (Permitir) ou Deny (Negar). O Target é um elemento que especifica a aplicabilidade de uma política, estabelecendo em que situações ela deve ser aplicada.
O uso do Target é obrigatório, tanto a nível de uma Policy quanto a nível de um PolicySet, e opcional a nível de uma Rule. Um Target pode conter um ou mais elementos AnyOf, utilizado para montar uma sequência disjuntiva de elementos AllOf, que por sua vez é utilizado para montar uma sequência conjuntiva de elementos Match (não mostrado na figura). O Match é utilizado para combinação de valores de atributos no contexto de uma requisição enviada pelo ContextHandler. Ele deve conter um elemento AttributeValue, o qual especifica o valor de um atributo, e deve conter um elemento AttributeDesignator ou um elemento AttributeSelector, utilizados para recuperar uma bag de valores de atributos de uma requisição.
Figura 3 – Representação esquemática da linguagem de políticas do XAMCL (OASIS, 2013).
Além do Target, uma Rule pode conter um elemento Condition, que representa uma função booleana sobre atributos ou funções de atributos. Assim como o Target, uma Condition é utilizada também para definir a aplicabilidade de uma Rule, contudo, um elemento Condition é mais poderoso, na medida em que permite a comparação entre atributos de diferentes entidades. Um elemento que uma Condition pode conter é o Apply (não mostrado na figura), o qual é utilizado para aplicação de funções.
Como um PolicySet pode conter uma ou mais Policy(ies) e uma Policy pode conter uma ou mais Rule(s), o Policy Combining Algorithm e o Rule Combining Algorithm, definem como Policy(ies) devem ser combinadas em um PolicySet e como Rule(s) devem ser combinadas em uma Policy, respectivamente. Por fim, Obligation(s) e Advice(s) representam restrições adicionais que o PEP deve cumprir antes de aplicar a decisão tomada pelo PDP. O cumprimento das restrições em uma Obligation é obrigatório, enquanto que o cumprimento das restrições em um Advice é opcional. Ambos os elementos podem ser definidos a nível de uma Policy, PolicySet ou Rule.
A Listagem 2.3 apresenta um exemplo de uma política em XACML. Essa política
em questão, especifica que o sujeito Alice pode acessar seu histórico somente entre as 8h e às 18h. Nesse exemplo, na linha 1 é feita a declaração da versão do XML sendo utilizada. Das linhas 2 a 6 é feito o início da declaração da política com o elemento Policy, juntamente com um conjunto de atributos XML obrigatórios para esse elemento. O atributo xmlns especifica o namespace do documento XML para a versão 3 do XACML, o atributo PolicyId especifica o identificador da política, o atributo RuleCombiningAlgId especifica o Rule Combining Algorithm que será aplicado para combinação dos elementos Rule na política e o atributo Version indica a versão da política.
1 <?xml version="1.0" encoding="UTF-8"?> 2 <Policy 3 xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" 4 PolicyId="policy1" 5 RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" 6 Version="1.0">
7 <Description>Alice pode acessar seu histórico somente no horário de trabalho</Description>
8 <Target>
9 <AnyOf>
10 <AllOf>
11 <MatchMatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
12 <AttributeValueDataType="http://www.w3.org/2001/XMLSchema#string">alice</AttributeValue>
13 <AttributeDesignator
14 AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
15 Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
16 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>
17 </Match>
18 <MatchMatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
19 <AttributeValueDataType="http://www.w3.org/2001/XMLSchema#string">access</AttributeValue>
20 <AttributeDesignator
21 AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
22 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"
23 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>
24 </Match>
25 </AllOf>
27 </Target>
28 <Rule Effect="Permit" RuleId="Permit-Rule">
29 <Target>
30 <AnyOf>
31 <AllOf>
32 <MatchMatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
33 <AttributeValueDataType="http://www.w3.org/2001/XMLSchema#string">history</AttributeValue>
34 <AttributeDesignator
35 AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
36 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
37 DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>
38 </Match>
39 </AllOf>
40 </AnyOf>
41 </Target>
42 <Condition>
43 <ApplyFunctionId="urn:oasis:names:tc:xacml:1.0:function:and">
44 <ApplyFunctionId="urn:oasis:names:tc:xacml:1.0:function:time-greater-than">
45 <ApplyFunctionId="urn:oasis:names:tc:xacml:1.0:function:time-one-and-only">
46 <AttributeDesignator
47 AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-time"
48 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment"
49 DataType="http://www.w3.org/2001/XMLSchema#time" MustBePresent="true"/>
50 </Apply>
51 <AttributeValueDataType="http://www.w3.org/2001/XMLSchema#time">08:00:00</AttributeValue>
52 </Apply>
53 <ApplyFunctionId="urn:oasis:names:tc:xacml:1.0:function:time-less-than">
54 <ApplyFunctionId="urn:oasis:names:tc:xacml:1.0:function:time-one-and-only">
55 <AttributeDesignator
56 AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-time"
57 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment"
58 DataType="http://www.w3.org/2001/XMLSchema#time" MustBePresent="true"/>
59 </Apply>
60 <AttributeValueDataType="http://www.w3.org/2001/XMLSchema#time">18:00:00</AttributeValue>
61 </Apply>
62 </Apply>
63 </Condition>
64 </Rule>
65 <Rule Effect="Deny" RuleId="Deny-Rule"/>
66 </Policy>
Listagem 2.3 – Exemplo de uma política em XACML.
Na linha 7 é feita a descrição da política com o elemento Description. Das linhas 8 a 27 é feita a declaração do elemento Target com o elemento AnyOf especificando uma sequência disjuntiva de elementos AllOf, que por sua vez especifica uma sequência conjuntiva de elementos Match. Cada Match contém um AttributeValue e um AttributeDesignator. Um AttributeValue contém o valor do atributo sendo utilizado e o atributo XML obrigatório DataType especificando o tipo de dados do valor. Um AttributeDesignator especifica qual atributo de qual entidade está sendo utilizado, através dos atributos XML obrigatórios AttributeId e Category. O atributo XML obrigatório DataType, assim como no elemento AttributeValue, especifica o tipo de dados do atributo. Por fim, o atributo XML obrigatório MustBePresent, determina se deve ser retornada uma bag vazia ou Indeterminate caso o atributo especificado não seja encontrado na requisição.
Para o exemplo, o Target da política especifica que ela deve ser aplicada somente a requisições cujos atributo identificador (urn:oasis:names:tc:xacml:1.0:subject:subject-id ) do sujeito (urn:oasis:names:tc:xacml:1.0:subject-category:access-subject) tiver o valor alice e o atributo identificador (urn:oasis:names:tc:xacml:1.0:action:action-id) da ação (ur
n:oasis:names:tc:xacml:3.0:attribute-category:action) tiver o valor access. Caso isso seja verdadeiro, a política é aplicada a uma requisição e o restante dela é avaliado.
O restante do corpo da política é formado por dois elementos Rule, um declarado entres as linhas 28 e 64 e outro na linha 65. Cada um contém o atributo XML obrigatório Effect, com o primeiro tendo seu valor definido para Permit e o segundo para Deny. O atributo XML obrigatório RuleId especifica o identificador da Rule. O primeiro elemento Rule é formado por outros dois elementos, um Target e um Condition. O Target refina a aplicabilidade da Rule somente para requisições que contém o atributo identificador (u rn:oasis:names:tc:xacml:1.0:action:action-id) de ação (urn:oasis:names:tc:xacml:3.0:att ribute-category:action) com valor history. Já o elemento Condition refina ainda mais a aplicabilidade da Rule, utilizando elementos Apply para aplicar funções de comparação de tempo do XACML e o elemento AttributeDesignator para referencia o atributo da hora atual. Assim, esse elemento Condition especifica que a Rule deve ser aplicada somente a requisições que contenham o atributo hora atual (urn:oasis:names:tc:xacml:1.0:environme nt:current-time) do ambiente (urn:oasis:names:tc:xacml:3.0:attribute-category:environme nt) e o seu valor esteja entre os valores 08:00:00 e 18:00:00 horas. O segundo elemento Rule é vazio.
Por fim, caso alguma requisição realizada satisfaça as condições do elemento Target da política e não atendas as condições estabelecidas no primeiro elemento Rule, ou seja as condições estabelecidas no elemento Target ou as condições estabelecidas no elemento Condition não sejam satisfeitas, o segundo elemento Rule é avaliado em sequência. Como esse elemento não possui corpo (é vazio), suas condições sempre serão verdadeiras e ele sempre será aplicado caso o primeiro não seja, e como seu efeito é negar, o resultado da política para essas requisições será sempre negar.
Uma das caraterística do XACML é sua capacidade de extensão, podendo ser estendida de várias formas, facilitando sua introdução em diferentes contextos, com a própria especificação apresentando uma seção na qual lista seus pontos de extensão. Por exemplo, embora defina um conjunto padrão de entidades, seus atributos, tipos de dados e funções para combinação de atributos, novos elementos podem ser facilmente adicionados a uma implementação.
Uma das formas de estender o XACML é por meio de perfis. Um perfil XACML (XACML profile) é uma proposta de extensão na especificação padrão que define como utilizar XACML em um cenário específico, estabelecendo as melhores práticas para sua utilização, propondo mudanças na arquitetura padrão com a adição de novos componentes ou a modificação dos existentes, ou com a definição de novos elementos para as linguagens de definição de políticas e troca de mensagens. Vários perfis já foram e continuam a ser propostos. Alguns exemplos de perfis são o SAML Profile, que especifica como utilizar XACML em uma federação SAML, o RBAC Profile, que especifica como utilizar XACML
junto com RBAC e o Privacy Policy Profile que especifica como garantir a privacidade dos usuários na utilização do XAMCL.
O RBAC Profile, por exemplo, especifica como escrever políticas que satisfaçam os requisitos do Core RBAC e do Hierarchical RBAC da especificação RBAC do ANSI (ANSI, 2004). Para tanto, esse perfil define um novo atributo para representar o papel de um sujeito no sistema e diferences tipos de políticas com estrutura padrão para representar o relacionamento entre sujeitos, papeis e permissões.
2.3
Gerenciamento de Identidades
Gerenciamento de identidades (Identity Management - IdM) consiste de um sistema integrado de políticas, tecnologias e processos de negócios que permite a uma organiza-ção prover serviços de forma segura e garantir a privacidade das informações dos seus
usuários (JOSANG; POPE, 2005). O gerenciamento de identidades é fundamentado
em processos que possibilitam o gerenciamento de todo o ciclo de vida de identidades associadas a entidades em um determinado contexto, utilizando um conjunto de funções e capacidades que permitem a garantia da identidade de uma entidade e das informações contidas nessa identidade, permitindo a realização de transações comerciais de forma
segura (CHADWICK, 2009).
A identificação de um indivíduo em um sistema é essencial para conceder o acesso a recursos e serviços e permitir realização de ações. Assim, o processo de gerenciamento de identidades é fundamental para garantir o sucesso de outros serviços de segurança, como autenticação, autorização, auditoria e controle de acesso, uma vez que eles se baseiam fortemente na identidade de um indivíduo acessando um sistema. Portanto, as informações da identidade de um usuário possibilitam sua autenticação no sistema, a aplicação de regras de autorização e o registro de suas ações.
Todos os usuários que acessam um sistema possuem uma identidade. Uma identidade consiste de um conjunto de informações relacionadas a uma entidade em um determinado contexto, que permite que ela seja identificada unicamente nesse contexto. Uma entidade pode ser uma pessoa ou uma organização, e as informações que compõe a identidade são chamadas de atributos e compreende um conjunto de características da entidade necessárias para sua identificação e realização de ações no sistema. Não existe duas ou mais entidades em um dado sistema com a mesma identidade. Além disso, um indivíduo pode ter mais de uma identidade em um mesmo sistema, por exemplo, um usuário de um sistema de gestão de atividades acadêmicas pode ser tanto aluno como funcionário em uma instituição de ensino, possuindo assim um identidade para cada papel desempenhado
(JOSANG; POPE, 2005).
que podem englobar desde dados pessoais, como nome e idade, a características físicas como dados biométricos, ou cargos ocupados, reponsabilidades e privilégios em uma organização. Cada sistema determina, conforme seus requisitos, as informações necessárias que farão parte da identidade de um indivíduo. De fato, diferentes sistemas podem utilizar as mesmas
informações nas identidades dos seus usuários (WANGHAM et al., 2010).
Um aspecto importante da identidade é o atributo identificador, um atributo capaz de identificar unicamente uma entidade em um domínio, não existindo duas ou mais entidades com o mesmo valor para o atributo identificador, embora possam compartilhar semelhança entre outros atributos. Um identificador está fortemente relacionado ao domínio no qual ele foi definido, no sentido que ele não pode ser movido de forma significativa entre domínios. Assim, diferentes sistemas utilizam diferentes identificadores, podendo haver sistuações nas quais sistemas distintos possam utilizar o mesmo identificador para
identificar diferentes indivíduos (CHADWICK,2009).
Além das entidades, que comumente correspondem a indivíduos que acessam um sistema, e das suas respectivas identidades, um sistema de gerenciamento de identidades engloba também um ou mais Provedor de Identidades (Identity Provider - IdP), um componente confiável responsável por gerenciar identidades e autenticar usuários, e um ou
mais Provedores de Serviço (Service Provider - SP) 4, um componente que disponibiliza
recursos e serviços a usuários. Nesse contexto, a comunicação entre IdP e SP ocorre através da troca de mensagens, por meio das quais o IdP é responsável por emitir mensagens contendo credenciais de autenticação e autorização de seus usuários a um SP confiável.
Um Sistema de gerenciamento de identidades provê as ferramentas necessárias
para a gestão de identidades. De acordo com (WANGHAM et al., 2010), sistemas de
gerenciamento de identidades podem ser classificados em tradicional (isolado), centralizado, federado ou centrado no usuário.
No modelo tradicional, cada Provedor de Serviço é responsável por, além de oferecer e gerenciar recursos e serviços, gerenciar a identidade de seus usuários, atuando também como um Provedor de Identidade. Nesse modelo, um indivíduo tem múltiplas identidades, cada uma associada a um sistema ao qual ele acessa, tornando necessário de sua parte a memorização de todas as suas identidades, especialmente os atributos identificadores e atributos correspondentes a tokens de autenticação, utilizados pelos sistemas para realização do processo de autenticação.
O modelo centralizado se caracteriza pela presença de um único Provedor de Identidades central em um determinado domínio, responsável pelo gerenciamento de identidades e autenticação dos usuários, no qual todos os Provedores de Serviço devem confiar nas informações emitidas por esse Provedor de Identidade. Nesse modelo há o
4 Deste momento em diante os termos Provedor de Identidade e IdP e Provedor de Serviço e SP serão
conceito de autenticação única (Single Sign On - SSO), no qual usuários se autenticando uma única vez junto ao seu Provedor de Identidade, são capazes de utilizar os demais serviços dos Provedores de Serviço sem precisar se autenticar novamente.
No modelo federado, também chamado de modelo de Gestão de Identidades Fede-radas (Federated Identity Management - FIM), a responsabilidade de gerenciamento de identidades e autenticação de usuários é distribuída entre múltiplos Provedores de Identi-dades, pertencentes a diferentes domínios administrativos. Um domínio administrativo pode, por exemplo, representar uma instituição, podendo conter um ou mais Provedores de Serviço. Nesse modelo são estabelecidos acordos entre as instituições dos diferentes domínios, formando uma relação de confiança mútua conhecida como federação, permi-tindo que um usuário, proveniente do IdP de um determinado domínio, possa, com uma identidade única, uma vez identificado e autenticado no seu IdP, acessar serviços providos por Provedores de Serviços em outros domínios. Assim como no modelo centralizado, o SSO é inerente ao modelo federado.
No contexto do gerenciamento de identidades federadas, a Linguagem de Marcação para Asserções de Segurança (Security Assertion Markup Language – SAML) é um padrão
aberto baseado em XML, especificado e publicado pela OASIS5, utilizado para troca de
informações de autenticação e autorização entre parceiros de negócio em uma federação. O projeto Shibboleth, iniciativa do consórcio americano Internet2, é um exemplo de sistema que implementa o padrão SAML, permitindo o estabelecimento de uma federação entre aplicações de diferentes domínios para o compartilhamento seguro das informações das identidades dos usuários.
Por fim, embora haja outros modelos de gerenciamento de identidades, como o modelo centrado no usuário, com foco na privacidade dos dados da identidade, no qual o indivíduo tem total controle sobre os seus dados, determinando quais informações da identidade e para quem elas são liberadas, os modelos abordados aqui são comumente os mais utilizados.
2.4
Considerações Finais
Esse capítulo abordou os principais temas envolvidos na realização desse trabalho, apresentando os conceitos fundamentais relacionados a Controle de Acesso e Gerenciamento de Identidades, dois processos de importância vital para garantir a segurança de sistemas, destacando suas principais características, modelos e padrões. Além disso, foi abordado também XACML, um padrão aberto baseado em XML que fornece uma solução completa para controle de acesso com granularidade fina.
Assim, o foco do presente trabalho consiste em propor a utilização de XACML para definição de políticas de controle de acesso em ambientes federados, a partir do desenvolvimento de uma nova versão do FACS. Mais especificamente, o foco está em federações que utilizam o padrão SAML por meio do sistema Shibboleth, como é o caso da Comunidade Acadêmica Federada (CAFe).
3 FACS
Este capítulo apresenta de forma resumida o sistema FACS, que foi apresentado em um artigo do Simpósio Brasileiro em Redes de Computadores e Sistemas Distribuídos
(SBRC) em 2015 (DINIZ et al., 2015). Iniciamos descrevendo uma visão geral do FACS,
sua arquitetura, e concluímos com um breve levantamento de suas limitações.
3.1
Visão Geral
O FACS (Federated Access Control System) é um sistema de controle de acesso hierárquico, proposto para resolver os problemas relacionados a controle de acesso
en-frentados em (DINIZ et al., 2015), na implantação de um serviço de armazenamento de
nuvem em uma federação de identidades na forma de um Provedor de Serviço.
Nesse cenário, o serviço de nuvem, ainda em sua fase experimental, não poderia permitir o acesso de todos os usuários da federação devido à suas capacidades limitadas e modelo de implantação, que consistiu em um modelo comunitário no qual instituições que contribuíam com a capacidade do serviço poderiam selecionar usuários para usufruir das suas funcionalidades.
Contudo, uma vez na federação, um Provedor de Serviço pode ser acessado por qualquer usuário vinculado a qualquer IdP, ficando a cargo do próprio Provedor de Serviço controlar o acesso dos usuários da federação. Desse modo, o FACS foi proposto como uma solução que permita a administradores de SP controla o acesso dos usuários da federação através da definição de políticas de controle de acesso. Além disso, o FACS também permite que administradores de SP deleguem a administradores de IdP a capacidade de gerenciamento de políticas de controle de acesso ao SP.
O FACS foi integrado ao serviço edudrive@RNP1, baseado no ownCloud2, com um
alto nível de acoplamento, e suportando a definição de políticas de controle de acesso com alta-granularidade (tendo sido utilizado inicialmente para se definir quais usuários tem acesso ao serviço).
3.2
Arquitetura do FACS
A arquitetura do FACS é apresentada na figura 4. A esquerda tem-se um Provedor
de Serviço qualquer da federação com seu sistema de controle de acesso retratado segundo
1 <https://edudrive.rnp.br/> 2 <https://owncloud.org/>
os componentes do ABAC. A direita tem-se o FACS propriamente dito. A arquitetura do FACS é composta pelo System Administration Module, IdP Management Module, Access Management Module, SP Adapter e o PDP.
Figura 4 – Arquitetura do FACS (DINIZ et al.,2015).
O System Administration Module é o módulo utilizado pelo administrador do FACS (FACS Admin) para gerenciamento dos Provedores de Identidades, Provedores de Serviços e seus administradores. O IdP Management Module é o módulo utilizado pelos administradores dos Provedores de Serviços (SP Admin) para gerenciar os Provedores de Identidades autorizados a acessarem os serviços. O Access Management Module é o módulo utilizado pelos administradores dos Provedores de Serviço para gerenciamento de políticas de controle de acesso, podendo ser utilizado também pelos administradores de IdP quando o gerenciamento de controle de acesso é delegado pelo SP Admin a eles. Por fim, o SP Adapter é responsável por propagar as políticas definidas no FACS para os Provedores de Serviço no formato compreendido por cada um.
As políticas de controle de acesso gerenciadas pelo FACS são classificadas em dois níveis, políticas independentes de SP e políticas dependentes de SP. As políticas independentes de SP especificam que usuários, de quais instituições podem acessar um determinado Provedor de Serviço, sendo armazenadas no repositório de políticas do FACS. Já as para políticas dependentes de SP estabelecem os privilégios dos usuários nos Provedores de Serviço, sendo propagadas para cada Provedor de Serviço ao qual foram definidas por meio do SP Adapter.
O nível de políticas independentes de SP contempla diferentes formas de acesso, as
quais podem ser vistas na figura 5, que apresenta um fluxograma destacando os cenários
um usuário de um IdP tenta acessar um SP, o PEP do SP irá interceptar a requisição e consultará o PDP para verificará se o usuário está autorizado a acessar o serviço. Caso esteja, o acesso é liberado. Caso contrário, o PEP do SP irá consulta o PDP do FACS questionando se o usuário em questão pode ou não acessar o serviço. O FACS, por sua
vez, irá executar o fluxo da figura5.
Assim, na sua forma mais básica, um IdP não está cadastrado no FACS ou embora esteja cadastrado não foi autorizado a acessar o serviço. Caso algum usuário deste IdP tente acessar o serviço, o acesso será negado. Por outro lado, para um IdP cadastrado no FACS e autorizado a acessar o serviço, há três formas de acesso possíveis: automática, manual e baseado em políticas.
Figura 5 – Fluxo para políticas independentes de SP do FACS (DINIZ et al., 2015).
O modo de acesso automática representa o funcionamento básico de uma federação, no qual usuários de um IdP podem acessar automaticamente um Provedor de Serviço. No modo de acesso manual, quando um usuário tenta acessar um Provedor de Serviço é criada uma solicitação de acesso para ser processada pelo administrador do SP. Por último, no modo baseado em políticas, o acesso dos usuários é controlado com base em políticas definidas pelo administrador do SP. O administrador do IdP também é capaz controlar a acesso dos usuários do seu IdP ao Provedor de Serviço, caso o administrador do SP delegue essa capacidade.
3.3
Limitações
Embora o objetivo do FACS seja gerenciar o controle de acesso de usuários a Provedores de Serviço em uma federação através da definição de políticas de controle de acesso, não foi especificado nenhum padrão para definição de políticas, tanto para políticas dependentes de SP quanto para políticas independentes de SP quando o modo de acesso é definido para baseado em políticas. Além disso, ainda que o FACS tenha sido proposto como um sistema genérico capaz gerenciar o acesso para qualquer Provedor de Serviço
