System-generated dataset encryption key

Abstract

Generate a unique data encryption key for a dataset by assigning a dataset associated with a security policy, wherein the security policy specifies a key encryption key (KEK) tag; retrieving the KEK tag from the security policy; storing the KEK tag as metadata for the dataset; opening the dataset for a first write; generating a data encryption key (DEK); retrieving the KEK from a key repository based on the KEK tag; encrypting the DEK using the KEK; storing the encrypted DEK as metadata for the dataset; and encrypting the dataset using the DEK.

Description

Background Art

[0001] The present disclosure generally relates to generating data encryption keys (DEKs). The present disclosure specifically relates to systematically generating DEKs for files and datasets and enabling efficient rekeying of files and datasets. As used herein, the term "dataset" broadly refers to digital files and datasets.

[0002] Data encryption is an effective way to reduce the risk of data breaches. Deploying encryption policies can be complex. There is growing interest in using dataset-level encryption, where the underlying operating system performs encryption on behalf of each application without requiring application changes. Enterprise security architects deploying dataset-level encryption on behalf of their organizations may be responsible for determining new policies and procedures related to data encryption. For example, some security policies require periodic re-encryption of encrypted data with new DEKs. Summary of the Invention

[0003] The following is an overview presented to provide a basic understanding of one or more embodiments of the present disclosure. This overview is not intended to identify key or important elements or to delineate any scope of a particular embodiment or any scope of the claims. Its sole purpose is to present the concepts in a simplified form as a prelude to the more detailed description presented later. In one or more embodiments described herein, an apparatus, system, computer-implemented method, device, and / or computer program product enables generation of a data encryption key (DEK) for a data set.

[0004] Various aspects of the present invention disclose methods, systems, and computer-readable media associated with improving the ability to generate unique data encryption keys for a dataset by assigning a dataset associated with a security policy, where the security policy specifies a key encryption key (KEK) tag, retrieving the KEK tag from the security policy, storing the KEK tag as metadata of the dataset, opening the dataset for a first write, generating a data encryption key (DEK); retrieving the KEK from a key repository based on the KEK tag; encrypting the DEK using the KEK; storing the encrypted DEK as metadata of the dataset; and encrypting the dataset using the DEK. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The above and other objects, features and advantages of the present disclosure will become more apparent through a more detailed description of some embodiments of the present disclosure in the accompanying drawings, in which like reference numerals generally refer to like components in the embodiments of the present disclosure.

[0006] Figure 1 A schematic diagram of a functional block diagram of a system according to an embodiment of the present invention is provided.

[0007] Figure 2A schematic diagram of a system according to an embodiment of the present invention is provided.

[0008] Figure 3 A flow chart depicting an operational key generation sequence according to an embodiment of the present invention is provided.

[0009] Figure 4 A flow chart illustrating an operational read sequence according to an embodiment of the present invention is provided.

[0010] Figure 5 A flow chart is provided depicting the target of an operation for a dataset rekey operation according to an embodiment of the present invention, wherein the read sequence of the source is determined by Figure 4 Logo.

[0011] Figure 6 A cloud computing environment according to an embodiment of the present invention is shown.

[0012] Figure 7 An abstract model layer according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0013] Some embodiments will be described in more detail with reference to the accompanying drawings, in which embodiments of the present disclosure are shown. However, the present disclosure can be implemented in various ways and should not be construed as limited to the embodiments disclosed herein.

[0014] In one embodiment, one or more components of the system may employ hardware and / or software to solve problems that are highly technical in nature (e.g., opening an encrypted data set, verifying user authorization for a KEK tag, retrieving a KEK associated with the KEK tag from a key repository, providing the KEK to a storage management subsystem (SMS), reading an encrypted DEK from metadata for the data set, decrypting the DEK using the KEK, and then decrypting the data set using the decrypted DEK, etc.). These solutions are not abstract and cannot be performed by a human as a set of mental actions due to, for example, the processing power required to facilitate encryption key generation. Further, some of the processes performed may be performed by a dedicated computer for performing defined tasks related to memory operations. For example, a dedicated computer may be employed to perform tasks related to generating encryption keys, etc.

[0015] Dataset-level encryption refers to policy-based, application-transparent encryption of data stored in datasets. Typically, cryptographic key officers are responsible for creating and maintaining keys within an enterprise organization. They generate DEKs that are persistently stored in a key repository identified by a unique key tag. To implement dataset-level encryption for a collection of datasets, a key tag can be added to the security policy associated with the dataset intended to be encrypted. To control access to data in plain text, a security administrator can grant data owners permission for a dataset and the dataset DEK tag associated with the dataset. To restrict access to data in plain text, a security administrator can grant storage administrators only permission for the dataset, without granting permission for the DEK tag associated with the dataset. When a data owner writes to or reads from a dataset with the permission of the dataset and the DEK tag, the data is encrypted or decrypted using the DEK. Storage administrators who only have permission for the dataset can allocate and manage datasets, but cannot write to or read from the dataset without permission for the DEK tag, and therefore cannot access the data in plain text.

