秘密キー保護

はじめに

FAS証明書はFASサーバーの埋め込みデータベースに保存されます。 FAS証明書に関連付けられた秘密キーは、FASサーバーのネットワークサービスアカウントに保存されます。 デフォルトでは、キーはエクスポートできない2048ビットのRSAであり、Microsoftソフトウェアキー記憶域プロバイダーで作成および保存されます。

FAS PowerShellコマンド「PowerShellコマンドレット」を使用すると、秘密キーのプロパティと保存場所を変更できます。

メモ:

FAS構成と証明書は、FASサーバーにローカルに保存されます。 データはFASサーバー間で共有されません。

Citrix Virtual Apps and Desktops 2411より前のFASリリースでは、秘密キーのプロパティは%programfiles%\Citrix\Federated Authentication Service\Citrix.Authentication.FederatedAuthenticationService.exe.configのXMLファイルを編集して構成されていました。 これはPowerShellコマンドに置き換えられました。PowerShellコマンドはより柔軟性が高く、FASサーバーを再起動せずに適用できます。 さらに、XMLファイル設定とは異なり、PowerShellを使用して行われた構成は、FASサーバーをアップグレードしても保持されます。 したがって、次の設定のXMLファイルを使用した構成はサポートされなくなりました：

• Citrix.TrustFabric.ClientSDK.TrustAreaJoinParameters.KeyProtection
• Citrix.TrustFabric.ClientSDK.TrustAreaJoinParameters.ProviderLegacyCsp
• Citrix.TrustFabric.ClientSDK.TrustAreaJoinParameters.ProviderName
• Citrix.TrustFabric.ClientSDK.TrustAreaJoinParameters.ProviderType
• Citrix.TrustFabric.ClientSDK.TrustAreaJoinParameters.KeyLength

「Citrix Virtual Apps and Desktops 2411より前のバージョンのFASからのアップグレード」のセクションを参照してください。

FAS証明書とテンプレートに関する情報

FASが保持する証明書には、通常1つのインスタンスがある認証証明書と、ユーザー証明書の2種類があります。

メモ:

FAS認証証明書は、登録機関または要求エージェント（RA）証明書と呼ばれることもあります。

次のセクションで説明するように、FASは証明書を要求するときに証明書テンプレートを使用します。 FASは証明書要求でテンプレートの名前を指定しますが、テンプレートの内容は読み取りません。 したがって、テンプレートの設定を変更しても、FASによって行われる証明書要求には影響しません。 テンプレートの特定のプロパティを変更すると、CAによって生成される証明書に影響があります。 たとえば、テンプレートを使用して有効期間を変更できます。

FAS認証証明書

この証明書は、FASを構成するときに作成されます。 FAS管理コンソールの［Authorize］または［Reauthorize］ボタンを使用して、新しい認証証明書を要求できます。

より柔軟性の高いPowerShellコマンドを使用することもできます：

• New-FasAuthorizationCertificate：このコマンドは、承認プロセスで使用する証明書テンプレートを指定できることを除いて、FAS管理コンソールと同様に動作します。
• New-FasAuthorizationCertificateRequest：このコマンドは、認証証明書のオフライン要求を作成します。オフライン認証。

FASは登録機関として機能し、ユーザーに代わって証明書を要求するため、認証証明書はRA証明書と呼ばれることもあります。 証明書には拡張キー使用法「証明書要求エージェント」が含まれており、FASユーザー証明書を要求するときに認証資格情報として使用できます。

デフォルトでは、承認プロセスで次のテンプレートが使用されます：

• Citrix_RegistrationAuthority_ManualAuthorization：このテンプレートを使用して作成された証明書は一時的かつ有効期間が短く、承認プロセスのブートストラップに使用されます。
• Citrix_RegistrationAuthority：このテンプレートを使用して作成された証明書は有効期間が長く、FASサーバーによって保存されます。

FASを承認すると、次の手順が実行されます：

1. FASはキーペアを作成し、キーペアの公開キーとテンプレートCitrix_RegistrationAuthority_ManualAuthorizationを指定して、証明書署名要求（CSR）をCAに送信します。

2. テンプレートの発行要件には、CSRはCA管理者によって手動で承認される必要があると指定されています。

3. CA管理者がCSRを承認すると、CAはFASが取得する証明書を作成します。 この証明書の有効期間は1日間と短く、次の手順でのみ使用されます。 一度使用すると、FASは証明書とそのキーペアを破棄します。

