Systems and methods for customer data processing

Abstract

Various embodiments of the present technology generally relate to systems and methods for secure customer data processing. More specifically, some embodiments relate to processing derived data as a provider in a manner that supports security and provides a stronger level of control over the data. The solution supports four core principles of customer data processing: no export of customer data unless authorized; remote operations with shell access or equivalent only; temporary and task-based privileges; and ephemeral diagnostic data. The customer data processing system herein includes a central repository for storing diagnostic data, an upload tool for uploading to the central repository and automatic staging on containers, a diagnostic virtual machine that enables task-based access to diagnostic data and analysis tools hosted on dedicated containers, and applications for processing requests, provisioning and staging containers, and purging.

Description

[Technical Field]

[0001] Technical Field Various embodiments of the present technology relate generally to secure customer data processing. More specifically, embodiments of the present technology relate to systems and methods for processing customer data as a service provider in a manner that supports core security principles of customer data processing and provides a greater level of control over derived data and the entire lifecycle of the customer data. [Background technology]

[0002] background Cloud service providers are trusted by their customers to manage and maintain services, including sensitive data entered into or created in the service offering. Service providers are trusted stewards of customer data. Services may include Software as a Service (SaaS), Platform as a Service (PaaS), or Infrastructure as a Service (IaaS), along with other cloud services. The scope of customer data protection may include any digital assets (i.e., files) that may be subject to contractual, statutory, and / or other legal obligations. These obligations may vary by geographic area or jurisdiction (e.g., Europe, the United States, China, California, etc.). Examples of data subject to such obligations include, but are not limited to, (1) Customer Content and (2) Derivative Data. (1) Customer Content includes, but is not limited to, all software data (including personal data and personally identifiable information), text, images, audio, video, photos, third-party applications, and other content and materials in any format provided by Customer or any Customer User that are stored within or run on or through the Services. (2) Derived Data includes, but is not limited to, customer-specific metadata that can be used for maintenance, troubleshooting, monitoring, usage analysis, billing, capacity planning, training, service improvement, security and operations research, service development, and other cloud service provider functions. Service providers must meet certain requirements in their processing of customer data, such as privacy, security, and deletion rights, and it may be difficult to locate, account for, or remove data if the data is not properly tracked throughout its lifetime.For example, removing data requires knowing or understanding where the data resides and whether it is replicated, such as in backup systems, log repository systems, etc. Once data is allowed to leave the secure environment (e.g., the cloud), the traceability of the data is lost. Summary of the Invention [Problem to be solved by the invention]

[0003] For example, once data is downloaded to an engineer's computer for analysis, the data's traceability is lost, and the provider can no longer guarantee that it knows where every instance of the data resides, what it was used for, or where it was copied. Therefore, complying with General Data Protection Regulation (GDPR), California Consumer Privacy Act (CCPA), and Clarifying Lawful Overseas Use of Data (CLOUD) regulations, such as the right to deletion and the right to be forgotten, requires tremendous trust within the provider's task force. For example, personally identifiable information (PII) and logs may be downloaded to an engineer's workspace (e.g., laptop) to access an incident, and the engineer is responsible for remembering to delete them once their work is complete.

[0004] Nevertheless, diagnostic data has traditionally been downloaded to engineers' (i.e., customer support, development, and operations) local workstations for parsing and analysis. This means that customer data cannot be adequately tracked, secured, and wiped because it is extracted from the secure production environment (e.g., the cloud). Historically, cloud providers (e.g., PaaS, SaaS, private cloud, on-premise deployments, etc.) have addressed this issue by excluding derived data from the scope of protection offered to customer content. However, the solution disclosed herein provides a means to include derived data in the scope of protection offered to customers while still allowing access for troubleshooting and other diagnostic purposes.

[0005] The information provided in this section is presented as background information and is only to aid in the understanding of the present disclosure. No determination or assertion has been made as to the applicability of any of the foregoing as prior art to the present disclosure.

[0006] Brief Summary of the Invention This Summary is provided to introduce various concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. [Means for solving the problem]

[0007] Various embodiments herein relate to systems, methods, and computer-readable storage media for processing customer data in a secure manner to enable providers to have more control over derived data. In one embodiment, a computing device for processing customer data includes one or more computer-readable storage media, one or more processing systems, and program instructions stored on the one or more computer-readable storage media, which, when executed by the one or more processing systems, direct the one or more processing systems to identify data associated with a task stored in a data repository in response to a request from a data accessor to access data for the task. The program instructions further direct the processing system to provision a container for the task, the container including the data associated with the task and at least one data analysis tool, and to provide the data accessor with access to the container and to erase the container from the computing device after the one or more data accessors exit or finish using the container.

[0008] In one embodiment, the program instructions further direct the processing system to maintain the data repository, the data repository including data for a plurality of tasks. The program instructions may further direct the processing system to determine whether the data accessor is authorized to access the data associated with the task before provisioning the container for the task. The program instructions may further direct the processing system to notify the data accessor that the container is ready after provisioning the container for the task. The program instructions may further direct the processing system to detect that the data accessor has exited the container before erasing the container from the computing device. In some embodiments, the container prevents the data accessor from exporting the data associated with the task from the container. In some embodiments, the container is hosted on a virtual machine. In particular embodiments, the program instructions, to erase the container from the computing device, direct the processing system to identify a wait time for erasing the container and erase the container from the computing device after the wait time has elapsed.

