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, puede proteger su material criptográfico con una clave KMS de cifrado simétrico sin tener que llamar AWS KMS cada vez que cifra o descifra datos. 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 datos única para cifrar cada mensaje y cifra cada clave de cifrado de datos para cada solicitud de cifrado y cifra cada clave de cifrado de datos con una clave de encapsulado ú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 sola 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 identificador y la versión de la clave de sucursal identificados en los metadatos del campo cifrado, y se reutilizan para todas las operaciones de descifrado relacionadas con el identificador 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.

Compatibilidad con lenguajes de programación

El conjunto de claves jerárquico es compatible con los siguientes lenguajes y versiones de programación:

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.

Descifrar y verificar

El siguiente tutorial 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

AWS Encryption SDK 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 sobre los AWS KMS key cifrados simétricos de tu almacén de claves.

Los permisos de Amazon DynamoDB necesarios en la tabla de almacenamiento de claves

Los principales que interactúan con su almacén de claves también necesitan permisos en la tabla de DynamoDB. El conjunto de permisos depende del rol.

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

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

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

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 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 obtener más información, consulte Storm Tracking Cryptographic Materials Cache en el repositorio GitHub aws-encryption-sdk-specification.

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

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

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 memoria 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 ID 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: