Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

AWS KMS Llaveros jerárquicos

Con el conjunto de claves AWS KMS jerárquicas, puedes proteger tu material criptográfico con una clave KMS de cifrado simétrico sin tener que recurrir a él AWS KMS cada vez que encriptas o desencriptas un registro. Es una buena opción para las aplicaciones que necesitan reducir al mínimo las llamadas a determinados materiales criptográficos y para AWS KMS las aplicaciones que pueden reutilizar algunos materiales criptográficos sin infringir sus requisitos de seguridad.

El conjunto de claves jerárquicas es una solución de almacenamiento en caché de materiales criptográficos que reduce el número de AWS KMS llamadas mediante el uso de claves de rama AWS KMS protegidas que permanecen en una tabla de Amazon DynamoDB y, a continuación, el almacenamiento local en caché de las claves de rama utilizadas en las operaciones de cifrado y descifrado. La tabla de DynamoDB sirve como almacén de claves que administra y protege las claves de las sucursales. Almacena la clave de rama activa y todas las versiones anteriores de la clave de rama. La clave de rama activa es la versión más reciente de la clave de rama. El conjunto de claves jerárquicas utiliza una clave de cifrado de datos única para cada solicitud de cifrado y cifra cada clave de cifrado de datos con una clave de cifrado única derivada de la clave de sucursal activa. El conjunto de claves jerárquico depende de la jerarquía establecida entre las claves de ramificación activas y las claves de encapsulamiento derivadas.

El conjunto de claves jerárquico suele utilizar cada versión de clave de rama para satisfacer múltiples solicitudes. Sin embargo, usted controla el grado en que se reutilizan las claves de rama activas y determina la frecuencia con la que se gira la clave de rama activa. La versión activa de la clave de rama permanece activa hasta que la gire. Las versiones anteriores de la clave de rama activa no se utilizarán para realizar operaciones de cifrado, pero sí se pueden consultar y utilizar en las operaciones de descifrado.

Al crear una instancia del conjunto de claves jerárquico, se crea una caché local. Se especifica un límite de caché que define el tiempo máximo durante el que los materiales de las claves de ramificación se almacenan en la caché local antes de que caduquen y se expulsen de la caché. El conjunto de claves jerárquico realiza una AWS KMS llamada para descifrar la clave de sucursal y reunir los materiales de la clave de sucursal la primera vez que se especifica a en una operación. branch-key-id A continuación, los materiales de la clave de rama se almacenan en la memoria caché local y se reutilizan para todas las operaciones de cifrado y descifrado que la branch-key-id especifique hasta que caduque el límite de la memoria caché. El almacenamiento del material de las claves de la sucursal en la memoria caché local reduce las llamadas. AWS KMS Por ejemplo, considere un límite de caché de 15 minutos. Si realizas 10 000 operaciones de cifrado dentro de ese límite de caché, el conjunto de AWS KMS claves tradicional necesitaría realizar 10 000 AWS KMS llamadas para cumplir con las 10 000 operaciones de cifrado. Si tiene una activabranch-key-id, el conjunto de claves jerárquicas solo necesita realizar una AWS KMS llamada para realizar 10 000 operaciones de cifrado.

La memoria caché local separa los materiales de cifrado de los de descifrado. Los materiales de cifrado se ensamblan a partir de la clave de sucursal activa y se reutilizan para todas las operaciones de cifrado hasta que caduque el límite de la caché. Los materiales de descifrado se ensamblan a partir del ID de la clave de sucursal y la versión que se identifican en los metadatos del campo cifrado, y se reutilizan para todas las operaciones de descifrado relacionadas con el ID y la versión de la clave de sucursal hasta que caduque el límite de la caché. La caché local puede almacenar varias versiones de la misma clave de sucursal a la vez. Cuando la caché local está configurada para usar unabranch key ID supplier, también puede almacenar materiales de claves de sucursal de varias claves de sucursal activas a la vez.

Funcionamiento

Los siguientes tutoriales describen cómo el conjunto de claves jerárquico reúne los materiales de cifrado y descifrado, y las diferentes llamadas que realiza el conjunto de claves para las operaciones de cifrado y descifrado. Para obtener detalles técnicos sobre los procesos de derivación de claves de ajuste y cifrado de claves de datos de texto no cifrado, consulte Detalles técnicos del conjunto de claves jerárquico de AWS KMS.

Cifra y firma

