CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to and the benefit of the filing date of U.S. Application Serial No. 14/861,039, filed September 22, 2015, which is hereby incorporated by reference in its entirety.

TECHNICAL FIELD

The present disclosure relates generally to data security. More particularly, the present disclosure is directed to systems, methods, and devices, for providing a secure computer cluster with encryption in computing environments that deal with sensitive information, and in some aspects is directed to secure computer clusters having encryption of at-rest and in-motion data and being compliant with one or more proprietary information security standards.

BACKGROUND

Data sets generated in computing applications— e.g., those used in business intelligence and other applications— have been growing in size and complexity for some time. At the same time, more and more data of a sensitive nature is communicated over networks and/or stored or computed/processed using remote servers. By way of example, the use of payment cards for a broad spectrum of cashless transactions has become ubiquitous in the current economy, accounting for hundreds of billions of dollars in transactions per year. MasterCard International Incorporated, one example of a payment card network operator, processes millions of transactions per hour across roughly 230 countries. Aspects involved with the use of payment cards typically include the authentication of the payor/consumer using the payment card, as well as the authorization of the transaction based upon the availability of monies in the payor's/consumer's bank account. During this cashless transaction process, a large amount of transaction data, some of which is considered sensitive financial data, is generated and collected, often rapidly. Other examples of environments or applications involving data with a high volume, variety, velocity of generation/processing/transport, variability, and complexity— generally referred to as "big data"— include medical records, retail, government databases, and the like.