[0016] The amount of data encrypted by organizations continues to grow as data breaches become more prevalent. With dataset-level encryption, the process of distributing a new encrypted dataset typically requires application outages. Re-encrypting an existing encrypted dataset with a new DEK typically requires additional application outages. Depending on the frequency required to re-encrypt datasets with new DEKs, as defined in security policies, the number of outages can impact daily business operations.

[0017] The typical process of re-encrypting a dataset with a new DEK, also known as a rekey operation, involves a number of steps. In this example, the DEK tag is provided to the Storage Management Subsystem (SMS) via a dataset security policy defined by a security administrator that can be verified by the System Authorization Facility (SAF). Similar steps will be required regardless of how the DEK tag is provided to the system. This process involves at least 8 steps: generating a new DEK with a new key tag, locating all dataset security policies associated with the old DEK tag, updating the aforementioned dataset security policies with the new DEK tag, identifying all datasets encrypted with the old DEK tag, assigning the new dataset associated with the newly updated dataset security policy, copying data from the old dataset to the new dataset, deleting the old dataset, and archiving or setting an expiration date for the old DEK.

[0018] Various aspects of the present invention disclose methods, systems, and computer-readable media associated with improving the ability to rotate data encryption keys (DEKs) by having the operating system generate a unique DEK at the first dataset open time, which is encrypted with a key encryption key (KEK) and then stored in the metadata of the dataset it encrypted. This process requires the security administrator to specify the KEK tag instead of the DEK tag in the dataset security policy. The System Authorization Facility (SAF) can then verify the KEK tag and the user's authorization to access the KEK tag.

[0019] The data owner or storage administrator allocates a dataset associated with the dataset security policy. The SAF verifies the user's authorization for the dataset and the KEK tag, and retrieves the KEK tag from the associated dataset security policy. The disclosed method then stores the retrieved KEK tag in the metadata of the dataset. When the data owner opens the newly allocated dataset for the first write, the SMS calls the SAF to verify the user's authorization for the KEK tag, retrieves the KEK from the key repository, generates a unique DEK, encrypts the DEK using the KEK, and stores the encrypted DEK in the metadata of the dataset. The method then encrypts the dataset using the DEK. Encryption includes writing the encrypted data in the space allocated for the dataset.

[0020] Various aspects of the present invention disclose methods, systems, and computer-readable media associated with enabling the ability to read an encrypted dataset by opening the encrypted dataset, retrieving a KEK associated with a KEK tag from a key repository based on the KEK tag, retrieving an encrypted data encryption key (DEK) from dataset metadata, decrypting the DEK using the KEK, decrypting the dataset using the DEK, and providing user access to the dataset data.

[0021] To complete a dataset rekey operation, the data owner simply copies the data from the old encrypted dataset to a new dataset that is transparently encrypted using the newly generated DEK. The end result is a new dataset encrypted with the new DEK, with both the KEK tag and the encrypted DEK stored in the metadata of the new dataset. The DEK is unique to that dataset and is never stored outside of the dataset metadata.

[0022] Aspects of the present invention disclose methods, systems, and computer-readable media associated with improving the ability to replicate encrypted datasets by: assigning a target dataset associated with a security policy, retrieving a KEK tag from the security policy, storing the KEK tag as target dataset metadata, opening the target dataset for a first write, generating a target dataset data encryption key (DEK), retrieving the KEK from a key repository based on the KEK tag, encrypting the target dataset DEK using the KEK, storing the encrypted DEK as target dataset metadata; and encrypting a source dataset to the target dataset using the target dataset DEK.

[0023] A typical key update or key rotation process may include the following steps: generating a new data encryption key (DEK) with a new DEK label; locating all dataset security policies associated with the old DEK label; updating the dataset security policy with the new DEK label; identifying all datasets encrypted with the old DEK label; assigning the new dataset associated with the newly updated dataset security policy; copying data from the old dataset to the new dataset; deleting the old dataset; and archiving or setting an expiration date for the old DEK. The process represents a significant burden to coordinate the rotation or key update of all datasets encrypted using a single DEK. The disclosed methods and procedures provide a simplified process for rekeying datasets and enable staggered key updates of datasets across a collection of encrypted datasets.

[0024] In an embodiment, defining or allocating resources for a new dataset includes referencing a dataset security policy that includes a key encryption key (KEK) tag instead of a data encryption key (DEK) tag for the dataset. The KEK tag refers to a KEK stored in a cryptographic key repository. In this embodiment, upon first opening a dataset, the method retrieves the KEK tag from the dataset security policy and stores the KEK tag as dataset metadata. The method generates a unique DEK for the dataset. The method retrieves the KEK from the key repository using the KEK tag, encrypts the DEK using the KEK, and stores the encrypted DEK in the metadata of the dataset. The method encrypts the dataset using the DEK and writes the encrypted dataset to the allocated storage location.

