顧客管理のキー

Test Cloud と Test Cloud (公共部門向け) の顧客管理のキー

この手順は、Test Cloud および Test Cloud (公共部門向け) にのみ適用されます

ライセンス プランに応じて、この機能は以下のような方法で利用できます。

• フレックス ライセンス: Standard および Advanced のプラットフォーム プランで利用できます。
• ユニファイド プライシング ライセンス: Enterprise プラットフォーム プランでのみ利用可能です。
  警告:

  この機能を有効化すると、データ アクセスに深刻な影響があります。重要な問題が発生した場合は、データへのアクセスを失う危険性があります。

下表には、問題のある一般的なシナリオとその解決策が記載されています。

シナリオ	解決策
Azure Key Vault (AKV) にアクセスするための資格情報が期限切れか、削除されている。	まだメール アドレスとパスワードを使用してログインできる (非 SSO) 場合、以下を実行します。 組織管理者である場合は、組織の [管理] ページの [暗号化] セクションで資格情報を更新できます。 組織管理者ではない場合は、サポート チケットを使用して管理者ロールへの昇格を依頼できます。その後、組織の [管理] ページの [暗号化] セクションで資格情報を更新できます。 ログインできなくなった場合は、サポート チケットを使用して組織 ID を提供していただくと、UiPath の方で招待して管理者として昇格させることができます。その後、組織の [管理] ページの [暗号化] セクションで資格情報を更新できます。 ログイン アクセスを回復したら、新しい AKV キーと資格情報セットを作成してから、この新しい情報を使用して顧客管理のキーを設定し、他の誰も資格情報にアクセスできないようにすることをお勧めします。
AKV キーの有効期限が切れている。	顧客管理のキーは引き続き機能しますが、新しいキーに切り替えることをお勧めします。
AKV キーが削除された。	保持期間中に Azure Portal から AKV キーを復元できます。
AKV キーがパージされたが、バックアップがある。	Azure Portal のバックアップからキーを復元できます。既定では、復元したキーは元のキーと同じ ID になります。これは変更しないでください。
AKV キーがパージされ、バックアップがなかった。	警告: このシナリオを解決する方法はありません。この状況では、UiPath® の顧客データが失われます。

概要

ストレージ レベルの標準の TDE に加えて、一部のサービスでは、暗黙的なアプリケーション レベルの暗号化 (ALE) も採用されています。つまり、データは保存される前にアプリケーション層で暗号化され、セキュリティがより一層向上します。

さらに、一部のサービス/リソースでは、任意のユーザー主導の暗号化が提供されます。これはオプショナル (オプトイン) ALE と呼ばれます。これにより、サービス/リソースで ALE を採用するかどうかを選択して決定できます。サービスやリソースのリストと、それらに関連する暗号化の種類については、暗号化対象のデータについてまとめたこちらのページをご覧ください。

ALE を使用するサービスでは、暗黙的な場合でも機能を有効化した場合でも、暗号化キーを扱うユーザーを選択できます。これは、UiPath またはユーザー自身が管理できます。これを支援するために、 Azure Key Vault ではシークレットのバージョン管理がサポートされており、組織レベルでキーを設定するときに使用するシークレットを生成できます。

顧客管理のキーを有効化すると、以前にバックアップ済みのデータは再暗号化されず、既存のバックアップは有効期限が切れると削除されます。このオプションを使用して暗号化されるのは、新しいデータのみです。

顧客管理のキーの説明

顧客管理のキーのアーキテクチャでは、UiPath の製品またはプラットフォーム サービス (UiPath Orchestrator、UiPath Identity Service など) は通常、機密の顧客データを保存する前に暗号化します。データ アクセスが必要な場合、UiPath の製品またはサービスは、キー管理インフラストラクチャを呼び出して復号キーを取得します。これにより、キーを返すことをユーザーが拒否できるため、UiPath 内の暗号化データを制御できます。