In these types of applications and others, in which sensitive information is generated, collected, processed, accessible to various clients, and so on, it may frequently be desirable for such data to be stored, transferred, processed, etc., in a secure system with secure protocols. One example of a security benchmark for such protocols exists in the payment card setting and is known as the Payment Card Industry (TCP') Data Security Standard. The PCI Standard was created to increase controls and security protocols used in connection with cardholder information (e.g., to reduce credit card fraud). Other examples of security benchmarks and the like may include security requirements associated with the Health Insurance Portability and Accountability Act ("HIPAA"). Many government database and computing applications deal in sensitive information as well, and thus in various instances may be required to satisfy some minimum requirements related to security and encryption of data.

Nevertheless, traditional computing systems used in large-scale (e.g., big data) applications do not meet typical security protocols for, e.g., the above- · mentioned types of applications. By way of illustration, Hadoop® networks have been designed and implemented to provide parallel computing for big data applications such as social media, other business intelligence applications, and the like, in which the data grows exponentially and tends to be difficult to timely (i.e., rapidly) collect in a structured manner. While the parallel, speedy, and scalable nature of Hadoop networks can be useful for aggregating and organizing large data sets, these types of networks often lack sufficient security measures to be amenable to applications such as those described above, wherein sensitive data is at issue, thus requiring protection and security measures to be implemented. Because existing large-scale computing (e.g., Hadoop-like) networks designed for big-data applications do not provide for sufficient security and/or encryption capabilities, secure networks are currently implemented using architectures mat are not ideal for big data and like applications.

SUMMARY

In view of the above shortcomings in conventional computing and database solutions, in computing networks (e.g., Hadoop environments or the like) that deal with sensitive information— and particularly in those implemented on large data sets and used in on-the fly actionable applications (e.g., big data or business intelligence)— there exists a need for providing some security and/or encryption techniques to aspects of the data storage, updating, access, and/or retrieval process. In particular, there exists a need for a scalable, fast, and highly parallel network that, on tiie one hand, is capable of gathering significant amounts of data (e.g., as generated in the payment transaction process) and yet, on the other hand, is also sufficiently secure to satisfy any market, regulatory, or other needs for data privacy, security, etc. In this connection, embodiments of the present disclosure include systems, methods, and devices, capable of providing encryption of data (e.g., at-rest and in-motion data), including, for example, in computing environments that deal with sensitive information and/or that comply with a proprietary information security standard.

Embodiments of the present disclosure include a secure computing system with at-rest and in-motion encryption. The system includes a file system that in turn includes a set of encryption zones. Bach of the encryption zones includes encrypted files. The system also includes a set of encrypted data encryption keys. Each of the encrypted data encryption keys corresponds to one of the encrypted files. In this manner, unencrypted versions of the encrypted data encryption keys decrypt the corresponding encrypted files. Furthermore, the system includes an encryption zone key for each of the encryption zones. Each of the encryption zone keys corresponds to at least one of the encrypted data encryption keys, such tiiat the encryption zone keys decrypt the corresponding encrypted data encryption keys to generate the unencrypted version of the encrypted data encryption key. In other embodiments, the secure computing system includes a node that is external to the file system, and that stores the encrypted data encryption keys. The secure computing system, in further embodiments, also includes a hardware security module that stores at least some of the encryption zone keys.

The secure computing system, in example implementations, includes a key management service that is coupled to the file system and that processes requests for one or more of the encryption zone keys. Further to mis example implementation, the system may include a key server that is coupled to the key management service and that stores the encryption zone keys. The key management service is coupled to the file system using a first mutual secure sockets layer, and the key server is coupled to the key management service using a second mutual secure sockets layer. In another example deployment, the key management service is used for a first live mode, and the secure computing system further includes a duplicate key management

service used for a first standby mode. Further to this deployment, the key server includes the following: (1) a key trustee server used for a second live mode; (2) a duplicate key trustee server used for a second standby mode; (3) a hardware security module used for a third live mode; and/or (4) a duplicate hardware security module used for a third standby mode.

In addition, the system may also include an active directory coupled to a computer cluster that utilizes the file system. Hie active directory may be coupled to the computer cluster using a third mutual secure sockets layer, such that the active directory provides a certificate to a client to enable the client to access the computer cluster via a fourth mutual secure sockets layer using the certificate. In another deployment, the computer cluster is a Hadoop cluster, and, by the use of the encryption zone keys, the encrypted data encryption keys, the first, second, third, and fourth mutual secure sockets layers, and by the use of permissions and authorizations, the Hadoop cluster is secure beyond what is required for compliance with the Payment Card Industry Data Security Standard.

Aspects of the present disclosure also include a method for storing and processing data in a Hadoop computer cluster. The method includes generating an encrypted file from a file using a data encryption key specific to the file. The method also includes storing the encrypted data file in an encryption zone within a file system of the Hadoop computer cluster. Additionally, the method includes generating an encrypted data encryption key from the data encryption key using an encryption zone key specific to the encryption zone. The method further includes storing the encrypted data encryption key in a node external to the file system.

In embodiments of the present disclosure, the method includes decrypting the encrypted data encryption key using the encryption zone key, thus generating die data encryption key; and decrypting the encrypted file using the data encryption key. The method may also include storing the encryption zone key in at least one of a key trustee server and a hardware security module; and rotating the encryption zone key based upon one or more of characteristics of the encryption zone and industry compliance standards. In one or more deployments, the method includes receiving, from a client, a request for access to the encrypted file; and sending, in response to the request, the encrypted file and the encryption zone key specific to the encryption zone mat stores the encrypted file. Sending the encrypted file may be done using mutual SSL. Additionally, the method may include verifying the client

has permission and is authorized to access the file as requested. Further embodiments may involve the method storing the data encryption key external to the Hadoop computer cluster.

The present disclosure, in some embodiments, includes a Hadoop cluster having a Hadoop distributed file system ("HDFS"). The HDFS is coupled respectively to Hadoop services and to a key server using mutual SSL. The HDFS also includes a set of encryption zones, each of which stores encrypted files.

Moreover, the Hadoop cluster includes a node mat in turn includes a set of encrypted data encryption keys, each of which is specific to one of the encrypted files. The Hadoop cluster also includes a key server with a set of encryption zone keys stored thereon. Each the encryption zone keys corresponds to one of the encryption zones. For each of the encryption zones, the corresponding encryption zone key decrypts the encrypted data encryption key specific to encrypted file stored in the encryption zone.

In example implementations of the Hadoop cluster, clients connect to the Hadoop cluster using mutual SSL. Furthermore, the Hadoop services may include one or more of an operating system, a data warehouse, an execution engine, a workflow scheduler, a query engine, an interface aggregator, and a search platform; and each of the Hadoop services may be mutual SSL enabled. The encrypted files, in one embodiment, include cardholder data and/or medical records data. Additionally, in example deployments, the key server is coupled to the HDFS using mutual SSL; and the key server receives proxied client requests for access to the encryption zone keys stored on the key server.

BRIEF DESCRIPTION OF THE DRAWINGS

Further aspects of the present disclosure will be more readily appreciated upon review of the detailed description of the various disclosed embodiments, described below, when taken in conjunction with the accompanying figures.

Figure 1 illustrates an example payment card transaction processing system provided in connection with implementations of various embodiments of the disclosure.

Figure 2 illustrates an example computing system in which various embodiments of the disclosure may be implemented.

Figure 3 illustrates another example computing system in which various embodiments of the disclosure may be implemented.

Figure 4 is an example flow diagram illustrating various operations that may be performed to store and process data in accordance with various embodiments of the disclosure.

Figure 5 is an example flow diagram illustrating various operations that may be performed to store and process data in accordance with additional embodiments of the disclosure.

Figure 6 illustrates an example computing module that may be used to implement features of various embodiments of the disclosure.

The figures are described in greater detail in the description and examples below, are provided for purposes of illustration only, and merely depict typical or example embodiments of the disclosure. The figures are not intended to be exhaustive or to limit the disclosure to the precise form disclosed. It should also be understood that the disclosure may be practiced with modification or alteration, and that the disclosure may be limited only by the claims and the equivalents thereof.

DETAILED DESCRIPTION

Embodiments of the present disclosure are directed to systems, methods, and devices, capable of providing a secure computer cluster with encryption, e.g., of at-rest and in-motion data, and including, for example, in computing environments such as payment and other networks mat deal with sensitive

information and that may be subject to industry security standards and/or protocols. The details of some example embodiments of the systems, methods, and devices of the present disclosure are set forth in the description below. Other features, objects, and advantages of the disclosure will be apparent to one of skill in the art upon examination of the present description, figures, examples, and claims. It is intended that all such additional systems, methods, features, and advantages be included within this description, be within the scope of the present disclosure, and be protected by one or more of the accompanying claims.

The present disclosure includes computing networks (e.g., Hadoop environments or the like) that deal with sensitive information. Some embodiments includes such computer networks implemented on large data sets and used in on-the fly actionable applications (e.g., big data), and such computer networks that provide security and/or encryption techniques to data storing, updating, accessing, and retrieval processes. Thus, in accordance with embodiments of the present disclosure, whether the sensitive data is m-motion or at-rest, the data may be protected, for example, at least by the combination of layered encryption keys being applied and/or using mutual SSL for transmitting data within the network/computer system or externally therefrom. In further cases, authorization and permissions verifications are also implemented to provide additional layers of security.

As instances of the present disclosure relate to electronic transaction processing and data generated and collected thereby, the following description provides relevant context for various embodiments described herein. For example, Figure 1 depicts example payment card transaction processing system 100, which may operate in connection with embodiments of the disclosed systems, methods, and devices. Transaction processing of card-based payments, including electronic payments, may include both an authorization side and a clearing side. System 100 depicts both the authorization side and the clearing side of card-based payment transactions.

The authorization side may involve the process of confirming that a cardholder (or purchaser) has a sufficient line of credit to cover a proposed payment for an item. The clearing side of the transaction may involve reconciliation between an issuing bank (of a payment card) 114 and an acquiring (or merchant) bank 110— e.g., determining the amount owed by issuing bank 114 to acquiring bank 110 or vice versa. Later on, funds may be exchanged between issuing bank 114 and

acquiring/merchant bank 110, typically based on the clearing process.

In a typical card-based payment system transaction (or purchase transaction), purchaser 102 presents payment mechanism 104, which in various embodiments is a credit/debit/prepaid card, to merchant 106 for the purchase of an hem. This purchase transaction is indicated by arrow 124. The item may be a good and/or a service. "Payment mechanism" 104 or "payment card," as used herein, may also refer to a conventional magnetic-stripe credit or debit card, or similar proximity payment device (utilized on its own or incorporated into another device such as a mobile telephone, personal digital assistant (PDA), etc.) having near field

communications (NFC) capabilities, such as a radio frequency identification (RFID) chip implemented therein. "Payment mechanism" 104 or "payment card" may also

further refer to virtual or limited-use account numbers and electronic wallets and the like, such as may be used in online transactions.

It will be understood by those of ordinary skill in the art that, prior to the occurrence of such a transaction, purchaser 102 was issued payment mechanism 104 by issuing bank 122. Each payment mechanism 104 is typically associated with an account of purchaser 102, whether purchaser 102 is an individual or some other entity. Likewise, each transaction entered into using payment mechanism 104 is associated with the account In this regard, for each purchase transaction, payment network 112 processes account transactions by associating each transaction with the corresponding account, as is described in detail below. Periodically, as payment network 112 collects and processes account transactions, the information associated with these transactions is stored and sorted so that it may be subsequently analyzed, dispersed, and the like, as desired.

Moreover, it will be understood that merchant 106 has established a relationship with acquiring bank 110, thereby allowing merchant 106 to receive payment mechanism 104 (e.g., credit/debit cards) as payment for items. That is, acquiring/merchant banks (e.g., 110) and issuing banks (e.g., 114) may participate in various payment networks, including, by way of example, payment network 112. One such payment network is operated by MasterCard International Incorporated, the assignee of the present disclosure.

Referring again to Figure 1, after purchaser 102 presents payment mechanism 104 to merchant 106, merchant 106 may send a request message

(indicated by arrow 126), which in some embodiments may be all or part of an authorization request, to acquiring bank 110 via point-of sale (POS) terminal 108 located at or otherwise controlled by merchant 106. In turn, acquiring bank 110 communicates with payment network 112 (indicated by arrow 128), and payment network 112 communicates with issuing bank 114 (indicated by arrow 130) to determine whether purchaser 102 is authorized to make transaction 124. Issuing bank 114 either approves or declines the authorization request and thereafter transmits a response back to merchant 106 (indicated by arrows 136, 138, and 140). Merchant 106 may then either complete or cancel purchase transaction 124, based upon the response to the request message.

If purchase transaction 124 is approved, the transaction amount associated therewith will be sent from issuing bank 114 through payment network 112 to acquiring bank 110. The transaction amount, minus certain fees, will thereafter be deposited within a bank account belonging to merchant 106, in accordance with a process called settlement Issuing bank 114 thereafter bills purchaser 102 (indicated by arrow 132) for all purchase transactions conducted over a given period of time by sending a statement to purchaser 102. Purchaser 102 responds by submission of payment(s) (as indicated by arrow 134) to issuing bank 114. This submission of payments) (as indicated by arrow 134) by purchaser 102 may be automated (e.g., in the case of debit transactions), may be initiated by purchaser 102 for the exact amount matching amounts of purchases during the statement period (e.g., charge cards or credit balances paid in full), and/or may be submitted (in part or in whole) over a period of time mat thereby reflects the amount of the purchases, plus any financing charges agreed upon beforehand between purchaser 102 and issuing bank 114 (e.g., revolving credit balances).