[0025] In an embodiment, copying an existing encrypted dataset includes accessing an existing source dataset for a data read operation and initially accessing a newly allocated target dataset for a data write operation. In this embodiment, the newly allocated target dataset is associated with the same dataset security policy as the source dataset and uses the same KEK tag as the source dataset. Opening the existing source dataset for a read operation results in retrieving a KEK from a key repository using the KEK tag stored in the metadata of the source dataset, decrypting an encrypted DEK stored in the metadata of the source dataset using the KEK, and decrypting data from the source dataset using the DEK. Opening the newly allocated target dataset for a write (copy) operation results in retrieving a KEK from a key repository using the KEK tag stored in the metadata of the target dataset, generating a unique DEK for the target dataset, encrypting the DEK using the KEK, storing the encrypted DEK in the metadata of the target dataset, encrypting data from the source dataset using the newly generated DEK from the target dataset, and writing the newly encrypted data to the target dataset. By generating and using a new DEK for the target dataset, copying the existing encrypted source dataset effectively rekeys the dataset without changing the dataset security policy, KEK tag, or key repository.

[0026] In an embodiment, rekeying an existing encrypted dataset according to a dataset security policy simply requires allocating a new dataset according to the policy, copying the existing dataset to the new dataset—including generating a new DEK for the new dataset, encrypting the new DEK using the KEK associated with the KEK tag stored in the dataset's metadata, storing the encrypted DEK as new dataset metadata, and then encrypting and writing the new dataset using the DEK. In an embodiment, deleting the old dataset after copying completes the rekeying process.

[0027] Each dataset is encrypted using a unique DEK encrypted by a KEK. A single KEK can be used as a shared KEK across a collection of datasets. The combination of unique DEKs and shared KEKs enables staggered rekeying of datasets, as each rekeyed dataset acquires a new unique DEK without a new KEK, eliminating the need to rekey all datasets at once and the attendant system outages associated with mass rekeying of datasets.

[0028] In an embodiment, the System Authorization Facility (SAF) includes a defined system-level dataset security policy that indicates whether key tags in the dataset security policy should be treated as KEK tags or DEK tags. On a newly allocated dataset, the key tag is read from the dataset security policy and stored in the dataset metadata (e.g., cryptographic unit) along with an indicator designating the key tag as a KEK tag or a DEK tag.

[0029] In an embodiment, a user (storage administrator) may be authorized to access a dataset but not the associated KEK tag, thereby enabling the storage administrator to manipulate the dataset as needed without gaining access to the actual dataset data. In an embodiment, a dataset user may have access to a KEK tag and the associated KEK, but may not have access to all datasets associated with the KEK tag and KEK. Since each KEK and KEK tag may be reused across multiple datasets, verified user authorization for the KEK tag is necessary but not sufficient to enable a user to access the dataset data. Only users with verified authorization for the dataset and KEK tag can access the underlying dataset data. In this embodiment, the method verifies each user for authorization for each of the relevant datasets and associated KEK tags.

[0030] In an embodiment, Dataset-1 protected by KEK-1 associated with the KEK-1 tag and encrypted with DEK-1 may be rekeyed – undergo encryption key rotation – by the following steps:

[0031] a. Allocate a new dataset-2 associated with KEK-1 and the KEK-1 label according to the dataset security policy of dataset-1;

[0032] b. Open the new dataset-2, resulting in the generation of DEK-2;

[0033] c. Use KEK-1 to encrypt DEK-2. DEK-2 and KEK-1 label are stored with Dataset-2 as encrypted metadata; and

[0034] d. Copy the data from the source dataset to the new dataset - decrypt DEK-1 using KEK-1 associated with the KEK-1 tag. The data from dataset-1 is decrypted using DEK-1 and then encrypted using DEK-2.

[0035] This example includes appropriate steps by the SMS to verify user authorization to access the data set and the KEK-1 tag.

[0036] As used herein, SAF (System Authorization Facility), key repository, SMS (Storage Management Subsystem), KEK (Key Encryption Key), DEK (Data Encryption Key), and cryptographic provider comprise software modules of a computing environment utilized by the disclosed cryptographic key update method. CFHE (Cryptographic Function Hardware Engine) comprises a hardware engine of a computing environment that is called to perform cryptographic functions to support the disclosed key update method.

[0037] Figure 1 A functional block diagram illustrating the relationship between the various system components of the disclosed embodiment is provided. As shown, the SMS 12 receives a user data set request 10. After receiving the user data set request 10, the SMS 12 opens the allocated and existing data sets and scans the metadata of the data sets to obtain the encryption key information (KEK tag).

[0038] In an embodiment, SMS allocates new datasets based on the security policy defined for that dataset. The security policy includes any KEK tags assigned to the dataset and a list of users authorized to access the dataset. The SAF also maintains a list of users authorized to access each KEK tag. When allocating a dataset, SMS saves the dataset KEK tag as part of the dataset's encryption metadata.

[0039] SMS 12 queries SAF 14 for the dataset security policy to verify the requesting user's authorization to access the dataset and the associated KEK tag. After verifying the user's authorization to access the dataset and the associated KEK tag, SMS 12 passes the KEK tag from the dataset metadata to cryptographic provider 16. Cryptographic provider 16 uses the KEK tag to look up the KEK in key repository 18. In an embodiment, cryptographic provider 16 passes the KEK to SMS 12.

[0040] In an embodiment, for a new data set, SMS 12 calls cryptographic provider 16 to generate a DEK for the data set, encrypts the DEK using KEK, encrypts the data set using DEK, and writes data. SMS stores the encrypted DEK as metadata in the cryptographic unit associated with the assigned data set.

