Towards an End-to-End Architecture for Run-time Data Protection in the Cloud
Download as PPTX, PDF0 likes247 views
The document outlines the design of an end-to-end architecture for run-time data protection in cloud environments, addressing challenges such as the dynamic deployment of services and compliance with privacy regulations like GDPR. It highlights the need for integrated solutions that adapt to changing contexts and manage risks effectively, emphasizing automated risk analysis and data lifecycle management. Future work aims to transition from conceptual to technical architecture, enhancing the system's capabilities and robustness.
Towards an End-to-End Architecture for Run-time Data Protection in the Cloud
- 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. 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. 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. 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. Development and Validation Process Overview of process phases 5 1. Requirements Engineering 2. Design of E2E Architecture 3. Validation SEAA 2018, Prague
- 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. 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. 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. 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. 3. Validation 10 3) Validation 3a) Scenario- based Validation 3b) Case Study Scenarios for Goal Satisfaction Application Example SEAA 2018, Prague
- 11. 3. Validation Example scenario for scenario-based validation 11SEAA 2018, Prague
- 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. 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. Thank you! https://restassuredh2020.eu 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. 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. 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. 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. 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. 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. 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
Editor's Notes
- #16: R1: Registration of data subjects to the E2E run-time data protection system for specifying / updating their privacy preferences. R2: Access to sensitive data of data subjects is regulated by data protection policies. R3: Registration of data controllers to the E2E run-time data protection system for specifying contracts of offered services. R4: Requests for access to sensitive data by applications. R5: Compliance of application’s accesses to sensitive data with the data protection policies. R6: Data controllers monitor applications, the infrastructure and changes in data protection policies. R7: Identification of violations regarding data protection. R8: Support for data controllers in performing adaptations on applications and the cloud infrastructure. R9: Support for data controllers in identifying risks with respect to data protection, thus facilitating proactive adaptations.
- #17: Manages the data protection policies and service contracts governing the data life-cycle. Decides, based on the available policies and contracts, which operations are allowed for a certain data. Addresses requirements: R1, R2, and R3.
- #18: Ensuring that data accesses are secure and conform to the relevant policies. Applying secure enclaves and cryptographic techniques for ensuring data confidentiality and integrity. Involvement in access control to enforce the compliance with the specified data protection policies. Addresses requirements R2, R4, and R5
- #19: Responsible for the satisfaction of requirements in the presence of run-time changes. Continuously monitoring of the system and its environment. Analysing detected changes with respect to its impact on data protection and other quality attributes. Devising a plan to adapt the system if a identified change represents an actual or imminent problem. Carrying out planned adaptations by reconfiguring the appropriate component or context entity. Addresses requirements: R6, R7, and R8.
- #20: Responsibility for continuous run-time assessment of risks for data protection. Assessing of risks associated with the current system setup triggering Adaptation component if the risk level is too high. Assessing of risk impact of planned adaptations for ensuring that changes, proposed by adaptation will be compliant with the available policies do not introduce unacceptable risks of data protection violation. Addresses requirements: R7 and R9.