IBM Cloud Docs
Secrets Manager でのデータの保護

Secrets Manager でのデータの保護

IBM Cloud® Secrets Manager の使用時に安全にデータを管理できるようにするには、保管および暗号化されたデータ内容と、そのデータを削除する方法を正確に把握しておくことが重要です。 カスタマー・マネージド・キーを使用したデータ暗号化は、Key Protect または Hyper Protect Crypto Services との統合によってサポートされます。

Secrets Manager でのデータの保管方法および暗号化方法

Secrets Manager を操作すると、さまざまなタイプのシークレットに関する操作を処理するために、サービスが HashiCorp Vault と通信します。 設計上、バックエンドに対して行われるすべての要求には、Vault はセキュリティーバリアを使用します。 Vault からのデータは、Galois Counter Mode (GCM) で 256 ビットの Advanced Encryption Standard (AES) 暗号を使用し、96 ビットのナンスで自動的に暗号化されます。

Secrets Manager 保存中のすべての秘密を 封筒暗号化データ暗号鍵を使用してデータを暗号化し、完全に管理可能なルート・キーを使用して鍵を暗号化するプロセス。で暗号化します。 暗号化されたシークレットは、インスタンス固有の専用 Cloud Object Storage バケットに保管されます。 保管されたシークレットを保護するために、Secrets Manager は、Key Protect や Hyper Protect Crypto Services などのキー管理サービスと統合されています。 すべてのシークレットの各バージョンは、 ルート キーデータ・サービスに保管されている他の鍵の暗号化および暗号化解除に使用される対称ラップ鍵。 によって保護されているデータ暗号化キー (DEK) によって暗号化されます。このルート キーは Secrets Manager によって Vault へのアクセスの封印と封印解除に 使用されます。 この統合では、FIPS認証済みの ハードウェアセキュリティモジュールオンデマンド暗号化、キー管理、およびキー・ストレージをマネージド・サービスとして提供する物理アプライアンス。に根ざした暗号化キーを使用することで、お客様の機密情報を保護します。 資格情報は、サービスによって保管されている間は平文になることはありません。

Secrets Manager は、以下のセキュリティー・メカニズムを使用して、転送中のデータを保護します。

  • TLS 1.2+ (エンドツーエンド通信)
  • mTLS (内部通信)
  • Web App Firewall および DDoS 保護
  • Ingress および Egress ネットワーク・ルール (専用インスタンスの分離)

Secrets Manager での機密データの保護

鍵管理サービスとの統合を有効にすることによって、保存されたデータに、より高いレベルの暗号化制御を追加できます。

IBM Cloud に保管するデータは、保存時にはエンベロープ暗号化を使用して暗号化されます。 暗号鍵を自分で制御する必要がある場合には、鍵管理サービスを統合できます。 これらのプロセスは通常、Bring Your Own Key (BYOK) または Keep Your Own Keys (KYOK) と呼ばれます。 鍵管理サービスを使用すると、暗号鍵を作成、インポート、および管理できます。 アクセス・ポリシーを鍵に割り当てたり、ユーザーまたはサービス ID を鍵に割り当てたり、鍵へのアクセスを特定のサービスに対してのみ付与したりできます。

以下の表で、Secrets Manager データの暗号化を管理するためのオプションについて説明します。

Secrets Managerの暗号化オプション。
暗号化 説明
プロバイダー・マネージド型の暗号化 Secrets Manager に保管するデータは、IBM マネージド・キーを使用して暗号化されます。 暗号鍵は Key Protect に保管されます。 この設定はデフォルトです。
お客様管理の暗号化 Secrets Manager に保管されているデータは、ユーザーが所有、管理する暗号化キーを使用して、保管中に暗号化されます。 Key Protect または Hyper Protect Crypto Services で管理するルート・キーを使用します。

カスタマー・マネージド・キーについて

Secrets Manager はエンベロープ暗号化を使用して、カスタマー・マネージド・キーを運用します。 エンベロープ暗号化とは、ある暗号鍵を別の暗号鍵で暗号化することです。 実際のデータを暗号化するために使用される鍵は 、データ暗号鍵(DEK)アプリケーションに保管されているデータを暗号化するために使用される暗号鍵。 と呼ばれます。 DEK そのものが保管されることはなく、DEK が鍵暗号鍵 (KEK) と呼ばれるもう 1 つの鍵によってラップされ、ラップされた DEK が作成されます。 データを復号するには、ラップされた DEK をアンラップして DEK を取得します。 このプロセスは KEK (この場合は、鍵管理サービスに保管されているお客様のルート鍵) にアクセスすることによってのみ実行できます。

Key Protectでサポートされている Bring Your Own Key プロセス (BYOK) を使用して、 Secrets Manager に保管するデータを暗号化できます。 このマルチテナントサービスでは、オンプレミスのハードウェアセキュリティモジュール(HSM)から暗号化キーをインポートし、そのキーを管理することができます。 マスター鍵を含む鍵階層全体を排他的に制御したい場合は、 Hyper Protect Crypto Servicesでサポートされている Keep Your Own Key (KYOK) プロセスを使用できます。 KYOK では、BYOK 機能に加えて、 IBM でも鍵にアクセスできないという技術的な保証があります。 詳細はこちらをご覧ください

組織のニーズに最も適した鍵管理サービスは、ユース・ケースやセキュリティー要件に応じて異なります。 キー管理ソリューションについて詳しくは、Hyper Protect Crypto Services と Key Protect の違いを参照してください。

Secrets Manager のカスタマー・マネージド・キーの有効化

