跳转到： 导航, 搜索

Security/Guidelines/logging guidelines

概述

OpenStack 需要日志和通知安全指南和最佳实践，以防止机密信息意外泄露给未经授权的用户。本 wiki 旨在获得 OpenStack 社区对这些标准及其实现方式的共识。

状态

目前正在由 OpenStack 安全小组 (OSSG) 审核。

问题定义

难以识别机密数据

OpenStack 项目之间缺乏标准/结构化的日志和通知数据格式，这使得 OpenStack 操作员无法明确识别和过滤不应暴露给某些用户的机密数据。简单的架构图示例

Openstack logging security.png

注意：为简洁起见，本文档将使用“日志”代替“日志和通知”。

此图表示多个 OpenStack 服务生成日志，这些日志的格式可能不同，并且可能包含不同类型的机密数据（操作员不希望用户访问的数据）。可能存在操作员创建的过滤和聚合系统，以及将清理后的日志暴露给用户或操作员的方法。传递方法与本次讨论关系不大，但能够明确过滤掉日志中的机密数据非常重要。

OpenStack 中意外泄露凭据给未经授权用户的一些非详尽示例


OpenStack 的 CI/CD 特性加剧了这个问题。代码每天都在许多项目中合并，其中一些代码可能会引入新的日志条目，操作员需要检查和过滤这些条目。频繁更新的操作员可能需要花费更多的时间和精力在这个过程上。目前，许多操作员在处理日志泄露时处于被动模式，他们必须主动监控日志数据更改并迅速采取行动以防止潜在的数据泄露。这显然不是 OpenStack 操作员的最佳解决方案，尤其是在运行的 OpenStack 服务数量增加时，难度也会增加。

日志级别用于安全

在某些情况下，OpenStack 围绕日志的安全问题是由于使用日志级别来过滤机密数据造成的。为了提供更具体的示例，将日志级别设置为 DEBUG 或 INFO 导致明文凭据被记录（有时在用户全局可访问的位置）。这迫使操作员在潜在的机密数据泄露和更好的性能/调试数据之间做出选择。同样，这对于操作员来说也不是一个最佳设计。


解决方案

明确识别机密日志数据

建议规则:

  • 识别 OpenStack 代码中的机密数据，以便为管理员提供一个“标签”来清理后端日志过滤系统中的数据
  • 清除 OpenStack 代码中被 OpenStack 标识为机密或敏感的所有日志数据


到目前为止，OpenStack 社区的反馈明确拒绝了类似 Oslo Config 的设置来禁用安全功能（允许记录一些敏感数据）的概念。

讨论点：有反馈建议启用 AUDIT 级别的日志设置，这将启用敏感数据记录。社区对此有何看法？

OpenStack 敏感/机密数据

(不应暴露给用户)

数据类型 状态 描述
原始异常数据 正在审核中 不要记录未过滤的异常。 已经发生过数据库异常将凭据信息以明文记录的情况。 不同的异常类型可能会记录不同的数据，因此通常应避免这种做法。
凭据 正在审核中 绝不记录凭据信息，例如登录名、密码、身份验证令牌等。
个人身份信息 正在审核中 不要记录 PII 信息，例如客户地址、电话号码等。
密钥 正在审核中 绝不记录私钥或对称密钥。
服务器/服务状态 正在审核中 不允许用户访问非相关的服务状态，这些状态可能被用作攻击媒介。 示例：PRNG 状态/种子、文件路径、代码文件名、服务帐户名称等。
URI 和请求对象 正在审核中 不允许记录 URI 或完整的请求对象，这些对象可能会潜在地暴露凭据或数据位置信息。

注意：此列表旨在成为一个动态列表，以适应新的 OpenStack 问题/架构。

提醒：始终确保用户只能访问与其租户/项目关联的数据。


可能的实现方案

有一个领域作者承认缺乏知识：云审计数据联合 (CADF) 似乎在类似的空间中工作。 OpenStack 中有一个 PyCADF 项目，可能值得进一步调查。

Trace 类

在 Project Solum 中，创建了一个 TraceData 类来与 Oslo Log 配合使用，以执行两个主要任务

  • 启用在代码中识别机密/敏感数据
  • 允许 trace 数据持久化，并可能在每个后续日志调用中构建和使用


代码：https://github.com/stackforge/solum/blob/master/solum/common/trace_data.py

单元测试/用法示例：https://github.com/stackforge/solum/blob/master/solum/tests/common/test_trace_data.py

此代码将接受 Oslo Context 类并用数据填充自身，以防止与该通用库的意外交互。 Oslo Log 可以以与使用上下文类相同的方式使用此 trace 数据。

此方法的一个潜在问题是 Trace 类重复了 Oslo Context 类的一些数据。 提供了其他方法如下。

原生 Oslo Log 支持

根据到目前为止的 OpenStack 社区反馈，这是首选的实现路径。

扩展 Oslo Log 本身，以纳入将数据标记为敏感的功能（Oslo Log 中的一等公民功能）。 这可能需要 Oslo 团队进行更多的工作来设计这种解决方案。

一个想法是可能存在一种：LOG.debug("my log message", confidential=True) 类型的机制来识别敏感数据。 这将强制将日志条目分解为“公共”和“私有”日志调用（在某些情况下，即背靠背的日志调用）。

Oslo Log 额外结构

Oslo log 提供了一个“extra”字段，该字段可以保存任意数据。 一种选择是手动创建一个“private”键，该键保存操作员可用于过滤日志数据的 JSON 字典/列表。

示例：LOG.debug("随机非机密日志数据", extra={private={value=confidential_data}})

此路径的优点是不需要更改 Oslo 代码。 问题是，正确构建每个 Oslo Log 调用是一个非常繁琐且容易出错的过程。

日志级别使用建议

建议规则：不要使用日志级别来过滤机密数据（例如密码等）。

这篇文章对社区考虑日志级别的使用有很好的定义：何时使用日志级别 Warn 与 Error

为了使这更具体地适用于 OpenStack 并获得社区输入，这里有一个带有日志级别建议的表格

日志级别 预期用途
Critical 服务无法自动恢复，必须关闭服务以防止（进一步）数据丢失或损坏。
错误 无法自动恢复，需要管理员/操作员或用户干预才能恢复。
警告 发生了一些小错误，但通常可以通过一段时间或重试来恢复。 通常不需要手动干预或管理员分页。
Info 显示服务版本、启动/停止以及其他提供对服务操作更深入了解的指示。 通常是正常运行系统中使用的最低日志级别。
Debug 转储所有不损害安全或导致机密数据泄露的日志数据。 通常不用于正常操作，因为日志会非常庞大。


推广建议

推广安全建议的潜在方式

从 "https://wiki.openstack.org/w/index.php?title=Security/Guidelines/logging_guidelines&oldid=55847" 检索