Diploma Thesis Santiago Gómez Sáez - IAAS

4.2. Multi-tenancy
Communication in, and from the ESB must be multi-tenant aware. We divide the required
isolation between tenants into the following sub-requirements:
• Tenant-aware messaging: messages received in the ESB and routed between the tenantaware
endpoints should be enriched with tenant and user information.
• Tenant-aware endpoints: in ServiceMix-mt tenants pack a common endpoint configuration
packed in a SU, which is then deployed as a SA in ServiceMix-mt’s JBI container
[Sá12]. The multi-tenant aware BC dynamically modify the endpoint’s URL by injecting
tenant context in it. In a database system in our scenario we do not have only tenants as
the main actors, but also the different users which can access a tenant’s database. Therefore,
the tenant-aware endpoints should be dynamically created by injecting tenant and
user information in the endpoint’s URL. Furthermore, we must ensure tenant and user
authentication in the system.
• Tenant-aware routing and context: the deployment of tenant-aware endpoints should
be followed by the creation of a tenant-aware context. Resources involved in a routing
operation from one consumer endpoint to one provider endpoint can be shared between
different tenants, but they must manage the routing operations in different tenant-aware
contexts. The routing operations between two endpoints must identity the tenant and
user who initiated the routing.
• Tenant configuration isolation: configuration data persisted in our system should be
isolated between tenants. A tenant’s endpoint configuration data contains sensible
information which identifies and allows access to the tenant’s backend data stores.
• Tenant-aware correlation: in a request-response operations, the response obtained from
the backend data store must be correlated with the tenant’s request to the system, and
ensure that one tenant does not receive responses from another tenant’s request.
4.2.2. Storage Requirements
Due to the fact that our system does not primarily requires multi-tenant aware storage
support, but we rely on multi-tenant aware storage systems in the Cloud, we summarize the
main requirements for isolating data between tenants in database systems.
Curino et al. identify as a primary requirement for a Cloud provider offering a DBaaS model
security and privacy [CJZ + 10]. A system running multiple database servers and each server
multiple database instances must contain the necessary meta-data to provide tenant-aware
routing in the system, and ensure that one tenant can only access the information in his
database instance. Furthermore, privacy of stored data between tenants can be ensure by
encrypting all tuples [CJP + 11]. Curino et al. introduce CryptDB, a subsystem of a relational
Cloud which provide data encryption and unencryption functionalities for persisting data,
and for accessing data via SQL queries which are not aware of the encrypted storage mechanism
in the system. However, it is known that the key challenge in managing encrypted data
in the Cloud is doing it efficiently.
39