[0009] In an alternative embodiment, a method for securely processing customer data includes identifying data associated with an incident stored in a data repository and provisioning a container for the incident, the container including the data associated with the incident and at least one data analysis tool. The method further includes providing access to the container to a data accessor and purging the container from the system after the one or more data accessors exit or finish using the container (e.g., after it has been idle for a period of time). An incident may include the occurrence of any event or condition related to the provided services described herein. In some examples, an incident includes a data set related to the normal functioning of the provided services. Further examples of incidents may include, for example, an occurrence of abnormal function, an occurrence of normal function, a data upload event from a CDH upload tool, an error, an error report, a bug incident, or similar scenarios in which a data accessor may desire to access data for purposes of evaluating general performance, fixing bugs, addressing errors, or other general analysis, observation, adjustment, verification, or investigation.

[0010] In yet another embodiment, one or more non-transitory computer-readable storage media store program instructions for facilitating secure customer data processing, the program instructions, when read and executed by a processing system, directing the processing system to: identify data associated with a task stored in a data repository in response to a request from a data accessor to access data for the task, the program instructions further directing the processing system to: provision a container for the task, the container including the data associated with the task and at least one data analysis tool, the program instructions further directing the processing system to provide access to the container to the data accessor and to purge the container from a system after the one or more data accessors exit the container.

[0011] Many aspects of the present disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily drawn to scale. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views. While several embodiments are described in connection with these drawings, the present disclosure is not limited to the embodiments disclosed herein. Rather, the intention is to cover all alternatives, modifications, and equivalents. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 illustrates an operating environment including a customer data processing system according to some embodiments of the present technology. [Figure 2] FIG. 1 illustrates an overview of a customer data processing system, according to some embodiments of the present technology. [Figure 3] FIG. 1 illustrates a process overview for customer data processing according to some embodiments of the present technology. [Figure 4]FIG. 1 illustrates a customer data processing process according to some embodiments of the present technology. [Figure 5] FIG. 1 illustrates a secure customer data processing environment according to some embodiments of the present technology. [Figure 6] FIG. 1 illustrates a customer data processing process according to some embodiments of the present technology. [Figure 7] FIG. 1 illustrates a customer data processing process according to some embodiments of the present technology. [Figure 8] FIG. 10 illustrates a table of data categories related to customer data processing according to some embodiments of the present technology. [Figure 9] FIG. 1 illustrates several types of customer data processing toolkit patterns that may be used with various types of offered services in accordance with the present technology. [Figure 10] FIG. 1 illustrates a computing system for implementing a customer data processing toolkit in accordance with some embodiments of the present technology. DETAILED DESCRIPTION OF THE INVENTION

[0013] The drawings are not necessarily drawn to scale. Similarly, some components or operations may not be separated into respective blocks or combined into a single block for purposes of describing some embodiments of the present technology. Moreover, while the present technology is susceptible to various modifications and alternative forms, specific embodiments are shown by way of example in the drawings and are described in detail below. However, the intention is not to limit the present technology to the particular embodiments described. Rather, the present technology is intended to encompass all modifications, equivalents, and alternatives falling within the scope of the technology defined by the appended claims.

[0014] Detailed Description The following description and associated drawings teach the best mode of the present invention. For the purpose of teaching the principles of the present invention, some conventional aspects of the best mode may be simplified or omitted. The following claims specify the scope of the present invention. It should be noted that some aspects of the best mode may not fall within the scope of the present invention as specified in the claims. Accordingly, those skilled in the art will recognize variations from the best mode that fall within the scope of the present invention. Those skilled in the art will appreciate that the features described below can be combined in various ways to form multiple variations of the present invention. Consequently, the present invention is not limited to the specific examples described below, but only by the claims and their equivalents.

[0015]

[0002] Various embodiments of the present technology generally relate to secure customer data processing. More specifically, the present technology relates to a system and method for processing customer data as a service provider in a manner that supports core security principles of customer data processing and provides providers with a stronger level of control over derived data. The Customer Data Handling (CDH) toolkit disclosed herein enables service and cloud providers (e.g., SaaS, PaaS, IaaS, private cloud, on-premise deployments, etc.) to provide unprecedented data stewardship to their customers while improving operational efficiency. The solution supports four core principles of customer data processing: no export of customer data unless authorized; remote operations with shell access or equivalent only; temporary and task-based privileges; and ephemeral diagnostic data.

[0016] The CDH toolkit herein consists of four main components: a central repository for storing diagnostic data; an upload tool for uploading data to the central repository; diagnostic virtual machines (VMs) that enable task-based access to diagnostic data and analysis tools hosted on dedicated containers; and a CDH application for requesting and providing access to diagnostic data and tools, provisioning and staging the containers, and erasing the containers along with copies of the diagnostic data within the containers. Thus, when an authorized data accessor (e.g., a support / DevOps engineer or any program, tool, app, software, hardware, or combination thereof) requests access to diagnostic data related to one or more tasks and / or incidents, a temporary container is provisioned for the specific purpose upon authorization. Within the container, the data accessor may complete one or more tasks or analyses related to the incident before exiting the container, at which time the container and its copy of the data are erased from the system. Users cannot share or export data to external locations while working within the secure production environment (i.e., the container), thereby ensuring full traceability of the data while allowing individual access to specific users. An incident may include the occurrence of any event or condition related to the provided services described herein. In some examples, an incident includes a data set related to the normal functioning of the provided services. Further examples of incidents may include, for example, an occurrence of abnormal function, an occurrence of normal function, a data upload event from a CDH upload tool, an error, an error report, a bug incident, or similar scenarios in which a data accessor may desire to access data for purposes of assessing general performance, fixing bugs, addressing errors, or other general analysis, observation, adjustment, verification, or investigation.

