Key Protect の統合

Gen 2

Cloud Databases に保存されるデータは、デフォルトでランダムに生成された鍵を使用して暗号化されます。 暗号化キーを管理するには、 IBM Key Protect を通じてBring Your Own Key(BYOK)を利用し、独自のキーのいずれかを使用してデータベースやバックアップを暗号化することができます。

まずは、 Key ProtectIBM Cloud アカウントで設定を行ってください。

Key Protect での鍵の作成または追加

Key Protect のインスタンスに移動して、鍵を生成または入力します。

UI でのサービス承認

Key Protect デプロイメントで使用できるように Cloud Databases を許可します。

  1. IBM Cloud のダッシュボードを開きます。
  2. メニューバーから、 [管理 ] → [ アクセス (IAM) ] をクリックします。
  3. サイド・ナビゲーションで、**「許可」**をクリックします。
  4. 「作成」 をクリックします。
  5. **「ソース・サービス」**メニューで、デプロイメントのサービスを選択します。 例えば、 Databases for PostgreSQL あるいは Databases for MongoDB。
  6. ソース サービスのリソースメニューで、 すべてのリソース を選択します。
  7. 「ターゲット・サービス」 メニューで、「Key Protect」 を選択します。
  8. [リソースグループ] アカウント として、デフォルト値を選択するか、そのまま維持してください。 対象サービス
  9. ターゲット・サービスの**「インスタンス ID」**メニューで、許可を付与するサービス・インスタンスを選択します。
  10. リーダー の役割を有効にします。
  11. Bring your own key(BYOK)を使用するには、 依存サービスの承認セクションで、 承認の委任を有効にするチェックボックスを選択してください。
  12. 「許可」 をクリックします。

鍵を使用してデプロイメントをプロビジョンする前にサービス許可が存在していない場合は、プロビジョンが失敗します。

より厳格な承認ポリシーを設定したい場合は、明示的なルートキーCRN、または特定の Key Protect インスタンスを対象としてポリシーを設定してください。

CLI でのサービス認証の付与

  1. Cloud Databases サービスが、CLI上の Key Protect サービスインスタンスにアクセスできるようにする承認ポリシーを作成します。 すべての引数については、 IAM CLI リファレンス を参照してください。
ibmcloud iam authorization-policy-create <SERVICE-NAME> kms "Reader,AuthorizationDelegator"

鍵を使用してデプロイメントをプロビジョンする前にサービス許可が存在していない場合は、プロビジョンが失敗します。

より厳格な承認ポリシーを設定したい場合は、明示的なルートキーCRN、または特定の Key Protect インスタンスを対象としてポリシーを設定してください。

REST API によるサービス認証の付与

  1. Cloud Databases サービスが、IAM REST API を通じて Key Protect サービスインスタンスにアクセスできるようにする承認ポリシーを作成します。

APIのリファレンスの詳細については、「 IAM ポリシー管理 API 」を参照してください。

curl -X POST 'https://iam.cloud.ibm.com/v1/policies' -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' -d '{
  "type": "authorization",
  "subjects": [
      {
          "attributes": [
              {
                  "name": "accountId",
                  "value": "CUSTOMER_ACCOUNT_ID"
              },
              {
                  "name": "serviceName",
                  "value": "<SERVICE-NAME>"
              }
          ]
      }
  ],
  "roles": [
      {
        "role_id": "crn:v1:bluemix:public:iam::::serviceRole:Reader"
      },
      {
        "role_id": "crn:v1:bluemix:public:iam::::role:AuthorizationDelegator"
      }
    ],
    "resources": [
        {
            "attributes": [
                {
                    "name": "accountId",
                    "operator": "stringEquals",
                    "value": "CUSTOMER_ACCOUNT_ID"
                },
                {
                    "name": "serviceName",
                    "operator": "stringEquals",
                    "value": "kms"
                }
            ]
        }
    ]
}'

鍵を使用してデプロイメントをプロビジョンする前にサービス許可が存在していない場合は、プロビジョンが失敗します。

より厳格な承認ポリシーを設定したい場合は、明示的なルートキーCRN、または特定の Key Protect インスタンスを対象としてポリシーを設定してください。