このプロセスには、次のコンポーネントが関係します。

• キー管理サービス (KMS) - キーの暗号化を目的として開発された UiPath の内部ツールです。
• データ暗号化キー (DEK または KMS DEK) - プレーン テキスト データの暗号化に使用されます。一般的に、DEK は KMS または UiPath の内部キー コンテナーによって生成され、どこにもクリア テキストで保存されません。
• キー暗号化キー (KEK) - DEK の暗号化に使用されます。キーを暗号化するプロセスをキー ラッピングと呼びます。一般的に、KEK はユーザーが生成して自身のキー コンテナーに保存します。KEK は、ユーザーのキー管理サービスで管理される実際の顧客管理のキーとなります。
• 暗号化されたデータ暗号化キー (EDEK) - KEK によってラップされる DEK です。一般的に、このキーはサービス プロバイダー (Orchestrator など) によって保存されます。したがって、暗号化されたデータにアクセスする必要がある場合、サービスは常に顧客のキー管理サービスを呼び出し、EDEK の復号に必要な KEK を取得して DEK を生成し、その DEK を使用してデータを復号します。
• UiPath 内部キー - CMK や KMS DEK などのデータ列を暗号化するために使用されます。

次の図は、顧客管理のキーを有効化する際に関係するさまざまなコンポーネントがどのように連携するかを示しています。

顧客管理のキーを有効化する

注:

利用可能な機能は、使用するクラウド プラットフォームによって異なります。詳しくは、「 機能の提供状況」をご覧ください。

重要:

顧客管理のキー (CMK) を有効化すると、データのアクセシビリティに大きな影響を与えます。キーが利用できなくなったり、設定に誤りがあったりすると、データにアクセスできなくなる可能性があります。キーを紛失すると、コンテナーに接続できなくなります。したがって、組織のセキュリティ ポリシーに従って、常に Azure Portal または Azure とは別のセキュリティで保護されたキー コンテナーにキーのバックアップを作成する必要があります。クラウド プラットフォームによっては、クラウド境界の要件に準拠するために、Azure Key Vault を Microsoft Azure Government クラウドでホストする必要があります。

顧客管理のキーを有効化するには、Test Cloud を表す Microsoft Entra ID アプリケーションが Azure Key Vault 内のキー暗号化キーにアクセスできるように設定する必要があります。

クラウド プラットフォームに応じて、Microsoft Entra ID アプリケーションを構成する方法として以下のいずれかの方法を選択できます。

• (推奨) 自動セットアップ: UiPath で管理される Microsoft Entra ID アプリケーション (マルチテナント モデル) を使用すると、次のようなメリットがあります。
  • 管理すべきシークレットや証明書はありません。
  • 迅速かつ確実にセットアップできます。
  • UiPath が Microsoft Entra ID アプリケーションを管理します。
• カスタム Microsoft Entra ID アプリケーションの登録による手動セットアップ: 独自の Microsoft Entra ID アプリケーションを使用し、その構成を手動で管理します。以下の点にご注意ください。
  • アプリケーションの資格情報を作成および管理する必要があります。
  • 資格情報には有効期限があるため、定期的な更新が必要です。
  • 有効期限が切れる前に資格情報が更新されない場合、ユーザーはサインインできません。

UiPath で管理される Microsoft Entra ID アプリケーションを使用した自動セットアップ (推奨)

設定を簡素化し、シークレットや証明書の管理を避けたい場合は、この方法を使用します。UiPath では、ほとんどの組織にこのアプローチを推奨しています。

Microsoft Entra ID および組織管理者である場合

Microsoft Entra ID 管理者と組織管理者の両方である場合は、以下の手順に従い、UiPath で管理されるマルチテナント アプリケーションを使用して連携を設定します。

1. 組織で、[ 管理] > [セキュリティ>暗号化] に移動します。
2. [顧客管理のキー] を選択し、確認ダイアログに組織名を入力して選択を確定します。
3. [UiPath で管理されるマルチテナント アプリケーション (推奨)] を選択します。
4. [ 同意を与える] を選択し、Microsoft Entra ID アカウントでサインインします。同意すると、UiPath は、組織を代表する Microsoft Entra ID アプリケーションを Azure に作成します。
5. キー暗号化キーを作成し、Azure Key Vault を設定します。
6. キー暗号化キーの Azure Key Vault キーの URI を入力します。
   • バージョンレス キーの URI を指定すると、最新のキー バージョンが自動的に使用されます (キー ローテーションが有効)。
   • バージョン管理されたキーの URI を指定すると、その特定のキー バージョンを持つすべてのデータが UiPath によって暗号化されます。
7. [テストして保存] を選択して、連携をアクティブ化します。 エラーが発生した場合は、資格情報を確認してもう一度お試しください。

組織管理者の場合のみ

Microsoft Entra ID の管理者権限はなくても、組織管理者である場合は、以下の手順を実行して管理者の同意をリクエストし、連携を完了します。

1. 組織で、[ 管理] > [セキュリティ>暗号化] に移動します。
2. [顧客管理のキー] を選択し、確認ダイアログに組織名を入力して選択を確定します。
3. [UiPath で管理されるマルチテナント アプリケーション (推奨)] を選択します。
4. [同意する] を選択し、Microsoft Entra ID アカウントでサインインします。 Microsoft Entra ID の管理者権限がないため、次のいずれかのプロンプトが表示されます。
   1. [承認をリクエスト] (Microsoft のドキュメント「管理者の承認を要求する」を参照)。Microsoft Entra ID 管理者がリクエストを承認したら、次の手順に進みます。
   2. Microsoft のドキュメントに記載されているように、管理者の承認が必要です。次の手順を実行するよう、Microsoft Entra ID 管理者に依頼してください。
      1. この URL に移動して、Microsoft Entra ID の同意プロンプトを開きます。
      2. [組織の代表として同意] を選択してから [承諾] を選択します。
5. 管理者の同意が得られたという確認を受け取ったら、暗号化キーを作成して Azure Key Vault を設定した後、UiPath に戻り、手順 1 から 4 を繰り返します。
   • サインインに成功すれば、連携は正しく設定されています。
   • サインインに失敗した場合は、Microsoft Entra ID 管理者に問い合わせて、同意が正しく付与されたことを確認してもらってください。
6. キー暗号化キーの Azure Key Vault キーの URI を入力します。
   • バージョンレス キーの URI を指定すると、自動キー ローテーションが有効化され、Test Cloud では最新のキー バージョンが使用されます。
   • バージョン管理されたキーの URI を指定すると、Test Cloud はその特定のキー バージョンを持つすべてのデータが暗号化されます。
7. [テストして保存] を選択して、連携をアクティブ化します。 エラーが発生した場合は、資格情報を確認してもう一度お試しください。

カスタム Microsoft Entra ID アプリケーションの登録による手動セットアップ

UiPath で管理されるマルチテナント アプリケーションを使用する代わりに、独自の Microsoft Entra ID アプリケーションを設定する場合は、次の手順を実行します。このオプションでは、自身の資格情報を管理し、長期にわたって保持する必要があります。

重要:

手動設定で作成された資格情報は、定期的に期限切れになります。サービスの中断を避けるため、有効期限が切れる前に更新する必要があります。この運用オーバーヘッドを削減するには、 UiPath で管理される Entra ID アプリケーションを使用した自動セットアップの使用を検討してください。

1. Microsoft Entra ID アプリの登録を作成します。

   1. Microsoft Entra 管理センターで、[アプリの登録] > [新規登録] に移動します。
   2. 任意の名前を入力します。
   3. [サポートされているアカウントの種類] を [この組織ディレクトリのみに含まれるアカウント] に設定します。
   4. 登録を完了します。

2. 資格情報を作成します。

   アプリの登録の [証明書とシークレット] に移動し、以下のいずれかの方法を選択します。

   • クライアント シークレットを使用するには、以下の手順を実行します。
     1. [新しいクライアント シークレット] を選択します。
     2. 生成されたシークレット値を保存します。これは後で必要になります。
   • 証明書を使用するには、以下の手順を実行します。
     1. 新しいブラウザー タブで、Azure Key Vault に移動します。
     2. 証明書を作成します。
        • サブジェクト: CN=uipath.com
        • コンテンツの種類: PEM
        • 最大サイズ: 10 KB 未満
     3. 証明書を .pem 形式でダウンロードします。
     4. テキスト エディターで .pem ファイルを開きます。このファイルには次のセクションがあります。
        • -----BEGIN PRIVATE KEY----- / -----END PRIVATE KEY-----
        • -----BEGIN CERTIFICATE----- / -----END CERTIFICATE-----
     5. BEGIN CERTIFICATE と END CERTIFICATE の間の行のみを含む新しい .pem ファイルを作成します。
     6. アプリ登録の [Certificates & secrets ] セクションで、この新しい .pem ファイルをアップロードします。
     7. 証明書のコピーを保管します。これは、後で連携を完了するために必要になります。
     重要:

     ほとんどの資格情報の種類は最終的に期限切れになります。ユーザー サインインの問題を回避するには、資格情報の有効期限が切れる前に設定を更新してください。このオーバーヘッドを回避するには、 UiPath で管理される Microsoft Entra ID アプリケーションによる自動セットアップを使用します。

3. 連携の詳細情報を収集します。

   次の値を収集し、組織管理者に提供します。

   • アプリケーション (クライアント) ID
   • ディレクトリ (テナント) ID
   • クライアント シークレットまたは証明書

4. キー暗号化キーを作成し、Azure Key Vault を設定します。

   暗号化キーを準備して、Azure Key Vault のキー識別子をメモします。次のいずれかの形式を選択します。

   • バージョンレス キーの URI: キーの自動ローテーションを有効化します。UiPath は常に最新のキー バージョンを使用します。
   • バージョン管理されたキーの URI: 暗号化を特定のキー バージョンにロックします。UiPath は、そのバージョンを使用してすべてのデータを暗号化します。

5. 組織内で連携をアクティブ化します。

   1. UiPath に管理者としてサインインします。
   2. [管理] > [セキュリティ] > [暗号化] に移動します。
   3. [顧客管理のキー] を選択し、組織名を入力して選択を確定します。
   4. [カスタム アプリケーションの登録 ID とシークレット] を選択します。
   5. 先ほど収集した次の詳細情報を入力します。
      • ディレクトリ (テナント) ID
      • アプリケーション (クライアント) ID
      • クライアント シークレットまたは証明書
      • Azure Key Vault のキー識別子
   6. [テストして保存] を選択して、連携をアクティブ化します。

エラー メッセージが表示された場合は、資格情報を確認してもう一度お試しください。

キー暗号化キーを作成し、Azure Key Vault を設定する

開始する前に、Test Cloud で Azure Key Vault を使用するための以下の要件と推奨事項を確認してください。

• Key Vault は任意のリージョンで作成できますが、Test Cloud 組織と同じリージョンを使用することをお勧めします。
• UiPath では、顧客管理のキーに使用されるキー コンテナーにアクセスする必要があります。範囲を制限するには、この目的専用のコンテナーを作成することをお勧めします。
• この機能は、Azure Key Vault でサポートされている任意のキー サイズで動作します。
• 暗号化操作を実行するには、キーを折り返すとキーの折り返しを解除の権限を付与する必要があります。これらの権限は、Azure RBAC (ロールベースのアクセス制御) またはキー コンテナー アクセス ポリシーのどちらを使用してアクセスを管理するかに関係なく必要です。

