Using key agreement to protect data

Abstract

Methods and systems for protecting customer data in a multi-tenant database environment are described. A key identifier received from a security server can be stored by an application server. The key identifier can be associated with a private key that is accessible to the security server and not accessible to the application server. A request for deriving a symmetric key can be sent from the application server to the security server, the request including a public key generated by the application server, a salt value, and a key identifier. The symmetric key can then be derived based on the sent public key and private key using a key derivation function. The application server can then receive the symmetric key and store it in an in-memory cache and be used to securely encrypt data received by the application server from a client device.

Description

[0001] Copyright Notice

[0002] A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. Technical Field

[0003] The present disclosure relates generally to data processing, and more particularly to encrypting and decrypting data. Background Art

[0004] The subject matter discussed in the background section should not be assumed to be prior art simply because it is mentioned in the background section. Similarly, problems mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which themselves may also be inventions.

[0005] The following detailed description is made with reference to the disclosed technology. Preferred embodiments are described to illustrate the disclosed technology without limiting its scope, which is defined by the claims. Those skilled in the art should recognize various equivalent changes to the description.

[0006] Existing methods for protecting data (such as customer data) stored in storage areas (e.g., databases, data stores, etc.) can be based on asymmetric or symmetric cryptography. For asymmetric cryptography, a pair of keys is used - a public key and a private key. Customer data can be encrypted using the public key and decrypted using the corresponding private key. Typically, encrypting data using the public key of an asymmetric key pair is very slow. Instead, an acceptable practice is to use a symmetric key to encrypt data. The symmetric key itself is encrypted with the public key, thereby overcoming the performance issues of asymmetric key cryptography. Summary of the invention

[0007] Methods and systems for protecting customer data in a multi-tenant database environment are described. A key identifier received from a security server over a network connection can be stored by an application server. The key identifier can be associated with a private key, wherein the private key is accessible by the security server but not by the application server. The application server can also communicate with multiple client devices over a network. A request to derive a symmetric key can be sent from the application server to the security server. The request can be sent after the application server stores the key identifier and can include a public key, a salt value, and a key identifier generated by the application server. The symmetric key can then be derived by the security server using a key derivation function based on the sent public key and private key and sent to the application server. The application server can then store the symmetric key in an in-memory cache of the application server and use it to encrypt data received from one of the multiple client devices.

[0008] Other aspects and advantages of the invention can be seen from a review of the following drawings, detailed description, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The included drawings are for illustrative purposes and are only used to provide examples of possible structures and process steps of the disclosed technology. These drawings in no way limit any changes in form and details that can be made to the embodiments by those skilled in the art without departing from the spirit and scope of the present disclosure.

[0010] Figure 1 A diagram showing an exemplary computing system that may be used with some embodiments of the present invention.

[0011] Figure 2 A diagram showing an exemplary network environment that may be used with some embodiments of the present invention.

[0012] Figure 3 An exemplary relationship between a symmetric key and a client is shown according to some embodiments.

[0013] Figure 4 A flow chart illustrating an exemplary process performed in accordance with some embodiments for encrypting customer data using a symmetric key generated using key agreement.

[0014] Figure 5 A flow chart illustrating an exemplary process for generating a request for a symmetric key generated using key agreement in accordance with some embodiments.

[0015] Figure 6 An exemplary data structure listing various symmetric keys assigned to different tenants in a multi-tenant environment is shown in accordance with various embodiments.

[0016] Figure 7 An exemplary data structure listing key identifiers and their corresponding private keys is shown in accordance with various embodiments.

[0017] Figure 8 A flow chart illustrating one exemplary process for generating a symmetric key using key agreement, performed in accordance with some embodiments.

[0018] Fig. 9 A flow chart is shown of an exemplary process for performing key rotation on an application server in accordance with various embodiments.

[0019] Fig.10 An exemplary data structure for storing rotationally symmetric keys for clients in a multi-tenant environment is shown in accordance with various embodiments.

[0020] Fig.11 An exemplary data structure showing destruction of a symmetric key is shown in accordance with various embodiments.

[0021] Fig. 12A A system diagram 800 showing architectural components of an applicable environment is shown, according to some embodiments.

[0022] Fig. 12B A system diagram further illustrating architectural components of an applicable environment is shown according to some embodiments.

[0023] Fig.13 A system diagram illustrating the architecture of a multi-tenant database environment is shown in accordance with some embodiments.

[0024] Fig.14 A system diagram further illustrating the architecture of a multi-tenant database environment is shown according to some embodiments. DETAILED DESCRIPTION

[0025] In this section, applications of systems and methods according to one or more embodiments are described. These examples are provided only to increase context and aid in understanding the present disclosure. Therefore, it will be apparent to those skilled in the art that the techniques described herein may also be implemented without some or all of these specific details. In other cases, well-known processing steps are not described in detail in order to avoid unnecessarily obscuring the present disclosure. Other applications are possible, and therefore the following embodiments should not be viewed as limiting or restricting the scope or settings.

[0026] In the following detailed description, reference is made to the accompanying drawings, which form a part of the description and in which specific embodiments are shown by way of illustration. Although these embodiments are described in sufficient detail to enable those skilled in the art to practice the present disclosure, it is to be understood that these examples are not limiting, such that other embodiments may be used and changes may be made without departing from the spirit and scope of the present disclosure.

[0027] As used herein, the term "multi-tenant database system" refers to those systems in which various elements of the database system's hardware and software can be shared by one or more clients. For example, a given application server can handle requests for a large number of clients simultaneously, and a given database table can store rows for potentially more clients.

[0028] The described subject matter can be implemented in the context of any computer-implemented system, such as a software-based system, a database system, a multi-tenant environment, etc. In addition, the described subject matter can be implemented in conjunction with two or more separate and distinct computer-implemented systems that cooperate and communicate with each other. One or more embodiments can be implemented in a variety of ways, including as a process, an apparatus, a system, a device, a method, a computer-readable medium such as a computer-readable storage medium containing computer-readable instructions or computer program code, or as a computer program product including a computer-usable medium having computer-readable program code embodied therein.

[0029] Typically, a multi-tenant database environment can include multiple databases configured to store data associated with an organization or customer. When data (also referred to as customer data) is stored by a customer, it can be unencrypted. Customer data can be encrypted using asymmetric or symmetric cryptography when at rest. Encrypted customer data protects it from being accessed by any unauthorized user. Although encrypting customer data may be important, it may be desirable to protect decryption keys (private keys or symmetric keys). Decryption keys can be stored in storage areas that only certain authorized personnel (e.g., database administrators) can access. When a customer wants to extract customer data, the encrypted customer data can be decrypted using a decryption key. The decrypted customer data can then be sent to the customer. Encrypted customer data can be stored in any storage area associated with a multi-tenant database environment, including cloud-based storage areas, non-cloud-based storage areas, or other forms of storage implementations.

[0030] One technique for protecting decryption keys is to use a hardware security module (HSM). The HSM provides on-board secure key generation and on-board key storage and management. The HSM can be used to generate asymmetric or symmetric key pairs. The HSM can store private keys in its storage device so that the private keys cannot be extracted by external parties. A password may be required to use the HSM installed in the system. The HSM can be a universal serial bus (USB) device connected via a USB port, or it can be a card device installed via a system board, or it can be a network attached device.

[0031] Traditional systems for protecting customer data may use key wrapping to generate symmetric keys that are then used to encrypt customer data. Other systems may utilize Rivest-Shamir-Adleman (RSA) encryption to allow messages to be transmitted between client systems and application servers. This approach may have several disadvantages. First, the private key must be stored on the application server, which means that there are multiple potential areas (application server and HSM server) that may compromise security. In addition, using traditional methods, the derivation of symmetric keys may involve time- and computationally expensive processing, such as password-based key wrapping. When the key derivation process takes up such a large amount of resources, the HSM is often required to store all key fragments used for encryption in a cache; for multi-tenants, this may create a significant security risk because unauthorized access to the HSM may result in a malicious user being able to access the symmetric keys of multiple entities. In addition, quantum computing has been speculated to be able to compromise RSA encryption, making customer data encrypted using RSA keys vulnerable to attack at some time in the future.

[0032] The disclosed embodiments may relate to encrypting and decrypting or protecting customer data in a computer-implemented system. The described subject matter may be implemented in the context of any computer-implemented system, such as a software-based system, a database system, a multi-tenant environment, etc. In addition, the described subject matter may be implemented in conjunction with two or more separate and distinct computer-implemented systems that collaborate and communicate with each other. One or more implementations may be implemented in a variety of ways, including as a process, an apparatus, a system, a device, a method, a computer-readable medium such as a computer-readable storage medium containing computer-readable instructions or computer program code, or as a computer program product including a computer-usable medium having computer-readable program code embodied therein.

[0033] Computer Systems

[0034] Figure 1is a diagram of an exemplary computing system that may be used with some embodiments of the present invention. Computing system 102 may be used by a customer or organization to transfer customer data to be stored in a storage area associated with a multi-tenant database environment. For example, a multi-tenant database environment may be associated with The computing system 102 may also be used to extract customer data from a storage area.

