鍵の再ラップ
以下を使用して、データ暗号鍵を再暗号化します。 IBM® Key Protect API。
Key Protect 内のルート鍵をローテートすると、そのルート鍵と関連付けられたデータ暗号鍵 (DEK) を保護するための新しい暗号鍵素材が使用可能になります。 再ラップ API を使用して、 DEK を、非暗号化テキスト形式で鍵を公開することなく、再暗号化 (再ラップ) することができます。
エンベロープ暗号化がクラウド内の保存データのセキュリティー制御にどのように役立つかについては、エンベロープ暗号化を使用したデータ保護を参照してください。
API を使用した鍵の再ラップ
Key Protect 内で管理するルート鍵を使用して、指定されたデータ暗号鍵 (DEK) を、非暗号化テキスト形式でその DEK を公開することなく、再暗号化できます。
鍵の再ラップは、サービスへの unwrap 呼び出しと wrap 呼び出しを組み合わせることで機能します。 例えば、最初に rewrap API を呼び出して DEK にアクセスし、次に unwrap API を呼び出してその DEK を最新ルート鍵素材を使用して再暗号化することによって、wrap 操作をエミュレートできます。
サービス内でルート鍵をローテーションした後 を作成することで、ルート・キーに関連付けられているデータ暗号化キーをリラップする。
POST
https://<region>.kms.cloud.ibm.com/api/v2/keys/<keyID_or_alias>/actions/rewrap
-
最初のラップ要求を実行するために使用した、ローテートされたルート鍵の ID をコピーします。
GET api/v2/keys要求を行うか、Key Protect で鍵を表示することによって、鍵の ID を取得できます。 GUI。 -
最新のラップ要求時に返された
ciphertext値をコピーします。 -
以下を実行して、最新のルート・キー材料でキーをリラップする
curlコマンドを使用して作成できます。$ curl -X POST \ "https://<region>.kms.cloud.ibm.com/api/v2/keys/<keyID_or_alias>/actions/rewrap" \ -H "accept: application/vnd.ibm.kms.key_action+json" \ -H "authorization: Bearer <IAM_token>" \ -H "bluemix-instance: <instance_ID>" \ -H "content-type: application/vnd.ibm.kms.key_action+json" \ -H "x-kms-key-ring: <key_ring_ID>" \ -H "correlation-id: <correlation_ID>" \ -d '{ "ciphertext": "<encrypted_data_key>", "aad": [ "<additional_data>", "<additional_data>" ] }'次の表に従って、例の要求内の変数を置き換えてください。
| 変数 | 説明 |
|---|---|
| リージョン | 必須。 Key Protect インスタンスが |
存在している地理的領域を表す、
地域の省略形
(例: `us-south` または
`eu-gb`)。<br>詳細については、 [地域サービスエンドポイントを](/docs/key-protect?topic=key-protect-regions#service-endpoints) 参照してください。 |
| keyID_or_alias | 必須。 初回のラップ要求に使用したルート鍵の固有 ID または別名。 | | IAM_token | 必須。 IBM Cloud アクセス・トークン。 Bearer 値を含む、IAM トークンの全コンテンツを curl 要求に組み込みます。
詳細については、 アクセストークンの取得を 参照してください。 | | instance_ID | 必須。 Key Protect サービス・インスタンスに割り当てられた固有 ID。
詳細については、 インスタンスIDの取得を 参照してください。 | | key_ring_ID | オプション。 鍵が属する鍵リングの固有 ID。 指定しない場合は、Key
Protect が、指定されたインスタンスに関連付けられているすべての鍵リングで鍵を検索します。 鍵リング ID を指定して、より最適化された要求を行うことをお勧めします。
注: x-kms-key-ring ヘッダーなしで作成された鍵のキーホルダーIDは、defaultである。
For more information, see グループ化キー.
| | correlation_ID | トランザクションを追跡し、相互に関連付けるために使用される固有 ID。 | | encrypted_data_key | 必須。 元のラップ操作によって返された ciphertext 値。 | | additional_data | オプション 鍵の保護を強化するために使用する追加認証データ (AAD)。 各ストリングは、最大 255 文字を保持できます。 最初のラップ呼び出しで
AAD を指定した場合、後続のアンラップ呼び出しまたは再ラップ呼び出し時に同じ AAD を指定する必要があります。
重要: Key Protect サービスは、追加の認証データを保存しない。 AAD を提供する場合は、後続のアンラップ要求または再ラップ要求時に、同じ AAD にアクセスして提供できるようにするため、データを安全な場所に保存してください。 |
新しくラップされたデータ暗号キー、元のキー・バージョン (keyVersion) 提供された暗号化テキストに関連付けられ、新しい暗号化テキストに関連付けられた最新のキー・バージョン (rewrappedKeyVersion) が応答エンティティー本文で返されます。 以下の JSON オブジェクトは、返された値の例を示しています。
{
"ciphertext": "eyJjaX ... h0Ijoi ... c1ZCJ9",
"keyVersion": {
"id": "02fd6835-6001-4482-a892-13bd2085f75d"
},
"rewrappedKeyVersion": {
"id": "12e8c9c2-a162-472d-b7d6-8b9a86b815a6"
}
}
データが最新のルート鍵で保護されるように、この新しい ciphertext 値を保管し、今後のエンベロープ暗号化操作で使用してください。
オプションの確認
ciphertext の値を base64 でデコードして、鍵が正常に再ラップされたことを確認します。
$ echo <ciphertext> | base64 --decode
<ciphertext> を、前のステップで返された base64 エンコード値に置き換えます。 以下の JSON オブジェクトは、CLI 出力の例を示しています。
{
"ciphertext": "mIzRrwZAA8+WqRckG6gt1ji8HlEEJPSiV+TRBSR4GVr+FlAZlC5KvRriRF0=",
"iv": "lbwxXlAW2DS7+5jGz5Y1Kg==",
"version": "4.0.0",
"handle": "8e309bae-b3ec-4270-9b87-89f8697fe54f"
}