FTP サーバーを TLS 用にカスタマイズするステップ

変更の始まりAT-TLS を使用して 変更の終わりFTP サーバーを TLS 用にカスタマイズできます。

始める前に

以下の情報について理解しておきます。
  • FTP サーバーは、TLS と Kerberos の両方をサポートできるようになっていなければなりません。 一部の構成ステートメントの設定は、TLS と Kerberos の両方に適用され、両方の動作に影響を及ぼします。
  • 変更の始まりFTP サーバーで TLS をサポートさせるには、Application Transparent TLS (AT-TLS) を制御アプリケーションとして使用するように、その FTP サーバーを構成する必要があります。 AT-TLS の詳細は、Application Transparent Transport Layer Security のデータ保護を参照してください。
    注: TLS を使用するには、X.509 デジタル証明書を使用する必要があります。 証明書および鍵リング・データベースについて詳しくは、TLS/SSL セキュリティーを参照してください。
    変更の終わり
要件: AT-TLS では、ポリシー・エージェントが構成され、TCP/IP スタックで AT-TLS が使用可能である必要があります。AT-TLS を構成するには、サーバー・システムの構成を参照してください。

手順

FTP サーバーを TLS 用にカスタマイズするには、以下のステップを実行します。

  1. どのレベルの RFC 4217、「On Securing FTP with TLS」をサーバーにサポートさせるかを決定します。
    • サーバーに「On Securing FTP with TLS」のインターネット・ドラフト・レベルをサポートさせるには、サーバーの FTP.DATA 構成ファイルで次のステートメントをコーディングします。
      TLSRFCLEVEL DRAFT
      これはデフォルトです。z/OS® FTP サーバーは、V1R2 以降、このレベルで TLS セキュリティーをサポートしています。このレベルのサポートを維持するには、FTP.DATA でこのステートメントをコーディングしてください。
    • サーバーに「On Securing FTP with TLS」の RFC 4217 レベルをサポートさせるには、サーバーの FTP.DATA 構成ファイルで次のステートメントをコーディングします。
      TLSRFCLEVEL RFC4217
      RFC「On Securing FTP with TLS」は、2005 年 10 月に RFC 4217 として発行されました。この RFC は、AUTH、CCC、および REIN コマンドの記述でインターネット・ドラフトとは異なります。 RFC 4217 は、AUTH および CCC コマンドをサーバーに送信できる場合に関してインターネット・ドラフトよりも制限が少なく、サーバー REIN 実装の詳細についてより明示的に記述されています。詳しくは、RFC 4217 を参照してください。
  2. サーバーの FTP.DATA 構成ファイルの中に次のステートメントをコーディングし、サーバーを TLS 用に使用可能にします。
    EXTENSIONS AUTH_TLS
  3. TLS セッションにどのレベルの認証を使用するかを決定します。
    • サーバー認証のみ
    • クライアント認証レベル 1
    • クライアント認証レベル 2
    • クライアント認証レベル 3
    サーバー認証とクライアント認証についての詳細は、Secure Socket Layer の概要を参照してください。
  4. サーバー鍵リング・データベースを作成し、必要になる証明書をそのサーバー鍵リング・データベースに追加します。
    それぞれの TLS セッション・ハンドシェークにはサーバー認証が含まれるので、常にこのサーバーの証明書をサーバー鍵リング・データベースに追加する必要があります。サーバー証明書が自己署名されている場合は、TLS を使用してログインするこれらのクライアントの鍵リング・データベースに、その証明書をエクスポートすることも必要です。サーバー証明書が認証局 (CA) により署名される場合は、サーバー証明書の署名に使用する CA 証明書 (サーバー証明書ではない) が、クライアント鍵リング・データベースに入っている必要があります。サーバー認証について詳しくは、サーバー認証を参照してください。

    クライアント認証と自己署名証明書を使用している場合は、クライアント証明書をサーバー鍵リング・データベースにインポートする必要があります。 クライアント証明書が CA により署名される場合は、クライアント証明書ではなく、クライアント証明書に署名するために使用される CA 証明書が、そのサーバー鍵リング・データベースに含まれていることが必要です。 詳しくは、クライアント認証を参照してください。

  5. 変更の始まり FTP.DATA にて TLSMECHANISM ATTLS をコーディングします。これがデフォルト設定です。 変更の終わり
  6. このサーバーにログインするクライアントが、TLS プロトコルの使用の要否を決定します。
    デフォルトは、TLS を使用するかどうかをクライアントに決めさせることです。 この設定は、SECURE_FTP 構成ステートメントを使用してカスタマイズされます。この設定が TLS と Kerberos の両方のセキュリティー動作に影響を及ぼすことを理解しておいてください。

    クライアントが TLS 使用の要否を決定できるようにするために、サーバーの FTP.DATA 構成ファイルの中に次のステートメントをコーディングします。

    SECURE_FTP ALLOWED
    これはデフォルトの設定であり、以下のことを指示します。
    • サーバーが TLS 用にのみ使用可能な場合、クライアントは TLS を使用してログインするか、セキュリティー・メカニズムをまったく使用せずにログインする必要があります。
    • サーバーが Kerberos 用にのみ使用可能な場合、クライアントは Kerberos を使用してログインするか、セキュリティー・メカニズムをまったく使用せずにログインする必要があります。
    • サーバーが TLS と Kerberos のどちらにも使用可能な場合、クライアントは TLS または Kerberos を使用してログインするか、セキュリティー・メカニズムをまったく使用せずにログインできます。
    セキュリティー・メカニズムを使用したログインをクライアントに義務付けるには、サーバーの FTP.DATA 構成ファイルの中に次のステートメントをコーディングします。
    SECURE_FTP REQUIRED
    この設定は、以下のことを指示します。
    • サーバーが TLS 用にのみ使用可能な場合、クライアントは TLS を使用してログインする必要があります。
    • サーバーが Kerberos 用にのみ使用可能な場合、クライアントは Kerberos を使用してログインする必要があります。
    • サーバーが TLS と Kerberos のどちらにも使用可能な場合、クライアントは TLS か Kerberos を使用してログインする必要があります。
  7. クライアント認証を使用したくない場合は、サーバーの FTP.DATA 構成ファイルの中に次のステートメントをコーディングできます。
    SECURE_LOGIN NO_CLIENT_AUTH
    これはデフォルトです。

    クライアント認証を使用したい場合は、以下のクライアント認証レベルを使用できます。

    • レベル 1 の認証は、システム SSL によって実行されます。クライアントは X.509 証明書をサーバーに渡します。 認証を渡すには、クライアント証明書に署名した認証局が、 サーバーに信頼されていると考える必要があります。レベル 1 のクライアント認証を使用するには、サーバーの FTP.DATA 構成ファイルの中に次のステートメントをコーディングします。
      SECURE_LOGIN REQUIRED
    • レベル 2 の認証では、レベル 1 の認証が提供され、さらに、クライアント証明書が RACF® (またはその他の SAF 準拠のセキュリティー製品) に登録され、ユーザー ID にマップされることが必要です。SSL ハンドシェーク時に受信されるクライアント証明書は、接続ネゴシエーションの前にセキュリティー製品に照会して、証明書がシステムに既知のユーザー ID にマップされることを確認するために使用されます。レベル 2 のクライアント認証を使用するには、サーバーの FTP.DATA 構成ファイルの中に次のステートメントをコーディングします。
      SECURE_LOGIN VERIFY_USER
    • レベル 3 の認証は、レベル 1 および 2 の認証を提供します。 それに加えて、RACF から戻されるユーザー ID に基づいて、サーバーへのアクセスを制限する機能も提供します。RACF の SERVAUTH クラスがアクティブであり、サーバーのポート・プロファイルが定義されている場合は、クライアント証明書に関連した要求側のユーザー ID がサーバーのポート・プロファイル内で定義されている場合のみ、接続が受け入れられます。レベル 3 のクライアント認証を使用するには、サーバーの FTP.DATA 構成ファイル内に以下のステートメントをコーディングします。
      SECURE_LOGIN VERIFY_USER
      さらに、RACF の SERVAUTH クラス内にサーバーのポート・プロファイルを定義します。

    クライアント認証の使用を選択した場合は、クライアント証明書認証プロセスを使用してクライアント・ログイン・パスワード・プロンプトを除去することもできます。その場合、クライアントはログイン・ユーザー ID を提供するだけでセッションを確立できます。 クライアントから受信した証明書は、セキュリティー製品の中に登録されている必要があり、ログイン・ユーザー ID へ関連付けられている必要があります。 証明書の登録と関連付けを行うには、RACDCERT ADD コマンドを使用します。 証明書が登録されていないか、ユーザー ID へ関連付けられていない場合は、パスワードの入力を求めるプロンプトが出されます。

    クライアント認証プロセスを使用してクライアント・パスワード・プロンプトを除去したくない場合は、サーバーの FTP.DATA 構成ファイルの中に次のステートメントをコーディングできます。

    SECURE_PASSWORD REQUIRED
    これはデフォルトです。

    クライアント認証プロセスを使用して、クライアント・パスワード・プロンプトをクライアント認証ステートメント (SECURE_LOGIN REQUIRED または SECURE_LOGIN VERIFY_USER) と一緒に除去したい場合は、サーバーの FTP.DATA 構成ファイルの中に次のステートメントをコーディングできます。

    SECURE_PASSWORD OPTIONAL
  8. FTP サーバー用に AT-TLS ポリシーを構成します。
    AT-TLS を構成するには、サーバー・システムの構成を参照してください。
    要件:
    • FTP サーバーは制御アプリケーションです。制御アプリケーションについて詳しくは、拡張アプリケーションに関する考慮事項を参照してください。

      ApplicationControlled および SecondaryMap パラメーターを指定して TTLSEnvironmentAdvancedParms ステートメントをコーディングします。どちらのパラメーターも値 On を指定する必要があります。ApplicatonControlled パラメーターにより、FTP は接続で TLS セキュリティーの開始と停止を行うことができます。SecondaryMap パラメーターは、アクティブまたはパッシブ・データ接続が、制御接続に使用される AT-TLS ポリシーを使用できるようにします。データ接続に追加の TTLSRule ステートメントをコーディングする必要はありません。

    • FTP サーバーでは、値 Server または ServerWithClientAuth を持つ HandshakeRole パラメーターが、TTLSEnvironmentAction ステートメントでコーディングされなければなりません。 SECURE_LOGIN ステートメントが、REQUIRED または VERIFY_USER パラメーターを伴って FTP.DATA でコーディングされる場合、HandshakeRole パラメーターの値は ServerWithClientAuth でなければなりません。
    • FTP サーバーの TTLSRule ステートメントでは、値 Inbound を持つ Direction パラメーターが必要です。

    AT-TLS に必要なポリシー構成ステートメントを表示する、ポリシー・エージェント AT-TLS 構成の例は次のとおりです。

       TTLSGroupAction  secure_ftp_server_group
       {
          TTLSEnabled On
       }
       TTLSEnvironmentAction secure_ftp_server_env
       {
          TTLSKeyringParms
          {
             Keyring 変更の始まりFTPD/変更の終わりserver-keyring-database
          }
          HandshakeRole Server       # When Secure_Login NO_CLIENT_AUTH is coded
          #HandshakeRole ServerWithClientAuth # When Secure_Login Required or Verify_User is coded
          TTLSEnvironmentAdvancedParms
          {
             ApplicationControlled On
             SecondaryMap  On変更の始まり
             TLSv1 Off
             TLSv1.1 On
             TLSv1.2 On
             TLSv1.3 On変更の終わり
          }
          TTLSCipherParmsRef   ftp_server_ciphers     # Used to customize ciphersuites for the FTP 
                                                      # server
       }
    TTLSCipherParms ftp_server_ciphers 
    {
       # Sample ciphers.  Should be customized!
       変更の始まりV3CipherSuites TLS_RSA_WITH_AES_256_CBC_SHA
       V3CipherSuites TLS_DHE_DSS_WITH_AES_256_CBC_SHA
       V3CipherSuites TLS_DHE_RSA_WITH_AES_256_CBC_SHA
       V3CipherSuites TLS_RSA_WITH_AES_128_CBC_SHA
       V3CipherSuites TLS_DHE_DSS_WITH_AES_128_CBC_SHA
       V3CipherSuites TLS_DHE_RSA_WITH_AES_128_CBC_SHA
       V3CipherSuites TLS_AES_128_GCM_SHA256
       V3CipherSuites TLS_AES_256_GCM_SHA384変更の終わり 
    }
    
       TTLSRule secure_ftp_server_rule
       {
          LocalPortRange 21                   # This should be set to the port the FTP server is
                                              #  listening on
          Direction Inbound
          TTLSGroupActionRef secure_ftp_server_group
          TTLSEnvironmentActionRef secure_ftp_server_env
       }
    ヒント: 変更の始まり他の多くの TLS 設定を AT-TLS ポリシーで構成できます。 変更の終わり

    変更の始まりFTP サーバー用の AT-TLS ポリシー規則を定義する場合は、許容可能な TLS プロトコル・バージョンや、許容可能な暗号スイートなど、各種重要 TLS 設定を決定する必要があります。 必要に応じて、ネットワーク・セキュリティー管理者と協力して、これらの設定の適切な値を決定します。 AT-TLS ポリシー・ステートメントについて詳しくは、「z/OS Communications Server: IP 構成解説書」の『AT-TLS ポリシー・ステートメント』を参照してください。変更の終わり

  9. データ接続のためのセキュリティー・レベルを決めます。
    暗号化データ転送を義務付けることを選択するか、データ転送のセキュリティー・レベルをクライアントが決定できるようにすることを選択できます。 デフォルトは、セキュリティー・レベルをクライアントが決定できるようにすることです。

    この設定は、SECURE_DATACONN 構成ステートメントを使用してカスタマイズされます。この設定が TLS と Kerberos の両方のセキュリティー動作に影響を及ぼすことを理解しておいてください。

    データに暗号アルゴリズムを適用せず、データを未加工で転送することをサーバーが必要とするようにしたい場合、また、暗号を使用しようとするクライアントがリジェクトされるようにしたい場合は、サーバーの FTP.DATA 構成ファイルの中に次のステートメントをコーディングします。

    SECURE_DATACONN NEVER

    データを未加工で転送するか暗号化するかをクライアントが決めるようにしたい場合は、サーバーの FTP.DATA 構成ファイルの中に次のステートメントをコーディングできます。

    SECURE_DATACONN CLEAR
    これはデフォルトです。

    TLS の場合は、データを暗号化するかどうかをクライアントが決めます。 クライアントがデータの暗号化を指示した場合は、サーバーとクライアントの間で TLS プロトコルを使用して暗号アルゴリズムがネゴシエーションされます。 Kerberos の場合、クライアントはデータの転送を未加工で行うか、保全性のみを保護して行うか、保全性とプライバシーの両方を保護して行うかを指定できます。

    データを暗号化して転送することをサーバーが必要とするようにしたい場合、また、未加工のデータを送信しようとするクライアントがリジェクトされるようにしたい場合は、サーバーの FTP.DATA 構成ファイルの中に次のステートメントをコーディングします。

    SECURE_DATACONN PRIVATE

    TLS の場合は、サーバーとクライアントの間で TLS プロトコルを使用して暗号アルゴリズムがネゴシエーションされます。 Kerberos の場合、データは保全性とプライバシーの両方の保護を使用して転送される必要があります。 保全性だけが保護されたデータを送信しようとするクライアントは、リジェクトされます。

  10. 制御およびデータ接続の保護を目的に SSL/TLS が使用されているときにサーバーがセッション再使用を必要とするかどうかを決定します。
    サーバーはデフォルトで、FTP セッション内のデータ接続において以下の SSL セッション ID のどちらかを再使用できます。
    • 制御接続の SSL セッション ID
    • 前のデータ接続の SSL セッション ID
    この設定は、SECURE_SESSION_REUSE 構成ステートメントを使用してカスタマイズされます。
    • FTP セッション内の後続のデータ接続において、以下の SSL セッション ID のどちらかをサーバーが再使用できるようにするには、そのサーバーの FTP.DATA 構成ファイルで、SECURE_SESSION_REUSE ステートメントに ALLOWED をコーディングしてください。
      • 制御接続の SSL セッション ID
      • 前のデータ接続の SSL セッション ID

      これはデフォルトです。

    • FTP セッション内の後続のデータ接続において、制御接続の SSL セッション ID をサーバーが必ず再利用するようにするには、そのサーバーの FTP.DATA 構成ファイルで、SECURE_SESSION_REUSE ステートメントに REQUIRED をコーディングしてください。

      リモート側でセッション ID の再使用がサポートされていない場合、この設定によって、データ接続および FTP 転送が失敗する可能性があります。

    SECURE_SESSION_REUSE ステートメントについては、「z/OS Communications Server: IP 構成解説書」を参照してください。

  11. セキュリティー製品を TLS 用に構成する方法については、TLS/SSL セキュリティーを参照してください。