[0035] The computing system 102 is only one example of a suitable computing system such as a mobile computing system, and there is no intention to impose any limitation on the scope of use or functionality of the design. The computing system 102 should not be interpreted as having any dependency or requirement on any one or combination of the components shown. The design can operate with many other general or special computing systems. Examples of well-known computing systems, environments, and / or configurations that can be applied to the present design include, but are not limited to, personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, etc. For example, the computing system 102 can be implemented as a mobile computing system, such as a mobile computing system configured to run with an operating system (e.g., iOS) developed by Apple, Inc. of Cupertino, California, or an operating system (e.g., Android) developed by Google, Inc. of Mountain View, California.

[0036] Certain embodiments of the present invention may be described in the general context of computing system executable instructions, such as program modules, executed by a computer. Typically, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. Those skilled in the art may implement the description and / or drawings herein as computer executable instructions, which may be implemented on any form of computing machine readable media discussed below.

[0037] Some embodiments of the present invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

[0038] refer to Figure 1, the computing system 102 may include, but is not limited to, a processing unit 120 having one or more processing cores, a system memory 130, and a system bus 121 that couples various system components including the system memory 130 to the processing unit 120. The system bus 121 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) field bus, and a Peripheral Component Interconnect (PCI) bus (also known as a Mezzanine bus).

[0039] The computing system 102 typically includes various computer-readable media. Computer-readable media can be any available media that can be accessed by the computing system 102, and includes both volatile and non-volatile media, removable and non-removable media. As an example and not limitation, computer-readable media can store information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other media that can be used to store the desired information and can be accessed by the computing system 102. Communication media typically contain computer-readable instructions, data structures, or program modules.

[0040] System memory 130 may include computer storage media in the form of volatile and / or nonvolatile memory, such as read-only memory (ROM) 131 and random access memory (RAM) 132. A basic input / output system (BIOS) 133, containing the basic routines that help transfer information between elements within computing system 102, such as during startup, is typically stored in ROM 131. RAM 132 typically contains data and / or program modules that are immediately accessible to and / or currently being operated on by processing unit 120. By way of example and not limitation, Figure 1 Also shown are operating system 134 , application programs 135 , other program modules 136 , and program data 137 .

[0041] The computing system 102 may also include other removable / non-removable, volatile / non-volatile computer storage media. For example only, Figure 1Also shown are hard disk drive 141 that reads from or writes to non-removable, non-volatile magnetic media, disk drive 151 that reads from or writes to removable, non-volatile disk 152, and optical drive 155 that reads from or writes to removable, non-volatile optical disk 156, such as, for example, a CD ROM or other optical media. Other removable / non-removable, volatile / non-volatile computer storage media that may be used in the exemplary operating environment include, but are not limited to, USB drives and devices, magnetic tape cartridges, flash memory cards, digital versatile disks, digital video tapes, solid-state RAM, solid-state ROM, and the like. Hard disk drive 141 is typically connected to system bus 121 via a non-removable memory interface such as interface 140, and disk drive 151 and optical drive 155 are typically connected to system bus 121 via a removable memory interface such as interface 150.

[0042] The above discussion and Figure 1 The drives and their associated computer storage media shown in FIG. 1 provide storage of computer readable instructions, data structures, program modules and other data for the computing system 102. For example, in FIG. Figure 1 , hard disk drive 141 is shown as storing operating system 144, application programs 145, other program modules 146, and program data 147. Note that these components may be the same as or different from operating system 134, application programs 135, other program modules 136, and program data 137. Operating system 144, application programs 145, other program modules 146, and program data 147 are given different numerical designations here to illustrate that at least they are different copies.

[0043] A user may enter commands and information into the computing system 102 through input devices such as a keyboard 162, a microphone 163, and a pointing device 161, such as a mouse, a trackball, or a touch pad or touch screen. Other input devices (not shown) may include a joystick, a game pad, a scanner, or the like. These and other input devices are typically connected to the processing unit 120 through a user input interface 160 coupled to the system bus 121, but may also be connected through other interfaces and bus structures, such as a parallel port, a game port, or a universal serial bus (USB). A monitor 191 or other type of display device is also connected to the system bus 121 via an interface such as a video interface 190. In addition to the monitor, the computer may also include other peripheral output devices such as speakers 197 and a printer 196, which may be connected through an output peripheral interface 190.

[0044] The computing system 102 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer 180. Remote computer 180 can be a personal computer, handheld device, server, router, network PC, peer device or other common network node, and typically includes many or all of the elements described above with respect to the computing system 102. Figure 1 The logical connections shown in the figure include a local area network (LAN) 171 and a wide area network (WAN) 173, but other networks may also be included. Such a networking environment is common in offices, enterprise-wide computer networks, intranets and the Internet.

[0045] When used in a LAN networking environment, the computing system 102 can be connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computing system 102 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160 or other appropriate mechanism. In a networked environment, program modules or portions thereof described relative to the computing system 102 may be stored in the remote memory storage device. By way of example and not limitation, Figure 1 Remote applications 185 are shown residing on remote computer 180. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

[0046] It should be noted that some embodiments of the present invention may be used in Figure 1 However, some embodiments of the invention may be executed on a server, a computer dedicated to message processing, a handheld device, or on a distributed system, wherein different parts of the design may be executed on different parts of the distributed computing system.

[0047] Another device that can be coupled to the system bus 121 is a power source such as a battery or a direct current (DC) power supply and an alternating current (AC) adapter circuit. The DC power source can be a battery, a fuel cell, or a similar DC power source that needs to be recharged periodically. The communication module (or modem) 172 can use a wireless application protocol (WAP) to establish a wireless communication channel. The communication module 172 can implement a wireless networking standard, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard, IEEE Standard 802.11-1999, published by the IEEE in 1999.

[0048] An example of a mobile computing system may be a laptop computer, tablet computer, netbook, smart phone, personal digital assistant, or other similar device with onboard processing capability and wireless communication capabilities, which is powered by a direct current (DC) power source that supplies a DC voltage to the mobile computing system and which is only within the mobile computing system and requires periodic recharging, such as a fuel cell or battery.

[0049] network

[0050] Figure 2 A diagram of an exemplary network environment that may be used with some embodiments of the present invention is shown. Network environment 200 includes computing systems 205 and 212. One or more of computing systems 205 and 212 may be mobile computing systems. Computing systems 205 and 212 may be connected to network 250 via a cellular connection or via a Wi-Fi router (not shown). Network 250 may be the Internet. Computing systems 205 and 212 may be coupled to one or more server computing systems 255 and 260 via network 250.

