CN113498589B

CN113498589B - Managed secret management transmission system and method

Info

Publication number: CN113498589B
Application number: CN202080011007.7A
Authority: CN
Inventors: 克里斯托弗·泰泽尔; 藤本泰诺
Original assignee: Data Key Of Wine Cellar Access Control Co ltd
Current assignee: Data Key Of Wine Cellar Access Control Co ltd
Priority date: 2019-01-29
Filing date: 2020-01-22
Publication date: 2023-03-24
Anticipated expiration: 2040-01-22
Also published as: US20200244455A1; KR20210119491A; EP3903442B1; CN113498589A; KR102396643B1; CA3126952C; EP3903442A1; EP3903442A4; WO2020159774A1; CA3126952A1; US11212096B2; US11616647B2; AU2020216787B2; US20220094539A1; EP4221073A1; EP3903442C0; JP7102621B2; JP2022517133A; AU2020216787A1

Abstract

A hosted secret management transmission system and method for managing secrets at one or more off-site locations that facilitates secret flow, secret retrieval, and secret copying. The method includes defining boundaries for two or more masters, each master having an independent master record and each master including two or more regions; defining a main region within two or more regions; accessing a master record hardware security module as a primary source of secrets within a primary region; defining a secondary area; accessing a backup recording hardware security module within the secondary area, the backup recording hardware security module being a location to create a backup of confidential data from the primary recording hardware security module; and performing a live replication from the primary record hardware security module to the backup record hardware security module, wherein the live replication supports concurrent multi-tenant confidentiality management for a plurality of different companies.

Description

Managed secret management transmission system and method

Technical Field

The present disclosure relates generally to secret management systems and methods, and in particular, to API and cryptographic key security management systems and methods.

Background

Internet security is one of the areas of concern and potential liability in cyberspace, electronic commerce, and the entire internet. There are many types of potential vulnerabilities that hackers or other malicious parties can exploit.

For example, application software such as websites are increasingly utilizing third party APIs. In many systems, APIs, passwords, keys, certificates, encryption keys, and other secrets are stored in code libraries and databases of applications. In these systems, the application's key cannot be prevented from being used outside the web site. The first thing hackers typically do if an application is attacked is the replication environment. This means that a hacker will acquire a copy of the application database if the attack is using SQL, or a server if the attack is damaging. As such, secrets may be lost and data and services protected by the secrets may be compromised.

There is a major need to protect sensitive data, network transactions and communications by removing these API keys from the code base or database of the application, encrypting them and storing them securely in the isolated system. This can limit damage that may occur if the application is damaged or if the developer has a local copy of the application code base or database.

Another problem that arises in the field of application development and hosting is the problem of decrypting production data in the development environment. This may occur due to the actions of a malicious developer or other individual. Alternatively, this may happen accidentally if the developer does not know how to isolate the production secrets. Also, as an example, they may inadvertently trigger a third party production service, such as sending a test notification from a development user to a production user.

Furthermore, another problem arising in the field of application development and hosting is the need to be able to control the geographical location of the data when it is stored in the cloud. Typically, when companies store their data in a hosted cloud, they have little control over where their data is being stored, which can be problematic due to security issues, regulatory issues, and/or other issues.

There is a continuing need in the art for secret management techniques that provide security over the internet and various applications.

Disclosure of Invention

According to some embodiments, a managed secret management transmission system (managed secret transport system) is disclosed that manages secrets at one or more displaced locations. In some such embodiments, the system includes two or more masters (sovereignties), which are components of a larger functional grouping. In one or more embodiments, each master has an independent master record, and each master includes two or more regions; a primary region and any number of secondary regions. In some embodiments, the hosted secret management transfer system further includes a master record hardware security module in a primary region of each authority, each authority being a primary storage of the authority's secret. The master record hardware security module is a real record of all operations (actions) confidential within the corresponding ownership of the master record hardware security module. In some such embodiments, the confidential operation includes one or more of a create operation, an update operation, and a delete operation.

In another aspect of some embodiments, the hosted secret management transmission system further includes a backup recording hardware security module in a secondary region of the two or more regions, the secondary region not being the primary region of ownership. In one or more embodiments, the backup recording hardware security module receives a live copy from the primary recording hardware security module. The backup recording hardware security module is the location where the data backup is created from the master recording hardware security module of the master. In yet another aspect of some embodiments, a hosted secret management transmission system includes a primary cache hardware security module included in each of two or more regions that receives live copies from a backup recording hardware security module. In yet another aspect of some embodiments, the hosted secret management transmission system includes a hardware security module cache pool included in each of the two or more regions. Each hardware security module cache pool is expandable to replicate from a respective primary cache hardware security module of each hardware security module cache pool according to traffic demands within the region.

In some embodiments, the hosted secret management transmission system further comprises a cluster of software containers and a software container management system included in each of the two or more regions. The software container management system ensures that the software container is available and functioning properly. In this way, requests from software containers in the zone cluster are load balanced among the primary cache hardware security module and the hardware security module cache pool for all reads. In one or more embodiments, when a value is requested, the system identifies the original ownership of the value and, if different from the original ownership of the request and is allowable, requests the value from the original ownership and then caches the value in the primary cache hardware security module of the region from which the request originated. The value is then distributed to the hardware security module cache pool via replication.

In some embodiments of the hosted secret management transmission system, the master is defined based on geopolitical boundaries. By way of example only, and not limitation, geopolitical boundaries may include: a country, a national union, or a national group. In other embodiments of the hosted secret management transfer system, the master is arbitrarily defined to organize regions and bind secrets to a single group, company or enterprise. In another aspect of some embodiments of the hosted secret management transmission system, the region is defined by a real world boundary including regional directions (east, west, north, and south) or a country with a ownership. In other embodiments of the hosted secret management transmission system, the region is based in whole or in part on a unique data center included within one or more of the same cloud provider, a different cloud provider, a local system, and a private cloud.

In one or more embodiments, the secondary area provides high availability if the entire primary area becomes unavailable. In another aspect of some embodiments of the hosted secret management transmission system, the master record is where all write operations occur. In yet another aspect of some embodiments of the escrow secret management transmission system, no read operations occur on the primary record except during an emergency. In yet another aspect of some embodiments of the managed secret management transmission system, the backup recording hardware security module keeps the load on the primary recording hardware security module as low as possible to reduce or eliminate the possibility of a database lock occurring. In some embodiments of a hosted secret management transmission system, a primary cache hardware security module serves as a primary replication source for all cached values in its respective region.

In another aspect of some embodiments, the hosted secret management transmission system securely distributes the copied value among the masters to provide reduced request latency, and distributes the copied value through the primary cache hardware security module and the hardware security module cache pool, while the master record hardware security module of the respective master always includes the original value. In some embodiments of the hosted secret management transmission system, an area is designated with a primary database cluster, wherein data is stored in the primary database cluster. Data is globally replicated from a primary database cluster to a distributed replica database located in each region. In one or more embodiments of the hosted secret management transfer system, the data stored in the primary database cluster is metadata of secrets managed in the system that includes one or more of: name, internal name, version number, original master and security policy to which protection values can be distributed. In some embodiments of the hosted secret management transmission system, the data is stored as an event stream that causes metadata entities to be built, rather than storing the metadata as a single entity. In such embodiments, the event stream provides a continuous audit log of all events that resulted in the taking of variant actions. In one or more embodiments of the hosted secret management transmission system, machine learning analysis is used to persist events in audit logs for anomalies and security issues.

In some embodiments of the hosted secret management transmission system, clients are created by users and bound to a key ring (KeyRing) while restricting access to values of a particular environment, ensuring that values in various environments, such as production and development, do not cross. In some embodiments of the hosted secret management transmission system, the client is bound to the environment. In some such embodiments of the hosted secret management transfer system, by way of example only and not limitation, different types of environments include: production, staging, testing and development.

In some embodiments of the hosted secret management transmission system, each region includes a private subnet. In some such implementations, all components in the zone are located in private subnets within each available partition, which eliminates any possibility of direct contact with the internet via an external connection. In another aspect of some embodiments, all communications between regions and communications between masters are handled by encrypted connections, such as virtual private network connections, to increase security.

In another embodiment of a method of escrowing secret management transmission, the method manages the secret at one or more off-site locations. The method comprises the following steps: defining boundaries of two or more masters as components of a larger functional grouping, each master having an independent master record, wherein each master comprises two or more regions; defining a main area within two or more areas; accessing a master record hardware security module within the primary region as a primary source of the secret, wherein the master record hardware security module is a real record of all operations on the secret within its respective ownership, the operations on the secret including one or more of a create operation, an update operation, and a delete operation; defining an off-region (off-region) of two or more regions that are not the main region; accessing a backup recording hardware security module in the closed region, the backup recording hardware security module being a location to create a backup of confidential data from the primary recording hardware security module; performing a real-time copy from the primary recording hardware security module to the backup recording hardware security module; accessing a primary cache hardware security module in each of two or more regions that receives a live copy from a backup recording hardware security module; accessing a hardware security module cache pool in each of two or more regions, wherein the hardware security module cache pool is expandable to be replicated from a primary cache hardware security module according to traffic demands within the region; accessing a cluster of software containers and a software container management system that ensures that the software containers are available and functioning properly in each of two or more regions in the master; and receiving a request for a value at the software container, wherein the request for the value from the software container in the zone cluster is load balanced among the primary cache hardware security module and the hardware security module cache pool for all reads; wherein when a value is requested, the system looks up the original ownership of the value and, if different from the original ownership of the request and is allowable, requests the value from the original ownership and then caches the value in the primary cache hardware security module of the region from which the request originated, wherein the value is then distributed to the hardware security module cache pool via replication.

In some embodiments of the escrow secret management transmission method, the master right is defined based on geopolitical boundaries. By way of example only, and not limitation, geopolitical boundaries may include: a country, a national union, or a national group. In other embodiments that host secret management transfer methods, the master rights are arbitrarily defined to organize regions and bind secrets to a single party, company, or enterprise. In another aspect of some embodiments of the escrow secret management transmission method, the region is defined by a real world boundary including a regional direction (east, west, north, and south) or a country having a ownership. In other embodiments of the escrow secret management transfer method, the region is based in whole or in part on a unique data center included within one or more of the same cloud provider, a different cloud provider, a local system, and a private cloud.

In one or more embodiments, the secondary area provides high availability if the entire primary area becomes unavailable. In another aspect of some embodiments of the escrow secret management transfer method, the master record is where all write operations occur. In yet another aspect of some embodiments of the escrow secret management transmission method, no read operation occurs on the primary record except during an emergency. In yet another aspect of some embodiments of the managed secret management transfer method, the backup recording hardware security module keeps the load on the primary recording hardware security module as low as possible to reduce or eliminate the possibility of a database lock occurring. In some embodiments of the managed secret management transfer method, the primary cache hardware security module serves as a primary replication source for all cached values in its respective region.

In another aspect of some embodiments, a hosted secret management transmission method securely distributes replicated values among masters to provide reduced request latency, and distributes replicated values through a primary cache hardware security module and a hardware security module cache pool, while a master of a respective master records the hardware security module to always include the original value. In some embodiments of the method of escrow secret management transfer, an area is designated with a primary database cluster, wherein data is stored in the primary database cluster. Data is globally replicated from a primary database cluster to a distributed replica database located in each region. In one or more embodiments of the method of escrowing secret management transfer, the data stored in the primary database cluster is metadata of the secret managed in the method, the metadata including one or more of: name, internal name, version number, original master and security policy to which protection values can be distributed. In some embodiments of the hosted secret management transmission system, the data is stored as an event stream that causes metadata entities to be built, rather than storing the metadata as a single entity. In such embodiments, the event stream provides a continuous audit log of all events that resulted in the taking of variant actions. In one or more embodiments of the managed secret management transmission system, events in the audit log are continuously audited for anomalies and security issues using machine learning analysis.

In some embodiments of the escrow secret management transfer method, a client is created by a user and bound to a key ring while restricting access to values of a particular environment, ensuring that values in various environments, such as production and development, do not cross. In some embodiments of the escrow secret management transfer method, the client is bound to the environment. In some such embodiments of the escrow secret management transfer method, by way of example only and not limitation, different types of environments include: production, staging, testing and development.

In some embodiments of the escrow secret management transmission method, each region comprises a private subnet. In some such embodiments, all other components in the zone are located in private subnets within the various available partitions, which eliminates any possibility of direct contact with the internet via an external connection. In another aspect of some embodiments, all communications between regions and communications between masters are handled by encrypted connections, such as virtual private network connections, to increase security.

In one or more other embodiments, a hosted secret management transmission system for managing secrets at one or more offsite locations is disclosed. In some such embodiments, the system includes two or more masters, which are components of a larger functional grouping. In one or more embodiments, each master has an independent master record, and each master includes two or more zones, the two or more zones further including at least a primary zone and a secondary zone. In some embodiments, the hosted secret management transfer system further includes a master record hardware security module in a primary region of each authority, each authority being a primary storage of the authority's secret. The master record hardware security module is a true record of all operations that are confidential within the corresponding master authority for that master record hardware security module. In some such embodiments, the operations on the secret include one or more of a create operation, an update operation, and a delete operation.

In another aspect of some embodiments, the hosted secret management transmission system further includes a backup recording hardware security module in one or more secondary regions, the secondary regions not being primary regions of ownership. In one or more embodiments, the backup record hardware security module receives live copies from a primary record hardware security module that simultaneously supports multi-tenant confidentiality management for multiple different companies. In one or more embodiments, the backup recording hardware security module creates backup data from the primary recording hardware security module.

In yet another aspect of some embodiments, a hosted secret management transmission system includes a primary cache hardware security module included in each of two or more regions that receives live copies from a backup recording hardware security module. In yet another aspect of some embodiments, the hosted secret management transmission system includes a hardware security module cache pool included in each of the two or more regions. Each hardware security module cache pool is expandable to replicate from a respective primary cache hardware security module of each hardware security module cache pool according to traffic demands within the region.

In some embodiments, the hosted secret management transmission system further comprises a software container cluster and a software container management system, the software container cluster and the software container management system being included in each of the two or more regions. The software container management system ensures that the software container is available and functioning properly. In this way, requests from software containers in the zone cluster are load balanced for all read operations among the primary cache hardware security module and the hardware security module cache pool.

In one or more embodiments, when a non-existent value is requested, the system identifies the original master of the value and, if different from the original master of the request and allowable, requests the value from the original master and then caches the value in the primary cache hardware security module of the region from which the request originated. The value is then distributed to the hardware security module cache pool via real-time replication.

Drawings

In the drawings, the same reference numerals denote the same elements or operations. The sizes and relative positions of elements in the drawings are not necessarily drawn to scale. For example, the shapes of various elements and angles are not necessarily drawn to scale, and some of these elements are arbitrarily enlarged and positioned to improve drawing legibility. Further, the particular shapes of the elements as drawn, are not necessarily intended to convey any information regarding the actual shape of the particular elements, and have been solely selected for ease of recognition in the drawings.

