Sabiá: arquitetura integrada de autenticação e autorização de dados orientada ao consentimento do usuário para ecossistemas de aprendizagem em saúde no Brasil

(1)

UNIVERSIDADEFEDERALDO RIO GRANDE DO NORTE

UNIVERSIDADEFEDERAL DORIOGRANDE DO NORTE

CENTRO DETECNOLOGIA

PROGRAMA DEPÓS-GRADUAÇÃO EMENGENHARIAELÉTRICA E

DECOMPUTAÇÃO

Sabiá: Arquitetura Integrada de Autenticação e

Autorização de Dados Orientada ao

Consentimento do Usuário para Ecossistemas

de Aprendizagem em Saúde no Brasil

Túlio de Paiva Marques Carvalho

Orientador: Prof. Dr. Ricardo Alexsandro de Medeiros Valentim

Tese de Doutorado apresentada ao Pro-grama de Pós-graduação em Engenharia Elé-trica e de Computação da UFRN (área de concentração: Engenharia de Computação) como parte dos requisitos para obtenção do título de Doutor em Ciências.

Número de ordem PPgEEC: D273

Natal, RN, julho de 2020

(2)

Carvalho, Túlio de Paiva Marques.

Sabiá: Arquitetura Integrada de Autenticação e Autorização de Dados Orientada ao Consentimento do Usuário para Ecossistemas de Aprendizagem em Saúde no Brasil / Tulio de Paiva Marques

Carvalho. - 2020. 69 f.: il.

Tese (doutorado) - Universidade Federal do Rio Grande do Norte, Centro de Tecnologia, Programa de Pós-Graduação em Engenharia Elétrica e de Computação, Natal, RN, 2020. Orientador: Prof. Dr. Ricardo Alexsandro de Medeiros Valentim.

1. Autenticação - Tese. 2. Autorização - Tese. 3.

Consentimento do usuário - Tese. 4. Sistemas de informação de saúde - Tese. 5. Interoperabilidade - Tese. I. Valentim, Ricardo Alexsandro de Medeiros. II. Título.

RN/UF/BCZM CDU 004.75

Universidade Federal do Rio Grande do Norte - UFRN Sistema de Bibliotecas - SISBI

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

(3)

Dedico este trabalho aos meus pais

João Marques e Umbelina, à minha

esposa Luhane, ao meu pequeno

filho Pedro e aos meus irmãos Artur

e Jihane.

(4)

Agradecimentos

Muitas pessoas foram importantes durante o processo de construção deste trabalho, as quais citarei abaixo (correndo o risco de esquecer vários nomes).

Agradeço à minha família: João Marques, Umbelina, Luhane, Pedro, Artur e Jihane.

Agradeço aos amigos: Ricardo Valentim, Jailton Carlos, Allyson Barros, Giovani Ângelo, Felipe Morais, Carlos Breno, Alex Fabiano e Welkson Renny.

Agradeço aos colegas, os quais se dedicaram ao Sabiá e contribuíram diretamente para o resultado desta Tese de Doutorado: Karilany Coutinho, Carlos Alberto Oliveira e Aquiles Burlamaqui.

Agradeço à banca de defesa pelas valiosas contribuições: Cynthia Magallanes, Cristine Gusmão e Antônio Luiz.

(5)

Resumo

Os Sistemas de Informação em Saúde no Brasil foram projetados e desenvolvidos de maneira heterogênea, além de tomar como base características locorregionais, resul-tando numa falta de integridade das informações. Nesse contexto, o Ministério da Saúde apontou a necessidade de soluções de interoperabilidade dos Sistemas de Informação em Saúde, destacando a importância da integração com os bancos de dados nacionais e do alinhamento às leis brasileiras de proteção de dados, bem como a relevância da sua apli-cação no contexto da Eduapli-cação, para auxiliar na formação continuada dos profissionais da área. Assim, este trabalho apresenta o Sabiá, uma plataforma para autenticação, au-torização e entrega de dados, alicerçada no consentimento do usuário, para Sistemas de Informação em Saúde no Brasil e que atualmente está presente no contexto dos ecossis-temas educacionais desse campo. A arquitetura do Sabiá foi desenvolvida para atingir os seguintes requisitos: R1) fornecer uma identidade federada; R2) ser um gerenciador de recursos federados; R3) coletar dados do usuário de diferentes Sistemas de Informação e; R4) entregar dados dos usuários a sistemas com base no consentimento deles. O Sabiá consiste em três componentes principais: 1) Sabiá Authorization Server, responsável pela implementação da autenticação aberta; 2) Sabiá Coletor, responsável por coletar dados de diferentes Sistemas de Informação e; 3) Sabiá Resource Server, responsável por forne-cer os dados previamente autorizados pelos usuários aos sistemas. Testes de desempenho foram executados de maneira a submeter o Sabiá ao cenário com a carga mais pesada – respaldada pelos dados históricos. A funcionalidade R4 foi selecionada para ser subme-tida aos testes de desempenho, porque é o processo que mais afeta o funcionamento geral do sistema. Os resultados dos testes não mostraram falhas e indicaram escalabilidade, consistência e performance do sistema, em que as médias de tempo de resposta perma-neceram abaixo de 100 milissegundos, situação em que o usuário percebe uma reação instantânea do sistema.

Palavras-chave: Autenticação; Autorização; Consentimento do usuário; Sistemas de Informação de Saúde; Interoperabilidade.

(6)

Abstract

Health information systems in Brazil have been designed and developed in a hetero-geneous manner, besides taking as a base local regional characteristic, resulting in a lack of information integrity. In this context, the Brazilian Ministry of Health pointed out the need for interoperability solutions of Health Information Systems, noting the importance of integration with national databases and alignment with Brazilian data protection laws as well its application in education to aid with continuing Education for healthcare profes-sionals. Therefore, this work presents Sabiá, a platform for authentication, authorization and data delivery, based on user consent for Health Information Systems in Brazil and currently applied in the context of educational ecosystems in this area. Sabiá’s architec-ture is designed to achieve the following requirements: R1) provide a Federated Identity; R2) be a federated resource manager; R3) collect user data from different Information Systems and; R4) deliver user data to systems based on user consent. Sabiá consists of th-ree main components: 1) Sabiá Authorization Server, responsible for implementing Open Authentication; 2) Sabiá Coletor, responsible for collecting data from different Informa-tion Systems and; 3) Sabiá Resource Server, responsible for delivering data previously authorized by the users to the systems. After analyzing historical data, R4 functionality was selected to be submitted to performance tests because it is the process that most af-fects overall system performance. The tests aimed at analyzing Sabiá’s behavior in the heaviest scenario – based on historical data. The results showed no flaws and indica-ted system stability, consistency and performance, in which the user perceives a system reaction instantaneous, whose response time averages remained below 100 milliseconds.

Keywords: Authentication; Authorization; User consent; Health information sys-tems; Interoperability.

(7)

Sumário

Sumário i

Lista de Figuras iii

Lista de Tabelas iv

Lista de Algoritmos v

Lista de Símbolos e Abreviaturas vi

1 Introdução 1

1.1 Objetivos . . . 3

1.2 Objetivos específicos . . . 3

1.3 Estrutura da Tese . . . 3

1.4 Publicações relacionadas . . . 4

1.4.1 Artigos publicados em periódicos . . . 4

1.4.2 Registros de software . . . 4

2 Fundamentação Teórica 6 2.1 Interoperabilidade em Sistemas de Informação . . . 7

2.2 Ecossistemas tecnológicos . . . 8 2.2.1 Introdução . . . 8 2.2.2 Desafios . . . 8 2.3 Protocolo HTTP . . . 9 2.4 Framework OAuth . . . 11 2.4.1 Introdução . . . 11 2.4.2 Papéis . . . 12 2.4.3 Fluxo . . . 13

2.4.4 Authorization grant types . . . 14

2.4.5 Client types . . . 16

2.4.6 Access token . . . 16

2.4.7 Authorization code grant . . . 17

2.5 Segurança em Sistemas de Informação Web . . . 20

3 Trabalhos Relacionados 23 3.1 Análise comparativa . . . 25

(8)

4 Método 28

4.1 Contextualização . . . 28

4.2 Requisitos arquiteturais . . . 30

4.3 Tecnologias utilizadas . . . 31

4.3.1 RESTful Web Services e JSON . . . 31

4.3.2 Framework OAuth . . . 32

4.3.3 Framework Django . . . 34

4.3.4 Banco de dados Postgres . . . 34