[0041] For an existing data set, SMS 12 verifies the requesting user's access to the data set and the KEK tag, and calls cryptographic provider 16 to decrypt the data set's DEK using the KEK, and then uses the DEK to decrypt the data set's data for access by user 10. In an embodiment, SMS 12 calls CFHE 20 to decrypt the data set using the decrypted DEK.

[0042] Figure 2A schematic diagram of exemplary network resources associated with practicing the disclosed invention is provided. The present invention may be practiced in a processor of any disclosed element that processes an instruction stream. As shown, a networked client device 110 is wirelessly connected to a server subsystem 102. A client device 104 is wirelessly connected to the server subsystem 102 via a network 114. The client devices 104 and 110 include a data set encryption key update program (not shown) along with sufficient computing resources (processor, memory, network communication hardware) for executing the program. Figure 2 As shown, server subsystem 102 includes server computer 150 . Figure 2 A block diagram of components of a server computer 150 within a networked computer system 1000 is depicted in accordance with an embodiment of the present invention. It should be understood that Figure 2 This merely provides an illustration of one implementation and does not imply any limitations with regard to the environments in which different embodiments may be implemented. Many modifications may be made to the depicted environments.

[0043] Server computer 150 may include processor(s) 154, memory 158, persistent storage 170, communication unit 152, input / output (I / O) interface(s) 156, and communication fabric 140. Processor 154 may include a CFHE (not shown) for performing specialized cryptographic functions. Communication fabric 140 provides communication between cache 162, memory 158, persistent storage 170, communication unit 152, and input / output (I / O) interface(s) 156. Communication fabric 140 may be implemented using any architecture designed to transfer data and / or control information between processors (such as microprocessors, communication and network processors, etc.), system memory, peripheral devices, and any other hardware components within the system. For example, communication fabric 140 may be implemented using one or more buses.

[0044] Memory 158 and permanent storage 170 are computer-readable storage media. In this embodiment, memory 158 includes random access memory (RAM) 160. In general, memory 158 may include any suitable volatile or non-volatile computer-readable storage media. Cache 162 is a fast memory that enhances the performance of processor(s) 154 by storing recently accessed data from memory 158 and data near recently accessed data.

[0045] Program instructions and data for implementing embodiments of the present invention (e.g., encryption program 175) are stored in persistent storage 170 for execution and / or access by one or more of the corresponding processor(s) 154 of server computer 150 via cache 162. In this embodiment, persistent storage 170 comprises a magnetic hard drive. As an alternative to or in addition to a magnetic hard drive, persistent storage 170 may comprise a solid-state hard drive, a semiconductor memory device, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), flash memory, or any other computer-readable storage medium capable of storing program instructions or digital information.

[0046] The media used by persistent storage 170 may also be removable. For example, a removable hard drive may be used for persistent storage 170. Other examples include optical and magnetic disks, thumb drives, and smart cards, which are inserted into a drive for transfer to another computer-readable storage medium (which is also part of persistent storage 170).

[0047] In these examples, communications unit 152 provides for communications with other data processing systems or devices, including resources of client computing devices 104 and 110. In these examples, communications unit 152 includes one or more network interface cards. Communications unit 152 may provide for communications using either or both physical and wireless communication links. Software distribution programs, as well as other programs and data used to implement the present invention, may be downloaded to persistent storage 170 of server computer 150 via communications unit 152.

[0048] The I / O interface(s) 156 allow for input and output of data to and from other devices that may be connected to the server computer 150. For example, the I / O interface(s) 156 may provide a connection to an external device(s) 190, such as a keyboard, a keypad, a touch screen, a microphone, a digital camera, and / or some other suitable input device. The external device(s) 190 may also include portable computer-readable storage media, such as, for example, a thumb drive, a portable optical or magnetic disk, and a memory card. Software and data for implementing embodiments of the present invention (e.g., the encryption program 175 on the server computer 150) may be stored on such portable computer-readable storage media and may be loaded onto the permanent storage device 170 via the I / O interface(s) 156. The I / O interface(s) 156 are also connected to the display 180.

[0049] Display 180 provides a mechanism for displaying data to a user and may be, for example, a computer monitor. Display 180 may also function as a touch screen, such as the display of a tablet computer.

[0050] Figure 3 A flowchart 300 is provided, illustrating exemplary operational steps for creating a new dataset according to an embodiment of the present invention. According to flowchart 300, at block 310, the method of encryption program 175 allocates a new dataset upon a user request using parameters associated with the dataset security policy, including the use of a KEK tag for the dataset and the KEK tag itself. At block 320, the method retrieves the KEK tag from the dataset security policy, and at block 330, the method stores the KEK tag as encryption metadata for the dataset.

[0051] At block 340, the method opens the newly allocated data set for the first write of data to the data set. In conjunction with opening the data set for the first write, at block 350, the method generates - or has generated by the cryptographic provider - a data set-specific DEK.

[0052] At block 360, the method retrieves the KEK from the key repository based on the dataset's KEK tag. At block 370, the method encrypts the dataset DEK using the retrieved KEK, or causes a cryptographic provider to encrypt the DEK using the KEK. At block 380, the method retains the DEK in volatile memory for use in encrypting the dataset's data and stores the encrypted DEK as dataset metadata in the dataset's encryption metadata unit. At block 390, the method encrypts the data using the DEK in volatile memory and writes the data to the assigned dataset.

