9.安全

9.1 目标

  • 用于监控和管理的特权模型
    • 系统设置
      • BIOS配置
      • 系统电源状态
      • 传感器信息（电源/热量/健康）
      • 网络设置
      • 存储设置
      • 日志
    • Redfish服务配置
      • 账户管理
      • 网络设置
      • 日志
    • 固件版本
    • OEM供应商特有的功能与特性
  • 许可/授权模型应在Redfish兼容的设备间是一致的
    • 为许可/授权模型定义最小基线
  • 基础架构认证
  • CURL兼容
  • 客户端自动化
  • 内嵌服务处理器

9.2 协议

9.2.1 TLS

具体实现应该支持TLS v1.1或者之后的版本。

9.2.2 加密算法套件

具体实现应该在TLS套件中支持AES-256的加密算法。 Redfish实现应该考虑在没有使用可信证书的情况下，对认证和识别支持以下的加密算法

TLS_PSK_WITH_AES_256_GCM_SHA384
TLS_DHE_PSK_WITH_AES_256_GCM_SHA384
TLS_RSA_PSK_WITH_AES_256_GCM_SHA384

另外使用以上加密算法的优势还有“AES-GCM不仅仅是有效和安全的，并且还可以同硬件实现来达到更高的速度，同时成本更低并且延迟更小，因为这种模式可以被管道处理。” 参考RFCs如下

http://tools.ietf.org/html/rfc5487
http://tools.ietf.org/html/rfc5288

9.2.3 证书

具体实现应该支持默认证书可替换，证书需要包含一个至少4096位的RSA键和sha512-rsa的签名。

9.3 认证

  • 认证方法 服务应该同时支持“基本认证”和“Redfish会话登陆认证”（如以下会话管理所描述的） 服务可能实现其他的认证机制

9.3.1 HTTP头安全

  • 所有的写活动都必须被认证，如POST，PUT/PATCH和DELETE，除了如下情况
    • POST操作的会话服务/对象需要进行认证
      • 当发生认证失败时，扩展错误消息不能提供关于权限的信息。
  • REST对象不应该是可用未认证的，除非
    • 根对象需要确认设备和服务的位置
    • $metadata需要去获取资源类型
    • OData服务文档需要兼容OData客户端
    • 在/redfish里进行版本对象定位
  • 通过外部引用所连接的外部服务不在本规范范围内，并且它可能还有其他的安全需求。

9.3.1.1 HTTP重定向

  • 当这是一个HTTP重定向时，应该强制要求具有对目标资源的权限要求。

9.3.2 扩展错误处理

  • 当认证失败时扩展错误消息不应提供权限信息

9.3.3 HTTP头认证

  • 用于认证的HTTP头应该在其他头作可能影响响应前被处理，如etag, If-Modified等
  • HTTP的Cookie不应被用于认证任何的活动，如GET,POST,PUT/PATCH和DELETE

9.3.3.1 BASIC认证

被定义在RFC2617中的HTTP BASIC认证应该被支持，并且在第三方认证服务与客户端之间应该只使用兼容的TLS连接来传输数据。

9.3.3.2 请求/消息等级认证

任何已确立安全通道的请求都应该伴随一个认证头

9.3.4 会话管理

9.3.4.1 会话生命周期管理

会话管理留给了Redfish服务的实现来完成。它包含孤立的会话超时和同时打开的会话和数量。

  • Redfish服务应该遵从本规范来提供登陆会话

9.3.4.2 Redfish登陆会话

为了满足功能上对Redfish的多次操作，或出于安全的原因，客户端可能通过会话管理接口来创建一个Redfish的登陆会话。用于会话管理的URI通过会话服务来指定。用于确立会话的URI可以从SessionService的会话属性中或者该会话属性下面的Service Root的连接里找到。这两者应该是一样的。

{
    ...
    "SessionService": {
         "@odata.id": "/redfish/v1/SessionService"
    },
    "Links": {
         "Sessions": {
             "@odata.id": "/redfish/v1/SessionService/Sessions"
        }
    }
    ...
}

9.3.4.3 会话登入

作用于SessionService的会话集合资源的Redfish会话通过一个HTTP POST操作来创建，包含以下的POST主体：

POST /redfish/v1/SessionService/Sessions HTTP/1.1
Host: <host-path>
Content-Type: application/json; charset=utf-8
Content-Length: <computed-length>
Accept: application/json
OData-Version: 4.0

{
    "UserName": "<username>",
    "Password": "<password>"
}

原来的头应该保留对该会话创建时的引用，并在后续的请求中使用该会话从认证了的客户端域中去验证请求已经被初始化。 用于创建会话的POST请求的响应内容应包含：

  • 一个包含“会话认证令牌”的X-Auth-Token头用于客户端后续请求，并且
  • 一个包含连接的“Location”头用于新创建的会话资源。
  • JSON响应主体中要包含新创建的会话对象的所有展现。
Location: /redfish/v1/SessionService/Sessions/1
X-Auth-Token: <session-auth-token>

{
     "@odata.context": "/redfish/v1/$metadata#SessionService/Sessions/$entity",
     "@odata.id": "/redfish/v1/SessionService/Sessions/1",
     "@odata.type": "#Session.1.0.0.Session",
     "Id": "1",
     "Name": "User Session",
     "Description": "User Session",
    "UserName": "<username>"
}

客户端发送的会话登陆请求应该含有“会话认证令牌”和位置头中的返回连接。从登入POST响应中接收到带有“会话认证令牌”的请求头“X-Auth-Token”，通过设置该头内容“会话认证令牌”被用于后续的请求认证。客户端将会用一个连接来结束会话，该连接位于返回的POST的Location头中。 注意“会话ID”与“会话认证令牌”是不同的。会话ID是唯一确定会话资源并伴随响应数据返回的，它位于Location头连接的最后一节。拥有适当权限的管理员可以查看到活跃的会话并且也可以根据这个ID来结束相应的会话。但是只有客户端进行登陆后才会具有会话认证令牌。

9.3.4.4 X-Auth-Token HTTP头

在第三方认证服务与客户端间，具体实现应该只使用适当的TLS连接去传输数据。因此，POST创建一个新的会话应该只支持HTTPS，并且所有使用Basic认证的请求都要求使用HTTPS.

9.3.4.5 会话生存期

注意Redfish会话是使用“超时”而不是像某些基于令牌的方法采用的是令牌过期时间。对于Redfish会话来说，只要客户端持续发送更多时长超过会话超时周期的会话请求，会话会保持打开状态并且会话认证令牌一直保持有效。如果一旦会话超时，会话就会自动结束。

9.3.4.6 会话结束或注销

当客户端注销的时候Redfish会话会被结束。这是通过对已识别的会话资源实行一次DELETE操作来完成的。该会话资源一般是在会话创建时通过Location头中的链接来返回，或通过响应数据中的SessionId来返回。 根据会话资源ID来DELETE会话的能力，可以允许具有足够权限的管理员从一个不同的会话来结束另一个用户会话。

9.3.5 账户服务

  • 用户密码应该以单向加密技术来存储
  • 具体实现可能支持导出带密码的用户账户，但是也应该使用加密的方法去包含它们
  • 用户账户应该支持ETag并且也应该支持原子操作
    • 当请求不包含ETag时，具体实现可能会拒绝请求
  • 用户管理行为需要是原子操作
  • 当认证失败时，扩展错误消息不应该提供权限相关的信息

9.3.6 异步任务

  • 不管异步任务是基于哪个用户/权限上下文启动的，状态对象中的信息将用来强制要求所需的权限用于访问那个对象。

9.3.7 事件订阅

  • 在将事件数据对象推送到目标之前，Redfish设备可能要验证目标地址的身份

9.4.8 权限模型/授权

授权子系统使用角色与权限来空值用户对资源的访问

  • 角色
    • 角色是一个权限的集合，因此两个角色拥有相同权限在行为上应该是等价的。
    • 所有的用户需要被分配到一个确切的角色
    • 本规范定义了一个预定义角色的集合，其中有一个就是需要在用户被创建时分配的。
    • 预定义角色应该被创建的如下：
      • 角色名称 = “管理员”
        • 分配权限 = 登录，配置管理员，配置用户，配置组件，配置自身
      • 角色名称 = “操作者”
        • 分配权限 = 登录， 配置组件，配置自身
      • 角色名称 = “只读”
        • 分配权限 = 登录， 配置自身
    • 具体实现应该支持所有预定义的角色
    • 预定义角色可能包含OEM的权限
    • 用于预定义角色的权限数组应该不能被修改
    • 服务可能可选的支持附加的”自定义“角色，并且可能允许用户去创建自定义角色通过：1）寄送到角色集合；或2）一个实现可能实现一个预定义的自定义角色；或3）本规范之外的其他机制。
  • 权限
    • 权限是一个许可去执行一个带有已定义管理域（如配置用户）的操作（如读或写）
    • Redfish规范定义了一个”被分配权限“的集合，它位于角色资源的AssignedPrivileges数组中。
    • 一个实现可能也包含”OemPrivileges“，它位于角色资源的OemPrivilege数组中。
    • 通过使用在Redfish权限模式文件中的权限映射注解，权限被映射到资源上。
    • 在映射表中的多个权限构成了一个或关系的权限集
  • 用户管理
    • 当一个用户账户被创建时，分配权限给用户
    • 该用户所拥有的权限同它的角色来定义
  • ETag处理
    • 具体实现应该强制要求相同的权限模型用于ETag相关活动的，就如被强制用于ETag被展现的数据。
    • 例如，当活动需要访问权限去读取ETag所展现的数据时，也需要有相同的权限去读取ETag。

9.4 数据模型验证

9.4.1 模式

服务器和客户端的实现应该根据Redfish模式对提供的数据进行检查同时执行数据验证检查，以防止因之后的处理错误而产生漏洞。 当服务器与客户端之间在Redfish模式验证上产生分歧时，服务器可能会强制要求客户端的版本信息并拒绝请求。 客户端不应该进行数据插值除非Redfish模式允许。 在没有一个强安全需求的情况下权限不应该被修改。当权限需求已经被修改时，Redfish模式验证应该包含权限检查。 注意：权限变更是Redfish模式更新/修改的一部分，它应该被Redfish模式的修改日志记录下来。 当有一个安全的理由可以这样做时，幂等行为应该被拒绝。 资源定义应包含资源上必要的权限用于执行读/读写操作。 资源树的稳定性 - 资源上许可应该是稳定为优。 自定义操作 - 权限模型应当始终应用到主体和响应上。为URI所采用的权限模型应该被自定义自定义的动作所继承。

9.5 日志

9.5.1 用于安全日志条目的数据

具体实现应该记录认证请求包括认证失败的请求。登陆/注销认证的日志条目应该包含用户标识符，这样就可以用于唯一确定客户端和时间戳。

9.5.2 未完成的日志

  • 从RESTful服务调用的发起人那里来的每个日志条目，经过的每个中间环节，直到调用链中的最后一个实体，每个调用活动（triggered/ taken/ ...）都要记录一条日志在他们的审计日志里面。这就意味着对于任意的RESTful服务调用，审核日志条目 '将完整' 的呈现实体内执行的活动。
    • 所有的写动作，如POST, PUT/ PATCH和DELETE
      • 注意：不是必须记录每一个新日志条目的创建事件。
    • 要有能力去记录特权读，如GET
      • 这种能力可能默认是开启的
  • 应记录由于幂等操作被拒绝而导致的安全问题

9.5.3 审计日志的内容

细节： 需要产生一些事件

  1. 用户账户的登陆，注销，修改事件
  2. 成功和被拒绝的登陆尝试
  3. 成功和被拒绝的连接到节点和其他资源的访问尝试
  4. 用户账户的修改细节
  5. 所有系统配置的变化
  6. Redfish兼容设备中内建工具运行的相关信息（如，底层诊断工具）
  7. 访问Redfish兼容设备的系统接口的相关信息
  8. 网络地址和协议（如，用于访问的工作站IP地址和协议）
  9. 激活和反激活的保护措施

其中每个被写入文件的事件内的消息至少应该具备以下信息：

  • 用户ID
  • 日期，时间
  • 事件类型
  • 事件描述