Avalia¸ c˜ ao dos resultados obtidos

Na subse¸c˜ao 3.3.1, foi apresentado o modelo para obter a informa¸c˜ao pass´ıvel de ser inferida atrav´es das queries j´a executadas por um utilizador. Nesta subse¸c˜ao ser´a descrito o modelo de

avalia¸c˜ao, recorrendo `a informa¸c˜ao supramencionada. Esta solu¸c˜ao avalia os valores obtidos dos atributos sens´ıveis de predicado no contexto das cl´ausulas where das respetivas qill.

Posto isto, conv´em definir os tipos de resultados que podem surgir da subse¸c˜ao 3.3.1. Os resultados provenientes dos caminhos obtidos atrav´es da proje¸c˜ao do esquema de atributos inquiridos em m´ultiplas queries, ou seja, quando se obtˆem valores de atributos efetivos, podem ser divididos em duas categorias:

• no conjunto de valores obtidos, todos est˜ao associados ao tuplo sens´ıvel que se est´a a avaliar, tal como ´e apresentado no exemplo definido na listagem 3.5;

• no conjunto de valores obtidos, nem todos est˜ao associados ao tuplo sens´ıvel que se est´a a avaliar, tal como ´e apresentado no exemplo definido na listagem 3.6.

Tipicamente, o primeiro caso ocorre quando os atributos projetados entre as queries que formam o caminho, correspondem `as chaves das tabelas atravessadas. Em contrapartida, quando as proje¸c˜oes dos atributos entre as queries que formam o caminho correspondem a atributos comuns, os resultados obtidos podem n˜ao estar todos associados ao tuplo sens´ıvel. Tal como na l´ogica booleana [60], pode-se considerar que a express˜ao A∧B ´e verdadeira quando ambos os valores de A e B s˜ao verdadeiros, enquanto que na express˜ao C ∨ D, basta que apenas um dos acontecimentos C ou D seja verdadeiro para que a express˜ao tamb´em o seja.

Analogamente, quando se avalia um conjunto de valores que s˜ao todos associados ao tuplo sens´ıvel, basta que apenas um seja v´alido no contexto da cl´ausula where para que se possa concluir que o mesmo ´e v´alido.

Por outro lado, se nem todos os valores obtidos forem associados ao tuplo sens´ıvel, para considerar que o tuplo sens´ıvel ´e v´alido no contexto de qill, todas as combina¸c˜oes de valores

tˆem que o ser. No exemplo definido na listagem 3.11, consegue-se inferir que o empregado idenficado por (EmployeeID = 1), corresponde a um tuplo sens´ıvel protegido pois o Resultado (RS) de {C1.3 - C2.3} = {3119.15, 2954.55}. Os poss´ıveis valores de Salary associados ao

respetivo tuplo s˜ao ambos v´alidos no ˆambito da cl´ausula where de qill1 (Salary >= 2500).

Adicionalmente, tal como apresentado na se¸c˜ao 3.3.1, ´e poss´ıvel inferir informa¸c˜ao atrav´es da cl´ausula where das queries executadas. Seja Rill a restri¸c˜ao da cl´ausula where de qill e Ri

a restri¸c˜ao da cl´ausula where de qi.

Perante este cen´ario, ´e poss´ıvel inferir que um tuplo sens´ıvel ´e protegido quando se associ´a- lo ao tuplo retornado por uma query qi, cuja Ri ⊂ Rill. Considere-se que Rill = {Salary >

2000} e Ri= {Salary > 2500}. Se se conseguir associar o tuplo sens´ıvel a um tuplo retornado

por qi, pode-se concluir que o tuplo est´a associado a (Salary > 2500 > 2000).

Alternativamente, considera-se que um tuplo sens´ıvel ´e n˜ao protegido quando n˜ao est´a associado a nenhum tuplo retornado por uma query qi, cuja Rill ⊂ Ri. Considere-se que

Rill = {Salary > 2500} e Ri = {Salary > 2000}. Se o tuplo sens´ıvel n˜ao estiver associado

