OPEN DATA CENTER ALLIANCE USAGE: Data Security Rev. 1.0

OPEN DATA CENTER ALLIANCE USAGE: Data Security Rev. 1.0

Table of Contents Legal Notice...3 Executive Summary...4 Purpose...5 Reference Framework...5 Taxonomy...5 Usage Scenarios...6 Usage Scenario Transfer Preparations...6 Usage Scenario Cloud Data Transfer (via Media)...7 Usage Scenario Cloud Data Transfer (via API/etc.)...8 Usage Scenario Access to Data...9 Usage Scenario Customer Data Access...9 Usage Scenario Staff Data Access...11 Usage Scenario SysAdmin Data Access...13 Usage Scenario Backup and Restore...14 Usage Scenario Archive...16 Usage Scenario Deletion...17 Contributors Albert Caballero Trapezoid Christophe Gévaudan UBS Tino Hirschmann T-Systems, Deutsche Telekom Group Stephen Huang Bingosoft Ian Lamont BMW Matt Lowth National Australia Bank Manjunath Mahabhaleshwar Intel IT Robert Rounsavall Trapezoid Avi Shvartz Bank Leumi Jose Souza UBS 2

Legal Notice This Open Data Center Alliance SM Usage: Data Security document is proprietary to the Open Data Center Alliance (the Alliance ) and/or its successors and assigns. NOTICE TO USERS WHO ARE NOT OPEN DATA CENTER ALLIANCE PARTICIPANTS: Non-Alliance Participants are only granted the right to review, and make reference to or cite this document. Any such references or citations to this document must give the Alliance full attribution and must acknowledge the Alliance s copyright in this document. The proper copyright notice is as follows: 2013 Open Data Center Alliance, Inc. ALL RIGHTS RESERVED. Such users are not permitted to revise, alter, modify, make any derivatives of, or otherwise amend this document in any way without the prior express written permission of the Alliance. NOTICE TO USERS WHO ARE OPEN DATA CENTER ALLIANCE PARTICIPANTS: Use of this document by Alliance Participants is subject to the Alliance s bylaws and its other policies and procedures. NOTICE TO USERS GENERALLY: Users of this document should not reference any initial or recommended methodology, metric, requirements, criteria, or other content that may be contained in this document or in any other document distributed by the Alliance ( Initial Models ) in any way that implies the user and/or its products or services are in compliance with, or have undergone any testing or certification to demonstrate compliance with, any of these Initial Models. The contents of this document are intended for informational purposes only. Any proposals, recommendations or other content contained in this document, including, without limitation, the scope or content of any methodology, metric, requirements, or other criteria disclosed in this document (collectively, Criteria ), does not constitute an endorsement or recommendation by Alliance of such Criteria and does not mean that the Alliance will in the future develop any certification or compliance or testing programs to verify any future implementation or compliance with any of the Criteria. LEGAL DISCLAIMER: THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN IS PROVIDED ON AN AS IS BASIS. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE ALLIANCE (ALONG WITH THE CONTRIBUTORS TO THIS DOCUMENT) HEREBY DISCLAIM ALL REPRESENTATIONS, WARRANTIES AND/OR COVENANTS, EITHER EXPRESS OR IMPLIED, STATUTORY OR AT COMMON LAW, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, VALIDITY, AND/ OR NONINFRINGEMENT. THE INFORMATION CONTAINED IN THIS DOCUMENT IS FOR INFORMATIONAL PURPOSES ONLY AND THE ALLIANCE MAKES NO REPRESENTATIONS, WARRANTIES AND/OR COVENANTS AS TO THE RESULTS THAT MAY BE OBTAINED FROM THE USE OF, OR RELIANCE ON, ANY INFORMATION SET FORTH IN THIS DOCUMENT, OR AS TO THE ACCURACY OR RELIABILITY OF SUCH INFORMATION. EXCEPT AS OTHERWISE EXPRESSLY SET FORTH HEREIN, NOTHING CONTAINED IN THIS DOCUMENT SHALL BE DEEMED AS GRANTING YOU ANY KIND OF LICENSE IN THE DOCUMENT, OR ANY OF ITS CONTENTS, EITHER EXPRESSLY OR IMPLIEDLY, OR TO ANY INTELLECTUAL PROPERTY OWNED OR CONTROLLED BY THE ALLIANCE, INCLUDING, WITHOUT LIMITATION, ANY TRADEMARKS OF THE ALLIANCE. TRADEMARKS: OPEN CENTER DATA ALLIANCE SM, ODCA SM, and the OPEN DATA CENTER ALLIANCE logo are trade names, trademarks, and/or service marks (collectively Marks ) owned by Open Data Center Alliance, Inc. and all rights are reserved therein. Unauthorized use is strictly prohibited. This document does not grant any user of this document any rights to use any of the ODCA s Marks. All other service marks, trademarks and trade names reference herein are those of their respective owners. 3