キー暗号化キーを作成し、Azure Key Vault を設定するには、次の手順を実行します。

1. Microsoft Azure Portal で Azure Key Vault に移動し、既存のコンテナーを選択するか、新しいコンテナーを作成します。

2. 新しいキーを作成し、キーの URI をコピーします。Test Cloud で設定する URI が必要です。

   キーの URI として以下のいずれかのオプションを選択します。

   • バージョンレス キー URI: キーの自動ローテーションを有効化します。Test Cloud では常に最新バージョンのキーが使用されます。
   • バージョン管理されたキー URI: 暗号化を特定キー バージョンにロックします。Test Cloud では、そのバージョンを使用してすべてのデータが暗号化されます。

3. 前に作成した Microsoft Entra ID アプリケーションへのアクセス権を付与します。

   Azure RBAC またはキー コンテナー アクセス ポリシーを使用して、必要な権限を付与します。

4. Test Cloud に戻り、設定を完了します。

顧客管理のキーを編集する

このオプションを有効化すると、接続に関連する詳細を編集することもできるようになります。そのためには、[顧客管理のキー] オプションの [接続を編集] を選択し、必要に応じて任意の情報を変更します。

キーのローテーション

キーを定期的にローテーションし、暗号化されたデータを潜在的な侵害から継続的に保護することをお勧めします。

手動キーローテーション

手動キー ローテーションでは、CMK 構成自体を変更する必要があります。構成全体を変更することもできますが、重大な変更を最小限に抑えるために、キー識別子またはキーのバージョンのみを変更することをお勧めします。

キーの手動ローテーションを実行するには、次の手順を実行します。

1. 前に設定した Azure Key Vault 内に新しいキーを作成します。
2. 組織で [ 管理 ] > [セキュリティ] に移動します。
3. [顧客管理のキー] で [接続を編集] を選択します。
4. 既存のキー識別子を新しいキーの URI に置き換えます。
   注:

   キー ローテーションは、古いキーと新しいキーの両方が有効な場合にのみ機能します。

キーの自動ローテーション

キーの自動ローテーションにより、UiPath は Azure Key Vault で定義されたローテーション ポリシーに基づいて、最新バージョンのキーを自動的に使用できます。このアプローチにより、手作業が減り、セキュリティが向上します。

キーの自動ローテーション プロセスを有効化するには、次の手順を実行します。

1. Azure Key Vault で、キーのローテーション ポリシーを作成します。
2. 組織で [ 顧客管理のキー の設定] に移動し、 バージョンレス キーの識別子を指定します。設定手順については、「 顧客管理のキーを有効化する」をご覧ください。
3. Azure Key Vault でキーがローテーションされるたびに、UiPath は最新のキー バージョンを自動的に取得して適用します。UiPath は、新しいキーのバージョンを 1 時間ごとに自動的にチェックします。新しいバージョンが利用可能になると、手動で更新することなく取得されて適用されます。
   重要:

   • 古いキー バージョンのアクセス権限を無効化または変更しないでください。ローテーション プロセス中に暗号化されたデータへのアクセスが中断されないようにするには、以前のキー バージョンと現在のキー バージョンの両方にアクセス可能な状態を維持する必要があります。
   • 顧客管理のキー設定の手動変更 (キー識別子の更新など) とキーの自動ローテーション イベントは、どちらも組織の [管理] の [監査ログ] セクションで確認できます。

ライセンスのダウングレード

Enterprise プランの有効期限が切れると、クラウド プラットフォームによっては、自動的に Free プランにダウングレードされるか、表示専用ステートにダウングレードされます。データ暗号化に関しては、以下のような期待を込めておきましょう。

• [顧客管理のキー] オプションは依然として有効化されていますが、インターフェイスで灰色表示になります。このため、Key Vault の詳細の変更など、値の編集はできなくなります。
• [UiPath で管理されるキー (既定)] に切り替えることはできますが、プランを Enterprise にアップグレードするまで [顧客管理のキー] に戻すことができなくなります。

