Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページで
 

NETCONF Sessions over Transport Layer Security(TLS)

概要 NETCONF(ネットワーク構成プロトコル)クライアントは、相互X.509証明書ベース認証とトランスポート層セキュリティ(TLS)プロトコルを使用して、サポートされているJunosデバイスとのNETCONFセッションを確立できます。

NETCONF-over-TLS 接続について

TLS を介した NETCONF のメリット

  • 相互証明書ベースの認証を使用したデバイスのリモート管理が可能

  • SSH経由でNETCONFを使用する場合よりも、大規模なネットワークをより簡単に管理できます。

  • 公開キーインフラストラクチャを使用して、クライアントとサーバーの両方に相互TLS証明書ベースの認証を提供します。

  • NETCONF メッセージの接続と交換を保護します。

  • 交換されたメッセージのデータ整合性を保証

NETCONF over TLSの概要

SSH経由でNETCONFセッションを確立する代わりに、特定のJunosデバイスでトランスポート層セキュリティ(TLS)を介してネットワーク構成プロトコル(NETCONF)セッションを確立できます。TLSは、相互証明書ベースの認証を使用する暗号プロトコルであり、2台のデバイス間で安全で信頼性の高い接続を提供します。これは、SSL(セキュア ソケット レイヤー)プロトコルの後継です。TLS を介して NETCONF セッションを確立すると、NETCONF サーバーは TLS サーバーとして機能し、NETCONF クライアントは TLS クライアントになります。

TLSを介したNETCONFセッションは、SSHを使用するセッションよりもいくつかの利点を提供します。SSHは認証情報(ユーザー名とパスワード)またはキーを使用してクライアントを認証しますが、TLSは証明書を使用してクライアントとサーバーの両方を相互に認証します。証明書はクライアントに関する追加情報を提供でき、1台のデバイスを安全に認証するために使用できます。そのため、SSHを介したNETCONFセッションは個々のデバイスを手動で管理するのに適していますが、TLSを使用するNETCONFセッションでは、セキュアなデバイス間通信を可能にし、大規模ネットワークのデバイスをより適切に管理および自動化できます。

Junos デバイスとの NETCONF-over-TLS セッションには、以下の要件があります。

  • TLS バージョン 1.2 をサポートする NETCONF クライアント

  • サーバーとクライアントには、認証局によって署名された X.509 公開鍵証明書が必要です。

  • Junos 公開鍵基盤(PKI)には、適切なローカル証明書と CA 証明書が読み込まれている必要があります。

  • Junos デバイスは、TLS 上の NETCONF 用に構成され、クライアントのデフォルトまたは特定の証明書から NETCONF へのユーザー名マッピングを定義します。

  • NETCONF ユーザー名は、有効な Junos OS ユーザー アカウントに対応します。

TLS は、サーバーとクライアントの認証に X.509 デジタル証明書を使用します。デジタル証明書とは、認証 機関 または 認証機関(CA)と呼ばれる信頼できる第三者を通じて身元を確認するための電子的手段です。認証機関はデジタル証明書を発行します。この証明書は、証明書の検証によって 2 つのエンドポイント間のセキュアな接続を確立するために使用できます。X.509 標準では、証明書の形式が定義されています。サポートされているJunosデバイスでTLSを介してNETCONFセッションを確立するには、サーバーとクライアントの両方に有効なX.509証明書が必要です。証明書はCAによって署名されている必要があります。自己署名証明書を使用してTLS上のNETCONFセッションを確立することはできません。

Junos OS PKI は、デジタル証明書管理用のインフラストラクチャを提供します。TLS 接続を確立するには、Junos OS PKI に以下をインストールする必要があります。

  • NETCONF サーバーのローカル証明書とその中間 CA 証明書

    メモ：

    サーバー証明書チェーンに中間 CA が含まれていない場合は、ルート CA 証明書を構成する必要があります。

  • NETCONF クライアント証明書または証明書チェーンの検証に必要な NETCONF クライアントのルート CA 証明書

サーバーはクライアントの ID を検証し、TLS 接続を確立した後、NETCONF セッションを確立する前にそのクライアントの NETCONF ユーザー名を導き出す必要があります。NETCONF ユーザー名は、NETCONF 操作が実行されるアクセス権限と権限を持つ Junos ユーザー アカウントです。クライアント証明書とNETCONFのユーザー名マッピングのリストを設定したり、デフォルトのNETCONFユーザー名マッピングを設定することもできます。Junos OSは、クライアント証明書が設定されたクライアントのいずれにも一致しない場合、デフォルトマッピングを使用します。サーバーが有効な NETCONF ユーザー名を抽出した場合、NETCONF セッションを確立します。NETCONF ユーザー名の派生の詳細については、「 TLS クライアントから NETCONF ユーザー名マッピングについて」を参照してください。