FIG. 1 is a schematic diagram showing a hosted secret management transmission system including multiple principals in which the system facilitates secret flow, secret retrieval and secret duplication and multiple regions included in the multiple principals.

FIG. 2A is a schematic diagram illustrating a portion of a managed secret management transmission system including a single master and a plurality of zones included in the single master.

FIG. 2B is a schematic diagram illustrating a portion of a managed secret management transmission system that includes a single zone.

Fig. 3 is a schematic diagram showing the relationship between various key rings, clients, and users.

FIG. 4 is a schematic diagram showing how user accounts, key rings, development clients, and production clients are created.

FIG. 5 is a schematic diagram showing a secret storage process involving a user, a production client, a development client, a key ring, a production secret, a development secret, and multiple versions thereof.

FIG. 6 is a block diagram of an example processor-based client for use with a managed secret management transmission system.

Detailed Description

Those of ordinary skill in the art will appreciate that the present disclosure is illustrative only and is not intended to be in any way limiting. Each of the features and teachings disclosed herein may be used alone or in combination with other features and teachings to provide a hosted secret management system and method. Representative examples utilizing many of these additional features and teachings, both individually and in combination, are described in further detail with reference to the accompanying drawings. This detailed description is merely intended to teach a person of skill in the art further details for implementing various aspects of the present teachings and is not intended to limit the scope of the claims. Therefore, combinations of features disclosed in the detailed description may not be necessary to practice the teachings in the broadest sense, and are instead taught merely to describe certain representative examples of the present teachings.

Some portions of the detailed descriptions herein are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as "processing," "computing," "calculating," "determining," "displaying," "configuring," or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulate and transform data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

Furthermore, various features of the representative examples and the dependent claims may be combined in ways that are not specifically and explicitly enumerated in order to provide additional useful embodiments of the present teachings. It is also expressly noted that all value ranges or indications of groups of entities disclose every possible intermediate value or intermediate entity for the purpose of original disclosure and for the purpose of limiting the claimed subject matter. It is also expressly noted that the sizes and shapes of the components shown in the figures are intended to aid in understanding how the present teachings are implemented, and are not intended to be limiting of the sizes and shapes shown in the examples.

Throughout this specification and the claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" and "comprising", will be construed as open-ended, broad-spectrum, i.e., as if "includes, but is not limited to. Reference throughout the specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic may be combined in any suitable manner in one or more embodiments.

As used in this specification and the appended claims, the singular forms "a", "an", and "the" include plural referents unless the context clearly dictates otherwise. It should also be noted that the term "or" is generally employed in its broadest sense, i.e., as meaning "and/or," unless the context clearly dictates otherwise. The headings and abstract of the disclosure provided herein are for convenience only and do not interpret the scope or meaning of the embodiments.

Disclosed herein is a managed secret management transmission system and method 100 for modern Content Management Systems (CMSs), such as Drupal and WordPress, that enables applications to properly manage access to application secrets (e.g., API and encryption key management) in a secure off-site managed environment. The escrow secret management transmission system and method 100 is integrated into any application to provide a secure way of storing values such as API tokens, passwords, and encryption keys. The managed secret management transmission system and method 100 employs an off-site key management solution to prevent critical vulnerabilities, help applications comply with many industry regulations (e.g., PCI DSS, HIPAA, and other security requirements and regulations), and provide a deep defense "multi-tier" approach to protecting data of applications. In some embodiments, the hosted secret management transmission system and method 100 provides AES-256 encryption to custom plug-ins of applications in a seamless manner to protect static data in the applications while enabling enterprise-level HSM (hardware Security Module) key management.

In some embodiments, the hosted secret management transmission system and method 100 is an authentication, transmission, and routing system provided by, for example, thomson Security (Townsend Security) that obtains encrypted values and routes them to a displaced location where the encrypted values are statically encrypted for storage within the HSM. The managed secret management transmission system and method 100 provides an application administrator with the ability to control the way and location of storage of an application administrator's sensitive keys, thereby increasing the overall security of the application and allowing the application to meet specific regulatory and compliance requirements for key management.

In one or more embodiments, the hosted secret management transmission system and method 100 enables applications of various sizes to meet industry standards for key management through a managed extensible cloud key management system. Unlike other third party key managers, the escrow secret management transmission system and method 100 provides an additional layer of security and system monitoring. In some embodiments, the escrow secret management transfer system and method 100 incorporates off-site API and encryption key management to help applications comply with HIPAA, FERPA, and FISMA. In some embodiments, the managed secret management transmission system and method 100 is automatically configured to protect API keys of numerous third party plug-ins to seamlessly integrate and protect keys of applications. In one or more embodiments of the hosted secrets management system and method 100, the system provides multiple regional redundancies, a platform agnostic, static API for general integration, and regional specific data isolation that enables an application's administrator to select the location of its data store for data ownership.

In some embodiments, in addition to storing the values of the application in the secure encrypted HSM, the managed secret management transmission system and method 100 isolates the values of the development environment and the production environment from each other. This feature of the escrow secret management transmission system and method 100 provides several technical improvements. First, if an application administrator is encrypting values from the production environment by a key stored in the managed secret management system and method 100, those values cannot be decrypted in the development environment. This is important in a regulatory environment where application administrators need to be able to control who has access to encrypted data. Second, the data isolation provided by the hosted secrets management transmission system and method 100 prevents the cryptographic value from being compromised if the e-mail is accidentally sent from the development environment to the production service. The managed secret management transmission system and method 100 isolates the development environment of an application by keeping the production token and keys of the application away from the developer.

Stated otherwise, the escrow secret management transmission system and method 100 manages keys on a "per environment" basis, which reduces or eliminates the possibility of sharing keys from a production environment to a development environment. When using the escrow secret management system and method 100, if sensitive information is encrypted in a production environment, the data is not decrypted anywhere other than in the production environment. In this case, the data is encrypted in production by a production key that is not retrievable outside the production environment. If the database is cloned for development, the key that the CMS has access to cannot decrypt the data.

