Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

AWS KMS Porte-clés hiérarchiques

Grâce au trousseau de clés AWS KMS hiérarchique, vous pouvez protéger vos documents cryptographiques à l'aide d'une clé KMS à chiffrement symétrique sans avoir à appeler AWS KMS chaque fois que vous chiffrez ou déchiffrez un enregistrement. C'est un bon choix pour les applications qui ont besoin de minimiser les appels et pour AWS KMS les applications qui peuvent réutiliser certains éléments cryptographiques sans enfreindre leurs exigences de sécurité.

Le trousseau de clés hiérarchique est une solution de mise en cache des matériaux cryptographiques qui réduit le nombre d' AWS KMS appels en utilisant des clés de branche AWS KMS protégées conservées dans une table Amazon DynamoDB, puis en mettant en cache localement les matériaux des clés de branche utilisés dans les opérations de chiffrement et de déchiffrement. La table DynamoDB fait office de magasin de clés qui gère et protège les clés de branche. Il stocke la clé de branche active et toutes les versions précédentes de la clé de branche. La clé de branche active est la version de clé de branche la plus récente. Le trousseau de clés hiérarchique utilise une clé de chiffrement des données unique pour chaque demande de chiffrement et chiffre chaque clé de chiffrement des données avec une clé d'encapsulation unique dérivée de la clé de branche active. Le trousseau de clés hiérarchique dépend de la hiérarchie établie entre les clés de branche actives et leurs clés d'encapsulation dérivées.

Le trousseau de clés hiérarchique utilise généralement chaque version de clé de branche pour répondre à plusieurs demandes. Mais vous pouvez contrôler la mesure dans laquelle les clés de branche actives sont réutilisées et vous déterminez la fréquence de rotation de la clé de branche active. La version active de la clé de branche reste active tant que vous ne la faites pas pivoter. Les versions précédentes de la clé de branche active ne seront pas utilisées pour effectuer des opérations de chiffrement, mais elles peuvent toujours être interrogées et utilisées pour les opérations de déchiffrement.

Lorsque vous instanciez le trousseau de clés hiérarchique, il crée un cache local. Vous spécifiez une limite de cache qui définit la durée maximale pendant laquelle les éléments des clés de branche sont stockés dans le cache local avant d'expirer et d'en être expulsés. Le trousseau de clés hiérarchique effectue un AWS KMS appel pour déchiffrer la clé de branche et assembler les éléments de la clé de branche la première fois que a branch-key-id est spécifié dans une opération. Les éléments des clés de branche sont ensuite stockés dans le cache local et réutilisés pour toutes les opérations de chiffrement et de déchiffrement qui le spécifient branch-key-id jusqu'à l'expiration de la limite de cache. Le stockage des informations relatives aux clés de branche dans le cache local réduit le nombre d' AWS KMS appels. Par exemple, considérez une limite de cache de 15 minutes. Si vous effectuez 10 000 opérations de chiffrement dans cette limite de cache, le trousseau de AWS KMS clés traditionnel devra effectuer 10 000 AWS KMS appels pour effectuer 10 000 opérations de chiffrement. Si vous en avez un actifbranch-key-id, le trousseau de clés hiérarchique n'a besoin que d'un seul AWS KMS appel pour effectuer 10 000 opérations de chiffrement.

Le cache local sépare le matériel de chiffrement du matériel de déchiffrement. Les matériaux de chiffrement sont assemblés à partir de la clé de branche active et réutilisés pour toutes les opérations de chiffrement jusqu'à l'expiration de la limite de cache. Les matériaux de déchiffrement sont assemblés à partir de l'ID de clé de branche et de la version identifiés dans les métadonnées du champ chiffré, et ils sont réutilisés pour toutes les opérations de déchiffrement liées à l'ID et à la version de la clé de branche jusqu'à expiration de la limite de cache. Le cache local peut stocker plusieurs versions de la même clé de branche à la fois. Lorsque le cache local est configuré pour utiliser unbranch key ID supplier, il peut également stocker des éléments de clé de branche provenant de plusieurs clés de branche actives à la fois.

Comment ça marche

Les procédures pas à pas suivantes décrivent comment le trousseau de clés hiérarchique assemble le matériel de chiffrement et de déchiffrement, ainsi que les différents appels qu'il effectue pour les opérations de chiffrement et de déchiffrement. Pour plus de détails techniques sur les processus de dérivation des clés d'encapsulation et de chiffrement des clés de données en texte brut, voir Détails techniques des trousses de clés AWS KMS hiérarchiques.

Chiffrez et signez

La procédure pas à pas suivante décrit comment le trousseau de clés hiérarchique assemble les matériaux de chiffrement et en déduit une clé d'encapsulation unique.

Décrypter et vérifier