Junos プロセス tls プロキシは、TLS 接続を処理します。これは、TLSハンドシェイクを実行し、トラフィックを暗号化および復号化し、NETCONFユーザー名を決定し、NETCONFユーザーの認証パラメーターを取得します。tlsプロキシされたプロセスは、管理プロセス(mgd)と連携して動作し、NETCONFセッションを作成および管理します。NETCONF-over-TLSセッションワークフローは、 NETCONF-over-TLS接続ワークフローで概要を説明しています。

TLS 上の NETCONF の詳細については、 RFC 7589, Using the NETCONF Protocol over Transport Layer Security(TLS)with Mutual X.509 Authentication を参照してください。

トランスポート層セキュリティプロトコルの詳細については、RFC 5246、 トランスポート層セキュリティ(TLS)プロトコルバージョン1.2を参照してください。

TLS クライアントから NETCONF ユーザー名へのマッピングについて

NETCONF-over-TLS クライアントの認証済み ID は、NETCONF ユーザー名です。Junos デバイスは、このユーザーのアカウント権限で NETCONF 操作を実行します。個々のクライアントのNETCONFユーザー名を導き出すために使用するメソッドを設定することも、構成済みのクライアントに一致しないクライアントのNETCONFユーザー名を導き出すデフォルトメソッドを定義することもできます。

クライアント証明書の NETCONF ユーザー名へのマッピングを 階層レベルで [edit system services netconf tls client-identity] 構成できます。クライアントごとに、証明書フィンガープリントとマップ タイプを設定します。クライアント証明書のフィンガープリントが設定されたフィンガープリントと一致する場合、Junos OS は対応するマップ タイプを使用して NETCONF ユーザー名を導き出します。クライアントごとに1つのフィンガープリントのみを設定でき、各クライアントフィンガープリントは一意である必要があります。例えば：

設定された証明書フィンガープリントは、RFC 7407、 SNMP設定のYANGデータモデルで定義されているx509c2n:tls-フィンガープリント形式を使用します。この形式では、最初のオクテットはハッシュアルゴリズム識別子で、残りのオクテットはハッシュアルゴリズムの結果です。参照のためにここに示されているハッシュアルゴリズム識別子は、 RFC 5246、 トランスポート層セキュリティ(TLS)プロトコルバージョン1.2で定義されています。

  • md5: 1

  • sha1:2

  • sha224:3

  • sha256:4

  • sha384:5

  • sha512:6

また、 階層レベルで NETCONF ユーザー名のデフォルト マッピングを [edit system services netconf tls default-client-identity] 設定することもできます。クライアント証明書のフィンガープリントが構成済みのクライアントと一致しない場合、Junos デバイスはデフォルトのマップ タイプを使用して NETCONF ユーザー名を導き出します。

Junos デバイスは、以下のマップ タイプをサポートしています。

  • san-dirname-cn—NETCONF ユーザー名としてクライアント証明書の SubjectAltName(SAN)DirName フィールド()に定義された共通名(DirName:/CNCN)を使用します。

  • specified— 同じ階層レベルの ステートメントで定義された username NETCONF ユーザー名を使用します。

サーバーはクライアントの ID を検証し、TLS 接続を確立した後、NETCONF ユーザー名を導き出します。最初に、設定された各クライアントのフィンガープリントと、提示された証明書のフィンガープリントを照合します。一致する場合は、対応するマップ タイプを使用して NETCONF ユーザー名を取得します。構成されたフィンガープリントのどれもクライアントの証明書と一致しない場合、NETCONF ユーザー名の導き出しにデフォルト マップ タイプが使用されます。

サーバーがユーザー名を決定した後、ローカルまたはリモートでユーザーの許可を取得します。ユーザー名は、デバイスでローカルに定義されたユーザーアカウントを持っているか、軽量ディレクトリアクセスプロトコル(LDAP)サーバーで認証する必要があります。その後、Junosデバイス上でローカルに定義されたユーザーテンプレートアカウントにマッピングします。抽出したユーザー名が有効なローカル ユーザーまたはリモート ユーザーでない場合、TLS 接続は終了します。