In some implementations, the hosted secrets management transmission system and method 100 enables a company's administrative user to select a geographic area in which to store the company's secrets (e.g., a user in the United states may wish to store their company's secrets in the United states). If the application administrator is located outside the United states, the hosted secrets management transmission system and method 100 enables the application administrator to select another available area to store their secrets. Because the zones in the managed secret management transmission system and method 100 are isolated, the values set in one zone are not available in any other zone.

Referring to FIG. 1, one or more embodiments of a managed secret management transmission system and method 100 incorporate the use of multiple masters 110 and multiple zones 120. In particular, the managed secret management transmission system and method 100 includes two or more masters 110 that group components of greater functionality. In one or more embodiments, each master 110 has a separate master record, and each master 110 includes two or more regions 120, each region further including at least a primary region 120 and a secondary region 120. In some implementations, the master rights 110 can be drawn based on geopolitical boundaries (e.g., the united states, european union, etc.). In other implementations, the master rights 110 may be drawn arbitrarily to organize the regions 120 and bind secrets to a single group (e.g., a single company or enterprise). The region 120 within the main right 110 may be described by a real world boundary (e.g., east, west countries within the main right). Further, the regions 120 within the master 110 may be based on completely unique data centers (within the same cloud provider, different cloud providers, local systems, private clouds, etc.). The primary area 120 and the secondary area 120 (and potentially additional areas) within each master 110 provide high availability if the entire primary area becomes unavailable.

In some embodiments, the hosted secret management transmission system 100 also includes a master record hardware security module 130 in the primary region 120 of each master 110, the master record hardware security module 130 being the primary source of the secret. The master record hardware security module 130 is a real record of all operations that are confidential within its corresponding master rights 110. In some such embodiments, the confidential operation includes one or more of a create operation, an update operation, and a delete operation. The main recording hardware security module 130 is where all write operations occur. However, no read operation occurs at the primary recording hardware security module 130 except during an emergency.

In another aspect, the hosted secret management transmission system 100 further includes a backup recording hardware security module 140 in the secondary area 120 of the master 110. In one or more embodiments, the backup recording hardware security module 140 receives the live copy from the primary recording hardware security module 130. Backup recording hardware security module 140 is the location where a data backup is created from main recording hardware security module 130 of master authority 110, and backup recording hardware security module 140 keeps the load on main recording hardware security module 130 as low as possible to reduce or eliminate the possibility of a database lock occurring.

Referring now to another component, in some embodiments, the hosted secret management transmission system includes a primary cache hardware security module 150 included in each of the two or more regions 120 that receives live copies from the backup recording hardware security module 140. In yet another component of some embodiments, the hosted secret management transmission system 100 includes a hardware security module cache pool 160, the hardware security module cache pool 160 included in each of the two or more regions 120. Each hardware security module cache pool is expandable to replicate from a respective primary cache hardware security module 150 of each hardware security module cache pool 160 according to traffic demands within the region 120. In some embodiments, the primary cache hardware security module 150 acts as a primary copy source of all cached values in its respective region 120.

Referring now to yet another component, in some embodiments, the hosted secret management transmission system 100 further includes a software container cluster 170 and a software container management system 180, the software container cluster 170 and the software container management system 180 being included in each of the two or more regions 120. The software container management system 180 ensures that the software container 170 is available and functioning properly. In the hosted secret management transmission system 100, requests from the container 170 within the region 120 are load balanced among the primary cache hardware security module 150 and the hardware security module cache pool 160 for all reads. The container 170 is a method of operating system virtualization that enables applications and their dependencies to run in resource-isolated processes. The container 170 helps ensure that applications are deployed quickly, reliably, and consistently, regardless of the deployment environment.

In a managed secret management transmission system 100, when a value is requested that is not present, the system 100 identifies the original ownership 110 of the value. If different from the original authority requested and is allowable, the system requests the value from the original authority 110, which is then cached in the primary cache hardware security module 150 of the region 120 from which the request originated. The value is then distributed to the hardware security module cache pool 160 via replication. Because of this functionality, the hosted secret management system 100 securely distributes the copied value among the masters 110 to provide reduced request latency, and distributes the copied value through the primary cache hardware security module 150 and the hardware security module cache pool 160, while the master record hardware security module 130 of the respective master 110 always includes the original value.

In some embodiments of the hosted secret management system 100, each of the two or more regions 120 includes a primary database cluster 190 that stores data. Data is globally replicated from the primary database cluster 190 to the distributed replica database 194. In one or more embodiments of the hosted secret management system 100, the data stored in the primary database cluster 190 is metadata of the secrets managed in the system, including one or more of: name, internal name, version number, original master and security policy of the location to which the guard value can be distributed. Rather than storing the metadata as a single entity, the data is stored as an event stream. These events are then presented to build the metadata entity, while the event stream provides a continuous audit log of all variant operations taken in the system. The audit log allows additional analysis of events regarding anomalies and security issues using machine learning.

Referring now to fig. 3 and 4, in a managed secret management transmission system 100, clients are created by users and bound to a key ring while restricting access to values of a particular environment, ensuring that values in various environments, such as production and development, do not cross. In this manner, the client is bound to the environment in the managed secret management transmission system 100. In the managed secret management transmission system 100, by way of example only and not limitation, different types of environments include: production, staging, testing and development.

Referring again to fig. 1, 2A, and 2B, in the hosted secret management transmission system 100, each region 120 includes a private subnet 198. In one or more embodiments, private subnet 198 includes software container 170 and software container management system 180. In some such implementations, all of the components in the regions 120 are located in private subnets 198 within the respective available regions 120, which eliminates any possibility of direct contact via an external connection to the internet. On the other hand, all communications between the zones 120 and communications between the masters 110 are handled by private encrypted connections, e.g. via virtual private network connections, to increase security.

Others have attempted to solve the problems addressed by the managed secret management transmission system and method 100, but have not succeeded. Some such third parties attempt to have some similarities to the ultimate functionality of the escrow secret management transfer system and method 100; however, the design and performance of the escrow secret management transfer system and method 100 is unique. For example, the escrow secret management transport system and method 100 is a transport layer system that enables authentication, routing, and escrow, but does not provide storage. Clearly, the escrow secret management transmission system and method 100 enables dynamic creation of restrictions through secrets within the system. Furthermore, the hosted secret management transmission system and method 100 makes it possible for different endpoints to take different storage methods. It should be apparent that the managed secret management transfer system and method 100 is agnostic to the type and environment of the storage method. Furthermore, the hosted secret management transmission system and method 100 makes it possible to draw arbitrary lines in the creation of the master authority boundary, and to create a hybrid region with multiple clouds for secret management.

Some competing systems (competing systems) use Hardware Security Modules (HSMs) that employ default replication between "primary" and any number of "secondary" devices/services. However, this type of default replication is employed only for performance and availability, as by distributing secrets included in the primary device to the secondary devices, the load of the system may be balanced based on the location and/or interruption of any one of the systems. However, this type of third party replication is simply to replicate all or none of the data (all-or-nothing replication). Unless otherwise stated, in this type of third party copy, any content in the primary device is also copied to the secondary device. When dealing with systems that bridge (bridge) many different customers (e.g., companies) and locations around the world, each country has its own data privacy legislation, and this method of copying all or none is unacceptable.

Instead, the managed secret management transmission system and method 100 creates content that it defines as the master 110. Each of these masters 110 enables groupings of regions 120 to be created within the respective master 110. Obviously, each of these masters 110 enables data to be kept secret from the master 110 that sets the data. While the master 110 may be based on a global boundary, the master 110 may also be virtual to isolate secrets for a particular organization or group of organizations. Each master authority 110 has a master record that retains all of its values and logs to provide a confidential audit trail. However, the managed secret management transmission system and method 100 does not copy the data to all other masters 110. In contrast, the escrow secret management transmission system and method 100 makes it possible to control the distribution and transmission of secrets "secret by secret," which can be used to separate a secret of a first company from a secret of a second company, both of which can be hosted on the region 120 of the master 110 in the system 100. In some embodiments, this may be performed by using a whitelist of the master 110 to which the secret is allowed to be distributed and the master 110 to which the secret is allowed to be cached. Notably, the managed secret management transfer system and method 100 does not allow for permanent storage outside of the original master 110.

Such a global cache enables the managed secret management transmission system and method 100 to provide the performance advantage of global redundancy without requiring permanent storage, thereby allowing data "ownership" to be maintained. Such a "secret-by-secret" based complex licensing system provided by the hosted secrets management transmission system and method 100 enables the system to securely provide multi-tenancy (i.e., support multiple different companies simultaneously) while allowing each secret and each user to comply with the data regulations of their own jurisdictions. This is particularly noteworthy because new legislation such as General Data Protection Regulations (GDPR) result in users of the european union possibly having different Data legislation than users in the united states.

In addition to the ability to dynamically and individually limit secrets, the hosted secret management transmission system and method 100 also provides the unique ability to have each region 120 within the master 110 have a storage method that is independent of a particular master 110 or larger system. In this manner, the hosted secret management transmission system and method 100 enables each region 120 to utilize the hardware and services of the environment in which it is located, while other regions 120 in the privilege 110 may utilize different hardware and services. This storage method, independent of the hosted secret management transfer system and method 100, is transparent to the end user. Thus, end users do not have to change their methods, API interfaces, etc. for different storage types.

While some competitors allow storage across different "key stores," those secrets are either spaced by name, or restricted by the name of the value, only have access to the key store in which they are located, and restricted within any cluster to only having access to storage methods available within that cluster.

Unless otherwise noted, the end user must know the type of storage device on which the secret resides in order to retrieve the secret. Notably, in the hosted secret management transmission system and method 100, values may be set in one region 120 (or master 110) and retrieved in another region 120 (or master 110). Further, in the escrow secret management transmission system and method 100, a value may be stored in one region 120 in a first storage method and another value may be stored in a second region 120 within the same master 110 in a second storage method. This storage flexibility of the hosted secret management transmission system and method 100 enables each region 120 to meet the requirements of an individual region 120 without meeting network-wide requirements, which is a requirement of standard primary devices for secondary device replication used in some third party systems.

In addition to the storage method being independent of the managed secret management transmission system and method 100, the managed secret management transmission system and method 100 is also environmentally independent. Unless otherwise noted, the hosted secret management transfer system and method 100 may operate in any environment, and a value may be stored in one region 120 in a first environment, while another value may be stored in a second region 120 within the same master 110 in a second environment.

The core of the authentication and routing layer hosting the secret management transmission system and method 100 may run in any operating system based on Linux, which is capable of running software programs that perform operating system level virtualization (also referred to as containerization). By way of example only, and not limitation, such operating systems include: ubuntu, redHat, centOS and Oracle Linux. These operating systems are found in all major cloud infrastructure providers, such as: amazon web services, azure, google cloud platform, IBM cloud, and Rackspace.

While the managed secret management transmission system and method 100 is particularly well suited for use with secure websites, the system has broad applicability beyond secure websites. The managed secret management transmission system and method 100 may also be used for secret management in enterprise software, as well as for internal software within a corporate network. Furthermore, the hosted secret management transmission system and method 100 may be employed in other technology driven processes in enterprise systems. In some embodiments, the hosted secret management transmission system and method 100 may be used for secret management and for non-technical enterprises, such as production lines where software is loaded onto hardware devices. In other embodiments, the hosted secret management transmission system and method 100 may be used for secret management and for non-technical enterprises, such as factories that create automobiles and load software. With the popularity of the internet of things (IoT), many internet-connected devices need to securely connect with and communicate information to service providers operating the devices. These secrets may be stored locally on the internet-connected device; however, such local storage may create problems when such internet-connected device systems are damaged.

In contrast, the hosted secret management transmission system and method 100 enables internet-connected devices to be shipped without the secrets required for their operation and then authorized to access the secrets after reaching their end-user location. In this embodiment of the hosted secret management transmission system and method 100, access to secrets to which access to internet-connected devices is authorized may be revoked at any time.

Referring now to FIG. 3, a key ring 300 that hosts the secret management transmission system and method 100 is shown. The key ring 300 is a location where secrets are grouped into an environment, by way of example only and not limitation: development and production. Only the administrative account user 310 can change information on the key ring 300 such as billing level, key ring name, and allow the user account 320 to create the development client 330. The development client 330 may be created by anyone designated by the managed account user 310 who has access to the key ring 300. Production client 340 may be created only from authenticated requests, development client 330 creates requests and manages account user 310 authentication requests, providing a third point of authentication, as user authentication has a two-factor authentication, which may be accomplished via the following, by way of example only and not limitation: via a time-based one-time password algorithm or via an SMS message to a registered device.

Referring now to FIG. 4, to create a key ring 300 in the escrow secret management transmission system and method 100, the following process may be implemented: at 410, a user account 320 is created; at 420, the key ring 300 is created via authentication of the user account 320; at 430, a client for the development environment is created that allows connection to the key ring 300 via authentication of the user account 320; and at 440, a client is created that allows access to the production secret on the key ring 300 via authentication of the user account and via two-factor authentication. In this embodiment, the client is created by using the development certificate as a third source of authentication.

FIG. 5 further shows the technical uniqueness of the escrow secret management transfer system and method 100 in comparison to other third party systems. As shown in fig. 5, a user account may be created by authenticating a user 510. The user 510 may be associated with a key ring 530 through a registered production client 510, a registered production client 520, and a registered development client 530. In one or more embodiments, the registered production client 510 may then use the key ring 530 to access the production secret 540. In another aspect of one or more embodiments, the registered development client 530 may then use the key ring 530 to access the development secret 550. In some embodiments, the hosted secret management transmission system and method 100 may maintain different versions of the same production secret 540 (e.g., version-1 542, version-2 544). In another aspect of some embodiments, the hosted secret management transmission system and method 100 may maintain different versions of the same developed secret 550 (e.g., version-1 552, version-2 554).

It should be apparent that in the managed secret management transmission system and method 100, the client has a built-in authority and an unchangeable identity. Unless otherwise noted, a client in the hosted secret management transmission system and method 100 registers for a particular environment from the time it is created. The problem is that other third party systems can create users and then be given additional rights. However, these third party systems are vulnerable to privilege escalation attacks that make it possible to access new secrets from different environments. In this type of attack, a person with improper access to the host system (e.g., a hacker) promotes the user's rights to an environment where the user should not have the rights.

Clearly, the unique architecture of the hosted secret management transmission system and method 100 protects the identity and permissions of the client when it is created, and thus cannot be changed at any time in the future. Unless otherwise noted, the escrow secret management transmission system and method 100 enforces the identity and authority to enter the client as part of the cryptographic signature, so it cannot be changed at any time, thereby eliminating this type of attack. This is a technical improvement that enables the hosted secret management transmission system and method 100 to create a shared system in which users are from different groups that cannot cross each other.

It should be apparent that in some embodiments of the escrow secret management transmission system and method 100, the system stores multiple versions of the key under the namespace of the master secret. This technical improvement achieved by the hosted secret management transmission system and method 100 provides the ability to have multiple versions of the same secret all accessed under a single secret name. In this regard, the hosted secret management transmission system and method 100 enables a user to set various versions of secret values.

Some other third party systems allow for an undesirable type of "version" that must name the key version as secret-v 1, secret-v 2, etc. In addition, there are other third party systems that sometimes allow instances and versions, but they are stored horizontally and are part of a "key scrolling" process in which a new key is programmatically created and linked to a previous key, rather than created by user input. Instead, the escrow secret management transmission system and method 100 enables a user to control the key version and its value. Furthermore, the versions supported by the escrow secret management transmission system and method 100 enable two different users to use the same secret, and if one user updates the secret, the other user is unaffected.

In one or more embodiments, the escrow secret management transmission system and method 100 deploys multiple layers of encryption to protect secrets. The first layer of encryption occurs before the value actually leaves the user's application. In some embodiments, the escrow secret management transmission system and method 100 obtains the encrypted value to be stored and transmits the encrypted value to a server in the escrow secret management transmission system and method 100 over a secure, encrypted connection. Once in the escrow secret management transmission system and method 100, the encrypted value is routed to and stored in a statically encrypted manner inside an HSM (hardware Security module), such as provided by Townsend Security (Townsend Security). This is "end-to-end encryption" because the value sent to the escrow secret management transmission system and method 100 is encrypted and can only be decrypted where it started.

The escrow secret management transmission system and method 100 or anyone else cannot view, modify or lose the encrypted value at any time. In one embodiment, when an application requires a key for encryption/decryption or API requests, the escrow secret management transmission system and method 100 authenticates on behalf of the user using the certificate of the cooperating escrow provider server and releases the key. In this manner, credentials for accessing the managed secret management transmission system and method 100 are provided by an application host or application platform to prevent hijacking and tampering.

Using a process called key wrapping, keys become useless for use outside of the web site or application, environment. In the key wrapping process, a value is obtained and encrypted (wrapped) using a second key. The escrow secret management transmission system and method 100 takes a second key, commonly referred to as a KEK (key encryption key), and stores it in the application in place of the original value. The KEK has no function other than protecting the values stored in the managed secret management transmission system and method 100, and thus is stored securely on the application. Anyone who gains access to the key still does not have the original value and is useless to an attacker because they are irrelevant or not the origin of the value.

This prevents the keys stored by the managed secret management transmission system and method 100 from being viewed or compromised by adding another layer of security to the process. In some embodiments, the escrow secret management transmission system and method 100 employs a tissen secure (Townsend Security) FIPS140-2 compliant key manager to ensure that keys meet the highest industry standards. In some embodiments, the escrow secret management transmission system and method 100 encrypts the value to be stored using AES 256-bit CBC encryption with SHA256 HMAC.

One technical improvement of the escrow secret management transmission system and method 100 is that the system is configured to work with many current and contemplated storage technologies. In some embodiments, the hosted secret management transmission system and method 100 uses a physical or cloud-based hardware security module to statically store secrets securely in the system to provide the highest level of protection. Any hardware security module used in conjunction with the escrow secret management transmission system and method 100 is compatible with at least NIST 140-2, which makes the industry-optimized implementation of storage in encrypted and secure environments possible. Furthermore, these hardware security modules may hold certificates that comply with global regulations such as PCI-DSS, HIPAA, GDPR, etc.

In other embodiments, the escrow secret management transmission system and method 100 uses non-hardware security module storage methods that are statically encrypted and provide a basic level of security for secrets that do not need to meet regulatory compliance. These storage methods will be subject to industry scrutiny and advertised as non-hardware security modules or storage methods that may be non-compliant.

The escrow secret management transmission system and method 100 works for authentication via an x.509 certificate distributed from a hardware security module or a public certificate authority trusted by the escrow secret management transmission system and method 100. These certificates are cryptographically signed so that they are tamper-resistant and have identification data attached. Further, in some embodiments of the escrow secret management transmission system and method 100, authentication is performed by other cryptographically signed tokens, such as kubernets service account tokens. These tokens are verified from the storage technology to the original service by means of cryptographic signatures. This creates a similar encryption and tamper-resistant signature method used via x.509 certificates.

One of the many technical improvements provided by the hosted secret management transfer system and method 100 is that the underlying storage technology that interacts with the system 100 does not have to run in the same operating system used by the system 100. In some embodiments, the managed secret management transmission system and method 100 is based on Linux; however, in other embodiments, the managed secret management transfer system and method 100 is connected to storage technology running in an alternative operating system, such as Windows. The hosted secret management transmission system and method 100 spans not only the environment on which the network is based (e.g., the cloud) but also the capabilities of the operating system of the storage technology, enabling the hosted secret management transmission system and method 100 to truly be a universally applicable network for secret management. In contrast, a competitor's secret management system cannot run across environments and/or across operating systems of storage technologies. Instead, these competitor's confidentiality management systems only function in a particular cloud environment and/or only function in a particular operating system of the storage technology.

It should be apparent that one or more embodiments of the hosted secret management transmission system and method 100 distribute secrets to multiple connected environments and are capable of retrieving secrets, deriving secrets, or both. However, some hardware security module technologies only allow importing secrets and not retrieving secrets. Thus, this is another technical improvement provided by the hosted secret management transmission system and method 100 over some competitor systems.

For use in conjunction with the hosted secret management transmission system and method 100, fig. 6 illustrates a processor-based apparatus suitable for implementing a computing infrastructure for development clients and production clients, as described in fig. 3-5. Although not required, some portions of the embodiments will be described in the general context of processor-executable instructions or logic, such as program application modules, objects, or macrocommands executed by one or more processors. One skilled in the relevant art will appreciate that the described embodiments, as well as other embodiments, may be implemented by various processor-based system configurations, including handheld devices such as: smart phones and tablets, wearable devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, personal computers ("PCs"), network PCs, minicomputers, mainframe computers, and the like.

In some implementations, the client hosting the secret management transmission system and method 100 may include one or more processors 606, a system memory 608, and a system bus 610 that couples various system components including the system memory 608 to the processors 606. Processor-based clients will sometimes be referred to herein in the singular, but this is not intended to limit embodiments to a single system, as in some embodiments more than one system or other networked computing device will be involved. Non-limiting examples of commercially available systems include, but are not limited to, ARM processors from various manufacturers, core microprocessors from Intel Corporation, USA, powerPC microprocessors from IBM, sparc microprocessors from Sun Microsystems, inc., PA _ RISC family microprocessors from Hewlett-Packard Company, and 68xxx family microprocessors from Motorola Corporation.

The processor 606 in the processor-based client hosting the secret management transmission system and method 100 may be any logical processing unit, such as one or more Central Processing Units (CPUs), microprocessors, digital Signal Processors (DSPs), application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs), and the like. Unless otherwise noted, the construction and operation of the various blocks shown in FIG. 6 are of conventional design. Accordingly, these blocks need not be described in further detail herein, as they will be understood by those skilled in the relevant art.

