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 des données. 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 données unique pour chiffrer chaque message et chiffre chaque clé de chiffrement des données 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.

Compatibilité des langages de programmation

Le trousseau de clés hiérarchique est pris en charge par les langages de programmation et les versions suivants :

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

AWS Encryption SDK Cela ne nécessite pas de Compte AWS et ne dépend d'aucun 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.

Autorisations Amazon DynamoDB requises sur le tableau du magasin de clés

Les principaux acteurs qui interagissent avec votre magasin de clés ont également besoin d'autorisations sur la table DynamoDB. L'ensemble des autorisations dépend du rôle.

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}
};

Python

default_cache = CacheTypeDefault(
    value=DefaultCache(
        entry_capacity=100
    )
)

Rust

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

Go

cache := mpltypes.CacheTypeMemberDefault{
		Value: mpltypes.DefaultCache{
			EntryCapacity: 100,
		},
	}

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
    }
};

Python

multithreaded_cache = CacheTypeMultiThreaded(
    value=MultiThreadedCache(
        entry_capacity=100,
        entry_pruning_tail_size=1
    )
)

Rust

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

Go

var entryPruningTailSize int32 = 1
	cache := mpltypes.CacheTypeMemberMultiThreaded{
		Value: mpltypes.MultiThreadedCache{
			EntryCapacity:        100,
			EntryPruningTailSize: &entryPruningTailSize,
		},
	}

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 plus d'informations, consultez Storm Tracking Cryptographic Materials Cache dans le référentiel GitHub aws-encryption-sdk-specification.

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
    }
};

Python

storm_tracking_cache = CacheTypeStormTracking(
    value=StormTrackingCache(
        entry_capacity=100,
        entry_pruning_tail_size=1,
        fan_out=20,
        grace_interval=1,
        grace_period=10,
        in_flight_ttl=10,
        sleep_milli=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()?)

Go

var entryPruningTailSize int32 = 1
	cache := mpltypes.CacheTypeMemberStormTracking{
		Value: mpltypes.StormTrackingCache{
			EntryCapacity:        100,
			EntryPruningTailSize: &entryPruningTailSize,
			GraceInterval:        1,
			GracePeriod:          10,
			FanOut:               20,
			InFlightTTL:          10,
			SleepMilli:           20,
		},
	}

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 porte-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 porte-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 trousseaux de 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 :