顧客管理のキーを使用するためのベスト プラクティス

顧客管理のキーの使用を開始する前に、留意すべき重要な詳細事項がいくつかあります。

• キー ローテーション プロセスの一環として新しいキーの使用を開始すると、古いキーを使用してデータにアクセスしたり暗号化したりできなくなります。したがって、古いキーをキー コンテナー内に保持すること、つまり古いキーを削除するのではなく無効化することが重要です。これは特に障害復旧のシナリオで重要になります。この場合、UiPath はデータベースの古いバージョンのバックアップに戻さなければならないことがあります。そのバックアップで古いキーのいずれかが使用されていれば、そのキーにローテーションしてデータ アクセスを回復できます。 キーを削除する場合は、論理的な削除機能を使用することが重要です。

• キーを失うと、コンテナーに接続できなくなります。したがって、必ず、組織のセキュリティ ポリシーに従って Azure Portal 上、または Azure とは別のセキュリティで保護されたキー コンテナー内にキーのバックアップを作成する必要があります。

• シングル サインオンを利用して UiPath のサービスにアクセスしている場合は、緊急アクセス用 (Break Glass) アカウントとして機能するローカル アカウントを作成することを検討できます。外部 ID プロバイダーの情報は、顧客管理のキーで暗号化されたデータに含まれているため、キー コンテナーにアクセスできないと SSO アカウントがアクセス不能になります。

• セキュリティ上の理由から、最上位レベルの管理者権限を持たないユーザーには顧客管理のキーに対するパージ権限を付与しないようにする必要があります。

• UiPath がデータにアクセスできないようにする場合、次の図に示すように Azure Key Vault からキーを無効化できます。

  

詳しくは、Azure Key Vault の 回復操作について説明されたこちらのページをご覧ください。

Test Cloud (専有型) の顧客管理のキー

独自の暗号化キーを使用して、Test Cloud (専有型) 環境の UiPath で管理される Azure リソースに格納されるデータを保護できます。これにより、キーのローテーション、アクセス権限、コンプライアンス要件を完全に制御できます。

UiPath は、クロステナントの顧客管理のキー (CMK) の構成をサポートしています。キーはユーザー独自の Azure Key Vault に存在し、暗号化されたリソースは UiPath のテナントに残ります。

警告:

顧客管理のキーを有効化すると、UiPath による暗号化されたデータへのアクセス方法が変わります。キーまたはそのアクセス設定が利用できなくなると、データにアクセスできなくなる可能性があります。

サポートされるリソース

顧客管理のキーを使用して、UiPath で管理される以下のリソースを暗号化できます。

• Azure Storage アカウント
• Azure SQL Server
• Azure Disk
• Snowflake
  注:

  Azure Databricks と Azure Event Hubs では、クロステナントのカスタマー マネージド キー (CMK) はサポートされていません。これらのサービスでは、Key Vault が関連する Azure リソースと同じ Microsoft Entra テナントに存在する必要があるため、クロステナント CMK を使用して暗号化することはできません。これらのサービスは、テレメトリと分析の処理をサポートするために Insights によって内部的に使用されます。

  • Azure Event Hubs: ロボット ログや実行イベント、ジョブ実行データ、キュー アイテム イベント、リアルタイムの監視などのストリーミング テレメトリをバッファーします。Event Hubs のデータは一時的なものであり、長期的には保存されません。
  • Azure Databricks: リアルタイムの監視データ、履歴の集計、処理されたロボット実行のメトリックなどの分析データを処理および保存します。これらのサービスは、保存時の暗号化に Microsoft マネージド キーを使用し、顧客管理のキーで構成することはできません。

アーキテクチャ