[0051] Application server 255 may communicate with multiple client devices via network 250. Each computing system 205 may be associated with a client and may include a client application module 208. A user may use client computing system 205 and client application module 208 to connect to and communicate with server computing system 255 (also referred to as application server 255) and log into application 257 (e.g., The user can send customer data to the application server 255 and can request customer data from the application server 255.

[0052] The application server 255 may be coupled to a database 270 configured to store customer data. The application server 255 may be coupled to an entity (e.g., Company). An entity can generate a key pair for cryptography. The key pair includes a public key 273 and a private key (not shown). The private key is not publicly available, but is kept secret by the entity (also called the key holder). The public key 273 can be made available to anyone through a digital certificate issued by a certificate authority (CA). The certificate is also a confirmation or confirmation by the CA that the public key contained in the certificate belongs to the entity indicated in the certificate. For example, a customer can download a certificate and obtain the public key 273 to encrypt customer data to be sent to the application server 255. Only the entity (or the holder of the private key) can decrypt customer data that has been encrypted using the public key 273.

[0053] The application server 255 can be coupled to the cryptographic computing system 212 configured with a cryptographic application module 214. The cryptographic application module 214 can be configured as follows: Figure 4A generates public keys, private keys, symmetric keys and key fragments for one or more key distributions.

[0054] Application server 255 may be coupled to file system 271. File system 271 may be configured to store various cryptographic keys, including keys generated by cryptographic computing system 212.

[0055] The application server 255 can be coupled to a secure server computing system 260 (also referred to as an HSM server 260) configured with an HSM 266. The HSM 266 can be associated with an HSM public key 267 and an HSM private key 268. The HSM server 260 may include an HSM application module 265 that is configured to interact with the HSM 266 and perform various encryption and decryption operations. For example, the HSM application module 265 can use the HSM private key 268 to decrypt data previously encrypted using the corresponding HSM public key 267. A password may be required to access the HSM 266. For load balancing purposes, there may be multiple application servers 255 and multiple HSM servers 260 that are connected to a load balancer (not shown). All application servers 255 may need to know which HSM server 260 they can talk to at any particular time.

[0056] For some embodiments, the file system 271 may be synchronized with a file system local to the HSM server 260. This may enable the HSM server 260 to access and store data in the file system 271 as if the file system 271 were a local file system. For some embodiments, the HSM server 260 may only respond to queries sent by the application server 255. This may prevent any unauthorized user from accessing data or services associated with the HSM server 260. For example, the application server 255 may need to digitally sign each request it sends to the HSM server 260 using its shared secret.

[0057] Symmetric key usage

[0058] Figure 3An exemplary relationship between symmetric keys and clients according to some embodiments is shown. In this example, there are two clients 315 and 325. During operation, client 315 may send its client data 320 to application server 255. Application server 255 then uses symmetric key 322 unique to client 315 to encrypt client data 320 and generate encrypted client data 324. Encrypted client data 324 is then stored in database 270. Subsequently, when client 315 requests its client data, encrypted client data 324 is retrieved from database 270, decrypted by application server 255 using symmetric key 322, and decrypted client data 320 is sent to client 315.

[0059] Similarly, client 325 may send its client data 330 to application server 255. Application server 255 then uses symmetric key 332 unique to client 325 to encrypt client data 330 and generate encrypted client data 334. Encrypted client data 334 is then stored in database 270. Subsequently, when client 325 requests its client data, encrypted client data 334 is retrieved from database 270, decrypted by application server 255 using symmetric key 332, and decrypted client data 330 is sent to client 325.

[0060] When the application server 255 needs to access the symmetric key 322 or 332, the application server 255 can check to find out whether the symmetric key 322 or 332 exists in the in-memory cache 307. If the symmetric key 322 or 332 exists in the in-memory cache 307, it can be accessed and used by the application server 255. If the symmetric key 322 or 332 does not exist in the in-memory cache 307, the application server 255 can request the security server to export the symmetric key 322 or 332, receive the symmetric key, and use the regenerated symmetric key to decrypt the corresponding encrypted client data.

[0061] Figure 4 A specific embodiment of a flow chart of a method 400 for requesting a symmetric key generated using key agreement to encrypt and / or decrypt customer data is shown. Process 600 may be performed by an application server 255 ( ) in communication with a secure server 260 and an HSM 266. Figure 2408). The key identifier may be received at a set time, for example, via a network connection, from a secure server such as secure server 260, and may be stored by an application server (e.g., application server 255) in step 405. The key identifier may be one of many key identifiers received from a secure server, which may set aside a plurality of private keys for the application server to use for the secure server. The key identifier may be associated with a private key, wherein the private key may be accessible by the secure server but not by the application server. In box 407, the customer data may be received by the application server for storage in, for example, database 270. The customer data will be encrypted before being stored in database 270, so the receipt of the customer data by the application server will trigger step 408. Alternatively, the customer may request data previously encrypted by the application server and stored in database 270. The request may be made by a user using the client computing system 205 via an application program interface (API) or a user interface (UI). Once the customer data has been identified in the database, the symmetric key used to encrypt the customer data must be used to decrypt the customer data before the requested data is sent to the customer.

[0062] At step 408, the application server 255 may determine whether the symmetric key 308 is present in the in-memory cache 307 of the application server 255. If the symmetric key 308 is found, the process may proceed to step 420, where the symmetric key 308 may be used to encrypt (or decrypt if the client is querying encrypted data stored in the database 270) the client data. The decrypted client data may then be sent to the user, or in the case of encryption, the encrypted client data may be stored on the application server (e.g., in the database 270 or a similar data structure).

[0063] From block 408, if the application server 255 cannot find the symmetric key 322 in the in-memory cache 307, then it is necessary to derive the symmetric key 322. At step 410, a request for the symmetric key may be sent by the application server to the security server. The request may be sent after the application server stores the key identifier, and may include the public key generated by the application server, the salt value, and the key identifier.

[0064] Figure 5A flowchart of an exemplary process for generating a request for a symmetric key generated using key agreement according to some embodiments is shown. In step 505, an application server can generate a public-private key pair, and the public key can be used for a request for a symmetric key. Public and private keys can be generated using any suitable method, including but not limited to elliptic curve cryptography (wherein, both public and private keys correspond to different points on an elliptic curve and are encrypted using elliptic curve cryptography). In step 510, a random salt value can be generated, and unused key identifiers come from a secure server pool. The random salt value can be randomly generated data for generating each symmetric key, where different salt values ​​or strings can be used for each symmetric key request. Salt values ​​typically have enough bits to be unique between potentially large numbers of clients, where having more bits increases security, but also increases the complexity (and potential time delay) of generating symmetric keys.

[0065] The key identifier may be selected from a plurality of key identifiers available to the application server 255 via a secure server pool of keys, the list of keys having previously been sent to the application server as described above. Finally, at step 515, a request including the generated public key, salt value, and key identifier may be sent by the application server to the secure server. Furthermore, the combination of the public key, salt value, and key identifier may be stored in a permanent storage (i.e., a data structure) of the application server so that the application server can easily regenerate the symmetric key at a later date.