The system bus 610 in the processor-based client hosting the secret management transmission system and method 100 may employ any known bus structure or architecture, including a memory bus with a memory controller, a peripheral bus, and a local bus. The system memory 608 includes read only memory ("ROM") 612 and random access memory ("RAM") 614. A basic input/output system ("BIOS") 616, which may form part of the ROM 612, contains the basic routines that help to transfer information between elements within the processor-based device, such as during start-up. Some embodiments may employ separate buses for data, instructions, and power.

The processor-based client hosting the secret management transmission system and method 100 may also include one or more solid-state memories; such as flash memory or Solid State Drives (SSDs) that provide non-volatile storage of computer readable instructions, data structures, program modules, and other data for the processor-based devices. Although not depicted, the processor-based device may employ other non-transitory computer or processor readable media, such as a hard disk drive, an optical disk drive, or a memory card media drive.

Program modules in the processor-based client hosting the secret management transmission system and method 100 may be stored in the system memory 608, such as an operating system 630, one or more application programs 632, other programs or modules 634, drivers 636, and program data 638.

The system memory 608 in the processor-based client hosting the secret management transmission system and method 100 may also include a communication program 640, e.g., a server and/or a web client or browser for allowing the processor-based device to access and exchange data with other systems, such as a user computing system, a website on the internet, a corporate intranet, or other networks as described below. The communication program 640 in the depicted embodiment is markup language based, such as hypertext markup language (HTML), extensible markup language (XML), or Wireless Markup Language (WML), and operates with markup languages that use characters separated in sentence composition that are added to the data of a file to represent the structure of the file. Many servers and/or web clients or browsers are commercially available, such as those from Mozilla corporation of California and Microsoft of Washington.

