93
Universidade Federal do Rio Grande do Norte 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:Umaabordagempara ... · queria fazer), e pelos muitos desafios durante os 10 anos que estive com vocês. Muito ... (Gugu),quemeapoiaramdesdeo inícionessaempreitada. Aos

  • Upload
    others

  • View
    1

  • Download
    0

Embed Size (px)

Citation preview

Universidade Federal do Rio Grande do NorteInstituto Metrópole Digital

Programa de Pós-graduação em Engenharia de SoftwareMestrado Profissional em Engenharia de Software

SecAuthAPI : Uma abordagem parasuportar infraestruturas de autorização

auto-adaptativas

Welkson Renny de Medeiros

Natal-RNOutubro de 2018

Welkson Renny de Medeiros

SecAuthAPI: Uma abordagem para suportarinfraestruturas de autorização auto-adaptativas

Dissertação de Mestrado apresentada ao Pro-grama de Pós-graduação em Engenharia deSoftware da Universidade Federal do RioGrande do Norte como requisito parcial paraa obtenção do grau de Mestre em Engenhariade 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/RN2018

Medeiros, Welkson Renny de. SecAuthAPI: Uma abordagem para suportar infraestruturas deautorização auto-adaptativas / Welkson Renny de Medeiros. -2018. 90 f.: il.

Dissertação (mestrado) - Universidade Federal do Rio Grandedo Norte, Instituto Metrópole Digital, Programa de Pós-Graduaçãoem 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

Universidade Federal do Rio Grande do Norte - UFRNSistema de Bibliotecas - SISBI

Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede

Elaborado por Ana Cristina Cavalcanti Tinôco - CRB-15/262

Welkson Renny de Medeiros

SecAuthAPI: Uma abordagem para suportarinfraestruturas de autorização auto-adaptativas

Dissertação de Mestrado apresentada ao Pro-grama de Pós-graduação em Engenharia deSoftware da Universidade Federal do RioGrande do Norte como requisito parcial paraa obtenção do grau de Mestre em Engenhariade Software.

Trabalho aprovado. Natal/RN, 30 de outubro de 2018:

Dr. Carlos Eduardo da SilvaOrientador

Dr. Gustavo Henrique Matos BezerraMotta

Examinador Externo à Instituição

Dr. Sílvio Costa SampaioExaminador Interno

Natal/RN2018

Agradecimentos

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, incentivoe suporte necessário.

Muitas pessoas me ajudaram lá no início, em Cruzeta, e não poderia deixar decitá-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 deprogramação e incentivo), entre muitos outros colegas.

Ao pessoal da Focus Automação (Kerginaldo, William, Antônio, André, entreoutros), por me incentivar a fazer faculdade (por incrível que pareça, o matuto aqui nãoqueria fazer), e pelos muitos desafios durante os 10 anos que estive com vocês. Muitoobrigado!

Aos colegas do IFRN, em especial ao professor André Gustavo, por ter possibilitadoo 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 agradecimentoespecial para os amigos Diego Saraiva e José Augusto (Gugu), que me apoiaram desde oiní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 labrespira 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 amigoCephas Barreto por representar tão bem a turma no colegiado, e pela disposição emcontribuir com todos que precisavam.

Agradeço também aos professores do PPGSW! Os conhecimentos compartilhadosforam 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 esseprocesso apesar de difícil foi bastante divertido. Obrigado amigo!

“Quem ouve a repreensão construtivaterá lugar permanente entre os sábios.”

(Bíblia Sagrada, Provérbios 15, 31)

ResumoMecanismos de controle de acesso têm sido utilizados em sistemas de informação pararestringir o acesso a informações sensíveis. Tais mecanismos são capazes de lidar comameaças de agentes externos à instituição, porém são ineficientes quando consideramosataques envolvendo usuários internos. Políticas de controle de acesso estáticas são incapazesde lidar com comportamentos anômalos de usuários maliciosos que abusam de suaspermissões. Sistemas auto-adaptativos têm se mostrado como uma possível resposta paraesta situação, uma vez que são capazes de analisar a si próprios e ao ambiente em queestã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 poderiamser 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 nadefinição de planos de adaptação. Neste sentido, este trabalho propõe o SecAuthAPI, umaabordagem de suporte a infraestruturas de autorização auto-adaptativas baseadas emABAC(Attribute-Based Access Control). As operações são baseada em uma especificaçãofuncional formal do modelo ABAC e permitem a manipulação dinâmica de políticas decontrole de acesso. Considerando a aplicação desta abordagem em um sistema real, estetrabalho também propõe e implementa a externalização dos mecanismos de autorizaçãopara o sistema SUAP, desenvolvido e usado no IFRN, com intuito de desacoplar o controlede acesso da lógica de negócio da aplicação. As operações do SecAuthAPI foram avaliadasatravé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 desempenhoavaliado 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íciostrazidos pelo desacoplamento de preocupação de controle de acesso do código fonte daaplicação.

Palavras-chave: controle de acesso. ameaças internas. abac. sistemas auto-adaptativos.suap

SecAuthAPI: An approach for supportingself-adaptation of authorization infrastructures

Author: Welkson Renny de MedeirosSupervisor: Dr. Carlos Eduardo da Silva

AbstractAccess control mechanisms have been used in information systems to restrict access tosensitive information. Such mechanisms are able to deal with external agent threats, butthey are ineffective when considering attacks involving internal users. Static access controlpolicies are unable to deal with anomalous behavior of malicious users who abuse theirpermissions. 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 onthe behaviour of users, the access control policies could be dynamically modified to dealwith malicious users. However, self-adaptation requires a set of well-defined operationsthat can be used in the definition of adaptation plans. In this sense, this work proposes theSecAuthAPI, an approach to support self-adaptive authorization infrastructures based onABAC (Attribute-Based Access Control). The operations are based on a formal functionalspecification of the ABAC model and aim to enable the dynamic adaptation of accesscontrol policies. Considering the application of this approach in a real system, this workalso proposes and implements the externalization of authorization mechanisms for theSUAP system, developed and used at IFRN, with the intention of decoupling accesscontrol concern from the business logic of the application SecAuthAPI operations wereevaluated through a series of unit tests that attest its adherence to the formal functionalspecification, while separation of access control from SUAP had its performance evaluatedand compared to the legacy approach. The results show that, although it has an additionalcomputational cost, the impact on application performance is negligible. In addition, oursolution is highly feasible in view of the benefits brought due to the decoupling of concernfrom access control from the source code of the application.

Keywords: access control. insider threats. abac. self-adaptive sytems. suap.

Lista de ilustrações

Figura 1 – Tríade AAA (Autenticação, Autorização, Auditoria) . . . . . . . . . . . 21Figura 2 – Modelo de referência RBAC Core . . . . . . . . . . . . . . . . . . . . . 22Figura 3 – Distribuição dos mecanismos de controle de acesso ABAC . . . . . . . 23Figura 4 – Exemplo de aplicação do mecanismo ABAC . . . . . . . . . . . . . . . 24Figura 5 – Modelo de referência MAPE-K para computação autonômica . . . . . . 26Figura 6 – Visão de Self-Protection . . . . . . . . . . . . . . . . . . . . . . . . . . 27Figura 7 – Arquitetura do controle de acesso do SUAP . . . . . . . . . . . . . . . 28Figura 8 – Arquitetura de referência do SUAP . . . . . . . . . . . . . . . . . . . . 29Figura 9 – Arquitetura do SecAuthAPI . . . . . . . . . . . . . . . . . . . . . . . . 31Figura 10 – Diagrama de Sequência do SecAuthAPI . . . . . . . . . . . . . . . . . 33Figura 11 – Diagrama de Classes do SecAuthAPI . . . . . . . . . . . . . . . . . . . 35Figura 12 – Fases da externalização do controle de acesso . . . . . . . . . . . . . . 39Figura 13 – Visão da arquitetura de autorização externalizada para o SUAP . . . . 41Figura 14 – Arquitetura do DjangoPEP . . . . . . . . . . . . . . . . . . . . . . . . 43Figura 15 – Diagrama de classes do WSO2-PIP-SUAP . . . . . . . . . . . . . . . . 45Figura 16 – Processo de negócio da Central de Serviços . . . . . . . . . . . . . . . . 51Figura 17 – Intervenção dinâmica em uma política de controle de acesso . . . . . . 54Figura 18 – Execução dos testes unitários do SecAuthAPI . . . . . . . . . . . . . . 57Figura 19 – Proposta de externalização . . . . . . . . . . . . . . . . . . . . . . . . . 58Figura 20 – Infraestrutura para os experimentos de externalização . . . . . . . . . . 59Figura 21 – Demonstração das abordagens de autorização legada e externalizada . . 60Figura 22 – Tempo de resposta x Número de Usuários . . . . . . . . . . . . . . . . 64

Lista de tabelas

Tabela 1 – API - Operações Administrativas . . . . . . . . . . . . . . . . . . . . . 32Tabela 2 – Avaliação das pré/pós-condições da API via testes unitários . . . . . . 55Tabela 3 – Recursos alocados para a infraestrutura de avaliação . . . . . . . . . . 60Tabela 4 – Plano de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Tabela 5 – Testes de desempenho no SUAP-Legado e SUAP-Externalizado . . . . 63Tabela 6 – SecAuthAPI: AddPolicy() . . . . . . . . . . . . . . . . . . . . . . . . . 85Tabela 7 – SecAuthAPI: DeletePolicy() . . . . . . . . . . . . . . . . . . . . . . . . 85Tabela 8 – SecAuthAPI: ModifyPolicy() . . . . . . . . . . . . . . . . . . . . . . . 86Tabela 9 – SecAuthAPI: AddAttribute() . . . . . . . . . . . . . . . . . . . . . . . 87Tabela 10 – SecAuthAPI: DeleteAttribute() . . . . . . . . . . . . . . . . . . . . . . 87Tabela 11 – SecAuthAPI: ModifyAttribute() . . . . . . . . . . . . . . . . . . . . . . 88Tabela 12 – Testes de desempenho no SUAP-Legado . . . . . . . . . . . . . . . . . 92Tabela 13 – Testes de desempenho no SUAP-Externalizado . . . . . . . . . . . . . 92

Lista de abreviaturas e siglas

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 doNorte

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

PEP Policy Enforcement 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

XSD XML Schema Definition

Sumário

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.1 Problemática e Motivação . . . . . . . . . . . . . . . . . . . . . . . . 161.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.4 Organização do Documento . . . . . . . . . . . . . . . . . . . . . . . 19

2 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . 202.1 Controle de Acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2 Sistemas Auto-Adaptativos . . . . . . . . . . . . . . . . . . . . . . . . 252.3 SUAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.4 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3 SECAUTHAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.4 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4 EXTERNALIZAÇÃO DOS MECANISMOS DE AUTORIZAÇÃO . . 394.1 Proposta de externalização no SUAP . . . . . . . . . . . . . . . . . . 394.2 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.2 Implementação do PEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2.3 Implementação do PIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.3 Demonstração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.4 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5 AVALIAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.1 SecAuthAPI: Manipulação dinâmica de políticas . . . . . . . . . . . . 515.1.1 Preparação do ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.1.2 Demonstração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.1.3 Avaliação da API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.1.4 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.2 Externalização do controle de acesso no SUAP . . . . . . . . . . . . 585.2.1 Preparação do ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.3 Avaliação de Desempenho da Externalização . . . . . . . . . . . . . . 61

5.3.1 Plano de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.3.2 Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.3.3 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . 676.1 Controle de acesso dinâmico . . . . . . . . . . . . . . . . . . . . . . . 676.2 Externalização de controle de acesso . . . . . . . . . . . . . . . . . . 686.3 Ferramentas de controle de acesso em Python . . . . . . . . . . . . 696.4 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . 727.1 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.2 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737.3 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

APÊNDICES 81

APÊNDICE A – SECAUTHAPI: ESPECIFICAÇÃO DA API . . . . 82

APÊNDICE B – POLÍTICAS XACML . . . . . . . . . . . . . . . . 89B.0.1 Política “New Ticket” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89B.0.2 Política “Deny New Ticket by User” . . . . . . . . . . . . . . . . . . . . . 90

APÊNDICE C – RESULTADOS DOS TESTES DE DESEMPENHO 92

14

1 Introdução

Na era da informação, na qual as pessoas utilizam a Internet para efetuar transaçõescomerciais, 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 disponibilidadedos dados destes usuários sejam mantidos em segurança. Em uma pesquisa realizadaem 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 desegurança da informação reportados. Esse número pode ser ainda maior, considerando quemuitas empresas não reportam os ataques sofridos com receio de manchar sua reputaçãodiante do mercado e de seus clientes (KESLER, 2011).

Segundo Collins et al. (2016), historicamente as corporações têm investido emmecanismos de segurança como firewall, IDS (Intrusion Detection System), IPS (IntrusionPrevention System), entre outros, com intuito de se proteger contra ataques envolvendoameaç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árioatuando como funcionário/ex-funcionário, terceirizado, ou parceiro comercial que tem outeve acesso autorizado a rede, sistemas ou dados, e de forma intencional ou não intencionalexcede este acesso afetando negativamente a confidencialidade, integridade e disponibili-dade da informação ou dos sistemas de informação da organização, causando prejuízosfinanceiros, 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 principaismecanismos encontrados na literatura, destaca-se o modelo RBAC (Role-Based AccessControl) (ANSI, 2004), que associa permissões a papéis desempenhados pelos usuários nasorganizações, e o ABAC (Attribute-Based Access Control) (HU et al., 2014), que considerao uso de atributos do sujeito, ação, recurso e ambiente na definição das políticas de controlede acesso.

Entretanto, os mecanismos de controle de acesso não são capazes de detectarcomportamentos anômalos ou desvios comportamentais. A ineficácia dos mecanismos decontrole de acesso em lidar com ameaças internas tem contribuído para que cada vez maisa mídia noticie o roubo e exposição de informações sensíveis de instituições governamentaise corporações.

Booth, Brooke e Morris (2010) relata um caso envolvendo vazamento de dadossensíveis realizado por um analista de segurança do Exército Americano, que fez download1 https://www.cert.org/

Capítulo 1. Introdução 15

de mais de 250 mil documentos sigilosos usando suas credenciais no site do Departamentode Defesa e os publicou na internet. Em 2013, um ex-contratado da NSA copiou mais deum milhão de documentos confidenciais, e vazou para mídia detalhes do funcionamento doprograma 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, ondeum analista de investimentos utilizou de suas permissões e conhecimento sobre as rotinasdo sistema bancário para realizar transações não autorizadas, ocasionando perdas para obanco de aproximadamente 2 bilhões de dólares (YASEEN, 2017).

Um dos desafios em lidar com esses eventos anômalos está relacionado ao fato queos mecanismos de controle de acesso comumente implementados pelas organizações sãoestáticos. As políticas de controle de acesso definem se um usuário pode ou não acessardeterminado recurso no momento da tentativa de acesso. No entanto, não consideramdesvios na rotina como acesso a uma grande quantidade de documentos em um curtoperíodo de tempo, por exemplo, sendo incapazes de impedir ou mitigar atividades maliciosasdesta 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ômicosque monitoram continuamente o contexto em que estão inseridos, e são capazes de ajustarseu comportamento em resposta a mudanças no ambiente (CHENG et al., 2014). Oprincipal 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 algumasfunções de gerenciamento, e 4 partes que compartilham conhecimento (Knowledge) e sãoresponsá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, detectare 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 depolíticas de controle de acesso para mitigar o dano, tal como proposto por Bailey, Chadwicke Lemos (2011) e Silva et al. (2017). Neste sentido, auto-adaptação aplicado a segurançade 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 emsistemas 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 doNorte). O SUAP (Sistema Unificado de Administração Pública) implementa um mecanismode controle de acesso baseado no modelo RBAC, no qual as permissões são criadas eassociadas a papéis, e estes papéis são atribuídos aos usuários para que seja concedido ou

Capítulo 1. Introdução 16

negado permissão a determinado recurso. O SUAP é utilizado no IFRN, onde atualmenteatende mais de 20 mil usuários entre alunos, servidores e prestadores de serviços, e viaacordo de cooperação é cedido para mais de 20 outros Institutos Federais pelo Brasil. Oautor da proposta é Analista de Tecnologia da Informação no IFRN, e desde o ano 2012integra a equipe que mantém o SUAP, atuando diretamente na resposta a incidentes desegurança da informação envolvendo ativos de rede e sistemas.

1.1 Problemática e MotivaçãoNa 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 destestrabalhos, Silva et al. (2017) propõe o saRBAC, uma abordagem que de forma autonômicafaz a verificação de modelos estocásticos baseados em log‘s de execução de processos denegócio para estabelecer um intervalo de confiança que permita mensurar o comportamentodo 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 decontrole de acesso considerando um cenário real baseado no SUAP, entretanto, os usuáriosmaliciosos 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 manipulardinamicamente as políticas de controle de acesso, e assegurar que os atributos de qualidadesejam atendidos, é proposto na literatura o uso de métodos formais para garantir que asoperaçõ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 definindooperações administrativas para criação e manutenção de elementos de uma política decontrole 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 administrativasbaseadas em especificação funcional. Entretanto, uma proposta de verificação formal em Zpara o modelo ABAC e a especificação funcional com operações administrativas é propostopor Gouglidis et al. (2017). A especificação funcional dos modelos citados anteriormentedefinem operações de granularidade fina como a modificação de uma política ABAC aní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 atributoespecífico na política para impedir que determinado perfil de usuário acesse um recurso,

Capítulo 1. Introdução 17

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 sistemareal está relacionado ao fato que comumente os servidores de autorização não fornecemoperações granulares em suas API’s, e segundo Hu et al. (2014), modelos como o RBAC temdificuldades em lidar com arquiteturas onde decisões de controle de acesso dinâmicas sãorequeridas, sendo o modelo ABAC mais recomendado devido a facilidade que suas políticastêm em expressar regras complexas que podem avaliar diferentes atributos. Servidores deautorização como o FIware AuthZForce2 e o WSO2 IS (Identity Server)3 expõem operaçõespara a manipulação de políticas RBAC/ABAC via API, no entanto, essas operações sãode granularidade grossa, e consequentemente não suportam alteração de políticas a nívelde 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ãouniformidade das tecnologias suportadas pelos servidores de autorização, como SOAP naAPI 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 maneiraagnó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 principaismotivadores deste trabalho.

No contexto da aplicação desta abordagem em um sistema real, uma avaliação emudanças na arquitetura e mecanismos de controle de acesso do sistema a ser protegidodevem ser realizadas. No sistema usado no nosso estudo, o SUAP, observa-se que osmecanismos de controle de acesso da forma como estão implementados não proveem meiospara que as políticas de controle de acesso sejam manipuladas em tempo de execução. Aassociaçã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 decorators4 (similar a annotations no Java) definindo quais papéis são autorizados a acessar orecurso. O problema desta abordagem é que ela é pouco flexível do ponto de vista dequem administra os acessos dos usuários, pois se for requerido um novo papel para acessardeterminado recurso, será necessário alterar os parâmetros do decorator no código daaplicaçã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ção2 https://github.com/authzforce/server3 https://wso2.com/identity-and-access-management4 Exemplo de Decorator em Python: @group_required(u’Secretário EDU,Diretor EDU’)

Capítulo 1. Introdução 18

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 interfacespara 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 paramanipulaçã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çãoe não sobre a aplicação a ser protegida então deve-se (2) avaliar, propor e implementarmudanças no sistema a ser protegido considerando a externalização dos mecanismos deautorização.

1.2 ObjetivoNesse 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çãoatravé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 interfacepara manipulação de baixa granularidade de políticas de controle de acesso ABACbaseada 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 ummodelo de controle de acesso ABAC, incluindo a externalização dos mecanismos deautorização, mudanças na infraestrutura do sistema, e mecanismos para a definiçãode políticas.

• Avaliar a infraestrutura de autorização externalizada via testes de desempenho ecomparar com a abordagem legada com intuito de verificar a viabilidade da adoçãoda 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çãogranular para manipulação de políticas, e a integração e avaliação de forma simuladacom o controlador auto-adaptativo saRBAC (SILVA et al., 2017). Esta dissertação é umaevolução do SecAuthAPI em relação ao exposto no artigo, considerando que o Core daproposta foi reescrito permitindo maior flexibilidade na manipulação das políticas, e todasas operações granulares baseadas em especificação funcional formal estão implementadas e

Capítulo 1. Introdução 19

testadas. Esta dissertação apresenta também as etapas para externalizar os mecanismosde autorização em um sistema real, e baseado nessas fases implementa uma demonstraçãono sistema SUAP.

1.3 MetodologiaO 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 controlede acesso, insider threats, entre outros.

• Escolha das ferramentas: levantamento e testes em ferramentas open-source queatuam como servidores de autorização com suporte a ABAC e com API paramanipulaçã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çãoauto-adaptativas.

• Demonstração: as propostas de manipulação dinâmica de políticas de controle deacesso e a externalização dos mecanismos de autorização são demonstrados a partirde aplicações de exemplos.

• Avaliação: a proposta de manipulação dinâmica é avaliada a partir de testes unitárioscom intuito de garantir a conformidade com a especificação funcional, e para aproposta de externalização são realizados testes de desempenho e comparados com aabordagem legada com intuito de verificar a viabilidade em um sistema real.

1.4 Organização do DocumentoOs 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 temasque serão discutidos no restante deste trabalho. No capítulo 3 é apresentado o SecAuthAPIe sua implementação. O capítulo 4 apresenta um estudo sobre o processo de externalizaçãodos mecanismos de autorização em sistemas reais, e propõe e implementa os componentese as mudanças na arquitetura usando o sistema SUAP como referência. O capítulo 5apresenta a demonstração e avaliação do SecAuthAPI e da externalização no SUAP. Ostrabalhos relacionados a esta pesquisa são apresentados no capítulo 6, e no capítulo 7 sãorealizadas as considerações finais deste trabalho, as contribuições e limitações, e por fim aindicação de trabalhos futuros.

