It is difficult for customers to select the adequate cloud providers which fit their needs, as the number of cloud offerings increases rapidly. Many works thus focus on the design of cloud brokers. Unfortunately, most of them do not consider precise security requirements of customers. In this paper, we propose a methodology defined to place services in a multi-provider cloud environment, based on functional and non-functional requirements, including security requirements. To eliminate inner conflicts within customers requirements, and to match the cloud providers offers with these customers requirements, we use a formal analysis tool: Alloy. The broker uses a matching algorithm to place the required services in the adequate cloud providers, in a way that fulfills all customer requirements. We finally present a prototype implementation of the proposed broker.

Current Cloud Service Level Agreements (SLAs) do not cover security requirements. Some consortiums have proposed standards for the evaluation of security offered by the Cloud Providers (CP). Cloud Brokers (CB) can then generate Security Level Agreement (SecLA) contracts between customers and providers to fit users' requirements. However, the SecLAs do not provide enough details for complex customers' situations, such as sharing resources with other users/companies, or set up specific Access Controls and Security Properties (ACSP). In this paper, we tackle this issue, by introducing a general Requirement Specification Language (ACSP-RSL) to allow the customers to express their needs in term of ACSP. The underlying formal model, on which is based RSL, is partially presented. The global SecLA definition and negotiation process is thus extended with our proposal. RSL indeed also allows to express Security Requirements currently existing in SecLAs. The negotiation phase between CB and the CPs is discussed. We show how the RSL specifications expressed by the customer can be projected into a generic detection/protection policy expressed as an extension of RSL. A complete use-case for a healthcare system with multitenancy for users and services deployed is given. Its security requirements are analyzed, modeled, expressed and discussed.