NETCONF-over-TLS接続ワークフロー

Junos デバイスは、TLS および NETCONF サーバーとして機能します。サーバーは、TCP ポート 6513 で受信 NETCONF-over-TLS 接続をリッスンします。NETCONF クライアント(TLS クライアント)は、そのポート上のサーバーとの接続を開始します。

クライアントとサーバーは、TLS を介して NETCONF セッションを確立して使用するために、以下のアクションを実行します。

  1. クライアントは TLS ClientHello メッセージを送信して TLS ハンドシェイクを開始します。

  2. サーバーは、ServerHello メッセージ、サーバー証明書チェーン、および CertificateRequest メッセージを送信して、クライアントから証明書を要求します。

  3. クライアントはサーバーのIDを検証し、クライアント証明書チェーンを送信します。

  4. サーバーは、サーバー上で事前に構成されたクライアントのルートCAを使用して、クライアント証明書チェーンを検証します。

  5. サーバーは、そのクライアントの NETCONF ユーザー名を取得します。

  6. NETCONF ユーザー名が有効な場合、サーバーは NETCONF セッションを開始し、サーバーとクライアントは NETCONF <hello> メッセージを交換します。

  7. クライアントは、NETCONF ユーザーのアクセス権限と権限を使用して NETCONF 操作を実行します。

  8. クライアントは操作を <close-session> 実行して NETCONF セッションを終了し、その後 TLS 接続を閉じます。

以下のシナリオでは、サーバーが TLS を介して NETCONF セッションを確立できません。

  • サーバーまたはクライアント証明書の有効期限切れまたは自己署名。

  • クライアントは証明書を提供しません。

  • クライアントは中間 CA 証明書を送信しません。

  • クライアントのルート CA 証明書がサーバーに構成されていません。

  • サーバーは、構成済みマップ タイプまたはデフォルト マップ タイプにクライアント証明書をマッピングして、NETCONF ユーザー名を取得できません。

  • サーバーはマップ タイプを san-dirname-cn 使用してクライアントの NETCONF ユーザー名を取得しますが、クライアントの証明書では対応するフィールドにユーザー名は指定されません。

「」も参照

TLSを介してNETCONFセッションを確立する方法

ネットワーク管理システム(NMS)を使用して、Junos デバイスをリモート管理します。ネットワーク管理システムとサポートされているJunosデバイス間で、TLSを介してNETCONFセッションを確立できます。NMS は NETCONF および TLS クライアントであり、Junos デバイスは NETCONF および TLS サーバーです。

クライアントとサーバーが TLS を介して NETCONF セッションを確立する前に、以下のセクションで説明する要件を満たす必要があります。

ネットワーク管理システムへのTLSクライアントソフトウェアのインストール

TLS を使用して NETCONF セッションを確立するには、ネットワーク管理システムが最初に Junos デバイスとの TLS 接続を確立する必要があります。したがって、ネットワーク管理システムは、TLS プロトコルを管理するためのソフトウェアを必要とします。たとえば、トランスポートレイヤーセキュリティ(TLS)およびSSL(セキュアソケットレイヤー)プロトコル用のツールキットであるOpenSSLツールキットをインストールして使用できます。これはApacheスタイルのライセンスでライセンスされています。

OpenSSL の詳細については、「 https://www.openssl.org」を参照してください。

サーバーとクライアントの X.509 証明書を取得する

TLS プロトコルは、X.509 公開キー証明書を使用して、サーバーとクライアントの ID を認証します。TLS を介して NETCONF セッションを確立するには、サーバーとクライアントの両方に X.509 証明書が必要です。証明書は有効な認証機関(CA)によって署名されている必要があります。TLSを介したNETCONFセッションでは、自己署名証明書は受け入れされません。

OpenSSL を使用して NETCONF クライアントの証明書を取得するには、次の手順にしたがっています。

  1. 秘密鍵を生成し、鍵長をビット単位で指定します。
    メモ：

    Junosデバイスは、TLS上のNETCONFセッションで楕円曲線デジタル署名アルゴリズム(ECDSA)キーを使用してサポートしていません。
  2. クライアントの証明書で NETCONF ユーザー名を定義する場合は、openssl.cnf または同等の設定ファイルを更新して拡張子をsubjectAltName=dirName定義し、NETCONF ユーザー名を指定します。
  3. エンティティの公開鍵とアイデンティティに関する情報を含む証明書署名要求(CSR)を生成します。
  4. 以下のいずれかを実行して証明書を生成します。

    • CSR を認証機関に送信して X.509 証明書を要求し、追加の拡張を含む構成ファイルを提供します。

    • CA を使用して CSR に署名してクライアント証明書を生成し、構成ファイルと拡張子を -extfile 参照する必要がある場合は、 および -extensions オプションを含めます。

  5. 共通名(CN)フィールドと拡張(提供されている場合)が正しいことを確認します。