[0066] Figure 6 A simplified block diagram 600 is shown including an exemplary data structure 650 listing various symmetric keys assigned to different tenants in a multi-tenant environment according to various embodiments. Diagram 600 includes a tenant-aware database 605, which may correspond to Figure 2 The database 270 in communication with the application server 255 in the embodiment of the present invention includes a data structure 650. The data structure 650 can be a persistent storage that includes a plurality of tenants (e.g., from Figure 3 The combination of a public key, a key identifier (also called a key server ID), and a random salt value generated by the client 315 and 325 of the symmetric key. The rows of data structure 650, such as row 612 and row 618, can correspond to separate symmetric keys that have been used by the application server.

[0067] Symmetric keys for multiple tenants may be included in data structure 650, as illustrated by symmetric key entry 618 having a tenant ID 620 that is different from symmetric key entry 612. As shown for symmetric key entry 612, each symmetric key entry may be associated with a tenant id field value 615, a public key value 630 (associated with a public key generated by the application server when requesting the symmetric key corresponding to entry 612), a key identifier value 635 (associated with a private key accessible by the security server for generating the symmetric key), and a salt value 640 (a randomly generated number or string, as shown). In the case where the application is decrypting customer data, metadata associated with the customer data may be used to identify which symmetric key in data structure 650 was used to encrypt the customer data. The metadata may include any identifying information that allows the application server to identify the symmetric key used for encryption, including, for example, the public key value 630 of the symmetric key used to encrypt the customer data. Because in various embodiments the public key value for each symmetric key may be unique (i.e., the public key is not reused for different symmetric keys to provide greater security), the public key value 630 may be used to identify the symmetric key for purposes of decrypting encrypted customer data.

[0068] like Figure 4 As described in step 410 of , a request for a symmetric key may be sent to a secure server, and the secure server may generate a symmetric key using data specified by the request. Figure 8 A flow chart of an exemplary process 800 for generating a symmetric key using key agreement performed in accordance with some embodiments is shown. While in some embodiments, the secure server may not be under the control of the client whose data is to be encrypted / decrypted by the symmetric key, this may not always be the case. In some embodiments, the client may communicate with an HSM or other suitable key store using a client-hosted key server themselves. In step 805, a request to derive a symmetric key is received by the secure server from the application server, the request including a public key, a salt value, and a key identifier associated with a private key as described above.

[0069] In response to receiving the request, the security server can use a key derivation function to derive a symmetric key based on the received public key, salt value, and private key identified by the key identifier. In step 810, the key derivation can start by extracting the private key from a storage location that is inaccessible to the application server. The private key can be extracted from a key management service that communicates with the security server instead. The key management service can store multiple private keys linked to multiple key identifiers provided to the security server (for example, in an HSM, or in a storage device under the control of the key management service). The key management service can take the form of an HSM that protects all private keys included therein, and the HSM can communicate with the security server through a network connection. Alternatively, the key management service can split the private key between multiple key servers, wherein the secret sharing multi-party computation only allows a subset of the key servers (including the key management service server) to perform cryptographic calculations, which effectively allows access to the private key from the location where the key is shared, without actually assembling the private key on the key server. Such an embodiment can provide additional security by not storing the private key on the security server and only providing them when requested. Alternatively, the storage location can be a data storage within the security server. Figure 7 A simplified block diagram 700 of an exemplary data structure 730 listing key identifiers (eg, on each row such as row 710) and their corresponding private keys is shown in accordance with various embodiments.

[0070] A data structure 730 including a list of asymmetric key pairs (of public and private keys) may be stored in a secure server keystore 705, which in various embodiments may be an HSM, a key management service in communication with a secure server, or may be a data store within the secure server itself. Row 710 illustrates an asymmetric key pair record within the private key data structure 730, listing a corresponding key identifier 715 of the asymmetric key pair and a private key 725 associated with the key identifier. Row 710 may also include a public key 720 associated with the private key 725; as shown in the exemplary data structure 730, the public key 720 may be an elliptic curve public key generated via elliptic curve cryptography. The public key 720 may not typically be used to generate symmetric keys, and may be discarded by the key service in some embodiments.

[0071] return Figure 8After extracting the private key, in step 815, a key agreement protocol can be applied to the public key and the private key selected in the request by the key identifier to obtain a key agreement key. Any suitable key agreement protocol can be used to generate a key agreement key from the private key and the public key associated with the key identifier, including Diffie-Hellman key exchange, anonymous key exchange, etc. In an exemplary embodiment, the key agreement protocol can be based on a common elliptic curve function for generating the private key and the public key associated with the key identifier. The private key and the public key associated with the key identifier can be derived from the same elliptic curve (although derived from different elliptic curve key pairs corresponding to different points on the elliptic curve), and any suitable key agreement function can be applied to the private key and the public key associated with the key identifier. Such a function can be as simple as multiplying the public key by the private key associated with the key identifier to obtain a unique number. Since other methods, such as key wrapping, are vulnerable to quantum computing attacks, using key agreement may be advantageous for generating symmetric keys in encryption. In contrast, key agreement is generally more secure, even against quantum computing code cracking techniques.

[0072] Finally, at step 820, a symmetric key may be generated by the security server by applying a key derivation function to the key agreement key. The key derivation function may be a suitable cryptographic hash function that creates a symmetric key based on the key agreement key and a salt value received with the request to derive the symmetric key. Exemplary key derivation functions that may be used include PBKDF2, bcrypt, scrypt, etc. After the symmetric key is generated, it may be sent to the requesting application server at step 825. As described below, the symmetric key may then be stored in an in-memory cache of the application server and used by the application server to encrypt customer data stored by the application server.

[0073] return Figure 4 At step 420, the customer data may be encrypted by the application server using the received symmetric key. Since possession of the symmetric key is required to decrypt the customer data, the encrypted customer data is protected from access by any unauthorized user. When the customer wishes to retrieve the customer data, the encrypted customer data may be decrypted using the symmetric key, which may be stored in the application server's cache memory or may be re-derived by the application server, which may have access to the public key, salt value, and key identifier used to derive the symmetric key (e.g., via data structure 650). The decrypted customer data may then be sent to the customer.

[0074] The encrypted customer data may be stored in any persistent storage device that is in communication with the application server and is associated with the multi-tenant database environment. Examples of such persistent storage devices may be cloud-based storage areas, non-cloud-based storage areas, or other forms of storage implementations. Different tenants may utilize different persistent storage devices, which may be easily tracked by the application server using a unique tenant ID associated with one or more symmetric keys for each tenant in the data structure 650.

[0075] Compared to conventional data protection schemes, method 400 advantageously does not require the private key data to be persisted on an application server or security server (for embodiments in which the private key associated with the key identifier is stored on an HSM or other external storage device), thereby improving security by not including symmetric keys in the event that the application server or security server is compromised. Not only is security improved by not persisting the private key, but method 400 also reduces the amount of cache required, because conventional systems require the private key to be persisted in a cache memory, which can be resource intensive in a multi-tenant environment. After the symmetric key is removed from the cache, only the public key used to generate the symmetric key is needed to regenerate the symmetric key; in some embodiments, the private key used by the application server to generate the public key can be disposed of to save memory resources. Finally, method 400 also presents a different use of key agreement than conventional use. Conventionally, key agreement is typically used to protect communications between two devices, and method 400 uses key agreement to securely generate symmetric keys to encrypt data from a third-party client device that is not used to generate the symmetric key. As described above, no single party can compromise the symmetric keys generated using method 400, thereby providing unique benefits to multi-tenant application servers to protect customer data.

[0076] Over time, it may be a good practice for clients to rotate the symmetric keys used to encrypt their data (i.e., use different symmetric keys to encrypt their data) in order to provide more security for the encrypted data. To do this, the application server may simply send a new request to the security server for a different symmetric key. In various embodiments, this request to assess a symmetric key for a particular client may be initiated by the client, by an administrator of the application server, or automatically by the application server (e.g., after a predetermined period of time). Fig. 9A flow chart of an exemplary process 900 for performing key rotation on an application server according to various embodiments is shown. At step 905, the application server may send a request to rotate a symmetric key, the rotation request including a different public key generated by the application server, a different salt value, and a different key identifier associated with a different private key accessible by the private server. Using different elements in the request to rotate a symmetric key increases security because having common elements increases the likelihood that the rotational symmetric key will be compromised if the current symmetric key is compromised.

[0077] After the security server receives the request for the rotationally symmetric key, the security server may repeat the rotation of the symmetric key using the different components received in the request for the rotationally symmetric key, for example, Figure 8 The symmetric key generation process shown in method 800 in FIG. Then, in response to the request to rotate the symmetric key, a different symmetric key can be sent from the security server to the application server at step 910. The different symmetric keys can be derived based on different public keys and different private keys associated with different key identifiers using a key derivation function for generating symmetric keys.

[0078] Different symmetric keys may be linked to a symmetric key, such as a tenant key data structure, and further stored in an in-memory cache of the application server. Fig.10 An exemplary data structure 1000 is shown storing entries 1010 of rotational symmetric keys for clients in a multi-tenant environment according to various embodiments. Obviously, entry 1010 in the tenant key data structure is the rotational symmetric key associated with entry 1005, because tenant ID 1009 matches tenant ID 1007. As described above, the public key 1015, key identifier 1020, and salt value 1025 of the symmetric key associated with entry 1010 are unique to provide improved security via the rotated keys.

[0079] Once the different symmetric key has been cached, it can be used by the application server at step 915 to encrypt data subsequently received from one of the plurality of client devices. In some cases, it may be desirable to destroy a symmetric key previously used by a client (e.g., if one of the components used to generate the symmetric key has been compromised). This can be accomplished by the application server deleting the symmetric key from a list of symmetric keys associated with the application server (e.g., the tenant key data structure discussed above). The list of symmetric keys can be stored on the application server itself, or in a database in communication with the application server, where the database also stores encrypted client data. Fig.11An exemplary data structure 1100 showing the destruction of a symmetric key is shown in accordance with various embodiments. Data structure 1100 is based on data structure 1000, where symmetric key 1105 for customers associated with tenant IDs 1007 and 1009 has been deleted from the list of symmetric keys in data structure 1100. By deleting the public key 1120 and salt 1125 of the symmetric key associated with entry 1105, there is no longer a record for recreating the symmetric key associated with entry 1105. Without the symmetric key, any customer data encrypted with the symmetric key associated with entry 1105 cannot be decrypted.

[0080] On-demand service environment

[0081] Fig. 12A A system diagram 1200 showing architectural components of an on-demand service environment is shown according to some embodiments. Client machines located in a cloud 1204 (or the Internet) can communicate with the on-demand service environment via one or more edge routers 1208 and 1212. The edge routers can communicate with one or more core switches 1220 and 1224 via a firewall 1216. The core switch can communicate with a load balancer 1228, which can distribute server loads across different pods such as pods 1240 and 1244. Pods 1240 and 1244, which can each include one or more servers and / or other computing resources, can perform data processing and other operations for providing on-demand services. Communication with the pods can be performed via pod switches 1232 and 1236. Components of the on-demand service environment can communicate with a database storage system 1256 via a database firewall 1248 and a database switch 1252.

[0082] like Fig. 12A and 12B As shown, accessing the on-demand service environment may involve communications transmitted between various hardware and / or software components. In addition, the on-demand service environment 1200 is a simplified representation of an actual on-demand service environment. For example, although in Fig. 12A and 12B Only one or two devices of each type are shown, but some embodiments of the on-demand service environment may include any device from one to multiple devices of each type. Moreover, the on-demand service environment need not include Fig. 12A and 12B Each device shown in or may include Fig. 12A and 12B Additional equipment not shown.

[0083] In addition, one or more devices in the on-demand service environment 1200 may be implemented on the same physical device or on different hardware. Some devices may be implemented using hardware or a combination of hardware and software. Therefore, terms such as "data processing apparatus," "machine," "server," and "device" as used herein are not limited to a single hardware device, but include any hardware and software configured to provide the described functionality.

[0084] The cloud 1204 is intended to refer to a data network or multiple data networks, typically including the Internet. Client machines located in the cloud 1204 can communicate with the on-demand service environment to access services provided by the on-demand service environment. For example, the client machine can access the on-demand service environment to retrieve, store, edit and / or process information.

[0085] In some embodiments, edge routers 1208 and 1212 route packets between cloud 1204 and other components of on-demand service environment 1200. Edge routers 1208 and 1212 may employ Border Gateway Protocol (BGP). BGP is the core routing protocol of the Internet. Edge routers 1208 and 1212 may maintain a table of IP networks or "prefixes" that specify network reachability between autonomous systems on the Internet.

[0086] In one or more embodiments, firewall 1216 can protect internal components of on-demand service environment 1200 from Internet traffic. Firewall 1216 can block, allow, or deny access to internal components of on-demand service environment 1200 based on a set of rules and other criteria. Firewall 1216 can act as one or more of a packet filter, an application gateway, a stateful filter, a proxy server, or any other type of firewall.

[0087] In some embodiments, core switches 1220 and 1224 are high-capacity switches that transmit packets within the on-demand service environment 1200. Core switches 1220 and 1224 can be configured as bridges that quickly route data between different components within the on-demand service environment. In some embodiments, the use of two or more core switches 1220 and 1224 can provide redundancy and / or reduced latency.

[0088] In some embodiments, pods 1240 and 1244 may perform core data processing and service functions provided by the on-demand service environment. Each pod may include various types of hardware and / or software computing resources. Fig. 12B An example that discusses the pod architecture in more detail.

[0089] In some embodiments, communication between pods 1240 and 1244 may occur via pod switches 1232 and 1236. Pod switches 1232 and 1236 may facilitate communication between pods 1240 and 1244 and client machines located in cloud 1204, for example, via core switches 1220 and 1224. Furthermore, pod switches 1232 and 1236 may facilitate communication between pods 1240 and 1244 and database storage 1256.

[0090] In some embodiments, load balancer 1228 can distribute the workload between pods 1240 and 1244. Balancing on-demand service requests between pods can help improve resource usage, increase throughput, reduce response time and / or reduce overhead. Load balancer 1228 may include a multilayer switch to analyze and forward traffic.

[0091] In some embodiments, access to the database storage device 1256 can be protected by a database firewall 1248. The database firewall 1248 can act as a computer application firewall operating at the database application layer of the protocol stack. The database firewall 1248 can protect the database storage device 1256 from application attacks, such as structured query language (SQL) injection, database rootkits, and unauthorized information disclosure.

[0092] In some embodiments, the database firewall 1248 may include a host that uses one or more forms of reverse proxy services to proxy traffic before passing it to a gateway router. The database firewall 1248 may inspect the content of database traffic and block certain content or database requests. The database firewall 1248 may work at the SQL application layer on the TCP / IP stack, managing the connection of applications to the database or SQL management interface, and intercepting and implementing packets to or from the database network or application interface.

[0093] In some embodiments, communication with the database storage system 1256 can be performed via a database switch 1252. The multi-tenant database system 1256 can include more than one hardware and / or software component for processing database queries. Thus, the database switch 1252 can direct database queries sent by other components of the on-demand service environment (e.g., pods 1240 and 1244) to the correct component within the database storage system 1256. In some embodiments, the database storage system 856 is an on-demand database system shared by many different organizations. The on-demand database system can adopt a multi-tenant approach, a virtualization approach, or any other type of database approach. Reference Fig.13 and 14 Discuss on-demand database systems in more detail.

[0094] Fig. 12B A system diagram showing the architecture of a pod 1244 is shown according to one embodiment. Pod 1244 can be used to provide services to users of on-demand service environment 1200. In some embodiments, each pod can include various servers and / or other systems. Pod 1244 includes one or more content batch servers 1264, content search servers 1268, query servers 1272, file enforcement servers 1276, access control system (ACS) servers 1280, batch servers 1284, and application servers 1288. Moreover, pod 1244 includes a database instance 1290, a fast file system (QFS) 1292, and an indexer 1294. In one or more embodiments, some or all communications between servers in pod 1244 can be transmitted via switch 1236.

[0095] In some embodiments, application server 1288 may include hardware and / or software frameworks dedicated to executing processes (e.g., programs, routines, scripts) to support the construction of applications provided by on-demand service environment 1200 via pod 1244. Some such processes may include operations for providing the services described herein. Content batch server 1264 may be requested within the pod. These requests may be long-running and / or not tied to a specific customer. For example, content batch server 1264 may handle requests related to log mining, cleanup work, and maintenance tasks.

[0096] The content search server 1268 may provide query and indexer functionality. For example, functionality provided by the content search server 1268 may allow a user to search for content stored in an on-demand service environment. The FileForce server 1276 may manage requested information stored in a FileForce storage device 1278. The FileForce storage device 1278 may store information such as documents, images, and basic large objects (BLOBs). By using the FileForce server 1276 to manage requests for information, the image footprint on the database may be reduced.

[0097] The query server 1272 can be used to extract information from one or more file systems. For example, the query system 1272 can receive a request for information from an application server 1288 and then send the information query to NFS 1296 located outside the pod. Pods 1244 can share database instances 1290 configured as a multi-tenant environment, where different organizations share access to the same database. In addition, the services provided by pods 1244 may require various hardware and / or software resources. In some embodiments, the ACS server 1280 can control access to data, hardware resources, or software resources.

[0098] In some embodiments, batch server 1284 can process batch jobs, which are used to run tasks at specified times. Thus, batch server 1284 can send instructions to other servers, such as application server 1288, to trigger batch jobs. In some embodiments, QFS 1292 can be a server available from Sun Microsystems Inc. in Santa Clara, California. An open source file system obtained from pod 1244. QFS can be used as a fast access file system for storing and accessing information available within pod 1244. QFS 1292 can support some volume management capabilities, allowing many disks to be grouped together into a file system. File system metadata can be stored on a separate set of disks, which is useful for streaming applications that cannot tolerate long disk seeks. Therefore, the QFS system can communicate with one or more content search servers 1268 and / or indexers 1294 to identify, extract, move and / or update data stored in the network file system 1296 and / or other storage systems.

[0099] In some embodiments, one or more query servers 1272 may communicate with NFS 1296 to retrieve and / or update information stored outside of pod 1244. NFS 1296 may allow servers located in pod 1244 to access information so as to access files over a network in a manner similar to accessing local storage. In some embodiments, queries from query servers 1222 may be sent to NFS 1296 via load balancer 1220, which may distribute resource requests across various resources available in an on-demand service environment. NFS 1296 may also communicate with QFS 1292 to update information stored on NFS 1296 and / or provide information to QFS 1292 for use by servers located within pod 1244.

[0100] In some embodiments, a pod may include one or more database instances 1290. The database instance 1290 may send information to the QFS 1292. When the information is sent to the QFS, it may be used by servers within the pod 1244 without requiring additional database calls. In some embodiments, the database information may be sent to an indexer 1294. The indexer 1294 may provide an index of information available in the database 1290 and / or the QFS 1292. The index information may be provided to the file enforcement server 1276 and / or the QFS 1292.

[0101] Fig.13 A block diagram of an environment 1310 in which an on-demand database service may be used is shown according to some embodiments. Environment 1310 includes an on-demand database service 1316. User systems 1312 may be any machine or system that a user uses to access a database user system. For example, any of user systems 1312 may be a handheld computing system, a mobile phone, a laptop computer, a workstation, and / or a network of computing systems. Fig.13 and 14 As shown, a user system 1312 may interact with an on-demand database service 1316 via a network 1314 .

[0102] An on-demand database service, such as system 1316, is a database system that is available to external users who do not necessarily care about building and / or maintaining a database system, but rather is available to users when they need a database system (e.g., on demand). Some on-demand database services can store information from one or more tenants, which is stored in tables of a common database image to form a multi-tenant database system (MTS). Therefore, "on-demand database service 1316" and "system 1316" will be used interchangeably herein. A database image may include one or more database objects. A relational database management system (RDBMS) or its equivalent may perform storage and retrieval of information for (multiple) database objects. Application platform 1318 may be a framework, such as hardware and / or software, such as an operating system, that allows applications of system 1316 to run. In one embodiment, on-demand database service 1316 may include application platform 1318 that enables the creation, management, and execution of one or more applications developed by a provider of an on-demand database service, a user accessing the on-demand database service via user system 1312, or a third-party application developer accessing the on-demand database service via user system 1312.

[0103] Fig.131316, including a network interface 1320, an application platform 1318, a tenant data store 1322 for tenant data 1323, a system data store 1324 for system data 1325 accessible to the system 1316 and possibly multiple tenants, program code 1326 for implementing various functions of the system 1316, and a process space 1328 for executing MTS system processes and tenant-specific processes (such as running applications as part of an application hosting service). Additional processes that may be executed on the system 1316 include a database indexing process.

[0104] The users of user systems 1312 may differ in their respective capabilities, and the capabilities of a particular user system 1312 may be determined entirely by the permissions (permission level) of the current user. For example, in the case where a call center agent is using a particular user system 1312 to interact with system 1316, the user system 1312 has the capabilities assigned to the call center agent. However, when an administrator is using the user system to interact with system 1316, the user system has the capabilities assigned to the administrator. In a system with a hierarchical role model, a user at one permission level may access applications, data, and database information accessible to users at a lower permission level, but may not access certain applications, database information, and data accessible to users at a higher permission level. Therefore, depending on the user's security or permission level, different users may have different capabilities regarding accessing and modifying application and database information.

[0105] The network 1314 is any network or combination of networks of devices that communicate with each other. For example, the network 1314 can be any one or any combination of a LAN (local area network), a WAN (wide area network), a telephone network, a wireless network, a point-to-point network, a star network, a token ring network, a hub network, or other suitable configurations. Since the most common type of computer network currently used is a TCP / IP (Transmission Control Protocol and Internet Protocol) network (such as the Internet), this network will be used in many examples herein. However, it should be understood that although TCP / IP is a frequently implemented protocol, the network used in some embodiments is not limited thereto.

[0106] The user system 1312 can communicate with the system 1316 using TCP / IP, and at a higher network level, other public Internet protocols are used to communicate, such as HTTP, FTP, AFS, WAP, etc. In the example of using HTTP, the user system 1312 may include an HTTP client, commonly referred to as a "browser", for sending HTTP messages to and receiving HTTP messages from an HTTP server at the system 1316. Such an HTTP server can be implemented as the only network interface between the system 1316 and the network 1314, but other technologies or alternatives may also be used. In some embodiments, the interface between the system 1316 and the network 1314 includes a load sharing function, such as a circular HTTP request distributor, to balance the load and evenly distribute the incoming HTTP requests to multiple servers. At least for the user who is accessing the server, each of the multiple servers can access the data of the MTS; however, other alternative configurations may be used instead.

[0107] In some embodiments, Fig.13 The system 1316 shown implements a web-based customer relationship management (CRM) system. For example, in some embodiments, the system 1316 includes an application server configured to implement and execute a CRM software application, and to provide relevant data, code, forms, web pages and other information to and from the user system 1312, and to store and extract relevant data, objects and web page content to the database system. For a multi-tenant system, the data of multiple tenants can be stored in the same physical database object, however, the tenant data is usually arranged to keep the data of one tenant logically separated from the data of other tenants, so that one tenant cannot access the data of another tenant unless such data can be explicitly shared. In some embodiments, the system 1316 implements applications other than or in addition to the CRM application. For example, the system 1316 can provide tenants with access to multiple hosted (standard and custom) applications. User (or third-party developer) applications that may or may not include CRM can be supported by an application platform 1318, which manages the creation of applications, storage in one or more database objects, and execution of applications in virtual machines in the process space of the system 1316.

[0108] Each user system 1312 may include a desktop personal computer, workstation, laptop computer, PDA, cellular phone, or any wireless access protocol (WAP) enabled device, or any other computing system capable of directly or indirectly connecting to the Internet or other network. User system 1312 typically runs an HTTP client, such as a browser program, such as Microsoft's Internet Explorer. Browser, Mozilla A browser, Opera's browser, or a WAP-enabled browser in the case of a cellular phone, PDA or other wireless device, etc., thereby enabling users of user system 1312 (e.g., subscribers to a multi-tenant database system) to access, process and view information, pages and applications available to them from system 1316 via network 1314.

[0109] Each user system 1312 also generally includes one or more user interface devices, such as keyboard, mouse, tracking ball, touch pad, touch screen, pen, etc., for interacting with the graphical user interface (GUI) provided by the browser on a display (e.g., monitor screen, LCD display, etc.) in combination with pages, tables, applications, and other information provided by system 1316 or other systems or servers. For example, the user interface device can be used to access data and applications hosted by system 1316, and searches are performed on stored data, and otherwise allow users to interact with various GUI pages that can be presented to the user. As described above, the embodiment is suitable for use with the Internet, and the Internet refers to a specific global network interconnection. However, it should be understood that other networks can also be used to replace the Internet, such as intranets, extranets, virtual private networks (VPNs), networks based on non-TCP / IP, any LAN or WAN, etc.

[0110] According to some embodiments, each user system 1312 and all of its components are operators that can be configured using an application such as a browser, including using an application such as Intel Similarly, system 1316 (and additional instances of MTS where there are more than one) and all of its components may be configurable using application(s) including computer code to use a processor system 1317 (which may include Intel processor, etc.) and / or a central processing unit of a multi-processor unit.

[0111] The embodiment of the computer program product includes (multiple) machine-readable storage media on which / in which instructions are stored, which can be used to program a computer to perform any one of the processes of the embodiments described herein. The computer code for operating and configuring the system 1316 to communicate with each other and process web pages, applications and other data and media content as described herein is preferably downloaded and stored on a hard disk, but the entire program code or part thereof may also be stored in any other volatile or non-volatile memory medium or device, such as ROM or RAM, or provided on any medium capable of storing program code, such as any type of rotating medium including floppy disks, optical disks, digital versatile disks (DVDs), compact disks (CDs), microdrives and magneto-optical disks, as well as magnetic cards or optical cards, nanosystems (including molecular memory ICs), or any type of medium or device suitable for storing instructions and / or data. In addition, the entire program code or part thereof can be sent and downloaded from a software source through a transmission medium, such as through the Internet, or from another server, or sent through any other traditional network connection (such as an extranet, VPN, LAN, etc.) using any communication medium and protocol (such as TCP / IP, HTTP, HTTPS, Ethernet, etc.). It should also be understood that the computer code for implementing the embodiments may be implemented in any programming language that can be executed on the client system and / or the server system, such as C, C++, HTML, any other markup language, Java, or any other programming language. TM , Any other scripting language, such as VBScript, and many other well-known programming languages ​​can be used. (Java TM It's Sun Company's trademark).

[0112] According to some embodiments, each system 1316 is configured to provide web pages, forms, applications, data, and media content to user (client) systems 1312 to support access by user systems 1312 that are tenants of the system 1316. In this way, the system 1316 provides security mechanisms to keep the data of each tenant separate unless the data is shared. If more than one MTS is used, they can be close to each other (e.g., in a server farm located in a single building or campus), or they can be distributed in locations far away from each other (e.g., one or more servers located in city A and one or more servers located in city B). As used herein, each MTS may include logically and / or physically connected servers that are locally distributed or distributed across one or more geographic locations. In addition, the term "server" is intended to include a computing system that includes processing hardware and (multiple) process spaces, as well as associated storage systems and database applications (e.g., OODBMS or RDBMS), as known in the art.

[0113] It should also be understood that "server system" and "server" are often used interchangeably herein. Similarly, the database objects described herein can be implemented as a single database, a distributed database, a collection of distributed databases, a database with redundant online or offline backup or other redundancy, etc., and can include a distributed database or storage network and associated processing intelligence.

[0114] Fig.14 Also shown is a block diagram of environment 1310 further illustrating system 1316 and various interconnections in accordance with some embodiments. Fig.14 User system 1312 is shown to include a processor system 1312A, a memory system 1312B, an input system 1312C, and an output system 1312D. Fig.14 A network 1314 and a system 1316 are shown. Fig.14 The system 1316 is also shown to include a tenant data store 1322, tenant data 1323, a system data store 1324, system data 1325, a user interface (U1) 1430, an application program interface (API) 1432, PL / SOQL 1434, a save routine 1436, an application settings mechanism 1438, application servers 14001-1400N, a system process space 1402, a tenant process space 1404, a tenant management process space 1410, a tenant storage area 1412, a user storage 1414, and application metadata 1416. In other embodiments, the environment 1310 may not have the same elements as those listed above and / or may have other elements instead of or in addition to those listed above.

[0115] User system 1312, network 1314, system 1316, tenant data storage device 1322, and system data storage device 1324 are above Fig.13 Regarding user system 1312, processor system 1312A may be any combination of processors. Memory system 1312B may be any combination of one or more memory devices, short-term and / or long-term memory. Input system 1312C may be any combination of input devices, such as a keyboard, mouse, trackball, scanner, camera, and / or an interface to a network. Output system 1312D may be any combination of output devices, such as a monitor, printer, and / or an interface to a network. Fig.14 As shown, the system 1316 may include a set of HTTP application servers 1400, an application platform 1318, a tenant data storage device 1322, and a system data storage device 1324. Fig.13) network interface 1320. Also shown is a system process space 1402, including separate tenant process spaces 1404 and tenant management process spaces 1410. Each application server 1400 can be configured as a tenant data storage device 1322 and tenant data 1323 therein, as well as a system data storage device 1324 and system data 1325 therein to serve requests from user systems 1312. The tenant data 1323 can be divided into separate tenant storage areas 1412, which can be physical arrangements and / or logical arrangements of data. Within each tenant storage area 1412, user storage devices 1414 and application metadata 1416 can be similarly allocated to each user. For example, a copy of a user's most recently used (MRU) items can be stored in the user storage device 1414. Similarly, a copy of the MRU items of the entire organization as a tenant can be stored in the tenant storage area 1412. UI 1430 provides a user interface, and API 1432 provides an application programmer's interface to system 1316 resident processes to users and / or developers at user systems 1312. Tenant data and system data may be stored in a database such as Oracle TM Databases in various databases.