専用環境で顧客管理のキーを有効化すると、UiPath ではフェデレーション ID を使用したクロステナント暗号化モデルが使用されます。これにより、データが UiPath で管理される Azure サービスに格納されている場合でも、暗号化キーはユーザーによって完全に制御されたままです。

このアーキテクチャは、CMK とフェデレーション ID を使用して保存データをセキュリティで保護するための Azure パターンに基づいています。

この機能のアーキテクチャの主要なコンポーネントは次のとおりです。

1. UiPath テナント: 暗号化が必要な Azure リソースをホストします。

2. テナント: Azure Key Vault と顧客管理のキーをホストします。

3. マルチテナント アプリケーション: UiPath によって登録され、テナントにインストールされます。これにより、セキュリティで保護されたクロステナント アクセスが可能になります。

4. マネージド ID: UiPath アプリに割り当てられ、Key Vault に対する認証に使用されます。

5. フェデレーション資格情報: UiPath アプリがシークレットを格納せずにマネージド ID を使用できるようにします。

6. Azure Key Vault: 顧客管理のキーを格納します。

   暗号化フローは次のとおりです。

7. サポート チケットを提出して、アプリケーションの登録 ID と名前を受け取ります。

8. UiPath は、マルチテナント アプリケーションを登録し、ユーザー割り当てマネージド ID をアタッチします。

9. アプリケーションを Azure テナントにインストールします。

10. Key Vault でキーを作成し、キーの URI (バージョンを含む) を UiPath と共有します。

11. Azure RBAC を使用して、 get、 wrapKey、 unwrapKeyのアクセス許可をアプリケーションに割り当てます。

12. UiPath は、暗号化と復号にキーを使用するように、関連する Azure リソースを構成します。

UiPath がキーを保存することはありません。すべての操作は、Azure API とユーザー独自のアクセス制御を使用して安全に実行されます。

前提条件

顧客管理のキーを有効化する前に、次の要件を満たしていることを確認してください。

• Azure Key Vault の要件:
  • 論理的な削除と消去保護が有効化されている。
  • リソース ロックは、Key Vault とキーで構成されます。
  • キーの種類は RSA 2048 ビットである必要があります。これらの構成により、誤って削除されることを防ぎ、回復性が確保されます。
• 権限と設定:
  • サポート チケットを提出して UiPath にマルチテナント アプリケーションの登録 ID と名前をリクエストします。
  • テナントでキーを作成し、UiPath のアプリケーションに対してそのキーへのアクセスを承認する必要があります。
  • キーのローテーションは、キーのバージョン管理が有効化されている場合にサポートされます。

手順

1. Azure テナントで Azure Key Vault を作成または選択します。

2. 次の要件に従って、Key Vault と暗号化キーを構成します。

   • 論理的な削除と消去保護を有効化します。削除されたキーまたはボールトを最大 90 日間復元できるようにします。
   • Key Vault とキーの両方に リソース ロック を適用する 誤って削除または変更されないようにします。
   • キーの種類として [RSA 2048 ビット ] を選択します。
   • Key Vault が Azure Disk リソースと同じリージョンにあることを確認します (Azure Disk の暗号化に必要です)。
   • [ ネットワーク] で、[ 信頼された Microsoft サービスにこのファイアウォールのバイパスを許可する] を選択します。詳しい手順については、「新しい ストレージ アカウントにクロステナントのカスタマー マネージド キーを設定する - Azure Storage」をご覧ください。.

3. サポート チームから提供された情報を使用して、お使いの Azure テナントに UiPath マルチテナント アプリケーションをインストールします。

4. Azure RBAC ロールである Key Vault Crypto Service Encryption ユーザーを UiPath アプリケーションに割り当てて、Key Vault にアクセスできるようにします。

   または、UiPath アプリケーションに、get、wrapKey、および unwrapKeyの権限を持つ Key Vault アクセス ポリシーを付与します。