El siguiente tutorial describe cómo el conjunto de claves jerárquico reúne los materiales de cifrado y obtiene una clave de encapsulamiento única.

Descifrado y verificación

En el siguiente tutorial, se describe cómo el conjunto de claves jerárquico reúne los materiales de descifrado y descifra la clave de datos cifrados.

Requisitos previos

Antes de crear y utilizar un conjunto de claves jerárquicas, asegúrese de que se cumplen los siguientes requisitos previos.

Permisos necesarios

El SDK AWS de cifrado de bases de datos no requiere una Cuenta de AWS y no depende de ninguna Servicio de AWS. Sin embargo, para usar un conjunto de claves jerárquicas, necesitas uno Cuenta de AWS y los siguientes permisos mínimos para los cifrados simétricos de tu AWS KMS key almacén de claves.

Para obtener más información sobre cómo controlar el acceso a las claves de su sucursal y al almacén de claves, consulteImplementación de permisos de privilegio mínimo.

Elige una memoria caché

El conjunto de claves jerárquicas reduce el número de llamadas al AWS KMS almacenar en caché local el material de las claves de sucursal utilizado en las operaciones de cifrado y descifrado. Antes de crear tu conjunto de claves jerárquicas, debes decidir qué tipo de caché quieres usar. Puedes usar la caché predeterminada o personalizarla para que se adapte mejor a tus necesidades.

El conjunto de claves jerárquicas admite los siguientes tipos de caché:

Caché predeterminada

La mayoría de usuarios no necesitará modificar sus requisitos de subprocesamiento. La caché predeterminada está diseñada para admitir entornos con muchos subprocesos múltiples. Cuando caduca una entrada de materiales clave de rama, la caché predeterminada evita que varios subprocesos AWS KMS llamen al notificar a un hilo que la entrada de materiales clave de la sucursal caducará con 10 segundos de antelación. Esto garantiza que solo un subproceso envíe una solicitud AWS KMS para actualizar la caché.

La caché predeterminada y la StormTracking caché admiten el mismo modelo de subprocesamiento, pero solo es necesario especificar la capacidad de entrada para usar la caché predeterminada. Para personalizaciones de caché más detalladas, utilice el. StormTracking caché

A menos que desee personalizar el número de entradas de materiales clave de la rama que se pueden almacenar en la caché local, no es necesario especificar un tipo de caché al crear el conjunto de claves jerárquicas. Si no especificas un tipo de caché, el conjunto de claves jerárquicas utiliza el tipo de caché predeterminado y establece la capacidad de entrada en 1000.

Para personalizar la caché predeterminada, especifique los valores siguientes:

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 caché

La MultiThreaded caché se puede usar de forma segura en entornos con subprocesos múltiples, pero no proporciona ninguna funcionalidad para minimizar AWS KMS las llamadas a Amazon DynamoDB. Como resultado, cuando una entrada de materiales clave de rama caduque, se notificará a todos los subprocesos al mismo tiempo. Esto puede provocar varias AWS KMS llamadas para actualizar la caché.

Para usar la MultiThreaded caché, especifique los valores siguientes:

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 caché

La StormTracking memoria caché está diseñada para soportar entornos con muchos subprocesos múltiples. Cuando una entrada de materiales clave de sucursal caduca, la StormTracking caché evita que varios subprocesos llamen AWS KMS al notificar a un subproceso que la entrada de materiales clave de sucursal va a caducar por adelantado. Esto garantiza que solo un subproceso envíe una solicitud AWS KMS para actualizar la caché.

Para usar la StormTracking caché, especifique los valores siguientes:

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()?)

Caché compartida

De forma predeterminada, el conjunto de claves jerárquico crea una nueva memoria caché local cada vez que se crea una instancia del conjunto de claves. Sin embargo, la caché compartida puede ayudar a conservar la memoria al permitirte compartir una caché entre varios conjuntos de claves jerárquicos. En lugar de crear una nueva caché de materiales criptográficos para cada conjunto de claves jerárquicas que instancie, la caché compartida solo almacena una caché en la memoria, que pueden utilizar todos los conjuntos de claves jerárquicas que hacen referencia a ella. La caché compartida ayuda a optimizar el uso de la memoria al evitar la duplicación de materiales criptográficos en los conjuntos de claves. En cambio, los conjuntos de claves jerárquicos pueden acceder a la misma memoria caché subyacente, lo que reduce el consumo total de memoria.