[0017] The SaaS CDH solution herein enables cloud provider teams to achieve full alignment with core CDH principles by providing a system consisting of diagnostic data repositories and hosted analytical tools in secure production environments, isolated by task or incident. The CDH toolkit solution accelerates the process for requesting access, enabling tasks to be performed with faster turnaround times. The solution also improves engineer productivity by isolating tasks within containers, eliminating the need to reconfigure environments to work on different tasks at different times. Multiple engineers can share incident containers to collaborate and provide 24 / 7 coverage without having to start over. Furthermore, the CDH toolkit significantly reduces risk exposure for both customers and providers and improves the handling of customer data by enforcing effective access control and purging of data. The solution herein provides sufficient control over the lifecycle of customer diagnostic data, ensuring that traceability of this data is always maintained as it is used by various engineers or provider staff during analysis or troubleshooting related to various customer incidents. The technology herein can be used in this way, i.e. to process all customer data (including derived data) in a way that is fully traceable but cannot be downloaded or extracted, and to keep that data within a secure production environment.

[0018] In existing systems, data may be stored within a corporate firewall with role-based access, with limited location-restricted access. Diagnostic data persists, is not purged, and there is no ability to track exported data. Similarly, parsing and analysis tools run on personal workstations, but access controls impose continuous access on users, with access only revoked in response to role changes. However, customers expect providers to use data securely and on a need-to-know basis. Traditionally, diagnostic data has been excluded from that scope of protection. With these existing technologies, there are few technical controls for data export, and the security of derived data relies on employee compliance with policies. When users share log files with another location or user, they traditionally share the files with a mount point from which the other location or user can access the files. In an exemplary scenario, a customer of a service provider may contact support to report a problem, and the provider may create a record of the problem (i.e., a bug database). Additionally, any diagnostic data information provided by the customer related to the problem may be attached to the incident record in the bug database, and any user with access to the bug database can access data related to any incident in the database. This creates an environment where access to customer diagnostic data is uncontrolled. With this technology, providers can further control what data related to an incident is accessible, while providing more restricted access to incidents.

[0019] In the system presented herein, data can only be accessed through an ephemeral container, and the data is temporarily added to a provisioned container for an incident in response to a valid request. For example, a data accessor or multiple accessors may go to a CDH application user interface and request access to data for a particular incident. Once access is approved based on policies, credentials, etc., a container containing the diagnostic data for that particular incident and any associated set of tools is provisioned for that incident. The data accessor can then use the data in the provisioned container to perform parsing, troubleshooting, and analysis jobs without being able to download, export, or communicate data outside the provisioned container. Once the task or analysis is complete, the data accessor can exit the provisioned container, at which time (or later), the container, along with any data in the container, is purged from the system. In some examples, the data accessor may not exit or close the container, and the container may be purged after a certain period of non-use or idleness. In other examples, the container may be purged after an allowed time has elapsed.

[0020] FIG. 1 illustrates an example customer data processing environment including a CDH system 100, in accordance with the technology disclosed herein. FIG. 1 includes a CDH system 100 that includes a diagnostic data repository 101, an upload tool 102, a CDH application 103, and a diagnostic VM 104. FIG. 1 also includes incident data 110 and a computing device 120. In one example, incident data 110 is uploaded to diagnostic data repository 101 in response to a customer error report. A user operating computing device 120 may then identify the incident data and request access to the incident data for one or more purposes (e.g., bug detection, analysis, investigation, etc.). In response to the request to access the incident data stored in diagnostic data repository 101, CDH application 103 determines whether the user and / or computing device 120 has the necessary credentials or authorization to access the incident data. In response to determining that the user and / or computing device 120 meets the necessary requirements, the CDH application 103 can automatically provision a container (e.g., a Docker container) to run on the diagnostic VM 104, stage a copy of the incident's diagnostic data in the provisioned container, and provide access to the provisioned container to the computing device 120.

[0021] Once a computing device 120 is provided with access to the provisioned containers and staged environments, various tools become available within the environments. In some examples, the same complete set of tools may be provided for each container, while in other examples, tools may be provided based on specific incidents, service constraints, and similar factors. Once the user of the computing device 120 has completed using the provisioned container, they can close or exit the provisioned container. After exiting, the CDH application 103 can automatically purge the container along with a copy of any diagnostic data provided with the container. In some examples, the purge may occur immediately in response to the container being closed, while in other examples, the purge may occur based on a time delay or time interval.

[0022] In some examples, the diagnostic data repository 101 is an object storage service (OSS). Separate instances of the diagnostic data repository 101 may be provisioned for specialized production environments or clouds that must adhere to different constraints. For example, specialized clouds subject to Payment Card Industry (PCI) compliance or Health Insurance Portability and Accountability Act (HIPAA) compliance may exist so that the diagnostic data in those instances can conform to their respective requirements. In some examples, the upload tool 102 may include a compiled binary (upload tool) for uploading diagnostic data to the diagnostic data repository 101. The diagnostic VM 104 enables task-based access to diagnostic data and analysis tools hosted on dedicated containers within the secure production environment.