[0053] Figure 4 A flowchart 400 illustrating exemplary activities associated with practicing the present disclosure is provided. At block 410, a storage management system (SMS) receives a user request and opens an encrypted dataset. After opening the dataset, at block 420, the SMS retrieves a key encryption key (KEK) tag found in the metadata of the dataset. The SMS may request verification of the user's authorization to access the dataset and the KEK tag according to a SAF policy.

[0054] At block 430, the SMS passes the KEK tag associated with the data set to the cryptographic provider to retrieve the KEK associated with the data set via the KEK tag. The cryptographic provider looks up the KEK associated with the KEK tag in the key repository and passes the KEK to the SMS.

[0055] At block 440, the SMS retrieves the encrypted DEK from the metadata of the open dataset and decrypts the DEK using the KEK. In an embodiment, the SMS decrypts the DEK from the dataset metadata using the KEK.

[0056] At block 450, the encryption program 175 method decrypts the dataset using the DEK. In one embodiment, the SMS invokes CFHE to decrypt the dataset using the DEK. At block 460, the method provides the user with access to the decrypted data of the dataset. The KEK tag and the encrypted DEK are retained in the metadata of the encrypted dataset.

[0057] In an embodiment, after a dataset has been initially encrypted using a DEK, which is encrypted using a KEK, rekeying - rotating - changing the dataset's encryption key simply requires copying the encrypted dataset from its current dataset allocation to a new dataset allocation with the same KEK tag. During the copy execution, generation of a new DEK for the newly allocated dataset occurs with the initial write access of the dataset used to make the copy, resulting in the copy being encrypted using the new DEK while still being accessed using the original KEK. Alternatively, the new dataset SAF profile may include a new KEK tag, which results in a copy of the source dataset encrypted with the new DEK, which is further encrypted using the new KEK.

[0058] Figure 5 Flowchart 500 illustrates exemplary operational steps of encryption program 175 during the replication and rekeying of a dataset. At block 510, the method of encryption program 175 allocates a target dataset following a user request to replicate a source dataset using parameters associated with the target dataset security policy, including the use of a KEK tag for the dataset and the KEK tag itself. The dataset security policy of the source dataset, including the KEK tag of the source dataset, is applied to the target dataset. At block 520, the method retrieves the KEK tag from the target dataset security policy, and at block 530, the method stores the KEK tag as encryption metadata for the target dataset.

[0059] At block 540, the method opens the allocated target dataset for the first write of the source data to the target dataset. In conjunction with opening the target dataset for the first write, at block 550, the method generates - or has generated by the cryptographic provider - a DEK specific to the target dataset.

[0060] At block 560, the method retrieves the KEK from the key repository based on the KEK tag of the target dataset. At block 570, the method encrypts the target dataset DEK using the retrieved KEK. At block 580, the method saves the target dataset DEK in volatile memory to encrypt the data of the dataset and stores the encrypted target dataset DEK as target dataset metadata in the encryption metadata unit of the target dataset. The method of the encryption program 175 follows Figure 4The method then encrypts and writes the source data to the target dataset using the DEK in the volatile memory. In an embodiment, the method then encrypts and writes the source data to the target dataset by deleting the source data from the persistent memory (not shown).

[0061] It should be understood that although the present disclosure includes detailed descriptions about cloud computing, the implementation of the teachings cited herein is not limited to cloud computing environments. Instead, embodiments of the present invention can be implemented in conjunction with any other type of computing environment now known or later developed.

[0062] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be quickly provisioned and released with minimal management effort or interaction with the service provider. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0063] Features are as follows:

[0064] On-demand self-service: Cloud consumers can unilaterally and automatically provision computing capabilities, such as server time and network storage, as needed, without requiring human interaction with the service provider.

[0065] Broad Network Access: Capabilities are available over the network and accessed through standard mechanisms that facilitate the use of heterogeneous thin-client or thick-client platforms (e.g., mobile phones, laptops, and PDAs).

[0066] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically assigned and reassigned as needed. There is a sense of location independence, as consumers typically do not have control or knowledge of the exact location of the provided resources, but may be able to specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0067] Rapid elasticity: The ability to quickly and elastically provision capacity, in some cases automatically scaling down and releasing capacity to scale up quickly. To the consumer, the capacity available for provisioning typically appears unlimited and can be purchased in any quantity at any time.

[0068] Metered Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the utilized services.

[0069] The service model is as follows:

[0070] Software as a Service (SaaS): The ability provided to consumers is to use the provider's applications running on a cloud infrastructure. Applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0071] Platform as a Service (PaaS): The capability provided to consumers is to deploy applications created or acquired using programming languages ​​and tools supported by the provider onto cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but do have control over the deployed applications and the configuration of the application hosting environment.

[0072] Infrastructure as a Service (IaaS): The capabilities provided to consumers are processing, storage, networking, and other basic computing resources on which consumers can deploy and run arbitrary software, including operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but rather have control over the operating system, storage, deployed applications, and potentially limited control over selected networking components (e.g., host firewalls).

[0073] The deployment model is as follows:

[0074] Private cloud: Cloud infrastructure is operated solely for an organization. It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0075] Community cloud: Cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0076] Public cloud: Cloud infrastructure is made available to the public or large industry groups and is owned by the organization that sells cloud services.

[0077] Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0078] Cloud computing environments are service-oriented and focus on statelessness, low coupling, modularity, and semantic interoperability. The core of cloud computing is the infrastructure that consists of a network of interconnected nodes.

[0079] Now see Figure 6 , depicts an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud consumers can communicate, such as, for example, personal digital assistants (PDAs) or cellular phones 54A, desktop computers 54B, laptop computers 54C, and / or automobile computer systems 54N. The nodes 10 can communicate with each other. They can be grouped (not shown) physically or virtually in one or more networks, such as private clouds, community clouds, public clouds, or hybrid clouds, or a combination thereof, as described above. This allows the cloud computing environment 50 to provide infrastructure, platforms, and / or software as services for which cloud consumers do not need to maintain resources on local computing devices. It should be understood that Figure 6 The types of computing devices 54A-N shown in are intended to be illustrative only, and computing node 10 and cloud computing environment 50 may communicate with any type of computerized device over any type of network and / or network-addressable connection (eg, using a web browser).

[0080] Now see Figure 7 , showing the cloud computing environment 50 ( Figure 6 ) provides a set of functional abstraction layers. It should be understood in advance that Figure 7 The components, layers, and functions shown in are intended to be illustrative only, and embodiments of the present invention are not limited thereto. As described, the following layers and corresponding functions are provided.

[0081] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include: mainframes 61; servers based on RISC (Reduced Instruction Set Computer) architecture 62; servers 63; blade servers 64; storage devices 65; and network and networking components 66. In some embodiments, software components include web application server software 67 and database software 68.

[0082] Virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 71 ; virtual storage 72 ; virtual networks 73 , including virtual private networks; virtual applications and operating systems 74 ; and virtual clients 75 .

[0083] In one example, the management layer 80 may provide the functionality described below. Resource provisioning 81 provides dynamic procurement of computing and other resources for performing tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking when utilizing resources within the cloud computing environment and bills or invoices the consumption of these resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. User portal 83 provides access to the cloud computing environment for consumers and system administrators. Service level management 84 provides cloud computing resource allocation and management so that required service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides pre-arrangement and procurement of cloud computing resources in anticipation of future demand according to the SLA.

[0084] The workload layer 90 provides examples of functionality that can take advantage of a cloud computing environment. Examples of workloads and functionality that can be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analytics processing 94; transaction processing 95; and cryptography 175.

[0085] The present invention may be implemented as a system, method, and / or computer program product in any possible degree of integration of technical details. The present invention may be beneficially practiced in any system (single or parallel) that processes a stream of instructions. The computer program product may include a computer-readable storage medium (one or more media) having computer-readable program instructions thereon for causing a processor to perform various aspects of the present invention.

[0086] Computer-readable storage media can be a tangible device that can retain and store the instructions used by the instruction execution device.Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), static random access memories (SRAM), portable compact disc read-only memories (CD-ROM), digital versatile discs (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards, or projection structures in the grooves with instructions recorded thereon, and any suitable combination of the above. Computer-readable storage media as used herein should not be interpreted as temporary signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagated by waveguides or other transmission media (for example, light pulses passing through fiber optic cables), or electrical signals emitted by wires.

[0087] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network), or downloaded to an external computer or external storage device. The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium within the corresponding computing / processing device.

[0088] The computer-readable program instructions for performing the operation of the present invention can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, the configuration data of integrated circuit or source code or object code written in any combination of one or more programming languages, these programming languages ​​include object-oriented programming languages ​​(such as Smalltalk, C++ etc.) and process programming languages ​​(such as " C " programming languages ​​or similar programming languages). The computer-readable program instructions can be performed completely on the user's computer, partly on the user's computer, performed as an independent software package, partly on the user's computer, partly on a remote computer or fully on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer by any type of network (including local area network (LAN) or wide area network (WAN)), or can be connected to an external computer (for example, using an internet service provider through the internet). In certain embodiments, the electronic circuit comprising for example programmable logic circuit, field programmable gate array (FPGA) or programmable logic array (PLA) can make the electronic circuit personalized to perform computer-readable program instructions by utilizing the state information of computer-readable program instructions, so as to perform various aspects of the present invention.

[0089] The present invention will be described below with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0090] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, and these instructions cause the computer, programmable data processing device, and / or other equipment to operate in a specific manner, so that the computer-readable storage medium having the instructions stored therein includes an article of manufacture containing instructions that implement aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0091] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device, so that a series of operational steps are performed on the computer, other programmable apparatus, or other device to produce computer-implemented processing, so that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0092] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functions and operations of possible implementations of the systems, methods and computer program products according to different embodiments of the present invention. To this end, each box in the flowchart or block diagram may represent a module, segment or portion of an instruction, which includes one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions annotated in the box may not occur in the order annotated in the figure. For example, depending on the functions involved, two blocks shown in succession may actually be executed substantially simultaneously, or the blocks may sometimes be executed in the opposite order. It should also be noted that each box in the block diagram and / or flowchart, and the combination of the boxes in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs a specified function or action or performs a combination of dedicated hardware and computer instructions.

