Abstract: A hardware security module (HSM) client processes a request to store data in a set of HSMs. The HSM client determines a property of the data indicative of a sensitivity classification of the data. As a result of determining the data lacks a classification as sensitive, the HSM client transmits the data to a data store outside the set of HSMs and updates a database used by the HSM client to associate an identifier of the data with a reference to a location in the data store.

Abstract: Fault-tolerant storage of cryptographic information maintained on a fleet of HSMs may be provided by dividing the cryptographic information into a number of stripes which are distributed and stored on individual HSMs in the HSM fleet. Parity information is generated which allows one or more stripes to be regenerated if one or more stripes becomes corrupt or is lost. The parity information may be stored on an HSM in the HSM fleet, or outside the fleet on a storage service, HSM management hub, tangible computer-readable media, or other device. If an HSM in the HSM fleet fails, resulting in the loss of a stripe, an HSM in the fleet can recover the missing stripe by re-creating the missing stripe from the remaining stripes combined with the parity information. In some examples, stripes are mirrored within the fleet of HSMs.

Abstract: The present disclosure relates to two-factor authentication with a Hardware Security Module (HSM). In response to a login attempt, the HSM indicates that two-factor authentication is required. To generate the second authentication factor, a management console is accessed using credentials. The management console generates the second authentication factor and provides the second authentication factor to the client. The client then provides the second authentication factor to the HSM to complete the two-factor authentication operations.

Abstract: The present disclosure relates to two-factor authentication with a Hardware Security Module (HSM). In response to a login attempt, the HSM indicates that two-factor authentication is required. To generate the second authentication factor, a management console is accessed using credentials. The management console generates the second authentication factor and provides the second authentication factor to the client. The client then provides the second authentication factor to the HSM to complete the two-factor authentication operations.

Abstract: An HSM cluster includes a set of hardware security modules that maintain a set of cryptographic keys that are synchronized across the HSM cluster. Individual applications running on client computer systems access the HSM cluster using HSM cluster clients running on the client computer systems. The HSMs are accessed via a set of HSM cluster servers that monitor the synchronization of the cryptographic keys. Synchronization of the HSMs is maintained by the HSM cluster clients. The HSM cluster clients replicate key-addition and key-deletion operations across the HSM cluster. When a new key is created by a particular HSM, a prefix associated with the particular HSM is added to the identifier associated with the new key to avoid key-namespace collisions. If the set of cryptographic keys becomes unsynchronized across the HSM cluster, applications may continue read-only cryptographic operations while the HSM cluster is resynchronized by the HSM cluster clients.

Abstract: A set of cryptographic keys are synchronized across a set of HSMs that are configured in an HSM cluster. The set of cryptographic keys is maintained in a synchronized state by HSM cluster clients running on client computer systems with corresponding client applications. If the HSM cluster becomes unsynchronized, an HSM cluster client attempts to lock the HSM cluster and reestablish synchronization of the cryptographic keys across the HSM cluster. HSMs within the HSM cluster are able to establish an encrypted communication channel to other HSMs without revealing the contents of their communications to their respective host computer systems. Individual HSMs in the HSM cluster may include features that assist the HSM cluster client in determining whether each HSM is up-to-date, identifying particular keys that are not up-to-date, and copying keys from one HSM to another HSM within the HSM cluster.

Abstract: Fault-tolerant storage of cryptographic information maintained on a fleet of HSMs may be provided by dividing the cryptographic information into a number of stripes which are distributed and stored on individual HSMs in the HSM fleet. Parity information is generated which allows one or more stripes to be regenerated if one or more stripes becomes corrupt or is lost. The parity information may be stored on an HSM in the HSM fleet, or outside the fleet on a storage service, HSM management hub, tangible computer-readable media, or other device. If an HSM in the HSM fleet fails, resulting in the loss of a stripe, an HSM in the fleet can recover the missing stripe by re-creating the missing stripe from the remaining stripes combined with the parity information. In some examples, stripes are mirrored within the fleet of HSMs.

Abstract: Fault-tolerant storage of cryptographic information maintained on a fleet of HSMs may be provided by dividing the cryptographic information into a number of stripes which are distributed and stored on individual HSMs in the HSM fleet. Parity information is generated which allows one or more stripes to be regenerated if one or more stripes becomes corrupt or is lost. The parity information may be stored on an HSM in the HSM fleet, or outside the fleet on a storage service, HSM management hub, tangible computer-readable media, or other device. If an HSM in the HSM fleet fails, resulting in the loss of a stripe, an HSM in the fleet can recover the missing stripe by re-creating the missing stripe from the remaining stripes combined with the parity information. In some examples, stripes are mirrored within the fleet of HSMs.