4.3.5 Algoritmo PBKDF2 . . . 34 4.4 Arquitetura . . . 35 4.4.1 Evolução Arquitetural . . . 43 5 Experimentos e Resultados 45 5.1 Teste de desempenho . . . 45 5.1.1 Materiais . . . 45 5.1.2 Resultados . . . 47 5.1.3 Discussão . . . 47 6 Conclusão 48 6.1 Desafios e limitações . . . 48 6.2 Impacto e contribuições . . . 49 6.3 Trabalhos futuros . . . 51 Referências bibliográficas 52

(9)

Lista de Figuras

2.1 Fluxo abstrato do OAuth . . . 13

2.2 Fluxo OAuth authorization code . . . 17

4.1 Visão geral da arquitetura do Sabiá . . . 35

4.2 Tela de confirmação de identidade . . . 38

4.3 Fluxo que compreende a autenticação do usuário e a entrega de dados baseada no consentimento dele . . . 40

4.4 Tela de consentimento . . . 42

5.1 Entidades do banco de dados utilizadas nos experimentos . . . 46

(10)

Lista de Tabelas

3.1 Critérios utilizados na análise comparativa dos trabalhos relacionados . . 26 3.2 Comparativo entre os trabalhos relacionados e o trabalho desenvolvido

nesta pesquisa . . . 27

33table.caption.18

5.1 Resultados dos experimentos obtidos com a ferramenta JMeter . . . 47

(11)

Lista de Algoritmos

1 Função atualizar_dados_escopo_usuario . . . 39

(12)

Lista de Símbolos e Abreviaturas

ACE Authentication and Autorization for Constrained Environments

API Application Programming Interface

AVA Ambiente Virtual de Aprendizagem

AVASUS Ambiente Virtual de Aprendizagem do SUS

CB Content Based

CBO Cadastro Brasileiro de Ocupações

CdP Comunidade de Práticas

CF Collaborative Filtering

CFM Conselho Federal de Medicina

CNES Cadastro Nacional de Estabelecimentos de Saúde

CNRM Comissão Nacional de Residência Médica

CNS Cartão Nacional SUS

CPF Cadastro de Pessoa Física

CSRF Cross-Site Request Forgery

CSV Comma-Separated Values

EPS Educação Permanente em Saúde

FIP Federated Identity Provider

FRM Federated Resource Manager

GPDR General Data Protection Law

GPU Graphics Processing Unit

HL7 Health Level Seven

HTML Hypertext Markup Language

(13)

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

IOT Internet of Things

JSON Javascript Object Notation

JSTOR Journal Storage

MOODLE Modular Object-Oriented Dynamic Learning Environment

MS Ministério da Saúde

OAuth Open Authorization

ODS Objetivo de Desenvolvimento Sustentável da ONU

OMS Organização Mundial da Saúde

ONU Organização das Nações Unidas

OSI Open System Interconnection

OWASP Open Web Application Security Project

PBKDF2 Password-Based Key Derivation Function 2

PNTD Plataforma Nacional de Telediagóstico

REST REpresentational State Transfer

RFID Radio-frequency Identification

Sabiá Saúde Aberta à Interatividade e à Aprendizagem

SAML Security Assertion Markup Language

SIS Sistema de Informação em Saúde

SMART Sistema de Monitoramento e Avaliação dos Resultados do Programa Telessaúde

SOAP Simple Object Access Protocol

SQL Structured Query Language

SSL Secure Socket Layer

(14)

SUS Sistema Único de Saúde

TIC Tecnologia de Informação e Comunicação

TLS Transport Layer Security

UMA User-Managed Access

UNA-SUS Universidade Aberta do Sistema Único de Saúde

URI Uniform Resource Identifier

URL Uniform Resource Locator

W3C World Wide Web Consortium

WBAN Wireless Medical Sensor Network

WMNS Wireless Body Area Netwotk

WPA Wi-Fi Protected Access

WSDL Web Service Definition Language

WWW World Wide Web

XML Extensible Markup Language

(15)

Capítulo 1

Introdução

Historicamente, no contexto dos Sistemas de Informação em Saúde (SIS) no Brasil, as diferentes soluções foram projetadas e implementadas de acordo com necessidades es-pecíficas e isoladas, estando elas adequadas às características locorregionais. Tal situação está alinhada com as diretrizes do Sistema Único de Saúde (SUS) do país, as quais con-sideram aspectos como a heterogeneidade intrínseca presente nas diferentes regiões do país, o que inclui a adaptação de tais soluções à organização e à gestão locorregionais (Brasil 2015, Brasil 2017).

No entanto, a ausência de um direcionamento mais amplo para a concepção e o pro-jeto das soluções provoca uma grande fragmentação dos usuários e de outros dados dos SIS no contexto do SUS e do Ministério da Saúde (MS), resultando na redundância e na falta de integridade das informações no escopo de cada Sistema de Informação. Tal cená-rio praticamente anula a possibilidade de uma visão global das informações de maneira concisa, atualizada e confiável, não permitindo, assim, o eficaz diagnóstico e o uso de fer-ramentas de Tecnologia de Informação e Comunicação (TIC) para subsidiar a tomada de decisão, tanto no aspecto institucional quanto no aspecto mais global, em que temos, por exemplo, a construção de políticas públicas por parte do MS (Brasil 2015, Brasil 2017).

Motivadas a partir dessa conjuntura, existem iniciativas do MS que apontam a carência de resoluções que viabilizem a interoperabilidade dos diferentes Sistemas de Informação em Saúde no nosso país, bem como a implementação de mecanismos que se integrem com as bases nacionais de identificação, tais como o Cartão Nacional SUS (CNS) e o Cadastro Nacional de Estabelecimentos de Saúde (CNES), somados a outros sistemas externos ao MS. Dentre os contextos de aplicação das soluções indicados, podemos destacar a incorporação de soluções de TIC em sistemas de aprendizagem, cujo propósito, entre outros, é o de impulsionar ações de Educação Permanente em Saúde (EPS), de forma a permitir que os trabalhadores do SUS tenham maior conhecimento teórico e prático para o desempenho de suas atividades (Brasil 2015, Brasil 2017, Brasil 2018a).

Na medida em que a integração entre os diferentes sistemas de aprendizagem evo-lui, eles poderão juntos formar um ecossistema tecnológico de aprendizagem, em que os usuários, os fluxos e os recursos educacionais são compartilhados de maneira harmô-nica. Esta troca de informações é geralmente feita através de Application Programming Interfaces (APIs), Web Services, formatos de intercâmbio de dados e protocolos que permitam a interoperabilidade entre Sistemas de Informação heterogêneos, que podem

(16)

CAPÍTULO 1. INTRODUÇÃO 2

ser produzidos por diferentes fornecedores e implementados com diferentes tecnologias (Brasil 2015, García-Holgado e García-Peñalvo 2016).

Quanto a tais ecossistemas tecnológicos, a maioria dos Sistemas de Informação pro-veem seus próprios mecanismos de autenticação e de gerenciamento de usuários, o que pode ser demarcado como um problema de usabilidade, pois os usuários têm que autenticar-se por meio de nome e autenticar-senha próprios em cada Sistema de Informação. Tal problema au-menta na medida em que novos Sistemas de Informação são incorporados no ecossistema tecnológico (Brasil 2015, García-Holgado e García-Peñalvo 2016).

Observamos que esse quadro de diferentes mecanismos de autenticação e de geren-ciamento de usuários também está presente no contexto dos Sistemas de Informação em Saúde, em que as credenciais dos usuários estão espalhadas entre os diversos SIS, os quais não se integram. Tal situação acarreta numa perda de identidade integral do indi-víduo e, por isso, não inviabiliza a visão e a análise de toda a trajetória dos usuários em cada SIS e também em todo o ecossistema tecnológico (Brasil 2015, García-Holgado e García-Peñalvo 2016).

Uma abordagem para unificar credenciais de usuário espalhadas em diferentes Sis-temas de Informação é fazer uso de Federated Identity Provider (FIP), que oferece ge-renciamento de identidade centralizado, sendo o meio pelo qual os aplicativos da Web fornecem Single Sign-On (SSO) entre os diferentes domínios (ou endereços da Web), que é uma característica desejável, porque evita que o usuário tenha que realizar o procedi-mento de login repetidas vezes nos diferentes sistemas (Herrera-Cubides et al. 2019).