20

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 aplicadosno 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 AcessoO controle de acesso é um dos componentes fundamentais para garantir a segurança

de sistemas computacionais. Segundo Sandhu e Samarati (1994), “o propósito de umcontrole de acesso é limitar as ações ou operações que um usuário legítimo de um sistemade computador pode realizar”. A terminologia relacionada a controle de acesso utilizadanas ú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 decomputador executando em nome de um determinado usuário;

• Objeto: recursos que podem ser acessados em um sistema de computador, tais comoum 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 arquiteturaAAA (Authentication, Authorization e Auditing) ou autenticação, autorização e auditoriarespectivamente, 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 dedados da própria aplicação (autenticação local), ou através de mecanismos externosa aplicação (autenticação externalizada) como serviços de diretório (Microsoft ActiveDirectory, OpenLDAP, por exemplo), serviços de identidade (OIDC - OpenID Connectpor exemplo), entre outros. Comumente as corporações adotam a externalização da

Capítulo 2. Referencial Teórico 21

autenticação nos seus sistemas, possibilitando que as mesmas credenciais do usuário sejamutilizadas 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 decontrole diretamente no código da aplicação, no entanto alguns produtos como o WSO2 ISe OpenAM já fornecem mecanismos para externalização da autorização. A externalizaçãoda autorização será melhor detalhada no decorrer desta seção.

A Figura 1 apresenta um exemplo da tríade AAA, em que um sujeito tenta acessarum determinado recurso protegido (ex.: relatório, arquivo, entre outros). Na primeirafase o sistema solicita a autenticação do usuário (usuário e senha por exemplo), e casoas credenciais informadas na autenticação estejam corretas o sistema verifica se o sujeitotem permissão para acessar o recurso (fase de autorização), e em caso positivo o acesso aorecurso é permitido. A caixa sombreada de azul mostra a fase de auditoria, que registra oseventos de controle de acesso, como login do usuário, data e hora do acesso, operação erecurso 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 demodelos de controle de acesso (THION, 2007). O modelo RBAC introduz o conceito depermissões associadas a papéis, no qual os usuários são atribuídos a estes papéis. SegundoANSI (2004), “papéis são criados para várias funções de trabalho na organização e osusuá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 foremnecessárias. Ao revogar uma determinada permissão em um papel, todos os usuáriosque 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 umdeterminado papel uma nova sessão (SESSIONS) é criada. Cada papel tem uma ou maispermissõ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 destemodelo é o problema de explosão de papéis, que ocorre quando o número de papéis criadospara atender determinadas especificidades cresce de forma a inviabilizar a administraçãodo controle de acesso, e podendo chegar a casos onde o número de papéis é maior que onúmero de usuários em sistemas em larga escala (ELLIOTT; KNIGHT, 2010).

Capítulo 2. Referencial Teórico 22

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 modeloRBAC denominada RBAC Policy-Enhanced (RPE) (ANSI, 2012), que suporta atributoscomo parte das restrições nas decisões de controle de acesso, e tem como objetivo lidarcom a pouca flexibilidade do modelo RBAC em domínios que mudam rapidamente. Algunsdos servidores de autorização avaliados neste trabalho e apresentados ao longo desta seçãosuportam RBAC, entretanto, não suportam RPE.

O uso de atributos para definição de políticas de controle de acesso fora discutidoanteriormente por Yuan e Tong (2005), que propõe o modelo ABAC (Attribute BasedAccess 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çõespara realizar operações em um determinado objeto ou recurso são permitidas ou negadasde acordo com atributos. Os atributos contêm informações no formato chave-valor, erepresentam 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 controlede acesso que determinam se uma requisição será ou não permitida de acordo com osvalores dos atributos.

Um mecanismo de controle de acesso RBAC/ABAC apresenta uma arquiteturafuncional com um conjunto de componentes necessários para seu funcionamento. A Figura3 apresenta uma arquitetura com a distribuição e gerenciamento dos mecanismos decontrole de acesso, onde são destacados os principais pontos funcionais como PEP (PolicyEnforcement Point), PDP (Policy Decision Point), PAP (Policy Administration Point) ePIP (Policy Information Point).

O PEP intercepta as requisições entre o sujeito e o objeto, em seguida gera umarequisiçã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

Capítulo 2. Referencial Teórico 23

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 peloPEP, avalia os atributos e computa a decisão de acordo com o que está definido na políticade controle de acesso, e por fim retorna a decisão para o PEP. O PAP é responsável porprovê uma interface para gerenciamento das políticas de controle de acesso, e armazenaressas políticas em um repositório (PR ou Policy Repository). O PIP é responsável porrecuperar atributos necessários para a avaliação da política, por exemplo, a política esperaN atributos, sendo um deles disponível apenas em uma fonte externa como uma baseLDAP, portanto, no momento da avaliação do acesso pelo PDP, o mesmo irá detectarque os atributos recebidos na requisição de autorização não são suficientes para avaliar apolítica, e irá solicitar ao PIP que recupere o conteúdo deste atributo a partir da fonteexterna, no caso um LDAP.

A Figura 4 apresenta um exemplo destes componentes funcionais aplicados emuma arquitetura de controle de acesso ABAC. Neste exemplo o usuário ao tentar acessarum recurso protegido tem sua requisição interceptada por um PEP, que recupera seusatributos da requisição (onde userxyz é nome do usuário, POST a ação, /new_ticket orecurso sendo acessado e suporte o papel atribuído ao usuário), em seguida encaminhaesta requisição para o PDP, que recupera as políticas do repositório, e por fim compara osatributos da requisição com os atributos esperados pela política ABAC, e se os valores dosatributos estiverem iguais o acesso é permitido, caso contrário é negado.

Capítulo 2. Referencial Teórico 24

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 decontrole de acesso é o eXtensible Access Control Markup Language (XACML) propostocomo padrão pelo OASIS (PARDUCCI; LOCKHART; RISSANEN, 2013). O XACMLé uma linguagem de extensão do XML que especifica os tipos de elementos que podemser utilizados na definição de uma política, como as regras, algoritmos de combinação deregras, atributos, obligations (condição adicional que deve ser aplicada obrigatoriamentepelo PEP antes de liberar ou negar o acesso), advice (similar ao obligations, no entanto oPEP pode se negar a aplicar a condição adicional), além de definir o formato de troca demensagens entre o PEP e o PDP, que é o XACML Request para o envio de requisiçõesde autorização, e o XACML Response para resposta da avaliação com a decisão final depermitir 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 deoperações administrativas, computa decisão de forma eficiente através de um algoritmolinear, entre outros (HAREL, 2017), no entanto, não há produtos comerciais ou open-sourcemaduros 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 sendoatualizado, e pesquisado em periódicos e conferências de referência no âmbito de controlede 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 umaarquitetura que considere a externalização dos componentes funcionais é requerido um1 https://github.com/PM-Master/Policy-Machine2 https://csrc.nist.gov/Projects/Policy-Machine3 http://www.sacmat.org/

Capítulo 2. Referencial Teórico 25

servidor de autorização com suporte a interfaces PAP, PDP, e que suporte a linguagemXACML (BROSSARD; GEBEL; BERG, 2017). Durante o desenvolvimento deste trabalhoalguns 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 alinguagem OASIS XACML v3.0, e uma API REST para a interface PAP com suportea operações básicas como a inserção e remoção de políticas ABAC. Esta solução nãofornece interface web para gerenciamento das políticas.

• WSO2 Identify Server5: fornece API REST para o PDP e SOAP para o PAP, alémdo suporte a single-sign-on (SSO) com os protocolos OpenID Connect, SAML 2.0 eWS-Federation, e módulos para atuar como provedor de identidades (IDP) e provedorde serviços (SP). Esta solução fornece uma interface web denominada Carbon, quepossibilita criar políticas XACML de forma simplificada usando assistentes, avaliara política simulando requisições de autorização, entre outros.

• OpenAM 6: 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 2015a ForgeRock abandonou o projeto open-source, e mantém apenas a versão comercialdo produto denominado ForgeRock Identity Management7.

• AT&T XACML8: implementação de referência do OASIS XACML 3.0 feito pelaAT&T em linguagem Java. A solução fornece API’s REST para PAP e PDP, e umainterface 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 encontradasnas demais soluções (dashboard, suporte a RBAC e ABAC, etc.), e fornecer suporte pagocaso seja necessário na adoção corporativa, o WSO2 IS se mostrou a melhor escolha paraauxiliar no desenvolvimento desta proposta.

2.2 Sistemas Auto-AdaptativosSelf-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 sobrevariadas 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 é um4 https://github.com/authzforce/server5 https://wso2.com/identity-and-access-management6 https://github.com/ForgeRock/openam-community-edition7 https://www.forgerock.com/platform/identity-management8 https://github.com/att/XACML

Capítulo 2. Referencial Teórico 26

modelo de referência para o desenvolvimento de sistemas auto-adaptativos baseados emelementos capazes de gerir recursos externos e seu comportamento interno. A proposta doloop 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 softwareou recurso de hardware com comportamento autônomo que é acoplado através de umAutonomic Manager. O Monitor sonda continuamente as informações de contexto atravésdos 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 noplano e altera o comportamento do Managed Element através de um Effector. Todosos componentes compartilham conhecimento através do elemento Knowledge Manager.Portanto, um sistema auto-adaptativo é capaz de realizar auto-gerenciamento atravésda 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çara mudança necessária.

Segundo Kephart 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 autorestambém listam os 4 principais aspectos relacionados a auto-gerenciamento em computaçãoautonômica, que são:

• Self-Configuration ou auto-configuração: configuração automática de componentes esistemas seguindo políticas de alto nível.

• Self-Optimization ou auto-otimização: componentes e sistemas buscam continuamenteoportunidades para melhorar sua própria eficiência e desempenho.

Capítulo 2. Referencial Teórico 27

• Self-Healing ou auto-recuperação: o sistema automaticamente detecta, diagnostica erepara os problemas localizados em hardware e software.

• Self-Protection ou auto-proteção: o sistema se defende automaticamente contraataques maliciosos ou falhas em cascata.

No contexto de segurança da informação, Yuan, Esfahani e Malek (2014) propõemuma 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ávelpor 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 monitoraro ambiente de domínio (Domain) onde o software a ser protegido está executando.

Figura 6 – Visão de Self-Protection

Fonte: Elaborado por Yuan, Esfahani e Malek (2014)

Considerando esta abordagem aplicada a mecanismos de controle de acesso, oProtected Subsystem (Base-level) é a infraestrutura de autorização alvo, que contémuma implementação específica de um modelo controle de acesso. O conhecimento sobre osserviços disponíveis e como se comunicar com estes é mandatório para o componente Executeser capaz de executar os planos de adaptação da melhor forma possível. São exemplosde 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 deintervençã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 oestado 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 contextode segurança da informação vêm sendo desenvolvidos no laboratório Stela (SmarT Envi-

Capítulo 2. Referencial Teórico 28

ronment LAboratory)9 do IMD/UFRN coordenado pelo professor Dr. Carlos Eduardo daSilva, 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 etal., 2018).

2.3 SUAPO 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 TIdo IFRN e atualmente é distribuído para mais de 20 institutos federais pelo Brasil pormeio de acordos de cooperação. O desenvolvimento do sistema é baseado em tecnologiasopen-source, tais como a linguagem Python10, o framework Django11, e o banco de dadosPostgreSQL12.

A Figura 7 apresenta a arquitetura conceitual do sistema, onde no topo sãoapresentados alguns módulos como o Edu (gestão educacional), RH (recursos humanos), eADM (administração), sendo que o sistema já conta com mais de 40 módulos. O móduloldap_backend permite que SUAP externalize a autenticação de usuários através de umabase de usuários do serviço de diretório AD (Microsoft Active Directory), além de permitirque o SUAP insira usuários em grupos do AD para controlar acesso a pastas em servidoresde 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, umframework web que fornece diversos componentes plugáveis e reutilizáveis, dentre os quaisdestaca-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-

Silva10 https://www.python.org/11 https://www.djangoproject.com/12 https://www.postgresql.org/

Capítulo 2. Referencial Teórico 29

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 RelationalMapping ou Mapeamento Objeto Relacional, entre outras operações envolvendo banco dedados), entre outros. Na parte inferior e sombreado na cor laranja são apresentados algunsframeworks de terceiros utilizados para suporte a banco de dados PostgresSQL (psycopg2 ),acesso a diretórios LDAP (python-ldap), API’s REST (Django Rest Framework), entreoutros.

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 fornecidaspelo middleware, destaca-se o mecanismo para registro de novos usuários, armazenamentoseguro 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 apartir da base de dados da aplicação, no entanto há classes de extensão que possibilitam aexternalização da autenticação. Isso é explorado pelo SUAP através da externalização degerência de usuários e autenticação para uma base LDAP (Microsoft AD ou OpenLDAPvia pacote python-ldap).

No tocante a autorização, o middleware fornece mecanismos que possibilitam aimplementação de políticas baseadas em grupos de usuários (baseada em RBAC) comobjetivo de restringir acessos a recursos. As restrições de acesso a determinado recursopodem 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ãosuporta a externalização dos mecanismos de autorização. Esta limitação será abordadadurante 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 SUAP13 https://docs.djangoproject.com/en/1.8/_modules/django/contrib/auth/middleware/

Capítulo 2. Referencial Teórico 30

considerando os componentes utilizados no ambiente em produção no IFRN. Observa-seque o usuário acessa o sistema SUAP a partir do browser de um dispositivo ou do aplicativoSUAP Mobile para smartphones, em seguida essa requisição é recebida por um servidor webNGnix14, que atua como um proxy reverso encaminhando as requisições para o servidor deaplicação Django denominado Gunicorn15. A arquitetura também prevê o serviço MicrosoftActive Directory, o qual é utilizado pelo SUAP para autenticar os usuários a partir de umabase única, além de um outro servidor Linux executando o banco de dados PostgreSQL.O ELK16 (ElasticSearch, LogStash, Kibana) é um componente opcional da arquiteturado SUAP, mas importante na parte de coleta de log‘s (LogStash), armazenamento embase de dados NoSQL para suporte a grandes volumes de dados (ElasticSearch), e paravisualização analítica (Kibana).

2.4 DiscussãoNeste capítulo foram apresentados alguns conceitos importantes para compreensão

da proposta deste trabalho. Na seção 2.1 foi realizado uma breve introdução sobre controlede acesso, destacando os principais mecanismos e modelos, como o RBAC (baseado empapéis) e ABAC (baseado em atributos), além de destacar a importância de externalizaro controle de acesso em uma arquitetura baseada em pontos funcionais. Em seguidafoi 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 contextode segurança da informação ou auto-proteção (Self-Protection). Por fim, na seção 2.3foi apresentado o SUAP, um sistema desenvolvido no IFRN para gestão acadêmica eadministrativa da instituição, e que foi selecionado para ser usado na demonstração eavaliação da abordagem proposta neste trabalho.

14 https://nginx.org/en/15 http://gunicorn.org/16 https://www.elastic.co/elk-stack

31

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çãode infraestruturas de autorização, fornecendo uma interface padronizada para manipularpolíticas de controle de acesso em servidores de autorização de maneira agnóstica (PAP-Agnostic) usando a linguagem XACML (PARDUCCI; LOCKHART; RISSANEN, 2013), ebaseado 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 ArquiteturaA arquitetura do SecAuthAPI é apresentada na Figura 9. O SecAuthAPI atua

como um effector, fornecendo operações para controladores auto-adaptativos, que em umcontexto de segurança da informação são capazes de identificar e responder a atividadesanômalas. Essas ferramentas podem se comunicar com o SecAuthAPI através de umainterface 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 asencaminha para um adaptador específico no pacote Adapter. Este adaptador é responsávelpor implementar as chamadas para cada servidor de autorização.

Os servidores de autorização fornecem diferentes operações para manipulação depolíticas e em diferentes protocolos de acesso através da sua interface PAP. O SecAuthAPIimplementa adaptadores que fazem a orquestração de chamadas específicas para cada

Capítulo 3. SecAuthAPI 32

servidor de autorização, suportando no momento os produtos WSO2 Identity Server eFIware AuthZForce, WSO2 Adapter e AZF Adapter respectivamente. A arquitetura propostaé flexível, possibilitando que novos adaptadores sejam implementados para outros servidoresde autorização (ex.: OpenAM, AT&T XACML, entre outros).

O pacote Core é responsável pela manipulação local das políticas de controlede 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 depolítica não é suportada pelos servidores de autorização, tais como as operações granularesde manipulação de políticas a nível de atributo.

Na sequência, será apresentado o design do SecAuthAPI e o detalhamento daimplementação dos componentes desta proposta.

3.2 DesignO SecAuthAPI é baseado na especificação formal proposta por Gouglidis et al. (2017)

para o modelo ABAC. Nesta especificação são definidas operações para administração depolí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 naTabela 1. O Apêndice A apresenta o detalhamento de todas as operações do SecAuthAPIconsiderando suas pré e pós-condições. O componente é baseado no padrão arquiteturalREST (FIELDING, 2000), sendo as operações/métodos apresentadas em termos de verbosHTTP (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 verboGET representa a recuperação de um recurso/objeto (leitura), o POST a criação, PUT amodificação, e DELETE a exclusão. Na tabela a operação responsável por inserir uma novapolítica é acionada através do verbo POST e recurso /policy.

Tabela 1 – API - Operações Administrativas

Verbo HTTP Recurso DescriçãoPOST /policy Insere política no PAPPUT /policy/policy_name Modifica política no PAPDELETE /policy/policy_name Exclui política no PAP

Além dos parâmetros submetidos via URL (policy_name ou nome da política porexemplo), o SecAuthAPI requer a inclusão de parâmetros adicionais no corpo da requisiçãoHTTP para algumas operações. Por exemplo, para inserir uma nova política é necessário

Capítulo 3. SecAuthAPI 33

informar o código em XML (XACML) da mesma, no entanto em políticas com um grandenúmero de regras e atributos o tamanho da URL pode estourar o limite tanto do browserquanto do servidor web, portanto este código é submetido como parâmetro no corpo darequisição. O detalhamento dos parâmetros na URL e no corpo da requisição HTTP sãoapresentados no apêndice A.

Como forma de demonstrar o funcionamento do SecAuthAPI, a figura 10 apresentaum 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çãoa 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 é tratadapelo método policy_attribute do pacote API, que é responsável por todas as operaçõesde manipulação a nível de atributo, sendo as ações como criar, alterar e excluir acionadasbaseado no verbo HTTP utilizando na requisição (no exemplo é utilizado POST). Osparâmetros do corpo da requisição responsáveis por definir a categoria, nome e valor doatributo foram omitidos neste exemplo por questão de espaço.

Baseado nos parâmetros informados, o SecAuthAPI faz uma chamada a um métodoque se encontra no pacote Adapter denominado add_attribute(), e este antes de iniciar amanipulação da política faz uma chamada a operação getPolicy da API PAP do servidorde 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

Capítulo 3. SecAuthAPI 34

excluir uma política de forma geral), ou de granularidade fina (alterar a política a nível deatributo). Neste caso, por se tratar de uma operação de manipulação a nível de atributo, eesta operação não ser suportada pela API do servidor de autorização em questão, então oAdapter faz uma chamada ao método add_attribute() do pacote Core, onde este métodoabre o código da política em linguagem XACML, e manipula o XML inserindo o novoatributo em questão, e por fim devolve para o adaptador. No passo seguinte, o adaptadorencaminha o código da nova política (já com o atributo inserido) para o servidor deautorização através da sua API PAP utilizando o método updatePolicy(), e este devolveo status da operação para o SecAuthAPI, que em seguida encaminha para o controladorauto-adaptativo.

Por fim, para as operações que não envolvam manipulação granular de políticaso procedimento é similar, no entanto não é necessário chamar os métodos contidos nopacote Core, já que as operações são suportadas pelos servidores de autorização e podemser encaminhadas diretamente para a API dos mesmos.

3.3 ImplementaçãoO protótipo do SecAuthAPI é implementado em Python1 com auxílio do framework

web Django. O Django é utilizado no desenvolvimento da camada de persistência daspolíticas no banco de dados, na interface web para administração de políticas, e nostestes unitários. A interface REST API é implementada usando o framework Django RestFramework2, que provê mecanismos para autenticação, serialização de dados, navegaçãona API, e outros. As operações fornecidas pela API, bem como os verbos HTTP e códigosde retorno são baseados na especificação semântica do protocolo HTTP apresentada naRFC 7231 (FIELDING; RESCHKE, 2014).

A Figura 11 apresenta um diagrama UML que destaca os principais pacotes eclasses 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 descriptionarmazena uma descrição mais detalhada da política, e por fim content armazena o códigoda política em linguagem XACML. Os métodos para criação, edição e exclusão sãoimplementados pelo Django Framework, entretanto, o método Save foi sobrescrito naclasse Policy para permitir que o nome da política seja recuperado a partir do códigoXACML, já que o nome da política é utilizado como parâmetro nas API’s dos servidoresde autorização (ex.: WSO2 IS).

O pacote Core também contém uma classe denominada Xacml_Util, que é res-1 https://www.python.org/2 http://www.django-rest-framework.org/

Capítulo 3. SecAuthAPI 35