OPEN DATA CENTER ALLIANCE USAGE: Data Security Rev. 1.0 Executive Summary In many organizations today, there is a significant demand for introducing cloud computing into the enterprise. The hope is that the cloud s multi-tenant, shared infrastructure will enable greater computing efficiency, flexibility, and cost efficiency. At the same time, organizations require that compute platforms are secure and comply with all relevant rules, regulations, and laws. These requirements must be met whether using a dedicated service available through a private cloud or a service shared with other subscribers through a public cloud. In addition to topics covered to date, the Open Data Center Alliance SM (ODCA) recognizes that the more organizations look to leverage the benefits of cloud, the more data they will be sending out of their environment. Therefore, ensuring that data stays secure in a cloud environment is critical to the ongoing success of cloud services. Moving highly sensitive or mission-critical data to a cloud provider is not a decision an organization takes lightly; cloud subscribers should thoroughly understand the data life cycle and the controls that can provide the appropriate level of data protection. Cloud service providers, too, need to understand these controls. Threats of tampering or theft of data when in transit mean that most sensitive information is encrypted in transit. However, recent data theft (such as an incident at Sony 1 ) has occurred while data is at rest underscoring the need for cloud-based data security. This usage model extends on the existing work created by the ODCA in the Data Security Framework and provides usage models which cover the different elements of the cloud data life cycle, and what security controls should be overlaid in each stage of data use. This document is intended for use by Security and Enterprise IT groups involved in planning and operations. Solution providers and technology vendors will benefit from its content to better understand customer needs and tailor service and product offerings. Standards organizations will find the information helpful in defining standards that are open and relevant to end users. 1 www.guardian.co.uk/technology/2011/apr/27/playstation-users-identity-theft-data-leak 4

Purpose This usage model seeks to define requirements for helping to make it possible for data to be is appropriately secured at all times when being created, accessed, stored or deleted in a cloud environment. It should be noted that not all information is sensitive, so it s important that security controls deployed are commensurate to the data s sensitivity so that the solution available for the cloud subscriber is both robust and cost effective, as applying onerous security controls on top of non-sensitive data (e.g., Encrypting Marketing Brochures) provides little value. It should be noted, however, that for sensitive information (e.g., customer data, company financials, etc.), controls must be applied to ensure the data is not tampered with, is not accessed without appropriate permission, and that the data is protected when at rest. This Usage Model is a companion document to the Data Security Framework 2 and discusses the usage scenarios specific to the cloud data life cycle. It provides usage scenarios for each stage of the data access life cycle, and the security controls which should (or must) be applied to effectively protect the information at each stage. Reference Framework The usage models in this paper seek to highlight the specific uses of data throughout its life cycle seeks to identify the security controls which are required to protect the data during its use. Destroy Create Transfer Initiate Cloud Subscriber Archive Cloud Subscriber Media/Online Archive Data Life Cycle Cloud Provider Store Transfer Share Use Figure 1. Protecting Data throughout the Data Life Cycle Taxonomy Actor Cloud Subscriber Cloud Provider Cloud Subscriber (Customer) Cloud Subscriber (Staff) Cloud Subscriber (SysAdmin) Description A person or organization that has been authenticated to a cloud and maintains a business relationship with a cloud. An organization providing network services and charging cloud subscribers. A (public) cloud provider provides services over the Internet. A customer of the cloud subscriber who may need to utilize a cloud-based service. A staff member employed by the cloud subscriber who may need to provide support to customers or access the cloud-based service. The person(s) responsible for administering the cloud subscriber s specific cloud service. 2 www.opendatacenteralliance.org/ourwork/usagemodels 5