Mais do que nunca, é crucial que as organizações, especialmente as que lidam com dados relacionados à Saúde, armazenem e manipulem as informações pessoais de seus usuários de maneira segura e de acordo com as legislações de proteção de dados vigentes, cujas políticas e leis variam em cada país (Abouelmehdi et al. 2018).

A legislação atual no Brasil determina que o usuário é o proprietário de seus dados, de forma que o armazenamento, o uso e o compartilhamento deles deve ser feito atra-vés do consentimento expresso (de maneira clara e explícita), permitindo que o indivíduo autorize ou revogue o consentimento feito anteriormente – podendo, inclusive, excluir definitivamente seus dados pessoais em todo o ecossistema. A legislação ainda aborda o princípio da segurança, o qual preconiza a utilização de medidas técnicas aptas a proteger os informações pessoais de acessos não autorizados. Tal controle do acesso centrali-zado aos dados por parte dos usuários é função de sistemas Federated Resource Manager (FRM) (Brasil 2014, Brasil 2018b).

Assim, diante do exposto sobre o desafio de projetar, implementar e implantar uma solução de integração de SIS, o presente trabalho apresenta o “Sabiá”, uma arquitetura baseada no protocolo Open Authorization (OAuth) que agrega diferentes SIS por meio de uma abordagem de autenticação (com suporte a SSO), autorização, coleta e disponibi-lização de dados conforme consentimento expresso do usuário, respeitando a legislação brasileira corrente. Dessa forma, o Sabiá é, ao mesmo tempo, um Federated Identity Pro-vider (FIP) e um Federated Resource Manager (FRM), estando presente no contexto de ecossistemas tecnológicos de aprendizagem em Saúde no Brasil.

(17)

1.1 Objetivos

O principal objetivo deste trabalho é projetar, implementar e implantar uma arquite-tura integrada de autenticação e de interoperabilidade de dados, respeitando o consenti-mento do usuário, no contexto de Sistemas de Informação em Saúde no Brasil, com foco em ecossistemas tecnológicos de aprendizagem nessa área. A arquitetura citada tem o objetivo de cumprir quatro requisitos: R1) fornecer uma identidade federada; R2) ser um gerenciador de recursos federados; R3) coletar dados do usuário de diferentes Sistemas de Informação e; R4) entregar os dados a sistemas com base no consentimento do usuário.

1.2 Objetivos específicos

Os objetivos específicos deste trabalho consistem em:

• Projetar, implementar e implantar uma solução Federated Identity Provider (FIP) para prover uma identidade federada para os usuários de Sistemas de Informação em Saúde (SIS) no Brasil;

• Projetar, implementar e implantar uma solução Federated Resource Manager (FRM) que permita aos usuários o gerenciamento de seus dados federados no contexto dos SIS, bem como em todo o ecossistema tecnológico;

• Coletar e entregar dados de usuário para os diferentes Sistemas de Informação, respeitando o consentimento do usuário e a legislação brasileira vigente;

• Projetar e implementar a arquitetura Sabiá;

• Validar a arquitetura do Sabiá por meio de testes de desempenho;

• Implantar e disponibilizar o Sabiá para uso em ambiente de produção.

1.3 Estrutura da Tese

O presente trabalho está organizado da forma descrita a seguir.

O Capítulo 1 apresenta o problema a ser tratado, os objetivos, a organização (ou es-trutura) deste documento e também as publicações relacionadas a esta pesquisa.

O Capítulo 2 aborda a fundamentação teórica dos principais tópicos relacionados ao desenvolvimento da arquitetura proposta, com o intuito de preparar o leitor para as dis-cussões seguintes. Nessa etapa serão abordados os temas: interoperabilidade em Sistemas de Informação, ecossistemas tecnológicos, Hypertext Transfer Protocol (HTTP), Open Authorization (OAuth) e Segurança em Sistemas Web. Logo, o leitor familiarizado com esses assuntos pode prosseguir para o capítulo posterior.

O Capítulo 3 apresenta os trabalhos relacionados aos temas da pesquisa aqui explici-tada – aspecto importante para evidenciar as contribuições do trabalho desenvolvido nesta Tese de Doutorado.

(18)

O Capítulo 4 tem o objetivo de descrever a solução anunciada nesta Tese de Douto-rado, abordando a arquitetura, os principais fluxos e as tecnologias utilizadas durante o projeto, o desenvolvimento e a implantação do Sabiá.

O Capítulo 5 descreve os procedimentos para os experimentos realizados referentes aos testes de desempenho, além dos resultados aclarados.

Por fim, no Capítulo 6 são discutidos os resultados obtidos a partir dos experimentos, bem como as limitações, os desafios, os impactos, as contribuições e, por último, as investigações futuras relacionados ao presente trabalho.

1.4 Publicações relacionadas

1.4.1 Artigos publicados em periódicos

• De Paiva Marques Carvalho, T., de Paiva, J. C., de Medeiros Valentim, R. A., Silva, C. B. P., de Lima, D. F., & Silva, E. C. (2020). Sabiá: an authentica-tion, authorizaauthentica-tion, and user data delivery architecture based on user consent for health information systems in Brazil. Research on Biomedical Engineering. doi:10.1007/s42600-020-00058-8 (Carvalho et al. 2020)

• Paiva, J. C. de, Carvalho, T. de P. M., Vilela, A. B. C. B., Nóbrega, G. Â. S. da, Souza, B. S. de, & Valentim, R. A. de M. (2018). SMART: a service-oriented ar-chitecture for monitoring and assessing Brazil’s Telehealth outcomes. Research on Biomedical Engineering, 34(4), 317–328. doi:10.1590/2446-4740.18004 (Paiva et al. 2018)

1.4.2 Registros de software

• SABIÁ – SAÚDE ABERTA À INTERATIVIDADE E À APRENDIZAGEM Nome do Titular: INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TEC-NOLOGIA DO RIO GRANDE DO NORTE / UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE. Processo INPI: BR 51 2016 001829-1.

• PSBE – PORTAL DA SAÚDE BASEADA EM EVIDÊNCIAS

Nome do Titular: INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TEC-NOLOGIA DO RIO GRANDE DO NORTE / UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE. Processo INPI: BR 51 2016 001830-5.

• BARRAMENTO SOA-LAIS

(19)

• Plataforma Mercosul

• Sistema Nacional de Negociação Permanente do SUS – SiNNP-SUS

• SISTEMA DE GESTÃO ACADÊMICA DA RET-SUS

(20)

Capítulo 2

Fundamentação Teórica

O presente Capítulo aborda a fundamentação teórica dos principais tópicos relaci-onados ao desenvolvimento deste trabalho, tendo a finalidade de subsidiar o leitor nos conteúdos em seguida.

Aqui serão abordados os temas: interoperabilidade em Sistemas de Informação, ecos-sistemas tecnológicos, Hypertext Transfer Protocol (HTTP), Open Authorization (OAuth) e Segurança em Sistemas Web. Dessa maneira, o leitor, já ciente de tais elementos, pode continuar a leitura bem fundamentado.

Antes de entrarmos em cada tópico, descrevemos a seguir alguns conceitos básicos, os quais serão utilizados ao longo deste capítulo:

• Framework ou Software Framework: pode ser entendido como um conjunto de especificações, definições ou diretrizes que é utilizado para resolver um problema de um domínio ou de um contexto específico.

• Sistema de informação: sistema que recebe uma informação e armazena, acessa, transforma, transfere e processa esse dado para prestar o serviço desejado (Langefors 1977). No contexto desta Tese, temos os seguintes sinônimos de Sistemas de In-formação: aplicativo, aplicação, sistema Web e client – este último amplamente utilizado no protocolo OAuth.

O presente Capítulo está organizado da seguinte forma:

• Na Seção 2.1 serão desenvolvidos os conceitos gerais sobre interoperabilidade de sistemas, com foco em Sistemas de Informação em Saúde;

• Na Seção 2.2 serão tratados os conceitos gerais sobre ecossistemas tecnológicos, apontando os benefícios e os desafios na implementação deles, estabelecendo tam-bém um paralelo com os Sistemas de Informação em Saúde;

• Na Seção 2.3 abordaremos, superficialmente, o protocolo HTTP e introduziremos alguns conceitos relevantes para a subseção seguinte;

• Na Seção 2.4 4 discutiremos, com profundidade, o protocolo OAuth, apresentando os conceitos e os fluxos essenciais, os quais serão importantes, principalmente, para o entendimento do Capítulo 4 e;

(21)

CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 7

• Na Seção 2.5 dissertaremos sobre importantes conceitos acerca da segurança em sistemas Web, apresentando as principais vulnerabilidades, bem como as aborda-gens que podem mitigá-las.

