--- sourceDocument: オーストラリア ServiceNow AI Platform の機能 sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/servicenow-platform Release : - australia ft:locale : - ja-JP ft:publication_title : - オーストラリア ServiceNow AI Platform の機能 ft:clusterId : - platcap bundleId : - platcap workflow : - Platform --- # MID サーバー証明書チェックポリシー # MID サーバー証明書チェックポリシー {#ariaid-title1} * リリースバージョン: Australia * * 更新日 2026年03月12日 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：9分 MID サーバーは、4 種類のセキュリティチェックを使用して外部トラフィックを保護します。セキュリティチェックでは、TLS/SSL 証明書の検証、ホスト名の検証、証明書失効リスト (CRL)、およびオンライン証明書ステータスプロトコル (OCSP) の検証を使用してセキュリティを強化します。MID サーバー 証明書チェックポリシーテーブルを使用して、これらのセキュリティチェックを制御します。 |-| | | [ ] {#mid-security-checks__table_m2t_cv4_nhb} ## TLS/SSL 証明書の検証 {#mid-security-checks__section_w5g_d2n_mnb} TLS/SSL 暗号化セキュリティでは、公開鍵暗号化とも呼ばれる非対称暗号化を使用します。この暗号化では、公開鍵と秘密鍵の 2 つの暗号鍵を使用します。公開鍵はデータの暗号化に使用され、公開されます。秘密鍵はデータの復号化に使用され、そのセキュリティは信頼性を検証するために不可欠です。ネットワークの準備の詳細については、次を参照してください。 [MID サーバー TLS/SSL 証明書チェックポリシー Quebec アップグレード情報 \[KB0867397\]](https://support.servicenow.com/kb_view.do?sysparm_article=KB0867397). TLS/SSL 証明書の検証では、MID サーバーは TLS または SSL 証明書で保護された Web サーバーへの接続を試行します。Web サーバーは、TLS/SSL 証明書のコピーを MID サーバーに送信します。MID サーバーは証明書の信頼性を確認し、メッセージを Web サーバーに送信します。Web サーバーは、TLS/SSL 暗号化セッションを開始するためのデジタル署名された承認で応答します。その後、MID サーバーは Web サーバーとの暗号化された通信を開始できます。 ## ホスト名の検証 {#mid-security-checks__section_kdd_12n_mnb} ホスト名の検証は、クライアントが正しいサーバーと通信していることを確認するためのサーバー ID チェックを含む HTTPS の一部です。このチェックは、中間者攻撃によってリダイレクトされた後にサーバーに情報を送信することを防ぎます。 このチェックでは、サーバーから送信された証明書の `dnsName` が、要求の実行に使用された URL と一致することを確認します。RFC 6125 に従い、ホスト名の検証は、証明書の subjectAlternativeName の dNSName フィールドに対して実行する必要があります。一部の従来の実装では、証明書の commonName フィールドに対してチェックが行われます。名前が一致しない場合、接続が終了します。 注: ホスト名の検証では、サーバーによって提示された検証済みの証明書からホスト名を取得します。そのため、TLS 証明書の検証は、ホスト名検証の前提条件です。 ## オンライン証明書ステータスプロトコル (OCSP) {#mid-security-checks__section_zht_c2n_mnb} OCSP では、MID サーバーがターゲットサーバーとさらに通信する前に、リモート認証局サーバーに接続して証明書を検証します。特にこれらの証明書に他の証明書に署名する機能がある場合、侵害された証明書はセキュリティ上の脆弱性となる可能性があります。証明書が壊れているか偽造されている場合、認証局はどの証明書が無効で使用すべきでないかをクライアントに通知できます。 OCSP レスポンダ (通常は証明書発行者によって実行されるサーバー) は、証明書が「良好」、「失効」、または「不明」であるという署名付き応答を返します。要求を処理できない場合は、エラーコードが返されることがあります。 証明書の発行者は、別の権限を OCSP レスポンダとして委任することができます。これにより、検証が必要な一連の証明書が作成されます。レスポンダの証明書は、問題の証明書の発行者が発行する必要があります。レスポンダの証明書には、それを OCSP 署名機関としてマークする特定の拡張子を含める必要があります。 注: OCSP チェックは、OCSP レスポンダに対して行われるセカンダリ HTTP 呼び出しです。プライマリコールは、OCSP レスポンダからの応答に基づいて接続を中断する場合があります。 ## 証明書失効リスト (CRL) {#mid-security-checks__section_gjh_p3c_l3c} CRL チェックは、証明書の失効ステータスを確認するための OCSP の代替手段を提供します。MID サーバーは、ライブ OCSP レスポンダーをクエリするのではなく、認証局 (CA) によって提供される URL から証明書失効リスト (CRL) をダウンロードしてキャッシュします。次に、MID サーバーは、SSL/TLS ハンドシェイク中に、ローカルにキャッシュされた CRL に対して証明書の失効ステータスをチェックします。証明書が CRL に表示される場合、MID サーバーは接続を拒否し、イベントをログに記録します。 CRL はローカルにキャッシュされ、CA の更新スケジュールに基づいて定期的に更新されます。CRL のダウンロードが失敗した場合、システムは設定可能な再試行ポリシーに従って再試行します。 注: 2025 年 5 月 7 日の時点で、Let's Encrypt は発行された証明書に OCSP URL を含めなくなり、認証局で OCSP をオプションにし、CRL サポートを義務付けた CA/ブラウザーフォーラムの投票用紙 SC-063 を受けて、OCSP レスポンダーを廃止しました。CRL チェックにより、OCSP のサポートが終了した CA によって発行された証明書の証明書失効検証が継続されます。 ## MID サーバーセキュリティポリシー {#mid-security-checks__section_q4l_qws_snb} MID サーバーのセキュリティ方針は、MID サーバーから発信されるすべての HTTPS トラフィックを制御します。これには、MID サーバーからインターネットエンドポイント、ServiceNow URL、イントラネットエンドポイント、およびクラウドエンドポイントへの HTTPS 接続が含まれます。 これらの接続は、さらに次の 4 つのセキュリティ方針に分類できます。 ServiceNow エンドポイントポリシー : このポリシーは、ServiceNow URL 専用のシステムデフォルトです。MID サーバーの config.xml には、インスタンスへの最初の接続にのみ使用され、system_default ポリシーで更新されるブートストラッププロパティがあります。 インターネットポリシー : これらのポリシーは、MID サーバーからインターネット上のエンドポイントへのすべての HTTPS 接続を対象とします。 イントラネットポリシー : これらのポリシーは、セルフホストネットワークなどの予約済み IP サブネットを対象とします。 上書きされたポリシー : このポリシー定義を使用して、特定のエンドポイントまたは URL を上書きできます。上書きされたポリシーは、操作時に最も優先順位が高くなります。 どちらのテーブルも編集可能で、IP 範囲を含めたり除外したりするだけでなく、実行する必要がある証明書検証チェックの種類を制御することもできます。セキュリティを最大化するために、すべての証明書検証チェックを有効にします。Quebec バージョンでは、新規インストールのすべてのポリシーとチェックがデフォルトでオンになっています。 アップグレードした場合、イントラネットポリシーでは証明書検証チェックはデフォルトで無効になっています。セキュリティを強化するには、内部ネットワーク内のエンドポイントのポリシーを設定して有効にします。 注: 接続を成功させるには、内部エンドポイントまたは URL に有効な CA 署名付き証明書がある必要があります。 自己署名証明書をホストするエンドポイントの場合は、証明書を MID サーバー トラストストアにインポートするか、そのホストを検証するポリシーチェックを無効にします。証明書の追加方法の詳細については、「[MID サーバー用の SSL 証明書を追加する](https://servicenow-prod.fluidtopics.net/1BYppVm34Jt9PsnXM7c1yA#add-ssl-certificates "SSL 経由でソースにコネクトするように MID サーバーを設定します。")」を参照してください。 Quebec にアップグレードした後、証明書チェックポリシーテーブルに移動し、必要に応じてポリシー構成を変更します。MID サーバーが起動してインスタンスに接続すると、MID サーバーから発生する後続の HTTPS 接続は実行時にこれらの証明書チェックの適用を開始します。安全でない接続は切断され、適切なエラーメッセージが表示されます。 ## インスタンスセキュリティポリシーの使用 {#mid-security-checks__section_vgp_nps_dwb} 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 を更新します。 config.xml のデフォルトパラメーターは次のとおりです。 * `` * `` * `` * `` {#mid-security-checks__ul_wv5_1zx_2wb} セルフホストまたはオンプレミスのインスタンスでは、config.xml に次のパラメーター、`` を追加する必要があります。 **関連概念** * [MID サーバー認証情報と SOAP 要求](https://servicenow-prod.fluidtopics.net/vkEl33bs5oQSiD5da6hQZQ#mid-authentication-soap-requests "Web サービスの発動データを更新するためのベーシック認証情報を設定します。セキュリティを強化するため、MID サーバーへの着信 SOAP 要求ごとにベーシック認証を実施することができます。") * [MID Server 統一キーストア](https://servicenow-prod.fluidtopics.net/rF4bP8PKMA441a9mzrPAIQ#mid-unified-keystore "MID サーバーの統一キーストアでは、MID サーバー上のすべての製品で共通の証明書とキーペアを使用できます。この機能により、アプリケーションは、MID サーバーがインスタンスに接続するために使用するのと同じ、MID サーバーへの安全な通信チャネルを使用できます。") * [MID サーバー コマンド監査ログ](https://servicenow-prod.fluidtopics.net/iJZ0UEUA83kveFL9hJw3Fg "コマンド監査ログには、 ディスカバリー アプリケーションに対して MID サーバー によって実行されたコマンドが記録されます。コマンドを確認して、例外やエラーがないことを確認します。") * [MID サーバーの FIPS 適用モード](https://servicenow-prod.fluidtopics.net/Eu3RQ9854QTFeVdjL3nTYw#mid-fips-enforced "MID サーバーは、National Security Cloud (NSC) IL-5 環境をサポートしています。この環境では、使用するすべての暗号化を FIPS 検証する必要があります。MID サーバーは、FIPS 検証済みの暗号化アルゴリズムのみが使用される FIPS 強制モードで実行できます。") * [MID サーバーガバナンス](https://servicenow-prod.fluidtopics.net/9Cd5bFCwSOuruop03ZG6Uw "非アクティブな MID サーバーを無効にしてシャットダウンする自動タイムアウトを設定することで、MID サーバーのセキュリティを向上させます。この機能を有効にして、非アクティブなタイムアウト期間をグローバルに設定したり、各 MID サーバーに対して設定したりできます。") **関連タスク** * [MID サーバー構成ファイルの値の暗号化または復号化](https://servicenow-prod.fluidtopics.net/y6~oM5L6l8MFDxcGga7DiQ "config.xml ファイル内の任意の MID サーバーパラメーターの値を暗号化できます。すべての暗号化された値の属性は、ログインパスワードのセキュリティ属性を含め、構成ファイル内から管理されます。") * [MID Server 相互認証の有効化](https://servicenow-prod.fluidtopics.net/4DZZIhvugl1iv~MyuRysEg "インスタンスに対する認証にクライアント証明書を使用するように MID サーバーを構成します。これにより、MID サーバー構成のキーストアにベーシック認証情報を作成する必要がなくなります。") * [MID サーバーと Azure Key Vault の統合](https://servicenow-prod.fluidtopics.net/uGvFmtQW5CxJF8qYkboNjA#mid_azure_key_vault_integration "MID サーバーと Azure Key Vault を統合すれば、インスタンスに認証情報を保存しなくても、オーケストレーション、ディスカバリー、サービスマッピングを実行することができます。") * [MID サーバーのリキー](https://servicenow-prod.fluidtopics.net/Z11~3a34xzcTUsPF6qAz0Q "MID サーバーをリキーして、新しい秘密鍵を生成します。秘密鍵は、MID サーバーが情報を安全に送信できるように、自動認証情報を復号化するために使用されます。キーペアは、MID サーバーの検証時に最初に生成され、セキュリティ要件を満たすために定期的に MID サーバーをリキーする必要があります。") * [MID サーバー用の SSL 証明書を追加する](https://servicenow-prod.fluidtopics.net/1BYppVm34Jt9PsnXM7c1yA#add-ssl-certificates "SSL 経由でソースにコネクトするように MID サーバーを設定します。") * [MID サーバーの外部トラストストアを指定します](https://servicenow-prod.fluidtopics.net/HzOIKzqWhXOIjYSBvjjD6g "MID サーバー JVM は、MID インストールディレクトリの外部にあるトラストストアを利用できるため、アップグレード中にトラストストアに追加された証明書が上書きされることはありません。このトラストストアファイルが MID インストールディレクトリの外にあることが重要です。トラストストアの場所は、MID サーバーの wrapper-override.conf ファイルにパラメーターを追加することで指定できます。") * [ファイル同期された MID サーバーへのスクリプトファイルの添付](https://servicenow-prod.fluidtopics.net/hhgjehGQ4aIMOZj7RcIpCw#mid-server-script-attach "スクリプトファイルを添付して、接続された MID サーバーと同期させることができます。") **関連資料** * [MID サーバー構成ファイルのセキュリティ](https://servicenow-prod.fluidtopics.net/KFMa4DhyEQCkjQiYjpsTYw "機密性の高い MID サーバー構成データは、内部および外部のデータ暗号化や外部データ ストレージを含むいくつかの異なるスキームを使用して保護することができます。") * [MID Server SSH 暗号化アルゴリズム](https://servicenow-prod.fluidtopics.net/GNKPfsBu_07rkfmR4NiAYw "MID サーバーは SSH クライアントを利用して多くのディスカバリーアクションを実行します。SSH ハンドシェイクでは、クライアントとサーバーの両方が、最初に双方がサポートするアルゴリズムを決定し、次にクライアントが最も優先度の高いアルゴリズムを選択します。ホストキーアルゴリズムの場合、クライアントは、キータイプに一致する、双方がサポートする最も優先度の高いアルゴリズムを選択します。")