Payment network 112 may include at least one of each of the following: storage, servers, and mainframes (none of which are shown in Fig. 1, but each of which will be appreciated by one of skill in the art upon studying the present disclosure). The mainframes may include a processing device and may be configured to implement the authorization and clearing process, with such configuration and/or associated instructions being stored in the storage and through various network connections to respective counterpart computer systems at issuing bank 114 and acquiring bank 110. The storage may include computer-readable-media storage technologies, such as a floppy drive, hard drive, tape drive, flash drive, optical drive, read-only memory (ROM), random access memory (RAM), and/or the like. The servers and the storage may be controlled by software/hardware and may store data and/or instructions to allow the mainframes to operate in accordance with aspects of the present disclosure. POS terminal 108 is in data communication, directly or indirectly, and at least from time to time, with, e.g., an acquirer host computer (not shown) that is part of payment network 112, and that is operated for or on behalf of acquiring bank 110, which handles payment card transactions for merchant 106. The server may be operated by or on behalf of the payment network 112, and may provide central switching and message routing functions among the member financial institutions of payment network 112. Issuing bank 114 also may make use of an issuer host computer (not shown), and an access point (not shown), via which the issuer host computer exchanges data messages with the server.

It should be noted that, in practice, payment card transaction processing system 100 may involve a number of cardho lders/purchasers 102, POS terminals 108, merchants 106, acquirer host computers, issuer host computers, and access points, as well as a number of respective acquiring and issuing banks 110 and 114. In general, the acquirer host computer may receive authorization requests from POS terminals 108, forward the authorization requests through payment network 112, receive authorization responses, and relay the authorization responses back to POS terminal 108. Moreover, the issuer host computer may, in general, receive authorization requests from the servers and transmit authorization responses back to the server based on the authorization requests.