4. FASは別のキーペアを作成し、このキーペアの公開キーとテンプレートCitrix_RegistrationAuthorityを指定して2番目のCSRをCAに送信します。 要求は前の手順の証明書によって承認され、署名されます。

5. CAは自動的に証明書を発行し、FASは証明書を取得し、FASは承認済みになります。 デフォルトでは、この認証証明書の有効期間は2年間です。

前述のキーペアを作成するために使用された設定は、次のPowerShellコマンドを使用して表示できます：

Get-FasKeyConfig -Address localhost -CertificateType ra

FASユーザー証明書

FASは、ユーザーをVDAにサインインさせるためのユーザー証明書を作成します。

FASがユーザー証明書を作成すると、次の手順が実行されます：

• FASはキーペアを作成し、キーペアの公開キー、ユーザーのID、およびデフォルトではテンプレートCitrix_SmartcardLogon（使用されるテンプレートは構成可能です）を指定してCSRをCAに送信します。
• CSRはFAS認証証明書を使用して署名されます。
• Citrix_SmartcardLogonテンプレートには発行要件「アプリケーションポリシー：証明書要求エージェント」があります。 この属性はFAS認証証明書に存在するため、CAはユーザー証明書を自動的に発行します。
• FASは証明書を取得し、FASサーバーの埋め込みデータベースに保存します。
• デフォルトでは、証明書の有効期間は1週間です。

その後、ユーザー証明書はVDAで使用可能になり、ユーザーがサインインできるようになります。

前述のキーペアを作成するために使用された設定は、次のPowerShellコマンドを使用して表示できます：

Get-FasKeyConfig -Address localhost -CertificateType user

秘密キーの保存オプション

FASは、次の3つのカテゴリのストレージにキーペアを作成して保存するように構成できます：

• ソフトウェア：通常はMicrosoftソフトウェアキー記憶域プロバイダーを使用します。これはソフトウェアのみで保護され、データはディスクに保存されます。
• トラステッドプラットフォームモジュール（TPM）：TPMは、コンピューター上の物理ハードウェア、またはハイパーバイザーによって提供される仮想TPMです。
• ハードウェアセキュリティモジュール（HSM）：これは、暗号化キーを安全に保存するように設計されたハードウェア周辺機器またはネットワークデバイスです。

メモ:

考慮すべきトレードオフがあります。 ハードウェアストレージは比較的安全ですが、特に多数のユーザー証明書のキーペアを作成して保存する場合などは、パフォーマンスが低下することがよくあります。

FAS認証証明書ポリシーは秘密キーを所有するものすべてに対して、任意のユーザーへの証明書要求の承認を許可するため、FAS認証証明書に関連付けられた秘密キーは特に機密です。 結果として、このキーを管理するものはだれでも、ユーザーとして、環境に接続できます。

メモ:

Microsoft CAは、証明書の発行対象であるユーザーのセットを含む、FAS認証証明書の権限を制限するように構成できます。 「委任された登録エージェント」を参照してください。

このため、FASでは、認証証明書とユーザー証明書の秘密キーのプロパティを個別に構成できます。

一般的な構成は次のとおりです：

メモ:

ハードウェアTPMはユーザーキーにはお勧めしません。 認証証明書キーにのみTPMを使用します。 FASサーバーを仮想化環境で実行する予定の場合は、ハイパーバイザーのベンダーにTPM仮想化がサポートされているかどうかを確認してください。

主要な構成PowerShellコマンド

秘密キーの構成に関連するコマンドは次のとおりです：

• Get-FasKeyConfig
• Set-FasKeyConfig
• Reset-FasKeyConfig
• Test-FasKeyConfig

詳しくは、「PowerShellコマンドレット」を参照してください。

認証証明書とユーザー証明書のキー構成は独立しており、CertificateType引数によって指定されます。 たとえば、認証証明書（RA証明書）を要求するときに使用する秘密キー構成を取得する場合：

Get-FasKeyConfig -Address localhost -CertificateType ra

ユーザー証明書を要求するときに使用される秘密キー構成を取得する場合：

Get-FasKeyConfig -Address localhost -CertificateType user

Set-FasKeyConfigおよびGet-FasKeyConfigを使用して、次の秘密キーのプロパティを設定および検査できます：

さらに、Set-FasKeyConfigは、利便性のために提供されている次のスイッチとともに使用できます：

Microsoft Software Key Storage Providerは、通常、ディスク上にキーを作成して保存するために使用されるプロバイダーです。

Microsoft Platform Crypto Providerは、通常、TPMにキーを作成して保存するために使用されるプロバイダーです。

Get-FasKeyConfigは、使用されているプロバイダーとアルゴリズムを確認するのに役立つフィールドも提供します：

Reset-FasKeyConfigを使用して設定をデフォルトに戻すことができます。

Reset-FasKeyConfig -Address localhost -CertificateType ra
Reset-FasKeyConfig -Address localhost -CertificateType user
 

メモ:

秘密キー構成に加えられた変更（Set-FasKeyConfigまたはReset-FasKeyConfigを使用）は、新しく作成された証明書にすぐに適用されます。 ただし、異なる構成の既存の認証証明書とユーザー証明書は影響を受けません。

既存の証明書を削除するには、管理コンソールからFASサービスの許可を取り消すか、「FASの許可の取り消しとFAS証明書の削除」のPowerShellコマンドを使用します。

現在のユーザーキー構成に準拠しないキープール内の事前生成されたキーはすべて破棄されます。

構成シナリオの例

各例では、既存の証明書は構成の変更によって影響を受けないため、FASサービスを承認する前に、提供されているPowerShellを使用してキー構成を設定します。

間違ったキー構成の認証証明書またはユーザー証明書が既にある場合は、FAS証明書を検査し、FASの許可を取り消してFAS証明書を削除することで削除できます。

FASサーバーがライブ展開内にある場合は、構成を変更（メンテナンスモード）してメンテナンスモードにすることを検討してください。

例1 - すべてのキーをMicrosoftソフトウェアキー記憶域プロバイダーに保存する

これはデフォルトなので、追加の構成は必要ありません。

以前にキー構成を変更した場合は、次のコマンドを使用して、Microsoftソフトウェアキー記憶域プロバイダーの使用に戻すことができます：

Set-FasKeyConfig -Address localhost -CertificateType ra -UseDefaultSoftwareProvider
Set-FasKeyConfig -Address localhost -CertificateType user -UseDefaultSoftwareProvider
 

Reset-FasKeyConfigを使用すると、Microsoftソフトウェアキー記憶域プロバイダーに戻して、さらに他のすべてのキー構成設定をデフォルト値に戻すことができます。

例2 - 認証証明書キーをTPMに保存する

この例では、FAS認証証明書キーをTPM（物理または仮想）に保存し、ユーザー証明書キーをMicrosoftソフトウェアキー記憶域プロバイダーに保存する方法を示します。

FASはTPMで保護されたキーでユーザー証明書を生成できますが、TPMは大規模の展開には速度が遅すぎる、またはサイズが限定されている可能性があります。

次のPowerShellコマンドを使用します：

Set-FasKeyConfig -Address localhost -CertificateType ra -UseDefaultTpmProvider
Set-FasKeyConfig -Address localhost -CertificateType user -UseDefaultSoftwareProvider
 

例3 - すべてのキーをHSMに保存する

この例では、HSMを使用して認証証明書とユーザー証明書の秘密キーの両方を保存する方法を示します。 この例では、構成済みのHSMを想定しています。 HSMにはプロバイダー名が付けられます。 たとえば、HSMベンダーキー記憶域プロバイダーなどです。

次のPowerShellコマンドを使用します（例のテキストをHSMプロバイダーの実際の名前に置き換えます）：

Set-FasKeyConfig -Address localhost -CertificateType ra -Provider "HSM Vendor Key Storage Provider"
Set-FasKeyConfig -Address localhost -CertificateType user -Provider "HSM Vendor Key Storage Provider"
 

例4 - 楕円曲線キーを使用する

デフォルトでは、FASはRSAキーを生成します。 この例では、認証証明書とユーザー証明書の両方に楕円曲線（ECC）キーが構成されています。

この例では、異なるキーの長さを使用します。 認証証明書は384ビットキーで構成され、ユーザー証明書は256ビットキーで構成されます。

Set-FasKeyConfig -Address localhost -CertificateType ra -EllipticCurve $true -Length 384
Set-FasKeyConfig -Address localhost -CertificateType user -EllipticCurve $true -Length 256
 

この時点では、FAS証明書テンプレートの最小キーサイズがデフォルトで1024ビットに設定されているため、認証証明書およびユーザー証明書の要求がCAによって拒否される可能性があります。

したがって、この例では、テンプレートの最小キーサイズを次のように変更する必要があります：

• Citrix_RegistrationAuthority_ManualAuthorizationおよびCitrix_RegistrationAuthority：最小キーサイズを384（またはそれ以下）に変更します
• Citrix_SmartcardLogon：最小キーサイズを256（またはそれ以下）に変更します

