Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

AWS KMS Gantungan kunci hierarkis

Dengan keyring AWS KMS hierarkis, Anda dapat melindungi materi kriptografi Anda di bawah kunci KMS enkripsi simetris tanpa memanggil AWS KMS setiap kali Anda mengenkripsi atau mendekripsi catatan. Ini adalah pilihan yang baik untuk aplikasi yang perlu meminimalkan panggilan ke AWS KMS, dan aplikasi yang dapat menggunakan kembali beberapa materi kriptografi tanpa melanggar persyaratan keamanan mereka.

Keyring hierarkis adalah solusi caching materi kriptografi yang mengurangi jumlah AWS KMS panggilan dengan menggunakan kunci cabang yang AWS KMS dilindungi yang disimpan dalam tabel Amazon Dynam oDB, dan kemudian cache materi kunci cabang secara lokal yang digunakan dalam operasi enkripsi dan dekripsi. Tabel DynamoDB berfungsi sebagai penyimpanan kunci yang mengelola dan melindungi kunci cabang. Ini menyimpan kunci cabang aktif dan semua versi kunci cabang sebelumnya. K unci cabang aktif adalah versi kunci cabang terbaru. Keyring hierarkis menggunakan kunci enkripsi data unik untuk setiap permintaan enkripsi dan mengenkripsi setiap kunci enkripsi data dengan kunci pembungkus unik yang berasal dari kunci cabang aktif. Gantungan kunci hierarkis bergantung pada hierarki yang ditetapkan antara kunci cabang aktif dan kunci pembungkus turunannya.

Keyring hierarkis biasanya menggunakan setiap versi kunci cabang untuk memenuhi beberapa permintaan. Tetapi Anda mengontrol sejauh mana kunci cabang aktif digunakan kembali dan menentukan seberapa sering kunci cabang aktif diputar. Versi aktif dari kunci cabang tetap aktif sampai Anda memutarnya. Versi sebelumnya dari kunci cabang aktif tidak akan digunakan untuk melakukan operasi enkripsi, tetapi mereka masih dapat ditanyakan dan digunakan dalam operasi dekripsi.

Saat Anda membuat instance keyring hierarkis, itu membuat cache lokal. Anda menentukan batas cache yang menentukan jumlah waktu maksimum materi kunci cabang disimpan dalam cache lokal sebelum kedaluwarsa dan diusir dari cache. Gantungan kunci hierarkis membuat satu AWS KMS panggilan untuk mendekripsi kunci cabang dan merakit bahan kunci cabang saat pertama kali a branch-key-id ditentukan dalam suatu operasi. Kemudian, materi kunci cabang disimpan dalam cache lokal dan digunakan kembali untuk semua operasi enkripsi dan dekripsi yang menentukan itu branch-key-id sampai batas cache berakhir. Menyimpan materi kunci cabang di cache lokal mengurangi AWS KMS panggilan. Misalnya, pertimbangkan batas cache 15 menit. Jika Anda melakukan 10.000 operasi enkripsi dalam batas cache tersebut, AWS KMS keyring tradisional perlu membuat 10.000 AWS KMS panggilan untuk memenuhi 10.000 operasi enkripsi. Jika Anda memiliki satu yang aktifbranch-key-id, keyring hierarkis hanya perlu membuat satu AWS KMS panggilan untuk memenuhi 10.000 operasi enkripsi.

Cache lokal memisahkan bahan enkripsi dari bahan dekripsi. Materi enkripsi dirakit dari kunci cabang aktif dan digunakan kembali untuk semua operasi enkripsi sampai batas cache berakhir. Materi dekripsi dirakit dari ID kunci cabang dan versi yang diidentifikasi dalam metadata bidang terenkripsi, dan mereka digunakan kembali untuk semua operasi dekripsi yang terkait dengan ID kunci cabang dan versi hingga batas cache berakhir. Cache lokal dapat menyimpan beberapa versi kunci cabang yang sama sekaligus. Ketika cache lokal dikonfigurasi untuk menggunakan abranch key ID supplier, itu juga dapat menyimpan materi kunci cabang dari beberapa kunci cabang aktif sekaligus.

Cara kerjanya

Penelusuran berikut menjelaskan bagaimana keyring hierarkis merakit materi enkripsi dan dekripsi, dan panggilan berbeda yang dilakukan keyring untuk operasi enkripsi dan dekripsi. Untuk detail teknis tentang derivasi kunci pembungkus dan proses enkripsi kunci data plaintext, lihat Detail teknis gantungan kunci AWS KMS hierarkis.

Enkripsi dan tanda tangani