[0023] FIG. 2 illustrates an example solution design overview of a CDH system provided in accordance with the present disclosure. FIG. 2 includes cloud network access 200, support and DevOps engineer 230, and SaaS customer 240. Cloud network access 200 includes data center 205, Open Platform Communication (OPC) 210, and cloud infrastructure 215. OPC 210 includes pod 211, which represents a collection of one or more containers and their shared storage. Cloud infrastructure 215 includes pod 216, pod 217, object storage 218, VM 220, VM 225, host 223, and host 228. VM 220 includes container 221, container 222, a container engine, a host operating system, and infrastructure (e.g., servers, hardware). VM 225 includes container 226, container 227, a container engine, a host operating system, and infrastructure. VM 220 and VM 225 may include any number of containers, and the number of containers hosted on either virtual machine may vary. The components of cloud network access 200, including VM 220 and VM 225, are provided for illustrative purposes and may vary according to various implementations of the technology. Figure 2 further includes SaaS customer 240, which includes pod 241, customer storage 242, and customer-specific CDH upload tool 243.

[0024] In one example, a SaaS customer 240 may report an incident they encountered while using the provided service. The SaaS container 240 may then provide the incident data from customer storage 242 to object storage 218 using a customer-specific CDH upload tool 243. In some examples, the customer may provide the incident data to the provider itself. In other examples, an engineer or other member of the provider team may be assigned the task of accessing the incident data in customer storage 242 and adding it to object storage 218 in the cloud environment using a customer-specific CDH upload tool 243 or a similar tool. In yet another example, data from customer storage 242 may be retrieved in response to a request from a support and DevOps engineer 230 to access the incident data. Object storage 218 is a central data repository for diagnostic data. In some examples, separate instances of object storage 218 are provisioned for specialized clouds that are subject to different rules and regulations.

[0025] Once data for a particular incident is uploaded to object storage 218, a support and DevOps engineer 230 with the necessary permissions can access the incident data through a provisioned container hosted on a virtual machine (i.e., VM 220) within the secured environment (i.e., cloud network access 200). The support and DevOps engineer 230 may log in to cloud network access 200 or request approval to access the incident data for a given incident. Once approved to access the incident and secured environment, a provisioning workflow may begin, in which a container (e.g., container 221, container 222) is provisioned for the incident and diagnostic data for the incident is staged within the container along with various tools for analyzing or processing the data. The engineer may then be notified and provided access to the provisioned container via a host (i.e., host 223). The engineer does not have the ability to move incident data from within the provisioned container outside the environment. For example, there is no ability to download data from the provisioned container, export data, or access the Internet, thereby ensuring full traceability of the data.

[0026] Within the container, engineers can perform a variety of tasks, including, but not limited to, analyzing log files, analyzing memory or core dumps, drawing correlations between multiple log files, parsing data, performing comparisons, and searching for events or data points, and the environment may include tools for performing these tasks. Any number of tools may be provided within the container. If an engineer wants to include a new or additional tool in the provisioned environment, the engineer can go through a validation process that checks the tool for licensing and / or security approvals before loading it into the container. In some embodiments, an engineer may be prevented from attempting to install a new tool and be required to submit a request to the CDH DevOps team to have the new tool go through various validations before system-wide deployment of the tool. In this way, users are prevented from downloading, installing, and using unauthorized, insecure, or unsecured tools that could expose customer data to vulnerabilities.

[0027] Once the task or set of tasks related to the incident data for which the container was provisioned is complete, the user or engineer can close, leave, or exit the provisioned environment, at which time the container and its copy of the diagnostic data are automatically erased. In some examples, only the copy of the data may be erased with the container, with another set of data still residing in object storage 218. In alternative examples, the incident data may also be erased from object storage 218. In certain examples, the copy of the data from object storage 218 may be erased after a longer period of time compared to the container, thereby allowing the provider to create a new container at a later time to reanalyze the issue for the same customer or as part of a product bug fix process.

[0028] 3 illustrates an exemplary customer data processing workflow including steps 310, 320, 330, and 340 configured within customer environment 350, CDH toolkit backend 360, and CDH toolkit user interface (UI) 370. Step 310 includes step 311 and step 312. Step 320 includes step 321. Step 330 includes step 331, step 332, step 333, step 334, and step 335. Step 340 includes step 341, step 342, steps 344, 345, and step 346. Step 310 is performed within customer environment 350, step 320 is performed within CDH toolkit backend 360, step 330 is performed within CDH toolkit UI 370, and step 340 is performed within the combination of CDH toolkit backend 360 and CDH toolkit UI 370.