Usage Scenarios Usage Scenario Transfer Preparations Cloud subscriber The cloud subscriber decides on what type of data will move to the cloud and what key policies are to be shared with the cloud provider. Assumption 1: This is basically more process-oriented to understand what data can be shared and managed in the cloud. Assumption 2: Decisions made will affect both the service-level agreement and which data to move to the cloud. Assumption 3: The main purpose of the initial usage is to ensure that the cloud subscriber takes care of essentials before handing data over to the cloud provider. The cloud subscriber decides which data to move to the cloud and also what security policies need to be managed. 1. Decide the data classification if not previously defined 2. What rights to the data need to be provided 3. What types of data need to be encrypted in the cloud provider infrastructure 4. Type of archive/deletion/retention policies need to be used 5. Location of data 6. What backup/restore policies need to be defined No clarity on what data is moved to the cloud and impact of data loss. The cloud subscriber should ensure that he has required details for understanding the data and its consequences to the company. 6

Usage Scenario Cloud Data Transfer (via Media) Cloud Subscriber Secure Data Backup (Encryption) Physical Protection Secure Shipping Cloud Provider Secure Data Restore (Decryption) Secure Disposal/Return of Media Figure 2. Media Transfer (One Time) Cloud provider, cloud subscriber The goal of this usage scenario is for the cloud subscriber to handle the initial data transfer to the cloud provider s environment via digital media. Assumption 1: This is a transfer process from the cloud subscriber to the cloud provider s infrastructure. Assumption 2: The data is transferred one time and is a one-way transfer from the provider to the subscriber. Assumption 3: The media used could be a hard disk, tape or any or digital media which can hold the data. The cloud subscriber successfully transferred data to the cloud provider s infrastructure. 1. Cloud subscriber encrypts the data on to the media using any encryption method. 2. Cloud subscriber sends data by physically handing over or shipping to the cloud provider. 3. Cloud subscriber is responsible for the media until it has safely reached the cloud provider. 4. Data is restored on to the specific cloud provider-assigned media or through secured transfer method. Authorization can be given to cloud provider to decrypt the data based on the cloud subscriber agreement. 5. Confirmation is provided on what data and size of the data is restored. 6. If any encryption of data is to be done on the application or on specific data, then it follows the specific security level (i.e., Bronze/Silver/ Gold/Platinum). Digital media is corrupted or failed to transfer the data. Not able to decrypt the data in the media. Cloud provider to communicate with cloud subscriber to get another set of data. If it s allowed as per the agreement, then get the keys to decrypt the data. 7