Also included in a typical card-based payment system transaction are the clearing and settlement processes described above. Clearing (which may happen after transmission of the authorization response if approved) may refer to a process by which issuing bank 114 exchanges transaction information with acquiring bank 110 (also referred to as merchant bank). Referring again to Figure 1, acquiring bank 110 may transmit transaction information to payment network 112, which may include a clearing system (not shown in Fig. 1). The clearing system may validate the transaction information and forward it to issuing bank 114, which prepares data to be included on a payment statement for purchaser 102. The clearing system 114 may then provide reconciliation data to bom issuing bank 114 and acquiring bank 110.

Settlement may refer to a process by which issuing bank 114 exchanges the requisite funds with acquiring bank 110 to complete an approved transaction. In particular, acquiring bank 110 may send clearing data in a clearing message to payment network 112, whereupon payment network 112 calculates a net settlement position and sends advisement to acquiring bank 110 and issuing bank 114. Issuing bank 114 may remit payment to payment network 112, which then sends the payment to acquiring bank 110. Acquiring bank 110 men pays merchant 106 for the purchase made by purchaser 102, and issuing bank 114 bills purchaser 102.

Having provided this context for payment card transaction processing system 100, specific embodiments of the present disclosure will now be described. It will be noted at mis juncture, however, that one of skill in the art will recognize, upon studying the present disclosure, that system 100 merely represents one way in which large (and in some instances, sensitive) data sets are generated and/or processed, and mat system 100 may be modified to represent other environments in which such data