Although shown in fig. 6 as being stored in system memory 608, operating system 630, application programs 632, other programs/modules 634, drivers 636, program data 638, and the server and/or browser can be stored on any other of a variety of non-transitory processor-readable media (e.g., a hard disk drive, optical disk drive, SSD, and/or flash memory).

A user of a processor-based client hosting the secret management transmission system and method 100 may enter commands and information via a pointer, for example, through an input device such as a touch screen 648 via a finger 644a, a stylus 644b, or via a computer mouse or trackball 644c that controls a cursor. Other input devices may include a microphone, joystick, game pad, tablet, scanner, biometric scanner, or the like. These and other input devices (i.e., "I/O devices") are connected to the processor 606 through an interface 646, such as a touch screen controller and/or a universal serial bus ("USB") interface that couples user input to the system bus 610, although other interfaces, such as a parallel port, game port, or wireless interface or serial port, may be used. The touch screen 648 may be coupled to the system bus 610 via a video interface 650, such as a video adapter, to receive image data or image information for display via the touch screen 648. Although not shown, the processor-based client may include other output devices, such as speakers, vibrators, haptic actuators, or haptic engines, among others.

The processor-based client that hosts secret management transmission system and method 100 operates in a networked environment using one or more logical connections to communicate with one or more remote computers, servers, and/or devices via one or more communication channels, such as one or more networks 614a, 614 b. These logical connections may facilitate any known method of allowing computers to communicate, such as over one or more LANs and/or WANs, such as the Internet and/or a cellular communication network. Such networking environments are well known in wired and wireless enterprise-wide computer networks, intranets, extranets, internets and other types of communication networks. These other types of communication networks include telecommunications networks, cellular networks, paging networks, and other mobile networks.

