Expressway が証明書ベースの認証モードで動作している場合、ユーザ認証は Expressway 外部のプロセスによって管理されます。

ユーザが Expressway にログインしようとすると、Expressway はクライアント ブラウザから証明書を要求します。 その後、ブラウザはカード リーダーと対話してスマート カードから証明書を取得します (または、証明書がすでにブラウザに読み込まれている場合もあります)。 カード/ブラウザから証明書を解放するには、通常、ユーザは PIN を入力して認証するよう求められます。 Expressway が受信したクライアント証明書が有効 (信頼できる証明機関によって署名され、有効期限内で、CRL によって失効していない) 場合、ユーザは認証されているとみなされます。

ユーザの承認レベル (読み取り/書き込み、読み取り専用など) を決定するには、Expressway は証明書からユーザの承認ユーザ名を抽出し、関連するローカルまたはリモートの承認メカニズムに提示する必要があります。

（注）	クライアント証明書が (PIN またはその他のメカニズムによって) 保護されていない場合、Expressway への認証されていないアクセスが可能になる可能性があります。 一部のブラウザでは証明書ストアをパスワードで保護できますが、証明書がブラウザに保存されている場合にも、この保護の欠如が当てはまる可能性があります。

ユーザー名は、[証明書ベースの認証設定（Certificate-based authentication configuration）] ページの [Regex] フィールドと [ユーザー名の形式（Username format）] フィールドで定義されたパターンに従って、クライアント ブラウザの証明書から抽出されます。

• Regex フィールドでは、(?<name>regex )構文を使用してキャプチャグループの名前を指定し、一致するサブパターンを関連する [ユーザー名形式（Username format）] フィールドで置き換えることができます。例:

  /(件名:.*, CN=(?<Group1>.*))/m.

  ここで定義される正規表現は、 PHP 正規表現ガイドラインに準拠する必要があります。

• [ユーザー名の形式（Username format）] フィールドには、固定テキストと Regex で使用されるキャプチャグループ名が混在して含まれることがあります。 各キャプチャ グループ名は # で区切ります (例: prefix#Group1#suffix )。 各キャプチャ グループ名は、正規表現処理から取得されたテキストに置き換えられます。

クライアント証明書テスト ページを使用すると、さまざまな 正規表現 と ユーザ名形式 の組み合わせを証明書に適用した結果をテストできます。

高度なアカウント セキュリティ モードでは、リモート認証のみを使用する必要がありますが、認証サーバが利用できない場合に備えて緊急アカウントも用意しておく必要があります。 「 高度なアカウント セキュリティ モードの構成」を参照してください。

証明書ベースの認証を使用している場合、緊急アカウントは、一致する資格情報を持つ有効な証明書を提示して認証できる必要があります。

緊急アカウント用のクライアント証明書を作成し、CN が ユーザ名の形式と一致していることを確認し、証明書を緊急管理者の証明書ストアにロードする必要があります。

X12.5 以降、Cisco Expressway シリーズは ACME プロトコル (自動証明書管理環境) をサポートしており、Let's Encrypt などの証明機関から Expressway-E への自動証明書署名と展開が可能になります。

CSR が生成されると、そのピアに対してのみ単一のリクエストと秘密キーの組み合わせが生成されます。 Expressway のクラスタがある場合は、ピアごとに個別の署名要求を生成する必要があります。 これらの要求は証明機関に送信され、返されたサーバ証明書は関連する各ピアにアップロードされる必要があります。

正しいサーバ証明書が適切なピアにアップロードされていることを確認してください。そうでない場合、各ピアに保存されている秘密キーは、アップロードされた証明書と一致しなくなります。

モバイルおよびリモート アクセスを展開する場合、Unified Communication および Expressway 証明書の要件に関する詳細は、 『Cisco Expressway 証明書の作成および使用の導入ガイド』 の 「Expressway 構成ガイド」 ページに記載されています。

Expressway は、複数のソースから証明書失効情報を取得できます。

• CRL 配布ポイントからの CRL データの自動ダウンロード。

• チェックする証明書内の OCSP (Online Certificate Status Protocol) レスポンダ URI 経由 (SIP TLS のみ)。

• CRL データの手動アップロード。

• Expressway の 信頼された CA 証明書 ファイル内に埋め込まれた CRL データ。

SIP TLS 接続の証明書失効チェックの管理方法も構成する必要があります。

1. [ 設定 > SIP] に移動します。

2. 証明書失効チェック セクションまで下にスクロールし、それに応じて設定を構成します。

   フィールド	説明	使用上のヒント
   証明書失効チェックモード	SIP TLS 接続の確立中に交換される証明書に対して失効チェックを実行するかどうかを制御します。	失効チェックを有効にすることをお勧めします。
   OCSP の使用	証明書失効チェックを実行するためにオンライン証明書ステータス プロトコル (OCSP) を使用できるかどうかを制御します。	OCSP を使用するには、以下の方法があります。 チェックする X.509 証明書には、OCSP レスポンダ URI が含まれている必要があります。 OCSP レスポンダは、SHA-256 ハッシュ アルゴリズムをサポートする必要があります。 サポートされていない場合、OCSP 失効チェックと証明書の検証は失敗します。
   CRLs の使用	証明書失効リスト (CRL) を使用して証明書失効チェックを実行するかどうかを制御します。	証明書が OCSP をサポートしていない場合は、CRL を使用できます。 CRL は、Expressway に手動でロードすることも、事前設定された URI から自動的にダウンロードすることも ( 「証明書失効リスト (CRL) の管理」 を参照)、X.509 証明書に含まれる CRL 配布ポイント (CDP) URI から自動的にダウンロードすることもできます。
   CDP からの CRL ダウンロードを許可する	X.509 証明書に含まれる CDP URI からの CRL のダウンロードを許可するかどうかを制御します。
   フォールバック動作	失効ソースに接続できない場合など、失効ステータスを確立できない場合の失効チェック動作を制御します。 失効として扱う: 証明書を失効として扱います (したがって、TLS 接続は許可されません)。 失効していないものとして扱う: 証明書を失効していないものとして扱います。 デフォルト: 失効していないものとして扱う	「失効していないものとして扱う」 は、失効元に接続できない場合でもシステムが引き続き正常に動作することを保証しますが、失効した証明書が受け入れられる可能性があります。

既存のシステムをアップグレードすると、以前の動作とデフォルトが維持されます。

新規インストールの場合は、Expressway に接続する必要があるすべてのブラウザおよびその他の機器が TLS 1.2 をサポートしていることを確認してください。

X15.2 以降のリリースでは、お客様は TLS 1.3 を有効にするように設定を変更できます。 設定を変更するためのオプションが提供されています。

必要に応じて（通常は従来の機器との互換性の理由から）、サービスごとに最小 TLS バージョンを構成して、バージョン 1.0 または 1.1 を使用できます。

Expressway 上のサービスに対して、暗号スイートとサポートされる最小 TLS バージョンを設定できます。 暗号スイートは表に示されています (暗号文字列は OpenSSL 形式です)。

HTTPS など、Expressway がクライアントとして機能できるサービスの場合、同じ最小 TLS バージョンと暗号スイートがネゴシエートされます。

これらの推奨事項に留意してください

1. Expressway は、デフォルトで次の非推奨の暗号をサポートしています。 X15.0 リリース以降では、 メンテナンス > セキュリティ > 暗号 ページからこれらの暗号を削除することをお勧めします。

   • TLS_DHE_RSA_WITH_AES_128_CCM

   • TLS_RSA_WITH_AES_256_CCM

   • TLS_RSA_WITH_AES_128_CCM

2. X14.2 リリース以降、Expressway は Anonymous Diffie-Hellman (ADH) 暗号をサポートしなくなりました。

3. たとえばエンドポイントでは、E20 は Anonymous Diffie Hellman (ADH) 暗号のみをサポートしますが、Expressway はエンドポイントの ADH 暗号をサポートしません。 この結果、TLS 接続に問題が発生します。

   解決策: TC/CE エンドポイントのサービス証明書

   1. TC/CE エンドポイントで SIP の証明書を有効にするには、 TC/CE エンドポイント にログインし、次のパスに従います。

      • TC エンドポイントの場合 - [構成] > [セキュリティ] に移動します。

      • CE エンドポイントの場合 - セキュリティ > サービス証明書 に移動します。

   2. [サービス証明書] ページでは、SIP オプションはデフォルトで [オフ]に設定されています。 証明書を使用するには、SIP の証明書を有効にする、つまり オン にする必要があります。 このオプションを有効にしないと、TLS ハンドシェイク エラーが発生します。

      （注）	Expressway は、SIP サービスに対して Anonymous Diffie-Hellman (ADH) 暗号をサポートしていません。

廃止された暗号の削除

Expressway でデフォルトの暗号設定が変更されます。 変更点は以下の通りです。

新規インストール

“EECDH:EDH:HIGH:-
AES256+SHA:!MEDIUM:!LOW:!3DES:!MD5:!PSK:!eNULL:!aNULL:!aDH:!AES256+DH+AESCCM”

新しい暗号設定

"HIGH:!MEDIUM:!LOW:!3DES:!MD5:!PSK:!eNULL:!aNULL:!aDH:-AES256+SHA:-
RSA+AESCCM:-DHE+AESCCM:-DHE+CHACHA20"

以下の暗号は、最小 TLSv1.2 構成で削除されました。

1. TLS_RSA_WITH_AES_256_CCM

2. TLS_RSA_WITH_AES_128_CCM

3. TLS_DHE_RSA_WITH_AES_256_CCM

4. TLS_DHE_RSA_WITH_AES_128_CCM

5. TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256

アップグレード

ユーザが以前のバージョンからアップグレードする場合、

• 既存のバージョンではデフォルトの暗号が使用されていましたが、新しい暗号文字列に変更されます。

• ユーザは既に暗号を変更しており、そのまま保持されます。

• ユーザが ECDHE-RSA-AES256-GCM-SHA384 のプレフィックスを使用する RSA 暗号を優先している場合、システムはそのプレフィックスを保持し、アップグレード後は RSA が優先されます。

重要

X15.0.2 OVA ファイルを使用した新しい VM のデプロイメントでは、暗号パラメータが新しい推奨構成に設定されます。 "HIGH:!MEDIUM:!LOW:!3DES:!MD5:!PSK:!eNULL:!aNULL:!aDH:-AES256+SHA:-RSA+AESCCM:- DHE+AESCCM:-DHE+CHACHA20" デフォルトの暗号構成を持つシステムで X15.0.2 にアップグレードすると、暗号構成は新しい推奨構成に自動的に更新されます。 "HIGH:!MEDIUM:!LOW:!3DES:!MD5:!PSK:!eNULL:!aNULL:!aDH:-AES256+SHA:-RSA+AESCCM:- DHE+AESCCM:-DHE+CHACHA20" カスタマイズされた暗号構成を持つシステムで X15.0.2 にアップグレードすると、ソフトウェアのアップグレード後も暗号構成はそのまま保持されます (自動的に更新されません)。 アップグレード後に設定を工場出荷時の設定にリセットした後、暗号パラメータが新しい推奨設定に自動的に更新されます。 "HIGH:!MEDIUM:!LOW:!3DES:!MD5:!PSK:!eNULL:!aNULL:!aDH:-AES256+SHA:-RSA+AESCCM:- DHE+AESCCM:-DHE+CHACHA20"

禁止された暗号の削除

Expressway は、デフォルトで次の非推奨の暗号をサポートしています。 X15.0 リリース以降では、[メンテナンス（Maintenance）] > [セキュリティ（Security）] > [Ciphers（暗号）] ページからそれらを削除することをお勧めします。

1. TLS_DHE_RSA_WITH_AES_128_CCM

2. TLS_RSA_WITH_AES_256_CCM

3. TLS_RSA_WITH_AES_128_CCM

重要	高度なアカウント セキュリティ オプションは、Expressway シリーズ デバイスでは 使用できません 。 説明するセクション全体は、Cisco TelePresence Video Communication Server（VCS）シリーズにのみ適用されます。

高度なアカウント セキュリティを有効にすると、Web インターフェイスを使用するリモート認証されたユーザのみにログイン アクセスが制限され、一部のシステム機能へのアクセスも制限されます。 Expressway が高度なアカウント セキュリティ モードであることを示すために、分類バナーとして指定されたテキストがすべてのウェブページに表示されます。

高度なアカウント セキュリティ モードの変更を有効にするには、システムを再起動する必要があります。

HTTP メソッド

Expressway Web サーバでは、次の HTTP メソッドが許可されます。

API へのユーザアクセスを無効にする方法

管理者はデフォルトで API にアクセスできます。 これは次の 2 つの方法で無効にできます。

• Expressway が高度なアカウント セキュリティ モードで実行されている場合、すべてのユーザに対して API アクセスが自動的に無効になります。

• 個々の管理者の API アクセスは、ユーザ構成オプションを通じて無効にすることができます。

重要

X14.2.5 以降、Expressway シリーズ デバイスで FIPS140-2 オプションが 利用可能 になりました。 これは、スマート ライセンス モデルを実行しながら Expressway で FIPS をサポートする最初のバージョンです。 「Expressway Select」イメージで実行される Cisco Expressway シリーズには、FIPS 機能が含まれています (追加のライセンスやオプション キーをインストールしたり、Smart Licensing ポータルで有効にしたりする必要はありません)。 FIPS140-2 モードは、高度なセキュリティ オプション キー と Expressway Select を備えた Cisco Video Communication Server (VCS) でのみ使用可能であり、Expressway (輸出規制対象バージョン) では使用できません。

（注）	FIPS140-2 モードを無効にするには、工場出荷時の状態にリセットする必要があります。

FIPS (連邦情報処理規格 140) は、暗号化モジュールのセキュリティ要件を規定する米国およびカナダ政府の規格です。 FIPS140-1 は 1994 年に機密データ保護の必須規格となり、2001 年に FIPS140-2 に置き換えられました。Expressway X8.8 以降では、FIPS140-2 準拠の機能が実装されています。

FIPS140-2 暗号化モードの場合、暗号化のワークロードが増加するため、システム パフォーマンスが影響を受ける可能性があります。

FIPS140-2 モードが有効になっている Expressway をクラスタ化できます。