[0116] The application platform 1318 includes an application provisioning mechanism 1438 that supports the creation and management of applications by application developers, for example, applications may be saved as metadata in the tenant data store 1322 via a save routine 1436 for execution by the tenant process space 1404 managed by the subscriber as the tenant management process 1410. Calls to these applications may be coded using PL / SOQL 34 that provides a programming language style interface extension to the API 1432. A detailed description of some PL / SOQL language embodiments is discussed in commonly assigned U.S. Pat. No. 7,730,478, filed on Sep. 21, 2007 by Craig Weissman, entitled “METHOD AND SYSTEM FOR ALLOWING ACES TO DEVELOPED APPLICATIONS VIA A MULTI-TENANT ON-DEMAND DATABASE SERVICE,” which is incorporated herein by reference in its entirety and for all purposes. The call to the application may be detected by the system process which manages to extract the application metadata 1416 for the calling subscriber and execute the metadata as the application in the virtual machine.

[0117] Each application server 1400 can be communicatively coupled to, for example, a database system that can access system data 1325 and tenant data 1323 via a different network connection. For example, one application server 14001 can be coupled via a network 1314 (e.g., the Internet), another application server 1400N-1 can be coupled via a direct network link, and another application server 1400N can be coupled via yet another different network connection. Transmission Control Protocol and Internet Protocol (TCP / IP) are typical protocols used to communicate between application servers 1400 and database systems. However, other transmission protocols can also be used to optimize the system depending on the network interconnect used.

