M. Azraoui, M. Önen, R. Molva, “Framework for Searchable Encryption with SQL Databases”, Conference CLOSER 2018, 19-21 March 2018, Medeira, Portugal. [Conference website http://closer.scitevents.org/]
CLARUS modules integration
The main objective of building the CLARUS proxy is to secure sensitive data to be stored in the cloud and process them in a performing way.
For this reason the CLARUS proxy has been implemented as a main process with a three plugin architecture compiled as java JARs as shown below:
- Protocol plugins: The communication between the client application and the CSP (storing and manipulating sensitive data) relies natively on a dedicated protocol or list of protocols. These protocols should be added as plugins to manage the client application requests and the CSP responses. The data communicated using the proxy will be modified/obfuscated but will rely always on the native protocols supported by the client application and CSP. In this case, we ensure the transparency of the Proxy mainly from the end-user point of view. Natively the TCP protocol is supported by the CLARUS proxy which facilitates the integration of protocols on top of it.
- Data protection plugins: The CLARUS proxy proposes different protection mechanisms for sensitive data. These mechanisms depend generally on the client application requirements in terms of data security and privacy. Different plugins are already implemented or under implementation in the context of CLARUS project. This is the case for the following list: simple encryption, searchable encryption, homomorphic encryption, anonymization, splitting, verifiable keyword search.
- Authentication plugin: In the current state of the implementation, only LDAP (Lightweight Directory Access Protocol) is implemented as a plugin. This is because it is one of the most common methods to authenticate users in a company network and it is easy to connect to this authentication and identification service. Other authentication methods can be added for future developments.
One other process must run in the same host (physical or virtual host) as the CLARUS proxy process. It is the administration process implemented as a command line utility namely clarus-adm. It allows:
- configuring the repository used by the CLARUS proxy for the access rights management
- configuring the user authentication module
- configuring the Cloud Service Providers
o to register a Cloud Service Provider (CSP)
o delete a CSP
o update a CSP configuration
o enable or disable a CSP
o configuring the failover mode
o configuring the deployment of modules o registering a new module
o deleting a module
o updating a module
Two other separate processes should be deployed in the same host as the CLARUS proxy process. But this is not mandatory to have them co-located. These modules are:
- The policy manager module (named clarus-spm) that defines the CLARUS security policies, i.e. what to protect in the outsourced datasets and how to protect it. The output of this program is a JSON file needed by the CLARUS main process to configure itself.
- The access control policy manager (named clarus-arm) that manages the access right to different authenticated proxy users. This manager defines the access rights of the users on the storage/processing services protected by CLARUS. It also defines the permissions of the users on the outsourced datasets.
Finally, the monitoring module is defined as a standalone module that can run on the same proxy host as a separate process or a virtual machine in this host or on any standalone (physical or virtual) host. The whole integration is performed in a platform provided by Thales.