5. 先ほど作成したサポート チケットを通じて、キー URI を UiPath と共有します。

   注:

   サポートされているすべてのリソースに 1 つのキーを使用することも、SQL、ストレージ、ディスク、Snowflake などのリソースごとに個別のキーを使用することもできます。別のキーを使用する場合は、サポート チケットを通じて対応するキーの URI を UiPath に提出してください。

6. UiPath は、指定したキー URI を使用して、Azure ベースのリソースの暗号化を構成し、サポートされているコンポーネント (ストレージ、SQL、ディスク、Snowflake リソースなど) に顧客管理のキー (CMK) を適用します。Snowflake リソースに CMK を適用する場合は、以下の追加手順に従う必要があります。

   1. この Snowflakeコミュニティガイドの手順1〜2.5を実行します。
   2. 手順 2.5 の出力をサポート チケット経由で UiPath に提供します。
   3. UiPath が、手順 2.5 と手順 3.1 で説明した Azure Key Vault への Tri-Secret Secure セルフ登録 を完了します。
   4. UiPath は、Azure の同意リンクと Snowflake のプリンシパル名を共有します。
   5. こちらで説明する Snowflake の手順を手順 3 から続行します。
   6. 手順 4 で Key Vault のパブリック アクセス制御 (特定の IP または仮想ネットワーク経由) が必要な場合は、サブネットの詳細について UiPath にお問い合わせください。
   7. UiPath は手順 4.5 を完了します。

7. CMK による暗号化が有効な場合に通知する。

データ損失防止

偶発的なデータ損失を避けるために、UiPath では以下を推奨しています。

• キー ローテーション:
  • Azure サービスは、新しいキーのバージョンを 1 日に 1 回確認します。キー バージョンを変更してもダウンタイムは発生しません。詳しくは、「 アカウント暗号化のカスタマー マネージド キー - Azure Storage」をご覧ください。
  • ローテーション後、24 時間待ってから以前のバージョンを無効にしてください。
  • 古いバックアップは再暗号化されないため、古いキーのバージョンを復元できるようにしておいてください。
• 一時的な取り消し:
  • キーを削除せずに無効化できます。
  • これにより、暗号化されたリソースへのアクセスがブロックされますが、暗号化状態には影響しません。
  • キーが再度有効化されると、アクセスが復元されます。
  • 無効化している間、操作は 403 Forbidden エラーを返します。

データが失われる可能性があるシナリオと、問題を防止または軽減する方法については、以下の表をご覧ください。

表 1.考えられるデータ損失シナリオ

問題	影響	予防	緩和
AKV リソース ロックの削除	AKV/キーが削除される可能性があります。削除すると、約 10 分以内にリソースにアクセスできなくなります。	論理的な削除と消去の保護により、AKV/キーを 90 日以内に復元できます。	90日以内にAKVまたはキーを復元します。
AKV/現在のキーの削除	約 10 分以内にリソースにアクセスできなくなります。	論理的な削除と消去の保護により、AKV/キーを 90 日以内に復元できます。	90日以内にAKVまたはキーを復元します。
以前のキー バージョンの削除	バックアップの復元が中断される	論理的な削除と消去の保護により、AKV/キーを 90 日以内に復元できます。	90日以内にAKVまたはキーを復元します。
キーの侵害	危険にさらされているデータ	AKV にネットワーク保護を適用します。	N/A
アクセスの取り消し (RBAC/ファイアウォールの変更) 例: サーバーからキー コンテナーの get、 wrapKey、 unwrapKey アクセス許可を取り消すか、キー コンテナーのファイアウォール規則を変更します。	約 10 分以内にリソースにアクセスできなくなります。	リソース ロックを使用します。	権限の復元
Azure Key Vault の停止	約 10 分以内にリソースにアクセスできなくなります。	リージョン間のフェールオーバーがサポートされていないリージョンには、Azure Key Vault をプロビジョニングしません。詳細については、「 Azure Key Vault の信頼性」をご覧ください。	アクションは不要です