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)より多くのLinuxワークロードが共有ネットワークインフラストラクチャを横断するにつれて、ネットワークトラフィックの暗号化に対するリクエストが増加してきました。ポイントツーポイントのトラフィック暗号化を行う方法は数多くありますが、Linux NFSコミュニティのリード・メンバーは、NFSトラフィックのover-the-wire（ネットワーク越し）暗号化を実現するための、（これまでとは）異なる、より単純な戦略を提案しています。
https://tools.ietf.org/html/draft-cel-nfsv4-rpc-tls-01
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/
0 件のコメント:
コメントを投稿