La procédure pas à pas suivante décrit comment le trousseau de clés hiérarchique assemble le matériel de déchiffrement et déchiffre la clé de données chiffrée.

Conditions préalables

Avant de créer et d'utiliser un trousseau de clés hiérarchique, assurez-vous que les conditions préalables suivantes sont remplies.

Autorisations requises

Le SDK AWS de chiffrement de base de données n'en nécessite pas Compte AWS et n'en dépend pas Service AWS. Toutefois, pour utiliser un trousseau de clés hiérarchique, vous devez disposer Compte AWS des autorisations minimales suivantes sur le ou les AWS KMS key chiffrements symétriques de votre magasin de clés.

Pour plus d'informations sur le contrôle de l'accès aux clés de votre agence et à votre magasin de clés, consultezImplémentation des autorisations avec le moindre privilégié.

Choisissez un cache

Le trousseau de clés hiérarchique réduit le nombre d'appels en AWS KMS mettant en cache localement les éléments clés de branche utilisés dans les opérations de chiffrement et de déchiffrement. Avant de créer votre trousseau de clés hiérarchique, vous devez décider du type de cache que vous souhaitez utiliser. Vous pouvez utiliser le cache par défaut ou le personnaliser en fonction de vos besoins.

Le trousseau de clés hiérarchique prend en charge les types de cache suivants :

Cache par défaut

Pour la plupart des utilisateurs, le cache par défaut répond à leurs exigences en matière de thread. Le cache par défaut est conçu pour prendre en charge les environnements fortement multithread. Lorsqu'une entrée de matériel clé de branche expire, le cache par défaut empêche l'appel de plusieurs threads AWS KMS en notifiant à un thread que l'entrée de matériaux de clé de branche va expirer 10 secondes à l'avance. Cela garantit qu'un seul thread envoie une demande AWS KMS d'actualisation du cache.

Le cache par défaut et le StormTracking cache prennent en charge le même modèle de threading, mais il vous suffit de spécifier la capacité d'entrée pour utiliser le cache par défaut. Pour des personnalisations plus précises du cache, utilisez le. StormTracking cache

À moins que vous ne souhaitiez personnaliser le nombre d'entrées de matériel de clé de branche pouvant être stockées dans le cache local, vous n'avez pas besoin de spécifier de type de cache lorsque vous créez le trousseau de clés hiérarchique. Si vous ne spécifiez aucun type de cache, le trousseau de clés hiérarchique utilise le type de cache par défaut et définit la capacité d'entrée sur 1 000.

Pour personnaliser le cache par défaut, spécifiez les valeurs suivantes :

Java