When used in a networked environment, a processor-based client hosting the secret management transmission system and method 100 may include one or more network, wired or wireless communication interfaces 652a, 656 (e.g., network interface controllers, cellular radio, WIFI radio, bluetooth radio) to establish communications over a network, such as the internet 614a or cellular network 614 b.

In a networked environment, program modules, applications, or data, or portions thereof, may be stored in a server computing system (not shown). Those skilled in the relevant art will appreciate that the network connections shown in FIG. 6 are but a few examples of ways to establish communications between the computers, and that other connections, including wireless connections, may be used.

For convenience, the processor 606, the system memory 608, and the network and

communication interfaces

652a, 656 are shown communicatively coupled to each other via the system bus 610, providing connections between the above-described components. In alternative embodiments of the processor-based device, the above-described components may be communicatively coupled in a manner different than that shown in FIG. 6. For example, one or more of the components described above may be directly coupled to the other components, or may be coupled to each other via intermediate components (not shown). In some embodiments, the system bus 610 is omitted and the components are directly coupled to each other using suitable connections.

Throughout this specification and the appended claims, the term "communicative" when used in "communicative approach," "communicative coupling," and in variants such as "communicatively coupled" is used to generally refer to any engineering arrangement for transmitting and/or exchanging information. Example communication paths include, but are not limited to, electrically conductive paths (e.g., electrically conductive wires, electrically conductive traces), magnetic paths (e.g., magnetic media), one or more communication links via one or more wireless communication protocols, and/or optical paths (e.g., optical fibers), and example communication couplings include, but are not limited to, electrical couplings, magnetic couplings, wireless couplings, and/or optical couplings.

Indefinite verb forms are often used throughout this specification and the appended claims. Examples include, but are not limited to: "detect", "provide", "transmit", "communicate", "process", "route", etc. Unless the specific context requires otherwise, the indefinite verb form is used in an open, inclusive manner, i.e., like "detect at least", "provide at least", "transmit at least", etc.

The above description of illustrated embodiments, including what is described in the abstract, is not intended to be exhaustive or to limit the embodiments to the precise forms disclosed. While specific embodiments of, and examples for, the disclosure are described herein for illustrative purposes, various equivalent modifications can be made without departing from the spirit and scope of the disclosure, as will be recognized by those skilled in the relevant art.

For example, the foregoing detailed description has set forth various embodiments of the devices and/or processes via the use of block diagrams, schematics, and examples. Insofar as such block diagrams, schematics, and examples include one or more functions and/or operations, it will be understood by those within the art that each function and/or operation within such block diagrams, schematics, or examples can be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. In one embodiment, the present subject matter may be implemented via an Application Specific Integrated Circuit (ASIC). However, those skilled in the art will recognize that embodiments disclosed herein, in whole or in part, can be equivalently implemented in standard integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more controllers (e.g., microcontrollers) as one or more programs running on one or more processors (e.g., microprocessors, central processing units, graphics processing units), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and/or firmware would be well within the skill of one of ordinary skill in the art in view of the teachings of this disclosure.

When the logic is implemented as software and stored in memory, the logic or information may be stored on any processor-readable medium for use by or in connection with any processor-related system or method. In the context of this disclosure, a memory is a processor readable medium as an electronic, magnetic, optical, or other physical device or means that includes or stores a computer and/or processor program. Logic and/or information may be embodied in any processor-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions associated with logic and/or information.

In the context of this specification, a "non-transitory processor-readable medium" can be any means that can store the program associated with logic and/or information for use by or in connection with an instruction execution system, apparatus, and/or device. The processor-readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: portable computer diskette (magnetic, compact flash, secure digital, etc.), random Access Memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM, EEPROM, or flash memory), portable compact disc read-only memory (CDROM), digital tape, and other non-transitory media.

The various embodiments described above can be combined to provide further embodiments. To the extent that they are not inconsistent with the specific teachings and definitions herein, the entire contents of the U.S. patents, U.S. patent application publications, U.S. patent applications, foreign patents, foreign patent applications and non-patent publications referred to in this specification and/or listed in the application data sheet are incorporated herein by reference in their entirety. Aspects of the embodiments can be modified, if necessary, to employ systems, circuits and concepts of the various patents, applications and publications to provide yet further embodiments.

This application claims priority to U.S. non-provisional application serial No. 16/261,443, filed on 29/1/2019, which is incorporated herein by reference in its entirety.

These and other changes can be made to the embodiments in light of the above detailed description. In general, in the following claims, the terms used should not be construed to limit the claims to the specific embodiments disclosed in the specification and the claims, but should be construed to include all possible embodiments along with the full scope of equivalents to which such claims are entitled. Accordingly, the claims are not limited by the disclosure.

Claims

1. A escrow secret management transmission system for managing secrets at one or more offsite locations, the escrow secret management transmission system comprising:

a server comprising one or more processors and a memory device storing a set of instructions that, when executed by the one or more processors, cause the one or more processors to:

defining boundaries for two or more masters, the two or more masters being components of a functional grouping, each master having an independent master record, wherein each master comprises two or more regions;

defining a main region within the two or more regions;

accessing a master record hardware security module of a primary storage device that is a secret of the master authority within the primary region, wherein the master record hardware security module is a real record of all operations on a secret within a respective master authority of the master record hardware security module, the operations on the secret including one or more of a create operation, an update operation, and a delete operation;

defining one or more secondary areas that are not the primary area;

accessing a backup recording hardware security module within the one or more secondary areas, the backup recording hardware security module being a location to create the confidential data backup from the primary recording hardware security module;

performing a real-time copy from the primary record hardware security module to the backup record hardware security module, the backup record hardware security module supporting concurrent multi-tenant confidentiality management for a plurality of different companies;

accessing, in each of the two or more regions, a primary cache hardware security module that receives a live copy from the backup recording hardware security module;

accessing a hardware security module cache pool in each of the two or more regions, wherein the hardware security module cache pool is expandable to replicate values from the primary cache hardware security module according to traffic demands within a region;

accessing a cluster of software containers and a software container management system that ensures that the software containers are available and functioning properly in each of the two or more regions of ownership; and is

Receiving a request for a value at a software container, wherein the request for a value of the software container in a software container cluster of a region is load balanced among the primary cache hardware security module and the hardware security module cache pool for all read operations;

wherein when a non-existent value is requested, the hosted secret management transmission system looks up an original master of the value, and, if the original master of the value is different from the requested original master and is allowable, requests the value from the original master and then caches the value in the primary cache hardware security module of the region from which the request originated, wherein the value is then distributed to the hardware security module cache pool via real-time replication.