ponsável por disponibilizar métodos que possibilitam a manipulação granular de umapolítica XACML, como a inserção de um atributo em uma política existente (métodoadd_attribute()) por exemplo, operação esta não suportada pela API dos servidores deautorizaçã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 recursosREST da API, por exemplo, quando um recurso da API é chamado, um método da classePolicyViewSet 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 quandonecessá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 é realizadopela classe Adapter. As classes WSO2 e AuthZForce são implementações concretas da classeabstrata AuthService, que contém métodos abstratos com operações comuns a todos osservidores de autorização e que devem ser implementados pelas classes que a herdam.

Operações funcionais como Add Policy e Delete Policy já são suportadas pelos

Capítulo 3. SecAuthAPI 36

servidores de autorização WSO2 e AuthZForce, entretanto, as interfaces fornecidas pelaAPI dos servidores de autorização implementam tecnologias distintas. O AuthZForcepermite 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íticade acordo com o protocolo utilizado pelo servidor de autorização. A implementação destaclasse é baseada no padrão de projeto Adapter (GAMMA et al., 1995), que permite queinterfaces distintas trabalhem em conjunto. As operações de manipulação são realizadasusando métodos específicos de cada produto, por exemplo, WSO2 requer que a políticaseja enviada usando envelope SOAP a partir do método add_policy() da classe concretaWSO2.

Quando um método de manipulação a nível de atributo é chamado usando oSecAuthAPI, o mesmo recupera a política XACML (formato XML), converte o XML emobjetos 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 utilizandoXACML 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 por Gouglidis 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 formatoJSON através do corpo da requisição.

O protótipo foi implementado levando em consideração o baixo acoplamento deseus componentes. Se necessário, a API REST (pacote API na figura 11) pode ser alteradapara outro método de chamada remota como XML-RPC 4, SOAP5, entre outros. A APIfornece as operações de forma padronizada, e internamente interage com os servidores deautorização utilizando adaptadores (Adapters) específicos para cada servidor de autorização,e estes adaptadores implementam as chamadas para as interfaces suportadas pelo servidorde autorização em uso. Para este protótipo os servidores de autorização WSO2 IS eAuthZForce foram utilizados, entretanto, novos produtos podem ser implementados apartir da classe abstrata AuthService.

A Listagem 3.1 exibe um exemplo de chamada via linha de comando usando cURL(cliente HTTP), onde o recurso /policy do SecAuthAPI é acionado para inserir uma novapolítica XACML na interface PAP do servidor de autorização. O parâmetro “-X” defineo verbo HTTP (no caso POST, já que trata-se da inserção de uma nova política), emseguida 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), uma3 https://github.com/jamedeiros/XACML_Parser (desenvolvido com colaboração de Augusto/IFRN)4 https//docs.python.org/2/library/xmlrpclib.html5 https://pypi.python.org/pypi/soaplib

Capítulo 3. SecAuthAPI 37

breve descrição da política (description), e o conteúdo (content) da mesma em linguagemXACML.

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.2 apresenta um exemplo de uso de uma operação do SecAuthAPIpara modificação de política a nível de atributo. Na URL da API é informado o nome dapolítica (NewTicketOnlySupport), a regra na qual o atributo está inserido (NewTicket), evia 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) ovalor 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êndice A.

3.4 DiscussãoNeste 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çãofuncional ABAC. O protótipo expõe para os controladores auto-adaptativos uma APIREST com operações para manipulação de políticas XACML de maneira agnóstica deservidor 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ãodo código para suporte a outros servidores de autorização. Nesta fase da pesquisa oprotótipo está funcional para todas as operações de manipulação de políticas no servidorde autorização WSO2 IS, e necessita de testes no FIware AuthZForce.

Durante a implementação, o maior desafio encontrado foi a falta de bibliotecas ecó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áriomanipular vários elementos e posicioná-los na hierarquia correta conforme descrito naespecificação do XACML (PARDUCCI; LOCKHART; RISSANEN, 2013).

Uma solução é a aplicação de técnicas de transformação de modelos (EMF ouEclipse Modeling Framework), que envolve importar o schema XSD do XACML usando

Capítulo 3. SecAuthAPI 38

ferramentas EMF, que geram o código com métodos para manipulação da estrutura doXML de forma automática, no entanto, a implementação de transformação de modelospyecore6 em linguagem Python não suporta a importação de arquivos XSD, sendo esta umafuncionalidade específica da implementação Java7. Outras ferramentas como o GenerateDSforam avaliadas, no entanto o código gerado não contemplava operações no nível degranularidade exigidas pelo SecAuthAPI. Uma outra solução é converter o XML em umdicionário (dict em Python) usando a biblioteca xmltodict8, efetuar as manipulações naestrutura da política usando estes dicionários, e por fim converter o dicionário de volta paraXML, no entanto esta abordagem mostrou-se pouco eficiente nas operações de inserçãode atributos, e requeria muitos testes condicionais, que ocasionou um código de difícillegibilidade e manutenção.

Diante dos problemas enfrentados com as soluções de transformação de modelose outras bibliotecas de manipulação de XML em Python no que se refere a politicasXACML, o autor da proposta com colaboração do desenvolvedor José Augusto Medei-ros (COSINF/IFRN) propôs e implementou o XACML_Parser, que tem como objetivoimportar o código de uma política XACML em formato texto (XML), transformá-la emobjetos através de técnicas de parser, fornecer operações para manipulação desses objetos,e por fim transformá-los de volta em uma política XACML váida (a estrutura da políticaé validada através de um esquema XSD fornecido pelo OASIS9). O XACML_Parser jáestá integrado ao código do SecAuthAPI, e todas as operações relacionadas a manipulaçãode políticas estão funcionais e implementadas de forma simples e eficiente.

Por fim, é importante reforçar que o SecAuthAPI atua diretamente no servidor deautorização, e não tem nenhuma integração com sistema a ser protegido (por exemplo,o SUAP), portanto, o uso dessa abordagem está condicionada a sistemas que tenhamseus mecanismos de autorização externalizados. Neste cenário, o SecAuthAPI manipulaas políticas nos servidores de autorização, e os sistemas com mecanismos de autorizaçãoexternalizados consultam estes servidores de autorização que computam as decisões deacesso, e portanto, acessos maliciosos podem ser restringidos devido a políticas quepreviamente foram manipuladas pelo SecAuthAPI a pedido do controlador auto-adaptativo(saRBAC por exemplo). O plano de auto-adaptação com o encadeamento das ações aserem realizadas na política para conter o ataque, e a avaliação do impacto desta mudançasão de responsabilidade do controlador autonômico e estão fora do escopo deste trabalho.

6 https://github.com/pyecore/pyecore7 https://www.eclipse.org/modeling/emf/8 https://github.com/martinblech/xmltodict9 https://docs.oasis-open.org/xacml/3.0/XSD/

39

4 Externalização dos mecanismos de autori-zação

Este capítulo apresenta um estudo sobre a externalização dos mecanismos deautorização em um sistema existente, o SUAP. Este estudo foi motivado, entre outrosaspectos, pelo nosso interesse em aplicar o SecAuthAPI para manipular políticas de controlede acesso do SUAP. Inicialmente são descritas uma sequência de fases a serem realizadaspara atingir o objetivo de externalizar a autorização. Por fim, é proposto uma visão danova arquitetura de autorização considerando a externalização, e a implementação dealguns componentes de suporte.

4.1 Proposta de externalização no SUAPEsta seção apresenta uma sequência de fases que captura o processo realizado

para externalização dos mecanismos de controle de acesso no SUAP. Neste momento, aabordagem proposta foi toda pensada e aplicada ao sistema SUAP. Entretanto, nadaimpede de que no futuro a mesma seja evoluída para uma proposta genérica e agnósticade tecnologia o suficiente para ser aplicada em qualquer sistema. A figura 12 apresenta emformato de diagrama de atividades da UML as fases aplicadas na externalização. As fase 1e 2 podem ser realizadas em paralelo.

Figura 12 – Fases da externalização do controle de acesso

Fonte: Elaborado pelo autor

A descrição de cada fase e as ações a serem executadas são apresentadas a seguir:

Fase 1 (Avaliar mecanismos de autorização no SUAP): nesta fase o SUAP seráavaliado com intuito de obter mais detalhes sobre a arquitetura de autorização emuso, tais como mecanismos de autenticação (base local Microsoft Active Directory,OpenLDAP, etc.), autorização (ACL, MAC, RBAC, entre outros), e verificar nocódigo-fonte da aplicação quais restrições de acesso estão sendo aplicadas para

Capítulo 4. Externalização dos mecanismos de autorização 40

proteger um determinado recurso, por exemplo, deve-se verificar o uso de decorators(anotações) como permission_required na implementação das views, entre outros.

Fase 2 (Definir Servidor de Autorização): a interface PAP/PDP e os pontos deextensão para implementação do PIP são fornecidos pelos servidores de autorização.No estudo será utilizado o servidor de autorização open-source WSO2-IS.

Fase 3 (Definir política ABAC baseada nas políticas identificadas): nesta faseas políticas de controle de acesso e as restrições aplicadas diretamente no códigodo SUAP são implementadas em linguagem XACML. Para o desenvolvimento dapolítica XACML é utilizado o plugin ALFA para Eclipse e a interface web Carbondo servidor de autorização WSO2 IS.

Fase 4 (Definir PEP no SUAP): para que as requisições dos usuários aos recursospossa ser interceptada e enviada para decisão no componente externo é necessárioimplantar um PEP na aplicação. No contexto de aplicações Python/Django nãoforam encontradas implementações de PEP. Um protótipo de PEP foi desenvolvido,e será apresentado nas próximas seções.

Fase 5 (Definir PIP): o PIP é responsável por recuperar os valores dos atributos apartir de fontes externas, como uma base LDAP ou um banco de dados, por exemplo.A implementação do PIP é realizada a partir de um ponto de extensão no servidor deautorização. No contexto do nosso estudo, um PIP para recuperar atributos de umabase Postgres e do serviço de diretório Microsoft AD foi implementado utilizando umponto de extensão no servidor de autorização WSO2. Os detalhes da implementaçãoserão descritos nas próximas seções.

Fase 6 (Integração e Testes da nova Infraestrutura de autorização): nessa fasetodos os componentes da infraestrutura são inicializados (aplicação com o PEP,servidor de autorização com o PIP, AD, etc.), em seguida são realizados testes deacesso a recursos protegidos com intuito de verificar se a política de controle deacesso e toda infraestrutura de autorização estão funcionando adequadamente.

Fase 7 (Desativação dos mecanismos anteriores): nesta fase os mecanismos decontrole de acesso legado são desativados no SUAP, por exemplo, são removidas asrestrições aplicadas diretamente no código por meio de anotações em métodos.

Os novos componentes da infraestrutura de autorização devem manter registrosem log de todas as operações com intuito de auxiliar no processo de auditoria (SANDHU;SAMARATI, 1994).

Uma demonstração da aplicação dessas fases no SUAP de forma detalhada seráapresentada após a seção de implementação dos componentes da infraestrutura de autori-zação.

Capítulo 4. Externalização dos mecanismos de autorização 41

4.2 ImplementaçãoEsta seção apresenta uma proposta de visão da arquitetura considerando a inclu-

são dos componentes da infraestrutura de autorização, como também a implementaçãodos componentes que não são disponibilizados pelo servidor de autorização (WSO2 IS)selecionado para este estudo.

4.2.1 Arquitetura

Na fase 1 é proposto avaliar a infraestrutura de autorização de uma aplicaçãoexistente, no nosso caso, o SUAP, e a mesma foi apresentada na figura 7 da seção queapresenta o SUAP no referencial teórico. No contexto do sistema SUAP, observa-se quea autenticação é externalizada, já que a base de usuários é gerenciada em um serviço dediretório Microsoft Active Directory, entretanto, a autorização é realizada pelo frameworkDjango, e as restrições aos recursos são aplicadas diretamente no código da aplicação.

Para suportar a externalização dos mecanismos de controle de acesso no SUAPfoi necessário propor uma nova arquitetura de autorização. A figura 13 apresenta umavisão da arquitetura de externalização, onde sombreado na cor azul destaca-se uma visãoda aplicação SUAP e suas camadas (apresentação, negócio e dados), e para proteger aaplicação/API/etc. é inserido um PEP. Os detalhes de implementação do PEP serão apre-sentados na sub-seção 4.2.2. Os componentes sombreados na cor vermelha e posicionadosa direita são relacionados aos serviços de autorização. O servidor de autorização atuacomo uma interface PDP (decisão baseada nas políticas), e o PAP (acesso ao repositóriode políticas). Opcionalmente um PIP pode ser integrado ao servidor de autorização pararecuperar atributos de outras fontes (LDAP, banco, etc.). O funcionamento do PIP e umexemplo de implementação são apresentados na sub-seção 4.2.3.

Figura 13 – Visão da arquitetura de autorização externalizada para o SUAP

Fonte: Elaborado pelo autor

De uma forma geral, os componentes desta arquitetura funcionam da seguinteforma: um usuário ao tentar acessar um recurso protegido no sistema (o SUAP nesse

Capítulo 4. Externalização dos mecanismos de autorização 42

estudo de caso) terá sua requisição interceptada por um PEP. Este PEP irá recuperaralguns atributos da requisição (URL, usuário logado, verbo HTTP, etc.), em seguida iráencaminhar esses atributos para a interface PDP do servidor de autorização (WSO2 IS).O PDP irá recuperar a partir da interface PAP as políticas de controle de acesso que estãopublicadas, e irá computar a decisão confrontando os valores dos atributos enviados peloPEP com os valores esperados pela política cadastrada no PAP. Nos casos onde a políticarequer atributos que não foram enviados pelo PEP ocorre a chamada a interface PIP. Ainterface PIP irá conter uma lista de atributos suportados, e caso o atributo esperado peloPDP seja suportado pelo PIP o mesmo será acionado.

4.2.2 Implementação do PEP

Inicialmente foram realizadas buscas em repositórios de códigos na internet comintuito de encontrar a implementação de um PEP de exemplo na linguagem Python,mas não foi obtido êxito. Diante do fato, é proposto, implementado, e disponibilizadopublicamente o projeto DjangoPEP1.

O DjangoPEP é implementado sob a camada de middleware2 do Django, a qualpossibilita que todas as requisições HTTP direcionadas ao sistema desenvolvido emDjango sejam interceptadas antes de serem executadas, e a partir dessas requisições sãocoletados alguns atributos como usuário logado (sujeito no contexto do ABAC), URL(recurso), e verbo HTTP (ação) de forma transparente. Na fase seguinte, o DjangoPEP gerauma requisição de autorização XACML (XACML Request)(PARDUCCI; LOCKHART;RISSANEN, 2013), e envia para o PDP através de uma API REST do servidor deautorização para que a decisão de permitir ou não o acesso seja computada. O PDPdevolve a decisão para o DjangoPEP, e se a mesma for Permit a requisição irá prosseguir,se for diferente (deny ou outras), a requisição será negada (HTTP 403 / Forbidden).

A figura 14 apresenta a arquitetura de middleware do Django. Durante o ciclo darequisição as classes de middleware são executadas de forma sequencial iniciando pelotopo (CommonMiddleware na figura). Cada classe middleware tem sua função, como otratamento de User-Agents na classe CommonMiddleware, sessões (SessionMiddleware),proteção contra ataques de Cross Site Request Forgery ou CSRF (CsrfViewMiddleware),autenticação de usuários (AuthenticationMiddleware), suporte a mensagens baseadas emsessões ou cookies (MessageMiddleware), entre outros.

A última caixa (destacada na cor vermelha) é o DjangoPEPMiddleware, a propostade PEP para projetos Django, que coleta os atributos, envia para o servidor de autorização,e de acordo com a decisão do PDP permite ou não a continuidade do acesso. Caso o1 https://github.com/welkson/DjangoPEP2 https://docs.djangoproject.com/en/2.0/topics/http/middleware/

Capítulo 4. Externalização dos mecanismos de autorização 43

acesso seja permitido, o método process_view da camada de middleware libera o acesso aorecurso (pega os dados na view function e devolve para o usuário via process_response).

Figura 14 – Arquitetura do DjangoPEP

Fonte: Elaborado pelo autor baseado em Django (2015)

A ativação do DjangoPEP é realizada no arquivo de configuração settings.py, nogrupo de configuração “MIDDLEWARE”, e deve ser posicionado na última linha conformeexemplo destacado na listagem 4.1.

1 MIDDLEWARE = [

2 'django.middleware.common.CommonMiddleware',

3 'django.contrib.sessions.middleware.SessionMiddleware',

4 'django.middleware.csrf.CsrfViewMiddleware',

5 'django.contrib.auth.middleware.AuthenticationMiddleware',

6 'django.contrib.messages.middleware.MessageMiddleware',

7 'suap.middleware.django_pep.DjangoPEPMiddleware',

8 ]

Listagem 4.1 – Registro do middleware no settings.py

Ainda no settings.py, é necessário definir os parâmetros do DjangoPEP conformedemonstra a listagem 4.2. Na propriedade “DJANGOPEP_PRODUCT” deve ser informadoo servidor de autorização a ser utilizado como PDP/PAP/etc., sendo o valor 1 para o WSO2-IS e 2 para o FIware AuthZForce. No “DJANGOPEP_URL” é informado a URL do servidorde autorização que fornece a interface PDP, e os parâmetros “DJANGOPEP_USER”,“DJANGOPEP_PASSWORD” e “DJANGOPEP_TOKEN” são utilizados para autenticaro DjangoPEP no servidor de autorização, sendo possível utilizar usuário e senhas, ou umtoken OAuth.

Capítulo 4. Externalização dos mecanismos de autorização 44

1 # DjangoPEP Middleware settings

2 DJANGOPEP_PRODUCT = 1 # 1-WSO2 IS, 2-AuthZForce

3 DJANGOPEP_URL = 'https://localhost:9443/api/identity/entitlement/decision/pdp'

4 DJANGOPEP_USER = 'admin'

5 DJANGOPEP_PASSWORD = 'example'

6 DJANGOPEP_TOKEN = ''

7 DJANGOPEP_DEBUG = True

8 DJANGOPEP_IGNORE = ['/$', '/admin/*', '/accounts/*', '/comum/*', '/media/*']

Listagem 4.2 – Configuração do middleware DjangoPEP no settings.py

O parâmetro “DJANGOPEP_DEBUG” por padrão é desativado (definido como“False”), no entanto pode ser habilitado (alterando para “True”) quando o desenvolvedordesejar ativar o modo de depuração, que exibe as respostas fornecidas pela interface PDPdo servidor de autorização (XACML Response).

Por fim, no parâmetro “DJANGOPEP_IGNORE” é possível especificar uma listade URLs a serem ignoradas pelo DjangoPEP durante a interceptação das requisições, porexemplo, a URL /accounts/login/ é utilizada no Django para a tela de login e deve serignorada, pois antes de tratar as requisições de autorização o usuário deve está pelo menoslogado (fase de autenticação).

4.2.3 Implementação do PIP

Comumente as soluções de servidores de autorização fornecem interfaces que podemser implementadas para desenvolver um PIP customizado. No caso do WSO2, é necessáriocriar uma classe que implemente a interface PIPAttributeFinder ou herde a classe abstrataAbstractPIPAttributeFinder 3. O projeto do PIP irá gerar um pacote Jar, que será registradono WSO2 e disponibilizado para instanciação pelo PDP durante a fase de decisão. Duranteo estudo para aplicação da infraestrutura de autorização no sistema SUAP observou-se anecessidade de implementar um PIP que recupere os valores dos atributos de um serviçode diretório LDAP e de um banco de dados Postgres. A figura 15 apresenta um diagramade classes da solução WSO2-SUAP-PIP.

A principal classe do WSO2-SUAP-PIP é a SuapAttributeFinder. Ela possui umalista de atributos suportados pelo PIP (propriedade supportedAttributes), e implementa osmétodos init(), getModuleName(), getAttributeValues() e getSupportedAttributes() que sãodefinidos na interface PIPAttributeFinder. A lista de atributos suportados é definida combase em um arquivo de configurações localizado no diretório do WSO2. Toda interaçãocom esse arquivo é realizada através da classe utilitária ConfigUtil.

A classe utilitária ConfigUtil é responsável por fornecer um ponto único de acessoas configurações do PIP. Com o objetivo de garantir que exista uma única instância dotipo ConfigUtil durante toda a execução do PIP, foi adotado o padrão de projeto Singleton3 https://docs.wso2.com/display/IS550/Writing+a+Custom+Policy+Info+Point

Capítulo 4. Externalização dos mecanismos de autorização 45

Figura 15 – Diagrama de classes do WSO2-PIP-SUAP

Fonte: Elaborado pelo autor

(GAMMA et al., 1995). A classe localiza, lê e carrega as configurações definidas no arquivode propriedades.

A classe Factory é responsável por criar os conectores utilizados pelo PIP. Esta classepossui um método fábrica (padrão de projeto Factory Method) (GAMMA et al., 1995),que instancia objetos do tipo Connector. Para instanciar dinamicamente cada conector,optamos pelo uso de reflexão (API Java Reflection4), e de um arquivo de configurações(wso2-pip-suap.properties), por exemplo, o conector de LDAP pode ser utilizado pararecuperar 3 atributos, e o conector do Postgres utilizado para recuperar 5 atributos, sendoportanto a lista de atributos suportados por cada conector definida no arquivo properties,e a instanciação dinâmica de cada conector é realizada de acordo com o atributo sendorequisitado no momento. Essa decisão objetiva diminuir o acoplamento entre os conectorese as demais classes, bem como simplificar a extensão ou inclusão de novos conectores àimplementação atual. Da mesma forma que a classe ConfigUtil, a classe Factory tambémimplementa o padrão de projeto Singleton.

As fontes de dados utilizadas para recuperação dos atributos no contexto destaaplicação são denominadas conectores. A implementação atual do PIP suporta dois co-4 https://docs.oracle.com/javase/tutorial/reflect/index.html