Usage Scenario Cloud Data Transfer (via API/etc.) Cloud Subscriber Infrastructure Schedule Jobs SFTP/HTTPS Cloud Provider Infrastructure Monitoring Authentication/Authorization Data Protection Secured Gateway Services VPN Tunneling/Connector Internet SFTP/HTTPS VPN Tunneling/Connector Authentication/Authorization Secured Gateway Services Encryption Encryption Figure 3. Point to point transfer and the encryption controls in flight. Cloud provider, cloud subscriber To establish ongoing data transfer from the cloud subscriber to the cloud provider and vice versa. The usage model requirements for data encryption will change depending on the security level (i.e., B/S/G/P). Assumption 1: This is a transfer process from the cloud subscriber to the cloud provider infrastructure. This process is also for any data that is transferred back to the cloud subscriber by the cloud provider during archive scenarios or consolidated data transfer. Assumption 2: This is any transfer method (using API, connectors, etc.) initiated to transfer the data. Assumption 3: The data is transferred frequently based on the cloud subscriber s requirements (minute, hourly, daily). Assumption 4: The data also can be transferred based on the push/pull by the cloud subscriber/cloud provider and it also includes event-based data transfer. Assumption 5: Different transfer methods are file transfer, batch transfer, database, and data through APIs. The cloud subscriber successfully transferred data to the cloud provider s infrastructure and vice versa. 1. Continuous transfer method agreed on by the cloud provider and cloud subscriber to do the data transfer, and vice versa. 2. Confirmation is provided on what data is transferred and size of the data. 3. Secured channel (data in transit) established for data transfer by both the cloud provider and cloud subscriber. 4. Data encryption will be done on data at rest based on the security requirement (i.e., B/S/G/P). Data transfer fails on the cloud provider s side or the cloud subscriber s side. The monitoring should be enabled to check whether the data is transferred properly; if data transfer is stopped or failed then it should be made known to the cloud subscriber. The new initiation of data will happen based on the cloud subscriber requirement (whether to get confirmation for old data before beginning new data or new data is transferred without confirmation). 8

Usage Scenario Access to Data We have identified three basic actors of data access: The customer (the end user of an application that runs in the cloud) The staff member (who runs an application in the cloud typically the cloud subscriber) The SysAdmin (who sets up and administers the systems on which the cloud subscriber runs its applications typically the cloud provider staff) Usage Scenario Customer Data Access Definitions: The customer typically accesses data in the cloud through an application which provides him a service around the data. The customer will typically come from an uncontrollable external network generalized as Internet. The access goes through a traditional DMZ architecture with an outer firewall a reverse proxy enforcing the user authentication and applying access control for the requested application. Figure 4 illustrates the customer access path to data. Data access of the customer is only possible through an application. The user s profile for the application will determine which type of access the customer will do (read/write). The application server enforces auditability of the customer s actions through the whole customer session. In some cases, the application will access data or services from an application back end; the application server will have to forward the customer s user ID in order to ensure auditability of the actions performed on the back-end server. User Request Access Control Authentication Request Cascaded Request Application Server Application Back-end Server Customer Outer Firewall Reverse Proxy Inner Firewall Access Control/ Policy Server Authentication Server Figure 4. Customer Access Path to Data 9

Customer (cloud subscriber s user (staff or client)) this might be an application external to the cloud or a human user. The customer requests access to data through an application he is entitled to use. The access will be based on the permissions of the customer and the customer s verified identity. When the customer has been identified, the application will retrieve the data and disclose it to the customer according to the set of permissions they have. Assumption 1: The customer can provide verifiable authentication credentials to the authentication service. The authentication itself is described in the Identity Management usage case 3. Assumption 2: Subsequent (cascaded) calls from one application to another will keep the end-user context in order to ensure auditability of these actions. (Access control might be applied based on the ID of the application calling the back end, as this application has the responsibility to control which data can be disclosed to the end user.) Assumption 3: The customer is entitled to use the application he is calling. Assumption 4: There is data available that the customer can access through the application. The customer gets the data he was requesting from the application. 1. The customer calls the application URL. He is redirected to the authentication service to which he sends his credentials. (Please check the Identity Management usage case for more details about authentication.) 2. The authentication service verifies the customer s identity and redirects the customer back to the application passing the customer s user ID to the application. 3. The application retrieves the customer s permissions and performs the actions requested by the customer if he is entitled to them. 4. The application retrieves the data from the data source (e.g., back-end service or database) and performs the application s functional operations on it (e.g., transformation, formatting, sorting, filtering, etc.). 5. The application passes the resulting set of data to the customer. The authentication fails. Failure Condition 2: The customer is not entitled to use the application he was calling. Failure Condition 3: There is no data available that could be passed back to the customer. 3 www.opendatacenteralliance.org/ourwork/usagemodels 10

