MID サーバー証明書チェックポリシー
MID サーバーは、4 種類のセキュリティチェックを使用して外部トラフィックを保護します。セキュリティチェックでは、TLS/SSL 証明書の検証、ホスト名の検証、証明書失効リスト (CRL)、およびオンライン証明書ステータスプロトコル (OCSP) の検証を使用してセキュリティを強化します。MID サーバー 証明書チェックポリシーテーブルを使用して、これらのセキュリティチェックを制御します。
TLS/SSL 証明書の検証
TLS/SSL 暗号化セキュリティでは、公開鍵暗号化とも呼ばれる非対称暗号化を使用します。この暗号化では、公開鍵と秘密鍵の 2 つの暗号鍵を使用します。公開鍵はデータの暗号化に使用され、公開されます。秘密鍵はデータの復号化に使用され、そのセキュリティは信頼性を検証するために不可欠です。ネットワークの準備の詳細については、次を参照してください。 MID サーバー TLS/SSL 証明書チェックポリシー Quebec アップグレード情報 [KB0867397].
TLS/SSL 証明書の検証では、MID サーバーは TLS または SSL 証明書で保護された Web サーバーへの接続を試行します。Web サーバーは、TLS/SSL 証明書のコピーを MID サーバーに送信します。MID サーバーは証明書の信頼性を確認し、メッセージを Web サーバーに送信します。Web サーバーは、TLS/SSL 暗号化セッションを開始するためのデジタル署名された承認で応答します。その後、MID サーバーは Web サーバーとの暗号化された通信を開始できます。
ホスト名の検証
ホスト名の検証は、クライアントが正しいサーバーと通信していることを確認するためのサーバー ID チェックを含む HTTPS の一部です。このチェックは、中間者攻撃によってリダイレクトされた後にサーバーに情報を送信することを防ぎます。
このチェックでは、サーバーから送信された証明書の dnsName が、要求の実行に使用された URL と一致することを確認します。RFC 6125 に従い、ホスト名の検証は、証明書の subjectAlternativeName の dNSName フィールドに対して実行する必要があります。一部の従来の実装では、証明書の commonName フィールドに対してチェックが行われます。名前が一致しない場合、接続が終了します。
オンライン証明書ステータスプロトコル (OCSP)
OCSP では、MID サーバーがターゲットサーバーとさらに通信する前に、リモート認証局サーバーに接続して証明書を検証します。特にこれらの証明書に他の証明書に署名する機能がある場合、侵害された証明書はセキュリティ上の脆弱性となる可能性があります。証明書が壊れているか偽造されている場合、認証局はどの証明書が無効で使用すべきでないかをクライアントに通知できます。
OCSP レスポンダ (通常は証明書発行者によって実行されるサーバー) は、証明書が「良好」、「失効」、または「不明」であるという署名付き応答を返します。要求を処理できない場合は、エラーコードが返されることがあります。
証明書の発行者は、別の権限を OCSP レスポンダとして委任することができます。これにより、検証が必要な一連の証明書が作成されます。レスポンダの証明書は、問題の証明書の発行者が発行する必要があります。レスポンダの証明書には、それを OCSP 署名機関としてマークする特定の拡張子を含める必要があります。
証明書失効リスト (CRL)
CRL チェックは、証明書の失効ステータスを確認するための OCSP の代替手段を提供します。MID サーバーは、ライブ OCSP レスポンダーをクエリするのではなく、認証局 (CA) によって提供される URL から証明書失効リスト (CRL) をダウンロードしてキャッシュします。次に、MID サーバーは、SSL/TLS ハンドシェイク中に、ローカルにキャッシュされた CRL に対して証明書の失効ステータスをチェックします。証明書が CRL に表示される場合、MID サーバーは接続を拒否し、イベントをログに記録します。
CRL はローカルにキャッシュされ、CA の更新スケジュールに基づいて定期的に更新されます。CRL のダウンロードが失敗した場合、システムは設定可能な再試行ポリシーに従って再試行します。
MID サーバーセキュリティポリシー
MID サーバーのセキュリティ方針は、MID サーバーから発信されるすべての HTTPS トラフィックを制御します。これには、MID サーバーからインターネットエンドポイント、ServiceNow URL、イントラネットエンドポイント、およびクラウドエンドポイントへの HTTPS 接続が含まれます。
これらの接続は、さらに次の 4 つのセキュリティ方針に分類できます。
- ServiceNow エンドポイントポリシー
- このポリシーは、ServiceNow URL 専用のシステムデフォルトです。MID サーバーの config.xml には、インスタンスへの最初の接続にのみ使用され、system_default ポリシーで更新されるブートストラッププロパティがあります。
- インターネットポリシー
- これらのポリシーは、MID サーバーからインターネット上のエンドポイントへのすべての HTTPS 接続を対象とします。
- イントラネットポリシー
- これらのポリシーは、セルフホストネットワークなどの予約済み IP サブネットを対象とします。
- 上書きされたポリシー
- このポリシー定義を使用して、特定のエンドポイントまたは URL を上書きできます。上書きされたポリシーは、操作時に最も優先順位が高くなります。
どちらのテーブルも編集可能で、IP 範囲を含めたり除外したりするだけでなく、実行する必要がある証明書検証チェックの種類を制御することもできます。セキュリティを最大化するために、すべての証明書検証チェックを有効にします。Quebec バージョンでは、新規インストールのすべてのポリシーとチェックがデフォルトでオンになっています。
自己署名証明書をホストするエンドポイントの場合は、証明書を MID サーバー トラストストアにインポートするか、そのホストを検証するポリシーチェックを無効にします。証明書の追加方法の詳細については、「MID サーバー用の SSL 証明書を追加する」を参照してください。
Quebec にアップグレードした後、証明書チェックポリシーテーブルに移動し、必要に応じてポリシー構成を変更します。MID サーバーが起動してインスタンスに接続すると、MID サーバーから発生する後続の HTTPS 接続は実行時にこれらの証明書チェックの適用を開始します。安全でない接続は切断され、適切なエラーメッセージが表示されます。
インスタンスセキュリティポリシーの使用
MID サーバー設定パラメーター mid.ssl.use.instance.security.policy は、MID サーバーがインスタンスのセキュリティポリシーではなくブートストラップパラメーターを使用するかどうかを制御します。デフォルトでは、config.xml で mid.ssl.use.instance.security.policy は false に設定されているため、インスタンスによってブートストラップポリシーが上書きされることはありません。
このデフォルト設定により、MID サーバーのセットアップ中にいくつかの問題を防ぐことができます。たとえば、ホストが OCSP レスポンダーに到達できない場合、新しい MID サーバーのインストールは OCSP 接続を要求するインスタンスのポリシーによって中断されません。
設定パラメーター mid.ssl.use.instance.security.policy は、各 MID サーバーに設定できます。true に設定すると、MID サーバーはすべてのポリシーをインスタンスと同期し、ブートストラップ設定パラメーターはインスタンスの mid_cert_check_policy テーブルの *.servicenow.com ポリシーによって上書きされます。最終的なポリシーは、MID サーバーメモリ内のポリシーマップと config.xml を更新します。
<parameter name="mid.ssl.bootstrap.default.check_cert_hostname" value="true"/><parameter name="mid.ssl.bootstrap.default.check_cert_chain" value="true"/><parameter name="mid.ssl.bootstrap.default.check_cert_revocation" value="false"/><parameter name="mid.ssl.use.instance.security.policy" value="false"/>
セルフホストまたはオンプレミスのインスタンスでは、config.xml に次のパラメーター、<parameter name="mid.ssl.bootstrap.default.target_endpoint" value="FQDN_OF_THE_INSTANCE"/> を追加する必要があります。