Abstract: An HSM cluster includes a set of hardware security modules that maintain a set of cryptographic keys that are synchronized across the HSM cluster. Individual applications running on client computer systems access the HSM cluster using HSM duster clients running on the client computer systems. The HSMs are accessed via a set of HSM cluster servers that monitor the synchronization of the cryptographic keys. Synchronization of the HSMs is maintained by the HSM cluster clients. If the HSM cluster loses synchronization, an HSM cluster client resynchronizes the HSM cluster by acquiring a list of keys and key versions stored on each HSM, and generating an update map. Using the update map, the HSM client obtains, form various HSM in the HSM cluster, the latest versions of the out-of-date keys in an encrypted form. The HSM cluster client assembles and distributes updates to each HSM in the HSM cluster.

Abstract: Techniques for intelligent use of multiple virtualized resources via deep-inspection weighted round robin are described. Hardware resources shared between multiple clients can be intelligently selected between by the clients to perform operations. Weights of operation queues for the hardware resources that are assigned to instances can be provided to the clients to give the clients insight into how busy particular hardware resources are and what types of operations the hardware resources will be performing. In some embodiments, the clients can make use of a weighted round robin scheme to select between candidate hardware resources, allowing clients to effectively distribute operations between different hardware resources.

Abstract: An HSM management hub coordinates the distribution and synchronization of cryptographic material across a fleet of connected hardware security modules (“HSMs”). Cryptographic material is exchanged between HSMs in the fleet in a cryptographically protected format. In some examples, the cryptographic material is encrypted using a common fleet key maintained by the HSMs in the fleet. In other examples, the cryptographic material is protected using asymmetric cryptographic keys that are associated with the members of the HSM fleet. The HSM management hub may be used to divide the HSM fleet into subdomains by providing domain keys to subsets of HSMs within the HSM fleet. Cryptographic information that is encrypted with particular domain keys can be distributed across the entire HSM fleet, and restricted to use by authorized HSMs that are in possession of the particular domain keys.

Abstract: An HSM cluster includes a set of hardware security modules that maintain a set of cryptographic keys that are synchronized across the HSM cluster. Individual applications running on client computer systems access the HSM cluster using HSM cluster clients running on the client computer systems. The HSMs are accessed via a set of HSM cluster servers that monitor the synchronization of the cryptographic keys. Synchronization of the HSMs is maintained by the HSM cluster clients. The HSM cluster clients replicate key-addition and key-deletion operations across the HSM cluster. When a new key is created by a particular HSM, a prefix associated with the particular HSM is added to the identifier associated with the new key to avoid key-namespace collisions. If the set of cryptographic keys becomes unsynchronized across the HSM cluster, applications may continue read-only cryptographic operations while the HSM cluster is resynchronized by the HSM cluster clients.

Abstract: A resource generates and provides discovery configuration information to a network appliance. The network appliance validates the discovery configuration information, such as by validating a token within the discovery configuration information, then is configured using at least the discovery configuration information and passes at least a portion of the discovery configuration information to a network disjoint from that which connects the resource and the network appliance. This portion of discovery configuration information may include service advertisement information, routing information for traversing the network topology, and in some embodiments, the validation token.

Abstract: A set of cryptographic keys are synchronized across a set of HSMs that are configured in an HSM cluster. The set of cryptographic keys is maintained in a synchronized state by HSM cluster clients running on client computer systems with corresponding client applications. If the HSM cluster becomes unsynchronized, an HSM cluster client attempts to lock the HSM cluster and reestablish synchronization of the cryptographic keys across the HSM cluster. HSMs within the HSM cluster are able to establish an encrypted communication channel to other HSMs without revealing the contents of their communications to their respective host computer systems. Individual HSMs in the HSM cluster may include features that assist the HSM cluster client in determining whether each HSM is up-to-date, identifying particular keys that are not up-to-date, and copying keys from one HSM to another HSM within the HSM cluster.