sets are generated, such as in the medical records, retail, government, and other contexts. Such modifications are within the scope of the present disclosure. Further, as will be understood by one of skill in the art, the above-described processing of transactions typically involves a significant amount of data being generated, stored, and transferred, for example using payment network 112. In this regard, payment card transaction processing systems, such as system 100, typically utilize database capabilities within or in conjunction with payment network 112 to store, sort, and analyze transaction data associated with the transactions processed through system 100. As described above, however, these capabilities have not previously been realized using Hadoop and other like networks, as such solutions lack the often-requisite security/encryption measures (e.g., to comply with security protocols). So it is in the healthcare and other industries, though such systems may use a modified version of payment network 112 to gather/process the subject data.

Turning now to Figure 2, some embodiments of secure computing system 200 with at-rest and/or in-motion encryption are depicted. As alluded to previously, the present disclosure relates to providing encryption of data, including at-rest and in-motion data, and including, for example, in computing environments that deal with sensitive information and large data sets. Further, these data sets may be generated in connection with a payment network mat processes transactions, for example, according to the above-described scenario, (tee such system is depicted in secure computing system 200. Moreover, aspects of system 200 may be used in conjunction with various methods disclosed herein, for example, for providing encryption of at-rest and in-motion data, for storing and processing data in a PCI-compliant Hadoop computer cluster, other big-data or business intelligence computing cluster, and the like, as will be described below. Nevertheless, as mentioned above, system 200 may be used in various contexts other than payment networks— for example, to provide at-rest and in-motion encryption for medical records data, retail data (e.g., mat includes financial-related data of purchasers), data in a government database, or any other big-data computing network dealing with sensitive data.

Referring again to Figure 2, example secure computing system 200 is depicted. Secure computing system 200 may be used to implement the above-mentioned layered key and encrypted communication protocols in order to protect sensitive data stored and processed by system 200— e.g., by business intelligence clients or the like mat wish to access computer cluster 244 and various data stored in connection therewith (e.g., to run jobs on computer cluster 244). As shown, system 200 includes computer cluster 244 and client 218. In one embodiment, payment network 112 may be implemented at least in part using computing system 200.

As generally set forth above with reference to Figure 1, payment network 112 collects and processes account transactions, typically a large number of such transactions. These account transactions, in various embodiments, originate with one or more of POS terminals 108.1-n. Given the large number of account transactions potentially stored, sorted, organized, and tracked by payment network 112, payment network 112 typically maintains a significant database of information related to the account transactions. For example, this database of information, which in whole or in part may be referred to herein as one or more data sets, or more simply, data (or information), may include such account-transaction-related information as the timing, purchase amount, frequency, general category, and location of purchases made, as well as information about items purchased. Typically, these data sets may be included in transactions files, wherein each transaction file is associated with an account of a purchaser 102. Thus, any of this information may generally be stored and processed in computing system 200.

In accordance with embodiments of secure computing system 200, examples of security techniques, and the associated hardware and architectures, will be described that may achieve at-rest or in-motion encryption, or a combination of the two. In various implementations, these techniques include the use of layered encryption keys for encryption of at-rest data, and/or the use of mutual secure sockets layers ("SSL") for encryption of in-motion data. Generally, the keys described herein may be used to scramble underlying data. Some example implementations of keys described herein may include 256-bit keys. The use of the disclosed layered key technique and/or the mutual SSL in big data computing environments may render such environments amenable to various of the above-described applications in which sensitive data is at issue— e.g., payment networks, retail, medical records, etc., that may be subject to information security standards. Before describing the detail of these security techniques, additional description of some of the example hardware for the computing environment is provided, as follows.

As shown in Figure 2, computing system 200 may include computer cluster 244 and client 218. Client 218 may be a user or entity external to computer cluster 244, or may be internal to computer cluster 244, but in any case, for security purposes, the nature and extent to which client 218 is allowed to access particular data stored in computer cluster 244, may typically be limited and/or controlled. In particular, client 218 typically attempts to access computer cluster 244 in order to, for example, submit jobs thereto or kill jobs thereon, process or access data stored thereon, and receiver results therefrom.

In mis regard, client 218 may be a big data client, or a business intelligence client, e.g., that wishes to run business intelligence tools and/or other applications through computer cluster 244, or to otherwise access data stored in system 200, and thus that would benefit from accessing computer cluster 244. Client 218 may, in various examples, be a Hadoop API (application programming interface) client, may be any application, may use an enterprise ID to connect to computer cluster 244, and/or may be an end user (e.g., an individual human) using a computer. Client 218 may be coupled to computer cluster 244 (e.g., via connection 234), such that client 218 may access computer cluster 244. By way of example, client 218 may access computer cluster 244 under automated instruction, or directly by a human user of computer.

Computer cluster 244 may be part of or may function in conjunction with one or more of the above-described mainframes that may be present in payment network 112, or that may be present in other types of computing networks used for big data and/or business intelligence applications. Alternatively, computer cluster 244 may itself include one or more mainframes (see, e.g., mainframe 332 in Figure 3).

As illustrated in Figure 2, in one embodiment, system 200 includes file system 208, which in turn includes a set of one or more encryption zones 210. Each encryption zone 210 includes encrypted data files— in other words, within each encryption zone 210 are encrypted data files. The encrypted data files may be any type of data file, but may include, in the payment network example, account transaction files associated with cardholder transactions. In other examples, the data files may include other types of data (e.g., medical records data), but in general, the data files may include any type of data.

In addition to file system 208, computer cluster 244 includes a set of encrypted data encryption keys. Each of the encrypted data encryption keys correspond to one of the encrypted data files stored in an encryption zone 210. In this regard, an encrypted data file may be decrypted using the decrypted (or unencrypted) version of the corresponding encrypted data encryption key. For security reasons,

however, the unencrypted data encryption key, in various embodiments, is not stored on file system 208, nor is the unencrypted data encryption key typically passed between the various elements of computer cluster 244 or externally therefrom (e.g., to client 218). In this manner, for example, unauthorized access to fde system 208 will not result in exposure of the unencrypted data encryption key needed to decrypt the encrypted files in encryption zones 210. Accordingly, the use of encrypted data encryption keys introduces a layered approach to encryption security.

System 200 also includes an encryption zone key for each encryption zone 210. Each of the encryption zone keys corresponds to at least one of the encrypted data encryption keys. In this manner, an encryption zone key may be used to decrypt the corresponding encrypted data encryption key. Subsequently, as mentioned above, the unencrypted (or decrypted) version of the encrypted data encryption key may be used to decrypt the corresponding encrypted file.

Accordingly, die use of encryption zone keys in conjunction with encrypted data encryption keys may further the layered approach to encryption security.

In one example scenario, client 218 requests from computer cluster 244 access to an encrypted file stored hi encryption zone 210. Assuming client 218 has the requisite permissions and/or authorization required for this request (as will be described in further detail with respect to Figure 3), computer cluster 244 sends client 218 the encrypted file and the corresponding encryption zone key. Client 218 men decrypts the encrypted file using the encryption zone key and a local copy of the encrypted data encryption key, as described above. As illustrated in this example, the encrypted file and the encryption zone key are passed across the connection (e.g., connection 206) to client 218, while the encrypted data encryption key is not This may limit unwanted/unauthorized access to the encrypted data encryption key, and may provide for increased security for the encrypted file.

Using the above-described multi-layer key encryption may thus provide security for sensitive data stored in computer cluster 244. In accordance with embodiments described herein, such sensitive data is accessible only to clients 218 having the corresponding zone encryption key and encrypted data encryption key. Unauthorized clients 218 that do not hold the proper keys will be unable to access the encrypted files stored in encryption zones 210. Accordingly, as mentioned above, mis multi-layer key encryption may be used to protect sensitive data stored in system 200.

Figure 3 depicts embodiments of secure computing system 300 with attest and/or in-motion encryption. In various of the embodiments shown in Figure 3, system 300 may be substantially similar to system 200. As shown, however, one embodiment of system 300 includes key management service 310 and key server 346. Key management service 310 may be coupled to file system 208 and key server 346. Key management service 310 processes requests (e.g., from client 218) for one or more of the encryption zone keys mat may be stored in key server 346. For example, key management service 310 may proxy requests from client 218 to key server 346, thus providing an extra layer of security around files stored in system 300 (e.g., because client 218 does not have direct access to key server 246). In additional embodiments, key server 346 is implemented using key trustee server 312, or a combination of key trustee server 312 and hardware security module 314, which may be integrated into the back-end of system 300.

If both key trustee server 12 and hardware security module 314 are present in system 300, key trustee server 12 and hardware security module 314 together may provide redundant key service for file system 208. For example, if one of key trustee server 312 or hardware security module 314 fails, the other may be utilized as a backup. Likewise, in some example embodiments, key management service 310 may be made redundant as well. In such examples, system 300 includes a duplicate key management service (not shown, but, e.g., key management service 310), a duplicate key trustee server (not shown, but, e.g., key trustee server 312), and/or a duplicate hardware security module (not shown, but, e.g., hardware security module 314). Moreover, key management service 310 may be used for a first live mode, and the duplicate key management service may be used for a first standby mode; key trustee server 312 may be used for a second live mode and the duplicate key trustee server may be used for a second standby mode; and hardware security module 314 may be used for a third live mode, and the duplicate hardware security module may be used for a third standby mode.

In some embodiments, key management service 310 resides within or is part of computer cluster 244. In other embodiments, however, key management service 310 may be external to computer cluster 244. Further, as shown, key server 346 may be external to computer cluster 244, but may in other instances be internal thereto. As mentioned some instances of the present disclosure may include hardware security module 314, which may alternatively or additionally store various keys described herein, including, e.g., encryption zone keys. Although hardware security module 314 is shown as being part of key server 346, in some example embodiments, hardware security module 314 may be external to key server 346.

System 300, in example implementations, includes node 344, which may be external to file system 208. In some instances, e.g., if computer cluster 244 is a Hadoop cluster, node 344 may be a master node and may, for example, by implemented as a NameNode. The encrypted data encryption keys may be stored on node 344. Node 344 may be part of or accessible by computer cluster 244, but typically is not accessible to client 218. In this manner, client 218 will not have 0 unfettered access to the encrypted data encryption keys stored on computer cluster 244. Node 344 may also have access to one or more agent nodes 346 that may run underlying jobs distributed or delegated by node 344. Node 344 may also be a service node, and in some cases, there may be multiple nodes 344 included in computer cluster 244.

As mentioned above, in addition to multiple layers of encryption using encryption keys, in-motion data may be encrypted using mutual secure sockets layers ("SSL") for security purposes. For example, system 300 may engage in various types of internal and/or external communications (e.g., including TCP/IP, RPC, HTTP, HTTPS, and the like), and any or all such communications may be encrypted at the mutual SSL level. Such communications or connections (e.g., as may at times be represented as arrows), such as connections 206, 334, 336, 338, 340, and/or 342, in Figures 2 and 3) may be over a wire, wireless, and so on, as will be apparent to one of skill in the art upon studying the present disclosure. System 300 provides examples of how this may be done, as will be described below and with further reference to Figure 3. It will be noted that in Figures 2 and 3, one or more of the elements of systems 200 and 300 that are shown as filled with a dotted pattern fill may be mutual SSL enabled. It will also be appreciated by one of ordinary skill in the art upon studying the present disclosure, that various elements may be connected to one another whether or not arrows are explicitly shown. For example, mutual SSL may be used to connect various services 306 to one another, to connect services 306 to file system 208 (including the sub-elements of service 306 and/or file system 208), and to connect services 208 and/or file system 208 to any node 344, agent node 346, key management service 310, and key server 346, and vice versa.