Cuando creas tu caché compartida, sigues definiendo el tipo de caché. Puede especificar un tipo de caché Caché predeterminadaMultiThreaded caché, o StormTracking caché sustituirlo por cualquier caché personalizada compatible.

Particiones

Varios conjuntos de claves jerárquicos pueden usar una sola caché compartida. Al crear un conjunto de claves jerárquicas con una caché compartida, puede definir un ID de partición opcional. El ID de partición distingue qué conjunto de claves jerárquicas se está escribiendo en la caché. Si dos conjuntos de claves jerárquicos hacen referencia al mismo identificador de partición y al identificador de clave de ramalogical key store name, los dos conjuntos de claves compartirán las mismas entradas de caché en la caché. Si crea dos conjuntos de claves jerárquicos con la misma caché compartida, pero con diferentes identificadores de partición, cada conjunto de claves solo accederá a las entradas de la caché desde su propia partición designada dentro de la caché compartida. Las particiones actúan como divisiones lógicas dentro de la caché compartida, lo que permite que cada conjunto de claves jerárquicas funcione de forma independiente en su propia partición designada, sin interferir con los datos almacenados en la otra partición.

Si tiene la intención de reutilizar o compartir las entradas de la caché de una partición, debe definir su propio identificador de partición. Cuando pasas el identificador de partición a tu conjunto de claves jerárquicas, este puede reutilizar las entradas de la caché que ya están presentes en la caché compartida, en lugar de tener que recuperar y volver a autorizar el material de las claves de la sucursal. Si no especificas un identificador de partición, cada vez que instancies el conjunto de claves jerárquico, se asigna automáticamente un identificador de partición único al conjunto de claves.

Crear un conjunto de claves jerárquico

Para crear un conjunto de claves jerárquico, debe proporcionar los siguientes valores:

Los siguientes ejemplos muestran cómo configurar un almacén de claves con una configuración estática. Elija el idioma que prefiera:

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)?;

Tras configurar el almacén de claves, utilice el objeto de almacén de claves resultante para crear su conjunto de claves jerárquico. En los siguientes ejemplos de conjuntos de claves jerárquicos se utiliza el objeto de almacén de claves que configuró.

Uso del conjunto de claves jerárquico para el cifrado para búsquedas

El cifrado para búsquedas le permite buscar registros cifrados sin necesidad de descifrar toda la base de datos. Esto se logra indexando el valor de texto no cifrado de un campo cifrado con una baliza. Para implementar un cifrado para búsquedas, debe utilizar un conjunto de claves jerárquico.

La operación CreateKey de almacenamiento de claves genera tanto una clave de rama como una clave de baliza. La clave de rama se utiliza en las operaciones de cifrado y descifrado de registros. La clave de baliza se utiliza para generar balizas.

La clave de sucursal y la clave de baliza están protegidas por la misma clave AWS KMS key que especificó al crear su servicio de almacenamiento de claves. Cuando la CreateKey operación llama AWS KMS para generar la clave de sucursal, llama a kms: GenerateDataKeyWithoutPlaintext por segunda vez para generar la clave de baliza mediante la siguiente solicitud.

{
   "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"
}

Tras generar ambas claves, la CreateKey operación llama a ddb: TransactWriteItems para escribir dos elementos nuevos que conservarán la clave de sucursal y la clave de baliza en el almacén de claves de sucursal.

Cuando configuras una baliza estándar, el SDK de cifrado AWS de bases de datos consulta la clave de baliza en el almacén de claves. A continuación, utiliza una función de derivación HMAC-based de claves de extracción y expansión (HKDF) para combinar la clave de baliza con el nombre de la baliza estándar a fin de crear la clave HMAC para una baliza determinada.

A diferencia de las claves de sucursal, solo hay una versión de clave de baliza por almacén de claves. branch-key-id La clave de la baliza nunca se rota.

Definir la fuente de claves de baliza

Al definir la versión de la baliza para las balizas estándar y compuestas, debe identificar la clave de la baliza y definir un tiempo de vida útil (TTL) límite de caché para los materiales de la clave de la baliza. Los materiales de las claves de baliza se almacenan en una caché local independiente de las claves de rama. El siguiente fragmento muestra cómo definir la keySource para la base de datos de un solo inquilino. Identifique la clave de su baliza por el branch-key-id que está asociada.

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()?,
))