テンプレートを編集するには、mmc.exeを実行し、証明書テンプレートスナップインを追加します。 テンプレートを見つけて、そのプロパティを開きます。 最小キーサイズの設定は、テンプレートのプロパティの暗号化タブにあります。

メモ:

ECCキーを使用するユーザー証明書は、Citrix Virtual Apps and Desktops 2411以降を実行しているWindows VDAでのみサポートされます。 ECCキーはLinux VDAではサポートされていません。

秘密キーの構成をテストする

Set-FasKeyConfigコマンドはいくつかの検証を実行しますが、無効なキー構成を設定する可能性もあります。 たとえば、HSMのプロバイダー名を間違えたり、指定したキーの長さがハードウェアでサポートされていない可能性があります。

コマンドTest-FasKeyConfigが役立ちます。 現在のキー構成を使用してキーペアの作成を試み、成功または失敗を報告します。 失敗した場合は、失敗の理由が示されます。 成功した場合、キーペアは直ちに破棄されます。

次のPowerShellコマンドは、それぞれ認証とユーザーキーの構成をテストします：

Test-FasKeyConfig -Address localhost -CertificateType ra
Test-FasKeyConfig -Address localhost -CertificateType user
 

FAS サーバーを承認してルールを作成したら、次のようにユーザー証明書のテスト CSR を追加で作成できます。

Test-FasCertificateSigningRequest -Address localhost -UserPrincipalName user@example.com -Rule default

«user@example.com>/>を、Active Directory展開の実際のUPNに置き換えます。 FASルールは通常、デフォルトという名前になります。 ただし、構成した別のルールをテストする場合は、代わりにその名前を指定します。

CSRが成功した場合、FASは結果の証明書を破棄します。

FAS証明書の検査

PowerShellを使用して証明書のプロパティを検査し、関連付けられている秘密キーが保存されている場所を特定できます。

認証証明書の検査

FAS管理コンソールのauthorization certificateリンクをクリックすると、認証証明書が表示されます：

ただし、より詳細な情報についてはPowerShellを使用してください：

Get-FasAuthorizationCertificate -Address localhost -FullCertInfo

証明書が作成および保存されたプロバイダーを示すPrivateKeyProviderを含むいくつかのフィールドが返されます。

ユーザー証明書の検査

次のようにして、FASサーバーにキャッシュされているすべてのユーザー証明書の一覧を取得できます：

Get-FasUserCertificate -Address localhost -KeyInfo $true

KeyInfoパラメーターにより、出力には証明書に関連付けられた秘密キーに関する詳細情報が含まれます。 特に、PrivateKeyProviderフィールドは、証明書に関連付けられたキーペアが保存されている場所を示します（この値の解釈については、前のセクションを参照してください）。

-UserPrincipalNameなどのさまざまなオプションパラメーターを使用して、返される証明書のセットをフィルター処理できます。

コマンド出力の証明書フィールドは、PEMでエンコードされたユーザー証明書です。 次のように、Windows証明書GUIを使用して証明書を表示するには、テキストを.crtファイルにコピーします：

Citrix Virtual Apps and Desktops 2411より前のバージョンのFASからのアップグレード

Citrix Virtual Apps and Desktops 2411より前のFASリリースでは、秘密キーのプロパティは、次のXMLファイルを編集して構成されていました

%programfiles%\Citrix\Federated Authentication Service\Citrix.Authentication.FederatedAuthenticationService.exe.config
 

これはPowerShellコマンドに置き換えられました。このPowerShellコマンドは、より柔軟性が高く、FASサーバーを再起動せずに適用できます。

さらに、XMLファイル設定とは異なり、PowerShellを使用して行われた構成は、FASサーバーをアップグレードしても保持されます。

秘密キーの構成に関連するXMLファイル設定と、それに対応するPowerShellパラメーター（Get-FasKeyConfigおよびSet-FasKeyConfigで使用されている）を以下に示します：

XML構成のデフォルトとPowerShellのデフォルトは機能的に同等です。 つまり、デフォルトでは、このバージョンとCitrix Virtual Apps and Desktops 2411より前のバージョンのFASによって生成されるキーペアのプロパティは同じです。

したがって、XML構成ファイル内の前述の設定をいずれも変更していない場合は、FASをアップグレードするときに何もする必要はありません。

ただし、前述の設定のいずれかを変更した場合は、次のようにFASをアップグレードします：

