ALE と顧客管理のキー

この機能は、Enterprise ライセンスプランのすべてのティア (Standard ティアを含む) で利用できます。

警告:

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

問題のある一般的なシナリオとその解決策については、以下の表をご覧ください。

シナリオ	解決策
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 などのデータ列を暗号化するために使用されます。

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

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

警告:

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

必要な資格情報を作成し、このオプションを有効化するには、以下の手順を実行します。

Azure Key Vault 内に必要な資格情報を作成します。
注:
- キーコンテナーは任意のリージョン内に作成できますが、自身の組織と同じリージョンに属するようにすることをお勧めします。
- 顧客管理のキーに使用するキーコンテナーへのアクセス権が UiPath に付与されるため、この目的専用のコンテナーを作成することをお勧めします。
- この機能では、キーコンテナーで設定できる任意のキーサイズがサポートされます。
- UiPath では、Azure リソースへのアクセスを制御するためだけにキーコンテナーアクセスポリシーをサポートしています。これらのポリシーにラップおよびラップ解除の権限を設定する必要があります。
組織管理者としてログインします。
[管理]に移動し、左側のパネルで組織名をクリックして、[セキュリティ] をクリックします。
[セキュリティ設定] ページが表示されます。
[暗号化] セクションの [暗号化の種類] で [顧客管理のキー] を選択します。
[顧客管理のキーの設定] ウィンドウが表示されます。
以下に示す必要な詳細情報を、Azure Portal で定義されているとおりに入力します。
1. Azure ディレクトリ (テナント) ID (Azure でのアプリの登録の一環として作成):
2. Azure アプリケーション (クライアント) ID (Azure でのアプリの登録の一環として作成):
3. クライアントシークレット (Azure でのアプリの登録の一環として作成):
4. キー識別子 (Azure Key Vault で作成):
  
  重要: 必須: 必ず [キーを折り返す] および [キーの折り返しを解除] オプションを選択し、このアイテムを顧客管理のキーとして使用できるようにしてください。
[テストして保存] をクリックします。
独自の暗号化キーを設定済みであることを示す確認メッセージが表示されます。

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

注:

新しい顧客管理のキーを作成してからキーが反映されるまでに 15 分ほどかかる場合があります。この理由は、UiPath の内部キャッシュでは、パフォーマンス上の理由から同じキーが繰り返し反映されないようになっているためです。

Orchestrator では、外部キーの取得のキャッシュサイクルは 1 時間です。さらに、内部使用のキャッシュサイクルとしてさらに 15 分かかります。

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

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

キーのローテーション

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

自動ローテーションは Azure Key Vault で設定できますが、Automation Cloud^TM 組織の顧客管理のキーの情報は引き続き手動で更新する必要があります。

現在の Azure Key Vault または新しいコンテナー内に新しいキーを作成します。
Automation Cloud^TM 組織の [セキュリティ設定] ページに戻ります。
[顧客管理のキー] の [接続を編集] をクリックして、新しく作成したキーの詳細を追加します。

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

キーローテーションの監査:顧客管理のキーの変更は、Orchestrator の [監査] ページでテナントレベルで確認できます。

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

Enterprise プランの有効期限が切れると、自動的に Free プランにダウングレードされます。データの暗号化の観点から期待できる点は次のとおりです。

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

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

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

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

キーを削除する場合は、論理的な削除機能を使用することが重要です。
キーを失うと、コンテナーに接続できなくなります。したがって、必ず、組織のセキュリティポリシーに従って Azure Portal 上、または Azure とは別のセキュリティで保護されたキーコンテナー内にキーのバックアップを作成する必要があります。
シングルサインオンを利用して UiPath のサービスにアクセスしている場合は、緊急アクセス用 (Break Glass) アカウントとして機能するローカルアカウントを作成することを検討できます。外部 ID プロバイダーの情報は、顧客管理のキーで暗号化されたデータに含まれているため、キーコンテナーにアクセスできないと SSO アカウントがアクセス不能になります。
セキュリティ上の理由から、最上位レベルの管理者権限を持たないユーザーには顧客管理のキーに対するパージ権限を付与しないようにする必要があります。
UiPath がデータにアクセスできないようにする場合、次の図に示すように Azure Key Vault からキーを無効化できます。

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