Usage Scenario Staff Data Access Definitions: Staff members will access their resources in the cloud through their enterprise firewall or virtual private network (VPN) connection to an access gateway which ensures the user is coming from an identified organization (the cloud subscriber). Staff members will perform admin tasks as well as use applications running in the cloud. Basically, their roles and accessible resources will be controlled by an access control or policy server similar to that controlling the access of the customers (i.e., from a cloud provider s point of view, these are all customers). Figure 5 illustrate the staff member access path to data. Staff members can access data through applications as well as directly (e.g., files). The access gateway enforces auditability through the whole staff member session. Staff Request Access Control Authentication Request Application Server Access Control/ Policy Server Staff Enterprise Firewall Access Gateway Inner Firewall Authentication Server Figure 5. Staff Member Access Path to Data (Cloud subscriber s) staff The staff member requests access to data through an application he is entitled to use, or access to an infrastructure he is entitled to access directly. The access will be based on the permissions of the staff member and his verified identity. When the staff member has been identified (please check the Identity Management usage case for more details on authentication), the application will retrieve the data and disclose it to the staff according to the set of permissions the customer has. Or, if the staff member requires access to an infrastructure (e.g., database, application server, back-end server, infrastructure server), access will be granted according to his permissions on the target infrastructure. Assumption 1: The staff member can provide verifiable authentication credentials to the authentication service. Please check the Identity Management usage case for details on identity federation and authentication for high-privileged users. Assumption 2: The staff member is entitled to use the application he is calling, or to access the infrastructure he targets. Assumption 3: There is data available that the staff member can access through the application, or on the infrastructure he accesses. 11

The staff member gets the data he was requesting from the application. 1. The staff member calls the application URL. He is redirected to the authentication service to which he sends his credentials. 2. The authentication service verifies the staff member s identity and redirects him back to the application passing his user ID to the target. 3. The application retrieves the staff member s permissions and performs the actions requested by the staff member if he is entitled to them. 4. The application retrieves the data from the data source (e.g., back-end service or database) and performs the application s functional operations on it (e.g., transformation, formatting, sorting, filtering, etc.). 5. The application passes the resulting set of data to the staff member. The authentication fails. Failure Condition 2: The staff member is not entitled to access the application he was calling. Failure Condition 3: There is no data available that could be passed back to the staff member. Success Scenario 2: The staff member gets the data he wanted to access on the infrastructure. 1. The staff member calls the target infrastructure URL. He is redirected to the authentication service to which he sends his credentials. 2. The authentication service verifies the staff member s identity and redirects him back to the infrastructure passing his user ID to the target. 3. The infrastructure retrieves the staff member s permissions and performs the actions requested by him if he is entitled to them. 4. The staff member accesses the data from the data source (e.g., file). The authentication fails. Failure Condition 2: The staff member is not entitled to access the data source he was targeting. 12

Usage Scenario SysAdmin Data Access Definitions: The SysAdmin has OS-level access the the cloud provider s servers and is under control of an admin gateway to limit the access to systems the admin is entitled to. The admin gateway can be implemented as a function on each server, which enforces role-based access control on the OS level (e.g., PowerBroker). Figure 6 illustrates the SysAdmin access path to data. Basically, the SysAdmin has access to all servers on the OS level. He always accesses data directly, as he has no application entitlements. User Request Access Control Application Server Access Control/ Policy Server System Admin Admin Gateway Figure 6. SysAdmin Access Path to Data (Cloud provider s) SysAdmin The SysAdmin requests access to data on an infrastructure he is entitled to access directly. The access will be based on the permissions of the SysAdmin, and his verified identity. When the SysAdmin has been identified, the infrastructure (e.g., database, application server, back-end server, infrastructure server) access will be granted according to his permissions on the target. Assumption 1: The SysAdmin was authenticated previously to accessing the target. Please check the Identity Management usage case for more details on the authentication for high-privileged users. Assumption 2: The SysAdmin is entitled to access the infrastructure he targets. Assumption 3: There is data available that the SysAdmin can access on the infrastructure he targets. The SysAdmin gets the data he was requesting from the infrastructure. 1. The SysAdmin accesses an admin gateway that logs his activities on the target. 2. The admin gateway verifies the SysAdmin is entitled to access the target infrastructure and lets him jump over to it passing his user ID to the target. 3. The infrastructure retrieves the SysAdmin s permissions and performs the actions requested by him if he is entitled to them. 4. The SysAdmin accesses the data from the data source (e.g., file). The SysAdmin is not entitled to access the data source he was targeting. 13