• FASをメンテナンスモードにします。メンテナンスモード。
• FASインストーラーを実行するだけで、FASをインプレースでにアップグレードできます。アップグレードすると、以前の設定はすべてXMLファイルに存在しなくなり、XMLファイルで構成できなくなります。
• 主要な構成PowerShellコマンドで説明されているように、PowerShellコマンドSet-FasKeyConfigを使用して、必要に応じてFAS秘密キー構成を設定します。承認およびユーザー証明書に必要な設定を判断します。
• 「秘密キーの構成をテストする」の説明に従って、構成をテストします
• FASサーバーのメンテナンスモードを解除します

次回アップグレードするときには、FAS秘密キーの構成設定が保持されるため、特別な操作を行う必要はありません。

暗号化のリモート処理

FASユーザー証明書に関連付けられた秘密キーは、VDAに転送されることはありません。 代わりに、VDAがVDAへのサインインまたはセッション中の使用のためにユーザーのFAS証明書を使用する必要がある場合、暗号化要求はFASサーバーにリモートで戻されます。 これにより、秘密キーがFASキーストレージ（ソフトウェアストレージ、TPM、HSMのいずれの場合でも）から出ることがなくなるため、セキュリティが向上します。

Windows VDAでは、これはVDA上のプロバイダーのペアを使用することで達成されます。 暗号化要求を行うアプリケーションまたはオペレーティングシステムのコードは、操作がFASサーバーにリモートで戻されていることを認識しません。

Citrix Virtual Apps and Desktops 2411より前のプロバイダー 暗号化サービスプロバイダー（CSP）であり、アプリケーションとオペレーティング システムのコードへのアクセスは古いWindows CAPI APIを介して行われていました。 プロバイダーは以下のとおりです：

• CitrixLogonCsp.dll：VDAへのシングルサインオン用
• CitrixVirtualSmartcardCsp.dll：セッション中の証明書用

Citrix Virtual Apps and Desktops 2411以降では、VDAで追加のキーストレージプロバイダー（KSP）が提供されます。 アプリケーションとオペレーティングシステムのコードは、新しいWindows CNG APIを使用してこれらにアクセスします。 新しいプロバイダーは以下のとおりです：

• CitrixLogonKsp.dll：VDAへのシングルサインオン用
• CitrixVirtualSmartcardKsp.dll：セッション中の証明書用

KSPは、暗号化操作をWindowsアプリケーションに公開する最新の方法であり、より多くの機能を提供します。 例：

• ECCキーを使用した証明書がサポートされています
• 確率的署名スキーム（PSS）パディングがサポートされています

FASとVDAの両方がCitrix Virtual Apps and Desktops 2411以降を実行している場合は、KSPリモート処理（つまり、新しいKSPを介したリモート処理）が使用されます。 それ以外の場合、システムはリモート処理に古いCSPを使用するためにフォールバックします。

KSPリモート処理を無効にする

互換性の問題が発生した場合は、KSPリモート処理を無効にして、古いCSPリモート処理を常に使用することも可能です。

次のPowerShellを使用します：

Set-FasServer -Address localhost -KspRemoting $false

メンテナンスモード

ライブFASサーバーの構成を変更する場合は、メンテナンスモードにすることを検討してください。

FASがメンテナンスモードの場合、次のことが当てはまります：

• WorkspaceまたはStoreFrontが公開アプリケーションまたはデスクトップの起動シーケンスの一部としてFASを呼び出すと、FASはメンテナンスモードであることを示します。呼び出し元はこれに応じて、別のFASサーバーを選択する必要があります。
• 追加の予防策として、FASではメンテナンスモード時にユーザー証明書の自動作成は許可されません。 したがって、意図しない設定のユーザー証明書が誤って作成されるのを回避できます。
• ただし、VDAサインインやセッション中の使用など、既存のユーザー証明書に関連するアクティビティは引き続き許可されます。

自動ユーザー証明書の作成は許可されていませんが、管理者はNew-FasUserCertificateやTest-FasCertificateSigningRequestなどのPowerShellコマンドを使用してユーザー証明書を作成できます。

管理コンソールの使用

PowerShellの使用

次のようにして、FASサーバーをメンテナンスモードにします：

Set-FasServer -Address localhost -MaintenanceMode $true

次のようにして、FASサーバーをメンテナンスモードから解除し、通常の動作に戻します：

Set-FasServer -Address localhost -MaintenanceMode $false

関連情報

• FASのインストールと構成については、「インストールと構成」を参照してください。
• 一般的なFASの展開については、「フェデレーション認証サービスのアーキテクチャの概要」を参照してください。
• その他の具体的な手順については、「詳細な構成」を参照してください。