2.1 Interoperabilidade em Sistemas de Informação

A interoperabilidade pode ser entendida como a capacidade que distintos Sistemas de Informação têm de compartilhar dados e utilizá-los de maneira adequada em seus processos, contextos e usuários. Entende-se assim que diferentes sistemas podem ter sido produzidos por diferentes fornecedores, podem ter diferentes propósitos, podem estar implantados em diferentes infraestruturas e em diferentes bancos de dados. Logo, isso se estabelece em sistemas heterogêneos entre si em vários aspectos, tais como: técnico, sintático, semântico e organizacional (Farinelli e Almeida 2014).

Os Web Services surgiram num contexto em que ocorre uma crescente demanda de empresas e organizações que implementam e disponibilizam seus serviços para uso de terceiros, pois tais métodos permitem que essa integração de serviços seja feita de uma maneira padronizada, eficiente e eficaz entre sistemas heterogêneos. Web Services são considerados aplicativos modulares independentes, autoexplicativos e que podem ser pu-blicados, localizados e chamados pela Web através de seus Endpoints ou URIs (Rao e Su 2004).

Quando se deseja obter informações que não estão disponíveis através de Web Ser-vices, uma técnica muito utilizada é conhecida como Web Scrapping. Trata-se de uma abordagem de extração de dados da Web automatizada, geralmente retirando informações do HTML de páginas Web de um site. Para tal, são usados programas especificamente codificados para a captura e a manipulação dos dados de um site específico e, usualmente, armazenam as informações extraídas num banco de dados central (Malik e Rizvi 2011).

No contexto da Saúde, a abordagem técnica e os padrões devem permitir que a infor-mação seja compartilhada por profissionais, estabelecimentos e pacientes, independente da aplicação, da tecnologia ou da empresa que desenvolveu Sistema de Informação. As-sim, nessa circunstância, a interoperabilidade pode ser entendida como a capacidade dos Sistemas de Informação em Saúde trabalharem conjuntamente, não importando os limites organizacionais ou os técnicos, com o objetivo de avançar na entrega efetiva do ensino ou cuidado à Saúde para indivíduos e comunidades (Brasil 2015).

Na conjuntura dos Sistemas de Informação em Saúde no Brasil, temos a existência de múltiplas soluções disponibilizadas em produção, com uma grande variedade de forne-cedores, vocabulários e contextos de aplicação. Assim, existem diversas motivações na coleta e no uso de informações. Nesse cenário, o Ministério da Saúde alude à necessi-dade da criação de mecanismos, estruturas e barramentos que permitam que os diferentes Sistemas de Informação em Saúde interoperem entre si, de forma que tal integração ga-ranta o fluxo adequado de informações consideradas relevantes no contexto de cada SIS (Brasil 2015).

Tais mecanismos são especialmente relevantes porque possibilitam o aproveitamento das diversas soluções existentes, as quais são adequadas para cada contexto (de tema, de

(22)

localidade geográfica etc. – o que está alinhado às diretrizes do SUS), permitindo, dessa forma, a viabilização de ecossistemas tecnológicos (que abordaremos na Seção 2.2.

Amparado pela Resolução nº 6624 de 2013 da Organização Mundial de Saúde (OMS), o Ministério da Saúde entende que a interoperabilidade é um dos alicerces fundamentais para o efetivo desenvolvimento da Estratégia da E-Saúde para o Brasil: uma proposta para a organizar informações, agregando valor para que estas se tornem um componente estratégico para a tomada de decisão em relação ao sistema de Saúde (Brasil 2017).

2.2 Ecossistemas tecnológicos

2.2.1 Introdução

Atualmente, os Sistemas de Informação têm evoluído, devido ao nível de interoperabi-lidade entre eles, para ecossistemas tecnológicos, que são soluções que objetivam possuir informação e conhecimento de maneira agnóstica de tecnologia utilizada. É importante observar que os ecossistemas tecnológicos incluem o componente humano: os usuários, que estabelecem fluxos de informações com outros componentes e são afetados quando o sistema evolui (García-Holgado e García-Peñalvo 2016).

Os ecossistemas tecnológicos podem ser considerados como um Framework geral para desenvolver qualquer tipo de solução tecnológica em que a informação é o centro do sistema. Cada ecossistema tecnológico pode ser orientado a diferentes domínios, de-pendendo dos problemas os quais se pretende resolver. Por isso, existem ecossistemas tecnológicos para propósitos gerais que podem ser facilmente estendidos, adaptados e implantados para um objetivo específico (Chen et al. 2014). No contexto de Sistemas de Informação cujo propósito é a gestão orientada para fornecer e melhorar o conhecimento dentro de uma organização ou temática, o ecossistema é chamado de ecossistema tecno-lógico de aprendizagem (ou Learning Ecosystem). Tal tipo de ecossistema tecnotecno-lógico é adaptado à gestão de evolução da aprendizagem que ocorre em empresas e organizações (Uden et al. 2007, García Peñalvo et al. 2011).

2.2.2 Desafios

Apesar dos benefícios obtidos com o uso dos ecossistemas tecnológicos, a implemen-tação deles em organizações que escolhem esse tipo de solução tem maior complexidade em comparação aos sistemas de alguns anos atrás. Isso acontece porque, em termos ge-rais, os ecossistemas tecnológicos envolvem a integração de diferentes componentes que devem evoluir tanto individual quanto coletivamente. Nesse cenário de maior complexi-dade, surgem alguns desafios no uso dos ecossistemas tecnológicos, os quais, podemos citar (García-Holgado e García-Peñalvo 2016):

• Geralmente, a implantação dos ecossistemas tecnológicos é algo recente, assim, muitas organizações já têm soluções tecnológicas implantadas, as quais deverão ser integradas ao novo ecossistema, o que pode se tornar difícil quando não há mão de

(23)

obra disponível ou qualificada. Além disso, em muitos casos, as soluções existentes não são baseadas em software livre, o que inviabiliza ou dificulta tal adaptação.

• Há um grande número de aplicativos necessários para que as organizações atendam às suas necessidades. Em muitos casos, a conexão adequada entre os diferentes aplicativos não existe, o que geralmente culmina na inconsistência dos dados, que são distribuídos entre os diferentes aplicativos. Como consequência, não existe uma visão global para todas as informações e todos os conhecimentos gerados dentro da organização, o que prejudica, entre outras atividades, a tomada de decisão baseada nas informações globais e interrelacionadas.

• A maioria dos aplicativos fornece seus próprios mecanismos para gerenciamento e autenticação de usuários. Trata-se de um problema de usabilidade que se torna proporcionalmente maior na medida em que a quantidade de componentes do ecos-sistema aumenta. Isso ocorre porque o usuário deve gerenciar seu perfil em cada sistema e deve acessar cada um deles separadamente, então o usuário realiza o pro-cesso de autenticação muitas vezes – o que aumenta conforme o número de sistemas aumenta. Por isso, temos aqui dois problemas de usabilidade: o usuário precisa se lembrar das credenciais de cada sistema e; o usuário precisa realizar o procedimento de autenticação diversas vezes.

É válido salientar que os problemas descritos acima não são mutualmente exclusi-vos: eles podem ocorrer ao mesmo tempo no contexto da implantação de um ecossistema tecnológico.

Uma identidade federada corresponde a uma credencial de um sistema de autenti-cação que pode ser utilizada em outros sistemas, mesmo de diferentes fornecedores e domínios da Web. Essa abordagem é usada pelos aplicativos da Web para oferecer uma autenticação (ou login) única ou o Single Sign-On (SSO) em diferentes domínios, for-necendo gerenciamento centralizado de identidades – um recurso desejável porque evita que o usuário efetue o processo de autenticação repetidamente em diferentes aplicativos (Herrera-Cubides et al. 2019). Uma plataforma que oferece uma identidade federada é considerada uma Federated Identity Provider (FIP).

Quanto ao problema de as informações dos usuários estarem espalhadas em diferen-tes componendiferen-tes do ecossistema tecnológico, uma abordagem é o uso de ferramentas Federated Resource Manager (FRM), as quais permitem que o usuário, na qualidade de proprietário de seus dados, tenha o gerenciamento deles em todo o ecossistema tecnoló-gico.

2.3 Protocolo HTTP

O Hypertext Transfer Protocol (HTTP) – em Língua Portuguesa, Protocolo de Trans-ferência de Hipertexto – é uma especificação coordenada pelo World Wide Web Consor-tium (W3C) e pela Internet Engineering Task Force, que é a base para toda a comunicação de dados da World Wide Web (WWW). O HTTP é um protocolo presente na camada de

(24)

aplicação do modelo Open System Interconnection (OSI), sendo utilizado para Sistemas de Informação de hipermídia distribuídos e colaborativos (Fielding et al. 1999).

O HTTP é um protocolo baseado no paradigma ou na arquitetura “cliente-servidor”, em que clientes e servidores se comunicam trocando mensagens individuais (em oposição a um fluxo de dados). As mensagens enviadas pelo cliente, geralmente por um navega-dor da Web, para o servinavega-dor são chamadas de “requisições” e as mensagens enviadas do servidor para o cliente são chamadas de “respostas”.

Considerando que o HTTP é um protocolo com uma especificação extensa, iremos trazer aqui os conceitos mais relevantes para o entendimento deste trabalho:

• User-agent

O user-agent é qualquer ferramenta que atua em nome do usuário final. Na maio-ria dos casos, essa ferramenta é um browser (ou navegador Web) que tipicamente exibe uma página Web em formato Hypertext Markup Language (HTML), um do-cumento de hipertexto. O user-agent é sempre a entidade que inicia a requisição. Por outro lado, o servidor nunca inicia a requisição (embora existam mecanismos, incorporados ao longo dos anos, para simular mensagens iniciadas por servidores), agindo somente quando requisitado pelo cliente (Mozilla 2020).

• URI e URL

Segundo (Fielding et al. 1999), Uniform Resource Identifier (URI) ou identificador de recurso uniforme é o meio pelo qual o HTTP identifica os recursos disponíveis em um servidor Web. Um recurso pode ser um documento, uma imagem ou qual-quer outro tipo de arquivo. Outro tipo de identificador muito recorrente é o Uniform Resource Locator (URL), um tipo de URI comumente chamado de endereço Web. Abaixo temos exemplos de três URLs (ou URIs):

1) https://login.sabia.ufrn.br/