In one example embodiment, key management service 310 is coupled to file system 208 using first mutual SSL connection 334; and key server 346 is coupled to key management service 310 using second mutual SSL connection 336. In this embodiment, the first and second mutual SSL connections 334, 336 provide an additional security measure that protects the encryption zone keys and encrypted files as they are passed to/from and/or within computer cluster 244. Key management service 310 is typically not exposed to client 218, thus providing a security buffer between client 218 and encryption zone keys that may be stored in key server 346. Further, by using the various mutual SSL encrypted connections described herein, wire sniffing may be prevented. For example, the keys described herein are typically not be transferred over the wire (or wireless link, for example) without being encrypted, and decryption of these keys may require the proper certificate, in addition to the above-described keys. Additionally, and as mentioned above, in various embodiments, communications between, e.g., services 306 and file system 208, or other blocks included in system 300, may be done using mutual SSL, such that each party will need the proper certificate to receive the communication properly. In this regard, some implementations of key management service 310 may provide the advantage in that key management service 310 receives requests using different protocols, but then may use only a single protocol to communicate with key server 346. This may simplify the tasks required of key server 346, in addition to providing additional security, as mentioned above.

System 300, in another example embodiment, includes directory 316. Client 218 may be coupled to directory 316 (e.g., via connection 342). Directory 316 may in turn be coupled to computer cluster 244 (e.g., via connection 340) using third mutual SSL connection 340. Connection 342 need not be mutual SSL encrypted (though in some instances, connection 342 is mutual SSL encrypted)— for example, client 218 may access directory 316 over connection 342 in order to get a secure identification in a secure manner but using a non-secure network connection.

