翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AWS KMS 階層キーリング

AWS KMS 階層キーリングを使用すると、レコードを暗号化または復号する AWS KMS たびに を呼び出すことなく、対称暗号化 KMS キーで暗号化マテリアルを保護できます。これは、 への呼び出しを最小限に抑える必要があるアプリケーションや AWS KMS、セキュリティ要件に違反することなく一部の暗号化マテリアルを再利用できるアプリケーションに適しています。

階層キーリングは、Amazon DynamoDB テーブルに保持されている AWS KMS 保護されたブランチキーを使用し、暗号化および復号オペレーションで使用されるブランチキーマテリアルをローカルにキャッシュすることで AWS KMS 、呼び出しの数を減らす暗号化マテリアルキャッシュソリューションです。DynamoDB テーブルは、ブランチキーを管理および保護するキーストアとして機能します。アクティブなブランチキーと、ブランチキーの以前のすべてのバージョンが格納されます。アクティブなブランチキーは、ブランチキーの最新バージョンです。階層キーリングは、暗号化リクエストごとに一意のデータ暗号化キーを使用し、アクティブなブランチキーから派生した一意のラッピングキーを使用して各データ暗号化キーを暗号化します。階層キーリングは、アクティブなブランチキーと、その導出ラッピングキーの間に確立された階層に依拠します。

階層キーリングは通常、複数のリクエストを満たすために各ブランチキーバージョンを使用します。ただし、ユーザーがアクティブなブランチキーを再利用する範囲を制御し、アクティブなブランチキーをローテーションする頻度を決定します。ブランチキーのアクティブなバージョンは、ローテーションされるまでアクティブなままとなります。アクティブなブランチキーの以前のバージョンは暗号化オペレーションの実行には使用されませんが、引き続きクエリを実行して復号オペレーションに使用できます。

階層キーリングをインスタンス化すると、ローカルキャッシュが作成されます。ブランチキーマテリアルがローカルキャッシュ内に格納される最大時間 (ブランチキーマテリアルが期限切れになってキャッシュから削除されるまでの時間) を定義するキャッシュ制限を指定します。階層キーリングは 1 回の AWS KMS 呼び出しを行い、 オペレーションで が初めてbranch-key-id指定されたときにブランチキーを復号し、ブランチキーマテリアルをアセンブルします。その後、ブランチキーマテリアルはローカルキャッシュに格納され、キャッシュ制限が期限切れになるまで、その branch-key-id を指定するすべての暗号化および復号オペレーションのために再利用されます。ブランチキーマテリアルをローカルキャッシュに保存すると、 AWS KMS 呼び出しが減ります。例えば、キャッシュ制限が 15 分である場合を考えてみましょう。そのキャッシュ制限内で 10,000 回の暗号化オペレーションを実行する場合、従来の AWS KMS キーリングは 10,000 回の暗号化オペレーションを満たすために 10,000 回の AWS KMS 呼び出しを行う必要があります。アクティブな が 1 つある場合branch-key-id、階層キーリングは 10,000 回の暗号化オペレーションを満たすために 1 回の AWS KMS 呼び出しを行うだけで済みます。

ローカルキャッシュは、暗号化マテリアルと復号マテリアルを分離します。暗号化マテリアルはアクティブなブランチキーからアセンブルされ、キャッシュ制限が期限切れになるまですべての暗号化オペレーションに再利用されます。復号マテリアルは、暗号化されたフィールドのメタデータで識別されるブランチキー ID とバージョンからアセンブルされ、キャッシュ制限の有効期限が切れるまで、ブランチキー ID とバージョンに関連するすべての復号オペレーションに再利用されます。ローカルキャッシュは、同じブランチキーの複数のバージョンを一度に保存できます。ローカルキャッシュが を使用するように設定されている場合branch key ID supplier、一度に複数のアクティブなブランチキーからのブランチキーマテリアルを保存することもできます。

仕組み

次のチュートリアルでは、階層キーリングが暗号化および復号マテリアルをアセンブルする方法と、暗号化および復号オペレーションのためにキーリングが実行するさまざまな呼び出しについて説明します。ラッピングキーの導出とプレーンテキストデータキーの暗号化プロセスの技術的な詳細については、「AWS KMS 階層キーリングの技術的な詳細」を参照してください。

暗号化および署名

次のチュートリアルでは、階層キーリングが暗号化マテリアルをアセンブルし、一意のラッピングキーを導出する方法について説明します。

復号および検証

次のチュートリアルでは、階層キーリングが復号マテリアルをアセンブルし、暗号化されたデータキーを復号する方法について説明します。

前提条件

階層キーリングを作成して使用する前に、次の前提条件が満たされていることを確認してください。

必要なアクセス許可

AWS Database Encryption SDK は を必要とせず AWS アカウント 、 に依存しません AWS のサービス。ただし、階層キーリングを使用するには、 AWS アカウント と、キーストアの対称暗号化 AWS KMS key（複数可) に対する以下の最小限のアクセス許可が必要です。

ブランチキーとキーストアへのアクセスの制御の詳細については、「」を参照してください最小特権のアクセス許可の実装。

キャッシュを選択する

階層キーリングは、暗号化および復号オペレーションで使用されるブランチキーマテリアルをローカルにキャッシュ AWS KMS することで、 への呼び出し回数を減らします。階層キーリングを作成する前に、使用するキャッシュのタイプを決定する必要があります。デフォルトのキャッシュを使用するか、ニーズに合わせてキャッシュをカスタマイズできます。

階層キーリングは、次のキャッシュタイプをサポートしています。

デフォルトキャッシュ

ほとんどのユーザーにとって、Default キャッシュはスレッド要件を満たします。Default キャッシュは、高度にマルチスレッド化されている環境をサポートするように設計されています。ブランチキーマテリアルエントリの有効期限が切れると、デフォルトキャッシュは、ブランチキーマテリアルエントリの有効期限が 10 秒前になることを 1 つのスレッドに通知 AWS KMS することで、複数のスレッドが呼び出されるのを防ぎます。これにより、1 つのスレッドのみが にリクエストを送信 AWS KMS してキャッシュを更新します。

デフォルトキャッシュと StormTracking キャッシュは同じスレッドモデルをサポートしますが、デフォルトキャッシュを使用するにはエントリ容量を指定するだけで済みます。より詳細なキャッシュのカスタマイズを行うには、 を使用しますStormTracking キャッシュ。

ローカルキャッシュに保存できるブランチキーマテリアルエントリの数をカスタマイズする場合を除き、階層キーリングを作成するときにキャッシュタイプを指定する必要はありません。キャッシュタイプを指定しない場合、階層キーリングはデフォルトのキャッシュタイプを使用し、エントリ容量を 1000 に設定します。

デフォルトキャッシュをカスタマイズするには、次の値を指定します。

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キャッシュ

MultiThreaded キャッシュは、マルチスレッド環境で安全に使用できますが、 AWS KMS または Amazon DynamoDB 呼び出しを最小限に抑える機能はありません。その結果、ブランチキーマテリアルのエントリの期限が切れると、すべてのスレッドに同時に通知されます。これにより、キャッシュを更新するための複数の AWS KMS 呼び出しが発生する可能性があります。

MultiThreaded キャッシュを使用するには、次の値を指定します。

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 キャッシュ

StormTracking キャッシュは、高度にマルチスレッド化されている環境をサポートするように設計されています。ブランチキーマテリアルエントリの有効期限が切れると、StormTracking キャッシュは、ブランチキーマテリアルエントリの有効期限が切れることを 1 つのスレッドに通知 AWS KMS することで、複数のスレッドが を呼び出すのを防ぎます。これにより、1 つのスレッドのみが にリクエストを送信 AWS KMS してキャッシュを更新します。

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

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

共有キャッシュ

デフォルトでは、階層キーリングは、キーリングをインスタンス化するたびに新しいローカルキャッシュを作成します。ただし、共有キャッシュを使用すると、複数の階層キーリング間でキャッシュを共有できるため、メモリを節約できます。インスタンス化する階層キーリングごとに新しい暗号化マテリアルキャッシュを作成するのではなく、共有キャッシュは 1 つのキャッシュのみをメモリに保存します。このキャッシュは、それを参照するすべての階層キーリングで使用できます。共有キャッシュは、キーリング間での暗号化マテリアルの重複を回避することで、メモリ使用量を最適化するのに役立ちます。代わりに、階層キーリングは同じ基盤となるキャッシュにアクセスできるため、全体的なメモリフットプリントが削減されます。

