Instituto Metrópole Digital
Programa de Pós-graduação em Engenharia de Software Mestrado Profissional em Engenharia de Software
SecAuthAPI : Uma abordagem para
suportar infraestruturas de autorização
auto-adaptativas
Welkson Renny de Medeiros
Natal-RN Outubro de 2018
SecAuthAPI: Uma abordagem para suportar
infraestruturas de autorização auto-adaptativas
Dissertação de Mestrado apresentada ao Pro-grama de Pós-graduação em Engenharia de Software da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Engenharia de Software.
Universidade Federal do Rio Grande do Norte – UFRN Instituto Metrópole Digital – IMD
Programa de Pós-Graduação em Engenharia de Software
Orientador: Dr. Carlos Eduardo da Silva
Natal/RN
2018
Medeiros, Welkson Renny de.
SecAuthAPI: Uma abordagem para suportar infraestruturas de autorização autoadaptativas / Welkson Renny de Medeiros. -2018.
90 f.: il.
Dissertação (mestrado) - Universidade Federal do Rio Grande do Norte, Instituto Metrópole Digital, Programa de Pós-Graduação em Engenharia de Software. Natal, RN, 2018.
Orientador: Prof. Dr. Carlos Eduardo da Silva.
1. Controle de acesso Dissertação. 2. Ameaças internas -Dissertação. 3. ABAC - -Dissertação. 4. Sistemas auto-adaptativos - Dissertação. I. Silva, Carlos Eduardo da. II. Título.
RN/UF/BCZM CDU 004.41
Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede
SecAuthAPI: Uma abordagem para suportar
infraestruturas de autorização auto-adaptativas
Dissertação de Mestrado apresentada ao Pro-grama de Pós-graduação em Engenharia de Software da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Engenharia de Software.
Trabalho aprovado. Natal/RN, 30 de outubro de 2018:
Dr. Carlos Eduardo da Silva
Orientador
Dr. Gustavo Henrique Matos Bezerra Motta
Examinador Externo à Instituição
Dr. Sílvio Costa Sampaio
Examinador Interno
Natal/RN
2018
Agradeço primeiramente a Deus, por ter me ajudado a suportar os desafios enfren-tados durante todo o percurso deste trabalho.
A minha família, em especial a Odileide (esposa) e Anny (filha), pelo amor, incentivo e suporte necessário.
Muitas pessoas me ajudaram lá no início, em Cruzeta, e não poderia deixar de citá-las. Renê (primeiro professor de informática/1997), Jucely (primeiro emprego), Seilha (incentivo e apoio na minha mudança para Natal), meu primo Eudes/Bia (livros de
programação e incentivo), entre muitos outros colegas.
Ao pessoal da Focus Automação (Kerginaldo, William, Antônio, André, entre outros), por me incentivar a fazer faculdade (por incrível que pareça, o matuto aqui não queria fazer), e pelos muitos desafios durante os 10 anos que estive com vocês. Muito obrigado!
Aos colegas do IFRN, em especial ao professor André Gustavo, por ter possibilitado o convênio com o IMD, e principalmente por ter me incentivado a fazer o processo seletivo. Agradeço também a Eduardo Egito (o chefe :-) e aos demais colegas da COINRE (redes) e COSINF (sistemas) pelo apoio necessário. Não poderia esquecer de um agradecimento especial para os amigos Diego Saraiva e José Augusto (Gugu), que me apoiaram desde o início nessa empreitada.
Aos colegas do laboratório Stela (Gabi Cavalcante, Gabi Duarte, Irene, Inácia, Lucas, Pedro, Valmir, Kadson, entre muitos outros que passaram por lá). O pessoal no lab respira segurança da informação. Foram 2 anos de muito aprendizado com vocês. Obrigado! Aos colegas de turma do mestrado, em especial a Cesimar (IFZN), Allyson/Renie-re/Tarso (DIGTI) e Jorge (IFCang) pelas muitas discussões no nosso grupo “Mestrandos” no WhatsApp :-) Agradeço também aos demais colegas de turma, em especial ao amigo Cephas Barreto por representar tão bem a turma no colegiado, e pela disposição em contribuir com todos que precisavam.
Agradeço também aos professores do PPGSW! Os conhecimentos compartilhados foram essenciais para a conclusão deste trabalho.
Por fim, agradeço ao meu orientador, o professor Dr. Carlos Eduardo da Silva (Kadu). O ritmo de Kadu é frenético. Foram 2 anos intensos! Muita leitura, escrita, programação, reuniões, mas por gostarmos da área de segurança da informação esse processo apesar de difícil foi bastante divertido. Obrigado amigo!
terá lugar permanente entre os sábios.” (Bíblia Sagrada, Provérbios 15, 31)
Mecanismos de controle de acesso têm sido utilizados em sistemas de informação para restringir o acesso a informações sensíveis. Tais mecanismos são capazes de lidar com ameaças de agentes externos à instituição, porém são ineficientes quando consideramos ataques envolvendo usuários internos. Políticas de controle de acesso estáticas são incapazes de lidar com comportamentos anômalos de usuários maliciosos que abusam de suas permissões. Sistemas auto-adaptativos têm se mostrado como uma possível resposta para esta situação, uma vez que são capazes de analisar a si próprios e ao ambiente em que estão inseridos, e se modificar sobre variadas e imprevisíveis condições. Neste contexto, baseado no comportamento dos usuários, as políticas de controle de acesso poderiam ser dinamicamente modificadas para lidar com usuários maliciosos. Entretanto, a auto-adaptação exige um conjunto de operações bem definidas que possam ser utilizadas na definição de planos de adaptação. Neste sentido, este trabalho propõe o SecAuthAPI, uma abordagem de suporte a infraestruturas de autorização auto-adaptativas baseadas em ABAC(Attribute-Based Access Control). As operações são baseada em uma especificação funcional formal do modelo ABAC e permitem a manipulação dinâmica de políticas de controle de acesso. Considerando a aplicação desta abordagem em um sistema real, este trabalho também propõe e implementa a externalização dos mecanismos de autorização para o sistema SUAP, desenvolvido e usado no IFRN, com intuito de desacoplar o controle de acesso da lógica de negócio da aplicação. As operações do SecAuthAPI foram avaliadas através de testes unitários que atestam a sua aderência à especificação funcional formal, enquanto que a externalização de controle de acesso do SUAP teve seu desempenho avaliado e comparado com a abordagem legada. Os resultados alcançados demonstram que, embora tenha um custo computacional adicional, o impacto no desempenho da aplicação é desprezível. Adicionalmente, nossa solução mostra-se altamente viável diante dos benefícios trazidos pelo desacoplamento de preocupação de controle de acesso do código fonte da aplicação.
Palavras-chave: controle de acesso. ameaças internas. abac. sistemas auto-adaptativos.
self-adaptation of authorization infrastructures
Author: Welkson Renny de Medeiros Supervisor: Dr. Carlos Eduardo da Silva
Abstract
Access control mechanisms have been used in information systems to restrict access to sensitive information. Such mechanisms are able to deal with external agent threats, but they are ineffective when considering attacks involving internal users. Static access control policies are unable to deal with anomalous behavior of malicious users who abuse their permissions. Self-adaptive systems have been shown as a possible response for this situation, since they are able to analyze themselves and the environment in which they are deployed, modifying themselves over various and unpredictable conditions. In this context, based on the behaviour of users, the access control policies could be dynamically modified to deal with malicious users. However, self-adaptation requires a set of well-defined operations that can be used in the definition of adaptation plans. In this sense, this work proposes the SecAuthAPI, an approach to support self-adaptive authorization infrastructures based on ABAC (Attribute-Based Access Control). The operations are based on a formal functional specification of the ABAC model and aim to enable the dynamic adaptation of access control policies. Considering the application of this approach in a real system, this work also proposes and implements the externalization of authorization mechanisms for the SUAP system, developed and used at IFRN, with the intention of decoupling access control concern from the business logic of the application SecAuthAPI operations were evaluated through a series of unit tests that attest its adherence to the formal functional specification, while separation of access control from SUAP had its performance evaluated and compared to the legacy approach. The results show that, although it has an additional computational cost, the impact on application performance is negligible. In addition, our solution is highly feasible in view of the benefits brought due to the decoupling of concern from access control from the source code of the application.
Figura 1 – Tríade AAA (Autenticação, Autorização, Auditoria) . . . 21
Figura 2 – Modelo de referência RBAC Core . . . 22
Figura 3 – Distribuição dos mecanismos de controle de acesso ABAC . . . 23
Figura 4 – Exemplo de aplicação do mecanismo ABAC . . . 24
Figura 5 – Modelo de referência MAPE-K para computação autonômica . . . 26
Figura 6 – Visão de Self-Protection . . . 27
Figura 7 – Arquitetura do controle de acesso do SUAP . . . 28
Figura 8 – Arquitetura de referência do SUAP . . . 29
Figura 9 – Arquitetura do SecAuthAPI . . . 31
Figura 10 – Diagrama de Sequência do SecAuthAPI . . . 33
Figura 11 – Diagrama de Classes do SecAuthAPI . . . 35
Figura 12 – Fases da externalização do controle de acesso . . . 39
Figura 13 – Visão da arquitetura de autorização externalizada para o SUAP . . . . 41
Figura 14 – Arquitetura do DjangoPEP . . . 43
Figura 15 – Diagrama de classes do WSO2-PIP-SUAP . . . 45
Figura 16 – Processo de negócio da Central de Serviços . . . 51
Figura 17 – Intervenção dinâmica em uma política de controle de acesso . . . 54
Figura 18 – Execução dos testes unitários do SecAuthAPI . . . 57
Figura 19 – Proposta de externalização. . . 58
Figura 20 – Infraestrutura para os experimentos de externalização . . . 59
Figura 21 – Demonstração das abordagens de autorização legada e externalizada. . 60
Tabela 1 – API - Operações Administrativas . . . 32
Tabela 2 – Avaliação das pré/pós-condições da API via testes unitários . . . 55
Tabela 3 – Recursos alocados para a infraestrutura de avaliação . . . 60
Tabela 4 – Plano de testes . . . 62
Tabela 5 – Testes de desempenho no SUAP-Legado e SUAP-Externalizado . . . . 63
Tabela 6 – SecAuthAPI: AddPolicy() . . . 85
Tabela 7 – SecAuthAPI: DeletePolicy() . . . 85
Tabela 8 – SecAuthAPI: ModifyPolicy() . . . 86
Tabela 9 – SecAuthAPI: AddAttribute() . . . 87
Tabela 10 – SecAuthAPI: DeleteAttribute() . . . 87
Tabela 11 – SecAuthAPI: ModifyAttribute() . . . 88
Tabela 12 – Testes de desempenho no SUAP-Legado . . . 92
ABAC Attribute-Based Access Control ACPT Access Control Policy Tool
ANSI American National Standards Institute API Application Programming Interface CSRF Cross Site Request Forgery
EMF Eclipse Modeling Framework ELK ElasticSearch-LogStash-Kibana IDP Identity Provider
IDS Intrusion Detection System
IFRN Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte
IPS Intrusion Prevention System JSON JavaScript Object Notation
LDAP Lightweight Directory Access Protocol MAPE-K Monitor-Analyze-Plan-Execute-Knowledge NGAC Next Generation Access Control
NIST National Institute of Standards and Technology NSA National Security Agency
OASIS Organization for the Advancement of Structured Information Standards OIDC OpenID Connect
PAM Pluggable Authentication Modules PAP Policy Administration Point
PBKDF2 Password-Based Key Derivation Function 2 PDP Policy Decision Point
PIP Policy Information Point RBAC Role-Based Access Control REST Representational State Transfer RPE RBAC Policy-Enhanced
SACMAT Symposium on Access Control Models and Technologies SAML Security Assertion Markup Language
SAS Self-Adaptive Systems
SOAP Simple Object Access Protocol SMV Symbolic Model Verification SP Service Provider
SSO Single Sign-On
SUAP Sistema Unificado de Administração Pública TI Tecnologia da Informação
UML Unified Modeling Language
VM Virtual Machine
VPN Virtual Private Network
XACML eXtensible Access Control Markup Language XML eXtensible Markup Language
1 INTRODUÇÃO . . . 14 1.1 Problemática e Motivação . . . 16 1.2 Objetivo . . . 18 1.3 Metodologia . . . 19 1.4 Organização do Documento . . . 19 2 REFERENCIAL TEÓRICO . . . 20 2.1 Controle de Acesso . . . 20 2.2 Sistemas Auto-Adaptativos . . . 25 2.3 SUAP . . . 28 2.4 Discussão . . . 30 3 SECAUTHAPI . . . 31 3.1 Arquitetura . . . 31 3.2 Design . . . 32 3.3 Implementação . . . 34 3.4 Discussão . . . 37
4 EXTERNALIZAÇÃO DOS MECANISMOS DE AUTORIZAÇÃO . . 39
4.1 Proposta de externalização no SUAP . . . 39
4.2 Implementação . . . 41 4.2.1 Arquitetura . . . 41 4.2.2 Implementação do PEP . . . 42 4.2.3 Implementação do PIP . . . 44 4.3 Demonstração. . . 46 4.4 Discussão . . . 50 5 AVALIAÇÃO . . . 51
5.1 SecAuthAPI: Manipulação dinâmica de políticas. . . 51
5.1.1 Preparação do ambiente . . . 52
5.1.2 Demonstração . . . 53
5.1.3 Avaliação da API . . . 55
5.1.4 Discussão . . . 57
5.2 Externalização do controle de acesso no SUAP . . . 58
5.2.1 Preparação do ambiente . . . 58
5.3.2 Experimentos . . . 63
5.3.3 Discussão . . . 64
5.4 Considerações Finais . . . 65
6 TRABALHOS RELACIONADOS . . . 67
6.1 Controle de acesso dinâmico . . . 67
6.2 Externalização de controle de acesso . . . 68
6.3 Ferramentas de controle de acesso em Python . . . 69
6.4 Discussão . . . 71 7 CONSIDERAÇÕES FINAIS . . . 72 7.1 Contribuições . . . 72 7.2 Limitações . . . 73 7.3 Trabalhos futuros . . . 74 REFERÊNCIAS . . . 75
APÊNDICES
81
APÊNDICE A – SECAUTHAPI: ESPECIFICAÇÃO DA API . . . . 82APÊNDICE B – POLÍTICAS XACML . . . 89
B.0.1 Política “New Ticket” . . . 89
B.0.2 Política “Deny New Ticket by User” . . . 90
1 Introdução
Na era da informação, na qual as pessoas utilizam a Internet para efetuar transações comerciais, acessar serviços fornecidos por órgãos públicos, entre outros, é de vital impor-tância que medidas sejam adotadas para que a integridade, o sigilo e a disponibilidade dos dados destes usuários sejam mantidos em segurança. Em uma pesquisa realizada em 2016 pela empresa PWC denominada “Pesquisa Global de Segurança da Informação”
PWC (2016), somente no Brasil houve um aumento de 274% no número de incidentes de segurança da informação reportados. Esse número pode ser ainda maior, considerando que muitas empresas não reportam os ataques sofridos com receio de manchar sua reputação diante do mercado e de seus clientes (KESLER,2011).
Segundo Collins et al. (2016), historicamente as corporações têm investido em mecanismos de segurança como firewall, IDS (Intrusion Detection System), IPS (Intrusion
Prevention System), entre outros, com intuito de se proteger contra ataques envolvendo
ameaças externas, no entanto, os danos causados por ameaças internas são reais e subs-tanciais. Ameaça interna ou Insider Threat é definida pelo CERT SEI1 como um usuário
atuando como funcionário/ex-funcionário, terceirizado, ou parceiro comercial que tem ou teve acesso autorizado a rede, sistemas ou dados, e de forma intencional ou não intencional excede este acesso afetando negativamente a confidencialidade, integridade e disponibili-dade da informação ou dos sistemas de informação da organização, causando prejuízos financeiros, danos a reputação, entre outros (LEGG et al., 2015).
Tradicionalmente, organizações usam infraestruturas de autorização para proteger, controlar e monitorar o acesso aos recursos em sistemas de informação. Entre os principais mecanismos encontrados na literatura, destaca-se o modelo RBAC (Role-Based Access
Control) (ANSI, 2004), que associa permissões a papéis desempenhados pelos usuários nas organizações, e o ABAC (Attribute-Based Access Control) (HU et al.,2014), que considera o uso de atributos do sujeito, ação, recurso e ambiente na definição das políticas de controle de acesso.
Entretanto, os mecanismos de controle de acesso não são capazes de detectar comportamentos anômalos ou desvios comportamentais. A ineficácia dos mecanismos de controle de acesso em lidar com ameaças internas tem contribuído para que cada vez mais a mídia noticie o roubo e exposição de informações sensíveis de instituições governamentais e corporações.
Booth, Brooke e Morris (2010) relata um caso envolvendo vazamento de dados sensíveis realizado por um analista de segurança do Exército Americano, que fez download 1 https://www.cert.org/
de mais de 250 mil documentos sigilosos usando suas credenciais no site do Departamento de Defesa e os publicou na internet. Em 2013, um ex-contratado da NSA copiou mais de um milhão de documentos confidenciais, e vazou para mídia detalhes do funcionamento do programa de vigilância em massa da inteligência americana (GREENWALD, 2014). Na área financeira, um dos casos mais conhecidos ocorreu em 2011 no banco suíço UBS, onde um analista de investimentos utilizou de suas permissões e conhecimento sobre as rotinas do sistema bancário para realizar transações não autorizadas, ocasionando perdas para o banco de aproximadamente 2 bilhões de dólares (YASEEN, 2017).
Um dos desafios em lidar com esses eventos anômalos está relacionado ao fato que os mecanismos de controle de acesso comumente implementados pelas organizações são estáticos. As políticas de controle de acesso definem se um usuário pode ou não acessar determinado recurso no momento da tentativa de acesso. No entanto, não consideram desvios na rotina como acesso a uma grande quantidade de documentos em um curto período de tempo, por exemplo, sendo incapazes de impedir ou mitigar atividades maliciosas desta natureza.
Uma das possíveis abordagens para lidar com essas ameaças são os sistemas auto-adaptativos ou SAS (Self-Adaptive Systems) (HORN,2001). SAS são sistemas autonômicos que monitoram continuamente o contexto em que estão inseridos, e são capazes de ajustar seu comportamento em resposta a mudanças no ambiente (CHENG et al., 2014). O principal modelo de computação autonômica é o loop MAPE-K (Monitor, Analyze, Plan,
Execute, Knowledge) proposto pela IBM (KEPHART; CHESS, 2003). O loop autonômico é composto de um controlador autonômico (Autonomic Manager ) que automatiza algumas funções de gerenciamento, e 4 partes que compartilham conhecimento (Knowledge) e são responsáveis por monitorar, analisar, planejar e executar os planos de auto-adaptação (Monitor, Analyze, Plan e Execute respectivamente) (IBM,2006).
Em relação a segurança da informação, os sistemas de autoproteção ou
self-protection são uma classe de sistemas autonômicos capazes de analisar o ambiente, detectar
e responder sem interação humana a ameaças em tempo de execução (YUAN; ESFAHANI; MALEK, 2014). Entre as intervenções possíveis, podemos citar a alteração dinâmica de políticas de controle de acesso para mitigar o dano, tal como proposto porBailey, Chadwick e Lemos (2011) e Silva et al. (2017). Neste sentido, auto-adaptação aplicado a segurança de informação apresenta-se como uma proposta viável na mitigação de ameaças internas. No contexto da utilização e avaliação de mecanismos de controle de acesso em sistemas reais nas organizações, este trabalho utiliza como estudo o sistema SUAP desen-volvido no IFRN (Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte). O SUAP (Sistema Unificado de Administração Pública) implementa um mecanismo de controle de acesso baseado no modelo RBAC, no qual as permissões são criadas e associadas a papéis, e estes papéis são atribuídos aos usuários para que seja concedido ou
negado permissão a determinado recurso. O SUAP é utilizado no IFRN, onde atualmente atende mais de 20 mil usuários entre alunos, servidores e prestadores de serviços, e via acordo de cooperação é cedido para mais de 20 outros Institutos Federais pelo Brasil. O autor da proposta é Analista de Tecnologia da Informação no IFRN, e desde o ano 2012 integra a equipe que mantém o SUAP, atuando diretamente na resposta a incidentes de segurança da informação envolvendo ativos de rede e sistemas.
1.1
Problemática e Motivação
Na literatura há diversos trabalhos no contexto da aplicação de auto-adaptação em infraestruturas de autorização com intuito de mitigar atividades maliciosas. Em um destes trabalhos, Silva et al.(2017) propõe o saRBAC, uma abordagem que de forma autonômica faz a verificação de modelos estocásticos baseados em log‘s de execução de processos de negócio para estabelecer um intervalo de confiança que permita mensurar o comportamento do usuário, e identificar uso indevido de suas permissões de forma acidental ou maliciosa. A abordagem foi implementada e avaliada com base na especificação formal de políticas de controle de acesso considerando um cenário real baseado no SUAP, entretanto, os usuários maliciosos não são bloqueados pois no SUAP o mecanismo de controle de acesso é estático, algumas restrições de acesso são inseridas diretamente no código da aplicação (hard-coded), e não há uma interface que permita manipular as políticas de forma autonômica.
Considerando a complexidade da aplicação de auto-adaptação para manipular dinamicamente as políticas de controle de acesso, e assegurar que os atributos de qualidade sejam atendidos, é proposto na literatura o uso de métodos formais para garantir que as operações sejam verificáveis e que atendam a requisitos como eficiência e confiabilidade (WEYNS et al., 2012).
O modelo RBAC (ANSI,2004) é especificado formalmente em Z (ABRIAL; SCHU-MAN; MEYER, 1980; ISO/IEC, 2002) e propõe uma especificação funcional definindo operações administrativas para criação e manutenção de elementos de uma política de controle de acesso RBAC (ex.: AddRole, GrantPermission, entre outros).
Por outro lado, o modelo ABAC proposto pelo NIST (HU et al.,2014) não prevê verificação usando métodos formais e não fornece uma lista com operações administrativas baseadas em especificação funcional. Entretanto, uma proposta de verificação formal em Z para o modelo ABAC e a especificação funcional com operações administrativas é proposto por Gouglidis et al. (2017). A especificação funcional dos modelos citados anteriormente definem operações de granularidade fina como a modificação de uma política ABAC a nível de atributo de um sujeito (ex.: ModifyAttribute()). Este nível de granularidade é importante considerando que uma adaptação pode exigir a alteração de um atributo específico na política para impedir que determinado perfil de usuário acesse um recurso,
por exemplo.
Essas operações podem ser usadas como base para geração de planos de adaptação, e é importante que elas sejam bem definidas e tenham uma semântica clara (MEDEIROS; SARAIVA; SILVA,2017). Entretanto, o desafio em aplicar esta abordagem em um sistema real está relacionado ao fato que comumente os servidores de autorização não fornecem operações granulares em suas API’s, e segundoHu et al.(2014), modelos como o RBAC tem dificuldades em lidar com arquiteturas onde decisões de controle de acesso dinâmicas são requeridas, sendo o modelo ABAC mais recomendado devido a facilidade que suas políticas têm em expressar regras complexas que podem avaliar diferentes atributos. Servidores de autorização como o FIware AuthZForce2 e o WSO2 IS (Identity Server )3 expõem operações
para a manipulação de políticas RBAC/ABAC via API, no entanto, essas operações são de granularidade grossa, e consequentemente não suportam alteração de políticas a nível de atributo.
Um outro fato a considerar é a demanda de código ad-hoc requerido pelos con-troladores auto-adaptativos para manipular políticas usando essas API’s devido a não uniformidade das tecnologias suportadas pelos servidores de autorização, como SOAP na API do WSO2 e REST no FIware AuthZForce, por exemplo.
Neste sentido, uma abordagem que forneça infraestrutura para manipulação dinâ-mica de políticas de controle de acesso granular em servidores de autorização de maneira agnóstica e baseada em especificação funcional é de vital importância para suportar a auto-adaptação, e consequentemente a mitigação de insider threats, sendo estes os principais motivadores deste trabalho.
No contexto da aplicação desta abordagem em um sistema real, uma avaliação e mudanças na arquitetura e mecanismos de controle de acesso do sistema a ser protegido devem ser realizadas. No sistema usado no nosso estudo, o SUAP, observa-se que os mecanismos de controle de acesso da forma como estão implementados não proveem meios para que as políticas de controle de acesso sejam manipuladas em tempo de execução. A associação entre o papel e o recurso protegido é realizada no código-fonte da aplicação (Python), onde nos métodos que tratam o recurso a ser protegido são atribuídos decorators
4 (similar a annotations no Java) definindo quais papéis são autorizados a acessar o
recurso. O problema desta abordagem é que ela é pouco flexível do ponto de vista de quem administra os acessos dos usuários, pois se for requerido um novo papel para acessar determinado recurso, será necessário alterar os parâmetros do decorator no código da aplicação, e consequentemente, efetuar o deploy da nova versão no servidor em produção.
Uma das possíveis abordagens para trazer mais flexibilidade e permitir manipulação 2 https://github.com/authzforce/server
3 https://wso2.com/identity-and-access-management
granular das políticas é adotar a externalização (BROSSARD; GEBEL; BERG, 2017) da arquitetura de controle de acesso em pontos funcionais (HU et al., 2014), e portanto, remover as restrições de acesso do código e delegar para um componente externo a aplicação (servidor de autorização) a decisão de permitir ou não o acesso, além de fornecer interfaces
para gerenciamento de políticas que possibilitem a manipulação de forma autonômica. Portanto, os dois principais problemas no suporte a auto-adaptação em infraes-truturas de autorização são: (1) fornecer um mecanismo que exponha operações para manipulação de políticas de controle de acesso de maneira granular em servidores de auto-rização; e considerando que a infraestrutura dinâmica atua sobre o servidor de autorização e não sobre a aplicação a ser protegida então deve-se (2) avaliar, propor e implementar mudanças no sistema a ser protegido considerando a externalização dos mecanismos de autorização.
1.2
Objetivo
Nesse contexto, este trabalho propõe o SecAuthAPI, uma abordagem para suportar a manipulação dinâmica de políticas de controle de acesso em infraestruturas de autorização através de auto-adaptação.
Deste modo, identificamos os seguinte objetivos específicos:
• Propor e implementar o SecAuthAPI, uma API REST que expõe uma interface para manipulação de baixa granularidade de políticas de controle de acesso ABAC baseada em especificação funcional formal e agnóstica de servidor de autorização. • Propor e implementar mudanças na arquitetura do sistema SUAP para suportar um
modelo de controle de acesso ABAC, incluindo a externalização dos mecanismos de autorização, mudanças na infraestrutura do sistema, e mecanismos para a definição de políticas.
• Avaliar a infraestrutura de autorização externalizada via testes de desempenho e comparar com a abordagem legada com intuito de verificar a viabilidade da adoção da proposta.
O SecAuthAPI foi proposto inicialmente por Medeiros, Saraiva e Silva (2017), que definiu uma arquitetura para a abordagem, a implementação de uma operação granular para manipulação de políticas, e a integração e avaliação de forma simulada com o controlador auto-adaptativo saRBAC (SILVA et al.,2017). Esta dissertação é uma evolução do SecAuthAPI em relação ao exposto no artigo, considerando que o Core da proposta foi reescrito permitindo maior flexibilidade na manipulação das políticas, e todas as operações granulares baseadas em especificação funcional formal estão implementadas e
testadas. Esta dissertação apresenta também as etapas para externalizar os mecanismos de autorização em um sistema real, e baseado nessas fases implementa uma demonstração no sistema SUAP.
1.3
Metodologia
O desenvolvimento desta proposta é realizado de acordo com as seguintes fases:
• Levantamento bibliográfico: buscas e leituras em artigos e demais trabalhos relacio-nados ao tema desta pesquisa, como sistemas auto-adaptativos, modelos de controle de acesso, insider threats, entre outros.
• Escolha das ferramentas: levantamento e testes em ferramentas open-source que atuam como servidores de autorização com suporte a ABAC e com API para manipulação de políticas.
• Proposta e implementação: considerando os problemas e objetivos identificados, é pro-posto e implementado uma abordagem para suportar infraestruturas de autorização auto-adaptativas.
• Demonstração: as propostas de manipulação dinâmica de políticas de controle de acesso e a externalização dos mecanismos de autorização são demonstrados a partir de aplicações de exemplos.
• Avaliação: a proposta de manipulação dinâmica é avaliada a partir de testes unitários com intuito de garantir a conformidade com a especificação funcional, e para a proposta de externalização são realizados testes de desempenho e comparados com a abordagem legada com intuito de verificar a viabilidade em um sistema real.
1.4
Organização do Documento
Os demais capítulos deste trabalho serão organizados da seguinte forma: O capítulo
2 apresenta o referencial teórico com informações relevantes para compreensão de temas que serão discutidos no restante deste trabalho. No capítulo 3é apresentado o SecAuthAPI e sua implementação. O capítulo4apresenta um estudo sobre o processo de externalização dos mecanismos de autorização em sistemas reais, e propõe e implementa os componentes e as mudanças na arquitetura usando o sistema SUAP como referência. O capítulo 5
apresenta a demonstração e avaliação do SecAuthAPI e da externalização no SUAP. Os trabalhos relacionados a esta pesquisa são apresentados no capítulo 6, e no capítulo 7são realizadas as considerações finais deste trabalho, as contribuições e limitações, e por fim a indicação de trabalhos futuros.
2 Referencial Teórico
Este capítulo descreve conceitos relacionados aos temas abordados neste trabalho, como modelos e mecanismos de controle de acesso, sistemas auto-adaptativos aplicados no contexto de segurança da informação, e por fim apresenta o sistema SUAP, que será utilizado no estudo de caso a ser apresentado na avaliação da abordagem proposta.
2.1
Controle de Acesso
O controle de acesso é um dos componentes fundamentais para garantir a segurança de sistemas computacionais. Segundo Sandhu e Samarati (1994), “o propósito de um controle de acesso é limitar as ações ou operações que um usuário legítimo de um sistema de computador pode realizar”. A terminologia relacionada a controle de acesso utilizada nas últimas 3 décadas é descrita por Ferraiolo, Kuhn e Chandramouli (2007) como:
• Usuário/Sujeito: pessoas que interagem com a interface do sistema ou programa de computador executando em nome de um determinado usuário;
• Objeto: recursos que podem ser acessados em um sistema de computador, tais como um arquivo, banco de dados, impressora, etc.;
• Operação: atuação de um sujeito sobre um objeto por exemplo;
• Permissão: determina se uma operação em um objeto está autorizada;
Os mecanismos de controle de acesso são comumente baseados na arquitetura AAA (Authentication, Authorization e Auditing) ou autenticação, autorização e auditoria respectivamente, conforme proposto por Sandhu e Samarati (1994). A primeira função (autenticação) refere-se ao procedimento de verificar se o sujeito é quem ele diz ser, em seguida ocorre a fase de autorização, que verifica se o sujeito detém “direitos” ou “privilégios” sobre determinado recurso ou objeto protegido, e por fim a fase de auditoria (também chamada de Accounting ou Contabilização na RFC 2904 (VOLLBRECHT et al.,
2000)), que coleta detalhes das fases de autenticação e autorização (log’s, métricas, etc.) para posterior análise.
A base para a autenticação de usuários pode ser obtida através do banco de dados da própria aplicação (autenticação local), ou através de mecanismos externos a aplicação (autenticação externalizada) como serviços de diretório (Microsoft Active
Directory, OpenLDAP, por exemplo), serviços de identidade (OIDC - OpenID Connect
autenticação nos seus sistemas, possibilitando que as mesmas credenciais do usuário sejam utilizadas para acessar os computadores (ex.: login no Windows), acesso a rede sem fio, entre outros. No caso da autorização, comumente as aplicações aplicam mecanismos de controle diretamente no código da aplicação, no entanto alguns produtos como o WSO2 IS e OpenAM já fornecem mecanismos para externalização da autorização. A externalização da autorização será melhor detalhada no decorrer desta seção.
A Figura1 apresenta um exemplo da tríade AAA, em que um sujeito tenta acessar um determinado recurso protegido (ex.: relatório, arquivo, entre outros). Na primeira fase o sistema solicita a autenticação do usuário (usuário e senha por exemplo), e caso as credenciais informadas na autenticação estejam corretas o sistema verifica se o sujeito tem permissão para acessar o recurso (fase de autorização), e em caso positivo o acesso ao recurso é permitido. A caixa sombreada de azul mostra a fase de auditoria, que registra os eventos de controle de acesso, como login do usuário, data e hora do acesso, operação e recurso a ser acessado, e resultado da avaliação de política de autorização, entre outros.
Figura 1 – Tríade AAA (Autenticação, Autorização, Auditoria)
Fonte: Elaborado pelo autor baseado em Sandhu e Samarati(1994)
A relação entre sujeito, objeto/recurso, operação e permissão é definida através de modelos de controle de acesso (THION,2007). O modelo RBAC introduz o conceito de permissões associadas a papéis, no qual os usuários são atribuídos a estes papéis. Segundo
ANSI (2004), “papéis são criados para várias funções de trabalho na organização e os
usuários são atribuídos a estes papéis baseados nas suas responsabilidades e qualificações”.
Os papéis concedem permissões no sistema, e estas podem ser revogadas quando forem necessárias. Ao revogar uma determinada permissão em um papel, todos os usuários que estiverem atribuídos ao papel serão afetados. Conforme apresentado na Figura 2, um usuário (USERS ) é associado a um papel (ROLES ), e quando um usuário ativa um determinado papel uma nova sessão (SESSIONS ) é criada. Cada papel tem uma ou mais permissões associadas (PERMS ), que são a autorização para realizar operações (OPS ) em um objeto (OBS ) que está sendo controlado pelo RBAC. Uma das limitações deste modelo é o problema de explosão de papéis, que ocorre quando o número de papéis criados para atender determinadas especificidades cresce de forma a inviabilizar a administração do controle de acesso, e podendo chegar a casos onde o número de papéis é maior que o número de usuários em sistemas em larga escala (ELLIOTT; KNIGHT,2010).
Figura 2 – Modelo de referência RBAC Core
Fonte: Elaborado por ANSI (2004)
Em 2012 o ANSI publicou o padrão INCITS 494-2012, uma extensão do modelo RBAC denominada RBAC Policy-Enhanced (RPE) (ANSI, 2012), que suporta atributos como parte das restrições nas decisões de controle de acesso, e tem como objetivo lidar com a pouca flexibilidade do modelo RBAC em domínios que mudam rapidamente. Alguns dos servidores de autorização avaliados neste trabalho e apresentados ao longo desta seção suportam RBAC, entretanto, não suportam RPE.
O uso de atributos para definição de políticas de controle de acesso fora discutido anteriormente por Yuan e Tong (2005), que propõe o modelo ABAC (Attribute Based
Access Control), que posteriormente foi detalhado pelo NIST na publicação especial 800-162 (HU et al., 2014). O ABAC é um modelo de controle de acesso no qual as requisições para realizar operações em um determinado objeto ou recurso são permitidas ou negadas de acordo com atributos. Os atributos contêm informações no formato chave-valor, e representam características relacionadas ao sujeito (nome, idade, etc.), objeto/recurso (id, localização, etc.), ação/operação (inserir, remover, etc.) ou condição ambiental (data/hora, endereço IP, nível de ameaça, etc.). As políticas são representadas por regras de controle de acesso que determinam se uma requisição será ou não permitida de acordo com os valores dos atributos.
Um mecanismo de controle de acesso RBAC/ABAC apresenta uma arquitetura funcional com um conjunto de componentes necessários para seu funcionamento. A Figura
3 apresenta uma arquitetura com a distribuição e gerenciamento dos mecanismos de controle de acesso, onde são destacados os principais pontos funcionais como PEP (Policy
Enforcement Point), PDP (Policy Decision Point), PAP (Policy Administration Point) e
PIP (Policy Information Point).
O PEP intercepta as requisições entre o sujeito e o objeto, em seguida gera uma requisição de autorização a ser enviada para o componente que faz a avaliação (PDP), recebe a resposta da avaliação, e por fim aplica a decisão de permitir ou não o acesso de
Figura 3 – Distribuição dos mecanismos de controle de acesso ABAC
Fonte: Elaborado por Hu et al. (2014)
acordo com a avaliação realizada. O PDP recebe a requisição de autorização enviada pelo PEP, avalia os atributos e computa a decisão de acordo com o que está definido na política de controle de acesso, e por fim retorna a decisão para o PEP. O PAP é responsável por provê uma interface para gerenciamento das políticas de controle de acesso, e armazenar essas políticas em um repositório (PR ou Policy Repository). O PIP é responsável por recuperar atributos necessários para a avaliação da política, por exemplo, a política espera N atributos, sendo um deles disponível apenas em uma fonte externa como uma base LDAP, portanto, no momento da avaliação do acesso pelo PDP, o mesmo irá detectar que os atributos recebidos na requisição de autorização não são suficientes para avaliar a política, e irá solicitar ao PIP que recupere o conteúdo deste atributo a partir da fonte externa, no caso um LDAP.
A Figura 4 apresenta um exemplo destes componentes funcionais aplicados em uma arquitetura de controle de acesso ABAC. Neste exemplo o usuário ao tentar acessar um recurso protegido tem sua requisição interceptada por um PEP, que recupera seus atributos da requisição (onde userxyz é nome do usuário, POST a ação, /new_ticket o recurso sendo acessado e suporte o papel atribuído ao usuário), em seguida encaminha esta requisição para o PDP, que recupera as políticas do repositório, e por fim compara os atributos da requisição com os atributos esperados pela política ABAC, e se os valores dos atributos estiverem iguais o acesso é permitido, caso contrário é negado.
Figura 4 – Exemplo de aplicação do mecanismo ABAC
Fonte: Elaborado pelo autor
No contexto de ABAC, uma das linguagens utilizadas na definição de políticas de controle de acesso é o eXtensible Access Control Markup Language (XACML) proposto como padrão pelo OASIS (PARDUCCI; LOCKHART; RISSANEN, 2013). O XACML é uma linguagem de extensão do XML que especifica os tipos de elementos que podem ser utilizados na definição de uma política, como as regras, algoritmos de combinação de regras, atributos, obligations (condição adicional que deve ser aplicada obrigatoriamente pelo PEP antes de liberar ou negar o acesso), advice (similar ao obligations, no entanto o PEP pode se negar a aplicar a condição adicional), além de definir o formato de troca de mensagens entre o PEP e o PDP, que é o XACML Request para o envio de requisições de autorização, e o XACML Response para resposta da avaliação com a decisão final de permitir ou não o acesso.
Uma outra linguagem que implementa o modelo ABAC em alternativa ao XACML é o NGAC (Next Generation Access Control) (ANSI, 2013), que propõe uma lista de operações administrativas, computa decisão de forma eficiente através de um algoritmo linear, entre outros (HAREL,2017), no entanto, não há produtos comerciais ou open-source maduros que suportem esta linguagem, apenas um protótipo denominado Policy-Machine1,2
disponibilizado pelo NIST. O XACML foi proposto em 2003, e desde então vem sendo atualizado, e pesquisado em periódicos e conferências de referência no âmbito de controle de acesso como o SACMAT (Symposium on Access control Models and Technologies)3 (XU;
SHRESTHA; SHEN, 2018) (IYER; MASOUMZADEH,2018) (MORISSET; WILLEMSE; ZANNONE, 2018).
Para implementar mecanismos de controle de acesso como o ABAC em uma arquitetura que considere a externalização dos componentes funcionais é requerido um 1 https://github.com/PM-Master/Policy-Machine
2 https://csrc.nist.gov/Projects/Policy-Machine 3 http://www.sacmat.org/
servidor de autorização com suporte a interfaces PAP, PDP, e que suporte a linguagem XACML (BROSSARD; GEBEL; BERG,2017). Durante o desenvolvimento deste trabalho alguns servidores de autorização open-source foram avaliados e serão apresentados a seguir:
• AuthZForce4: fornece uma RESTful API para a interface PDP com suporte a
linguagem OASIS XACML v3.0, e uma API REST para a interface PAP com suporte a operações básicas como a inserção e remoção de políticas ABAC. Esta solução não fornece interface web para gerenciamento das políticas.
• WSO2 Identify Server5: fornece API REST para o PDP e SOAP para o PAP, além
do suporte a single-sign-on (SSO) com os protocolos OpenID Connect, SAML 2.0 e
WS-Federation, e módulos para atuar como provedor de identidades (IDP) e provedor
de serviços (SP). Esta solução fornece uma interface web denominada Carbon, que possibilita criar políticas XACML de forma simplificada usando assistentes, avaliar a política simulando requisições de autorização, entre outros.
• OpenAM6: fornece interfaces REST para PAP e PDP, e suporta SAML, OAuth 2.0,
OpenID Connect, dashboard para manipulação de políticas XACML, etc. Em 2015 a ForgeRock abandonou o projeto open-source, e mantém apenas a versão comercial do produto denominado ForgeRock Identity Management7.
• AT &T XACML8: implementação de referência do OASIS XACML 3.0 feito pela
AT&T em linguagem Java. A solução fornece API’s REST para PAP e PDP, e uma interface web para gerenciamento de políticas.
Por se tratar um projeto open-source maduro, com uma ativa comunidade de desen-volvedores e usuários, além de disponibilizar funcionalidades que não foram encontradas nas demais soluções (dashboard, suporte a RBAC e ABAC, etc.), e fornecer suporte pago caso seja necessário na adoção corporativa, o WSO2 IS se mostrou a melhor escolha para auxiliar no desenvolvimento desta proposta.
2.2
Sistemas Auto-Adaptativos
Self-Adaptive Systems ou Sistemas Auto-Adaptativos são sistemas capazes de
monitorar a si próprio e ao ambiente em que estão inseridos, e se reconfigurar sobre variadas e imprevisíveis condições (HORN, 2001). Entre os modelos de auto-adaptação, destaca-se o MAPE-K proposto pela IBM (KEPHART; CHESS, 2003). O MAPE-K é um 4 https://github.com/authzforce/server
5 https://wso2.com/identity-and-access-management
6 https://github.com/ForgeRock/openam-community-edition 7 https://www.forgerock.com/platform/identity-management 8 https://github.com/att/XACML
modelo de referência para o desenvolvimento de sistemas auto-adaptativos baseados em elementos capazes de gerir recursos externos e seu comportamento interno. A proposta do loop de controle autonômico é apresentada na Figura 5.
Figura 5 – Modelo de referência MAPE-K para computação autonômica
Fonte: Elaborado por Brun et al. (2009)
No loop autonômico do MAPE-K o Managed Element representa qualquer software ou recurso de hardware com comportamento autônomo que é acoplado através de um
Autonomic Manager. O Monitor sonda continuamente as informações de contexto através
dos sensores (Sensors), o Analyze interpreta e compara os dados obtidos do Monitor, e o Plan sintetiza e cria planos de adaptação quando necessário. Quando um plano é recebido, o Execute complementa a tradução de cada uma das ações especificadas no plano e altera o comportamento do Managed Element através de um Effector. Todos os componentes compartilham conhecimento através do elemento Knowledge Manager. Portanto, um sistema auto-adaptativo é capaz de realizar auto-gerenciamento através da coleta de informações, e a partir desses dados identificar a necessidade de alteração, planejar uma lista de ações, e coordenar a execução dos passos planejados para endereçar a mudança necessária.
SegundoKephart e Chess(2003), a essência dos sistemas de computação autonômica é o auto-gerenciamento (self-management), que tem como intenção liberar os adminis-tradores de sistemas de detalhes de operação e manutenção destes sistemas. Os autores também listam os 4 principais aspectos relacionados a auto-gerenciamento em computação autonômica, que são:
• Self-Configuration ou auto-configuração: configuração automática de componentes e sistemas seguindo políticas de alto nível.
• Self-Optimization ou auto-otimização: componentes e sistemas buscam continuamente oportunidades para melhorar sua própria eficiência e desempenho.
• Self-Healing ou auto-recuperação: o sistema automaticamente detecta, diagnostica e repara os problemas localizados em hardware e software.
• Self-Protection ou auto-proteção: o sistema se defende automaticamente contra ataques maliciosos ou falhas em cascata.
No contexto de segurança da informação, Yuan, Esfahani e Malek (2014) propõem uma visão do que eles consideram ser um sistema de auto-proteção (Self-Protection) con-forme apresenta a Figura 6. O meta-level subsystem é parte do software que é responsável por proteger o sistema alvo (base-level subsystem). Os objetivos de segurança são frequen-temente especificados por atores humanos, como usuários ou engenheiros (User/Engineer ), e para uma melhor eficácia os sistemas de auto-proteção devem ser capazes de monitorar o ambiente de domínio (Domain) onde o software a ser protegido está executando.
Figura 6 – Visão de Self-Protection
Fonte: Elaborado porYuan, Esfahani e Malek (2014)
Considerando esta abordagem aplicada a mecanismos de controle de acesso, o
Protected Subsystem (Base-level) é a infraestrutura de autorização alvo, que contém
uma implementação específica de um modelo controle de acesso. O conhecimento sobre os serviços disponíveis e como se comunicar com estes é mandatório para o componente Execute ser capaz de executar os planos de adaptação da melhor forma possível. São exemplos de controladores auto-adaptativos o saRBAC (SILVA et al., 2017), SAAF (BAILEY; CHADWICK; LEMOS, 2011), Ariadne (TSIGKANOS et al.,2015), entre outros.
A aplicação de técnicas de auto-adaptação permite que a infraestrutura observe, avalie, e atue em seus próprios mecanismos de controle de acesso, reduzindo a necessidade de intervenção humana, automatizando as atividades de gerenciamento, e auxiliando na identi-ficação e resposta apropriada para casos de abusos dos direitos de acesso, além de avaliar o estado da infraestrutura de autorização para garantir que o acesso suficiente e relevante es-tará disponível para os usuários. Alguns trabalhos envolvendo auto-adaptação no contexto de segurança da informação vêm sendo desenvolvidos no laboratório Stela (SmarT
Envi-ronment LAboratory)9 do IMD/UFRN coordenado pelo professor Dr. Carlos Eduardo da
Silva, entre os quais destacamos o saRBAC (SILVA et al.,2017), SecAuthAPI (MEDEIROS; SARAIVA; SILVA, 2017), SADF (JÚNIOR et al., 2018) e SAS no OpenStack (SILVA et al., 2018).
2.3
SUAP
O SUAP (Sistema Unificado de Administração Pública) é um sistema de gestão acadêmica e administrativa que começou a ser desenvolvido em 2007 pela equipe de TI do IFRN e atualmente é distribuído para mais de 20 institutos federais pelo Brasil por meio de acordos de cooperação. O desenvolvimento do sistema é baseado em tecnologias
open-source, tais como a linguagem Python10, o framework Django11, e o banco de dados
PostgreSQL12.
A Figura 7 apresenta a arquitetura conceitual do sistema, onde no topo são apresentados alguns módulos como o Edu (gestão educacional), RH (recursos humanos), e ADM (administração), sendo que o sistema já conta com mais de 40 módulos. O módulo
ldap_backend permite que SUAP externalize a autenticação de usuários através de uma
base de usuários do serviço de diretório AD (Microsoft Active Directory), além de permitir que o SUAP insira usuários em grupos do AD para controlar acesso a pastas em servidores de arquivos, impressão, acesso a VPN, etc.
Figura 7 – Arquitetura do controle de acesso do SUAP
Fonte: Elaborado pelo autor
A parte sombreada na cor verde na figura apresenta o Django Framework, um framework web que fornece diversos componentes plugáveis e reutilizáveis, dentre os quais destaca-se o django.contrib.admin (interface web gerada dinamicamente onde são disponibi-9
https://www.researchgate.net/lab/STELA-SmarT-Environment-LAboratory-Carlos-Eduardo-da-Silva
10 https://www.python.org/ 11 https://www.djangoproject.com/ 12 https://www.postgresql.org/
lizadas operações para inserir, excluir, modificar, e buscar dados), django.contrib.templates (define como a página será apresentada), django.db (suporte a ORM/Object Relational
Mapping ou Mapeamento Objeto Relacional, entre outras operações envolvendo banco de
dados), entre outros. Na parte inferior e sombreado na cor laranja são apresentados alguns frameworks de terceiros utilizados para suporte a banco de dados PostgresSQL (psycopg2 ), acesso a diretórios LDAP (python-ldap), API’s REST (Django Rest Framework), entre outros.
O Django também fornece um middleware denominado django.auth13, que é res-ponsável pela autenticação e autorização dos usuários. Entre as funcionalidades fornecidas pelo middleware, destaca-se o mecanismo para registro de novos usuários, armazenamento seguro da senhas (PBKDF2 por padrão), reset de senha, grupos de usuários e permissões, entre outros. No tocante a autenticação, o middleware por padrão verifica as credenciais a partir da base de dados da aplicação, no entanto há classes de extensão que possibilitam a externalização da autenticação. Isso é explorado pelo SUAP através da externalização de gerência de usuários e autenticação para uma base LDAP (Microsoft AD ou OpenLDAP via pacote python-ldap).
No tocante a autorização, o middleware fornece mecanismos que possibilitam a implementação de políticas baseadas em grupos de usuários (baseada em RBAC) com objetivo de restringir acessos a recursos. As restrições de acesso a determinado recurso podem ser aplicadas diretamente no código da aplicação a partir de anotações
decora-tors/Python nos métodos, sendo esta a abordagem adotada no SUAP. O Django não
suporta a externalização dos mecanismos de autorização. Esta limitação será abordada durante o decorrer deste trabalho.
Figura 8 – Arquitetura de referência do SUAP
Fonte: Elaborado pelo autor
Por fim, a figura 8 traz uma visão da arquitetura de implantação do SUAP 13 https://docs.djangoproject.com/en/1.8/_modules/django/contrib/auth/middleware/
considerando os componentes utilizados no ambiente em produção no IFRN. Observa-se que o usuário acessa o sistema SUAP a partir do browser de um dispositivo ou do aplicativo
SUAP Mobile para smartphones, em seguida essa requisição é recebida por um servidor web NGnix14, que atua como um proxy reverso encaminhando as requisições para o servidor de aplicação Django denominado Gunicorn15. A arquitetura também prevê o serviço Microsoft
Active Directory, o qual é utilizado pelo SUAP para autenticar os usuários a partir de uma
base única, além de um outro servidor Linux executando o banco de dados PostgreSQL. O ELK16 (ElasticSearch, LogStash, Kibana) é um componente opcional da arquitetura
do SUAP, mas importante na parte de coleta de log‘s (LogStash), armazenamento em base de dados NoSQL para suporte a grandes volumes de dados (ElasticSearch), e para visualização analítica (Kibana).
2.4
Discussão
Neste capítulo foram apresentados alguns conceitos importantes para compreensão da proposta deste trabalho. Na seção2.1 foi realizado uma breve introdução sobre controle de acesso, destacando os principais mecanismos e modelos, como o RBAC (baseado em papéis) e ABAC (baseado em atributos), além de destacar a importância de externalizar o controle de acesso em uma arquitetura baseada em pontos funcionais. Em seguida foi apresentado na seção 2.2 conceitos relacionados a sistemas auto-adaptativos (SAS), destacando o modelo autonômico MAPE-K proposto pela IBM, e sua aplicação no contexto de segurança da informação ou auto-proteção (Self-Protection). Por fim, na seção 2.3
foi apresentado o SUAP, um sistema desenvolvido no IFRN para gestão acadêmica e administrativa da instituição, e que foi selecionado para ser usado na demonstração e avaliação da abordagem proposta neste trabalho.
14 https://nginx.org/en/ 15 http://gunicorn.org/
3 SecAuthAPI
Este capítulo apresenta o SecAuthAPI. O SecAuthAPI consiste em um efetor/atu-ador (effector em uma arquitetura de auto-adaptação) para suportar a auto-adaptação de infraestruturas de autorização, fornecendo uma interface padronizada para manipular políticas de controle de acesso em servidores de autorização de maneira agnóstica
(PAP-Agnostic) usando a linguagem XACML (PARDUCCI; LOCKHART; RISSANEN, 2013), e baseado em operações de uma especificação funcional formalmente verificada.
A arquitetura proposta para esta abordagem, como também os detalhes de imple-mentação serão apresentados nas seções a seguir.
3.1
Arquitetura
A arquitetura do SecAuthAPI é apresentada na Figura 9. O SecAuthAPI atua como um effector, fornecendo operações para controladores auto-adaptativos, que em um contexto de segurança da informação são capazes de identificar e responder a atividades anômalas. Essas ferramentas podem se comunicar com o SecAuthAPI através de uma interface REST que realiza as ações de um plano de adaptação.
Figura 9 – Arquitetura do SecAuthAPI
Fonte: Elaborado pelo autor
O SecAuthAPI recebe na sua API implementada no pacote API (PAP) uma re-quisição vinda do Controlador Auto-Adaptativo para manipulação de política, e as encaminha para um adaptador específico no pacote Adapter. Este adaptador é responsável por implementar as chamadas para cada servidor de autorização.
Os servidores de autorização fornecem diferentes operações para manipulação de políticas e em diferentes protocolos de acesso através da sua interface PAP. O SecAuthAPI implementa adaptadores que fazem a orquestração de chamadas específicas para cada
servidor de autorização, suportando no momento os produtos WSO2 Identity Server e
FIware AuthZForce,WSO2 Adapter e AZF Adapter respectivamente. A arquitetura proposta
é flexível, possibilitando que novos adaptadores sejam implementados para outros servidores de autorização (ex.: OpenAM, AT &T XACML, entre outros).
O pacote Core é responsável pela manipulação local das políticas de controle de acesso, interagindo com o Repositório Políticas para a persistência. O Adapter consome os métodos do Core quando uma determinada operação de manipulação de política não é suportada pelos servidores de autorização, tais como as operações granulares de manipulação de políticas a nível de atributo.
Na sequência, será apresentado o design do SecAuthAPI e o detalhamento da implementação dos componentes desta proposta.
3.2
Design
O SecAuthAPI é baseado na especificação formal proposta porGouglidis et al.(2017) para o modelo ABAC. Nesta especificação são definidas operações para administração de políticas, que são implementadas no SecAuthAPI através de uma API genérica que provê operações para manipulação de políticas de controle de acesso XACML de forma granular, possibilitando intervenções a nível de atributo, por exemplo.
As principais operações disponibilizadas pelo SecAuthAPI são apresentadas na Tabela 1. O ApêndiceA apresenta o detalhamento de todas as operações do SecAuthAPI considerando suas pré e pós-condições. O componente é baseado no padrão arquitetural REST (FIELDING,2000), sendo as operações/métodos apresentadas em termos de verbos HTTP (ex. GET, POST) e recursos (ex., /policy). Os verbos mapeiam operações de CRUD (Create, Read, Update, Delete ou criar, ler, atualizar e excluir respectivamente). O verbo GET representa a recuperação de um recurso/objeto (leitura), o POST a criação, PUT a modificação, e DELETE a exclusão. Na tabela a operação responsável por inserir uma nova política é acionada através do verbo POST e recurso /policy.
Tabela 1 – API - Operações Administrativas
Verbo HTTP Recurso Descrição
POST /policy Insere política no PAP
PUT /policy/policy_name Modifica política no PAP DELETE /policy/policy_name Exclui política no PAP
Além dos parâmetros submetidos via URL (policy_name ou nome da política por exemplo), o SecAuthAPI requer a inclusão de parâmetros adicionais no corpo da requisição HTTP para algumas operações. Por exemplo, para inserir uma nova política é necessário
informar o código em XML (XACML) da mesma, no entanto em políticas com um grande número de regras e atributos o tamanho da URL pode estourar o limite tanto do browser quanto do servidor web, portanto este código é submetido como parâmetro no corpo da requisição. O detalhamento dos parâmetros na URL e no corpo da requisição HTTP são apresentados no apêndice A.
Como forma de demonstrar o funcionamento do SecAuthAPI, a figura10 apresenta um diagrama de sequência (UML) representando uma chamada realizada por um controla-dor auto-adaptativo a uma operação granular fornecida pelo SecAuthAPI, onde a atuação a ser realizada é a inserção de um novo atributo na política do servidor de autorização, que nesse exemplo é o WSO2 IS.
Figura 10 – Diagrama de Sequência do SecAuthAPI
Fonte: Elaborado pelo autor
A chamada realizada pelo controlador auto-adaptativo ao SecAuthAPI é tratada pelo método policy_attribute do pacote API, que é responsável por todas as operações de manipulação a nível de atributo, sendo as ações como criar, alterar e excluir acionadas baseado no verbo HTTP utilizando na requisição (no exemplo é utilizado POST). Os parâmetros do corpo da requisição responsáveis por definir a categoria, nome e valor do atributo foram omitidos neste exemplo por questão de espaço.
Baseado nos parâmetros informados, o SecAuthAPI faz uma chamada a um método que se encontra no pacoteAdapter denominado add_attribute(), e este antes de iniciar a manipulação da política faz uma chamada a operação getPolicy da API PAP do servidor de autorização WSO2 para que o mesmo recupere uma cópia da política. Na fase seguinte, o Adapter avalia se a operação em questão é de granularidade grossa (inserir, alterar ou
excluir uma política de forma geral), ou de granularidade fina (alterar a política a nível de atributo). Neste caso, por se tratar de uma operação de manipulação a nível de atributo, e esta operação não ser suportada pela API do servidor de autorização em questão, então o Adapter faz uma chamada ao método add_attribute() do pacote Core, onde este método abre o código da política em linguagem XACML, e manipula o XML inserindo o novo atributo em questão, e por fim devolve para o adaptador. No passo seguinte, o adaptador encaminha o código da nova política (já com o atributo inserido) para o servidor de autorização através da sua API PAP utilizando o método updatePolicy(), e este devolve o status da operação para o SecAuthAPI, que em seguida encaminha para o controlador auto-adaptativo.
Por fim, para as operações que não envolvam manipulação granular de políticas o procedimento é similar, no entanto não é necessário chamar os métodos contidos no pacote Core, já que as operações são suportadas pelos servidores de autorização e podem ser encaminhadas diretamente para a API dos mesmos.
3.3
Implementação
O protótipo do SecAuthAPI é implementado em Python1 com auxílio do framework web Django. O Django é utilizado no desenvolvimento da camada de persistência das políticas no banco de dados, na interface web para administração de políticas, e nos testes unitários. A interface REST API é implementada usando o framework Django Rest
Framework2, que provê mecanismos para autenticação, serialização de dados, navegação
na API, e outros. As operações fornecidas pela API, bem como os verbos HTTP e códigos de retorno são baseados na especificação semântica do protocolo HTTP apresentada na RFC 7231 (FIELDING; RESCHKE, 2014).
A Figura 11 apresenta um diagrama UML que destaca os principais pacotes e classes do SecAuthAPI.
A classe de domínio Policy do pacote Core contém a propriedade name que é utilizada para armazenar o nome da política, em seguida a propriedade description armazena uma descrição mais detalhada da política, e por fim content armazena o código da política em linguagem XACML. Os métodos para criação, edição e exclusão são implementados pelo Django Framework, entretanto, o método Save foi sobrescrito na classe Policy para permitir que o nome da política seja recuperado a partir do código XACML, já que o nome da política é utilizado como parâmetro nas API’s dos servidores de autorização (ex.: WSO2 IS).
O pacote Core também contém uma classe denominada Xacml_Util, que é res-1 https://www.python.org/
ponsável por disponibilizar métodos que possibilitam a manipulação granular de uma política XACML, como a inserção de um atributo em uma política existente (método
add_attribute()) por exemplo, operação esta não suportada pela API dos servidores de
autorização.
Figura 11 – Diagrama de Classes do SecAuthAPI
Fonte: Elaborado pelo autor
Na classe PolicySerializer são definidas quais as classes de domínio serão utilizadas (chamada de Model no Django), e as propriedades que devem ser serializadas pelo
Django-Rest-Framework nas operações com a API. A classe PolicyViewSet implementa os recursos
REST da API, por exemplo, quando um recurso da API é chamado, um método da classe
PolicyViewSet executa operações como a verificação do verbo HTTP (ex.: GET, PUT,
POST), em seguida os dados são serializados e retornados para o cliente da API, e quando necessário, as operações são encaminhadas para os servidores de autorização.
O gerenciamento das políticas no PAP dos servidores de autorização é realizado pela classeAdapter. As classes WSO2 e AuthZForce são implementações concretas da classe abstrata AuthService, que contém métodos abstratos com operações comuns a todos os servidores de autorização e que devem ser implementados pelas classes que a herdam.
servidores de autorização WSO2 e AuthZForce, entretanto, as interfaces fornecidas pela API dos servidores de autorização implementam tecnologias distintas. O AuthZForce permite a manipulação de política utilizando uma interface PAP do tipo REST API, enquanto o WSO2 suporta SOAP, portanto, é necessário um Adapter para tratar a política de acordo com o protocolo utilizado pelo servidor de autorização. A implementação desta classe é baseada no padrão de projeto Adapter (GAMMA et al., 1995), que permite que interfaces distintas trabalhem em conjunto. As operações de manipulação são realizadas usando métodos específicos de cada produto, por exemplo, WSO2 requer que a política seja enviada usando envelope SOAP a partir do método add_policy() da classe concreta WSO2.
Quando um método de manipulação a nível de atributo é chamado usando o
SecAuthAPI, o mesmo recupera a política XACML (formato XML), converte o XML em
objetos usando o XACML_Parser 3, efetua a manipulação na política (um novo atributo,
por exemplo), converte de volta para XML, verifica a integridade da política utilizando
XACML XML Schema (XSD), e publica a política no PAP do servidor de autorização.
As operações seguem a especificação funcional formal proposta porGouglidis et al.
(2017), por exemplo, a operação funcional ModifyAttribute (sub | obj, ATTRs, ATTRo) é mapeada na API para o verbo HTTP PUT e recurso /policy/policy_name/rule_name. Dados adicionais como atributo a ser alterado e o novo valor são enviados em formato JSON através do corpo da requisição.
O protótipo foi implementado levando em consideração o baixo acoplamento de seus componentes. Se necessário, a API REST (pacote API na figura11) pode ser alterada para outro método de chamada remota como XML-RPC4, SOAP5, entre outros. A API
fornece as operações de forma padronizada, e internamente interage com os servidores de autorização utilizando adaptadores (Adapters) específicos para cada servidor de autorização, e estes adaptadores implementam as chamadas para as interfaces suportadas pelo servidor de autorização em uso. Para este protótipo os servidores de autorização WSO2 IS e
AuthZForce foram utilizados, entretanto, novos produtos podem ser implementados a
partir da classe abstrata AuthService.
A Listagem3.1 exibe um exemplo de chamada via linha de comando usando cURL (cliente HTTP), onde o recurso /policy do SecAuthAPI é acionado para inserir uma nova política XACML na interface PAP do servidor de autorização. O parâmetro “-X” define o verbo HTTP (no caso POST, já que trata-se da inserção de uma nova política), em seguida o “-H” informa o token de autorização OAuth, em seguida a URL do SecAuthAPI, e por fim os parâmetros requeridos pela operação proposta, que são o nome (name), uma 3 https://github.com/jamedeiros/XACML_Parser (desenvolvido com colaboração de Augusto/IFRN) 4 https//docs.python.org/2/library/xmlrpclib.html
breve descrição da política (description), e o conteúdo (content) da mesma em linguagem XACML.
1 curl -X POST -H "Authorization: Bearer S760bVdDhxNDhAW4PNs0aDKOeQvrqT" http://127.0.0.1:8000/policy/ 2 --data-urlencode name="NewTicketOnlySupport"\
3 --data-urlencode description="Only support role can register" \ 4 --data-urlencode content@Policy/NewTicketOnlySupport.xml
Listagem 3.1 – Extra/Sec_AddPolicy.sh
Já a listagem 3.2apresenta um exemplo de uso de uma operação do SecAuthAPI para modificação de política a nível de atributo. Na URL da API é informado o nome da política (NewTicketOnlySupport), a regra na qual o atributo está inserido (NewTicket), e via parâmetro da requisição o nome do atributo (attribute_name), e o valor a ser alterado (SuperAdmin), ou seja, modifique no atributo “papel” (http://wso2.org/claims/role) o
valor para “SuperAdmin”.
1 curl -X PUT -H "Authorization: Bearer S760bVdDhxNDhAW4PNs0aDKOeQvrqT" http://127.0.0.1:8000/policy/NewTicketOnlySupport/NewTicket/ \ 2 --data-urlencode attribute_name="http://wso2.org/claims/role" \ 3 --data-urlencode attribute_value="SuperAdmin"
Listagem 3.2 – Extra/Sec_UpdatePolicyAttribute.sh
As demais operações funcionais do SecAuthAPI são apresentadas no apêndiceA.
3.4
Discussão
Neste capítulo foi apresentado o SecAuthAPI, uma abordagem para suportar manipulação dinâmica de políticas de controle de acesso baseado em uma especificação funcional ABAC. O protótipo expõe para os controladores auto-adaptativos uma API REST com operações para manipulação de políticas XACML de maneira agnóstica de servidor de autorização.
O protótipo foi concebido levando em consideração a modularização de seus compo-nentes (ex.: Core, API, etc.), e interfaces que permitam de forma simplificada a extensão do código para suporte a outros servidores de autorização. Nesta fase da pesquisa o protótipo está funcional para todas as operações de manipulação de políticas no servidor de autorização WSO2 IS, e necessita de testes no FIware AuthZForce.
Durante a implementação, o maior desafio encontrado foi a falta de bibliotecas e códigos de exemplos em Python no que se refere a políticas XACML v3.0. O XACML é um XML complexo, e para incluir um simples atributo em uma política é necessário manipular vários elementos e posicioná-los na hierarquia correta conforme descrito na especificação do XACML (PARDUCCI; LOCKHART; RISSANEN, 2013).
Uma solução é a aplicação de técnicas de transformação de modelos (EMF ou
