[Network, Linux, Security] Encrypting NFS data on the Wire

原文はこちら。
https://blogs.oracle.com/linux/encrypting-nfs-data-on-the-wire

---

Oracle Linuxの開発者であるChuck Leverは、NFS（実際にはすべてのRPCベースのプロトコル）に対する透過的なエンドツーエンドの暗号化を実現するためのインターネットドラフト標準（draft-cel-nfsv4-rpc-tls-01）の協同作業に参画しています。

Remote Procedure Call Encryption By Default (draft-cel-nfsv4-rpc-tls-01)
https://tools.ietf.org/html/draft-cel-nfsv4-rpc-tls-01

より多くのLinuxワークロードが共有ネットワークインフラストラクチャを横断するにつれて、ネットワークトラフィックの暗号化に対するリクエストが増加してきました。ポイントツーポイントのトラフィック暗号化を行う方法は数多くありますが、Linux NFSコミュニティのリード・メンバーは、NFSトラフィックのover-the-wire（ネットワーク越し）暗号化を実現するための、（これまでとは）異なる、より単純な戦略を提案しています。

Linux NFSのメンテナであるTrond MyklebustとOracle Linuxの開発者であるChuck Leverは、NFSなどのRPCベースのプロトコルのための、透過的で構成が簡単なエンドツーエンドの暗号化標準であるNFS-over-TLSを提案しています。このソリューションでは、自己署名証明書を使用して、NFSのネットワーク・トラフィックの標準暗号化を設定します。この方法ではKerberosやActive Directoryの重いオーバーヘッドはかかりません。

IPsecやKerberosのように、ネットワーク上でNFSトラフィックを暗号化する方法はたくさんありますが、現時点では、大きな欠点があるためにほとんどのユーザーがそれらを使用していません。RPC-over-TLSを有効にするこの提案は、HTTPSと同様に、自己署名証明書を選択して、暗号化を「簡単な」オプションにします。

この標準は最もシンプルで使い勝手の良いソリューションとして押し出されているものではありますが、代替暗号化ソリューションが適切なソリューションになり得ない場合にも、ユニークなメリットを提供します。具体的には、接続毎の暗号化（例えばIPSec）に対するフロー毎の暗号化であったり、（クラウド環境ではよくあることですが）顧客のユーザー認証ドメインがホストのID管理とは別の場合であったりする場合にメリットを提供します。

クライアントとサーバーがすでに信頼関係がある場合ようなデプロイメントのケースは多々あります。そのような場合、必要なのは信頼されていないネットワーク上を流れるNFSトラフィックの保護だけです。ほとんどのNFSはすでにこのように動作しており、テナントはDNSサービスが提供するIPアドレスを信頼しますが、トラフィックを見張らない他のテナントは信頼しません。

このソリューションは、Webトラフィックの暗号化のためのhttpsソリューションからヒントを得ています。具体的には、認可/認証とは別に暗号化に焦点を当てます。このソリューションはユーザー認証ソリューションほどの機能はありませんが、これは管理者が必要とする最小限の構成で使用できるソリューションです。この標準は以下の前提でロールアウトされるでしょう。

• use-if-availableモデル（使用可能な場合には使用）にデフォルトで設定されている
• つまり、接続の両端でこの標準をサポートし、証明書の信頼性が十分にある場合には、NFSトラフィックは暗号化される

この機能がNFSクライアントやNFSサーバーにロールアウトされる際には、全てのNFSトラフィックが透過的に暗号化されることになるでしょう。

これはまだ標準のドラフトですので、すぐにOracle Linuxサーバーで利用できるようになるわけではありません。しかし、業界メディアではすでに話題になっています。

Oi! Not encrypting RPC traffic? IETF bods would like to change that
RPC over TLS: You know it makes sense
https://www.theregister.co.uk/2018/11/14/internet_draft_rpc_over_tls/