[0029] In step 311, a user or engineer logs into customer environment 350 using existing or pre-approved credentials and / or authentication information. In step 312, the user or engineer runs the CDH Upload Tool to create an incident in the CDH Toolkit and upload the requested or relevant diagnostic data. In step 321, the incident is registered with the CDH Toolkit. In step 331, user access is requested from within CDH Toolkit UI 370, and a CDH user interface is provided in step 332. In step 333, the credentials are queried from the identity management service for user approval. If the user is approved, in step 341, an automated provisioning task is triggered, and in step 342, a container (i.e., one of containers 343) is provisioned on the container host. In step 344, a notification is sent to the user indicating that a container for the requested incident has been provisioned, and an email notification is sent in step 334. The user can then access the container, which contains the data and tools specific to the incident. In step 335, the user may be notified that the container will be purged after a certain number of days (e.g., 7 days, 3 days, 2 days, 1 day) based on system / platform settings. In some examples, the user may be able to request a time extension. In alternative embodiments, the user may indicate how many days should pass before the container and copies of data are automatically purged. In some embodiments, the user may be allowed to manually purge the container at any time. In step 345, the CDH toolkit checks whether 30 days have passed or whether the incident has been resolved. If one or both of those are true, an automatic purge task is triggered in step 346 to purge the container along with a copy of the incident data.

[0030] In addition to the container provisioning steps provided in steps 310, 320, 330, and 340, data may be purged from the secure data repository after a period of time or in response to an event. In this example, in step 321, the CDH toolkit checks whether 90 days have passed since the incident data was uploaded, and if so, in step 322, initiates automatic purging of the data from secure storage.

[0031] FIG. 4 illustrates a customer data processing process that may be performed by the CDH system disclosed herein. In step 405, the CDH system stores diagnostic data for the incident in a diagnostic data repository. In some examples, step 405 may be triggered by an incident report, in response to an automatic data upload of diagnostic data for the incident, in response to an upload by a user of the service experiencing the incident, or by a service provider user initiating the upload. In step 410, the CDH system receives a service request for the incident from a user or engineer. The service request may include an indication of the incident that the user or engineer is attempting to access. In step 415, the CDH system authorizes the requesting entity (i.e., the user or engineer) based on the credentials associated with the requesting entity. In some examples, an identity management system is used to authorize the requesting entity. In some examples, this identity management system may be specific to the CDH system of this example. Alternatively, in some examples, the identity management system may be a central system for many services that is accessible to providers.

[0032] In response to the requesting entity's approval, in step 420, the CDH system provisions a container for the incident and stages diagnostic data specific to the incident in a dedicated container. Along with this diagnostic data, the CDH system stages any necessary analytical tools in the container. In some implementations, the container may be a dedicated Docker container hosted on a virtual machine, while in other implementations, the container may be hosted on an alternative computing machine, hosted by an alternative container host. In this example, the provisioned container is locked down in a secure environment (i.e., the cloud) within a virtual private network requiring multiple different credentials and subject to various access controls. In step 425, the CDH system detects the termination of the service request, and in step 430, the CDH system erases the container and the copy of the incident's diagnostic data staged in the container.

[0033] The CDH system provided herein may include an application (e.g., CDH application 103) that exists outside of the container and provides authorized staff with a UI for requesting access to task-based diagnostic data (i.e., incident-specific data) based on entitlements and approvals. This application is responsible for automated provisioning of task-based containers within a secure environment (i.e., cloud network access 200) and job control integration between system components and notifications / reports. This application is also responsible for automated purging of task-based diagnostic data and associated containers. The CDH toolkit provided herein enables data to be ephemeral by allowing providers to effectively purge diagnostic data upon task completion (i.e., upon termination of the service request and return to the application UI). This automated purge mechanism may purge all associated data in response to termination of the service request, in some instances after a grace period.

[0034] FIG. 5 illustrates a CDH access environment 500 that provides an example overview of incident-specific customer data access. CDH access environment 500 includes a computing device 505 and a secure production environment 510. Computing device 505 may represent any form of computing device, including, but not limited to, a desktop computer, a laptop, a mobile device, a cell phone, or a tablet. Secure production environment 510 includes a container 515 that includes an analysis tool 516 and incident-specific diagnostic data 517. In this example, an engineer may initiate a request to access incident-specific data via computing device 505. In response to access being approved based on requirements that may include, but are not limited to, user credentials, device requirements, and location requirements, computing device 505 may be authorized to access the requested incident's diagnostic data.

[0035] In response to approval, a container 515 is provisioned specifically for the requested incident. In some examples, in response to provisioning the container, an engineer is notified that the container is ready and informed how to access the provisioned container. The incident-specific diagnostic data 517 provided to the container 515 may include any data, reports, or other derived data related to the incident, and the analytical tools 516 herein may include any related parsing or analysis capabilities in addition to other tools. From within the container 515, the computing device 505 does not have the ability to download any information or data from the container. Similarly, the computing device 505 does not have the ability to export data from within the container or access the Internet, external networks, or internal networks.

[0036] FIG. 6 illustrates a data access process 600 that provides an example overview of steps that may be performed by an engineer or similar user to access diagnostic data and perform tasks in accordance with the incident-specific, task-based data access policies described herein. In step 605, the engineer requests access to diagnostic data for an incident via a CDH application (e.g., CDH application 103) user interface. In step 610, upon authorization, the engineer receives access to a provisioned container for the incident. The container includes incident-specific data and a set of task-based tools, as described above. Then, in step 615, the engineer can access the container to complete one or more tasks related to the incident within the container. Upon completion of the one or more tasks, the engineer exits the container and returns to the CDH application user interface.

