要理解这个安全模型，您应该熟悉所谓的 通用安全服务应用程序编程接口 （Generic Security Services application programming interface，GSS-API）版本 2 的更新 1。GSS-API 在 RFC 2743 中进行了完整的描述，不幸的是，它是最难理解的 RFC 之一。
从 NFSv4 的使用经验中我们知道，让网络文件系统与操作系统独立开来是非常困难的。不过要让操作系统的安全性和网络协议完全独立开来却更加困难。我们必须两者都要，因为 NFS 必须要能够处理大量的用户操作，但还不能太多地引入网络协议交互的特有内容。
NFS 客户机和服务器之间的连接通过所谓的“健壮 ” RPC 安全性进行了增强。NFSv4 使用了在 RFC 1831 中定义的开放网络计算远程过程调用（Open Network Computing Remote Procedure Call，ONCRPC）标准。这个安全模型必须进行增强，而不是依赖于一个简单的认证（称为 AUTH_SYS ），有一个称为 RPCSEC_GSS 的基于 GSS-API 的安全模型已经被定义并作为 NFSv4 的一个强制部分实现了。NFSv4 中提供的最重要的安全机制包括 Kerberos 版本 5 和 LIPKEY。
尽管 Kerberos 在 Internet 上使用时有诸多限制，但是 LIPKEY 却有一个令人满意的优点——可以像 Secure Socket Layer（SSL）一样工作，提示用户输入自己的用户名和密码，同时还可以避免 SSL 对 TCP 的依赖性 —— 这是 NFSv4 没有的一种依赖性。如果不要求 RPCSEC_GSS，可以设置 NFS 来对安全性问题进行协商。以前的 NFS 版本都没有这种能力，因此不能对保护的质量、数据的完整性、认证的要求或加密类型进行协商。
对于 NFSv3 的安全性存在大量的批评。尽管 NFSv3 服务器是在 TCP 上运行的，但是也完全可以在 Internet 上运行 NFSv3 网络。不幸的是，这必须要打开多个端口，因而会导致几个众所周知的安全性问题。通过让 2049 端口成为 NFS 的强制端口，就可以跨过防火墙来使用 NFSv4，而不用太过注意其他协议（例如 Mount 协议）正在侦听哪些端口。因此，丢弃 Mount 协议具有几方面的正面影响：
强制的强认证机制： NFSv4 强制强认证机制。Kerberos 非常常见，低层基础设施公钥机制（Lower Infrastructure Public Key Mechanism，LIPKEY）也必须要支持。NFSv3 只支持 UNIX 型的标准加密来对访问进行认证 —— 这在大型网络中会导致一些主要的安全问题。
强制的 Microsoft Windows NT 型的访问控制列表（ACL）方案 ：尽管 NFSv3 允许对认证进行强加密，但是它并没有推动 Windows NT 型的 ACL 访问方案。可移植操作系统接口（POSIX）风格的 ACL 一段时间也曾实现过，但是一直都没有得到广泛采用。NFSv4 强制采用了 Windows NT 型的 ACL 方案。
协商的认证类型和机制 ： NFSv4 使对认证类型和机制进行协商成为可能。在 NSFv3 中，只能手工确定采用哪种加密类型。系统管理员然后必须对加密和安全协议进行协调。
NFS 仍然是不对等的吗？
NFSv4 正在开始取代很多 UNIX 和 Linux 系统上的 NFSv3。作为一个网络文件系统，NSFv4 有几个竞争对手。考虑到通用 Internet 文件系统（CIFS）/服务器消息块（SMB）是 Windows 和 Linux 上专有的系统，它们都可以认为是 NFSv4 的强劲对手。AFS 从来都没有太多的商业影响，它所关注的是的分布式文件系统的一些元素，而此文件系统可以简化数据迁移和复制。
从内核发展到 2.2 版本开始，产品级 Linux 版本的 NFS 就已经存在了，但是 Linux 内核版本的一大失误是对于 NFSv3 的采纳太晚了。实际上，Linux 花了相当长时间才能完全支持 NSFv3 。在 NSFv4 出现时，这个问题快速得到了解决，现在不仅仅是 Solaris、AIX 和 FreeBSD 可以提供对 NSFv4 的全面支持了。
复制本页网址和标题，发送给你QQ/Msn的好友一起分享 Alacritech / MacDragon 消费电子擂台
精品推荐