Usage Scenario Backup and Restore Definitions: Operational data: Any data of the cloud subscriber that is processed on the cloud providers infrastructure and is directly provided by the cloud subscriber or is a derived product of this data. Typically, this is application data but may include the VM and its configuration as well. Cloud subscriber, cloud provider The cloud subscriber requests a backup of his operational data. The backup will be based on the operational needs of the cloud subscriber and the provisions defined in the terms of service. When required, the operational data is restored upon request of the cloud subscriber. Assumption 1: The usage scenario could be either based on an explicit backup request of the customer or an automatic triggering of a backup via the API (cloud portal). Assumption 2: The backup service is either defined in the contract or the terms of service. Details are specified in these documents. This also included details about the restore process. Assumption 3: The main purpose of a backup is to ensure the availability of the data for operational use. Assumption 4: Backup is stored and secured in accordance to contract or terms of service definitions. The cloud subscriber data is backed up successfully. All actions are successfully executed via the API. 1. The cloud subscriber uses the API to trigger a one-time or regular backup of his operational data. 2. The data is automatically backed up by the cloud infrastructure and a confirmation is provided to the cloud subscriber. 3. Additional data is provided to the cloud subscriber to monitor the availability and functionality of one-time or regular backups if necessary. The backup operation is unsuccessful. The cloud provider monitors the managed resources for failed requests and resolves problems as they arise. In addition a standard interface is provided to the cloud subscriber to report potential problems and errors. Success Scenario 2: The cloud subscriber data is restored successfully. All actions are successfully executed via the API. 1. The cloud subscriber uses the API to trigger a full or selective restore of operational data from the backup. 2. The data is automatically restored by the cloud infrastructure and a confirmation is provided to the cloud subscriber. 3. The cloud subscriber verifies the restore of his data on the affected systems. The restore operation is unsuccessful. The cloud provider repeats the restore operations and resolves the issues that caused the error. 14

Success Scenario 3: The cloud subscriber data is backed up successfully. Backup operations are specially trigged via a direct (change) request to the cloud provider and are executed by the cloud provider manually or partially manual. 1. The cloud subscriber requests a backup from the cloud provider. This request contains details about the data to be backed up as well as the backup schedule (if needed). 2. The cloud provider verifies the request with regards to the contract/terms of service. 3. The cloud provider backs up the defined data as requested by the cloud subscriber. 4. The cloud provider provides a confirmation to the cloud subscriber. 5. Additional data will be provided to the cloud subscriber in case of regular backups, which enables the cloud subscriber to verify that data has been successfully backed up. The backup operation is unsuccessful. The cloud provider repeats the backup operations and resolves the issues that caused the error. Failure Condition 2: The backup request is invalid. Failure Handling 2: The cloud provider informs the cloud subscriber about the problem. The cloud subscriber creates a new correct request. Success Scenario 4: The cloud subscriber s data is restored successfully. Restore operations are specially trigged via a direct (change) request to the cloud provider and are executed by the cloud provider manually or partially manual. 1. The cloud subscriber requests a restore from the cloud provider. This request contains details about the data to be restored. 2. The cloud provider verifies the request with regards to the contract/terms of service. 3. The cloud provider restores the data as requested by the cloud subscriber. 4. The cloud provider provides a confirmation to the cloud subscriber. The restore operation is unsuccessful. The cloud provider repeats the restore operations and resolves the issues that caused the error. 15