Panduan berikut menjelaskan bagaimana keyring hierarkis merakit bahan enkripsi dan memperoleh kunci pembungkus yang unik.

Dekripsi dan verifikasi

Panduan berikut menjelaskan bagaimana keyring hierarkis merakit materi dekripsi dan mendekripsi kunci data terenkripsi.

Prasyarat

Sebelum Anda membuat dan menggunakan keyring hierarkis, pastikan prasyarat berikut terpenuhi.

Izin yang diperlukan

AWS Database Encryption SDK tidak memerlukan Akun AWS dan tidak bergantung pada apa pun Layanan AWS. Namun, untuk menggunakan keyring hierarkis, Anda Akun AWS memerlukan izin minimum berikut pada enkripsi simet AWS KMS key ris di penyimpanan kunci Anda.

Untuk informasi selengkapnya tentang mengendalikan akses ke kunci cabang dan penyimpanan kunci, lihatMenerapkan izin yang paling tidak diistimewakan.

Pilih cache

Keyring hierarkis mengurangi jumlah panggilan yang dilakukan AWS KMS dengan menyimpan secara lokal materi kunci cabang yang digunakan dalam operasi enkripsi dan mendekripsi. Sebelum Anda membuat keyring hierarkis, Anda perlu memutuskan jenis cache apa yang ingin Anda gunakan. Anda dapat menggunakan cache default atau menyesuaikan cache agar sesuai dengan kebutuhan Anda.

Keyring hierarkis mendukung jenis cache berikut:

Cache default

Bagi sebagian besar pengguna, cache Default memenuhi persyaratan threading mereka. Cache Default dirancang untuk mendukung lingkungan multithread yang berat. Ketika entri materi kunci cabang kedaluwarsa, cache Default mencegah beberapa thread dipanggil AWS KMS dengan memberi tahu satu thread bahwa entri materi kunci cabang akan kedaluwarsa 10 detik sebelumnya. Ini memastikan bahwa hanya satu thread mengirim permintaan AWS KMS untuk menyegarkan cache.

Default dan StormTracking cache mendukung model threading yang sama, tetapi Anda hanya perlu menentukan kapasitas entri untuk menggunakan cache Default. Untuk penyesuaian cache yang lebih terperinci, gunakan. StormTracking cache

Kecuali Anda ingin menyesuaikan jumlah entri materi kunci cabang yang dapat disimpan dalam cache lokal, Anda tidak perlu menentukan jenis cache saat membuat keyring hierarkis. Jika Anda tidak menentukan jenis cache, keyring hierarkis menggunakan tipe cache Default dan menetapkan kapasitas entri menjadi 1000.

Untuk menyesuaikan cache Default, tentukan nilai-nilai berikut:

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

MultiThreaded Cache aman digunakan di lingkungan multithread, tetapi tidak menyediakan fungsionalitas apa pun untuk meminimalkan AWS KMS atau panggilan Amazon DynamoDB. Akibatnya, ketika entri materi kunci cabang kedaluwarsa, semua utas akan diberitahu pada saat yang sama. Ini dapat menghasilkan beberapa AWS KMS panggilan untuk menyegarkan cache.

Untuk menggunakan MultiThreaded cache, tentukan nilai-nilai berikut:

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

C StormTracking ache dirancang untuk mendukung lingkungan multithread yang berat. Ketika entri materi kunci cabang kedaluwarsa, StormTracking cache mencegah beberapa utas memanggil AWS KMS dengan memberi tahu satu utas bahwa entri materi kunci cabang akan kedaluwarsa terlebih dahulu. Ini memastikan bahwa hanya satu thread mengirim permintaan AWS KMS untuk menyegarkan cache.

Untuk menggunakan StormTracking cache, tentukan nilai-nilai berikut:

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 bersama

Secara default, keyring hierarkis membuat cache lokal baru setiap kali Anda membuat instance keyring. Namun, cache bersama dapat membantu menghemat memori dengan memungkinkan Anda berbagi cache di beberapa gantungan kunci hierarkis. Alih-alih membuat cache materi kriptografi baru untuk setiap keyring Hierarkis yang Anda buat, cache Bersama hanya menyimpan satu cache dalam memori, yang dapat digunakan oleh semua gantungan kunci hierarkis yang mereferensikannya. Cache bersama membantu mengoptimalkan penggunaan memori dengan menghindari duplikasi materi kriptografi di seluruh gantungan kunci. Sebaliknya, gantungan kunci hierarkis dapat mengakses cache dasar yang sama, mengurangi jejak memori secara keseluruhan.