a nenhum tuplo retornado por qi, pode-se concluir que o tuplo est´a associado a (Salary <=

Prova de Conceito

Neste cap´ıtulo ser´a descrita a implementa¸c˜ao da solu¸c˜ao apresentada no cap´ıtulo 3. De fato, tal como se pode adivinhar atrav´es da leitura do respetivo capitulo, foi implementada parcialmente uma primeira solu¸c˜ao, recorrendo ao paradigma de grafos e, na segunda, recor- rendo ao paradigma de hipergrafos, que corresponde a uma evolu¸c˜ao natural da solu¸c˜ao ao problema proposto.

Come¸car-se-´a por apresentar a arquitetura geral da solu¸c˜ao desenvolvida na se¸c˜ao 4.1. De seguida descrever-se-´a a implementa¸c˜ao dos componentes principais desta solu¸c˜ao.

• A se¸c˜ao 4.2 apresenta o Desenvolvimento do Orchestrator;

• A se¸c˜ao 4.3 apresenta o Desenvolvimento do Schema Interpreter; • A se¸c˜ao 4.4 apresenta o Desenvolvimento do Query Interpreter; • A se¸c˜ao 4.5 apresenta o Desenvolvimento do Query Executor; • A se¸c˜ao 4.6 apresenta o Gestor de Pol´ıticas;

• A se¸c˜ao 4.7 apresenta o Desenvolvimento do Evaluator.

Por fim ser´a explicada a forma como ´e poss´ıvel a um administrador de sistemas utilizar a plataforma desenvolvida no ˆambito desta disserta¸c˜ao, na se¸c˜ao 4.8 e em 4.9 ser´a definido o caso de uso com o qual se pretende avaliar o trabalho desenvolvido e discutidos alguns dos resultados obtidos nesse contexto.

No ˆambito do desenvolvimento desta solu¸c˜ao foi necess´aria a cria¸c˜ao de estruturas auxi- liares. No Anexo C s˜ao apresentadas as unidades b´asicas de armazenamento de informa¸c˜ao. Nele ´e explicada a importˆancia das mesmas e as opera¸c˜oes que se podem realizar ao n´ıvel de cada uma.

4.1

Arquitetura Geral

A figura 4.1 apresenta a arquitetura da solu¸c˜ao desenvolvida no ˆambito desta disserta¸c˜ao. O Orchestrator corresponde ao componente desta solu¸c˜ao que serve de interface para aplica¸c˜oes terceiras que a pretendam utilizar. No ˆambito da execu¸c˜ao de uma query, este

Figura 4.1: Arquitetura PFPE

componente ´e respons´avel por (1) process´a-la recorrendo ao Query Interpreter, (2) execut´a- la recorrendo ao Query Executor e, por fim, (3) avaliar se a informa¸c˜ao pass´ıvel de ser inferida coloca um utilizador malicioso em posi¸c˜ao quebrar as pol´ıticas de controlo de acesso probabil´ısticas definidas recorrendo ao Evaluator.

No ˆambito do processo de interpreta¸c˜ao de queries, realizado em Query Interpreter, ´e obtida uma instˆancia da estrutura do tipo de dados Query ( desenvolvida nesta disserta¸c˜ao) que armazena os atributos e tabelas inquiridos bem como o contexto em que os respetivos valores ser˜ao obtidos ( tipicamente obtido atrav´es da cl´ausula where da mesma). Este com- ponente recorre ao Schema Interpreter de forma a conseguir perceber quais os atributos e as tabelas presentes nas declara¸c˜oes SQL submetidas pelo programador da aplica¸c˜ao. Neste contexto, pode ocorrer o caso de ser necess´ario uma transforma¸c˜ao adicional dependendo dos atributos inquiridos pela query e dos atributos que n˜ao devem ser utilizador no ˆambito do processo de avalia¸c˜ao, apresentados na subse¸c˜ao 3.1.2, e que se encontram armazenados em Policy Server. Este componente al´em de armazenar este conjunto de atributos, armazena tamb´em as pol´ıticas de controlo de acesso probabil´ısticas.

Tal como j´a referido, o Query Executor ´e respons´avel pela execu¸c˜ao das queries sub- metidas e o respetivo armazenamento em Database aux, sob a forma apresentada na se¸c˜ao 3.2.

Relativamente ao processo de avalia¸c˜ao, realizado pelo componente Evaluator, ´e verifi- cado para cada tuplo sens´ıvel de cada pol´ıtica de controlo de acesso probabil´ıstica estabelecida se um utilizador malicioso, atrav´es da informa¸c˜ao j´a obtida ( armazenada em Database aux) consegue violar as pol´ıticas supramencionadas. No ˆambito deste processo ´e produzido um re- lat´orio que especifica atrav´es de quais queries e t´ecnicas de inferˆencia um utilizador consegue inferir informa¸c˜ao dos atributos sens´ıveis de predicado associados a cada tuplo sens´ıvel.