[0118] In some embodiments, each application server 1400 is configured to process requests for any user associated with any organization as a tenant. Since it is desirable to be able to add and remove application servers from the server pool at any time for any reason, preferably, there is no server affinity with a specific application server 1400 for a user and / or organization. Therefore, in some embodiments, an interface system (e.g., F5 large IP load balancer) implementing a load balancing function is communicatively coupled between application server 1400 and user system 1312 to distribute requests to application server 1400. In some embodiments, the load balancer uses a minimum connection algorithm to route user requests to application server 1400. Other examples of load balancing algorithms may also be used, such as round-robin and observed response time. For example, in some embodiments, three consecutive requests from the same user may hit three different application servers 1400, and three requests from different users may hit the same application server 1400. In this manner, system 1316 is multi-tenant in that system 1316 can handle storage of and access to different objects, data, and applications across different users and organizations.

[0119] As an example of a storage device, a tenant may be a company that employs sales personnel, wherein each call center agent uses system 1316 to manage their sales process. Thus, a user may maintain contact data, lead data, customer follow-up data, performance data, goal and progress data, etc., all of which apply to the user's personal sales process (e.g., in tenant data storage device 1322). In one example of an MTS arrangement, since all data and applications to be accessed, viewed, modified, reported, transmitted, calculated, etc. may be maintained and accessed by a user system that only has network access, a user may manage his or her sales work and cycle from any of many different user systems. For example, if a call center agent is visiting a customer and the customer has Internet access in their lobby, the call center agent may obtain critical updates about the customer while waiting for the customer to arrive in the lobby.