.cache(CacheType.builder()
        .Default(DefaultCache.builder()
        .entryCapacity(100)
        .build())

C# / .NET

CacheType defaultCache = new CacheType
{
    Default = new DefaultCache{EntryCapacity = 100}
};

Rust

let cache: CacheType = CacheType::Default(
    DefaultCache::builder()
        .entry_capacity(100)
        .build()?,
);

MultiThreaded cache

Le MultiThreaded cache peut être utilisé en toute sécurité dans les environnements multithread, mais il ne fournit aucune fonctionnalité permettant de minimiser les appels AWS KMS Amazon DynamoDB. Par conséquent, lorsqu'une entrée de matériel clé de branche expire, tous les fils de discussion sont notifiés en même temps. Cela peut entraîner plusieurs AWS KMS appels pour actualiser le cache.

Pour utiliser le MultiThreaded cache, spécifiez les valeurs suivantes :

Java

.cache(CacheType.builder()
        .MultiThreaded(MultiThreadedCache.builder()
        .entryCapacity(100)
        .entryPruningTailSize(1)                                        
        .build())

C# / .NET

CacheType multithreadedCache = new CacheType
{
    MultiThreaded = new MultiThreadedCache
    {
        EntryCapacity = 100,
        EntryPruningTailSize = 1
    }
};

Rust

CacheType::MultiThreaded(
            MultiThreadedCache::builder()
                    .entry_capacity(100)
                    .entry_pruning_tail_size(1)
                    .build()?)

StormTracking cache

Le StormTracking cache est conçu pour prendre en charge les environnements fortement multithread. Lorsqu'une entrée de matériel de clé de branche expire, le StormTracking cache empêche l'appel de plusieurs threads AWS KMS en notifiant à un thread que l'entrée de matériaux de clé de branche va expirer à l'avance. Cela garantit qu'un seul thread envoie une demande AWS KMS d'actualisation du cache.

Pour utiliser le StormTracking cache, spécifiez les valeurs suivantes :

Java

.cache(CacheType.builder()
        .StormTracking(StormTrackingCache.builder()
        .entryCapacity(100)
        .entryPruningTailSize(1)
        .gracePeriod(10)
        .graceInterval(1)
        .fanOut(20) 
        .inFlightTTL(10)
        .sleepMilli(20)                                        
        .build())

C# / .NET

CacheType stormTrackingCache = new CacheType
{
    StormTracking = new StormTrackingCache
    {
        EntryCapacity = 100,
        EntryPruningTailSize = 1,
        FanOut = 20,
        GraceInterval = 1,
        GracePeriod = 10,
        InFlightTTL = 10,
        SleepMilli = 20
    }
};

Rust

CacheType::StormTracking(
                StormTrackingCache::builder()
                    .entry_capacity(100)
                    .entry_pruning_tail_size(1)
                    .grace_period(10)
                    .grace_interval(1)
                    .fan_out(20)
                    .in_flight_ttl(10)
                    .sleep_milli(20)
                    .build()?)

Cache partagé

Par défaut, le trousseau de clés hiérarchique crée un nouveau cache local chaque fois que vous instanciez le jeu de clés. Cependant, le cache partagé peut contribuer à économiser de la mémoire en vous permettant de partager un cache entre plusieurs porte-clés hiérarchiques. Plutôt que de créer un nouveau cache de matériel cryptographique pour chaque jeu de clés hiérarchique que vous instanciez, le cache partagé ne stocke qu'un seul cache en mémoire, qui peut être utilisé par tous les ensembles de clés hiérarchiques qui le référencent. Le cache partagé permet d'optimiser l'utilisation de la mémoire en évitant la duplication de documents cryptographiques entre les trousseaux de clés. Au lieu de cela, les trousseaux de clés hiérarchiques peuvent accéder au même cache sous-jacent, réduisant ainsi l'empreinte mémoire globale.

Lorsque vous créez votre cache partagé, vous définissez toujours le type de cache. Vous pouvez spécifier un Cache par défautMultiThreaded cache, ou StormTracking cache comme type de cache, ou le remplacer par un cache personnalisé compatible.

Partitions

Plusieurs porte-clés hiérarchiques peuvent utiliser un seul cache partagé. Lorsque vous créez un trousseau de clés hiérarchique avec un cache partagé, vous pouvez définir un ID de partition facultatif. L'ID de partition permet de distinguer le trousseau de clés hiérarchique qui écrit dans le cache. Si deux porte-clés hiérarchiques font référence au même ID de partition et au même ID de clé de branchelogical key store name, les deux porte-clés partageront les mêmes entrées de cache dans le cache. Si vous créez deux trousseaux de clés hiérarchiques avec le même cache partagé, mais des ID de partition différents, chaque jeu de clés n'accédera aux entrées du cache qu'à partir de sa propre partition désignée dans le cache partagé. Les partitions agissent comme des divisions logiques au sein du cache partagé, permettant à chaque jeu de clés hiérarchique de fonctionner indépendamment sur sa propre partition désignée, sans interférer avec les données stockées dans l'autre partition.

Si vous avez l'intention de réutiliser ou de partager les entrées du cache d'une partition, vous devez définir votre propre identifiant de partition. Lorsque vous transmettez l'ID de partition à votre trousseau de clés hiérarchique, celui-ci peut réutiliser les entrées de cache déjà présentes dans le cache partagé, au lieu de devoir récupérer et réautoriser les éléments clés de branche. Si vous ne spécifiez pas d'identifiant de partition, un identifiant de partition unique est automatiquement attribué au trousseau de clés chaque fois que vous instanciez le jeu de clés hiérarchique.

Création d'un porte-clés hiérarchique

Pour créer un porte-clés hiérarchique, vous devez fournir les valeurs suivantes :

Les exemples suivants montrent comment configurer un magasin de clés avec une configuration statique. Choisissez votre langue préférée :

Java

import software.amazon.awssdk.services.dynamodb.DynamoDbClient;
import software.amazon.awssdk.services.kms.KmsClient;
import software.amazon.cryptography.keystore.KeyStore;
import software.amazon.cryptography.keystore.model.KeyStoreConfig;
import software.amazon.cryptography.keystore.model.KMSConfiguration;

final KeyStore keystore = KeyStore.builder()
        .KeyStoreConfig(KeyStoreConfig.builder()
                .ddbClient(DynamoDbClient.create())
                .ddbTableName(keyStoreName)
                .logicalKeyStoreName(logicalKeyStoreName)
                .kmsClient(KmsClient.create())
                .kmsConfiguration(KMSConfiguration.builder()
                        .kmsKeyArn(kmsKeyArn)
                        .build())
                .build())
        .build();

C# / .NET

using Amazon.DynamoDBv2;
using Amazon.KeyManagementService;
using AWS.Cryptography.KeyStore;

var kmsConfig = new KMSConfiguration { KmsKeyArn = kmsKeyArn };
var keystoreConfig = new KeyStoreConfig
{
    KmsClient = new AmazonKeyManagementServiceClient(),
    KmsConfiguration = kmsConfig,
    DdbTableName = keyStoreName,
    DdbClient = new AmazonDynamoDBClient(),
    LogicalKeyStoreName = logicalKeyStoreName
};
var keystore = new KeyStore(keystoreConfig);

Rust

use aws_db_esdk::key_store::client as keystore_client;
use aws_db_esdk::key_store::types::key_store_config::KeyStoreConfig;
use aws_db_esdk::key_store::types::KmsConfiguration;

let sdk_config = aws_config::load_defaults(aws_config::BehaviorVersion::latest()).await;
let key_store_config = KeyStoreConfig::builder()
    .kms_client(aws_sdk_kms::Client::new(&sdk_config))
    .ddb_client(aws_sdk_dynamodb::Client::new(&sdk_config))
    .ddb_table_name(key_store_name)
    .logical_key_store_name(logical_key_store_name)
    .kms_configuration(KmsConfiguration::KmsKeyArn(kms_key_arn.to_string()))
    .build()?;

let keystore = keystore_client::Client::from_conf(key_store_config)?;

Après avoir configuré votre magasin de clés, utilisez l'objet de stockage de clés qui en résulte pour créer votre porte-clés hiérarchique. Les exemples de porte-clés hiérarchiques qui suivent utilisent l'objet de stockage de clés que vous avez configuré.

Utilisation du trousseau de clés hiérarchique pour le chiffrement consultable

Le chiffrement consultable vous permet de rechercher des enregistrements chiffrés sans déchiffrer l'intégralité de la base de données. Cela se fait en indexant la valeur en texte brut d'un champ chiffré à l'aide d'une balise. Pour implémenter le chiffrement consultable, vous devez utiliser un trousseau de clés hiérarchique.

L'CreateKeyopération de stockage de clés génère à la fois une clé de branche et une clé de balise. La clé de branche est utilisée dans les opérations de chiffrement et de déchiffrement des enregistrements. La clé de balise est utilisée pour générer des balises.

La clé de branche et la clé de balise sont protégées par les mêmes AWS KMS key que celles que vous avez spécifiées lors de la création de votre service de stockage de clés. Une fois que l'CreateKeyopération a appelé AWS KMS pour générer la clé de branche, elle appelle kms : GenerateDataKeyWithoutPlaintext une deuxième fois pour générer la clé de balise à l'aide de la requête suivante.

{
   "EncryptionContext": { 
      "branch-key-id" : "branch-key-id",
      "type" : type,
      "create-time" : "timestamp",
      "tablename" : "the logical table name for your key store",
      "kms-arn" : the KMS key ARN,
      "hierarchy-version" : 1
   },
   "KeyId": "the KMS key ARN",
   "NumberOfBytes": "32"
}

Après avoir généré les deux clés, l'CreateKeyopération appelle ddb : TransactWriteItems pour écrire deux nouveaux éléments qui conserveront la clé de branche et la clé de balise dans votre magasin de clés de branche.

Lorsque vous configurez une balise standard, le SDK AWS Database Encryption interroge le magasin de clés pour la clé de balise. Ensuite, il utilise une fonction de dérivation de clé HMAC-based d'extraction et d'expansion (HKDF) pour combiner la clé de balise avec le nom de la balise standard afin de créer la clé HMAC pour une balise donnée.

Contrairement aux clés de branche, il n'existe qu'une seule version de clé branch-key-id de balise par magasin de clés. La touche de la balise n'est jamais pivotée.

Définition de la source de clé de votre balise

Lorsque vous définissez la version de balise pour vos balises standard et composées, vous devez identifier la clé de balise et définir une limite de durée de vie (TTL) du cache pour les matériaux des clés de balise. Les éléments clés des balises sont stockés dans un cache local distinct de celui des clés de branche. L'extrait suivant montre comment définir le pour une base de données keySource à locataire unique. Identifiez la clé de votre balise par celle à laquelle branch-key-id elle est associée.

Java

keySource(BeaconKeySource.builder()
        .single(SingleKeyStore.builder()
                .keyId(branch-key-id)
                .cacheTTL(6000)
                .build())
        .build())

C# / .NET

KeySource = new BeaconKeySource
{
    Single = new SingleKeyStore
    {
       KeyId = branch-key-id,
       CacheTTL = 6000
    }
}

Rust

 .key_source(BeaconKeySource::Single(
    SingleKeyStore::builder()
        // `keyId` references a beacon key.
        // For every branch key we create in the keystore,
        // we also create a beacon key.
        // This beacon key is not the same as the branch key,
        // but is created with the same ID as the branch key.
        .key_id(branch_key_id)
        .cache_ttl(6000)
        .build()?,
))