5.1 Conceptual Model of the Reference Architecture (RA)

With the essential actors and roles necessary to describe accountability relationships identified, the building blocks of the RA model can now be examined. Again, emphasising the importance of building upon established and standardised concepts instead of “re-inventing the wheel”, we base the RA conceptual model on the corresponding NIST cloud reference architecture conceptual model [5]. Figure 21 below illustrates how the RA adapts and extends the NIST cloud reference architecture to support accountability.

Figure 21: A4Cloud reference architecture conceptual model.

Our amendments to the NIST RA can be organised into three different classes:

• Actors: the focus on accountability for data protection has led us to add two actors those identified by NIST: the cloud subject and the cloud supervisory authority (refer to section 2.1 for details).
• Architectural Components: We have introduced a third cross-cutting aspect of the architecture: accountability. We have elected to add accountability as a separate aspect as it is not restricted to any particular cross-cutting aspect already identified. Indeed, cloud providers are typically held accountable for performance and availability, security, and data protection, making accountability cross-cutting other cross-cutting concerns. The NIST diagram does not show explicitly the security and privacy aspects for the cloud broker. We believe NIST did not intend to exclude these aspects for that actor and have consequently introduced these aspects alongside accountability as concerns, mirroring what is done for the cloud service provider.
• Stakeholder Functions: Actors perform selective functions corresponding to their roles in the cloud ecosystem. NIST lists a few such functions for cloud auditors; we have identified the key accountability functions for the various actors acting as accountees.  More specifically:
• Cloud Auditors: as part of their audit responsibilities, cloud auditors perform the verification of the accountability claims of accountors (cloud service providers and cloud brokers in this architecture). The auditors are also in charge of evaluating compliance to certification and attestation schemes related to accountability, such as ISO 27001, SOX2, or CSA STAR Certification.
• Cloud Customers: before using cloud services, cloud customers go through a selection and agreement process during which they select a suitable CSP for their needs. The also assess the suitability of the CSP to their needs based on the accountability information provided.
• Cloud Subjects: in regards to data protection, the relationship between the data (cloud) subject and the data controller (cloud service customer or provider, depending on the solution architecture) goes beyond one where the customer provides statically requirements up-front; accountability principles recognise the importance of the dialogue (under the form of an individual participation) between the data subject and the data controller, where the data subject has the ability to issue queries to the data processor, requesting explanations and clarification of how its data is protected, and with the ability to clarify its requirements in terms of data handling requirements.
• Cloud Supervisory Authority: in the context of data protection regulations, the DPA has the ability to verify, investigate, and to issue sanctions against data controller and processors when they are not in compliance with the regulations.
• Cloud Brokers: the NIST RA identifies a variety of services provided by the Cloud Broker. In its role as an intermediate between the Cloud Customer and the CSP, the broker must assess how accountable the CSP is to its accountees.

In the remainder of this section we will focus on the account part of the architecture. We start by describing a service-oriented approach for accountability which enhances cross-domain interactions between the architecture components. We then list a set of capabilities that need to be implemented to achieve accountability. These capabilities (e.g., policy definition, incident management) could be viewed as autonomous building blocks that interact with each other to perform common goals.