During the 7th International Workshop in Data Privacy Management, that will take place in Pisa, on September 13-14, 2012, I will be presenting a paper entitled "Automating Privacy Enforcement in Cloud Platforms", written in collaboration with Peng Yu, gabriel.serme and anderson.santanadeoliveira. You can find below the abstract as well as summary of the solution described in the paper.
Abstract
Privacy in cloud computing is a major concern for individuals, governments, service and platform providers. In this context, the compliance with regards to policies and regulations about personal data protection is essential, but hard to achieve, as the implementation of privacy controls is subject to diverse kinds of errors. In this paper we present how the enforcement of privacy policies can be facilitated by a Platform as a Service. Cloud applications developers can use non-obtrusive annotations in the code to indicate where personally identifiable information is being handled, leveraging the aspect-oriented programming (AOP) features. Subsequently the evaluation of user defined preferences is performed by trustful components provided by the platform, liberating developers from the burden of designing custom mechanisms for privacy enforcement in their software.
Scenario
In our scenario we focused on Platform as a Service cloud. Typically in such model developers are given the possibility to deploy application in the cloud infrastructure without worrying about application servers. Also additional services, e.g. database access, are managed by cloud platform, so there is no need for managing database connection by application itself. In our proof of concept we experimented with SAP NetWeaver Cloud. The interface between application and database in case of this platform is JPA or JDBC.
The use case we have chosen focuses on shopping application that collects user shopping list and shopping history, regarding previous visits to supermarket chain. User has a possibility to modify preferences regarding which items on his shopping list (according to product category) will be shared for further processing (e.g. business analytics, marketing). The back office interface for Business Users enables querying the information collected by the shopping application and performing different set of analytics on this data. As shopping history is linked to the user, we relate to it as Personally Identifiable Information (PII) which we consider as private user information that he would like to restrict access to.
To record the privacy choices of the user we used PPL (Privacy Policy for Life) language coming from the previous research project we were doing. It is based on XACML – eXtensible Access Control Markup Language and enriched with data usage elements, like purpose, and Third Party usage. Here is the example of how purposes for which user would like to share his private information are stored in the policy file:
<ppl:DataHandlingPreferences>
<ppl:AuthorizationsSet>
<ppl:AuthzUseForPurpose>
<ppl:Purpose>http://www.w3.org/2002/01/P3Pv1/individual-analysis</ppl:Purpose>
<ppl:Purpose>http://www.w3.org/2002/01/P3Pv1/admin</ppl:Purpose>
<ppl:Purpose>http://www.w3.org/2002/01/P3Pv1/contact</ppl:Purpose>
</ppl:AuthzUseForPurpose>
<ppl:AuthzDownstreamUsage allowed="false"/>
..
</ppl:AuthorizationsSet>
</ppl:DataHandlingPreferences>
Aspect-Oriented Programming Principle in Handling Private Information
Usually the application code handling privacy related data is scattered and tangled all over the application, being difficult to handle and to maintain if any changes in the privacy policy are introduced. As we observed in the existing applications the operations, which are performed on the private user data to ensure that privacy policies are enforced, are typically cross-cutting concerns in aspect-oriented programming paradigm.
Inspired by this, we designed a process for the application developer that contributes to simplifying a way the data protection compliance could be achieved. It consists of adding meta-information to the application code via Java annotation mechanism in the JPA entity classes. Entity class in JPA terms is the one that is mapped into a database structure (usually a table, but also more complex type of mappings exist, e.g. to map object inheritance hierarchy) and enables the objects of that class to be persisted in a database. We provide also a second type of annotations, for the methods that make use of a private data, to indicate the purpose of the data usage.
The modifications to the code are non-intrusive, in the sense that the application business functions flow will stay exactly the same as before, except for the data set it will operate on, that will be obtained from database by adhering to the privacy policy. We developed simple annotation library for Java which consists of three annotations:
- @PII
indicates that JPA entity class should be considered as personally identifiable information. Here is the example of usage inside our use-case shopping application:
import javax.persistence.Entity;
import com.sap.cessa.annotations.PII;
..
@Entity
@PII
public class ShoppingHistory implements Serializable {
..
private Consumer consumer;
private Product product;
..
}
- @PiiAccessClass
this annotation is put in the class to indicate that it contains methods accessing personal data (so the objects of the class annotated with @PII annotation).
- @Info
applied to PII access method, it describes the purpose or set of purposes of the query performed in that method.
Another code snippet shows how the two above annotation are used in ShoppingHistoryDAO class to indicate that it accesses private information - user's shopping history - for marketing purpose. This is done by getHistory() method. Here is the code:
import com.sap.cessa.annotations.Info;
import com.sap.cessa.annotations.PiiAccessClass;
..
@PiiAccessClass
public class ShoppingHistoryDAO extends DaoImpl<ShoppingHistory> {
..
@Info(purpose="http://www.w3.org/2006/01/P3Pv11/marketing")
public final List<ShoppingHistory> getHistory() {
..
}
..
}
Enforcement Mechanism
Both the code annotations supporting privacy enforcement as well as the user privacy preferences represented in form of the policy are combined in our proposed solution. To enable processing of the annotations and policies we implemented the following components:
- Annotation Detector, which scans Java classes at the deployment time and looks for the JPA entities that are containing privacy-related annotation in its definition (@PII, @PiiAccessClass).
- Policy Handler, which analyses user's privacy choices and by linking it with purposes information recorded in the policy, feeds the database that stores these information in the form that can be used for the enforcement.
Actual enforcement mechanism implemented in our proof of concept was inspired by query modification techniques. It consists in two components:
- JDBC Wrapper, that intercepts all queries issued by the cloud application when it consumes the collected data containing shopping history of the users. This component is provided on the platform as an alternative to the default JDBC driver in order to enforce users' privacy preferences.
- SQL Filter, which rewrites original queries issued to the database by replacing the requested data set with a projection of that data set taking into account privacy preferences.
When application is accessing data from the SHOPPING HISTORY table, original query is transformed so that it takes into account the information derived from privacy policy that was put by the Policy Handler in the CONSUMER CONSENT table. This table stores the association between the consumers and the different product categories about which these consumers opted to reveal their shopping history. Modified query yields the data set of the same structure as original query but without disclosing the information that consumers declined to share, omitting the rows that contain shopping history related to products categories that user didn't give his consent, as it can be seen in the RESULT table.
Although modified query looks much more complex than the original (as it contains few additional SQL join statements) we didn't observe in our experiments much decrease in the application performance.
Solution presented here leverages Aspect-Oriented Programming paradigm thus increasing the code readability and maintainability. Furthermore, it simplifies developers work by providing the enforcement mechanism directly as a cloud platform components, decreasing the efforts concerning preparation of custom implementation. Of course there is still a need to prepare privacy policy in expected format, correctly indicate the private information in the data model using the annotations and leave the placeholders for consumer opt-in/opt-out choices in data model, that can be linked to the policy.
The additional tools, e.g. automated code scanners helping developers to identify where private information is used and suggest purposes according to the type of processing performed on data, could be prepared to further automate the solution. Those features could also be used to provide validation and certification of the application. Currently our assumption is that it's the application provider who is willing to be compliant and thus will correctly indicate where and how private information is processed.
This work was supported by the CESSA Project - Compositional Evolution of Secure Software with Aspects - grant number 09-SEGI-002-01 - from the French National Research Agency (ANR). Many thanks to theodoor.scholte for his valuable comments on a previous version of this paper.
- SAP Managed Tags:
