第二页
访问控制列表
ACL 对于寻求更大的 Windows 客户端兼容性的 NetApp 客户而言，它是请求最为频繁的功能之一。NFSv4 ACL 大大改善了 NFS 的安全性和与 CIFS 的互操作性。
ACL 允许在每个用户的基础上授予或拒绝针对各个文件对象的访问权限，提供更为细化的访问权限控制和与传统的 UNIX 模式权限位相比程度更大的可选性。NFSv4 ACL 基于 NT 原型，但是它们不包含所有者/组信息。NFSv4 ACL 由访问权限控制条目 (ACE) 的数组组成，包含有关允许/拒绝访问的信息、许可权限位、用户名称/组名称和标记。
由于 NetApp 已向 CIFS 客户端提供 ACL 支持，NFSv4 中的额外 ACL 功能将创建一些独特的考虑。NetApp 提供三种类型的配额树 —UNIX、NTFS 和混合型 — 用于不同的客户端。NFSv4 ACL 的处理方式取决于配额树的类型：
UNIX 配额树
NFSV4 ACL 和模式位有效
Windows 客户端不能设置属性
UNIX 语义学占优势
NTFS 配额树
NT ACL 和模式位有效，；UNIX 客户端不能设置属性
NFSv4 ACL 从用 NT ACL 访问文件的 NFS 客户端的模式位生成
NT 语义学占优势
混合型配额树
NFSv4 ACL、NT ACL 和模式位有效
Windows 和 UNIX 客户端可以设置属性
NFSv4 ACL 是为具有 NT ACL 的文件从模式位生成的
显然，您应该仔细选择您使用的配额树类型，以获得期望结果：
仅限访问 NFS：UNIX 配额树
混合访问：混合型配额树
多数 CIFS 访问：NTFS 配额树
仅限访问 CIFS：NTFS 配额树
关于 ACL的唯一其他最佳实践是每个 ACL. 使用不超过 192 个 ACE 您可以提高每个 ACL 的 ACE 数量到当前的最大数 400，但是执行这样的操作意味着带来是否必需转为 Data ONTAP 的更早版本或是否使用 SnapMirror转至较早版本的问题。
强制安全性
除包括 ACL 之外，NFSv4 还通过以下措施提高了上个 NFS 版本的安全性：
要求带加密的具有很强的 RPC 安全性
通过一个安全的带内系统，协商在服务器和客户端之间使用的安全性类型
使用字符串而不是整数来表示用户和组标识符
NFS 安全性已获得基于“一般安全性服务 API (GSS-API)”的安全性附加功能支持，称为 RPCSEC_GSS [RFC2203]。NFS 的所有版本均可以使用 RPCSEC_GSS。但是，要实施一致的 NFS 版本 4 就必须实施 RPCSEC_GSS。RPCSEC_GSS 是分配的类似于常用的 AUTH_SYS 安全性，后者是上个 NFS 版本中标准的身份验证方法。
RPCSEC_GSS 在以下两个方面有别于 AUTH_SYS 和其他传统的 NFS 安全机制：
RPCSEC_GSS 不只是身份验证。它能执行完整性校验和与整个 RPC 请求和响应体的加密。因此RPCSEC_GSS 提供远远不只身份验证的安全性。
由于 RPCSEC_GSS 只封装 GSS-API 消息标记 — 它仅作为 Kerberos 等安全机制的特定机制标签的传输 — 添加新安全机制（只要它们符合 GSS-API）不要求重新编写 NFS 的重要部分。
图 1) 配有 AUTH_SYS 的 NFS 与 RPCSEC-GSS 安全性相比。
NFSv3 和 NFSv4 可以使用 RPCSEC-GSS。但是，AUTH_SYS 是 NFSv3 的默认值。
网友评论