ユーザーが管理するキーを使用して作業することを選択した場合は、使用している Secrets Manager のインスタンスに必ず有効な IAM 許可が割り当てられているようにします。 その許可を作成するには、以下の手順を使用します。

  1. Key Protect または Hyper Protect Crypto Services のインスタンスを作成します。

  2. ユーザーのキー管理サービス・インスタンスに、ルート・キーの生成またはインポートを行います。

    Key Protect または Hyper Protect Crypto Services を使用してルート・キーを作成すると、サービスがクラウド・ベースの HSM にルート設定された暗号キー・マテリアルを生成します。 鍵の名前に、自分の名前やロケーションなどの個人情報が含まれていないことを確認してください。

  3. Key Protect または Hyper Protect Crypto Services にサービス・アクセス権限を付与します。

    アカウント所有者か、使用している鍵管理サービスのインスタンスの管理者が、これを行う必要があります。 また、Secrets Manager サービスに対して最低でもビューアー・アクセス権限も持っている必要があります。

    1. **「管理」 > 「IAM へのアクセス」 > 「権限」**に移動します。
    2. ソースアカウントを選択します
      • このアカウントで Secrets Manager インスタンスをプロビジョニングする予定の場合は、[このアカウント] を選択します。
      • 特定のアカウントを選択し、 Secrets Manager インスタンスをプロビジョニングするソースアカウントのIDを入力してください。
    3. Key Protect または Hyper Protect Crypto Services の特定のインスタンスで、お客様のルートキーが含まれているものを対象サービスとして選択します。
    4. 権限をスコープする:
      • キーホルダー 内のすべてのキー - 「条件を追加」 をクリックし 、「キーホルダーID」 を選択して、キーホルダーのIDを入力します。
      • 特定の暗号化キー - 「条件を追加」 をクリックし 、「リソースタイプ」 を選択し、値のキー を入力します。 次に 、「条件を追加」 をクリックし 、「リソースID」 を選択して、暗号化キーのIDを入力します。
    5. リーダーの役割を割り当てます。
    6. 「許可」 をクリックして、許可を確認します。

    Hyper Protect Crypto Services を使用している場合は、 Hyper Protect Crypto Services インスタンスに Viewer プラットフォームのアクセスポリシーを割り当てる 2 つ目の IAM 認証を追加します。

    1. **「管理」 > 「IAM へのアクセス」 > 「権限」**に移動します。
    2. ソース・サービスに、Secrets Manager サービスを選択します。
    3. 特定のインスタンス Hyper Protect Crypto Services をターゲットサービスとして選択し、その中にルートキーを含めます。
    4. ビューアーの役割を割り当てます。
    5. 「許可」 をクリックして、許可を確認します。

    後で Secrets Manager インスタンスの削除を選択すると、この許可も IAM によって削除されます。

  4. 事前に承認したルートキーを使用して 、 Secrets Manager インスタンスを作成します

Secrets Manager でのデータの削除

Secrets Manager のインスタンスを削除すると、それに関連付けられているすべてのユーザーデータも削除されます。 サービス・インスタンスを削除すると、7 日間の再利用期間が開始します。 その期間中は、インスタンスおよび関連付けられているすべてのユーザー・データを復元できます。 ただし、インスタンスおよびデータが完全に削除されている場合は、リストアできなくなります。Secrets Manager は、完全に削除されたインスタンスからのデータは保管しません。

新しい料金プランのリリースの一環としてインスタンスが自動的に削除された場合は、レクラメーション・プロセスを使用して復元できます。 リストア後、1 時間以内にプランをアップグレードする必要があります。そうしないと、プランは再度削除されます。

Secrets Manager データ保存ポリシーは、サービスを削除した後にデータが保管される期間を記述します。 Secrets Manager サービス詳細に記述されたデータ保存ポリシーについては、IBM Cloud の用語と特記事項を参照してください。

Secrets Manager インスタンスの削除

Secrets Manager のインスタンスが不要になったら、サービス・インスタンスおよび保管されているデータを削除できます。 インスタンスは無効状態になり、7 日後にそのデータが永久に削除されます。 また、コンソールを使用してサービス・インスタンスを削除することもできます。

7 日間のレクラメーション期間中は、Secrets Manager とさまざまな統合サービス (Key Protectなど) 間の許可を削除しないでください。Secrets Manager は、当該サービスの関連リソースからインスタンスを登録抹消するための許可を使用します。 インスタンスが完全に削除されたら、IAM によって許可も削除されます。

  1. サービスを削除して、7 日間の再利用期間を適用します。

    ibmcloud resource service-instance-delete "<instance_name>"
    

    <instance_name>を、削除したいSecrets Managerインスタンスの名前に置換します。

  2. オプション: インスタンスを永久に削除するために、再利用 ID を取得します。

    ibmcloud resource reclamations --resource-instance-id <instance_ID>
    

    <instance_ID>をSecrets ManagerインスタンスIDに置き換えます。

    再利用インスタンスを削除してインスタンスを永久に削除すると、データは復元できなくなります。

  3. オプション: 再利用インスタンスを永久に削除します。

    ibmcloud resource reclamation-delete <reclamation_ID>
    

    <reclamation_ID>を、前のステップで取得した値に置き換えます。

削除されたサービス・インスタンスのリストア

インスタンスを永久に削除していない場合は、7 日間の再利用期間内に復元することができます。

  1. 復元可能なサービス・インスタンスを表示します。

    ibmcloud resource reclamations
    

    使用可能なインスタンスのリストから、リストアしたい Secrets Manager インスタンスのレクラメーション ID をコピーします。

  2. 復元して再利用します。

    ibmcloud resource reclamation-restore <reclamation_ID>
    

    <reclamation_ID>を、前のステップで取得した値に置き換えます。