Accordingly, directory 316 may provide a certificate to enable client 218 to access computer cluster 244 via fourth mutual SSL connection 234. In one embodiment, directory 216 may be an active directory (e.g., Kerberos KDS, or the like) that, as mentioned, issues one or more tickets to client 218 so that client 218 may obtain the ticket in a secure manner over a non-secure network connection (e.g., by connection 342) and ultimately access computer cluster 244 using the ticket In this manner,

directory 316 may implement a network authentication protocol to restrict access to computer cluster 244 to only authorized clients 218 (e.g., those clients 218 having the proper ticket).

CLAIMS

What is claimed is:

1. A secure computing system with at-rest and in-motion encryption, the system comprising:

a file system comprising a set of encryption zones, each of the encryption zones comprising encrypted files;

a set of encrypted data encryption keys, each of the encrypted data encryption keys corresponding to one of the encrypted files, such that unencrypted versions of the encrypted data encryption keys decrypt the corresponding encrypted files; and an encryption zone key for each of the encryption zones, each of the encryption zone keys corresponding to at least one of the encrypted data encryption keys, such that the encryption zone keys decrypt the corresponding encrypted data encryption keys to generate the unencrypted version of the encrypted data encryption key.

2. The secure computing system of claim 1, further comprising a node that is external to the file system, and that stores the encrypted data encryption keys.