[0037] FIG. 7 illustrates a customer data processing process that may be performed by a user or engineer associated with a SaaS provider. In this example, incident data is not automatically uploaded to the CDH Toolkit and is instead manually added to the toolkit from the machine experiencing the issue. Thus, in step 705 of this example, a user logs into the virtual machine or server experiencing the issue. In some examples, a user or customer of a SaaS offering may have reported a problem or incident, thereby indicating that an engineer should upload associated data to the CDH Toolkit to investigate the incident. In step 710, the engineer collects data related to the incident and adds the data to the CDH Toolkit.

[0038] In step 715, the engineer accesses the data added to the CDH Toolkit through a container provisioned by the CDH Toolkit, along with the analysis tools provided in the container. This container is accessed through the CDH Toolkit system, and the only data provided in the container is data for the specific problem or task the engineer is to perform. In some examples, accessing the container requires approval through a data access authorization system before the container is provisioned by the CDH Toolkit. Once the engineer accesses the container, they can perform analysis or tasks related to the problem or incident, as shown in step 720, which may include actions such as troubleshooting or parsing, as just a few examples. Once the engineer has finished any or all tasks or analysis, they can exit the container in step 725, at which point the container and the copy of the data in the container are either automatically purged or queued for later purging.

[0039] FIG. 8 illustrates various data categories in table 800 that may be used by a service provider (e.g., SaaS, PaaS, IaaS, private cloud, on-premises, etc.) to control data usage, according to certain embodiments of the present technology. The columns in Table 8 include the data category, allowed attachments, whether the data can be shared outside the cloud network, and whether the data is pre-approved. The data categories shown in Table 8 include "Your Content," "Customer Data," "Service Analytics Data," "Diagnostic Data," and "Control Data." Different types of data may be subject to different restrictions. Data can be separated according to the data categories included in table 800, per incident and per cloud service. Separating data into categories enables compliance with contractual obligations through an established set of patterns for each data type, as further described with reference to FIG. 9.

[0040] Figure 9 illustrates various CDH toolkit patterns that may be used by cloud providers to ensure compliance with contractual obligations and regulations. Figure 9 includes CDH toolkit pattern 900. CDH toolkit pattern 900 includes commercial cloud services 905 and specialized cloud services 910. Commercial cloud services 905 include private cloud 906 and public cloud 907 patterns. Specialized cloud services 910 include European Union Restricted Access (EURA) services 911, government services 912, Payment Card Industry (PCI) compliant services 913, and Health Insurance Portability and Accountability Act (HIPAA) compliant services 914.

[0041] The CDH Toolkit pattern can be used to separate data sets based on various regulations that a customer may be subject to. Different cloud customers may fall into different categories and therefore be separated into different instances of the CDH Toolkit as shown in CDH Toolkit pattern 900. The different instances of the CDH Toolkit are separated so that each instance can adhere to the pattern rules for policies related to data access, data residency, etc. In some examples, the same CDH application may be used on the front end to access data in different instances of the CDH Toolkit, but on the back end, these instances are provisioned in different data centers or different regions.

[0042] 10 illustrates a computing system 1001 that represents any system or collection of systems in which the various processes, systems, programs, services, and scenarios disclosed herein may be implemented. Examples of computing systems 1001 include, but are not limited to, desktop computers, laptop computers, server computers, routers, web servers, cloud computing platforms, and data center equipment, as well as other types of physical or virtual server machines, physical or virtual routers, containers, and any variation or combination thereof.

[0043] The computing system 1001 may be implemented as a single apparatus, system, or device, or may be implemented in a distributed manner as multiple apparatuses, systems, or devices. The computing system 1001 includes, but is not limited to, a processing system 1002, a storage system 1003, software 1005, a communication interface system 1007, and an optional user interface system 1009. The processing system 1002 is operatively coupled to the storage system 1003, the communication interface system 1007, and the user interface system 1009.

[0044] Processing system 1002 loads and executes software 1005 from storage system 1003. Software 1005 includes and executes customer data processing processes 1006, which may represent any of the customer data processing processes described with respect to the previous figures. When executed by processing system 1002 to provide a customer data processing toolkit, software 1005 directs processing system 1002 to operate as described herein, at least for the various processes, operational scenarios, and sequences described in the previous implementations. Computing system 1001 may optionally include still other devices, features, or functionality not described for purposes of brevity.

[0045] 10, processing system 1002 may include a microprocessor and other circuitry that retrieves and executes software 1005 from storage system 1003. Processing system 1002 may be implemented within a single processing device, or may be distributed across multiple processing devices or subsystems that cooperate in executing program instructions. Examples of processing system 1002 include general-purpose central processing units, graphical processing units, application-specific processors and logic devices, and other types of processing devices, combinations or variations thereof.

[0046] Storage system 1003 may include any computer-readable storage medium that is readable by processing system 1002 and capable of storing software 1005. Storage system 1003 may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Examples of storage media include random access memory, read-only memory, magnetic disks, optical disks, optical media, flash memory, virtual and non-virtual memory, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other suitable storage media. In no case is the computer-readable storage medium a propagating signal.

[0047] In addition to computer-readable storage media, in some implementations, storage system 1003 may also include computer-readable communications media through which at least a portion of software 1005 may be communicated internally or externally. Storage system 1003 may be implemented as a single storage device, or across multiple storage devices or subsystems that are co-located or distributed with respect to each other. Storage system 1003 may include further elements, such as a controller, that may communicate with processing system 1002 or possibly other systems.