共有キャッシュを作成する場合でも、キャッシュタイプを定義します。StormTracking キャッシュ キャッシュタイプとして デフォルトキャッシュ、MultiThreadedキャッシュ、または を指定するか、互換性のあるカスタムキャッシュを置き換えることができます。

パーティション

複数の階層キーリングで 1 つの共有キャッシュを使用できます。共有キャッシュを使用して階層キーリングを作成する場合、オプションのパーティション ID を定義できます。パーティション ID は、キャッシュに書き込む階層キーリングを区別します。2 つの階層キーリングが同じパーティション ID、logical key store name、ブランチキー ID を参照している場合、2 つのキーリングはキャッシュ内で同じキャッシュエントリを共有します。同じ共有キャッシュで異なるパーティション IDs を持つ 2 つの階層キーリングを作成すると、各キーリングは共有キャッシュ内の独自の指定されたパーティションからのみキャッシュエントリにアクセスします。パーティションは共有キャッシュ内の論理的な分割として機能し、各階層キーリングが他のパーティションに保存されているデータを妨害することなく、独自の指定されたパーティションで独立して動作できるようにします。

パーティション内のキャッシュエントリを再利用または共有する場合は、独自のパーティション ID を定義する必要があります。パーティション ID を階層キーリングに渡すと、キーリングは、ブランチキーマテリアルを再度取得して再承認するのではなく、共有キャッシュに既に存在するキャッシュエントリを再利用できます。パーティション ID を指定しない場合、階層キーリングをインスタンス化するたびに、一意のパーティション ID がキーリングに自動的に割り当てられます。

階層キーリングを作成する

階層キーリングを作成するには、次の値を指定する必要があります。

検索可能な暗号化のための階層キーリングの使用

検索可能な暗号化を使用すると、データベース全体を復号することなく、暗号化されたレコードを検索できます。これは、ビーコンを使用して暗号化されたフィールドのプレーンテキストの値にインデックスを付けることで実現されます。検索可能な暗号化を実装するには、階層キーリングを使用する必要があります。

キーストア CreateKey オペレーションは、ブランチキーとビーコンキーの両方を生成します。ブランチキーは、レコードの暗号化および復号オペレーションで使用されます。ビーコンキーは、ビーコンを生成するために使用されます。

ブランチキーとビーコンキーは、キーストアサービスの作成時に指定した AWS KMS key ものと同じ によって保護されます。CreateKey オペレーションが AWS KMS を呼び出してブランチキーを生成すると、kms:GenerateDataKeyWithoutPlaintext をもう一度呼び出し、次のリクエストを使用してビーコンキーを生成します。

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

両方のキーを生成した後、CreateKey オペレーションは ddb:TransactWriteItems を呼び出して、ブランチキーとビーコンキーを永続化する 2 つの新しい項目をブランチキーストアに書き込みます。

標準ビーコンを設定すると、 AWS Database Encryption SDK はキーストアにビーコンキーをクエリします。その後、HMAC ベースの extract-and-expand 鍵導出関数 (HKDF) を使用して、ビーコンキーと標準ビーコンの名前を組み合わせ、特定のビーコンの HMAC キーを作成します。

ブランチキーとは異なり、キーストアには ごとに 1 つのビーコンbranch-key-idキーバージョンしかありません。ビーコンキーがローテーションされることはありません。

ビーコンキーソースの定義

標準ビーコンおよび複合ビーコンのビーコンバージョンを定義する際には、ビーコンキーを識別し、ビーコンキーマテリアルのキャッシュ制限 Time To Live (TTL) を定義する必要があります。ビーコンキーマテリアルは、ブランチキーとは別のローカルキャッシュに格納されます。次のスニペットは、シングルテナンシーデータベースの keySource を定義する方法を示しています。関連付けられている 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()?,
))