Key Protect キーの使用

鍵を使用する許可を Cloud Databases デプロイメントに付与した後、デプロイメントをプロビジョンするときに鍵の名前または CRN を指定します。 このデプロイメントは暗号鍵を使用してデータを暗号化します。

プロビジョニング時のUIで「 Key Protect 」キーを使用する

カタログページからプロビジョニングを行う場合は、ドロップダウンメニューから Key Protect インスタンスとキーを選択してください。

プロビジョニング時にCLIで Key Protect キーを使用する

CLI では、parameters JSON オブジェクト内の dataservices.encryption.disk パラメータを使用して、サービスインスタンスにルートキーの CRN を割り当てます。

ibmcloud resource service-instance-create <INSTANCE-NAME> <SERVICE-NAME> <PLAN-NAME> REGION -p '{"dataservices":{"encryption":{"disk":"KMS_KEY_CRN"}}}'

Key Protect キーは、IDだけでなく、完全なCRNで識別する必要があります。 Key Protect のCRNは、という形式になっています crn:v1:<...>:key:<id>。

プロビジョニング時のAPIで Key Protect キーを使用する

API では、リクエストのボディ内でパラメータ dataservices.encryption.disk を使用してください。

  curl -X POST https://resource-controller.cloud.ibm.com/v2/resource_instances -H "Authorization: Bearer <IAM token>" -H 'Content-Type: application/json' -d '{
    "name": "<INSTANCE-NAME>",
    "target": "ca-mon",
    "resource_group": "<A RESOURCE GROUP GUID>",
    "resource_plan_id": "<A PLAN ID>",
    "parameters": {
      "dataservices": {
          "encryption": {
            "disk": "KMS_KEY_CRN"
          }
      }
    }

Key Protect キーは、IDだけでなく、完全なCRNで識別する必要があります。 Key Protect のCRNは、という形式になっています crn:v1:<...>:key:<id>。

鍵のローテーション

Key Protect 手動および自動の キーローテーション 機能を提供しており、 Cloud Databases の展開環境ではキーローテーションがサポートされています。 鍵をローテートすると、プロセスは _KMS 状態の同期中_タスクを開始し、デプロイメントは新しい鍵で再暗号化されます。 このタスクはデプロイメントの_概要_にある_タスク_ページに表示され、関連する Key Protect および Cloud Databases イベントが Activity Tracker に送信されます。

詳細については、「 手動または自動での回転 」を参照してください。

デプロイメントの削除

Key Protect キーで保護されているデプロイメントを削除した場合、そのデプロイメントはソフト削除期間(最大9日間)中は、引き続きそのキーに登録されたままとなります。 ソフト削除期間中にキーを削除するには、そのキーを 強制削除してください。 ソフト削除期間が経過すると、その鍵は強制しなくても削除できます。 キーをいつ削除できるかを確認するには、 そのキーとデプロイメントとの関連性を 確認してください。

暗号の廃棄

暗号の廃棄は破壊アクションです。 鍵が削除されると、データはリカバリー不能になります。

Key Protect これにより、 IBM Cloud® サービス(第2世代 Cloud Databases の展開を含む)で使用中のキーを 強制削除することができます。 このアクションは暗号の廃棄と呼ばれます。 デプロイメントで使用中の鍵を削除すると、データが含まれているディスクがロックされ、そのデプロイメントが無効化されます。 UI や、UI、CLI、API のセキュリティー設定などの一部のメタデータには引き続きアクセスできますが、データベースやそこに含まれているデータにはアクセスできません。 キーの削除は 、 Activity Tracker Event Routing に として送信されます kms.secrets.delete。

バックアップ用のBring your own key

Key Protect を使用する場合、データベースをプロビジョニングする際に、デプロイメントのバックアップを格納する IBM® Cloud Block Storage for Virtual Private Cloud ディスクを暗号化するためのキーを指定することもできます。

バックアップは、データベースと同じ暗号化キーを引き継ぎます。 データベースからバックアップを作成する際、別の暗号化キーを指定することはできません。

委任許可の付与

デプロイメントで Key Protect キーを使用できるようにするには、サービスの承認を付与する際に「 承認の委任を有効にする 」設定を行う必要があります。 鍵を使用してデプロイメントをプロビジョンする前に委任許可が存在していない場合は、プロビジョンが失敗します。