Abstract: An HSM cluster includes a set of hardware security modules that maintain a set of cryptographic keys that are synchronized across the HSM cluster. Individual applications running on client computer systems access the HSM cluster using HSM cluster clients running on the client computer systems. The HSMs are accessed via a set of HSM cluster servers that monitor the synchronization of the cryptographic keys. Synchronization of the HSMs is maintained by the HSM cluster clients. The HSM cluster clients replicate key-addition and key-deletion operations across the HSM cluster. When a new key is created by a particular HSM, a prefix associated with the particular HSM is added to the identifier associated with the new key to avoid key-namespace collisions. If the set of cryptographic keys becomes unsynchronized across the HSM cluster, applications may continue read-only cryptographic operations while the HSM cluster is resynchronized by the HSM cluster clients.

Abstract: An HSM cluster includes a set of hardware security modules that maintain a set of cryptographic keys that are synchronized across the HSM cluster. Individual applications running on client computer systems access the HSM cluster using HSM duster clients running on the client computer systems. The HSMs are accessed via a set of HSM cluster servers that monitor the synchronization of the cryptographic keys. Synchronization of the HSMs is maintained by the HSM cluster clients. If the HSM cluster loses synchronization, an HSM cluster client resynchronizes the HSM cluster by acquiring a list of keys and key versions stored on each HSM, and generating an update map. Using the update map, the HSM client obtains, form various HSM in the HSM cluster, the latest versions of the out-of-date keys in an encrypted form. The HSM cluster client assembles and distributes updates to each HSM in the HSM cluster.

Abstract: A set of cryptographic keys are synchronized across a set of HSMs that are configured in an HSM cluster. The set of cryptographic keys is maintained in a synchronized state by HSM cluster clients running on client computer systems with corresponding client applications. If the HSM cluster becomes unsynchronized, an HSM cluster client attempts to lock the HSM cluster and reestablish synchronization of the cryptographic keys across the HSM cluster. HSMs within the HSM cluster are able to establish an encrypted communication channel to other HSMs without revealing the contents of their communications to their respective host computer systems. Individual HSMs in the HSM cluster may include features that assist the HSM cluster client in determining whether each HSM is up-to-date, identifying particular keys that are not up-to-date, and copying keys from one HSM to another HSM within the HSM cluster.

Abstract: An HSM cluster includes a set of hardware security modules that maintain a set of cryptographic keys that are synchronized across the HSM cluster. Individual applications running on client computer systems access the HSM cluster using HSM cluster clients running on the client computer systems. The HSMs are accessed via a set of HSM cluster servers that monitor the synchronization of the cryptographic keys. Synchronization of the HSMs is maintained by the HSM cluster clients. If the HSM cluster loses synchronization, an HSM cluster client resynchronizes the HSM cluster by acquiring a list of keys and key versions stored on each HSM, and generating an update map. Using the update map, the HSM client obtains, form various HSM in the HSM cluster, the latest versions of the out-of-date keys in an encrypted form. The HSM cluster client assembles and distributes updates to each HSM in the HSM cluster.

Abstract: An HSM management hub coordinates the distribution and synchronization of cryptographic material across a fleet of connected hardware security modules (“HSMs”). Cryptographic material is exchanged between HSMs in the fleet in a cryptographically protected format. In some examples, the cryptographic material is encrypted using a common fleet key maintained by the HSMs in the fleet. In other examples, the cryptographic material is protected using asymmetric cryptographic keys that are associated with the members of the HSM fleet. The HSM management hub may be used to divide the HSM fleet into subdomains by providing domain keys to subsets of HSMs within the HSM fleet. Cryptographic information that is encrypted with particular domain keys can be distributed across the entire HSM fleet, and restricted to use by authorized HSMs that are in possession of the particular domain keys.

Abstract: An HSM management hub coordinates the distribution and synchronization of cryptographic material across a fleet of connected hardware security modules (“HSMs”). Cryptographic material is exchanged between HSMs in the fleet in a cryptographically protected format. In some examples, the cryptographic material is encrypted using a common fleet key maintained by the HSMs in the fleet. In other examples, the cryptographic material is protected using asymmetric cryptographic keys that are associated with the members of the HSM fleet. The HSM management hub may be used to divide the HSM fleet into subdomains by providing domain keys to subsets of HSMs within the HSM fleet. Cryptographic information that is encrypted with particular domain keys can be distributed across the entire HSM fleet, and restricted to use by authorized HSMs that are in possession of the particular domain keys.