[0120] Although each user's data can be separated from other users' data regardless of each user's employer, some data can be shared or accessible organization-wide data by multiple users or all users of a given organization as a tenant. Therefore, there may be some data structures distributed at the tenant level managed by system 1316, while other data structures may be managed at the user level. Since MTS can support multiple tenants including possible competitors, MTS should have security protocols that keep data, applications, and separate applications using. Moreover, since many tenants can choose to access MTS instead of maintaining their own systems, redundancy, normal operation time, and backup are additional functions that can be implemented in MTS. In addition to user-specific data and tenant-specific data, system 1316 can also maintain system-level data or other data that can be used by multiple tenants. Such system-level data can include industry reports, news, posts, etc., which can be shared between tenants.

[0121] In certain embodiments, the user system 1312 (which may be a client machine / system) communicates with the application server 1400 to request and update system-level and tenant-level data from the system 1316, which may require sending one or more queries to the tenant data store 1322 and / or the system data store 1324. The system 1316 (e.g., the application server 1400 in the system 1316) automatically generates one or more SQL statements (e.g., SQL queries) designed to access the required information. The system data store 1324 may generate a query plan to access the requested data from the database.

[0122] Each database can generally be viewed as a collection of objects, such as a collection of logical tables, which contain data suitable for predefined categories. "Table" is a representation of a data object and can be used here to simplify the conceptual description of objects and custom objects according to some embodiments. It should be understood that "table" and "object" can be used interchangeably here. Each table generally contains one or more data categories, which are logically arranged into columns or fields in a viewable mode. Each row or record of the table contains data instances of each category defined by the field. For example, a CRM database may include a table describing a customer, which has fields for basic contact information, such as name, address, telephone number, fax number, etc. Another table may describe a purchase order, including fields for information such as customer, product, sales price, date, etc. In some multi-tenant database systems, standard entity tables may be provided for use by all tenants. For CRM database applications, such standard entities may include tables for account, contact, lead and opportunity data, each table containing predefined fields. It should be understood that the term "entity" may also be used interchangeably with "object" and "table" in this article.

[0123] In some multi-tenant database systems, tenants may be allowed to create and store custom objects, or tenants may be allowed to customize standard entities or objects, including custom index fields, for example, by creating custom fields for standard objects. U.S. Patent 7,779,039, entitled "CUSTOM ENTITIES AND FIELDS IN MULTI-TENTANT DATABASE SYSTEM" by Weissman et al., teaches systems and methods for creating custom objects and customizing standard objects in a multi-tenant database system, which patent is incorporated herein by reference in its entirety and for all purposes. In some embodiments, for example, all custom entity data rows are stored in a single multi-tenant physical table, which may contain multiple logical tables per organization. In some embodiments, multiple "tables" for a single customer may actually be stored in a large table and / or in the same table as data for other customers.

[0124] These and other aspects of the present disclosure may be implemented by various types of hardware, software, firmware, etc. For example, some features of the present disclosure may be implemented at least in part by a machine-readable medium including program instructions, state information, etc. for performing the various operations described herein. Examples of program instructions include machine code such as produced by a compiler and files containing high-level code that can be executed by a computer using an interpreter. Examples of machine-readable media include, but are not limited to, magnetic media such as hard disks, floppy disks, and tapes; optical media such as CD-ROM disks; magneto-optical media; and hardware devices specifically configured to store and execute program instructions, such as read-only memory devices ("ROM") and random access memory ("RAM").

[0125] Although one or more embodiments and techniques are described with reference to implementations in which the service cloud console is implemented in a system having an application server that provides a front end for an on-demand database service capable of supporting multiple tenants, one or more embodiments and techniques are not limited to multi-tenant databases nor to deployment on application servers. Other database architectures may be used without departing from the scope of the claimed embodiments, i.e., the IBM provided etc. to implement the embodiments.

[0126] Any of the above embodiments may be used alone or in any combination with each other. Although the various embodiments may have been motivated by various deficiencies of the prior art that may be discussed or suggested at one or more locations in the specification, the embodiments may not necessarily address any of these deficiencies. In other words, different embodiments may address different deficiencies discussed in the specification. Some embodiments may only partially address some of the deficiencies or only one defect that may be discussed in the specification, and some embodiments may not address any of these deficiencies.

[0127] Although various embodiments have been described herein, it should be understood that they are presented by way of example only and not limitation. Therefore, the breadth and scope of the present application should not be limited by any embodiment described herein, but should only be limited in accordance with the following and later filed claims and their equivalents.

Claims

1. A computer-implemented method for protecting client data using an application server, the method comprising: storing, by an application server, a key identifier received from a security server over a network connection, the key identifier being associated with a private key, the private key being accessible by the security server and not accessible by the application server, the application server also being in communication with a plurality of client devices over a network; sending, from the application server to the security server, a request for deriving a symmetric key, the request being received after storing the key identifier, the request including a public key generated by the application server, a salt value, and the key identifier; receiving, by the application server from the security server, a symmetric key generated by applying a key derivation function to a key agreement key generated by applying a key agreement protocol to the public key and the private key associated with the key identifier, the symmetric key being stored in an in-memory cache of the application server; as well as Data received from one of the plurality of client devices is encrypted by the application server using the symmetric key, and the encrypted data is stored on a persistent storage device in communication with the application server.

2. The method according to claim 1, wherein: The public key and the private key associated with the key identifier both correspond to different points on an elliptic curve.

3. The method according to claim 1, wherein: The public key and the private key associated with the key identifier are components of a Diffie-Hellman key exchange.

4. The method according to claim 1, further comprising: sending, by the application server, a request to rotate the symmetric key, the request to rotate comprising a different public key, a different salt, and a different key identifier associated with a different private key accessible to the private server; receiving, by the application server from the security server in response to the request to rotate, a different symmetric key, the different symmetric key derived based on the different public key and the different private key using the key derivation function, the different symmetric key being concatenated to the symmetric key and also stored in an in-memory cache of the application server; as well as Data from one of the plurality of client devices is encrypted by the application server using the different symmetric key.

5. The method of claim 4, further comprising, in response to receiving the different symmetric key, deleting the symmetric key from a symmetric key list associated with the application server.

6. The method of claim 4, further comprising maintaining a data structure listing the symmetric keys used by the application server, the table including, for each row, a public key for each symmetric key, a salt for each symmetric key, and a key identifier for each symmetric key.

7. The method according to claim 1, wherein: The private key is retrieved from a key management service in communication with the security server, the key management service storing a plurality of private keys accessible by the security server.

8. The method according to claim 1, wherein: The key derivation function applies a cryptographic hash function to the key agreement key and the salt value.

9. A device for protecting client data, comprising: one or more processors of an application server; as well as A non-transitory computer readable medium storing a plurality of instructions that, when executed, cause the one or more processors to: storing a key identifier received from a security server over a network connection, the key identifier being associated with a private key, the private key being accessible by the security server and inaccessible by the application server, the application server also being in communication with a plurality of client devices over a network; sending a request to the security server to derive a symmetric key, the request being received after storing the key identifier, the request including a public key generated by the application server, a salt value, and the key identifier; receiving the symmetric key from the security server over the network connection, the symmetric key generated by applying a key derivation function to a key agreement key generated by applying a key agreement protocol to the public key and the private key associated with the key identifier, the symmetric key stored in an in-memory cache of the application server; as well as Data from one of the plurality of client devices is encrypted using the symmetric key, and the encrypted data is stored on a persistent storage device in communication with the application server.

