Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Towards an End-to-End Architecture for Run-time Data Protection in the Cloud


Published on

Protecting sensitive data, such as personal data or confidential business data, is a key concern for the adoption of cloud solutions. Protecting data in the cloud is made particularly challenging by the dynamic changes that cloud systems may undergo at run time, as well as the complex interactions among multiple software and hardware components, services, and stakeholders. Conformance to data protection requirements in such a dynamic environment cannot any longer be ensured during design time; e.g., due to the dynamic changes imposed by replication and migration of components. It requires run-time data protection mechanisms. Given the complex interactions in the cloud, individual data protection mechanisms, such as access control, encryption, or secure hardware, are not sufficient, as they only help protect specific parts of a cloud system. An attacker may use the “weakest link in the chain” to get access to sensitive data. To address these challenges, we propose combining multiple existing data protection approaches and extending them to run-time, ultimately delivering an end-to-end architecture for run-time data protection in the cloud. We describe the process of designing this architecture, present the architecture itself, and validate and substantiate its practical applicability in a commercial case study.

Published in: Technology
  • See how I make over $7,293 a month from home doing REAL online jobs! ♥♥♥
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

Towards an End-to-End Architecture for Run-time Data Protection in the Cloud

  1. 1. Towards an End-to-End Architecture for Run-time Data Protection in the Cloud Nazila Gol Mohammadi*, Zoltan Adam Mann*, Andreas Metzger*, Maritta Heisel*, James Greig+ * paluno, +OCC
  2. 2. Motivational Example 2SEAA 2018, Prague IaaS Cloud Provider X FR Component A DB PaaS Cloud provider US Component B is deployed in a non-EU geolocation. Access violates GPDR wrt. geo-location policies. Data is transferred to SaaS provided by untrusted entity, thus threat to data protection Component and thus its data is deployed on non-secure infrastructure and thus data may be compromised Data is deployed in non- secure DB and thus data may be compromised SaaS Cloud Provider Z Data Consumer IaaS Cloud Provider Y DataData Subject Legislative Organ Data Controller A Com- ponent C Component B
  3. 3. Challenges for Data Protection Uncertainty at design time of run-time changes • Dynamic deployment, migration, change of privacy preferences, … • Privacy- and Security-by-Design no longer sufficient  Runtime data protection Conflicting goals • Security techniques can have considerable overhead • May negatively impact costs, performance, etc.  Trade-off between conflicting goals Complex interactions among multiple entities • Software, hardware, services, stakeholders, … • “Isolated”, individual solutions not sufficient  End-to-end architecture and integrated solutions 3SEAA 2018, Prague
  4. 4. Solution Idea End-to-end architecture for integration and dynamic adaptation of data protection techniques 4SEAA 2018, Prague End-to-End Runtime Data Protection Exploiting Secure Hardware for Secure Data Storage and Processing Sticky Policies & Secure Data Life-cycle Models@ Runtime & Self- Adaptation Automated Risk Analysis & Management
  5. 5. Development and Validation Process Overview of process phases 5 1. Requirements Engineering 2. Design of E2E Architecture 3. Validation SEAA 2018, Prague
  6. 6. 1. Requirements Engineering 6 1) Requirements Engineering 1a) Context Analysis (Identifying Roles and Entities) 1b) Requirements Identification (Goal and Scenario Modelling) Privacy Framework from ISO/IEC 29100 General Data Protection Regulation (GDPR) List of Actors & Context Entities Goal Model SEAA 2018, Prague
  7. 7. 2. Design of E2E Architecture Considerations to manage complexity • Define architecture on conceptual level  no deployment concerns (e.g., distribution) • Focus on run-time concerns  design tools considered separately • Identify key functions and concerns  high-level components • Define principal information flow  conceptual interfaces (low coupling) 7SEAA 2018, Prague
  8. 8. 2. Design of E2E Architecture 8SEAA 2018, Prague Application Data Controller Cloud infrastructure (public, private, …) Sensitive data store Data gatekeeper Adaptation Risk assessment monitor adapt register* register Data access protection data access adapt monitor * Data Subject may register directly with Data Gatekeeper or via Application Data Subject request System modeling
  9. 9. 2. Design of E2E Architecture 9SEAA 2018, Prague Application Data Controller Cloud infrastructure (public, private, …) Sensitive data store Data gatekeeper Adaptation Risk assessment Run-time model proposed adaptation risk impact of proposed adaptation policies, service contracts current risk level too high analyze update monitor adapt analyze service contracts register* register request Data access protection data access request restrictions monitor adapt adapt monitor Logging log log log log policy change Data Subject System modeling
  10. 10. 3. Validation 10 3) Validation 3a) Scenario- based Validation 3b) Case Study Scenarios for Goal Satisfaction Application Example SEAA 2018, Prague
  11. 11. 3. Validation Example scenario for scenario-based validation 11SEAA 2018, Prague
  12. 12. 3. Validation Commercial case study • Data subjects • Vulnerable adults living at home • Data users 1) Volunteers 2) Social care providers • Data access 1) Matchmaking between volunteers and vulnerable adults 2) Anonymous access to geographical data about people with unmet needs • Deployment on public cloud 12SEAA 2018, Prague
  13. 13. Conclusion and Outlook Initial design of End-to-End architecture for data protection in the cloud Future work • From conceptual to technical architecture (decentralization of components, programmatic APIs, …) • Exploiting TOSCA for run-time model SEAA 2018, Prague 13
  14. 14. Thank you! Research leading to these results has received funding from …the EU’s Horizon 2020 research and innovation programme under grant agreement 731678 (RestAssured) SEAA 2018, Prague 14
  15. 15. Requirements for E2E architecture • R1: Registration of data subjects to for specifying/updating their privacy preferences • R2: Access to sensitive data of data subjects regulated by data protection policies • R3: Registration of data controllers for specifying offered service contracts • R4: Applications requests access to sensitive data • R5: Compliance of application’s accesses to data protection policies • R6: Data controllers need monitoring capabilities • R7: Identification of violations • R8: Data controllers need adaptations capabilities (for data protection) • R9: Data controllers should identify risks w.r.t. to data protection 15SEAA 2018, Prague
  16. 16. Design of E2E architecture Data Gatekeeper (cont.) • Manages the data protection policies and service contracts • Decides, based on the available policies and contracts, which operations are allowed 16SEAA 2018, Prague
  17. 17. Design of E2E architecture Data Access Protection (cont.) • Ensuring conformance of data accesses to the policies • Secure enclaves and cryptographic techniques for ensuring data confidentiality and integrity • Access control to enforce the compliance with the data protection policies • 17SEAA 2018, Prague
  18. 18. Design of E2E architecture Adaptation (cont.) • Responsible for the satisfaction of data protection goals in the presence of run-time changes • Continuously monitoring of the system and its environment • Analysing detected changes w.r.t. its impact on data protection • Devising a plan to adapt the system if a identified change represents an actual or imminent problem • Carrying out planned adaptations by reconfiguration 18SEAA 2018, Prague
  19. 19. Design of E2E architecture Risk Assessment (cont.) • Responsible for continuous run-time risks assessment • Triggering Adaptation component if the risk level is too high • Assessing risk impact of planned adaptations to ensure that proposed changes by adaptation: • will be compliant with the data protection policies • do not introduce unacceptable risks 19SEAA 2018, Prague
  20. 20. 2. Design of E2E Architecture Run-time Model • Considers all relevant assets and their relationships within system and its context • Up-to-date by monitoring • Model information is used by multiple components to reason about • current situation • associated risks of data protection violation • other requirement violations 20SEAA 2018, Prague