2. The system of claim 1, wherein the master rights are defined based on geopolitical boundaries, wherein the geopolitical boundaries include countries, state leagues, or groups of countries, wherein the master rights are defined in any organizational region and bind secrets to a single group, company, or enterprise, wherein the region is defined by a real world boundary of a country including a regional direction or within one of the master rights, wherein the region is based on a completely unique datacenter included in one or more of the same cloud provider, different cloud providers, local systems, and private clouds, and wherein the secondary region provides high availability if the entire primary region becomes unavailable.

3. The system of claim 1, wherein the primary record is where all write operations occurred.

4. The system of claim 1, wherein no read operations occur on the primary record other than an emergency.

5. The system of claim 1, wherein the backup recording hardware security module keeps the load on the primary recording hardware security module as low as possible to reduce or eliminate the possibility of a database lock occurring.

6. The system of claim 1, wherein the primary cache hardware security module serves as a primary replication source for all cached values in its respective region.

7. The system of claim 1, wherein the hosted secret management transmission system securely distributes replicated values among the masters to provide reduced request latency, and distributes the replicated values through the primary cache hardware security module and the hardware security module cache pool, while the primary record hardware security module of the respective master always includes an original value.

8. The system of claim 1, wherein each of the two or more regions comprises a database cluster, one of the database clusters designated as a primary database cluster, wherein data is stored in the primary database cluster and data is globally replicated from the primary database cluster to a distributed replica database.

9. The system of claim 8, wherein the data stored in the primary database cluster is metadata of the secrets managed in the hosted secret management transfer system, the metadata including one or more of: name, internal name, version number, original master and security policy to which protection values can be distributed.

10. The system of claim 8, wherein the data is stored as an event stream that causes metadata entities to be built, rather than storing the metadata as a single entity.

11. The system of claim 10, wherein the event stream provides a continuous audit log of all events that resulted in variant operations being taken.

12. The system of claim 11, wherein events in the continuous audit log are analyzed for anomalies and security issues using machine learning.

13. The system of claim 1, wherein a client is created by a user and bound to a key ring while restricting the client's access to values of a particular environment, which ensures that production and development values do not cross.

14. The system of claim 13, wherein the client is bound to the particular environment.

15. The system of claim 13, wherein the different types of specific environments include production, staging, testing, and development.

16. The system of claim 1, wherein each zone comprises a private subnet comprising all components in the zone, wherein all other software container management systems in one of the zones are located in the private subnet within the respective available partition, which eliminates any possibility of direct contact via an external connection to the internet.

17. The system of claim 1, wherein all communications between regions and communications between masters are handled by encrypted connections.

18. A escrow secret management transmission method for managing secrets at one or more offsite locations, the method comprising:

defining a main region within the two or more regions;

defining one or more secondary areas that are not the primary area;

performing a real-time copy from the primary record hardware security module to the backup record hardware security module, the backup record hardware security module supporting simultaneous multi-tenant confidentiality management for a plurality of different companies;

Receiving a request for a value at a software container, wherein the request for a value of the software container in a software container cluster of a region is load balanced among a primary cache hardware security module and the hardware security module cache pool for all read operations;

wherein when a non-existent value is requested, a managed secret management transmission system looks up an original master of the value, and if the original master of the value is different from the requested original master and is allowable, requests the value from the original master and then caches the value in the primary cache hardware security module of the region from which the request originated, wherein the value is then distributed to the hardware security module cache pool via real-time replication.

19. The method of claim 18, wherein the master rights are defined based on geopolitical boundaries, wherein the geopolitical boundaries include countries, state leagues, or groups of countries, wherein the master rights are defined in any organizational region and bind secrets to a single group, company, or business, wherein the region is defined by real world boundaries of countries including directions to a region or within one of the master rights, wherein the region is based on a completely unique datacenter included in one or more of the same cloud provider, different cloud providers, local systems, and private clouds, wherein the secondary region provides high availability if the entire primary region becomes unavailable.

20. The method of claim 18, wherein the primary record is where all write operations occurred.

21. The method of claim 18, wherein no read operation occurs on the primary record other than in an emergency.

22. The method of claim 18, wherein the backup recording hardware security module keeps the load on the primary recording hardware security module as low as possible to reduce or eliminate the possibility of a database lock occurring.

23. The method of claim 18, wherein the primary cache hardware security module serves as a primary copy source of all cached values in its respective region.

24. The method of claim 18, wherein the managed secret management transmission system securely distributes replicated values among the masters to provide reduced request latency, and distributes the replicated values through the primary cache hardware security module and the hardware security module cache pool, while the primary record hardware security module of the respective master always includes an original value.

25. The method of claim 18, wherein a zone is designated with a primary database cluster, wherein data is stored in the primary database cluster, and data is globally replicated from the primary database cluster to a distributed replica database located at each zone.

26. The method of claim 25, wherein the data stored in the primary database cluster is metadata of the secret managed in the hosted secret management transmission system, the metadata including one or more of: name, internal name, version number, original master and security policy to which protection values can be distributed.

27. The method of claim 25, wherein the data is stored as an event stream that causes metadata entities to be constructed, rather than storing the metadata as a single entity.

28. The method of claim 27, wherein the event stream provides a continuous audit log of all events that resulted in variant operations being taken.

29. The method of claim 28, wherein events in the continuous audit log are analyzed for anomalies and security issues using machine learning.

30. The method of claim 18, wherein a client is created by a user and bound to a key ring while restricting the client's access to values of a particular environment, which ensures that production and development values do not cross.

31. The method of claim 30, wherein the client is bound to the particular environment.

32. The method of claim 30, wherein the different types of specific environments include production, staging, testing, and development.

33. The method of claim 18, wherein each zone comprises a private subnet that includes all components in the zone, wherein all other software container management systems in one of the zones are located in the private subnet within the respective available partition, which eliminates any possibility of direct contact via an external connection to the internet.

34. The method of claim 23, wherein all communications between regions and communications between masters are handled by encrypted connections.

35. A escrow secret management transmission system for managing secrets at one or more offsite locations, the escrow secret management transmission system comprising:

two or more masters, the two or more masters being components of a functional grouping, each master having an independent master record, wherein each master comprises two or more regions, the two or more regions further comprising at least a primary region and a secondary region;

a master record hardware security module included in the primary region, the master record hardware security module being a primary storage of a secret of the master authority, wherein the master record hardware security module is a real record of all operations on the secret within the respective master authority of the master record hardware security module, the operations on the secret including one or more of a create operation, an update operation, and a delete operation;

a backup recording hardware security module included in one or more secondary areas that are not primary areas, the backup recording hardware security module receiving a live copy from the primary recording hardware security module that simultaneously supports multi-tenant confidentiality management for a plurality of different companies, wherein the backup recording hardware security module is a location from which a data backup is created from the primary recording hardware security module;

a primary cache hardware security module contained in each of the two or more regions, the primary cache hardware security module receiving a live copy from the backup recording hardware security module;

a hardware security module cache pool included in each of the two or more regions, wherein each hardware security module cache pool is expandable to replicate values from a respective primary cache hardware security module of each hardware security module cache pool according to traffic demands within a region; and

a software container cluster and software container management system included in each of the two or more zones, wherein the software container management system ensures that software containers are available and functioning properly, wherein requests for software containers in a zone's software container cluster are load balanced for all read operations among the primary cache hardware security module and the hardware security module cache pool;

wherein when requesting a value that is not present, the hosted secret management transmission system identifies an original master of the value, and, if the original master of the value is different from the original master of the request and is allowable, requests the value from the original master and then caches the value in the primary cache hardware security module of the region from which the request originated, wherein the value is then distributed to the hardware security module cache pool via real-time replication.