[0048] Software 1005 (including customer data processing process 1006) may be embodied in program instructions that, among other functions, when executed by processing system 1002, may direct processing system 1002 to operate as described with respect to the various operational scenarios, sequences, and processes illustrated herein. For example, software 1005 may include program instructions for implementing the secure diagnostic data processing system described herein.

[0049] In particular, these program instructions may include various components or modules that cooperate or interact to perform the various processes and operational scenarios described herein. These various components or modules may be embodied with compiled or interpreted instructions, or other variations or combinations of instructions. These various components or modules may be executed synchronously or asynchronously, serially or in parallel, in single-threaded or multi-threaded environments, or according to any other suitable execution paradigm, variation, or combination thereof. Software 1005 may include still other processes, programs, or components, such as operating system software, virtualization software, or other application software. Software 1005 may also include firmware or other forms of machine-readable processing instructions executable by processing system 1002.

[0050] In general, when loaded and executed on processing system 1002, software 1005 may transform an entire suitable apparatus, system, or device (of which computing system 1001 is representative) from a general-purpose computing system to a special-purpose computing system customized to provide the customer data processing toolkit described herein. Indeed, encoding software 1005 on storage system 1003 may transform the physical structure of storage system 1003. The specific transformation of such physical structure may depend on various factors in various implementations of this description. Examples of such factors may include, but are not limited to, the technology used to implement the storage media of storage system 1003, whether the computer storage media is characterized as primary or secondary storage, and other factors.

[0051] For example, if the computer-readable storage medium is embodied as a semiconductor-based memory, the software 1005 may transform the physical structure of the semiconductor memory when the program instructions are encoded therein, such as by changing the state of transistors, capacitors, or other discrete circuit elements that make up the semiconductor memory. Similar transformations may be made to magnetic or optical media. Other transformations of physical media are possible without departing from the scope of this description, and the above examples are provided solely to facilitate this description.

[0052] The communications interface system 1007 may include communications connections and devices that enable communication with other computing systems (not shown) over a communications network (not shown). Examples of connections and devices that together enable inter-system communications may include network interface cards, antennas, power amplifiers, radio-frequency (RF) circuitry, transceivers, and other communications circuitry. These connections and devices may communicate over a communications medium to exchange communications with other computing systems or networks of systems, such as metal, glass, air, or other suitable communications medium. The above media, connections, and devices are well known and need not be described in detail here.

[0053] Communications between computing system 1001 and other computing systems (not shown) may occur over communications networks according to various communications protocols, combinations of protocols, or variations thereof. Examples include intranets, interworking networks, the Internet, local area networks, wide area networks, wireless networks, wired networks, virtual networks, software-defined networks, data center buses and backplanes, or other types of networks, combinations of networks, or variations thereof. The above communications networks and protocols are well known and need not be described in detail here.

[0054] While some examples provided herein are described in the context of SaaS offerings, SaaS customer data, cloud storage, and / or data centers, it should be understood that the customer data processing systems and methods described herein are not limited to such embodiments and may be applied to various other data processing environments and their associated systems. As will be appreciated by those skilled in the art, aspects of the present invention may be embodied as systems, methods, computer program products, and other configurable systems. Accordingly, aspects of the present invention may take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects, all of which may be generally referred to herein as “circuits,” “modules,” or “systems.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer-readable medium(s) having computer-readable program code embodied therein.

[0055] Unless the context clearly dictates otherwise, throughout the specification and claims, words like "comprise," "comprising," and the like, should be construed in an inclusive sense, i.e., "including, but not limited to," as opposed to an exclusive or exhaustive sense. As used herein, the words "connected," "coupled," or any variation thereof, mean any direct or indirect connection or coupling between two or more elements, and such coupling or connection between elements may be physical, logical, or a combination thereof. Furthermore, the words "herein," "above," "below," and words of similar import, when used in this application, refer to this application as a whole and not to any particular portions of this application. Where the context permits, words using the singular or plural number in the above Detailed Description may also include the plural or singular number respectively. The word "or" in reference to a list of two or more items covers all of the following interpretations of the word: any of the items in the list, all of the items in the list, and any combination of the items in the list.

[0056] Phrases such as "in some embodiments," "according to some embodiments," "in the embodiments shown," "in other embodiments," and the like generally mean that the particular feature, structure, or characteristic that follows the phrase is included in at least one implementation of the technology and may be included in more than one implementation. Also, such phrases do not necessarily refer to the same or different embodiments.

[0057] The above detailed description of examples of the present technology is not intended to be exhaustive or to limit the present technology to the precise form described above. While specific examples of the present technology have been described above for illustrative purposes, those skilled in the art will recognize that various equivalent modifications are possible within the scope of the present technology. For example, while processes or blocks are presented in a given order, alternative implementations may perform routines or utilize systems having blocks in a different order, or may remove, move, add, sub-divide, combine, and / or modify some processes or blocks to provide alternatives or subcombinations. Each of these processes or blocks may be implemented in a variety of different ways. Also, while processes or blocks are sometimes shown as being performed in series, these processes or blocks may instead be performed or implemented in parallel, or may be performed at different times. Furthermore, any specific numerical values set forth herein are merely examples. Alternative implementations may utilize different values or ranges.