2) https://login.sabia.ufrn.br/suporte/

3) https://login.sabia.ufrn.br/buscar?nome=maria

Uma URI tem quatro partes principais:

1. protocolo: https para os três exemplos acima;

2. autoridade ou nome de domínio: login.sabia.ufrn.br para os três exem-plos acima;

3. path: “/”, /suporte/ e /buscar/, respectivamente;

4. query: é a parte após o caractere “?”, que está presente no terceiro exemplo acima, indicando que o parâmetro nome tem o valor maria.

• Requisições

Conforme visto anteriormente, uma requisição é uma mensagem enviada pelo cli-ente com destino ao servidor. De forma simplificada, temos abaixo a representação de uma requisição HTTP:

(25)

GET / HTTP/1.1

Host: login.sabia.ufrn.br

No exemplo acima, GET é o método HTTP, “/” é o path, HTTP/1.1 é a versão do protocolo e a linha abaixo é o cabeçalho, tendo o parâmetro “Host” com valor “login.sabia.ufrn.br”. O método HTTP geralmente é um verbo e, na maioria das requisições, temos os métodos GET e POST. Com a correta implementação dos métodos HTTP, o verbo GET deve retornar um recurso para o cliente (sem alterar o estado do recurso) e verbo POST é utilizado para inserir um novo recurso, o que muda o estado de recursos no servidor.

O protocolo HTTP abrange uma numerosa quantidade de métodos, parâmetros no cabeçalho etc. Porém, não iremos nos aprofundar em tais aspectos por não serem estritamente necessários para o entendimento desta Tese.

2.4 Framework OAuth

2.4.1 Introdução

No modelo tradicional de sistemas da Web, quando há necessidade de fornecer acesso aos recursos protegidos do usuário a aplicativos de terceiros, o primeiro compartilha suas credenciais (nome de usuário e senha) com esses aplicativos. Tal abordagem ocasiona uma série de problemas, sobretudo no tocante à segurança. Sobre eles, podemos citar (Hardt 2012, Leiba 2012):

• Aplicativos de terceiros armazenam as credenciais do usuário para uso posterior, tipicamente num formato de texto puro e sem criptografia. Senhas armazenadas de tal forma oferecem risco de exposição, uma vez que, caso o banco de dados seja comprometido, as credenciais estarão expostas.

• Todos os aplicativos precisam implementar autenticação com senha, o que aumenta a chance de vulnerabilidade porque a forma com que cada um manipula e armazena as informações não é conhecida. Assim, não se sabe se os padrões de segurança recomendados são seguidos.

• Uma vez em posse das credenciais do usuário, os aplicativos de terceiros terão acesso global e irrestrito aos recursos protegidos desse indivíduo, retirando dele a capacidade de restringir a duração ou de limitar o acesso a um subconjunto limitado de recursos. Além disso, o compartilhamento das credenciais permite também que os aplicativos de terceiros executem ações em nome do usuário, podendo tais ações serem destrutivas ou irreversíveis.

• Os usuários (proprietários dos recursos) não conseguem revogar o acesso a um apli-cativo terceiro sem revogá-lo a todos os outros. Para contornar isso, o usuário precisa modificar suas credenciais no servidor principal e atualizar as credenciais

(26)

apenas nos aplicativos terceiros que ele ainda deseja conceder o acesso, o que é um grande inconveniente.

• O comprometimento de qualquer aplicativo terceiro resulta no comprometimento das credenciais do usuário e de todos os dados protegidos por tais credenciais. Com o propósito de atacar os problemas citados, surge o OAuth, um Framework de autorização que permite que um aplicativo terceiro tenha acesso limitado a um serviço HTTP em nome do proprietário do recurso. O Framework define a interação de aprova-ção entre o proprietário do recurso e o serviço HTTP. Logo, nesse contexto, o usuário proprietário do recurso é o resource owner e o aplicativo terceiro é o client.

O Framework OAuth se propõe a resolver os entraves mencionados anteriormente ao introduzir uma camada de autorização que separa o papel do client do papel do resource owner. No OAuth, o client faz a requisição de acesso aos recursos controlados pelo resource owner, os quais são hospedados ou armazenados pelo resource server.

Enquanto no modelo tradicional as credenciais do resource owner seriam comparti-lhadas com o client (o que poderia ocasionar os problemas supracitados), no OAuth o clientobtém um access token, que é um conjunto de caracteres que permite acesso, du-rante um tempo definido, a um conjunto de recursos definidos e limitados por meio de escopos (scopes). Access tokens são emitidos para clients por um authorization server com a aprovação do resource owner. O client usa o access token para acessar os recursos protegidos hospedados pelo resource server (Hardt 2012, Leiba 2012).

Fazendo uma analogia com o mundo real, o access token pode ser entendido como uma procuração, permitindo que um terceiro possa agir em nome do usuário num con-texto específico de atuação e por um período de tempo acordado. Por exemplo: um aluno (resource owner) pode conceder acesso de leitura aos seus certificados, armazenados num ambiente virtual de aprendizagem (resource server), para um serviço de impressão (cli-ent) sem a necessidade de compartilhar suas credenciais (nome de usuário e senha). Ao invés disso, o aluno (resource owner) acessaria o serviço de impressão (client) e este, por sua vez, solicitaria ao usuário a permissão de leitura aos certificados hospedados no ambi-ente virtual de aprendizagem (authorization server). Assim, o client teria acesso apenas aos recursos (scopes) concedidos pelo usuário.

2.4.2 Papéis

O Framework OAuth define quatro papéis (Hardt 2012, Leiba 2012): 1. Resource Owner

Entidade capaz de conceder acesso a um recurso protegido, o qual é de sua propri-edade. Geralmente é uma pessoa e comumente é referido como usuário ou usuário final.

2. Resource Server

É o servidor Web que hospeda e armazena os recursos protegidos, sendo capaz de aceitar e responder às solicitações dos clients para acesso aos recursos protegidos do resource owner por meio de access tokens.

(27)

3. Client

É o aplicativo que faz solicitações de acesso aos recursos protegidos em nome do resource ownere com sua autorização. Observamos aqui que o termo client não im-plica numa restrição tecnológica ou de implementação – podendo assim este client ser um aplicativo Web, desktop, mobile etc.

4. Authorization server

Servidor que emite os access tokens para os clients após autenticação do resource ownere a obtenção de sua autorização.

O OAuth não define processos ou tecnologias para a comunicação entre o authoriza-tion servere o resource server, o que fica a critério do desenvolvedor. Observamos aqui que um mesmo servidor (ou serviço) pode ser um authorization server e um resource ser-ver. Ademais, um único authorization server pode emitir access tokens que serão aceitos por múltiplos resource servers.

2.4.3 Fluxo

Figura 2.1: Fluxo abstrato do OAuth

Fonte: https://api.slack.com/legacy/oauth

O fluxo abstrato do OAuth é ilustrado na Figura 2.1 e descreve a interação entre os quatro papéis. Cada passo (interação) será descrito a seguir:

1. O client solicita a autorização para o resource server. O authorization request pode ser feito diretamente para o resource owner (conforme ilustrado na Figura 2.1) ou indiretamente (usando o authorization server como intermediário);

(28)

2. O client recebe um authorization grant, que é uma credencial representando a auto-rização do resource owner, podendo ser em um dos quatro authorization grant types definidos no OAuth, os quais serão abordados na Subseção 2.4.4. O authorization grant typedepende do método utilizado pelo client no passo authorization request (passo 1) e dos authorization grant types suportados pelo authorization server.

3. O client requisita um access token ao se autenticar no authorization server e apre-sentar tal o authorization grant recebido no passo 2.

4. O authorization server autentica o client e valida o authorization grant. Caso seja válido, o authorization server emite o access token e o entrega para o client.

5. O client requisita acesso a um recurso protegido pelo resource server informando o access tokenrecebido no passo 4.

6. O authorization server valida o access token junto ao authorization server. Caso seja válido, o authorization server entrega o recurso protegido para o client.

A Figura 2.1 ilustra um fluxo genérico do Framework OAuth, porém, por razões de segurança, o recomendado, segundo a própria especificação (Hardt 2012), é que o client obtenha o authorization grant do resource owner (aspecto ilustrado nos passos 1 e 2 da Figura 2.1) fazendo uso do authorization server como um intermediário, o que é garantido pelo authorization code grant, que é um dos quatro authorization grant types definidos no OAuth, os quais serão abordados na Subseção 2.4.4.

2.4.4 Authorization grant types

Um authorization grant é uma credencial, representando uma autorização de acesso aos recursos protegidos do resource owner. Por isso, ela é usada pelo client para obtenção do access token (Hardt 2012, Leiba 2012).

A especificação do OAuth define quatro authorization grant types. Entretanto, para o escopo desta Tese, iremos nos aprofundar mais no authorization code, que foi ampla-mente utilizado no projeto deste trabalho e, além disso, é o authorization grant type reco-mendado por possuir benefícios relacionados à segurança quando comparado aos demais (Hardt 2012, Leiba 2012).

1. Authorization code

O authorization code é obtido usando o authorization server como um intermediá-rio entre o client e o resource owner. Ao invés de solicitar a autorização diretamente do resource owner, o client direciona o resource owner para o authorization server através do seu user-agent, que direciona o resource owner de volta para o client com o authorization code.

Antes de direcionar o resource owner de volta para o client com o authorization code, o authorization server autentica o resource owner e obtém sua autorização. Devido ao fato do resource owner somente se autenticar no authorization server, as

(29)

credenciais do resource owner não são compartilhadas com o client. Dessa forma, o resource owner tem uma relação de confiança maior com o authorization server, que é a entidade que armazena suas credenciais.

O authorization code provê alguns benefícios de segurança, tais como a capacidade de autenticar o client, bem como transmitir o access token diretamente para o client sem passar pelo user-agent, o que seria uma potencial falha de segurança e poderia expor o access token para aplicativos terceiros que fazem uso do mesmo user-agent.

2. Implicit

O Implicit é um fluxo simplificado do Authorization Code, sendo apropriado para clientsimplementados em um browser e que usam uma linguagem de programação de script, como JavaScript. No fluxo Implicit, ao invés de emitir o authorization code para o client, este recebe diretamente um access token após autorização do resource owner. Assim, este authorization grant type é implícito porque não há emissão de credenciais intermediárias (como o authorization code) para obtenção do access token.

Nesse fluxo, o authorization server não autentica o client para emitir um access token. Em alguns casos, o client pode ser verificado e identificado através da URI de redirecionamento, que é usada para entregar o access token para o client. Di-ferentemente do authorization code, no authorization grant type implicit o access tokenpode ser exposto para o resource owner ou para outras aplicações de terceiros com acesso ao user-agent utilizado pelo resource owner.

O authorization grant type implicit melhora a capacidade de resposta e eficiência de alguns clients, uma vez que reduz a quantidade de passos exigidos para obtenção do access token. Entretanto, tal conveniência deve ser avaliada considerando as implicações relacionadas à segurança.

3. Resource owner password credencials

Nesse fluxo, as credenciais do resource owner (nome de usuário e senha) podem ser usadas diretamente como um authorization grant para obtenção do access token. Assim, o resource owner password credencials deve ser usado somente quando não há outros authorization grant types disponíveis ou quando há um alto nível de confiança entre o resource owner e o client, o que geralmente ocorre em aplicativos da instituição ou empresa que o resource owner faz parte.

Mesmo considerando que esse fluxo requer o acesso direto do client às credenciais do resource owner, tais credenciais são usadas numa requisição para obtenção do access token. Esse authorization grant type pode eliminar a necessidade do client de armazenar as credenciais para uso futuro, por isso a importância do client ser confiável.

4. Client credentials

O authorization grant type client credentals refere-se à autenticação do próprio client(o client é o próprio resource owner) e pode ser usado quando os recursos

(30)

que o client deseja obter estão sob controle dele mesmo. Dessa forma, o client está agindo em seu próprio nome (e não em nome de um usuário final). Por exemplo: um aplicativo pode usar o authorization grant type client credentials para gerenciar o nome, a descrição ou o logotipo do próprio aplicativo.

2.4.5 Client types

O OAuth define dois client types, que são categorizados com base na capacidade de manter a confidencialidade das credenciais ao autenticar com o authorization server (Hardt 2012, Leiba 2012):

1. Confidential

Um client é do tipo confidential quando é capaz de manter a confidencialidade de suas credenciais. Estão nessa categoria os clients implementados em um servidor seguro e que implementam acesso seguro às credenciais de acesso do próprio client.

2. Public

Um client é do tipo public quando não é capaz de manter a confidencialidade de suas credenciais. Estão nessa categoria os clients que são executados em disposi-tivos móveis do usuário final, em aplicadisposi-tivos baseados em navegador ou ainda em aplicativos que fazem uso de linguagem de programação que são executados no user-agentdo resource owner.

Diante do exposto, é natural inferir que o client type mais recomendado, do ponto de vista da segurança, é o confidential, haja vista a capacidade de manter as informações (as credenciais do client) confidenciais.

2.4.6 Access token

Um access token pode ser entendido como uma concessão de acesso aos recursos protegidos por um período de tempo. Trata-se de uma grande sequência de caracteres que representa uma autorização emitida para um client, de forma que nessa autorização estão expressos o escopo (OAuth scope) e a duração do acesso. Access tokens são autorizados pelo resource owner e emitidos pelo authorization server.

No contexto do OAuth, um scope é um mecanismo desenvolvido para limitar o acesso de um client aos recursos do resource owner. Um client pode solicitar um ou mais scopes, sendo eles apresentadas ao resource owner na tela de consentimento. Assim, o access tokenemitido para o client será limitado aos escopos concedidos pelo usuário final na tela de consentimento.

De maneira geral, o client solicita acesso a determinados scopes ao resource owner. A especificação do OAuth permite que o authorization server ou o resource owner mo-difiquem os scopes solicitados originalmente pelo client, o que poderá ser feito na tela de consentimento.

O OAuth não define nenhum valor específico para escopos, pois essa é uma decisão que dependente da arquitetura e das necessidades internas de cada aplicativo.

(31)

Access tokens fornecem uma camada de abstração, substituindo diferentes constru-ções de autorização por um único token entendido pelo resource server. Tal abstração possibilita a emissão de access tokens mais restritivos (menos scopes do que foram auto-rizados anteriormente) e remove a necessidade do resource server de implementar uma ampla variedade de métodos de autenticação. Assim, a implementação de access tokens é um fator importante para a garantia de interoperabilidade entre sistemas heterogêneos.

2.4.7 Authorization code grant

Conforme visto na Subseção 2.4.4, o authorization code é um authorization code grant typeque é utilizado para obter o access tokens, sendo otimizado para clients do tipo confidential. Como é baseado num fluxo de redirecionamento, o client deve ser capaz de interagir com o user-agent do resource owner, bem como ser capaz de receber requisições do authorization server.