委任を有効にしてデプロイメントをプロビジョンすると、IAM の_許可_に 2 つのエントリーが表示されます。 その 1 つは、委任者として状況をリストするデプロイメントに関するエントリーです。 このエントリーは「作成したユーザー (User Created)」です。

デリゲーターの例: Key Protect 認証
役割 ソース ターゲット タイプ
許可委任者、リーダー <cloud-databases>サービス Key Protect サービス ユーザー定義

また、サービスインスタンスとそのバックアップ(存在する場合)に関する「 Block Storage for VPC 」ボリュームについても、デプロイメントがイニシエーターとなります。

Cloud Databases からの Cloud Object Storage に対する Key Protect 認証の例
役割 ソース ターゲット タイプ
リーダー Block Storage for VPC サービス Key Protect サービス 作成者<cloud-databases-crn>

鍵の削除

IAM/ Key Protect によって、キーと Block Storage for VPC の間のポリシーを削除すること自体は妨げられませんが(2番目の例)、そうするとトピックやパーティションを復元できなくなる可能性があります。

Hyper Protect Crypto Services (HPCS)の使用

承認済みの Cloud Databases Gen 2 展開については、 Key Protect の代わりに Hyper Protect Crypto Services を使用できます。 この統合は、このページに記載されている標準的な BYOK プロセスに従いますが、以下の点が異なります:

  1. IAM 認証における対象サービス:

    サービスの承認を行う際は、対象サービスとして Hyper Protect Crypto Services (または CLI/API では hs-crypto )を選択してください kms。 読者の役割を維持し、 権限の委譲を有効にする (AuthorizationDelegator)が選択されていることを確認してください。

  2. プロビジョニングにおける主要なCRN:

    プロビジョニング・ペイロードには、 Hyper Protect Crypto Services の完全なルートキーCRN(の代わりに crn:v1:bluemix:public:hs-crypto:... で始まるもの kms)を指定してください:

    • CLI / API: パラメータ dataservices.encryption.disk を使用して CRN を渡します:

      "dataservices": {
        "encryption": {
          "disk": "crn:v1:bluemix:public:hs-crypto:<REGION>:a/<ACCOUNT-ID>:<HPCS-INSTANCE-ID>:key:<KEY-ID>"
        }
      }
      
    • Terraform (ibm_database): Hyper Protect Crypto Services キーの CRN を 引数 key_protect_key に渡します:

      key_protect_key = "crn:v1:bluemix:public:hs-crypto:<REGION>:a/<ACCOUNT-ID>:<HPCS-INSTANCE-ID>:key:<KEY-ID>"
      

デプロイメントのバックアップは、ストレージの委任を通じて、自動的に同じ Hyper Protect Crypto Services キーを継承します。 リージョン間の独立したバックアップコピー(CRC)については、バックアップコピーのペイ dataservices.encryption.disk ロード内で、別の宛先キー CRN をオプションで指定することができます。

よくある落とし穴

キーと許可を削除する場合は注意してください。 同じキーを使用するデプロイメントが複数ある場合、委任認証を取り消すことで、それらのデプロイメントすべてのデータを意図せず破棄してしまう可能性があります。 可能であれば、複数のデプロイメントで同じキーを使用しないでください。

インスタンスに関連付けられたデータを完全に消去したい場合は、キーを削除してください。 Block Storage for VPC を実行することで、ストレージが読み取り・書き込み不可の状態になります。 ただし、その同じ鍵を使用している他のデプロイ(またはそのバックアップ)では、その後エラーが発生することになります。

複数のデプロイやバックアップで同じキーを使用する必要がある場合、キーや承認を削除すると、次のような副作用が生じる可能性があります。 (表2に示されているように) Block Storage for VPC のボリューム認証情報を削除すると、作成者として表示されているデプロイメントだけでなく、同じキーを使用している他のすべてのデプロイメントにも影響が及びます。 サポートチケットを開いてポリシーの再作成を依頼するまでは、それらのデプロイではエラーが発生し続けます。

鍵を再利用する場合には注意してください。