5.3.1 Integration Patterns

In this section, we introduce the concept of integration patterns for accountability, which is inspired by the existing attempts of several software vendors and IT system and solution providers to provide some common ways to facilitate integration in multi-scaled and multi-oriented systems. From an accountability perspective, the integration patterns refer to the interaction of the accountability mechanisms with each other and with the external world. By saying so, we emphasise the need for interoperability among the different layers of a cloud ecosystem in order to achieve accountability, as this is described in the four phases, namely agreement, reporting, demonstration and remediation. The integration patterns may go beyond the strict boundaries of the technical details of an accountability solution and analyse the integration requirements along processes (or even other non-technical mechanisms, such as legal contracts) as well.

In the context of the A4Cloud Reference Architecture, we will introduce the following integration patterns:

• Agreement patterns: this family of patterns analyses the integration patterns to serve the agreement practices of the Accountability Framework and involve:
  • Capability pattern: this pattern integrates the way that the different cloud providers can advertise their offerings, by describing their function, security and privacy provisions to their clients in a structured template.
  • Policy specification pattern: this pattern integrates the various types of data handling procedures that reflect the accountability dimensions of a data protection problem (for example, the specification of data access, data retention or data transfer rules).
  • Policy enforcement pattern: this pattern describes the common functions for a policy decision point.
• Reporting patterns
  • Metrics pattern: this is a pattern to maintain a certain level of conformance along the cloud providers on the appropriate assessment of the environment state. This pattern needs more investigation in the sense that it should be considered from two different perspectives: i) a pattern on metrics description for monitoring, and ii) a pattern on assembling individual metrics patterns for assessing the state of a provider in an aggregated manner (for example the combination of metrics for delivering the accountability maturity score).
  • Log communication pattern: this pattern describes the way that the collected logs are communicated with a specific transformation model to serve an integrated approach for log reasoning and analysis.
  • Incident messaging pattern: this pattern is used to communicate incidents via a point to point approach.
• Demonstration patterns
  • Evidence building pattern: this pattern provides the way to build an evidence shared repository from multi-source log listeners and collectors.
• Remediation patterns
  • Incident Response pattern: this pattern defines a communication path for enabling the exchange of incident management and remediation actions.

As an example of the log communication pattern, we consider the actions of the cloud provider which offers the infrastructure. In another case, this infrastructure is based on OpenStack [48] and, thus, the relevant pattern refers to the integration of the OpenStack services with the accountability ones to collect the appropriate logs. This integration includes the monitoring and analysis of the events referring to the traffic realised in the OpenStack network and, especially, the Controller Node. An accountability service should implement a pattern to log the events collected in this part of the OpenStack infrastructure and parse these logs to identify the type of actions happened and filter them, based on policies. The pattern should, then, implement a protocol so that the collected logs can be communicated to other referring accountability services (e.g. evidence).