Figura 2.2: Fluxo OAuth authorization code

Fonte: https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

A Figura 2.2 ilustra o fluxo do authorization Ccde grant, cujos passos são descritos a seguir:

No passo 1, o client inicia o fluxo ao redirecionar o user-agent do resource owner para o authorization server. Nessa requisição de redirecionamento, o client informa sua identificação, os scopes solicitados e uma URI de redirecionamento que o authorization serverirá enviar para o user-agent de volta quando o acesso for concedido (ou negado).

No passo 2, o authorization server autentica o resource owner através do user-agent, e estabelece se o resource owner concedeu ou não a requisição de acesso do client.

(32)

No passo 3, uma vez que o resource owner concedeu o acesso, o authorization ser-ver redireciona o user-agent de volta para o client usando a URI de redirecionamento fornecida no passo 1. Essa URI inclui um authorization code.

Os passos anteriores (1, 2 e 3) referem-se à requisição de autorização. Vamos agora explicar mais tecnicamente tal processo: a requisição de redirecionamento é realizada através de uma requisição GET ao authorization server, feita com uma URI que é cons-truída pelo client utilizando o formato “application/x-www-form-urlencoded”. Ela tem os seguintes parâmetros:

• response_type

obrigatório e deve ter o valor code por se tratar do authorization code grant;

• client_id

obrigatório e refere-se à identificação do client;

• redirect_uri

opcional e refere-se à URI de redirecionamento mencionada anteriormente.

• scope

opcional e refere-se aos scopes solicitados pelo client em relação aos recursos pro-tegidos do resource owner;

• state

opcional, com o propósito de manter o estado entre a requisição e a resposta, sendo importante para que o resource owner tenha a experiência mais fluida.

Abaixo segue um exemplo dessa requisição de redirecionamento ao authorization ser-ver“authserver.com”: GET https://authserver.com/authorize? response_type=code& client_id=s6BhdRkqt3& state=xyz& redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

Ao receber a requisição (passo 1), o authorization server a valida e assegura que todos os parâmetros requeridos estão presentes e válidos. Se a requisição for válida, o authorization server autentica o resource owner e recebe do resource owner se ele autoriza ou não o pedido de acesso do client (passo 2).

Após isso, o authorization server direciona o user-agent para a URI informada em redirect_uri usando uma resposta HTTP de redirecionamento, que inclui o authoriza-tion code(passo 3). A resposta do authorization server para o client vem na forma de uma requisição do primeiro para o segundo. Essa requisição também utiliza o formato “application/x-www-form-urlencoded” e tem os seguintes parâmetros:

(33)

• code

obrigatório e refere-se ao authorization code gerado pelo authorization server;

• state

obrigatório se o parâmetro state estava presente na requisição de autorização do client(ilustrada anteriormente).

Abaixo segue um exemplo dessa requisição do authorization server para client:

GET https://client.com/endpoit/? code=SplxlOBeZQQYbYS6WxSbIA& state=xyz

No passo 4, o client requisita (informando o authorization code recebido no passo 3) o access token ao authorization server. Ao fazer essa requisição, o client autentica com o authorization server e informa a URI de redirecionamento usada para obter o authorization codepara verificação.

Essa requisição do access token ao resource server pelo client utiliza o formato “application/x-www-form-urlencoded” e tem os seguintes parâmetros:

• grant_type

obrigatório e deve ser authorization_code;

• code

obrigatório e refere-se ao authorization code recebido anteriormente do authoriza-tion server;

• redirect_uri

obrigatório se o redirect_uri foi incluído no authorization request, de forma que tais valores devem ser idênticos;

• client_id

obrigatório e refere-se à identificação do client.

Abaixo segue um exemplo dessa requisição:

POST /token HTTP/1.1 Host: server.example.com

Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code& code=SplxlOBeZQQYbYS6WxSbIA&

(34)

Ao receber a requisição, o authorization server deve:

• Exigir autenticação do client se for confidential ou se o authorization grant type for client credentials;

• Autenticar o client caso as credenciais de autenticação estejam corretas;

• Caso o client seja confidential, assegurar que o authorization code foi emitido para o client; caso o client seja public, assegurar que o code foi emitido para o client_idda requisição;

• Verificar se o authorization code é valido;

• Assegurar que o parâmetro redirect_uri foi incluído no authorization request inicial e se os valores são idênticos.

No passo 5, o authorization server autentica o client, valida o authorization code e assegura que a URI de redirecionamento é compatível com a URI usada para redirecionar o client no passo 3. Se for válida, o authorization server responde de volta com o access token.

Abaixo segue uma resposta de sucesso com o access token:

HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }

Observamos que a resposta vem em formato Javascript Object Notation (JSON) e que o valor do access token está presente no atributo access_token. Além deste, podemos ter atributos extras definidos a critério do desenvolvedor.

2.5 Segurança em Sistemas de Informação Web

Atualmente, a Web e, consequentemente, os Sistemas de Informação Web, fazem parte do cotidiano das pessoas, constituindo o principal meio de acesso a muitos ser-viços básicos, como Saúde, Educação, e-commerce, transações financeiras etc. Como resultado, vulnerabilidades em plataformas Web abrem possibilidades para que usuários mal-intencionados realizem ataques com consequências catastróficas, que variam desde

(35)

perdas econômicas (como no caso de ataques a fornecedores de pagamento) até violações de privacidade (como no caso de divulgação indevida de arquivos pessoais ou registros eletrônicos de pacientes no contexto de sistemas de informação de saúde). Conforme os serviços com requisitos críticos de segurança vão se tornando cada vez mais disponíveis na Web, aumenta a necessidade da implementação de mecanismos eficazes de proteção e de minimização dessas vulnerabilidades (Bugliesi et al. 2017).

A Open Web Application Security Project (OWASP), fundação sem fins lucrativos que trabalha para aumentar a segurança de softwares, é considerada uma referência na área de segurança para o desenvolvimento de Sistemas de Informação. Por isso, ela realizou levantamento dos maiores riscos de segurança, ou vulnerabilidades, para aplicações Web (Jain e Shanbhag 2012, Acharya et al. 2015, Cifuentes et al. 2015).

Contextualizando com o presente trabalho, podemos citar alguns dos riscos levantados pela OWASP:

• Broken authentication

A confirmação da identidade do usuário é crítica num Sistema de Informação, espe-cialmente em sistemas provedores de identidade federada, bem como em sistemas gerenciadores de recursos federados. A broken authentication abrange os riscos de segurança em que a confirmação da identidade do usuário é comprometida, princi-palmente por perda, por “adivinhação” de suas credenciais (ocorre quando se usa senhas fracas ou bem conhecidas) ou por "sequestro de sessão"(ocorre quando há exposição da informação do identificador de sessão do usuário, o que permite que outro usuário mal-intencionado possa agir em nome da vítima).

• Injection

Injection ocorre quando os dados fornecidos pelo usuário não são validados, filtra-dos ou sanitizafiltra-dos pela aplicação. O exemplo mais comum desse tipo de ataque ocorre quando um usuário mal-intencionado insere instruções Structured Query Language (SQL) como um parâmetro na URL, o que pode provocar a execução de tais instruções no banco de dados da aplicação, comprometendo a consistência do banco de dados. Por ser muito comum o uso de SQL nesse tipo de ataque, muitas vezes injection é referido como SQL injection.

• Cross-Site Scripting (XSS)

Ataques do tipo XSS ocorrem quando um usuário mal-intencionado consegue in-serir scripts (instruções executáveis) de forma que estes sejam realizados em user-agents(geralmente navegadores da Web) de outros usuários. Podemos exemplificar esse tipo de ataque da seguinte forma: um usuário acessa um artigo específico (num sistema do tipo blog) e, ao submeter um comentário para tal texto, ele insere um código JavaScript; considerando que o comentário fica visível para todos os indiví-duos que acessam tal artigo e que o sistema não trata essa falha, o código JavaScript inserido pelo usuário mal-intencionado será executado sempre que qualquer usuá-rio acesse o artigo. Nesse exemplo, o JavaScript pode, por exemplo, recuperar o identificador da sessão de outros usuários. Dessa forma, o XSS explora a confiança que um usuário tem por um site ou Sistema de Informação em particular.

(36)

• Cross-Site Request Forgery (CSRF)