[0093] References in the specification to "one embodiment," "an embodiment," "an exemplary embodiment," etc., indicate that the described embodiment may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. In addition, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an embodiment, it is considered that it is within the knowledge of those skilled in the art to affect such feature, structure, or characteristic in conjunction with other embodiments (whether or not explicitly described).

[0094] The terms used herein are for the purpose of describing specific embodiments only and are not intended to limit the present invention. As used herein, unless the context clearly indicates otherwise, the singular forms "a", "an" and "the" are intended to include the plural forms as well. It should also be understood that when the terms "comprises" and / or "comprising" are used in this specification, they specify the presence of the features, wholes, steps, operations, elements and / or parts, but do not preclude the presence or addition of one or more other features, wholes, steps, operations, elements, parts and / or combinations thereof.

[0095] The description of various embodiments of the present invention has been presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the invention. The terminology used herein is selected to best explain the principles of the embodiments, practical applications, or technical improvements over technologies found in the marketplace, or to enable those skilled in the art to understand the embodiments disclosed herein.

Claims

1. A computer-implemented method for generating a unique key for a data set, the method comprising: allocating, by one or more computer processors, resources for a data set associated with a security policy, wherein the security policy specifies a key encryption key (KEK) tag; retrieving, by the one or more computer processors, a KEK tag from the security policy; storing, by the one or more computer processors, the KEK tag as metadata for the dataset; opening, by the one or more computer processors, the data set for a first write; generating, by the one or more computer processors, a data encryption key (DEK); retrieving, by the one or more computer processors, a KEK from a key repository based on the KEK tag; encrypting, by the one or more computer processors, the DEK using the KEK; storing, by the one or more computer processors, the encrypted DEK as metadata for the data set; encrypting, by the one or more computer processors, the data set using the DEK; as well as Writes an encrypted dataset to the allocated resources.

2. The computer-implemented method of claim 1 , further comprising: opening, by the one or more computer processors, the encrypted data set; retrieving, by the one or more computer processors, a KEK from the key repository based on the KEK tag of the encrypted data set; retrieving, by the one or more computer processors, an encrypted DEK from metadata of the encrypted data set; decrypting, by the one or more computer processors, the encrypted DEK using the KEK; decrypting, by the one or more computer processors, the encrypted data set using the DEK; as well as User access to the data set data is provided by the one or more computer processors.

3. The computer-implemented method of claim 1 , further comprising: distributing, by the one or more computer processors, a target data set associated with the security policy; retrieving, by the one or more computer processors, a KEK tag from the security policy; storing, by the one or more computer processors, the KEK tag as metadata of the target dataset; opening, by the one or more computer processors, the target data set for a first write; generating, by the one or more computer processors, a target data set DEK; retrieving, by the one or more computer processors, a KEK from the key repository based on the KEK tag; encrypting, by the one or more computer processors, the target data set DEK using the KEK; storing, by the one or more computer processors, the encrypted DEK as metadata for the target dataset; as well as The one or more computer processors encrypt a source data set into the target data set using the target data set DEK. The computer-implemented method of claim 3 , further comprising deleting the source data. The computer-implemented method of claim 1 , further comprising authenticating user access to the assigned data set.

6. The computer-implemented method of claim 1, further comprising authenticating user access to the KEK ticket.

7. The computer-implemented method of claim 1 , further comprising: opening, by the one or more computer processors, the encrypted source data set; retrieving, by the one or more computer processors, from the key repository a KEK associated with the KEK tag based on the KEK tag; retrieving, by the one or more computer processors, the encrypted DEK from the dataset metadata; decrypting, by the one or more computer processors, the encrypted DEK using the KEK; decrypting, by the one or more computer processors, the encrypted source data set using the DEK; distributing, by the one or more computer processors, a target data set associated with the security policy; retrieving, by the one or more computer processors, a KEK tag from the security policy; storing, by the one or more computer processors, the KEK tag as metadata of the target dataset; opening, by the one or more computer processors, the target data set for a first write; generating, by the one or more computer processors, a target data set DEK; retrieving, by the one or more computer processors, a KEK from the key repository based on the KEK tag; encrypting, by the one or more computer processors, the target data set DEK using the KEK; storing, by the one or more computer processors, the encrypted DEK as target dataset metadata; as well as The one or more computer processors encrypt the source dataset data into the target dataset using the target dataset DEK.

8. A computer program product for generating a unique key for a data set, the computer program product comprising one or more computer-readable storage devices and program instructions stored collectively on the one or more computer-readable storage devices, the stored program instructions comprising: program instructions for allocating resources for a data set associated with a security policy, wherein the security policy specifies a key encryption key (KEK) tag; program instructions for retrieving a KEK tag from the security policy; Program instructions for storing the KEK tag as metadata for the dataset; Program instructions for opening the data set for a first write; Program instructions for generating a data encryption key (DEK); program instructions for retrieving the KEK from a key repository based on the KEK tag; Program instructions for encrypting the DEK using the KEK; program instructions for storing the encrypted DEK as metadata for the data set; program instructions for encrypting the data set using the DEK; as well as Program instructions for writing an encrypted data set to the allocated resources.