Capítulo 4. Externalização dos mecanismos de autorização 46

nectores, sendo estes implementados pelas classes PgConnector e LdapConnector. Cadaconector pode suportar um ou mais atributos. Por exemplo, no conector do banco Postgres(PgConnector), atualmente é recuperado o atributo “solicitante” da central de serviços, noentanto outros atributos relacionados a esta mesma fonte de dados podem ser implementa-dos na classe. Para diminuir a quantidade de recursos alocados com as fontes de dados, osconectores implementam o padrão de projeto Singleton, mantendo uma única conexão aorecurso estabelecida.

A classe TipoAtributo e outras não representadas no diagrama, são classes acessóriasresponsáveis por realizar pequenas tarefas secundárias, resultantes de refatorações do códigoao logo do tempo, com o objetivo de melhorar a legibilidade do código, não impactandona função do PIP. Por tal motivo, elas não foram descritas nesta seção.

O código-fonte da aplicação WSO2-SUAP-PIP está disponível publicamente norepositório GitHub 5. A configuração e integração com o WSO2 são apresentadas noarquivo README que acompanha o código da aplicação.

4.3 DemonstraçãoEsta seção apresenta uma demonstração da aplicação das fases de externalização

descritas na seção anterior. Uma instância do SUAP é configurada seguindo o procedi-mento padrão descrito no manual de instalação do sistema, em seguida são realizados osprocedimentos (fases) necessários para externalizar os mecanismos de autorização conformedescrito na seção 4.1.

A fase 1 orienta a “Avaliar mecanismos de autorização no SUAP”. Conformedescrito anteriormente, no SUAP a autorização é baseada no modelo RBAC implementadapor um middleware de controle de acesso do Django, e as restrições de acesso são aplicadasdiretamente no código da aplicação (hard-coded), portanto é pouco flexível no contextode ambientes dinâmicos que necessitam mudar restrições de acesso com maior agilidade.Usando o módulo “Central de Serviços” como modelo, diversas restrições de acesso sãoaplicadas no código da aplicação (hard-coded) na forma de decorator (anotação de método),por exemplo, o decorator “@permission_required([’centralservicos.add_chamado’])” éaplicado ao método abrir_chamado com a finalidade de restringir a criação de novoschamados apenas para usuários com a permissão add_chamado, e neste mesmo método éaplicada uma outra restrição no código para garantir que chamados relacionados a serviçosinativos sejam bloqueados (código Python: if not servico.ativo), além de outras restriçõescomo exibir o chamado apenas para o usuário que solicitou o atendimento em questão.Essas restrições poderiam ser removidas do código e implementados em uma políticaXACML no servidor de autorização externo a aplicação, que possibilita a implementação5 https://github.com/welkson/WSO2-SUAP-PIP

Capítulo 4. Externalização dos mecanismos de autorização 47

de políticas de granularidade fina como esta em questão, além de expor interfaces paraque esta política possa ser ajustada dinamicamente em um contexto de uma infraestruturade autorização auto-adaptativa.

A fase 2 orienta a “Definir Servidor de Autorização’. Conforme descrito no capítulo2, há diversas soluções open-source e comerciais de servidores de autorização. No nossoestudo a solução escolhida é o WSO2 Identity Server, por ser uma ferramenta open-sourcede alta maturidade na indústria. O WSO2 IS irá fornecer a interface PDP (decisão) e PAP(gerenciamento de políticas), além de expor pontos de extensão a serem utilizados paraimplementação do PIP descrito na seção 4.2.3.

Para manter um ambiente similar ao usado no SUAP em produção, o sistemaoperacional escolhido para instalação do servidor de autorização, o SUAP e demaiscomponentes da infraestrutura de autorização é o Debian Linux 9 (Stretch) 6. A versãowso2is-5.4.0-update2 7 do WSO2 é utilizada.

Após o término da inicialização do WSO2 IS, a interface web de gerenciamento(Carbon) poderá ser acessada através de um browser (exemplo: https://10.22.0.122:9443/- onde 192.168.0.122 é o IP da máquina virtual utilizada durante os experimentos parainstalação do WSO2). Via Carbon deve ser realizada a inserção da política XACML geradavia ALFA na fase 3. Para inserir é necessário acessar Entitlement -> PAP -> PolicyAdministration, em seguida clicar em Add New Entitlement Policy, e depois em WritePolicy in XACML. No Policy Editor o código da política XACML (XML gerado peloALFA) deve ser inserido e salvo (Save Policy). Na listagem de políticas é necessário clicarem Publish To My PDP na política que acaba de ser inserida para que a mesma sejadisponibilizada para uso no PDP.

Usando como base as restrições aplicadas no código de algumas operações domódulo Central de Serviços, deu-se início a fase 3, “Definir política ABAC baseada naspolíticas identificadas”. Para facilitar a implementação da política XACML é utilizado umplugin para Eclipse denominado ALFA 8, que é distribuído gratuitamente pela empresaAxiomatics. O ALFA permite implementar políticas XACML de forma simples utilizandouma linguagem de alto nível. A implementação de uma regra na política XACML emALFA para a operação “Visualizar Chamado” da central de serviços do SUAP é descritana listagem 4.3.

1 namespace CentralServicos {

2 policy central_servicos = "central_servicos" {

3 apply denyUnlessPermit

45 rule visualizar_chamado {

6 target clause stringRegexpMatch("^.*/centralservicos/chamado/[0-9]*/$",

7 Attributes.resourceId)

6 https://www.debian.org/index.pt.html7 https://github.com/wso2/product-is/releases/tag/v5.4.0-update28 https://www.axiomatics.com/product/developer-tools-and-apis/

Capítulo 4. Externalização dos mecanismos de autorização 48

8 clause Attributes.actionId == "GET"

9 condition chamado.solicitante == Attributes.subjectId

10 permit

11 }

12 }

Listagem 4.3 – Política XACML em ALFA para a operação Visualizar Chamado

As linhas 1, 2 definem o grupo a qual a política pertence (namespace) e o nome dapolítica (policy central_servicos). Na linha 3 é definido que por padrão todas as requisiçõesdevem ser negadas, exceto as explicitamente definidas nas regras. Na linha 5 define-se onome da regra, e entre 6 e 8 a clausula target define os atributos e os valores esperados. Noatributo de recurso (resourceId) é definido via expressão regular que o valor esperado podecomeçar com qualquer domínio (ex: suap.ifrn.edu.br, suap.xyz.edu.br, entre outros), e orecurso a ser protegido é “/centralservicos/chamado/”, e por fim o número do chamado(somente números entre 0 e 9). Além do atributo de recurso, a regra define que o verboHTTP dessa operação deve ser um “GET” (atributo de ação no contexto do ABAC), eque apenas o dono do chamado deverá ter permissão para visualiza-lo (atributo de sujeitorecuperado via PIP: subjectId). Por fim, na linha 10 é definida a decisão a ser tomada casoos valores do atributos enviados pelo PEP (ou recuperados via PIP) estejam de acordocom o especificado na regra, e neste caso é permit (permitir).

Ao salvar a implementação em ALFA descrita anteriormente, o Eclipse irá gerarautomaticamente o arquivo XML com o código XACML da política no diretório src-gen.Uma das formas de testar a política é instalar no ambiente de desenvolvimento umaversão do WSO2 IS, inserir a política no PAP, e efetuar testes simulando um PEP com afuncionalidade Try It9.

O exemplo citado anteriormente implementa uma regra na política de controlede acesso do módulo central de serviços do SUAP para uma determinada operação(visualizar chamado), entretanto, este módulo contém dezenas de outras operações comsuas respectivas restrições aplicadas diretamente no código (hard-coded) que tambémdevem ser consideradas na implementação da política ABAC/XACML conforme descritona fase 3, no entanto, a implementação dessas demais regras foge do escopo deste trabalho,que tem por objetivo demonstrar o processo de externalização do controle de acesso apartir de alguns exemplos reais.

Com a política ABAC/XACML implementada, o próximo passo é implantar umPEP na aplicação legada para interceptar as requisições e encaminhar para um servidorde autorização externo à aplicação conforme descrito na fase 4. O SUAP é desenvolvidoem Python e Django, e não dispõe de implementação de referência de um PEP, sendonecessário propor e implementar um PEP para continuidade desta proposta. O PEP9 https://docs.wso2.com/display/IS530/Evaluating+a+XACML+Policy

Capítulo 4. Externalização dos mecanismos de autorização 49

DjangoPEP tem sua implementação descrita na seção 4.2.2. A configuração do DjangoPEPno SUAP segue o que está descrito na seção de implementação do PEP.

Conforme descrito anteriormente, o PEP captura atributos da requisição comousuário logado, URL sendo acessada, verbo HTTP, entre outros, no entanto, por ser umcomponente genérico, o PEP não consegue recuperar atributos específicos do módulo queestá sendo protegido. Na política implementada na fase 3 o atributo “chamado.solicitante”é considerado, e este por ser específico do SUAP não pode ser recuperado pelo PEP. Nessescasos é necessário implementar uma extensão ao servidor de autorização denominadaPIP (fase 5)para que o mesmo recupere de fontes externas esse tipo de atributo paraauxiliar na decisão do PDP. Um PIP para este estudo é proposto (WSO2-SUAP-PIP),onde atributos do banco de dados PostgreSQL e de um diretório LDAP (Microsoft AD)são recuperados. Os detalhes da implementação e configuração do PIP são descritos nocapítulo 4, seção 4.2.3, e o código está disponível no GitHub 10.

Com os componentes da externalização devidamente instalados, a próximo etapa é“Testar nova infraestrutura de autorização” conforme descrito na fase 6. Inicialmente oWSO2 deve ser inicializado, e os logs exibidos durante esse processo devem ser atentamenteobservados para detectar possíveis erros durante o registro do PIP, ou erros em outrosmódulos que possam comprometer o funcionamento das demais interfaces necessárias parao funcionamento da infraestrutura de autorização (PDP, PAP, etc.). O fork do SUAP ondefoi instalado o middleware PEP (SUAP-Externalizado) deve ser configurado com mododebug habilitado (DJANGOPEP_DEBUG=True no arquivo settings.py), em seguida oSUAP deve ser iniciado (./manage.py runserver), alguns acessos ao SUAP via browserdevem ser realizados, e os trace logs do PEP via console devem ser observados com intuitode garantir que as requisições estão sendo interceptadas e que os atributos genéricos estãosendo recuperados. Após estes testes iniciais o debug do PEP pode ser desabilitado paranão comprometer o desempenho da infraestrutura de autorização.

Se os testes realizados nos componentes da externalização forem bem sucedidos,a próxima etapa é Desativação dos mecanismos anteriores conforme descreve a fase 7.As restrições de controle de acesso que estavam implementadas diretamente no códigoda aplicação (hard-coded) devem ser removidas, pois nessa fase as mesmas já devem estádevidamente implementadas em XACML e publicadas no servidor de autorização, ouseja, as restrições foram movidas para fora do código da aplicação, permitindo uma maiorflexibilidade e facilidade de manutenção.

Por fim, após a implantação de toda a infraestrutura de autorização externalizada,o próximo passo é manter atualizada as políticas de controle de acesso ABAC considerandomudanças no sistema que possam surgir, como correções de bugs, implementações denovos módulos, entre outros, e também manter atualizados e sob monitoramento os novos10 https://github.com/welkson/WSO2-SUAP-PIP

Capítulo 4. Externalização dos mecanismos de autorização 50

componentes, como o PEP e serviços do servidor de autorização (PDP, PIP).

4.4 DiscussãoEsta capítulo apresentou um estudo sobre a externalização dos mecanismos de

autorização em um sistema real, o SUAP. A documentação oficial do ABAC e outros artigosda literatura descrevem os componentes da infraestrutura de autorização como o PEP,PIP, PDP, mas não propõe um processo ou um detalhamento em fases dos procedimentosa serem realizados para externalizar os mecanismos de autorização. Alguns estudos propõeexemplos utilizando aplicações simples, que não consideram os desafios encontrados naaplicação da abordagem em um sistema real.

Diante do exposto, foi proposto uma lista de fases descrevendo os procedimentosa serem seguidos para externalizar os mecanismos de autorização, além da proposta eimplementação de alguns componentes da infraestrutura de autorização como PEP e PIP.Por fim, foi realizado uma demonstração detalhando a aplicação de cada uma das fases naexternalização no SUAP.

A avaliação da infraestrutura de autorização e demais componentes envolvidos naexternalização do SUAP será realizada no capítulo a seguir.

51

5 Avaliação

Este capítulo apresenta a avaliação da proposta deste trabalho. A avaliação estádividida em 2 etapas, sendo a primeira relacionada ao suporte a auto-adaptação de políticasde controle de acesso em infraestruturas de autorização usando o SecAuthAPI (apresentadono capítulo 3), e a segunda parte é relacionada a externalização dos mecanismos de controlede acesso (apresentado no capítulo 4) em um sistema existente, o SUAP.

5.1 SecAuthAPI: Manipulação dinâmica de políticasNesta seção serão demonstrados os experimentos realizados com o SecAuthAPI com

intuito de mostrar a viabilidade da proposta. Os experimentos foram realizados utilizandoum processo de negócio real relacionado com o módulo Central de Serviços do sistemaSUAP do IFRN.

O exemplo do processo de negócio proposto por Silva et al. (2017) contém umapolítica de controle de acesso com as possíveis adaptações. O exemplo consiste de umprocesso de negócio da Central de Serviços, onde os clientes registram tickets que serãotratados pela equipe de suporte de TI. O processo tem um controle de acesso baseadono modelo RBAC, que define três papéis: Cliente, Suporte e Administrador. O Cliente équalquer usuário que necessite de um serviço de TI e expressa sua necessidade através daabertura de um chamado. O atendente Suporte é um membro da equipe de TI responsávelpor tratar os chamados dos Clientes. Por fim, o Administrador supervisiona o trabalhoda equipe de suporte, interagindo com os chamados quando necessário. Este cenário éapresentado na Figura 16.

Figura 16 – Processo de negócio da Central de Serviços

1. Openticket

14. Cancelticket by user

8. Reopenticket

10. Add moreinformation

3. Allocateto support

2. Openticket onbehalf

4. Allocateto self

5. Checkticket

6. Reallocateticket

9. Suspendticket

7. Solveticket

13. Cancelticket by support

12. Closeexpired ticket

15. Cancelabandonedticket

11. Closeticket

Client

Admin

Support

Fonte: Elaborado por Silva et al. (2017)

A Central de Serviços inclui permissões para abrir um chamado, quer por um

Capítulo 5. Avaliação 52

Cliente (Open Ticket) ou por um atendente se passando por um cliente (Open ticket ofbehalf ), ex., o cliente pode ir pessoalmente ao departamento de TI para reportar umproblema. O chamado aberto pode ser alocado para um atendente de suporte que podetrabalhar sobre a questão, ou cancelar o chamado. Após finalizar o atendimento, o Suportepode marcá-lo como resolvido, e o Cliente então pode fechar ou reabrir o chamado.

Este exemplo considera que os usuários do sistema podem abusar de suas permissões,por exemplo, um Cliente que reabre muitos chamados quando comparado com os demaisclientes, ou um atendente de Suporte que abre chamados em nome dos usuários, aloca ochamado para ele mesmo, e por fim cancela o chamado, aumentando artificialmente seunível de produtividade. Quando um caso de abuso é detectado, a política de controle deacesso é modificada para mitigar o risco. A detecção de um abuso, e a decisão sobre comoresponder a tais abusos está fora do escopo deste trabalho, que fornece a infraestrutura desuporte necessária para a realização do plano de adaptação gerado.

5.1.1 Preparação do ambiente

Para simular acesso dos usuários ao módulo Central de Serviços do SUAP umprotótipo denominado PythonPEP foi desenvolvido. O PythonPEP simula requisiçõesHTTP aos recursos protegidos, e atuando como um PEP captura os atributos, preparao XACML Request, e envia para a interface PDP do servidor de autorização que sejarealizada a decisão de permitir ou não o acesso baseado nas políticas implementadas noservidor de autorização.

O servidor de autorização utilizado nos experimentos para atuar como PAP ePDP é o WSO2 Identify Server. O SecAuthAPI requer acesso administrativo ao serviçoEntitlementPolicyAdminService da interface PAP do WSO2 fornecido por API webservice,no entanto este serviço por padrão é desativado, sendo necessário alterar no arquivorepository/conf/carbon.xml a chave HideAdminServiceWSDLs para false 1.

Uma instância do SecAuthAPI também é integrada ao servidor de autorização parasuportar a manipulação dinâmica de políticas de controle de acesso. No settings.py foramconfigurados os parâmetros que definem qual servidor de autorização está em uso (nesseexemplo o WSO2IS), além das credenciais (usuário e senha ou token de acesso OAuth) e oendereço IP.

A seção a seguir demonstra através de um protótipo a simulação de requisiçõesa um recurso protegido, a computação da decisão de acesso através de um servidor deautorização, e por fim a atuação de um controlador autonômico que manipula uma políticade controle de acesso via SecAuthAPI com intuito de interromper uma atividade maliciosa.1 https://docs.wso2.com/display/IS530B/Entitlement+using+SOAP+Service

Capítulo 5. Avaliação 53

5.1.2 Demonstração

Foi criado um serviço REST com operações para cada tipo de atividade do processode negócio, e em seguida esses serviços foram protegidos usando políticas XACML com oWSO2 Identity Server. Conforme apresenta a Listagem 5.1, a política define quais atributossão esperados na requisição (resourceId="/new_ticket", role="client"or "support", andactionId="POST"). Uma política XACML é implementada utilizando XML, e por setratar de um código detalhado e extenso, foi utilizado neste exemplo uma abstração destapolítica implementada com um plugin do Eclipse denominado ALFA 2. O ALFA permiteescrever políticas XACML usando uma sintaxe simplificada, e converte automaticamenteeste código para XACML.

1 policy new_ticket {

2 apply denyUnlessPermit

3 rule can_new_ticket {

4 target clause ticket.resourceId == "/new_ticket"

5 clause ticket.actionId == "POST"

6 clause user.role == "client" or

7 user.role == "support"

8 permit

9 }

10 }

Listagem 5.1 – Política XACML para permitir criação de novos tickets

Esta política afirma que para abrir um novo ticket (recurso “/new_ticket”) utili-zando o método POST (verbo HTTP) o usuário precisa ter um papel “client” ou “support”.Esta política XACML foi inserida no WSO2IS através da interface PAP. O código destapolítica no formato XML encontra-se no apêndice B, algoritmo B.1.

Os atributos do usuário como userId e role durante os experimentos foram con-siderados como sendo obtidos pelo próprio protótipo, e foram incluídos nas requisiçõesde autorização (XACML Request) a serem enviadas para o PDP, sendo desnecessário autilização de um PIP. Inicialmente foram enviadas alguns XACML Requests para o PDPpara checar se a política estava sendo avaliada corretamente, por exemplo, requisições comrole (papel) “visitor”, “client” e “support”.

Para simular o controlador auto-adaptativo foi considerado que um usuário emparticular efetuou uma operação abusiva, e que a decisão para mitigar o dano é alterar apolítica de controle de acesso para negar novas requisições para este usuário em particular.Então o plano de adaptação cria uma nova política de controle de acesso com um novoatributo para negar acesso para o usuário identificado usando a recurso fornecido pela APIREST em /policy/ via verbo HTTP POST.

O plano é simulado por meio de um script Python em termos de operações definidaspelo SecAuthAPI, que pode ser verificado de acordo com a especificação funcional formal2 https://www.axiomatics.com/product/developer-tools-and-apis/

Capítulo 5. Avaliação 54

antes de ser aplicado para o servidor de autorização.

A Listagem 5.2 apresenta a política de controle de acesso resultante usando ALFA,onde é observa-se um novo atributo para a regra de destino (user.userId == “userxyz”), eo resultado de negar (deny) o acesso. O código completo desta política em XML/XACMLencontra-se no Apêndice B, Listagem B.2. Por padrão o WSO2 utiliza o algoritmo de reso-lução de conflito denominado deny overrides, portanto a regra de negação tem prioridadesobre a regra apresentada anteriormente.

1 policy deny_new_ticket_userxyz {

2 apply denyUnlessPermit

3 rule deny_new_ticket_userxyz {

4 target clause ticket.resourceId == "/new_ticket"

5 clause ticket.actionId == "POST"

6 clause user.userId == "userxyz"

7 deny

8 }

9 }

Listagem 5.2 – Política XACML para bloqueio do usuário userxyz

A figura 17 apresenta a execução do protótipo via linha de comando, as açõesrealizadas na infraestrutura de autorização e os resultados obtidos.

Figura 17 – Intervenção dinâmica em uma política de controle de acesso

Fonte: Elaborado pelo autor

Inicialmente o protótipo exibe uma visão geral da política a ser submetida paraa interface PAP do servidor de autorização. A política se chama new_ticket, e esperaum atributo de ação do tipo POST, o recurso (resource_id) “/new_ticket”, e por fim ospapéis client ou support.

O primeiro passo do protótipo é utilizar o SecAuthAPI para implantar na interfacePAP do servidor de autorização a política XACML descrita acima. No passo seguinte o

Capítulo 5. Avaliação 55

protótipo simula uma requisição ao recurso protegido (/new_ticket passando os parâmetrosesperados pela política, exceto o atributo role, onde é submetido um atributo errado(role=contractor) de forma proposital para avaliar se a política e o PDP estão funcionandoadequadatamente. O PDP avalia a requisição e detecta que o atributo role da requisiçãoestá com um valor não esperado, e nega o acesso conforme especificado na política.

No passo seguinte o mesmo recurso é acessado, mas dessa a requisição é realizadacom o atributo role=support, que é um dos possíveis valores permitidos pela política. Arequisição é avaliada pelo PDP, e o acesso é permitido.

Em seguida, de forma simulada, o controlador autonômico saRBAC (SILVA et al.,2017) detecta um comportamento anômalo do usuário userxyz, e como parte do seu planoadaptação decide criar uma nova política impedindo o acesso deste usuário ao recurso, efaz uma chamada ao SecAuthAPI para que esta política seja implantada na interface PAPdo servidor de autorização.

Por fim, o protótipo simula um acesso ao recurso com os mesmos atributos queforam enviados no passo anterior e que foram permitidos, no entanto o PDP nega o acessobaseado na nova política que acaba de ser inserida e impede o usuário userxyz de acessaro recurso protegido, demonstrando a eficácia da abordagem proposta na manipulação depolíticas de controle de acesso com intuito de mitigar acessos maliciosos.

5.1.3 Avaliação da API

Nesta seção serão descritos os experimentos realizados nas operações fornecidaspelo SecAuthAPI com intuito de avaliar a conformidade da mesma com a especificaçãofuncional. Testes unitários foram implementados para todas as operações da API, e simulamações que validam se as pré/pós-condições das operações estão em conformidade coma especificação funcional ABAC proposta por Gouglidis et al. (2017). A tabela 2 listaas principais operações considerando as pré/pós-condições e os resultados esperados naexecução dos testes.

Tabela 2 – Avaliação das pré/pós-condições da API via testes unitáriosOperação Pré/Pós-Condições Teste realizado Resultado esperado

AddPolicy() Pré: política não deve existirPós: política deve existir

Inserir nova política HTTP 201 (OK)Inserir uma política já existente HTTP 303 (Política já existe)

ModifyPolicy() Pré: política deve existirPós: política modificada

Modificar política HTTP 204 (OK)Modificar política inexistente HTTP 404 (Política inexistente)

AddAttribute() Pré: atributo não deve existirPós: atributo deve existir

Insere um novo atributo (sujeito) HTTP 201 (OK)Inserir um atributo já existente HTTP 303 (Atributo já existe)

ModifyAttribute() Pré: atributo deve existirPós: atributo modificado

Modificar atributo HTTP 204 (OK)Modificar atributo inexistente HTTP 404 (Atributo inexistente)

Os testes foram implementados utilizando a suíte de testes nativa 3 do frameworkDjango. A listagem 5.3 apresenta um trecho do código da implementação dos testes3 https://docs.djangoproject.com/en/1.11/internals/contributing/writing-code/unit-tests/

Capítulo 5. Avaliação 56

unitários que avaliam as pré e pós-condições da operação AddAtribute().

Listagem 5.3 – Trecho de código dos testes unitários da operação AddAttribute()1 # testcase 1 (tenta inserir atributo inexistente)

2 new_attribute_name1 = "http://ifrn.edu.br/ldap/department"

3 new_attribute_value1 = "IT"

4 new_attribute_category1 = "urn:oasis:names:tc:xacml:1.0:subject:subject-id"

5 data = {'category': new_attribute_category1, 'attribute_name': new_attribute_name1, 'attribute_value':

new_attribute_value1}

67 response = self.client.post("/policy/%s/%s/" % (policy_name, rule_name), data, format='json')

8 self.assertEqual(response.status_code, status.HTTP_201_CREATED)

910 # testcase 2 (tenta inserir um atributo existente)

11 new_attribute_name2 = "urn:oasis:names:tc:xacml:1.0:action:action-id"

12 new_attribute_value2 = "POST"

13 new_attribute_category2 = "urn:oasis:names:tc:xacml:3.0:attribute-category:action"

14 data = {'category': new_attribute_category2, 'attribute_name': new_attribute_name2, 'attribute_value':

new_attribute_value2}

1516 response = self.client.post("/policy/%s/%s/" % (policy_name, rule_name), data, format='json')

17 self.assertEqual(response.status_code, status.HTTP_303_SEE_OTHER)

Entre as linhas 1 e 5 são definidos os valores do atributo a ser inserido, e na linha 7é executado uma operação POST no SecAuthAPI passando os novos atributos na operaçãopara inserir o atributo. Na linha 8 é realizado o teste para verificar se o resultado obtidoestá de acordo com o definido na especificação. Nesse caso, o código HTTP 201 é esperadoquando a operação for bem sucedida. A partir da linha 10 um outro atributo é declarado,no entanto esse atributo já existe na política previamente cadastrada.Na linha 16 o POSTé realizado, e na linha 17 o resultado esperado de acordo com a especificação é um HTTP303 quando um atributo sendo inserido já existir na política.

Durante a implementação dos testes unitários foram identificados alguns problemasna operação de adicionar atributo (AddAttribute()), pois a mesma não estava verificandoa existência de um atributo com o mesmo identificador na política, e possibilitava a inclusãode atributos duplicados. Os problemas identificados foram corrigidos antes da execuçãofinal dos testes.

A figura 18 apresenta a saída da execução dos testes unitários. Durante a execuçãoé exibido o nome dos métodos que implementam os testes. Cada método pode conter umou mais testes (positivos e negativos) para cada operação da API, por exemplo, no métodotest_3_add_attribute() que implementa os testes da operação AddPolicy() inicialmenteé inserido um atributo inexistente (caso de teste positivo), e em seguida é inserido umatributo existente (caso de teste negativo).

Por padrão a suíte de testes do Django cria um banco de dados para cada teste(SQLite), e este necessita ser populado com os dados necessários para a continuidadedos testes. Inicialmente o método setup() é executado, e neste é criado um usuário e sãodefinidos os parâmetros para acesso a API (usuário e senha criados no passo anterior). Em

Capítulo 5. Avaliação 57

Figura 18 – Execução dos testes unitários do SecAuthAPI

Fonte: Elaborado pelo autor

seguida a suíte chama na sequência os métodos para adição, modificação e exclusão depolíticas, e por fim os métodos para adição, modificação e exclusão de atributos de umapolítica existente. Nos métodos são implementadas diversas asserções (assert em Python)com objetivo de avaliar se as modificações realizadas nas políticas estão de acordo com oproposto na especificação, e caso uma dessas não esteja de acordo com o valor esperado oteste lista o método e a quantidade de erros encontrados. Conforme mostra a figura, ostestes foram executados em 2.3 segundos e foram concluídos com êxito (status OK).

5.1.4 Discussão

A seção 5.1 apresentou a avaliação do SecAuthAPI, uma abordagem de suporte amanipulação granular de políticas de controle de acesso baseada em especificação funcionalem servidores de autorização.

Com intuito de avaliar a conformidade das operações fornecidas pela API RESTdo SecAuthAPI com a especificação funcional de Gouglidis et al. (2017), foi proposto eimplementado uma bateria de testes unitários onde cada operação é executada e suas prée pós-condições são verificadas.

Conforme declarado anteriormente, no contexto de aplicações auto-adaptativasé fundamental que as operações disponibilizadas para o controlador sejam verificáveisformalmente. Os resultados obtidos durante a execução dos testes demonstram que todas asoperações fornecidas pelo SecAuthAPI estão em conformidade com o formalismo previstona especificação funcional.

Capítulo 5. Avaliação 58

Por fim, os testes unitários implementados poderão servir de base para implemen-tação de mais verificações em novas operações, como também para garantir que mudançasnas operações atuais manterão a conformidade com o previsto na especificação.

5.2 Externalização do controle de acesso no SUAPEsta seção apresenta a preparação do ambiente a ser utilizado na avaliação da

externalização dos mecanismos de autorização propostos no capítulo 4. Inicialmente serãodescritos os procedimentos e estratégias adotadas durante a preparação do ambientede execução dos experimentos, em seguida serão realizados testes para demonstrar ofuncionamento da arquitetura de autorização proposta. Este ambiente será utilizadonos testes de desempenho para avaliar o custo computacional das duas arquiteturas deautorização, a legada e a externalizada, e se o custo adicional que a nova arquitetura trazsão viáveis em comparação com a arquitetura legada.

5.2.1 Preparação do ambiente

Inicialmente foram criadas 2 cópias (forks) do repositório do SUAP, sendo umdesses forks mantido com o código igual ao utilizado em produção no SUAP (branch“master” sem qualquer alteração), e no outro fork é realizado ajustes no código parasuportar a infraestrutura de autorização externalizada. O primeiro fork é denominadoSUAP-Legado e será utilizado para demonstrar a infraestrutura de autorização com aabordagem de aplicar restrições no código (hard-coded), ou seja, a abordagem legada.O segundo fork é denominado SUAP-Externalizado, e tem por objetivo demonstrar autilização da infraestrutura de autorização externalizada (PEP, PDP, PIP, etc.). A figura19 apresenta uma visão das 2 abordagens de autorização.

Figura 19 – Proposta de externalização

Fonte: Elaborado pelo autor

Para instalar os forks do SUAP e os demais componentes necessários foram utilizadosmáquinas virtuais (VM’s) com recursos e configurações similares as utilizadas nos servidoresdo SUAP em produção no IFRN. A figura 20 apresenta as VM’s propostas para esta

Capítulo 5. Avaliação 59

avaliação, que são 1 VM para o SUAP-Legado, outra para SUAP-Externalizado, 1 VMpara o banco de dados (esta VM será compartilhada entre as 2 instâncias do SUAP), 1 VMpara o servidor de autorização, e 1 VM para os testes de carga. Os testes nas instânciasdo SUAP são realizados em momentos distintos, portanto o banco compartilhado não éum impeditivo para esta avaliação.

Figura 20 – Infraestrutura para os experimentos de externalização

Fonte: Elaborado pelo autor

Na tabela 3 é descrito os nomes (hostnames) definidos nas VM’s, os recursosalocados, a função e a versão das aplicações instaladas nas mesmas. As VM’s mpes-suap01e mpes-suap02 tem os mesmos recursos e são utilizadas para instalar o SUAP-Legado eSUAP-Externalizado. Na VM mpes-db está instalado um banco de dados PostgreSQL4

com os mesmos ajustes (tunnings) utilizados em produção, e com uma cópia do banco dedados utilizado pela equipe de desenvolvimento do SUAP no IFRN (dados mascarados).Na VM mpes-authz está instalado o servidor de autorização WSO2 IS 5, com ajustes parapermitir ajustes de políticas via API SOAP pela interface PAP. Por fim, na VM mpes-loadestá instalado o sistema de teste de desempenho JMeter 5. As VM’s estão no mesmosegmento de rede.

Os ambientes apresentados serão utilizados para demonstrar requisições realizadasao módulo Central de Serviços do SUAP utilizando a abordagem legada de autorização(restrições aplicadas no código / hard-coded) denominada “SUAP-Legado”, em seguida asmesmas requisições serão endereçadas a segunda instância do SUAP onde é aplicada ainfraestrutura de autorização externalizada (denominado “SUAP-Externalizado”).

Chamados com dados fictícios foram inseridos na base de dados, sendo os chamadosde 1 a 100 para o usuário “usuario 1”, e de 101 a 200 para o “usuario 2”. A políticaimplementada na seção anterior (listagem 4.3) define que os chamados só podem servisualizados por seus solicitantes, neste sentido os chamados de 1 a 100 só podem servisualizados por “usuario 1”, e 101 a 200 por “usuario 2”.4 http://postgresql.org/5 https://jmeter.apache.org/

Capítulo 5. Avaliação 60

Tabela 3 – Recursos alocados para a infraestrutura de avaliação

Nome da VM Recursos Função

mpes-suap01Disco: 40GBMemória: 32 GBCores: 16 (2.2 GHz)

SUAP (legado)

mpes-suap02Disco: 40GBMemória: 32 GBCores: 16 (2.2 GHz)

SUAP (externalizado)

mpes-dbDisco: 160GBMemória: 32 GBCores: 16 (2.2 GHz)

Banco de Dados(PostgreSQL 9.6)

mpes-authzDisco: 40GBMemória: 12 GBCores: 8 (2.2 GHz)

Servidor de Autorização(WSO2 IS 5.4.0 U2)

mpes-loadDisco: 40GBMemória: 32 GBCores: 32 (2.2 GHz)

Testes de Desempenho(JMeter 4.0 / r1823414)

A figura 21 exibe uma demonstração de uso do SUAP considerando as duasabordagens de autorização na visão de um usuário final. No passo 1 o “usuario 1” acessao chamado 1 usando o “SUAP-Legado”, e por esse chamado ser do próprio usuário oacesso ao mesmo é permitido (regra aplicada no código da aplição / hard-coded). Nopasso 2 o “usuario 1” tenta acessar o chamado 101 que pertence ao “usuario 2”, e oacesso é negado. No passo 3 e 4 o “usuario 1” acessa os mesmos chamados, no entanto o“SUAP-Externalizado” é utilizado, e os mesmos resultados são obtidos, demonstrando quea abordagem de autorização é efetiva no sentido de permitir ou negar acesso aos recursos deacordo com a política implementada no servidor de autorização, como também demonstrarque para o usuário final a mudança na estratégia de autorização é transparente.

Figura 21 – Demonstração das abordagens de autorização legada e externalizada

Fonte: Elaborado pelo autor

Capítulo 5. Avaliação 61

Esta seção apresentou o ambiente onde a avaliação da abordagem de externalizaçãoserá realizada, sendo um ambiente composto de uma instância do SUAP denominadaSUAP-Legado, onde abordagem de autorização aplica restrições de acesso a determinadosrecursos diretamente no código da aplicação (hard-coded), em seguida, uma outra instânciado SUAP denominada SUAP-Externalizado’’ com a proposta de externalização configu-rada, onde as restrições aplicadas no código são removidas, e os mesmos acessos realizadosao “SUAP-Legado” foram testados, obtendo-se o mesmo resultado.

5.3 Avaliação de Desempenho da ExternalizaçãoOs componentes adicionais requeridos em uma infraestrutura de autorização exter-

nalizada (como o PEP, PDP, PIP, entre outros) possibilitam que restrições de acesso queantes ficavam no código da aplicação sejam implementadas em serviços externos a aplicação,além de expor uma interface (PAP) que permite a manipulação dinâmica de políticasde controle de acesso, no entanto, esses componentes trazem um custo computacionalextra para a infraestrutura de autorização que necessita ser medido, comparado com aabordagem anterior (legada - restrições no código), e avaliado no sentido de verificar se aperda de desempenho não inviabiliza a adoção da proposta.

Neste sentido, esta seção descreve os experimentos realizados com uma ferramentade teste de desempenho ao sistema SUAP em um ambiente similar ao utilizado em produção,sendo uma das instâncias do SUAP configuradas com o formato legado de autorização(restrições no código), e outra com a proposta de externalização dos mecanismos deautorização.

A seguir serão apresentados os planos de testes a serem executados nas instânciasdo SUAP, os experimentos realizados, os resultados e ameaças a validade deste estudo.

5.3.1 Plano de Teste

Nesta seção é descrito o plano e a estratégia utilizada para realização dos testesde desempenho nas 2 abordagens de autorização do SUAP, a legada e a externalizada. Oaplicativo Apache JMeter é instalado e configurado na máquina virtual mpes-load, que seencontra no mesmo segmento de rede das outras VM’s utilizadas pelo SUAP (mpes-suap01,mpes-suap02, entre outras).

A estratégia é realizar requisições a chamados do módulo Central de Serviços nas 2instâncias do SUAP com uma quantidade crescente de usuários ao longo de 10 minutos, eno final obter métricas como tempo de resposta, quantidade de requisições, requisições porsegundo, etc. Os testes são executados inicialmente no SUAP-Legado, e são repetidos por10 vezes para remover distorções nos valores, em seguida os mesmos testes são executadosno SUAP-Externalizado e as mesmas métricas são obtidas.

Capítulo 5. Avaliação 62

Para facilitar a implementação do plano de testes o ambiente gráfico do JMeter éutilizado, em seguida o arquivo do plano gerado pelo aplicativo (extensão jmx) é copiadopara o servidor mpes-load para que os testes sejam executados em um ambiente não-gráfico.Outros procedimentos como a desativação dos listners ao executar o teste no servidor decarga foram realizadas seguindo as boas práticas recomendadas pelo JMeter 6, diminuindoas chances do teste ser comprometido com processamentos desnecessários como a geraçãode estatísticas (listeners), ambiente gráfico, latência de rede (teste realizado localmentemas apontando para um servidor remoto no datacenter por exemplo), entre outros. Ostestes realizados pelo plano geram um arquivo no formato csv, que após o término dostestes são processados gerando uma página html (dashboard) com as estatísticas, gráficos,entre outras informações.

Os planos de testes contém os mesmos parâmetros, mudando apenas o alvo ondeserão executados os testes, sendo o primeiro apontado para a a instância do SUAPdenominada “SUAP-Legado” que se encontra na VM mpes-suap01, e o segundo apontandopara o SUAP-Externalizado que se encontra na VM mpes-suap02. A tabela 4 apresentaos parâmetros do plano de testes implementado no JMeter.

Tabela 4 – Plano de testesParâmetro ValorThreads 100Ramp-Up 500Schedule 600CSV Data Set users.csv

A propriedade threads no JMeter está relacionada ao número de usuários simul-tâneos a serem utilizados no teste. O teste inicia com 1 usuário, e baseado no valorespecificado na propriedade Ramp-Up os demais usuários (limite de 100 usuários) sãochamados gradativamente durante o tempo do teste. O tempo total do teste são 10 mi-nutos (600 segundos), sendo que cada usuário deve iniciar seu teste de forma simultâneaa cada 5 segundos (500 ramp-up dividido por 100 threads = um novo usuário a cada 5segundos), ou seja, antes do tempo total do teste (10 minutos) todos os 100 usuários játerão sido iniciados e estarão executando requisições simultaneamente. As credenciais dos100 usuários utilizados nos testes são importados do arquivo users.csv

As requisições são realizadas em chamados aleatórios do módulo central de serviçosem uma base contendo aproximadamente 72 mil registros (dados dos usuários e doschamados foram mascarados), e tem por objetivo atenuar o impacto de cache nos diversoscomponentes envolvidos na infraestrutura (banco de dados, servidor web, servidor deautorização, PIP, entre outros) e que podem comprometer os resultados dos testes. OSecAuthAPI não implementa cache nas suas operações.6 https://jmeter.apache.org/usermanual/best-practices.html

Capítulo 5. Avaliação 63

5.3.2 Experimentos

Esta seção apresenta os resultados dos experimentos realizados com a ferramenta detestes de desempenho JMeter nas 2 instâncias do SUAP. Conforme relatado anteriormente,a infraestrutura de autorização dos mecanismos de autorização tem um custo computacionalenvolvido, e este precisa ser comparado com a abordagem atual (legada) com intuito deavaliar a viabilidade considerando um cenário de um sistema real.

A tabela 5 apresenta os resultados obtidos durante as 10 execuções dos testes dedesempenho realizadas no “SUAP-Legado” baseado no plano de testes especificado naseção anterior. A coluna “Usuários” exibe a evolução dos testes durante diferentes cargasde usuários, iniciando com os resultados obtidos com até 10 usuários, e variando de 10 em10 até o limite de 100 usuários. As colunas seguintes exibem o tempo médio, mediana, e odesvio padrão. Os dados obtidos durante os experimentos são apresentados detalhadamentenas tabelas 12 e 13 no apêndice C.

Tabela 5 – Testes de desempenho no SUAP-Legado e SUAP-Externalizado

Tempo de resposta das requisições em milissegundos (ms)

Os resultados dos testes de desempenho realizados no “SUAP-Legado” mostramque apesar do aumento gradativo na quantidade de usuários no decorrer do teste, o tempode resposta das requisições se mantém linear até o limite máximo de usuários definidospara o experimento (100 usuários).

Os mesmos testes foram realizados no “SUAP-Externalizado”, e percebe-se que ocusto computacional que a infraestrutura de externalização traz ocasiona um aumentono tempo de resposta das requisições, mas sem grandes variações durante o aumentogradativo dos usuários em comparando com a abordagem legada. O aumento do tempo deresposta na proposta de externalização também se mantém linear.

A figura 22 apresenta um gráfico onde é possível visualizar o tempo médio de

Capítulo 5. Avaliação 64

resposta das instâncias do SUAP considerando o aumento do número de usuários nodecorrer do tempo. Considerando a diferença entre a média de tempo das requisições das2 abordagens, percebe-se que a abordagem externalizada tem uma perda de desempenhomédio de 7,01% em comparação com a legada. O impacto da perda de desempenho dainfraestrutura de externalização em comparação com a infraestrutura legada em termosabsolutos é de menos de 0,5 segundos.

Figura 22 – Tempo de resposta x Número de Usuários

Fonte: Elaborado pelo autor

A perda de desempenho da arquitetura de autorização externalizada em comparaçãocom a legada se dá principalmente devido ao custo computacional extra dos componentescomo o PEP, PDP e PIP. Cada requisição realizada na aplicação é interceptada peloPEP, que necessita gerar uma requisição para o PDP para que a decisão seja computada(XACML Request/Response). Quando a requisição chega no PDP para decisão o servidorde autorização recupera as políticas, computa os atributos, e quando requerido solicitaatributos extras ao PIP. O PIP por sua vez conecta em fontes externas como Postgres eLDAP, e devolve os valores para o PDP finalizar a computação da decisão. Todas essasetapas têm custos computacionais extras, como lidar com arquivos XML, latência de redeentre as comunicações do PEP com PDP e PIP com LDAP e Postgres, entre outros.

Considerando que a abordagem de externalização traz diversos benefícios elencadosem seções anteriores, observa-se que essa perda de desempenho torna-se justificável epassível de mitigação, já que novos nós do SUAP podem ser incluídos no cluster debalanceamento de carga com intuito melhorar o tempo de resposta em ambientes em largaescala, e dessa forma melhorar o tempo de resposta das requisições para os usuários finais.

5.3.3 Discussão

Esta seção descreveu os teste de desempenho realizados nas instâncias legada eexternalizadas do SUAP com intuito de obter o tempo médio de resposta das requisições

Capítulo 5. Avaliação 65

das duas abordagens e avaliar se o custo adicional da infraestrutura de autorização é viávelconsiderando o contexto de um sistema real.

Os resultados dos testes de desempenho demonstram que a abordagem externalizadatem uma perda de desempenho média de aproximadamente 7%, no entanto considerarmosque em ambientes reais com centenas de usuários o tempo de resposta da abordagemexternalizada pode ser melhorado usando estratégias de balanceamento de carga, cache,entre outros, portanto conclui-se que é viável a utilização da abordagem em ambientesreais.

De todo modo, embora os testes de desempenho tenham sido realizados baseadosnas boas práticas recomendadas pela literatura e na documentação das ferramentas, osresultados são passíveis a ameaças de validade por alguns fatores que serão elencados aseguir.

Os testes foram realizados com um número máximo de 100 usuários simultâneosbaseados em dados obtidos dos relatórios de uso do SUAP no IFRN, entretanto, essenúmero pode ser bem maior considerando acessos atípicos como votações em enquetes,resultados de provas, entre outros. Na avaliação, observou-se que o tempo de resposta dasrequisições cresceu de forma linear, no entanto não foram realizados testes de stress paraobservar o comportamento do sistema no seu limite máximo.

Um outro fator a considerar é o tempo da execução dos testes. Cada rodadade testes tem um tempo máximo de 10 minutos (600 segundos), e um ramp-up de 500segundos, ou seja, ao chegar em 8 minutos e 20 segundos todos os usuários estarão ativose fazendo requisições ao recurso, e essa carga máxima de 100 usuários continuará sendoexecutada por mais 100 segundos (1 minuto e 40 segundos) até atingir o tempo máximodo teste, no entanto testes mais longos (horas por exemplo) não foram executados, eestes poderiam indicar problemas como implementação que causem consumo excessivo dememória, condição de corrida (race-condition), entre outros.

Por fim, os testes foram realizados apenas no módulo central de serviços, noentanto, testes em outros módulos auxiliariam a identificar gargalos em implementações deconsultas a outras fontes de dados (PIP) que poderiam comprometer o tempo de respostada infraestrutura de autorização.

5.4 Considerações FinaisEste capítulo apresentou a demonstração e avaliação do SecAuthAPI, uma abor-

dagem de suporte a manipulação granular de políticas de controle de acesso baseada ematributos (ABAC) em infraestruturas de autorização auto-adaptativas. O SecAuthAPIexpõe uma interface REST com operações de manipulação de políticas baseadas em

Capítulo 5. Avaliação 66

especificação funcional.

Para demonstrar o funcionamento do SecAuthAPI foi proposto e implementado umprotótipo denominado PythonPEP, que simula requisições a recursos protegidos em umsistema alvo com intuito verificar se a infraestrutura de autorização restringe ou permite oacesso corretamente de acordo com a política ABAC/XACML implementada no servidorde autorização. Durante os testes foi simulado o uso de um controlador auto-adaptativo(saRBAC), que detecta uma atividade maliciosa, e como parte do seu plano de adaptaçãoencaminha para o SecAuthAPI uma chamada para incluir uma nova política para bloqueiodo usuário malicioso identificado. O SecAuthAPI inclui a política, e o PythonPEP simulanovas requisições realizadas pelo usuário malicioso, que são imediatamente bloqueadasdemonstrando a efetividade da solução proposta.

Para avaliar se as operações do SecAuthAPI estão em conformidade com o definidona especificação funcional foi implementado uma bateria de testes unitários onde asoperações da API são executadas e as pré e pós-condições são verificadas. Uma tabeladescrevendo os principais testes foi proposto, e a execução do teste unitário e os resultadosforam apresentados.

O SecAuthAPI manipula política nos servidores de autorização (interface PAP doWSO2 e AuthZForce na versão proposta neste trabalho), e no contexto da aplicação dessaabordagem em um sistema real, é necessário efetuar mudanças arquiteturais no sistemaalvo para implementar a externalização dos mecanismos de autorização. Neste sentido, umestudo foi realizado, e componentes da infraestrutura de autorização foram implementadose configurados em uma instância do sistema SUAP denominada “SUAP-Externalizado”.

Para avaliar a viabilidade da aplicação da abordagem de externalização no sistemaSUAP foram realizados testes de desempenho na instância “SUAP-Externalizado” e nomodelo anterior (“SUAP-Legado”) com intuito de medir o tempo de resposta médio dasrequisições, e comparando com a abordagem legada verificar se o custo computacional dainfraestrutura de autorização externalizada não inviabiliza a adoção da proposta.

Os resultados dos testes demonstraram que a perda de desempenho da infraestruturade externalização é em torno de 7%, e esses valores na nossa visão não inviabilizam aadoção da proposta diante das vantagens que a abordagem externalizada trás (remoçãode restrições do código, manipulação dinâmica de políticas, entre outras), pois esse custopode ser mitigado alocando mais recursos nas VM’s envolvidas (adição de memória, cores,etc. / escalabilidade vertical), ou se for o caso, adicionando novos nós no cluster debalanceamento de carga (escalabilidade horizontal).

67

6 Trabalhos Relacionados

Este capítulo apresenta alguns trabalhos relacionados a controle de acesso, o temaprincipal desta pesquisa. Os trabalhos são categorizados em controle de acesso dinâmico,externalização e ferramentas para controle de acesso em linguagem Python.

6.1 Controle de acesso dinâmicoHá diversos trabalhos relacionados a controle de acesso dinâmico. McGraw (2009)

introduz o modelo RAdAC (Risk-Adaptable Access Control) baseado na ideia que decisõesde controle de acesso devem considerar o trade-off entre risco e potenciais benefícios depermitir o acesso, apoiando a tomada de decisão dinâmica na concessão do acesso. Shaikh,Adi e Logrippo (2012) apresenta um método para decisão de controle de acesso baseadoem risco, em que risco e confiança são calculados com base no histórico comportamentaldo usuário com acesso concedido. Kandala, Sandhu e Bhamidipati (2011) propõe umaabordagem que combina controle de acesso com risco e confiança, usando um modeloabstrato formal para expressar conceitos de sensível ao risco em controle de uso ou UsageControl (UCON).

No entanto, há uma distinção entre as decisões de controle de acesso dinâmicoe modificação dinâmica de políticas de controle de acesso. As abordagens com base nocontrole de acesso dinâmico consideram que o risco relacionado à informação é codificadana política de controle de acesso de antemão, restringindo o processo de tomada de decisãopara permitir ou não uma requisição em particular.

As abordagens com base na modificação dinâmica de políticas de controle de acessofocam na adaptação de políticas de autorização durante o tempo de execução para ampliarou restringir permissões de acesso. Por exemplo, Ariadne (TSIGKANOS et al., 2015) éuma abordagem para lidar com as ameaças de segurança em ambientes cibernéticos físicos(Cyber-Physical Systems) através da modelagem da topologia em termos de seus requisitosde segurança e de dispositivos/pessoas presentes no ambiente. Este modelo é usado para arealização de análise da ameaça e planejamento da resposta em tempo de execução pormeio de alterações nas regras de controle de acesso para mitigar as ameaças identificadas.

O SAAF (Self-Adaptive Authorization Framework) (BAILEY; CHADWICK; LE-MOS, 2011) é capaz de controlar infraestruturas de autorização, tais como, PERMIS(CHADWICK et al., 2008). SAAF monitora as decisões tomadas pelo processo de autori-zação do sistema e adapta a política de autorização em tempo de execução, tornando-amais restritivo para limitar o comportamento do usuário ou flexibilizar para apoiar os

Capítulo 6. Trabalhos Relacionados 68

usuários.

saRBAC (SILVA et al., 2017) é uma abordagem para reconfigurar dinamicamentea política RBAC (Role-Based Access Control) de sistemas de informação executandoprocessos de negócios, para protegê-los contra as ameaças internas (Insider Threats). Suaabordagem explora traços de execução de processos de negócio e checagem de modelosestocásticos para estabelecer intervalos de confiança para mensurar atributos-chave docomportamento do usuário e assim identificar e adaptativamente despromover os usuáriosque abusam de suas permissões de acesso intencionalmente ou acidentalmente. Taisabordagens dependem de controladores auto-adaptativos para modificar dinamicamente aspolíticas de controle de acesso em resposta a ameaças e violações detectadas no ambiente.

Todos os trabalhos citados demandam o desenvolvimento de código ad hoc paracada adaptação distinta e componente alvo, o que representa uma sobrecarga para osdesenvolvedores e um alto acoplamento do controlador auto-adaptativo com o sistemaalvo. Além de exigir o desenvolvimento operações de baixa granularidade pare seremutilizadas na geração de planos de adaptação, essas abordagens não permitem a verificaçãodos planos gerados, uma vez que as operações não são especificadas formalmente. Aabordagem proposta (SecAuthAPI ) trata essas questões, fornecendo meios para abstrairas peculiaridades e detalhes de implementação dos atuadores (effectors), com uma camadade software uniforme que expõe operações formalmente verificáveis.

Alguns trabalhos focam na verificação das políticas de controle de acesso. Fisleret al. (2005) apresenta uma ferramenta denominada Margrave, que usa diagramas dedecisão binária multi terminal para verificar as propriedades especificadas do usuário eexecutar a análise de impacto de mudança. Bailey, Chadwick e Lemos (2011) propõe orbacDSML, uma abordagem auto-adaptável orientada a modelo que fornece garantias deque a adaptação implantada está de acordo com os requisitos do sistema representadopor políticas RBAC usando perfis UML. Uma sintaxe abstrata para anotar os diagramasUML com informações sobre controle de acesso é proposta por Basin, Doser e Lodderstedt(2006). Os autores apresentam conceitos como usuário, papel e permissão, bem como asrelações entre os elementos de um determinado domínio meta-modelo. Por ser basearem formalismos, a abordagem do SecAuthAPI é complementar a estas, pois favorece averificação dos planos de adaptação.

6.2 Externalização de controle de acessoTradicionalmente, os modelos de controle de acesso foram implementados como

componentes da aplicação (hard-coded). Essa abordagem geralmente exige que cadaaplicação implemente sua própria forma de controle de acesso, vinculando as regras decontrole de acesso a release da aplicação. Essa abordagem ad-hoc é suscetível a erros (

Capítulo 6. Trabalhos Relacionados 69

error-prone), inflexível e não escalável. O acoplamento da lógica de negócio com a lógicado controle de acesso torna difícil a verificação e a validação da política de segurançaimplementada pelo processos de garantia de qualidade; além disso, esse tipo de soluçãoinibe o reaproveitamento da lógica de controle de acesso em diferentes aplicações.

Uma solução para este problema é desacoplar as regras de negócio da aplicação dasregras de autorização através da externalização do controle de acesso. A externalização docontrole de acesso pode ser realizada através de diversos paradigmas de controle de acessocomo RBAC e ABAC/XACML (ANSI, 2004)(HU et al., 2014) (PARDUCCI; LOCKHART;RISSANEN, 2013). Apesar da vasta literatura sobre soluções de externalização do controlede acesso, não encontramos o mesmo volume de pesquisas sobre as questões relativas aimplementação desses paradigmas em sistemas reais.

Brossard, Gebel e Berg (2017) propõem uma abordagem sistemática para imple-mentação de controle de acesso baseado em ABAC em empresas. Os atores baseiam aabordagem proposta em modelo de ciclo de vida para as políticas de autorização. Talmodelo contempla as seguintes etapas: (I) Definição dos casos de uso, (II) Obtenção dosrequisitos para autorização, (III) Identificação dos atributos requeridos para autorização,(IV) Definição das políticas de autorização, (V) Testes das políticas, (VI) Implantaçãona arquitetura alvo, (VII) Implantação das políticas, (VIII) Executar revisão de acesso.O principal objetivo do ciclo de vida é simplificar os processos de migração e adoçãodo controle de acesso. Camillo et al. (2017) propõe uma arquitetura que permite queum usuário obtenha serviços sem a necessidade de liberar todos os atributos pessoais. Aarquitetura obtém esse resultado avaliando a política de destino no domínio do provedor deidentidade, ou seja, as políticas são enviadas dos provedores de serviços para os provedoresde identidade a serem avaliados, sem a necessidade de liberar algumas informações pessoaispara o lado do provedor de serviços. A arquitetura foi avaliada através de um estudo decaso representando um cenário hipotético de uma livraria. Os autores demostraram queem determinadas situações, um usuário pode restringir a liberação de dados de pessoais eainda obter acesso a serviços. O foco do trabalho está na autenticação federada, enquantoque o presente trabalho foca na externalização da autorização do usuário.

Os trabalhos supracitados apresentam estudos hipotéticos e relativamente simples.Contrastando com o estudo apresentado no contexto da atual pesquisa que é baseado emum aplicação real legada.

6.3 Ferramentas de controle de acesso em PythonEsta seção apresenta frameworks para desenvolvimento de aplicações web em

Python, e seus respectivos mecanismos de controle de acesso, mais especificamente aautorização. Há uma vasta quantidade de frameworks web em Python, portanto, serão

Capítulo 6. Trabalhos Relacionados 70

abordados apenas os principais frameworks da categoria fullstack, ou seja, aqueles quefornecem componentes que auxiliam no desenvolvimento tanto do frontend (ex.: interfacede interação com o usuário) quanto backend (ex.: regras de negócio, persistência dos dados,segurança).

Os principais frameworks fullstack para a linguagem Python são o Django, Web2pye TurboGears. A seguir será realizada uma breve apresentação desses frameworks, e algumasconsiderações sobre os mecanismos de controle de acesso adotados:

Django: o Django1 foi criado em 2003 com o objetivo inicial de gerenciar um sitejornalístico, e em 2005 teve seu código aberto. Entre as principais vantagens doframework, destaca-se o desenvolvimento rápido, seguro e escalável de aplicações praweb. Quanto aos mecanismos de controle de acesso, o Django fornece uma API de-nominada django.contrib.auth com componentes customizáveis para autenticaçãoe autorização, e componentes prontos para páginas de login, recuperação de senhas,registro de usuários, entre outros. O mecanismo de autorização adotado é similarao modelo RBAC, sendo que em vez de papéis são definidos grupos. Os grupospodem ter permissões associadas, e permitem a inclusão ou remoção de usuários. Asrestrições de acesso a páginas (recursos) são comumente realizadas diretamente nocódigo da aplicação, atribuindo anotações aos métodos (decorators em Python) noarquivo views.py do projeto.

Web2py: o Web2py 2 foi criado em 2007, e tem como objetivo auxiliam no desenvol-vimento de aplicações web dinâmicas em Python que sejam rápidas, escaláveis eseguras. O framework fornece um mecanismo de controle de acesso com suporte adiferentes métodos de autenticação, incluindo SSO (Single Sign-On) em provedorescomo Google, PAM, LDAP, OpenID, OAuth, entre outros. A autorização é baseadano modelo RBAC, e as restrições aplicadas aos recursos são implementadas viaanotações (decorators) no código da aplicação.

TurboGears: a primeira versão do TurboGears3 foi disponibilizada publicamente em2005, e assim como os demais frameworks apresentados, tem por objetivo possi-bilitar o desenvolvimento de aplicações web de maneira rápida. O mecanismo decontrole de acesso com suporte a autenticação e autorização é implementado porum componente denominado repoze.who4. A autenticação pode ser implementadapelos métodos HTTP e LDAP, e a autorização adota um mecanismo similar aoutilizando no Django, onde grupos são criados e tem permissões associadas, e porfim usuários são removidos ou inseridos nestes grupos. Os usuários e grupos podem

1 https://www.djangoproject.com/2 http://www.web2py.com/3 http://www.turbogears.org4 https://turbogears.readthedocs.io/en/latest/turbogears/authentication.html

Capítulo 6. Trabalhos Relacionados 71

ser gerenciados a partir da interface de administração web denominada TurboGearsAdmin. As restrições de acesso aos recursos também são implementadas via anotações(decorators) diretamente no código da aplicação (classes de controle ou Controller), esuportam uso de predicados como All (checa se todos os predicados foram atendidos),Any (checa se pelo menos um predicado foi atendido), in_group (checa se o usuáriopertence a um determinado grupo), entre outros.

Conforme observado, todos os frameworks avaliados implementam as restrições deacesso aos recursos diretamente no código da aplicação (hard-coded) via anotações Python(decorator), e consequentemente restringem a atuação de um controlador auto-adaptativo(saRBAC por exemplo) durante eventos anômalos que necessitem de adaptação dinâmicade políticas para mitigar um abuso.

No caso do Django, o PEP proposto e implementado no capítulo 4 pode atuar deforma complementar aos mecanismos de autorização, possibilitando que as requisições deacesso sejam interceptadas e encaminhadas para um servidor de autorização externo aaplicação, e consequentemente removendo as restrições de acesso fixadas no código, alémde possibilitar o uso do SecAuthAPI, que fornece o suporte a manipulação dinâmica depolíticas de controle de acesso no contexto de um sistema auto-adaptativo.

Por fim, a implementação do PEP pode ser utilizada como referência no desenvol-vimento de PEP’s específicos para os frameworks Web2py e TurboGears.

6.4 DiscussãoEste capítulo apresentou alguns trabalhos relacionados que foram categorizados em

controle de acesso dinâmico, externalização do controle de acesso, e ferramentas de controlede acesso em Python, e por fim os comparou com a abordagem proposta na pesquisa.

Os trabalhos envolvendo controle de acesso dinâmico diferem do proposto noSecAuthAPI no sentido de exigir implementações distintas para cada adaptação no com-ponente alvo, enquanto o SecAuthAPI propõe um conjunto de operações baseadas emespecificação funcional formal através de uma camada de software que abstrai as peculiari-dades do sistema alvo.

Os trabalhos relacionados a externalização apresentam casos hipotéticos, enquantoa proposta apresentada neste trabalho usa um sistema real.

Por fim, os mecanismos de controle de acesso adotados por alguns dos principaisframeworks web em Python foram apresentados, e diferem da abordagem proposta porexigir a implementação das restrições de acesso diretamente no código da aplicação(hard-coded) em vez de externalizar tais restrições.

72

7 Considerações finais

Este capítulo apresenta as considerações finais relacionadas a proposta apresentadanesta dissertação. A seção 7.1 discorre sobre as principais contribuições obtidas, em seguidana seção 7.2 são listadas as limitações, e em 7.3 são indicados alguns trabalhos futuros.

7.1 ContribuiçõesEste trabalho tem como principal objetivo fornecer uma abordagem de suporte a

infraestruturas de autorização auto-adaptativas. Para alcançar esse objetivo foi propostoe implementado uma API REST denominada SecAuthAPI, que fornece operações paramanipulação de políticas baseadas em uma especificação funcional ABAC (GOUGLIDISet al., 2017), e que pode ser integrada a um controlador auto-adaptativo em um cenário deauto-proteção de sistemas, onde o controlador monitora continuamente o ambiente a serprotegido, e ao detectar uma ameaça atua sobre o SecAuthAPI executando operações quemanipulam políticas de controle de acesso de maneira granular com intuito de impedir oumitigar os abusos em tempo de execução. No contexto de sistemas auto-adaptativos, ofornecimento de operações baseadas em especificação funcional formal é essencial, poisfornece meios rigorosos para especificar e compreender o comportamento do sistema emtempo de design e execução (WEYNS et al., 2012).

A adoção do SecAuthAPI no contexto de um sistema real requer que a infraestruturade controle de acesso deste sistema externalize os mecanismos de autorização, ou seja,a aplicação deve remover as restrições de acesso do código e delegar para uma interfaceexterna (servidor de autorização) a decisão de permitir ou não o acesso baseado empolíticas.

Com intuito de demonstrar um caso real de adoção da infraestrutura de autorizaçãoauto-adaptativa, neste trabalho propomos externalizar os mecanismos de autorização dosistema SUAP. Na literatura não encontramos trabalhos demonstrando como esse processode externalização deveria ser realizado, e como uma das contribuição deste trabalhopropomos uma sequência de fases a serem seguidas para implantar a externalização emum sistema legado. Usando essas fases como base, implementamos uma demonstração doprocesso de externalização em um dos módulos do sistema SUAP, a central de serviços.

Como contribuição técnica, durante a implantação da externalização no sistemaSUAP observou-se a necessidade de implementar um PEP para Python/Django pois nãoencontramos soluções prontas em repositórios de código aberto, e também um PIP querecupera atributos de fontes LDAP e Postgres para que estes atributos sejam utilizados

Capítulo 7. Considerações finais 73

durante a etapa de decisão pelo PDP na demonstração da central de serviços do SUAP.

Por fim, realizamos uma avaliação das abordagens de suporte a infraestrutura deautorização propostas neste trabalho. O SecAuthAPI foi avaliado através da implementaçãoe execução de testes unitários que demonstram a conformidade deste com a especificaçãofuncional. A externalização foi avaliada através de testes de desempenho, e por fim osresultados foram comparados com a abordagem legada. A quantidade de componentes desegurança adotados na infraestrutura de autorização trazem um custo computacional amais comparando com a abordagem legada. Nos nossos testes a infraestrutura externalizadatem uma perda média de 7,01% de desempenho nos casos médios, e 17,39% no pior caso.Considerando os benefícios fornecidos pela infraestrutura de externalização, concluímosque esta perda é aceitável e passível de mitigação incluindo mais recursos a infraestrutura,seja no modelo vertical (mais memória, cores, etc.), ou horizontal (novos nós no cluster daaplicação SUAP).

Os resultados deste trabalho foram compilados em um artigo (MEDEIROS; SA-RAIVA; SILVA, 2017), que foi publicado e apresentado ao workshop Gestão de IdentidadesDigitais (WGID) do Simpósio Brasileiro em Segurança da Informação e Sistemas Compu-tacionais (SBSeg)1 nas categorias “Controle de Acesso baseado em atributos (ABAC)” e“Técnicas de prevenção contra fraudes e roubo de identidades”.

7.2 LimitaçõesA abordagem de manipulação de políticas de controle de acesso (SecAuthAPI ) têm

algumas limitações, e estas serão apresentadas a seguir.

O acesso as operações do SecAuthAPI através dos controladores auto-adaptativos érealizado apenas no modo administrativo. Um controlador devidamente autenticado atravésde um usuário e senha tem acesso a todas as operações, e não é possível definir permissões oupapéis para que apenas determinadas operações sejam autorizadas na API para um usuário.Em ambientes complexos com mais de um controlador auto-adaptativo manipulandopolíticas através do SecAuthAPI a autorização a nível de operação é importante, nosentido de limitar as operações que cada controlador pode executar.

Um outro ponto a ser considerado é que o SecAuthAPI foi proposto inicialmentepara suportar apenas o servidor de autorização WSO2 IS. O suporte a AuthZForce encontra-se implementado parcialmente. As operações para inserção e modificação de políticas estãoimplementadas, no entanto o AuthZForce requer alguns procedimentos adicionais paraativar a política para uso no PDP, e estes estão pendentes.

Por fim, uma outra limitação que afeta diretamente o SecAuthAPI é o não suporte1 https://sbseg2017.redes.unb.br/

Capítulo 7. Considerações finais 74

a PolicySet pela biblioteca Python desenvolvida para manipulação de políticas XACML, aXACML_Parser. O PolicySet permite agregar várias políticas em um único arquivo XML,e pode ser útil na manipulação de políticas complexas.

7.3 Trabalhos futurosA seguir serão listados algumas sugestões de estudos e implementações a serem

realizadas com intuito melhorar a abordagem de suporte a manipulação dinâmica depolíticas (SecAuthAPI ) e externalização dos mecanismos de autorização em sistemaslegados.

O SecAuthAPI faz uma verificação estrutural na política XACML através de umesquema XSD fornecido pela OASIS2 com intuito de verificar se a intervenção realizada napolítica não a corrompeu, no entanto, essa abordagem não avalia a completude da política.A política pode estruturalmente está correta, mas semanticamente está permitindo acessoa um recurso que deveria está bloqueado, e essa falha na implementação da política ou naconfiguração pode causar sérias vulnerabilidades (HU; KUHN, 2016). Uma das formas deavaliar a completude de uma política de controle de acesso é usando a ferramenta ACPT3

(Access Control Policy Testing) desenvolvida pelo NIST. O ACPT permite fazer umaverificação sintática e semântica das políticas XACML através de checagem de modelo(model checker) SMV (Symbolic Model Verification)(HU; KUHN; YAGA, 2017). O ACPTé um aplicativo desktop desenvolvido usando a linguagem Java. Uma recomendação detrabalho futuro é analisar o código e implementar meios de executar a checagem de políticasdo ACPT via linha de comando ou API, permitindo assim a integração com o SecAuthAPI.

No contexto de externalização dos mecanismos de autorização, uma recomendaçãode trabalho futuro é propor uma metodologia de externalização. A nossa abordagempropõe algumas fases e foi pensada especificamente para o sistema SUAP, no entanto acomplexidade envolvida na externalização poderia ser investigada mais a fundo, e umametodologia ou um processo poderiam ser propostos considerando artefatos de entrada,saída, maior detalhamento de cada etapa, ser agnóstica de sistema, como também fornecerimplementações de referência de PEP’s em outras linguagens, e PIP’s para servidores deautorização diferentes do WSO2, como o AuthZForce.

Ainda sobre externalização, uma outra proposta de trabalho futuro é desenvolveruma interface que facilite a implementação de políticas ABAC. Neste trabalho foi utilizadoo ALFA, mas este tem uma sintaxe pouco amigável para não-desenvolvedores. O WSO2fornece na interface web algumas ferramentas que através de formulários geram a políticaABAC em linguagem XACML, mas são limitadas e de difícil utilização.

2 https://docs.oasis-open.org/xacml/3.0/XSD/3 https://csrc.nist.gov/Projects/Access-Control-Policy-Tool

75

Referências

ABRIAL, J.; SCHUMAN, S. A.; MEYER, B. Specification Language. In:On the Construction of Programs. [s.n.], 1980. p. 343–410. Disponível em:<http://se.ethz.ch/~meyer/publications/languages/Z_original.pdf>. Citado na página16.

ANSI. Role Based Access Control. [S.l.], 2004. ANSI/INCITS 359-2004. Disponível em:<https://csrc.nist.gov/projects/role-based-access-control>. Citado 5 vezes nas páginas14, 16, 21, 22 e 69.

ANSI. Role Based Access Control - Policy-Enchanced. 2012. ANSI/INCITS 494-2012.Disponível em: <https://standards.incits.org/apps/group_public/project/details.php?project_id=1659>. Citado na página 22.

ANSI. Next Generation Access Control - Functional Architecture (NGAC-FA). 2013.ANSI/INCITS 499-2013. Disponível em: <https://standards.incits.org/apps/group_public/project/details.php?project_id=1649>. Citado na página 24.

BAILEY, C.; CHADWICK, D. W.; LEMOS, R. D. Self-adaptive authorization frameworkfor policy based RBAC/ABAC models. In: IEEE. Dependable, Autonomic and SecureComputing (DASC), 2011 IEEE Ninth International Conference on. IEEE, 2011. p. 37–44.Disponível em: <https://doi.org/10.1109/DASC.2011.31>. Citado 4 vezes nas páginas15, 27, 67 e 68.

BASIN, D.; DOSER, J.; LODDERSTEDT, T. Model Driven Security: fromUML Models to Access Control Infrastructures. ACM Transactions on SoftwareEngineering and Methodology (TOSEM), v. 15, p. 39–91, Jan 2006. Disponível em:<https://dl.acm.org/citation.cfm?id=1125810>. Citado na página 68.

BOOTH, R.; BROOKE, H.; MORRIS, S. WikiLeaks cables: Bradley Manning faces 52years in jail. [S.l.], 2010. Disponível em: <http://www.guardian.co.uk/world/2010/nov/30/wikileaks-cables-bradley-manning>. Acesso em: 10 jan. 2017. Citado na página 14.

BROSSARD, D.; GEBEL, G.; BERG, M. A Systematic Approach to Implementing ABAC.In: Proceedings of the 2Nd ACM Workshop on Attribute-Based Access Control. New York,NY, USA: ACM, 2017. (ABAC ’17), p. 53–59. ISBN 978-1-4503-4910-9. Disponível em:<http://doi.acm.org/10.1145/3041048.3041051>. Citado 3 vezes nas páginas 18, 25 e 69.

BRUN, Y.; SERUGENDO, G. D. M.; GACEK, C.; GIESE, H.; KIENLE, H. M.; LITOIU,M.; MÜLLER, H. A.; PEZZÈ, M.; SHAW, M. Engineering Self-Adaptive Systems throughFeedback Loops. In: Software Engineering for Self-Adaptive Systems. [s.n.], 2009. p. 48–70.Disponível em: <https://doi.org/10.1007/978-3-642-02161-9_3>. Citado na página 26.

CAMILLO, G.; WESTPHALL, C. M.; WERNER, J.; WESTPHALL, C. PreservingPrivacy with Fine-grained Authorization in an Identity Management System. In:The Sixteenth International Conference on Networks. ICN, 2017. Disponível em:<https://www.researchgate.net/publication/315816577_Preserving_Privacy_with_Fine-grained_Authorization_in_an_Identity_Management_System>. Citado napágina 69.

Referências 76

CHADWICK, D.; ZHAO, G.; OTENKO, S.; LABORDE, R.; SU, L.; NGUYEN, T. A.PERMIS: A Modular Authorization Infrastructure. Concurrency Computing : Practiceand Experience, John Wiley and Sons Ltd., Chichester, UK, v. 20, n. 11, p. 1341–1357,2008. ISSN 1532-0626. Disponível em: <http://dx.doi.org/10.1002/cpe.v20:11>. Citadona página 67.

CHENG, B. H.; EDER, K. I.; GOGOLLA, M.; GRUNSKE, L.; LITOIU, M.;MÜLLER, H. A.; PELLICCIONE, P.; PERINI, A.; QURESHI, N. A.; RUMPE, B.;SCHENEIDER, D.; TROLLMANN, F.; VILLEGAS, N. Using Models at Runtimeto Address Assurance for Self-Adaptive Systems. In: [email protected]. Springer,2014, (Lecture Notes in Computer Science, v. 8378). p. 101–136. Disponível em:<https://doi.org/10.1007/978-3-319-08915-7_4>. Citado na página 15.

COLLINS, M.; THEIS, M.; TRZECIAK, R.; STROZER, J.; CLARK, J.; COSTA,D.; CASSIDY, T.; ALBRETHSEN, M.; MOORE, A. Common Sense Guide toMitigating Insider Threats, Fifth Edition. Fifth. Pittsburgh, PA, 2016. Disponível em:<http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=484738>. Citado napágina 14.

DJANGO. Django Documentation (Middleware). 2015. <https://docs.djangoproject.com/en/1.8/topics/http/middleware/>. Acessado em: 17/07/2018. Citado na página 43.

ELLIOTT, A.; KNIGHT, S. Role Explosion: Acknowledging the Problem. In:Software Engineering Research and Practice. [s.n.], 2010. p. 349–355. Disponívelem: <https://www.researchgate.net/publication/221610600_Role_Explosion_Acknowledging_the_Problem>. Citado na página 21.

FERRAIOLO, D. F.; KUHN, D. R.; CHANDRAMOULI, R. Role-Based AccessControl. 2nd. ed. Norwood, MA, USA: Artech House, Inc., 2007. ISBN 1596931132,9781596931138. Disponível em: <https://csrc.nist.gov/publications/detail/book/2007/role-based-access-control>. Citado na página 20.

FIELDING, R. T. REST: Architectural Styles and the Design of Network-based SoftwareArchitectures. Tese (Doctoral dissertation) — University of California, Irvine, 2000.Disponível em: <http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>. Citadona página 32.

FIELDING, R. T.; RESCHKE, J. Hypertext Transfer Protocol (HTTP/1.1): Semanticsand Content. RFC Editor, 2014. RFC 7231. (Request for Comments, 7231). Disponívelem: <https://rfc-editor.org/rfc/rfc7231.txt>. Citado na página 34.

FISLER, K.; KRISHNAMURTHI, S.; MEYEROVICH, L. A.; TSCHANTZ, M. C.Verification and change-impact analysis of access-control policies. In: Proceedings. 27thInternational Conference on Software Engineering, 2005. ICSE 2005. [s.n.], 2005. p.196–205. ISSN 0270-5257. Disponível em: <https://doi.org/10.1109/ICSE.2005.1553562>.Citado na página 68.

GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Design Patterns: Elementsof Reusable Object-oriented Software. Boston, MA, USA: Addison-Wesley LongmanPublishing Co., Inc., 1995. ISBN 0-201-63361-2. Citado 2 vezes nas páginas 36 e 45.

Referências 77

GOUGLIDIS, A.; HU, V. C.; BUSBY, J. S.; HUTCHISON, D. Verification of ResiliencePolicies that Assist Attribute Based Access Control. In: ACM. Proceedings of the 2ndACM Workshop on Attribute-Based Access Control. 2017. p. 43–52. Disponível em:<https://doi.org/10.1145/3041048.3041049>. Citado 9 vezes nas páginas 16, 32, 36, 55,57, 72, 82, 83 e 84.

GREENWALD, G. No place to hide: Edward Snowden, the NSA, and the US surveillancestate. [S.l.]: Macmillan, 2014. ISBN 1250062586. Citado na página 15.

HAREL, O. NGAC vs XACML: What’s really the difference? 2017. Aces-sado em: 07/09/2018. Disponível em: <https://www.plainid.com/2017/05/ngac-vs-xacml-whats-really-the-difference/>. Citado na página 24.

HORN, P. Autonomic computing: IBM‘s Perspective on the State of InformationTechnology. IBM, 2001. Disponível em: <https://www.researchgate.net/publication/200031805_Autonomic_Computing_IBM’s_Perspective_on_the_State_of_Information_Technology>. Citado 2 vezes nas páginas 15 e 25.

HU, C. T.; KUHN, D. R.; YAGA, D. J. Verification and Test Methods for AccessControl Policies/Models. NIST special publication, n. 192, 2017. Disponível em:<https://dx.doi.org/10.6028/NIST.SP.800-192>. Citado na página 74.

HU, V. C.; FERRAIOLO, D.; KUHN, R.; FRIEDMAN, A. R.; LANG, A. J.;COGDELL, M. M.; SCHNITZER, A.; SANDLIN, K.; MILLER, R.; SCARFONE,K. et al. Guide to Attribute Based Access Control (ABAC) Definition andConsiderations. NIST special publication, v. 800, n. 162, 2014. Disponível em:<http://dx.doi.org/10.6028/NIST.SP.800-162>. Citado 7 vezes nas páginas 14, 16, 17,18, 22, 23 e 69.

HU, V. C.; KUHN, D. R. General Methods for Access Control Policy Verification(Application Paper). In: 2016 IEEE 17th International Conference on InformationReuse and Integration (IRI). [s.n.], 2016. p. 315–323. Disponível em: <http://doi.org/10.1109/IRI.2016.49>. Citado na página 74.

IBM. An Architectural Blueprint for Autonomic Computing. [S.l.], 2006. Disponível em:<https://www-03.ibm.com/autonomic/pdfs/AC%20Blueprint%20White%20Paper%20V7.pdf>. Citado na página 15.

ISO/IEC. ISO/IEC 13568: Information technology – Z formal specification notation –Syntax, type system and semantics. [S.l.], 2002. Disponível em: <http://standards.iso.org/ittf/PubliclyAvailableStandards/c021573\_ISO\_IEC\_13568\_2002(E).zip>. Citadona página 16.

IYER, P.; MASOUMZADEH, A. Mining Positive and Negative Attribute-Based AccessControl Policy Rules. In: Proceedings of the 23Nd ACM on Symposium on Access ControlModels and Technologies. New York, NY, USA: ACM, 2018. (SACMAT ’18), p. 161–172.ISBN 978-1-4503-5666-4. Disponível em: <http://doi.acm.org/10.1145/3205977.3205988>.Citado na página 24.

JÚNIOR, E. P. da C.; SILVA, C. E. da; PINHEIRO, M.; SAMPAIO, S. A newapproach to deploy a self-adaptive distributed firewall. Journal of Internet Servicesand Applications, v. 9, n. 1, p. 12, Jun 2018. ISSN 1869-0238. Disponível em:<https://doi.org/10.1186/s13174-018-0083-6>. Citado na página 28.

Referências 78

KANDALA, S.; SANDHU, R.; BHAMIDIPATI, V. An Attribute Based Frameworkfor Risk-Adaptive Access Control Models. In: 2011 Sixth International Conferenceon Availability, Reliability and Security. [s.n.], 2011. p. 236–241. Disponível em:<http://dx.doi.org/10.1109/ARES.2011.41>. Citado na página 67.

KEPHART, J. O.; CHESS, D. M. The vision of autonomic computing. Computer, v. 36,n. 1, p. 41–50, Jan 2003. ISSN 0018-9162. Disponível em: <https://doi.org/10.1109/MC.2003.1160055>. Citado 3 vezes nas páginas 15, 25 e 26.

KESLER, B. The vulnerability of nuclear facilities to cyber attack. Strategic Insights, v. 10,n. 1, p. 15–25, 2011. Disponível em: <https://calhoun.nps.edu/bitstream/handle/10945/25465/The_Vulnerability_of_Nuclear_Facilities_to_Cyber_Attack.pdf?sequence=1>.Citado na página 14.

LEGG, P. A.; BUCKLEY, O.; GOLDSMITH, M.; CREESE, S. Caught in the act of aninsider attack: detection and assessment of insider threat. In: 2015 IEEE InternationalSymposium on Technologies for Homeland Security (THS). [s.n.], 2015. p. 1–6. Disponívelem: <https://doi.org/10.1109/THS.2015.7446229>. Citado na página 14.

MCGRAW, R. W. Risk Adaptable Access Control (RAdAC). McLean and Clifton,VA, United States, 2009. Disponível em: <https://csrc.nist.gov/csrc/media/events/privilege-management-workshop/documents/radac-paper0001.pdf>. Citado na página67.

MEDEIROS, W. R. de; SARAIVA, J. D.; SILVA, C. E. da. Supporting the Self-adaptationof Authorization Infrastructures. SBSeg: VII Workshop de Gestâo de Identidades Digitais,p. 12, 2017. Disponível em: <https://sbseg2017.redes.unb.br/wp-content/uploads/2017/04/20171109_ANAIS_SBSEG_2017_FINAL_E-BOOK.pdf>. Citado 4 vezes naspáginas 17, 18, 28 e 73.

MORISSET, C.; WILLEMSE, T. A. C.; ZANNONE, N. Efficient Extended ABACEvaluation. In: Proceedings of the 23Nd ACM on Symposium on Access Control Modelsand Technologies. New York, NY, USA: ACM, 2018. (SACMAT ’18), p. 149–160. ISBN978-1-4503-5666-4. Disponível em: <http://doi.acm.org/10.1145/3205977.3205980>.Citado na página 24.

PARDUCCI, B.; LOCKHART, H.; RISSANEN, E. Extensible access control markuplanguage (XACML) version 3.0. OASIS Standard, p. 1–154, 2013. Disponível em:<https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml>. Citado 5vezes nas páginas 24, 31, 37, 42 e 69.

PWC. Pesquisa Global de Segurança da Informação. [S.l.], 2016. Disponível em:<http://www.pwc.com.br/pt/publicacoes/servicos/assets/consultoria-negocios/2016/tl-gsiss16-pt.pdf>. Acesso em: 09 jan. 2017. Citado na página 14.

SANDHU, R.; SAMARATI, P. Access Control: Principles and Practice, IEEECommunications 32 (9): 40–48, 1994. IEEE Communications Magazine, v. 32, n. 9, p.40–48, September 1994. Disponível em: <https://doi.org/10.1109/35.312842>. Citado 3vezes nas páginas 20, 21 e 40.

SHAIKH, R. A.; ADI, K.; LOGRIPPO, L. Dynamic Risk-based Decision Methods forAccess Control Systems. Computers Security, Elsevier Advanced Technology Publications,

Referências 79

Oxford, UK, UK, v. 31, n. 4, p. 447–464, jun. 2012. ISSN 0167-4048. Disponível em:<http://dx.doi.org/10.1016/j.cose.2012.02.006>. Citado na página 67.

SILVA, C. E. D.; DINIZ, T.; CACHO, N.; LEMOS, R. d. Self-adaptive authorisation inOpenStack cloud platform. Journal of Internet Services and Applications, v. 9, n. 1, p. 19,Sep 2018. ISSN 1869-0238. Disponível em: <https://doi.org/10.1186/s13174-018-0090-7>.Citado na página 28.

SILVA, C. E. da; SILVA, J. D. S. da; PATERSON, C.; CALINESCU, R. Self-adaptiveRole-based Access Control for Business Processes. In: Proceedings of the 12th InternationalSymposium on Software Engineering for Adaptive and Self-Managing Systems. Piscataway,NJ, USA: IEEE Press, 2017. (SEAMS ’17), p. 193–203. ISBN 978-1-5386-1550-8.Disponível em: <https://doi.org/10.1109/SEAMS.2017.13>. Citado 8 vezes nas páginas15, 16, 18, 27, 28, 51, 55 e 68.

THION, R. Access Control Models. Cyber Warfare and Cyber Terrorism, p. 318–326,2007. Disponível em: <http://dx.doi.org/10.4018/978-1-59140-991-5.ch037>. Citado napágina 21.

TSIGKANOS, C.; PASQUALE, L.; GHEZZI, C.; NUSEIBEH, B. Ariadne: TopologyAware Adaptive Security for Cyber-Physical Systems. In: 2015 IEEE/ACM 37th IEEEInternational Conference on Software Engineering. [s.n.], 2015. v. 2, p. 729–732. ISSN0270-5257. Disponível em: <http://dx.doi.org/10.1109/ICSE.2015.234>. Citado 2 vezesnas páginas 27 e 67.

VOLLBRECHT, J.; CALHOUN, P.; FARRELL, S.; GOMMANS, L. AAA AuthorizationFramework. RFC Editor, 2000. RFC 2904. (Request for Comments, 2904). Disponível em:<https://rfc-editor.org/rfc/rfc2904.txt>. Citado na página 20.

WEYNS, D.; IFTIKHAR, M. U.; IGLESIA, D. G. de la; AHMAD, T. A survey of formalmethods in Self-Adaptive Systems. In: Fifth International C* Conference on ComputerScience & Software Engineering, C3S2E ’12, Montreal, QC, Canada, June 27-29, 2012.[s.n.], 2012. p. 67–79. Disponível em: <http://doi.acm.org/10.1145/2347583.2347592>.Citado 3 vezes nas páginas 16, 72 e 82.

WHITTLE, J.; SAWYER, P.; BENCOMO, N.; CHENG, B. H. C.; BRUEL, J.RELAX: Incorporating Uncertainty into the Specification of Self-Adaptive Systems.In: RE 2009, 17th IEEE International Requirements Engineering Conference, Atlanta,Georgia, USA, August 31 - September 4, 2009. [s.n.], 2009. p. 79–88. Disponível em:<https://doi.org/10.1109/RE.2009.36>. Citado na página 82.

XU, D.; SHRESTHA, R.; SHEN, N. Automated Coverage-Based Testing of XACMLPolicies. In: Proceedings of the 23Nd ACM on Symposium on Access Control Modelsand Technologies. New York, NY, USA: ACM, 2018. (SACMAT ’18), p. 3–14. ISBN978-1-4503-5666-4. Disponível em: <http://doi.acm.org/10.1145/3205977.3205979>.Citado na página 24.

YASEEN, Q. Insider Threat in Banking Systems. Online Banking SecurityMeasures and Data Protection, IGI Global, p. 222, 2017. Disponível em: <http://dx.doi.org/10.4018/978-1-5225-0864-9.ch013>. Citado na página 15.

Referências 80

YUAN, E.; ESFAHANI, N.; MALEK, S. A Systematic Survey of Self-ProtectingSoftware Systems. TAAS, v. 8, n. 4, p. 17:1–17:41, 2014. Disponível em: <https://doi.org/10.1145/2555611>. Citado 2 vezes nas páginas 15 e 27.

YUAN, E.; TONG, J. Attributed Based Access Control (ABAC) for WebServices. In: 2005 IEEE International Conference on Web Services (ICWS 2005),11-15 July 2005, Orlando, FL, USA. [s.n.], 2005. p. 561–569. Disponível em:<https://doi.org/10.1109/ICWS.2005.25>. Citado na página 22.

Apêndices

82

APÊNDICE A – SecAuthAPI: Especificaçãoda API

As operações fornecidas pelo SecAuthAPI são baseadas na especificação funcionalde políticas ABAC proposta por Gouglidis et al. (2017), onde os mesmos utilizam lógicatemporal em notação Z para verificar formalmente a resiliência das políticas, e propõeuma lista de funções administrativas e de sistemas para ABAC. A verificação utilizandométodos formais é importante pois fornece meios rigorosos para especificar e compreender oscomportamentos de um sistema auto-adaptativo em tempo de design e execução (WEYNSet al., 2012), e a lidar com os desafios e incertezas nos quais esses sistemas estão expostos,como mudanças nas condições ambientais, falhas em sensores, ruídos em redes, ameaçasmaliciosas, erro humano, entre outros (WHITTLE et al., 2009).

Para compreensão do modelo formal ABAC proposto, algumas definições necessitamser apresentadas:

• SUB consiste em um sujeito, que pode ser interpretado como sendo um usuário dosistema, ou um processo que envia requisições para a execução de operações emobjetos. SUB é um conjunto de tuplas na forma (NAME, VALUE). Ex: (user, user1).

• OBJ consiste em um recurso do sistema ao qual uma ação será executada por umsujeito. OBJ é um conjunto de tuplas na forma (NAME, VALUE). Ex: (objectid,device01), (objectpath, /user).

• OPS : consiste de uma operação a qual será executada por um sujeito em umdeterminado objeto. OPS é um conjunto de tuplas na forma (NAME, VALUE). Ex.:(action, delete), (action, create).

• ATTRS, ATTRO, ENV : são uma lista de atributos de sujeitos, objetos, e condi-ções ambientais em formato de tuplas (chave, valor). Ex: {(role, Operator), (role,Supervisor), (role, Manager)}.

• SATTR: é uma lista que mapeia um conjunto de sujeitos (SUB) com um conjunto deatributos de sujeitos (ATTRS). Ex.: {((userid, user1), (role, Supervisor)), ((userid,user2), (role, Manager))}.

• OATTR: é uma lista que mapeia um conjunto de objetos (OBJ) com um conjunto deatributos de objetos (ATTRO). Ex.: {((objectid, device01), (status, up)), ((objectid,device02), (status, down))}.

APÊNDICE A. SecAuthAPI: Especificação da API 83

• POLICIES : em ABAC é uma lista de regras que contém atributos de sujeito, objeto,condições ambientais e operações (POLICIES ⊆ SATTR x OATTR x ENV x OPS),e baseado nos valores desses atributos possibilita determinar se uma requisição deveou não ser autorizada. Ex: AddPolicy(({}, (role, Operator)), ((objectid, device01),{}), {}, (action, startjob)).

Essas definições foram utilizadas por Gouglidis et al. (2017) para especificar asoperações administrativas (Administrative Operations) e as funções administrativas derevisão (Administrative Review Functions) para o modelo ABAC. As operações adminis-trativas listadas no artigo são apresentadas a seguir no formato “NomeDaOperação(parâmetros): Descrição”:

• AddSubject (subject? : SUB): Cria um novo sujeito.

• DeleteSubject (subject? : SUB): Exclui um sujeito existente.

• AddObject (object? : OBJ): Cria um novo objeto.

• DeleteObject (object? : OBJ): Exclui um objeto existente.

• AddOperation (operation? : OPS): Cria uma nova operação.

• DeleteOperation (operation? : OPS): Exclui uma operação existente.

• AddAttribute (type? : subject | object, attr? : ATTRS | ATTRO): Cria um novoatributo.

• ModifyAttribute (type? : subject | object, attr? : ATTRS | ATTRO): Modifica ovalor de um atributo existente.

• DeleteAttribute (type? : subject | object, attr? : ATTRS | ATTRO): Exclui umatributo existente.

• AddEnvironment (attr? : ENV ): Cria um novo atributo de categoria condiçãoambiental.

• ModifyEnvironment (attr! : ENV, value? : V ALUE): Modifica o valor de umatributo de condição ambiental.

• DeleteEnvironment (attr? : ENV ): Exclui um atributo de condição ambiental.

• AssignSubject (subject? : SUB, attr? : ATTRS): Atribui um sujeito para umatributo.

• DeassignSubject (subject? : SUB, attr? : ATTRS): Remove a atribuição de umsujeito para um atributo.

APÊNDICE A. SecAuthAPI: Especificação da API 84

• AssignObject (object? : OBJ, attr? : ATTRO): Atribui um objeto para um atri-buto.

• DeassignObject (object? : OBJ, attr? : ATTRO): Remove a atribuição de umobjeto para um atributo.

• AddPolicy (sattr?SATTR, oattr? : OATTR, env? : ENV, ops? : OPS): Adicionauma ação para um sujeito realizar uma operação em um objeto dado o valores dosatributos de sujeito e objeto, e em potencial os valores dos atributos ambientais.

• DeletePolicy (sattr?SATTR, oattr? : OATTR, env? : ENV, ops? : OPS): Excluia ação de um sujeito realizar uma operação em um objeto dado os valores dosatributos de sujeito e objeto, e potencialmente os valores do atributo de ambiente.

As funções administrativas de revisão são:

• AssignedSubjects (attr? : ATTRS, result! : 2SUB): Retorna um conjunto desujeitos atribuídos a um determinado atributo.

• AssignedObjects (attr? : ATTRO, result! : 2OBJ): Retorna um conjunto de objetosatribuídos a um determinado atributo.

• SubjectAttributes (sub? : SUB, result! : 2AT T RS): Retorna um conjunto de atri-butos que estão atribuídos para um determinado sujeito.

• ObjectAttributes (obj? : OBJ, result! : 2AT T RO): Retorna um conjunto de atribu-tos que estão atribuídos para um determinado objeto.

• SubjectAllAttributes (sub? : SUB, result! : 2AT T RS): Retorna um conjunto detodos os atributos que podem ser elegíveis para um sujeito, incluíndo atributosherdados de uma potencial hierarquia implementada usando a funcionalidade demeta-atributo.

• ObjectAllAttributes (obj? : OBJ, result! : 2AT T RO): Retorna um conjunto detodos os atributos que podem ser elegíveis para um objeto, incluíndo atributosherdados de uma potencial hierarquia implementada usando a funcionalidade demeta-atributo.

Baseado nas definições e operações administrativas propostas por Gouglidis et al.(2017), este trabalho propõe o SecAuthAPI, que implementa as operações administrativasno formato de API REST para suportar a manipulação dinâmica de políticas de controlede acesso ABAC em servidores de autorização. A Tabela 6 apresenta a especificação daoperação AddPolicy(), onde são destacados os formalismos utilizados na implementação

APÊNDICE A. SecAuthAPI: Especificação da API 85

das pré e pós-condições, e os possíveis parâmetros de entrada como o nome da política eseu código-fonte em linguagem XACML, e por fim os possíveis códigos de retorno.

Tabela 6 – SecAuthAPI: AddPolicy()

Operação AddPolicy()Descrição Insere uma nova política XACML no PAPParâmetros: (sattr? : SATTR, oattr? : OATTR, env? : ENV, ops? : OPS)Pré-Condição: {(sattr, oattr, env, ops) /∈ POLICIES}Pós-Condição: {(sattr, oattr, env, ops) ∈ POLICIES}API RESTEndpoint: /policyVerbo HTTP: POST

Parâmetros (cabeçalho):name ->nome da políticadescription ->descrição da políticacontent ->conteúdo da política em linguagem XACML

Retornos:HTTP 201 (OK - Política inserida com êxito)HTTP 303 (recurso já existe)HTTP 500 (erro interno no servidor)

A Tabela 7 apresenta a operação DeletePolicy(), que é utilizada para exclusão dapolítica de controle de acesso na interface PAP dos servidores de autorização.

Tabela 7 – SecAuthAPI: DeletePolicy()

Operação DeletePolicy()Descrição Exclui uma política XACML do PAPParâmetros: (sattr?: SATTR, oattr?: OATTR, env?: ENV, ops?: OPS)Pré-Condição: {(sattr, oattr, env, ops) ∈ POLICIES}Pós-Condição: {(sattr, oattr, env, ops) /∈ POLICIES}API RESTEndpoint: /policy/policy_nameVerbo HTTP: DELETEParâmetros (cabeçalho): -

Retornos:HTTP 204 (OK - Política excluída com êxito)HTTP 404 (política inexistente)HTTP 500 (erro interno no servidor)

Os autores da especificação propõe diversas operações para manipulação a nívelde atributo, no entanto não propõe uma operação para modificar parâmetros na políticaque não sejam atributos de uma determinada regra, por exemplo, não é possível alteraro parâmetro RuleCombiningAlgId que se localiza no cabeçalho da política e define acombinação de algoritmos a ser utilizado na avaliação da política. Diante de tal fato,no SecAuthAPI é proposto a operação ModifyPolicy(), que possibilita que uma política

APÊNDICE A. SecAuthAPI: Especificação da API 86

existente seja atualizada no PAP a partir de um novo código XACML passado comoparâmetro. A especificação da operação ModifyAttribute() é apresentada na Tabela 8.

Tabela 8 – SecAuthAPI: ModifyPolicy()

Operação ModifyPolicy()Descrição Modifica uma política XACML no PAPParâmetros: (sattr? : SATTR, oattr? : OATTR, env? : ENV, ops? : OPS)

Pré-Condição: {(sattr, oattr, env, ops) ∈ POLICIES},{(sattr′, oattr′, env′, ops′) /∈ POLICIES}

Pós-Condição: {(sattr, oattr, env, ops) /∈ POLICIES},{(sattr′, oattr′, env′, ops′) ∈ POLICIES}

API RESTEndpoint: /policy/policy_nameVerbo HTTP: PUT

Parâmetros (cabeçalho):name ->nome da políticadescription - >descrição da políticacontent - >conteúdo da política em linguagem XACML

Retornos:HTTP 204 (OK - Política alterada com êxito)HTTP 404 (política inexistente)HTTP 500 (erro interno no servidor)

Apesar da operação ModifyPolicy() permitir a alteração de qualquer trecho docódigo da política, a mesma exige como parâmetro o código de toda a política em linguagemXACML. Para operações mais granulares como a manipulação a nível de atributo aespecificação propõe algumas operações como AddAttribute e AddEnvironment() paraadição de atributo de sujeito e objeto e para adição de atributo de ambiente respectivamente.No contexto do SecAuthAPI essas duas operações foram unificadas, e a categoria doatributo (sujeito, operação, objeto e ambiente) serão definidas via parâmetro category. Aespecificação desta operação é apresentada na Tabela 9.

APÊNDICE A. SecAuthAPI: Especificação da API 87

Tabela 9 – SecAuthAPI: AddAttribute()

Operação AddAttribute()Descrição Insere um atributo em uma regra da políticaParâmetros: (type? : subject|object, attr? : ATTRs|ATTRo)Pré-Condição: {(name, value) /∈ ATTRS|ATTRO}Pós-Condição: {(name, value) ∈ ATTRS|ATTRO}API RESTEndpoint: /policy/policy_name/rule_nameVerbo HTTP: POST

Parâmetros (cabeçalho):category ->categoria do atributo (tipo: sujeito, ação, recurso)attribute_name ->nome do atributoattribute_value ->novo valor para o atributo

Retornos:HTTP 201 (OK - Atributo inserido com êxito)HTTP 303 (recurso já existe)HTTP 500 (erro interno no servidor)

Uma outra operação granular que foi proposto na especificação é a DeleteAttribute()e DeleteEnvironment(), que tem por objetivo a exclusão de um atributo de sujeito e objetode uma política, e a exclusão de um atributo de ambiente respectivamente. Essas operaçõestambém foram unificadas no SecAuthAPI em uma operação que exclui qualquer categoriade atributo. A especificação desta operação é apresentada na Tabela 10.

Tabela 10 – SecAuthAPI: DeleteAttribute()

Operação DeleteAttribute()Descrição Exclui um atributo que está contido em uma regra da políticaParâmetros: (type? : subject|object, attr? : ATTRS|ATTRO)Pré-Condição: {(name, value) ∈ ATTRS|ATTRO}Pós-Condição: {(name, value) /∈ ATTRS|ATTRO}API RESTEndpoint: /policy/policy_name/rule_nameVerbo HTTP: DELETEParâmetros (cabeçalho): attribute_name ->nome do atributo

Retornos:HTTP 204 (OK - Atributo excluído com êxito)HTTP 404 (atributo inexistente)HTTP 500 (erro interno no servidor)

Para modificação de valores a nível de atributo a especificação também propõe duasoperações, ModifyAttribute() e ModifyEnvironment(), que modificam valores em atributosde sujeito/objeto e ambiente respectivamente, e também foram unificadas no SecAuthAPIconforme apresentado na Tabela 11.

APÊNDICE A. SecAuthAPI: Especificação da API 88

Tabela 11 – SecAuthAPI: ModifyAttribute()

Operação ModifyAttribute()Descrição Altera um atributo que está contido em uma regra da políticaParâmetros: (type? : subject|object, attr? : ATTRS|ATTRO)Pré-Condição: {(name, value) ∈ ATTRS|ATTRO}Pós-Condição: {(name, value′) ∈ ATTRS|ATTRO}API RESTEndpoint: /policy/policy_name/rule_nameVerbo HTTP: PUT

Parâmetros (cabeçalho):category ->categoria do atributo (tipo: sujeito, ação, recurso)attribute_name ->nome do atributoattribute_value ->novo valor para o atributo

Retornos:HTTP 204 (OK - Atributo alterado com êxito)HTTP 404 (atributo inexistente)HTTP 500 (erro interno no servidor)

89

APÊNDICE B – Políticas XACML

B.0.1 Política “New Ticket”1 <?xml version="1.0" encoding="UTF-8"?>

2 <!--This file was generated by the ALFA Plugin for Eclipse from Axiomatics AB (http://www.axiomatics.com).

3 Any modification to this file will be lost upon recompilation of the source ALFA file-->

4 <xacml3:Policy xmlns:xacml3="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"

5 PolicyId="http://axiomatics.com/alfa/identifier/TicketProcess.open_ticket"

6 RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-unless-permit"

7 Version="1.0">

8 <xacml3:Description />

9 <xacml3:PolicyDefaults>

10 <xacml3:XPathVersion>http://www.w3.org/TR/1999/REC-xpath-19991116</xacml3:XPathVersion>

11 </xacml3:PolicyDefaults>

12 <xacml3:Target />

13 <xacml3:Rule

14 Effect="Permit"

15 RuleId="http://axiomatics.com/alfa/identifier/TicketProcess.open_ticket.can_open_ticket">

16 <xacml3:Description />

17 <xacml3:Target>

18 <xacml3:AnyOf>

19 <xacml3:AllOf>

20 <xacml3:Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

21 <xacml3:AttributeValue

22 DataType="http://www.w3.org/2001/XMLSchema#string">/new_ticket</xacml3:AttributeValue>

23 <xacml3:AttributeDesignator

24 AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"

25 DataType="http://www.w3.org/2001/XMLSchema#string"

26 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

27 MustBePresent="false"

28 />

29 </xacml3:Match>

30 </xacml3:AllOf>

31 </xacml3:AnyOf>

32 <xacml3:AnyOf>

33 <xacml3:AllOf>

34 <xacml3:Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

35 <xacml3:AttributeValue

36 DataType="http://www.w3.org/2001/XMLSchema#string">POST</xacml3:AttributeValue>

37 <xacml3:AttributeDesignator

38 AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"

39 DataType="http://www.w3.org/2001/XMLSchema#string"

40 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"

41 MustBePresent="false"

42 />

43 </xacml3:Match>

44 </xacml3:AllOf>

45 </xacml3:AnyOf>

46 <xacml3:AnyOf>

47 <xacml3:AllOf>

48 <xacml3:Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

49 <xacml3:AttributeValue

50 DataType="http://www.w3.org/2001/XMLSchema#string">client</xacml3:AttributeValue>

51 <xacml3:AttributeDesignator

APÊNDICE B. Políticas XACML 90

52 AttributeId="role"

53 DataType="http://www.w3.org/2001/XMLSchema#string"

54 Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"

55 MustBePresent="false"

56 />

57 </xacml3:Match>

58 </xacml3:AllOf>

59 <xacml3:AllOf>

60 <xacml3:Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

61 <xacml3:AttributeValue

62 DataType="http://www.w3.org/2001/XMLSchema#string">support</xacml3:AttributeValue>

63 <xacml3:AttributeDesignator

64 AttributeId="role"

65 DataType="http://www.w3.org/2001/XMLSchema#string"

66 Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"

67 MustBePresent="false"

68 />

69 </xacml3:Match>

70 </xacml3:AllOf>

71 </xacml3:AnyOf>

72 </xacml3:Target>

73 </xacml3:Rule>

74 </xacml3:Policy>

Listagem B.1 – XACML Policy: new_ticket

B.0.2 Política “Deny New Ticket by User”1 <?xml version="1.0" encoding="UTF-8"?>

2 <!--This file was generated by the ALFA Plugin for Eclipse from Axiomatics AB (http://www.axiomatics.com).

3 Any modification to this file will be lost upon recompilation of the source ALFA file-->

4 <xacml3:Policy xmlns:xacml3="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"

5 PolicyId="http://axiomatics.com/alfa/identifier/TicketProcess.deny_new_ticket_userxyz"

6 RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-unless-permit"

7 Version="1.0">

8 <xacml3:Description />

9 <xacml3:PolicyDefaults>

10 <xacml3:XPathVersion>http://www.w3.org/TR/1999/REC-xpath-19991116</xacml3:XPathVersion>

11 </xacml3:PolicyDefaults>

12 <xacml3:Target />

13 <xacml3:Rule

14 Effect="Deny"

15 RuleId="http://axiomatics.com/alfa/identifier/TicketProcess.deny_new_ticket_userxyz.deny_new_ticket_userxyz">

16 <xacml3:Description />

17 <xacml3:Target>

18 <xacml3:AnyOf>

19 <xacml3:AllOf>

20 <xacml3:Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

21 <xacml3:AttributeValue

22 DataType="http://www.w3.org/2001/XMLSchema#string">/new_ticket</xacml3:AttributeValue>

23 <xacml3:AttributeDesignator

24 AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"

25 DataType="http://www.w3.org/2001/XMLSchema#string"

26 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

27 MustBePresent="false"

28 />

29 </xacml3:Match>

30 </xacml3:AllOf>

31 </xacml3:AnyOf>

APÊNDICE B. Políticas XACML 91

32 <xacml3:AnyOf>

33 <xacml3:AllOf>

34 <xacml3:Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

35 <xacml3:AttributeValue

36 DataType="http://www.w3.org/2001/XMLSchema#string">POST</xacml3:AttributeValue>

37 <xacml3:AttributeDesignator

38 AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"

39 DataType="http://www.w3.org/2001/XMLSchema#string"

40 Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"

41 MustBePresent="false"

42 />

43 </xacml3:Match>

44 </xacml3:AllOf>

45 </xacml3:AnyOf>

46 <xacml3:AnyOf>

47 <xacml3:AllOf>

48 <xacml3:Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

49 <xacml3:AttributeValue

50 DataType="http://www.w3.org/2001/XMLSchema#string">userxyz</xacml3:AttributeValue>

51 <xacml3:AttributeDesignator

52 AttributeId="userId"

53 DataType="http://www.w3.org/2001/XMLSchema#string"

54 Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"

55 MustBePresent="false"

56 />

57 </xacml3:Match>

58 </xacml3:AllOf>

59 </xacml3:AnyOf>

60 </xacml3:Target>

61 </xacml3:Rule>

62 </xacml3:Policy>

Listagem B.2 – XACML Policy: deny_new_ticket

92

APÊNDICE C – Resultados dos testes dedesempenho

Este apêndice apresenta os resultados detalhados dos testes de desempenho realiza-dos no SUAP-Legado (abordagem onde as restrições de acesso são aplicadas diretamente nocódigo da aplicação) e no SUAP-Externalizado (proposta de infraestrutura de autorizaçãodescrita no capítulo 4) usando a ferramenta JMeter.

Um resumo dos resultados desta tabela, a avaliação e discussão estão apresentadosno capítulo 5, a partir da seção 5.2.1.

Tabela 12 – Testes de desempenho no SUAP-Legado

Tabela 13 – Testes de desempenho no SUAP-Externalizado