3. The secure computing system of claim 1, further comprising a key management service that is coupled to the file system and mat processes requests for one or more of the encryption zone keys.

4. The secure computing system of claim 3, further comprising a key server that is coupled to the key management service and that stores the encryption zone keys.

5. The secure computing system of claim 4, wherein the key management service is coupled to the file system using a first mutual secure sockets layer, and wherein the key server is coupled to the key management service using a second mutual secure sockets layer.

6. The secure computing system of claim S, further comprising an active directory coupled to a computer cluster that utilizes the file system, wherein the active directory is coupled to the computer cluster using a third mutual secure sockets layer, such that the active directory provides a certificate to a client to enable the client to access the computer cluster via a fourth mutual secure sockets layer using the certificate.

7. The secure computing system of claim 6, wherein:

the computer cluster is a Hadoop cluster, and

by the use of the encryption zone keys, the encrypted data encryption keys, die first, second, third, and fourth mutual secure sockets layers, and by the use of permissions and authorizations, die Hadoop cluster is secure beyond what is required for compliance with the Payment Card Industry Data Security Standard.

8. The secure computing system of claim 4, wherein:

the key management service is used for a first live mode;

the secure computing system further comprises a duplicate key management service used for a first standby mode; and

the key server comprises:

a key trustee server used for a second live mode;

a duplicate key trustee server used for a second standby mode;

a hardware security module used for a third live mode; and a duplicate hardware security module used for a third standby mode.

9. The secure computing system of claim 1 , further comprising a hardware security module that stores at least some of the encryption zone keys.

10. A method for storing and processing data in a Hadoop computer cluster, the method comprising:

generating an encrypted tile from a file using a data encryption key specific to the file;

storing the encrypted data file in an encryption zone within a file system of the Hadoop computer cluster;

generating an encrypted data encryption key from the data encryption key using an encryption zone key specific to the encryption zone; and

storing the encrypted data encryption key in a node external to the file system.

11. The method of claim 10, further comprising:

decrypting the encrypted data encryption key using the encryption zone key, thus generating the data encryption key; and

decrypting the encrypted file using the data encryption key.

12. Hie method of claim 10, further comprising:

storing the encryption zone key in at least one of a key trustee server and a hardware security module; and

rotating the encryption zone key based upon one or more of characteristics of the encryption zone and industry compliance standards.

13. The method of claim 10, further comprising:

receiving, from a client, a request for access to the encrypted file; and sending, in response to the request, the encrypted file and the encryption zone key specific to the encryption zone that stores the encrypted file, wherein sending the encrypted file is done using mutual SSL.

14. The method of claim 13, further comprising verifying the client has permission and is authorized to access the file as requested.

15. The method of claim 10, further comprising storing the data encryption key external to the Hadoop computer cluster.

16. A Hadoop cluster, comprising:

a Hadoop distributed file system coupled respectively to Hadoop services and to a key server using mutual SSL, the Hadoop distributed file system comprising a set of encryption zones, wherein each of the encryption zones stores encrypted files; a node, comprising a set of encrypted data encryption keys, each of which is specific to one of the encrypted files; and

a key server with a set of encryption zone keys stored thereon, each the encryption zone keys corresponding to one of the encryption zones, wherein, for each of the encryption zones, the corresponding encryption zone key decrypts the encrypted data encryption key specific to encrypted file stored in the encryption zone.

17. The Hadoop cluster of claim 16, wherein clients connect to the Hadoop cluster using mutual SSL.

The Hadoop cluster of claim 16, wherein:

the Hadoop services comprise one or more of an operating system, a data warehouse, an execution engine, a workflow scheduler, a query engine, an interface aggregator, and a search platform; and

each of the Hadoop services is mutual SSL enabled.

19. The Hadoop cluster of claim 16, wherein the encrypted files are selected from the group consisting of cardholder data and medical records data.

20. The Hadoop cluster of claim 16, wherein:

the key server is coupled to the Hadoop distributed file system using mutual SSL; and

the key server receives proxied client requests for access to the encryption zone keys stored on the key server.