同様に、サーバー証明書を生成します。

  1. 秘密鍵を生成し、鍵長をビット単位で指定します。

  2. 証明書署名要求(CSR)を生成します。

  3. 以下のいずれかを実行して証明書を生成します。

    • CSR を認証機関に送信し、X.509 証明書を要求します。

    • CA で CSR に署名し、サーバー証明書を生成します。

Junos OS PKI(公開鍵基盤)は、デジタル証明書管理用のインフラストラクチャを提供します。また、Junos OS PKI を使用して、サーバーのローカル証明書に必要なキー ペアと CSR を生成することもできます。Junos OS PKI および証明書の取得方法については、 PKI を使用したデジタル証明書の概要 と関連ドキュメントを参照してください。

Junos PKI へのサーバーのローカル証明書のインストール

サーバーのローカル証明書は、NETCONF および TLS サーバーとして動作する Junos デバイスの X.509 証明書です。Junos PKI でデバイスのローカル証明書をインストールする必要があります。

Junos PKI にサーバーのローカル証明書をインストールするには、次の手順にしたがっています。

  1. 証明書と秘密鍵をJunosデバイスにコピーします。
  2. Junos PKI を使用して、指定されたファイルから証明書を読み込みます。

    一意の証明書識別子を定義し、証明書と秘密鍵またはキーペアへのファイルパスを指定します。例えば：

  3. (オプション)証明書を確認します。

Junos PKI への CA 証明書のインストール

デジタル証明書とは、 認証機関(CA)と呼ばれる信頼できる第三者を通じて身元を確認するための電子的手段です。TLS を介して NETCONF セッションを確立する場合、クライアントとサーバーは、アイデンティティを認証するために X.509 デジタル証明書をそれぞれ持っている必要があります。Junos PKI(公開鍵基盤)内のクライアント証明書を検証するために必要なルート CA 証明書を設定する必要があります。また、Junos PKI でサーバーのローカル証明書を検証するために必要な CA も構成する必要があります。そのため、CA ごとに認証局プロファイルを設定し、対応する CA 証明書および証明書失効リスト(CRL)を読み込みます。この設定により、Junos デバイスは CA に対して証明書を検証できます。

メモ：

サーバー証明書チェーンに中間 CA が含まれていない場合は、ルート CA 証明書を構成する必要があります。それ以外の場合は、中間 CA のみを設定する必要があります。

CA プロファイルを手動で構成し、対応する CA 証明書と CRL を読み込むには、以下の手順にしたがっています。

  1. CA 証明書と必要な CA 証明書失効リスト(CRL)を Junos デバイスにダウンロードします。
  2. 例えば、必要な各 CA に対して信頼できる CA プロファイルを設定します。
  3. Junos PKI で、クライアントのルート CA プロファイルに関連付けられている CA 証明書を読み込み、証明書ファイルの場所を指定します。
  4. Junos PKI でサーバーの CA プロファイルに関連付けられている CA 証明書を読み込み、証明書ファイルの場所を指定します。

    • 証明書チェーンにルート CA のみが含まれている場合は、ルート CA 証明書を読み込みます。

    • 証明書チェーンに中間 CA が含まれている場合は、中間 CA 証明書のみを読み込む必要があります。

  5. 例えば、必要に応じて特定の CA プロファイルの CRL を読み込みます。
    メモ：

    特定のCAプロファイルに証明書失効リストを設定しない場合、 ステートメントを で設定することで失効チェックを revocation-check disable 無効にする必要があります。 [edit security pki ca-profile profile-name] hierarchy level.
  6. (オプション)CA 証明書を確認します。

TLS上でNETCONFサービスを有効にする

TLS上でNETCONFを有効にするには:

  1. サーバーのローカル証明書 ID を構成し、証明書のインストール時に定義された ID を参照します。
  2. サーバーが特定のクライアントの NETCONF ユーザー名を取得する方法を定義します。
  3. (オプション)TLSを介したNETCONFセッションのトレースオプションを設定します。
  4. 設定をコミットします。

