Project topics and materials
Get Complete Project Material File(s) Now! »
Consistency between consultation and modification
This section treats the second step of our approach. It handles the consistency between the ‘select’ and ‘update’ operators. This treatment is done only by analysing the quantification portion of the update query. Let u be a user and IConfu (resp. IIntegu) be the set of elements that the user u is permitted to select (resp. to update). In general, in the case of the select operator, the result of the query must be a subset of IConfu (Figure 4.1 (A)) in order to preserve confidentiality. Similarly for the update operator, the modified data must be a subset of IIntegu in order to preserve the integrity (Figure 4.1 (B)). As shown in the motivating example, these two rules are not sufficient to preserve confidentiality when the user has both authorizations to select and authorizations to update. In other words, the user can update an element x in IConfu ∩ IIntegu using reference to an element y of IConfu = E \IConfu in order to deduce the value of y associated with x, which he is not allowed to see. There are two cases: IConfu ∩ IIntegu = ∅, (2)IConfu ∩ IIntegu 6= ∅. It is obvious that in the first case (1), there is no such problem. However, in the current SQL implementation, we still have another kind of problem of confidentiality. For exemple, in our motivating example, if we suppose that the user Alice is allowed only to select names and cities of employees and she is allowed to update only their salaries. This corresponds to the case (1). Alice updates the salary of employees who earn exactly 45000 using the folowing SQL query: SQL> UPDATE Employee SET salary=salary+100 WHERE salary=45 000; 2 rows updated Although, Alice is not permitted to see the salary of employees, she has been able to learn, through this update command, that there are two employees with a salary 45000. This would correspond to a write down prohibited by the Bell-LaPadula model [76]. To solve it, we have just to delete the information message (number of rows that has been updated).
Now let us assume that IConfu ∩ IIntegu 6= ∅. Let x ∈ IConfu ∩ IIntegu, we denote IRef (x) a subset of elements of IConfu that are in relation with x, i.e IRef (x) = {y ∈ IConfu |∃R, a binary relation over E such that xRy}. If IRef (x) is not empty, then we can deduce the value of each element of IRef (x). We simply update the value of x using elements of IRef (x) in the where clause of our query. So, our problem is equivalent to the following proposition: [(∃x ∈ IConfu ∩ IIntegu)|IRef (x) 6= ∅] → [Interf erence(select, update)] (4.4) Interf erence(select, update) means that there exists an interference between select and update operators. To solve this problem, we must control WQuery (the where clause of the query) to avoid referencing a value that is not in IConfu . There are two cases:
Let ω be a condition of RDF triples. We assume that a user u is not allowed to see (select) values of predicates {pi}1≤i≤n where n ∈ N∗, if the condition ω is satisfied. Let Spredu be a set of all possible triples of E where predicates are elements of {pi}1≤i≤n. Since we are in the case of prohibition, so, IConfu = Spredu ∩ I(ω). If the WQuery of the update query uses at least one predicate of the set {pi}1≤i≤n, then the condition ω should not be satisfied in order to enforce the security policy. In other words we have to introduce the negative filter of ω in WQuery. This is equivalent to: [(∃p ∈ WQuery)|p ∈ {pi}1≤i≤n] → Filter(WQuery,ω(xp)) (4.5).
RDF condition as view and context
In section 5.4.1 we present how to model RDF conditions as context. In section 5.4.2 we present how to model simple condition as view. We explain also that some complex conditions could not be represented as views. In the rest of this chapter we assume that a complex condition is only expressed as context. However, simple condition could be expressed as context and/or as view. For instance, if we consider the RDF condition ω = ωsimple ∧ ωcomplex presented in the example 19. ω could be expressed with the two following OrBAC rules:
Rule1 : P ermission(org, Secretary, Read, V iewN ame, Cωcomplex ).
Rule2 : P ermission(org, Secretary, Read, Vωsalary , Cωcomplex ).
In that case we are modeling a complex condition as a context and simple condition as a view.
Rewriting Query Instrumented by OrBAC rules
In this section we present how to instrument a rewriting algoritm (fQuery) using security rules based on the OrBAC model [81]. In our case we only have two actions ‘read’ and ‘write’. The read action corresponds to SELECT query and the write action corresponds to UPDATE query. For a given SPARQL query, the subject s is the requestor. The action α corresponds to the query type. For instance, action ‘read’ for SELECT query and action ‘write’ for UPDATE query. Views can be retrieved by analyzing the clause WHERE of the query. It corresponds to the concepts and/or properties of a given concept that are queried. Each property pi of the where clause, corresponds to the view Vωpi . We define a new predicate When_permitted which allows us to get view definitions and context definitions corresponding to a given subject s, action α and view V . When_permitted is a predicate over domains OrgxSxAxV xDefxDef defined as follows: W hen_permitted(org, s, α, V, DCtx, DV iew) ← Empower(org, s, R).
Table of contents :
1 Introduction
1.1 Motivation and background
1.2 Contributions
1.3 Outline of the dissertation
2 Preliminaries and State of the Art
2.1 Background
2.1.1 RDF
2.1.2 OWL
2.1.3 SPARQL
2.1.4 SPARQL/Update
2.2 Semantic Mediation
2.3 Security enforcement for mediators
2.4 Security of query evaluation
2.4.1 View-based approach
2.4.2 Pre-processing approach
2.4.3 Post-processing approach
3 SPARQL Select Query Rewriting to Enforce Data Confidentiality
3.1 Introduction
3.2 Rewriting SPARQL Query: Basic Principles
3.3 Notations, Definitions and Theorems
3.4 Security policy
3.4.1 Permission
3.4.2 Prohibition
3.5 fQuery: Our query rewriting model
3.5.1 Case of simple condition !
3.5.2 Case of involved condition !
3.5.3 Case of complex condition !
3.5.4 Composition of simple and involved conditions
3.6 Conclusion and Contribution
4 Rewriting of SPARQL/Update Queries for Securing Data access
4.1 Introduction
4.2 Motivating example
4.3 Principle of our approach
4.3.1 Update access control
4.3.2 Consistency between consultation and modification
4.4 Conclusion and Contribution
5 SPARQL Query Rewriting Instrumented by an Access Control Model
5.1 Introduction
5.2 The OrBAC model
5.2.1 Basic predicates
5.2.2 Role, activity and view definition
5.2.3 Context definition
5.2.4 Hierarchy and inheritance
5.3 Principle of the approach
5.4 Modelling RDF Condition within OrBAC
5.4.1 RDF condition as context
5.4.2 RDF condition as view
5.4.3 RDF condition as view and context
5.5 Rewriting Query Instrumented by OrBAC rules
5.6 Conclusion
6 Privacy policy preferences enforced by SPARQL Query Rewriting
6.1 Introduction
6.2 Approach principle
6.3 Privacy-aware Ontology
6.4 The correctness criteria
6.5 Rewriting Algorithm principle
6.5.1 Normalization of triple patterns
6.5.2 Preferences acquisition
6.5.3 Preferences enforcement
6.5.4 SPARQL query without filter
6.5.5 SPARQL query with filters
6.6 Conclusion
7 Privacy query rewriting algorithm instrumented by a privacy-aware access control model
7.1 Introduction
7.2 The privacy-aware OrBAC model (PrivOrBAC)
7.2.1 Consent
7.2.2 Purpose
7.2.3 Accuracy
7.3 Our approach: PrivOrBAC query rewriting algorithm
7.3.1 PrivOrBAC services
7.3.2 PrivOrBAC SPARQL Service
7.4 Conclusion
8 Secure and Privacy-preserving Execution Model for Data Services
8.1 Introduction
8.1.1 Motivating Scenario
8.1.2 Challenges
8.1.3 Contributions
8.2 A Secure and Privacy-Preserving Execution Model for Data Services .
8.2.1 Model Overview
8.2.2 Semantic models for data services and policies
8.2.3 RDF views rewriting to integrate security and privacy constraints
8.2.4 Rewriting the extended view in terms of data services .
8.2.5 Enforcing security and privacy constraints
8.3 Conclusion and Perspectives
9 Architectures and Implementations
9.1 Implementation of fQuery
9.1.1 MotOrBAC tool
9.1.2 Implementation of fQuery-AC
9.1.3 Implementation of fQuery-Privacy
9.2 Performance of fQuery-Privacy instrumented by PrivOrBAC
9.2.1 Architecture
9.2.2 Use case
9.2.3 Experimental results
9.3 Performance of Secure and Privacy-preserving Execution Model for Data Services
9.3.1 Implementation
9.3.2 Evaluation
9.4 Use cases
9.4.1 AGGREGO Server
9.4.2 PAIRSE
10 Conclusion and perspectives
A fQuery: réécriture de requêtes SPARQL
A.1 Introduction
A.2 Généralités
A.3 fQuery-AC: Principe de base
A.4 fQuery-Privacy: Principe de base
A.5 Le cas des services de données
A.6 Implémentation
B Proof of theorem 3 chapter 3
C fQuery-AC Aspect
D fQuery-AC Visitor
List of Publications
Bibliography