Saat Anda membuat cache Bersama, Anda masih menentukan jenis cache. Anda dapat menentukanCache default,MultiThreaded cache, atau StormTracking cache sebagai jenis cache, atau mengganti cache khusus yang kompatibel.

Partisi

Beberapa gantungan kunci hierarkis dapat menggunakan cache Bersama tunggal. Saat Anda membuat keyring hierarkis dengan cache bersama, Anda dapat menentukan ID partisi opsional. ID partisi membedakan keyring hierarkis mana yang menulis ke cache. Jika dua gantungan kunci hierarkis mereferensikan ID partisi yang samalogical key store name,, dan ID kunci cabang, kedua gantungan kunci akan berbagi entri cache yang sama di cache. Jika Anda membuat dua gantungan kunci hierarkis dengan cache bersama yang sama, tetapi ID partisi yang berbeda, setiap keyring hanya akan mengakses entri cache dari partisi yang ditunjuk sendiri dalam cache Bersama. Partisi bertindak sebagai divisi logis dalam cache bersama, memungkinkan setiap keyring hierarkis beroperasi secara independen pada partisi yang ditunjuk sendiri, tanpa mengganggu data yang disimpan di partisi lain.

Jika Anda ingin menggunakan kembali atau berbagi entri cache dalam partisi, Anda harus menentukan ID partisi Anda sendiri. Ketika Anda meneruskan ID partisi ke keyring Hierarchical Anda, keyring dapat menggunakan kembali entri cache yang sudah ada di cache Bersama, daripada harus mengambil dan mengotorisasi ulang materi kunci cabang lagi. Jika Anda tidak menentukan ID partisi, ID partisi unik secara otomatis ditetapkan ke keyring setiap kali Anda membuat instance keyring hierarkis.

Buat gantungan kunci hierarkis

Untuk membuat keyring hierarkis, Anda harus memberikan nilai-nilai berikut:

Contoh berikut menunjukkan cara mengkonfigurasi penyimpanan kunci dengan konfigurasi statis. Pilih bahasa pilihan Anda:

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

Setelah Anda mengonfigurasi penyimpanan kunci, gunakan objek penyimpanan kunci yang dihasilkan untuk membuat keyring Hierarchical Anda. Contoh keyring hierarkis yang mengikuti menggunakan objek penyimpanan kunci yang Anda konfigurasikan.

Menggunakan keyring hierarkis untuk enkripsi yang dapat dicari

Enkripsi yang dapat dicari memungkinkan Anda untuk mencari catatan terenkripsi tanpa mendekripsi seluruh database. Ini dicapai dengan mengindeks nilai plaintext dari bidang terenkripsi dengan suar. Untuk menerapkan enkripsi yang dapat dicari, Anda harus menggunakan keyring hierarkis.

CreateKeyOperasi penyimpanan kunci menghasilkan kunci cabang dan kunci suar. Kunci cabang digunakan dalam enkripsi rekaman dan operasi dekripsi. Kunci suar digunakan untuk menghasilkan beacon.

Kunci cabang dan kunci suar dilindungi oleh yang sama dengan AWS KMS key yang Anda tentukan saat membuat layanan penyimpanan kunci Anda. Setelah CreateKey operasi memanggil AWS KMS untuk menghasilkan kunci cabang, ia memanggil kms: GenerateDataKeyWithoutPlaintext kedua kalinya untuk menghasilkan kunci suar menggunakan permintaan berikut.

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

Setelah menghasilkan kedua kunci, CreateKey operasi memanggil ddb: TransactWriteItems untuk menulis dua item baru yang akan mempertahankan kunci cabang dan kunci suar di penyimpanan kunci cabang Anda.

Saat Anda mengonfigurasi suar standar, AWS Database Encryption SDK menanyakan penyimpanan kunci untuk kunci beacon. Kemudian, ia menggunakan fungsi derivasi HMAC-based kunci ekstrak-dan-perluas (HKDF) untuk menggabungkan kunci suar dengan nama suar standar untuk membuat kunci HMAC untuk suar tertentu.

Tidak seperti kunci cabang, hanya ada satu versi kunci suar per branch-key-id di toko kunci. Kunci suar tidak pernah diputar.

Mendefinisikan sumber kunci suar Anda

Saat Anda menentukan versi suar untuk suar standar dan majemuk Anda, Anda harus mengidentifikasi kunci suar dan menentukan batas waktu cache untuk hidup (TTL) untuk materi kunci suar. Materi kunci suar disimpan dalam cache lokal terpisah dari kunci cabang. Cuplikan berikut menunjukkan cara mendefinisikan keySource untuk database penyewa tunggal. Identifikasi kunci suar Anda dengan yang terkait dengannya. branch-key-id

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