Esse tipo de ataque ocorre quando um usuário mal-intencionado consegue executar ações usando as credenciais de um outro sem o seu consentimento. Esse é um ata-que mais elaborado ata-que o XSS, em ata-que a vítima é um usuário já autenticado. Nesse modo de ataque, o usuário mal-intencionado prepara uma requisição, escolhendo os parâmetros para o servidor. Assim, esse ataque normalmente é feito sem a ví-tima perceber, por meio de requisições JavaScript. Uma abordagem para mitigar tal vulnerabilidade é por meio da checagem de um segredo em cada requisição que o servidor envia para o cliente antes de acessar tal formulário. Diferentemente do XSS, que explora a confiança que um usuário tem pelo sistema, o CSRF explora a confiança que o sistema tem pelo user-agent do usuário.

• Clickjacking

Clickjacking ocorre quando um site malicioso encapsula um outro confiado pela vítima (isso, geralmente, é realizado através de Iframe, que é uma marcação ou funcionalidade presente no HTML que permite embutir um site dentro de outro). Dessa forma, o site mal-intencionado pode executar ações sem o consentimento do usuário diretamente no site confiado pela vítima. Uma abordagem muito utilizada para evitar tal ataque é por meio da implementação nos servidores de um meca-nismo que impede que o site seja disponibilizado dentro de um Iframe.

(37)

Capítulo 3

Trabalhos Relacionados

O presente Capítulo apresenta os trabalhos relacionados com os principais temas desta pesquisa. Este capítulo é importante para evidenciar as contribuições do estudo desenvol-vido nesta Tese de Doutorado.

Foi realizada uma pesquisa na literatura da área com o intuito de encontrar publicações relacionadas aos objetivos desta Tese. Optamos por empreender as buscas dessas publi-cações fazendo uso do motor de pesquisa Google Scholar, o qual indexa publipubli-cações de diferentes periódicos e repositórios ao redor do mundo – incluindo Elsevier, IEEExplore, Journal Storage (JSTOR), Pubmed, Science Direct, Springer etc.

Após a realização e a análise dos resultados das leituras, entendemos que a abordagem mais adequada para encontrar os trabalhos relacionados seria através de uma busca por publicações considerando os seguintes critérios de inclusão:

• Ano de publicação: entre 2015 e 2020.

• Busca textual: allintitle: ((health OR healthcare) + (authentication OR aggregation OR distribution OR delivery OR protecting OR exchange) + (system OR systems OR application OR applications OR service OR platform OR architecture) + (data OR API OR APIs)) OR (elearning + (health OR healthcare) + brazil)

O filtro por “ano de publicação” teve o propósito de restringir os resultados de forma a obter os trabalhos mais recentes. Já o filtro “busca textual” foi utilizado para encontrar os trabalhos por palavras-chave ou título. Para isso, agregamos palavras-chave similares entre parêntesis para ampliar o escopo de nossa busca.

Depois da aplicação dos filtros, foram encontrados 84 resultados, incluindo o artigo publicado que é fruto desta Tese: (Carvalho et al. 2020). A partir de tais resultados, foi necessário excluir alguns artigos não relacionados, de forma que uma série de critérios de exclusão foram considerados, os quais descrevemos a seguir:

• Trabalhos fora do escopo de solução tecnológica. Isso foi necessário porque alguns termos da busca, como “system”, “distribution”, “delivery”, “protecting” e “ser-vice”, podem se referir a sistemas ou serviços de Saúde no sentido amplo, o que, claramente, não faz parte escopo do presente trabalho.

(38)

CAPÍTULO 3. TRABALHOS RELACIONADOS 24

• Trabalhos que fazem avaliação ou análise de protocolos ou algoritmos. Tais traba-lhos foram descartados porque, a rigor, não propõem uma solução tecnológica.

• Trabalhos cuja aplicação se dá num contexto específico, como Internet of Things (IoT), wearable devices, smart devices, sistemas de coleta de dados de sensores, sistemas de monitoramento de pacientes, Wireless Body Area Netwotk (WBAN), Wireless Medical Sensor Network (WMNS) ou ainda protocolos específicos de co-municação de dispositivos, como o Health Level Seven (HL7). Tais trabalhos foram descartados porque apresentam soluções num contexto específico, não sendo proje-tadas para permitir a integração com sistemas de outros contextos, como sistemas de aprendizagem ou telediagnóstico.

• Trabalhos cuja solução exige que o usuário utilize, no momento do registro ou do login, biometria ou outro dispositivo mais específico, como smart card ou crachás com Radio-frequency Identification (RFID). Tais trabalhos foram descartados por-que consideramos a necessidade de um dispositivo específico um fator limitador, especialmente no contexto de sistemas de aprendizagem.

• Trabalhos cuja solução não contempla autenticação de usuários ou autorização de uso de seus dados por outros sistemas. Alguns trabalhos propõem uma solução de transferência de dados e imagens, mas não autenticação ou autorização de recursos do usuário, que são características relevantes do trabalho apresentado nesta Tese.

Após a exclusão com base nos critérios acima, chegamos a quatro trabalhos relacio-nados: Wadhwa et al. (2015), de Araújo Oliveira et al. (2016), Su et al. (2016) e Ayoola et al. (2018).

Wadhwa et al. (2015) propõem uma arquitetura baseada na publicação e assinatura moderada por meio de um Web Service para apoiar a troca de dados da Saúde pública. Esse trabalho aponta alguns desafios, como a natureza heterogênea dos diferentes siste-mas, a escalabilidade necessária para o intercâmbio de dados na Saúde pública, bem como a segurança e a privacidade na troca de informações. A arquitetura proposta não define a tecnologia usada no componente de autorização ou autenticação, mas determina o uso do formato XML para o armazenamento de dados. Como trabalho futuro, planeja-se implan-tar a solução em uma situação do mundo real e usar os bancos de dados mais difundidos, como Mysql, Postgres e Oracle.

de Araújo Oliveira et al. (2016) apresentam o Sistema Single Sign-On da Universidade Aberta do Sistema Único de Saúde (UNA-SUS), com foco na integração de diferentes am-bientes virtuais de aprendizagem (AVAs) e com suporte à SSO. A solução agrega dados descentralizados de diferentes instituições de ensino no Brasil e coleta dados dos bancos de dados públicos, como o Cadastro Nacional de Estabelecimentos de Saúde (CNES), a Comissão Nacional de Residência Médica (CNRM) e o Conselho Federal de Medicina (CFM). Nessa solução, foi utilizado o protocolo Secure Sockets Layer (SSL) e Web Servi-ces Simple AcServi-cess Object Protocol (SOAP) com o formato Extensible Markup Language (XML) para intercâmbio de dados. Observamos que a solução proposta nesse trabalho implementa a autenticação e a autorização com o protocolo Security Assertion Markup

(39)

CAPÍTULO 3. TRABALHOS RELACIONADOS 25

Language (SAML), no qual não há consentimento expresso do usuário para o sistema coletar e usar os seus dados (Naik e Jenkins 2017).

Su et al. (2016) veiculam o Privacy as a Service, uma arquitetura centrada na privaci-dade do usuário, habilitando o consentimento deste como um serviço com os princípios da General Data Protection Law (GDPR). Ele implementa a Web Services RESTful com formato JSON e fornece autorização por meio do User-Managed Access (UMA), que é baseado no Framework OAuth. O trabalho se revela como uma solução robusta como um FRM, com um engenhoso sistema de segurança de dados e descritores semânticos para fornecer interoperabilidade. No entanto, garantir uma identidade federada parece estar fora do escopo do trabalho. Além disso, Single Sign-On não é mencionado.

Ayoola et al. (2018) anunciam a Do CHANGE Platform, que tem como objetivo agre-gar e distribuir dados de acordo com a legislação europeia de proteção. Ela foi original-mente desenvolvida como parte de uma pesquisa com pacientes cardíacos para ajudá-los a gerenciar suas condições de Saúde, mas, segundo os autores, foi empregada também para várias outras aplicações, como uso clínico, análise de dados e aplicativos móveis. A pla-taforma é implementada utilizando as tecnologias NodeJS e MongoDB, usa o serviço de terceiros Auth0 como um provedor de identidade federada (com suporte a SSO) e aplica o OAuth para autorização por SSL e RESTful Web Services. Trabalhos futuros apontam para o desenvolvimento de um FRM que permitirá aos usuários controlar o acesso aos dados no ecossistema.

3.1 Análise comparativa

Considerando os quatro trabalhos selecionados, observa-se uma forte relação com os temas abordados nesta tese. A Tabela 3.1 demonstra as principais características utilizadas para comparar os estudos relacionados com o desenvolvido aqui.