TLSクライアントとNETCONFのユーザー名マッピングを設定する

クライアント証明書と特定のクライアントのNETCONFユーザー名間のマッピングを定義できます。特定のクライアントにマッピングを定義しない場合、クライアントがTLS上でNETCONFセッションを確立するためには、デフォルトのマッピングを定義する必要があります。

マッピングを定義して、特定のクライアントの NETCONF ユーザー名を導き出すには、次のようにします。

  1. クライアントの証明書のフィンガープリントを決定するには、ネットワーク管理システム上の環境に適したコマンドと証明書の形式を実行します。
  2. RFC 5246、 トランスポート層セキュリティ(TLS)プロトコルバージョン1.2で定義されているフィンガープリントのハッシュアルゴリズム識別子を決定します。

    この例では、識別子値4に対応するSHA-256ハッシュアルゴリズムを使用しています。

    • md5: 1

    • sha1:2

    • sha224:3

    • sha256:4

    • sha384:5

    • sha512:6

  3. Junos デバイスで、クライアントの一意の識別子を定義します。
  4. クライアントの証明書フィンガープリントを x509c2n:tls-フィンガープリント形式で構成します。

    フィンガープリントの最初のオクテットはハッシュ アルゴリズム識別子で、残りのオクテットはハッシュ アルゴリズムの結果です。

  5. サーバーがそのクライアントの NETCONF ユーザー名を導き出す方法を定義するマップタイプを設定します。
  6. マップタイプが の場合、specifiedそのクライアントに使用するNETCONFユーザー名を設定します。
  7. 設定をコミットします。

デフォルト NETCONF ユーザー名マッピングの設定

クライアントが 階層レベルで設定されたクライアントに一致しない場合、NETCONF ユーザー名を導き出すために使用されるデフォルト マッピングを [edit system services netconf tls client-identity] 定義できます。

NETCONF ユーザー名を導き出すデフォルト マッピングを定義するには、

  1. サーバーが NETCONF ユーザー名を導き出すために使用するデフォルト マップ タイプを構成します。
  2. マップ タイプが の場合、specifiedデフォルトの NETCONF ユーザー名を設定します。
  3. 設定をコミットします。

NETCONFユーザーのユーザーアカウントを設定する

TLSを介してNETCONFセッションを確立すると、サーバーはクライアント証明書を、そのセッションのデバイス上で操作を実行するNETCONFユーザーにマッピングします。Junos OSは、NETCONF-over-TLSセッションのローカルユーザーとLDAPリモートユーザーをサポートします。NETCONFユーザーは、デバイス上でローカルに定義されたユーザーアカウントを持っているか、LDAPサーバーで認証する必要があります。その後、デバイス上でローカルに定義されたローカルユーザーテンプレートアカウントにマッピングする必要があります。次の手順では、Junos デバイスでユーザー アカウントを作成する方法について説明します。

Junos デバイスで NETCONF ユーザーのユーザー アカウントを作成するには、次の手順に従います。

  1. ステートメントを一意のuserユーザー名で設定し、 ステートメントをclass含めて、ユーザーが実行するすべてのアクションに必要な権限を持つログインクラスを指定します。

    例えば、以下の設定は 2 つのユーザーを定義しますnetconf-default-user。 netconf-user

  2. (オプション)および full-name ステートメントをuid設定して、ユーザーのIDと名前を指定します。
  3. 設定をコミットして、デバイス上のユーザーアカウントをアクティブにします。
  4. クライアントがTLSを介してNETCONFセッションを確立する各Junosデバイスで、前述の手順を繰り返します。

「」も参照

NETCONF-over-TLS セッションを開始する

ネットワーク管理システムは、NETCONF および TLS クライアントとして機能します。任意のソフトウェアを使用してTLSプロトコルを管理し、JunosデバイスとのNETCONF-over-TLSセッションを開始できます。

NETCONF-over-TLS セッションを開始するには、以下の手順にしたがっています。

  1. ポート6513でNETCONFサーバーへの接続を開始し、クライアントの証明書とキー、サーバーのルートCA証明書、クライアント証明書の検証に必要なすべての中間CA証明書を提供します。
  2. セッションが正しい NETCONF ユーザーにマッピングされていることを確認します。

    サーバーは、セッション確立中にそのセッションのNETCONFユーザー名を送信します。

  3. 必要に応じてNETCONF操作を実行します。
  4. NETCONF セッションと TLS 接続を閉じます。