10. The device according to claim 9, wherein: The public key and the private key associated with the key identifier both correspond to different points on an elliptic curve.

11. The device according to claim 9, wherein: The public key and the private key associated with the key identifier are components of a Diffie-Hellman key exchange.

12. The device according to claim 9, wherein: The plurality of instructions, when executed, further cause the one or more processors to: sending, by the application server, a request to rotate the symmetric key, the request to rotate comprising a different public key, a different salt, and a different key identifier associated with a different private key accessible to the private server; receiving, by the application server from the security server in response to the request to rotate, a different symmetric key, the different symmetric key derived based on the different public key and the different private key using the key derivation function, the different symmetric key being concatenated to the symmetric key and also stored in an in-memory cache of the application server; as well as Data from one of the plurality of client devices is encrypted by the application server using the different symmetric key.

13. The device according to claim 12, wherein: The plurality of instructions, when executed, further cause the one or more processors to: In response to receiving the different symmetric key, the symmetric key is deleted from a symmetric key list associated with the application server.

14. The device according to claim 9, wherein: The plurality of instructions, when executed, further cause the one or more processors to: A data structure is maintained that lists the symmetric keys used by the application server, the table including, for each row, a public key for each symmetric key, a salt for each symmetric key, and a key identifier for each symmetric key.

15. The device according to claim 9, wherein: The private key is extracted from a key management service in communication with the secure server, the key management service storing a plurality of private keys accessible by the secure server.

16. The device according to claim 9, wherein: The key derivation function applies a cryptographic hash function to the key agreement key and the salt value.

17. A computer program product comprising computer readable program code executed by one or more processors when extracted from a non-transitory computer readable medium, the program code comprising instructions to: storing a key identifier received from a security server over a network connection, the key identifier being associated with a private key accessible by the security server and inaccessible by an application server that is also in communication with a plurality of client devices over the network; sending a request to the security server to derive a symmetric key, the request being received after storing the key identifier, the request including a public key generated by the application server, a salt value, and the key identifier; receiving the symmetric key from the security server over the network connection, the symmetric key generated by applying a key derivation function to a key agreement key generated by applying a key agreement protocol to the public key and the private key associated with the key identifier, the symmetric key stored in an in-memory cache of the application server; as well as Data from one of the plurality of client devices is encrypted using the symmetric key, and the encrypted data is stored on a persistent storage device in communication with the application server.

18. The computer program product of claim 17, wherein: The public key and the private key associated with the key identifier both correspond to different points on an elliptic curve.

19. The computer program product of claim 17, wherein: The public key and the private key associated with the key identifier are components of a Diffie-Hellman key exchange.

20. The computer program product of claim 17, the program code comprising further instructions to: transmitting, by the application server, a request to rotate the symmetric key, the request to rotate comprising a different public key, a different salt, and a different key identifier associated with a different private key accessible to the private server; receiving, by the application server from the security server in response to the request to rotate, a different symmetric key, the different symmetric key derived based on the different public key and the different private key using the key derivation function, the different symmetric key being concatenated to the symmetric key and also stored in an in-memory cache of the application server; as well as Data from one of the plurality of client devices is encrypted by the application server using the different symmetric key.

21. The computer program product of claim 20, the program code comprising further instructions to: In response to receiving the different symmetric key, the symmetric key is deleted from a symmetric key list associated with the application server.

22. The computer program product of claim 20, the program code comprising further instructions to: A data structure is maintained that lists the symmetric keys used by the application server, the table including, for each row, a public key for each symmetric key, a salt for each symmetric key, and a key identifier for each symmetric key.

23. The computer program product of claim 17, wherein: The private key is extracted from a key management service in communication with the secure server, the key management service storing a plurality of private keys accessible by the secure server.

24. The computer program product of claim 17, wherein: The key derivation function applies a cryptographic hash function to the key agreement key and the salt value.

25. A computer-implemented method for protecting client data using a secure server, the method comprising: receiving, by the security server from the application server, a request to derive a symmetric key, the request comprising a public key, a salt value, and a key identifier associated with a private key; The symmetric key is derived by the security server based on the received public key and the private key associated with the key identifier using a key derivation function, the derivation comprising: extracting the private key associated with the key identifier from a storage location inaccessible to the application server; applying a key agreement protocol to the received public key and the extracted private key associated with the key identifier, the key agreement protocol outputting a key agreement key; and applying a key derivation function to the key agreement key to generate the symmetric key; and The derived symmetric key is sent by the security server to the requesting application server, where it is subsequently stored in an in-memory cache of the application server and used by the application server to encrypt customer data.

26. The method of claim 25, wherein the security server stores a list of asymmetric key pairs for a plurality of tenants, each asymmetric key pair comprising a public key and a private key, each private key being associated with a corresponding key identifier.

27. The method of claim 25, further comprising deleting, by the security server, the derived symmetric key after sending the derived symmetric key to the requesting application server.

28. The method according to claim 25, wherein: The public key and the private key associated with the key identifier both correspond to different points on an elliptic curve.

29. The method of claim 25, wherein the key agreement protocol generates the key agreement key based on an elliptic curve common to both the received public key and the extracted private key associated with the key identifier.

30. The method of claim 25, wherein: The key agreement protocol is the Diffie-Hellman key exchange.

31. The method of claim 25, wherein: The private key is retrieved from a key management service in communication with the security server, the key management service storing a plurality of private keys accessible by the security server.

32. An apparatus for protecting customer data, comprising: one or more processors of a security server; as well as A non-transitory computer readable medium storing a plurality of instructions that, when executed, cause the one or more processors to: receiving a request from an application server to derive a symmetric key, the request comprising a public key, a salt value, and a key identifier associated with a private key; deriving the symmetric key based on the received public key and the private key associated with the key identifier using a key derivation function, the plurality of instructions for deriving the symmetric key comprising instructions for: extracting the private key associated with the key identifier from a storage location inaccessible to the application server; applying a key agreement protocol to the received public key and the extracted private key associated with the key identifier, the key agreement protocol outputting a key agreement key; as well as applying a key derivation function to the key agreement key to generate the symmetric key; as well as The derived symmetric key is sent to the requesting application server, where it is subsequently stored in the application server's in-memory cache and used by the application server to encrypt customer data.

33. The apparatus of claim 32, wherein the plurality of instructions further comprises instructions for causing the one or more processors to store a list of asymmetric keys for a plurality of tenants, each asymmetric key pair comprising a public key and a private key, each private key being associated with a corresponding key identifier.

34. The apparatus of claim 32, the plurality of instructions further comprising instructions to cause the one or more processors to delete, by the security server, the derived symmetric key after sending the derived symmetric key to a requesting application server.

35. The device according to claim 32, wherein: The public key and the private key associated with the key identifier both correspond to different points on an elliptic curve.

36. The apparatus of claim 32, wherein: The key agreement protocol generates the key agreement key based on an elliptic curve common to both the received public key and the extracted private key associated with the key identifier.

37. The device according to claim 32, wherein: The key agreement protocol is the Diffie-Hellman key exchange.

38. The apparatus of claim 32, wherein: The private key is retrieved from a key management service that stores a plurality of private keys accessible to the secure server.

39. A computer program product comprising computer readable program code executed by one or more processors when extracted from a non-transitory computer readable medium, the program code comprising instructions to: receiving a request from an application server to derive a symmetric key, the request comprising a public key, a salt value, and a key identifier associated with a private key; The symmetric key is derived based on the received public key and the private key using a key derivation function, the instructions for deriving the symmetric key comprising instructions for: extracting the private key from a storage location inaccessible to the application server; applying a key agreement protocol to the received public key and the extracted selected private key using an elliptic curve common to both the received public key and the extracted selected private key, the key agreement protocol outputting a key agreement key; as well as applying a key derivation function to the key agreement key to generate the symmetric key; as well as The derived symmetric key is sent to the requesting application server, where it is subsequently stored in the application server's in-memory cache and used by the application server to encrypt customer data stored on the application server.

40. The computer program product of claim 39, further comprising instructions for storing a list of asymmetric keys for a plurality of tenants, the application server being associated with one of the plurality of tenants, each symmetric key in the list being associated with a public key accessible to the tenant and a private key accessible to the security server and inaccessible to the plurality of tenants.

41. The computer program product of claim 39, further comprising instructions for deleting the derived symmetric key after sending the derived symmetric key to the requesting application server.

42. The computer program product of claim 39, wherein: The key agreement protocol generates the key agreement key based on an elliptic curve common to both the received public key and the extracted private key associated with the key identifier.

43. The computer program product of claim 39, wherein: The key agreement protocol is the Diffie-Hellman key exchange.

44. The computer program product of claim 39, wherein: The private key is extracted from a key management service in communication with a secure server, the key server comprising a hardware security module storing a plurality of private keys linked to a plurality of public keys provided to the secure server.

Images