Usage Scenario Archive Cloud subscriber, cloud provider The cloud subscriber requests an archival of selected data. The archived data is stored in accordance to regulatory requirements and can be provided to the cloud subscriber if needed (e.g., for legislative reasons). Assumption 1: The archiving service is initially defined between the cloud subscriber and the cloud provider. Archival processes are typically designed once and are then used in an automated fashion. Assumption 2: All regulatory requirements have been identified and agreed upon during the initial setup of the archive service. Requirements are documented either in the terms of service or the contract. Assumption 3: A de-archiving of data is typically a manual processes, but may be designed in an automated fashion if needed. Assumption 4: The main purpose of archiving is to comply with regulatory requirement by proving a secure and integrity-protected long-term storage (e.g., 10 years). Furthermore, archived data is typically only a subset of the operational data because of storage and operational reasons. Assumption 5: The archiving itself is done via an automated interface. Assumption 6: Regular checks of the archive system are performed by the cloud provider if needed. The cloud provider s archive data is correctly and successfully archived in compliance with the applicable regulatory requirements. 1. The cloud subscriber uses the provided interface to archive selected data. 2. The cloud provider s archiving service archives the data and provides a confirmation to the cloud subscriber. 3. Additional evidence for the successful archiving is provided to the cloud subscriber if needed (e.g., checksum or digital signatures of archived file). The archiving request fails. The cloud provider monitors the managed resources for failed requests and resolve problems as they arise. Success Scenario 2: The cloud subscriber requests archived data from the cloud provider. 1. The cloud subscriber requests a de-archiving of selected or all archived data from the cloud provider. 2. The cloud provider verifies the requests in regards to the terms of service/contract. 3. The cloud provider provides the selected archived data to the cloud subscriber. 4. If needed, additional information regarding the correctness and integrity of the data is provided to the cloud subscriber. 16

Usage Scenario Deletion Cloud subscriber, cloud provider The cloud subscriber requests a data deletion from the cloud provider. This data deletion could be for all data or only selected parts of the cloud subscriber s data. Data deletion can be requested for operational data as well as backup or archive data. Assumption 1: The cloud subscriber has already copied all relevant data from the cloud to his premises or does not need the selected data residing on the cloud anymore. Assumption 2: Only the cloud subscriber s operational data is deleted; cloud subscriber-specific data generated on the cloud infrastructure itself will only be deleted as far as technically possible and feasible. 4 Remaining data will be deleted as soon as the retention times of these log files have been reached. A retention time should/needs to be defined for all logs that may contain PII or PII-related data (must be in accordance to local and applicable legislative requirements). Assumption 3: This usage scenario only describes the deletion of specific data. However, the cloud subscriber may still use other services from the cloud provider. Assumption 4: The deletion is final and cannot be undone. Assumption 5: Data deletion is conducted in accordance to the requirements defined either in the contract or the terms of service. Assumption 6: Cloud subscriber is authorized to request a data deletion. All specified cloud provider data has been deleted from the cloud provider s cloud infrastructure. 1. The cloud subscriber requests a data deletion for specific data and may also requests a confirmation (if defined in terms of service/ contract). 2. The cloud provider verifies possible constraints to the data deletion (e.g., terms of service/contract, timeframe, etc.). 3. The cloud subscriber s data is deleted in accordance with terms of service/contract requirements. 4. The cloud provider returns a confirmation message indicating the successful deletion of the cloud subscriber s data. 5. (Optional) The cloud provider returns evidence that the data has been deleted in accordance to the terms of service/contract definitions. The deletion request cannot be completed by the cloud subscriber. The cloud provider monitors the managed resource for failed requests and resolve problems as they arise. 4 Cloud subscriber data generated on the cloud infrastructure are typically artifacts such as infrastructure logs and/or logs from central cloud provider systems such as IAM which may have a reference to the customer. 17