[0058] The teachings of the technology provided herein may be applied to other systems, not necessarily those described above. Elements and operations of the various examples described above may be combined to provide further implementations of the technology. Some alternative implementations of the technology may include fewer elements as well as additional elements relative to those implementations described above.

[0059] These and other changes can be made to the present technology in light of the above detailed description. While the above description describes particular examples of the present technology and describes the best mode contemplated, no matter how detailed the above text may be, the present technology can be implemented in many ways. The details of the system may vary significantly in its specific implementation and still be encompassed by the technology disclosed herein. As noted above, specific terminology used in describing particular features or aspects of the present technology should not be construed to imply that the terminology has been redefined herein to be limited to any particular characteristic, feature, or aspect of the technology with which it is associated. In general, the words used in the following claims should not be construed to limit the technology to the specific examples disclosed in the specification, unless the Detailed Description section above expressly defines such words. Thus, the actual scope of the present technology encompasses not only the disclosed examples, but also all equivalent ways of practicing or implementing the technology under the scope of the claims.

[0060] To reduce the number of claims, certain aspects of the present technology are presented below in particular claim formats, but Applicant contemplates various aspects of the present technology in any number of claim formats. For example, while only one aspect of the present technology is recited as a computer-readable medium claim, other aspects may likewise be embodied as computer-readable medium claims or in other formats, such as means-plus-function claims. Any claim intended to be treated under 35 U.S.C. 112(f) begins with the words "means for," but the use of the word "for" in other contexts is not intended to seek treatment under 35 U.S.C. 112(f). Accordingly, Applicant reserves the right to pursue additional claims after filing this application, and to pursue such additional claim formats in either the present application or any continuing application.

Claims

1. 1. A computing device for processing customer data, comprising: one or more computer-readable storage media; one or more processing systems; and program instructions stored on the one or more computer-readable storage media, the program instructions, when executed by the one or more processing systems, causing the one or more processing systems to: and in response to a request from a data accessor to access data for a task, identifying data associated with the task stored in a data repository, the data being incident data including an occurrence of an event or condition related to a service, the program instructions further, when executed by the one or more processing systems, causing the one or more processing systems to: provisioning a separate instance of the data repository for each specialized production environment or cloud that must adhere to different constraints; and provisioning a container for the task, the container including the data associated with the task and at least one data analysis tool, the program instructions further, when executed by the one or more processing systems, causing the one or more processing systems to: providing access to the container to the data accessor; and erasing the container from the computing device after the data accessor has left the container; The computing device, wherein the data repository is configured to delete the data after a predetermined time that is greater than the lifetime of the container.

2. The computing device of claim 1 , wherein providing the data accessor with access to the container comprises providing the same application for accessing each of the separate instances of the data repository.

3. 3. The computing device of claim 1, wherein the program instructions further direct the one or more processing systems to maintain the data repository, the data repository containing data for multiple tasks.

4. The program instructions further cause the one or more processing systems to, before provisioning the container for the task, configure the data accessor to access the data associated with the task.

4. A computing device according to claim 1, further comprising instructions to determine whether access to the associated data is authorized.

5. 5. The computing device of claim 1, wherein the program instructions further direct the one or more processing systems to, after provisioning the container for the task, notify the data accessor that the container is ready.

6. The computing device of any preceding claim, wherein the container prevents the data accessor from exporting the data associated with the task from the container.

7. 7. The computing device of claim 1, wherein the program instructions further instruct the one or more processing systems to detect when the data accessor has exited the container before erasing the container from the computing device.

8. The computing device of any preceding claim, wherein the container is hosted on a virtual machine.

9. 9. The computing device of claim 1, wherein the program instructions direct the one or more processing systems to: identify a wait time for erasing the container, and erase the container from the computing device once the wait time has elapsed, in order to erase the container from the computing device.

10. 1. A computer-implemented method for securely processing customer data, comprising: identifying data stored in a data repository associated with an incident comprising an occurrence of an event or condition related to the service; provisioning a separate instance of the data repository for each specialized production environment or cloud that must adhere to different constraints; and provisioning a container for the incident, the container including the data associated with the incident and at least one data analysis tool, the method further comprising: providing access to the container to a data accessor; and erasing the container after the data accessor has left the container; The method, wherein the data repository is configured to delete the data after a predetermined time that is greater than the lifetime of the container.

11. The method of claim 10 , wherein providing access to the container to the data accessor comprises providing the same application for accessing each of the separate instances of the data repository.

12. The method of claim 10 or 11, further comprising maintaining the data repository, the data repository containing data for a plurality of incidents.

13. The method of any of claims 10 to 12, further comprising the step of determining whether the data accessor is authorized to access the data associated with the incident prior to the step of provisioning the container for the incident.

14. The method of any of claims 10 to 13, further comprising the step of, after the step of provisioning the container for the incident, notifying the data accessor that the container is ready.

15. The method of any of claims 10 to 14, wherein the container prevents the data accessor from exporting the data associated with the incident from the container.

16. The method according to any one of claims 10 to 15, further comprising the step of detecting that the data accessor has left the container before the step of erasing the container.

17. The method according to any of claims 10 to 16, wherein the container is hosted on a virtual machine.

18. A method according to any one of claims 10 to 17, wherein erasing the container comprises identifying a waiting time for erasing the container and erasing the container once the waiting time has elapsed.

19. A program for causing a processing system to execute the method according to any one of claims 10 to 18.

Images