9. The computer program product of claim 8, wherein the stored program instructions further comprise: Program instructions for opening encrypted data sets; program instructions for retrieving a KEK from the key repository based on the KEK tag of the encrypted data set; program instructions for retrieving the encrypted DEK from metadata of the encrypted data set; Program instructions for decrypting the encrypted DEK using the KEK; program instructions for decrypting the encrypted data set using the DEK; as well as Program instructions for providing user access to data in the data set.

10. The computer program product of claim 8, wherein the stored program instructions further comprise: program instructions for allocating a target data set associated with the security policy; program instructions for retrieving a KEK tag from the security policy; Program instructions for storing the KEK tag as metadata of the target dataset; Program instructions for opening the target data set for first writing; Program instructions for generating a target data set DEK; program instructions for retrieving a KEK from the key repository based on the KEK tag; Program instructions for encrypting the target data set DEK using the KEK; program instructions for storing the encrypted DEK as metadata of the target data set; as well as Program instructions for encrypting a source data set into the target data set using the target data set DEK.

11. The computer program product of claim 10, the stored program instructions further comprising program instructions for deleting the source data.

12. The computer program product of claim 8, the stored program instructions further comprising program instructions for authenticating user access to the allocated data set.

13. The computer program product of claim 8, the stored program instructions further comprising program instructions for authenticating user access to the KEK tag.

14. The computer program product of claim 8, wherein the stored program instructions further comprise: program instructions for opening the encrypted source data set; program instructions for retrieving, from the key repository based on the KEK tag, a KEK associated with the KEK tag; Program instructions for retrieving the DEK from the encrypted source data set metadata; Program instructions for decrypting the DEK using the KEK; Program instructions for decrypting the encrypted source data set using the DEK; program instructions for allocating a target data set associated with the security policy; program instructions for retrieving a KEK tag from the security policy; Program instructions for storing the KEK tag as metadata of the target dataset; Program instructions for opening the target data set for first writing; Program instructions for generating a target data set DEK; program instructions for retrieving a KEK from the key repository based on the KEK tag; Program instructions for encrypting the target data set DEK using the KEK; program instructions for storing the encrypted DEK as metadata for the target data set; as well as Program instructions for encrypting the source dataset data into the target dataset using the target dataset DEK.

15. A computer system for generating a unique key for a data set, the computer system comprising: one or more computer processors; one or more computer-readable storage devices; as well as Program instructions stored on the one or more computer-readable storage devices to be executed by the one or more computer processors, the stored program instructions comprising: program instructions for allocating resources for a data set associated with a security policy, wherein the security policy specifies a key encryption key (KEK) tag; program instructions for retrieving a KEK tag from the security policy; Program instructions for storing the KEK tag as metadata for the dataset; Program instructions for opening the data set for a first write; Program instructions for generating a data encryption key (DEK); program instructions for retrieving the KEK from a key repository based on the KEK tag; Program instructions for encrypting the DEK using the KEK; program instructions for storing the encrypted DEK as metadata for the data set; Program instructions for encrypting the data set using the DEK; and Program instructions for writing an encrypted data set to the allocated resources.

16. The computer system of claim 15, wherein the stored program instructions further comprise: Program instructions for opening encrypted data sets; program instructions for retrieving a KEK from the key repository based on the KEK tag of the encrypted data set; program instructions for retrieving the encrypted DEK from metadata of the encrypted data set; Program instructions for decrypting the encrypted DEK using the KEK; Program instructions for decrypting the encrypted data set using the DEK; as well as Program instructions for providing user access to data in the data set.

17. The computer system of claim 15, wherein the stored program instructions further comprise: program instructions for allocating a target data set associated with the security policy; program instructions for retrieving a KEK tag from the security policy; Program instructions for storing the KEK tag as metadata of the target dataset; Program instructions for opening the target data set for first writing; Program instructions for generating a target data set DEK; program instructions for retrieving a KEK from the key repository based on the KEK tag; Program instructions for encrypting the target data set DEK using the KEK; program instructions for storing the encrypted DEK as metadata for the target data set; as well as Program instructions for encrypting a source data set into the target data set using the target data set DEK.

18. The computer system of claim 15, the stored program instructions further comprising program instructions for authenticating user access to the allocated data set.

19. The computer system of claim 15, the stored program instructions further comprising program instructions for authenticating user access to the KEK tag.

20. The computer system of claim 15, wherein the program instructions further comprise: Program instructions for opening the encrypted source data set; program instructions for retrieving, from the key repository based on the KEK tag, a KEK associated with the KEK tag; program instructions for retrieving the encrypted DEK from the encrypted source data set metadata; Program instructions for decrypting the encrypted DEK using the KEK; Program instructions for decrypting the encrypted source data set using the DEK; program instructions for allocating a target data set associated with the security policy; program instructions for retrieving a KEK tag from the security policy; Program instructions for storing the KEK tag as metadata of the target dataset; Program instructions for opening the target data set for first writing; Program instructions for generating a target data set DEK; program instructions for retrieving a KEK from the key repository based on the KEK tag; Program instructions for encrypting the target data set DEK using the KEK; program instructions for storing the encrypted DEK as metadata for the target data set; as well as Program instructions for encrypting the source dataset data into the target dataset using the target dataset DEK.

Images