clay-good/nisify
GitHub: clay-good/nisify
Nisify 是一个专注于 NIST CSF 2.0 合规证据聚合的自动化评估工具，帮助组织持续跟踪合规成熟度并识别差距。
Stars: 4 | Forks: 0
# Nisify
**用证据证明您的 NIST 成熟度。**
Nisify 是一个 NIST CSF 2.0 合规性证据聚合工具，它连接您的云平台，收集证据工件，并将其映射到 NIST 控制项，以证明您的合规成熟度。自动化频繁变化的项，记录很少变化的项，并在同一个仪表板中跟踪这两者。
## 问题
追求 NIST CSF 2.0 合规性的组织面临痛苦的现实：
**手动收集证据耗时且容易出错。** 安全团队在每次审计前花费数周时间收集截图、导出日志并填写电子表格。证据一旦收集就会立即过时。
**昂贵的 GRC 平台功能过剩。** 企业合规工具每年成本六位数，需要专职管理员，并且捆绑了大多数组织从未使用过的功能。它们通常支持数十个框架，而您只需要一个。
**无法了解实际的合规状况。** 没有持续的证据收集，组织无法回答基本问题：“我们今天合规吗？” “我们的差距在哪里？” “我们是在进步还是倒退？”
## 解决方案
Nisify 只做一件事：聚合您现有云平台上的证据，并将其映射到 NIST CSF 2.0 控制项。
**以 NIST 为首的设计。** 专为 NIST CSF 2.0 构建。不是 SOC 2 加上 NIST 补丁。每个功能都服务于 NIST 合规性。
**证据聚合重点。** 连接您已经使用的 13 个平台（AWS、Okta、Jamf、Google、Snowflake、Datadog、GitLab、Jira、Zendesk、Zoom、Notion、Slab、SpotDraft），并通过只读 API 拉取证据。
**透明、确定性的评分。** 没有机器学习。没有黑盒子。每个成熟度评分都可以追溯到特定证据和明确规则。审计人员可以准确理解控制项为何获得其评分。
**零供应商锁定。** 导出所有内容。JSON、PDF、原始证据文件。您的数据属于您。任何时候都可以迁移。
**只读、安全设计。** Nisify 从不修改您的基础设施。所有 API 调用都是只读的。凭据在静态时加密。没有遥测，不打电话回家。
## 理解 NIST CSF 2.0 覆盖范围
NIST CSF 2.0 包含 **106 个子类**（控制项）。Nisify 提供 **100% 映射覆盖率**——每个控制项都有定义的证据要求。然而，并非所有证据都可以自动收集。
### 为什么只有 36% 可以自动化
| 类别 | 控制项 | 示例 | 原因 |
|----------|----------|----------|-----|
| **API 可收集 (36%)** | 38 | 多因素认证状态、设备清单、访问日志、安全发现 | 数据存在于具有 API 的平台中 |
| **手动证据 (64%)** | 68 | 董事会会议纪要、风险登记册、政策、培训记录 | 治理和组织流程存在于文档中，而非 API |
**这是 NIST CSF 2.0 的固有特性，而非工具限制。** 该框架涵盖：
- **技术控制**（保护、检测）——通常可自动化
- **治理控制**（治理）——需要董事会决策、政策、预算
- **流程控制**（识别、响应、恢复）——需要记录的程序
没有任何合规工具可以完全自动化 NIST CSF 2.0，因为该框架有意涵盖了存在于技术系统之外的组织治理。
### 证据流程
```
┌─────────────────────────────────────────────────────────────────────────┐
│ NIST CSF 2.0 (106 Controls) │
├───────────────────────────────────┬─────────────────────────────────────┤
│ API-COLLECTIBLE (38) │ MANUAL EVIDENCE (68) │
│ │ │
│ nisify collect --all │ nisify submit --control GV.PO-01 │
│ │ │ │ │
│ ▼ │ ▼ │
│ ┌─────────────────┐ │ ┌─────────────────┐ │
│ │ AWS, Okta, Jamf │ │ │ Policy docs, │ │
│ │ Google, GitLab │ │ │ Board minutes, │ │
│ │ Jira, Datadog.. │ │ │ Risk registers │ │
│ └────────┬────────┘ │ └────────┬────────┘ │
│ │ │ │ │
│ └───────────┬───────────┴───────────┘ │
│ ▼ │
│ ┌────────────────┐ │
│ │ Evidence Store │ ← All evidence stored together │
│ └────────┬───────┘ │
│ ▼ │
│ ┌────────────────┐ │
│ │ Mapping Engine │ ← Maps to controls by evidence type │
│ └────────┬───────┘ │
│ ▼ │
│ ┌────────────────┐ │
│ │ Dashboard │ ← Shows unified maturity score │
│ └────────────────┘ │
└─────────────────────────────────────────────────────────────────────────┘
```
### Nisify 自动化与手动提供内容的对比
| Nisify 自动化 | 您提供 |
|------------------|-------------|
| 从 13 个平台收集 | 政策文档（PDF、Word） |
| 将证据映射到控制项 | 董事会/委员会会议纪要 |
| 计算成熟度评分 | 风险登记册和评估 |
| 跟踪随时间变化的趋势 | 培训完成记录 |
| 识别差距 | 事件响应计划 |
| 生成报告 | 供应商评估报告 |
| 新鲜度跟踪 | 人力资源安全政策 |
### 价值主张
**没有 Nisify 时：**
- 审计前手动收集截图
- 审计周期之间没有可见性
- 审计发生时证据已过时
- 没有趋势跟踪
- 所有 106 个控制项 100% 手动工作
**使用 Nisify 时：**
- 36% 完全自动化，持续收集
- 实时查看技术控制项
- 自动新鲜度跟踪和告警
- 历史趋势显示改进/退化
- 64% 仍为手动，但在同一仪表板中跟踪
自动化部分涵盖了 **高变化** 的证据（访问日志、多因素认证状态、设备清单），否则需要持续手动收集。手动部分涵盖了 **低变化** 的证据（政策、治理文档），通常每季度或每年更新一次。
## 工作原理
```
Cloud Platforms (AWS, Okta, Jamf, Google, Snowflake, Datadog, GitLab, Jira, Zendesk, Zoom, Notion, Slab, SpotDraft)
|
Read-Only API Calls
|
v
+----------------+
| Collectors |
| (per platform) |
+----------------+
|
Normalized Evidence
|
v
+----------------+
| Evidence Store |
| (SQLite + JSON)|
+----------------+
|
v
+----------------+
| Mapping Engine |
| (Evidence -> |
| NIST Controls)|
+----------------+
|
v
+----------------+
| Maturity |
| Calculator |
+----------------+
|
v
+-------------+-------------+
| | |
v v v
+--------+ +---------+ +----------+
| CLI | |Dashboard| | Reports |
+--------+ +---------+ +----------+
```
1. **配置**平台，使用只读凭证
2. **收集**按计划（每小时、每天、每周）收集证据
3. **映射**证据到 NIST CSF 2.0 控制项（自动）
4. **评分**成熟度等级（0-4），按控制项、类别和功能
5. **识别**差距并提供可操作的建议
6. **报告**给利益相关者和审计人员
## 快速演示（无需凭证）
使用真实的示例数据立即尝试 Nisify：
```
# 从源代码安装
git clone https://github.com/clay-good/nisify.git
cd nisify
pip install -e .
# 一键生成演示数据并启动仪表板
nisify demo --dashboard
```
这将创建来自 AWS、Okta、Jamf 和 Google Workspace 的 30 天示例证据，然后打开仪表板（http://127.0.0.1:8080）。
**演示配置文件：**
- `--profile startup` - 安全基础的小型公司（存在许多差距）
- `--profile growing` - 中等规模公司，安全程度中等（默认）
- `--profile mature` - 安全能力较强的大型企业（差距较少）
```
# 示例：演示初创公司的合规态势
nisify demo --profile startup --organization "My Startup Inc." --dashboard
```
## 快速启动（生产使用）
```
# 从 PyPI 安装（尚未发布）
pip install nisify
# 或从源代码安装
git clone https://github.com/clay-good/nisify.git
cd nisify
pip install -e .
# 初始化配置
nisify init
# 交互式配置平台
nisify configure
# 测试连接
nisify test-connection aws
# 运行证据收集
nisify collect --all
# 查看成熟度分数
nisify maturity
# 查看差距
nisify gaps
# 生成报告
nisify report --format pdf --output compliance-report.pdf
# 启动仪表板
nisify dashboard
```
## CLI 参考
| 命令 | 描述 |
|---------|-------------|
| `nisify info` | 显示系统信息和诊断 |
| `nisify init` | 初始化配置目录和设置 |
| `nisify configure` | 交互式配置和凭据设置 |
| `nisify status` | 显示配置状态和上次收集时间 |
| `nisify collect` | 从已配置的平台运行证据收集 |
| `nisify maturity` | 计算并显示 NIST CSF 2.0 成熟度评分 |
| `nisify gaps` | 显示优先级建议的差距分析 |
| `nisify report` | 生成合规报告（PDF、JSON、HTML） |
| `nisify export` | 导出证据和分析数据 |
| `nisify dashboard` | 启动本地 Web 仪表板 |
| `nisify dashboard --background` | 在后台启动仪表板 |
| `nisify dashboard --stop` | 停止后台仪表板 |
| `nisify dashboard --status` | 检查仪表板是否正在运行 |
| `nisify schedule` | 配置自动证据收集 |
| `nisify schedule --enable` | 启用计划收集 |
| `nisify schedule --disable` | 禁用计划收集 |
| `nisify schedule --start-daemon` | 启动内置调度守护进程 |
| `nisify schedule --stop-daemon` | 停止内置调度守护进程 |
| `nisify schedule --logs` | 显示最近的调度日志 |
| `nisify test-connection` | 测试与特定平台的连接 |
| `nisify cleanup` | 根据保留策略清理旧证据 |
| `nisify cleanup --dry-run` | 预览将清理的内容 |
| `nisify demo` | 生成演示数据以快速评估 |
| `nisify demo --dashboard` | 生成演示数据并启动仪表板 |
| `nisify submit --control ID --type TYPE --url URL` | 提交带有 URL 引用的手动证据 |
| `nisify submit --control ID --type TYPE --file PATH` | 提交手动证据文件 |
| `nisify submit --list-types` | 列出可用于手动提交的证据类型 |
| `nisify backup` | 创建所有 Nisify 数据的备份归档 |
| `nisify restore` | 从备份归档恢复 |
全局选项：
- `--config PATH` - 覆盖配置文件位置
- `-v, --verbose` - 增加输出详细程度
- `-q, --quiet` - 抑制非必要输出
- `--version` - 显示版本号
输出格式（在 ``、`maturity` 和 `gaps` 命令中可用）：
- `--format table` - 人类可读的表格输出（默认）
- `--format json` - 用于脚本/自动化的 JSON 输出
- `--format csv` - 用于电子表格/分析的 CSV 输出
## 支持的平台
Nisify 支持 13 个云平台进行自动证据收集：
### 核心平台
| 平台 | 证据类型 | 所需权限 |
|----------|---------------|---------------------|
| AWS | 安全中心发现、IAM 配置、CloudTrail 状态、配置规则、S3 加密 | SecurityAudit 托管策略 |
| Okta | 用户目录、多因素认证状态、系统日志、安全策略 | okta.users.read、okta.logs.read、okta.policies.read |
| Jamf Pro | 设备清单、FileVault 状态、合规 EA、配置文件 | 审计员角色 |
| Google Workspace | 管理员审计日志、目录用户、2SV 状态、安全设置 | 管理员 SDK（只读） |
| Snowflake | 访问历史、查询历史、登录历史、用户/角色配置 | ACCOUNT_USAGE 上的 SELECT |
| Datadog | 安全信号、监控规则、监控器、审计跟踪 | 只读 API 密钥 |
### 开发与协作平台
| 平台 | 证据类型 | 所需权限 |
|----------|---------------|---------------------|
| GitLab | 项目、用户、审核事件、MR 批准、受保护分支、访问令牌 | api 或 read_api、read_user、read_repository |
| Jira | 项目、用户、审核日志、权限方案、安全问题 | 浏览项目、管理 Jira |
| Notion | 用户、数据库、页面、访问权限、审核日志（企业版） | 内部集成令牌 |
| Slab | 用户、帖子、主题、访问/共享权限 | API 令牌 |
### 通信与支持平台
| 平台 | 证据类型 | 所需权限 |
|----------|---------------|---------------------|
| Zoom | 用户、会议安全性、录制设置、安全配置、访问日志 | 服务器到服务器 OAuth：user:read:admin、meeting:read:admin |
| Zendesk | 用户、审核日志、安全设置、工单、用户/用户组 | 管理员访问 |
### 合同管理
| 平台 | 证据类型 | 所需权限 |
|----------|---------------|---------------------|
| SpotDraft | 用户、合同、模板、审核日志 | API 访问（联系 SpotDraft） |
## 确定性的逻辑
Nisify **不使用机器学习或 LLM** 进行评分或分析。
每个成熟度评分使用明确的、记录在案的规则计算：
- 证据类型 X 映射到 NIST 控制项 Y（在配置中定义）
- 证据的新鲜度影响置信度（可配置的阈值）
- 成熟度等级（0-4）根据证据的存在、完整性和时效性分配
您可以追溯到任何评分：
1. 贡献的具体证据项
2. 将证据连接到控制项的映射规则
3. 计算成熟度级别的评分算法
这种透明度对于审计员接受和组织信任至关重要。
## 扩展映射
Nisify 使用可配置的证据到控制项映射覆盖所有 106 个 NIST CSF 2.0 子类别。您可以通过编辑 `data/control_evidence_mappings.json` 来自定义这些映射。
### 映射配置格式
每个映射指定哪些证据类型满足一个控制项：
```
{
"control_id": "PR.AC-01",
"required_evidence_types": ["user_inventory", "mfa_status"],
"optional_evidence_types": ["access_logs"],
"platforms": ["okta", "aws", "google"],
"logic": "all_required",
"freshness_days": 30,
"description": "Identity management requires user inventory and MFA configuration"
}
```
### 映射字段
| 字段 | 描述 | 必需 |
|-------|-------------|----------|
| `control_id` | NIST CSF 2.0 子类 ID（例如 "PR.AC-01"） | 是 |
| `required_evidence_types` | 必须存在的证据类型 | 是 |
| `optional_evidence_types` | 提高置信度分数的可选证据 | 否 |
| `platforms` | 可以提供此证据的平台 | 否 |
| `logic` | 如何组合证据（参见下文） | 否（默认：all_required） |
| `freshness_days` | 证据过期天数 | 否（默认：30） |
| `description` | 人类可读的解释 | 否 |
### 逻辑类型
- **`all_required`**：`required_evidence_types` 中的所有证据类型都必须存在
- **`any_required`**：`required_evidence_types` 中至少有一个证据类型必须存在
- **`weighted`**：证据根据配置的权重按比例贡献
### 示例：添加新的映射
要将控制项 `GV.OC-03`（了解法律、监管和合同要求）映射：
```
{
"control_id": "GV.OC-03",
"required_evidence_types": ["contract_inventory"],
"optional_evidence_types": ["audit_logs", "security_policies"],
"platforms": ["spotdraft"],
"logic": "all_required",
"freshness_days": 90,
"description": "Legal/regulatory requirements tracked via contract management"
}
```
### 可用证据类型
每个平台收集的证据类型：
| 平台 | 证据类型 |
|----------|---------------|
| AWS | security_findings、password_policy、mfa_status、access_keys、audit_logging、config_compliance、data_protection、detection_rules、ha_config |
| Okta | user_inventory、mfa_status、access_logs、security_policies、access_assignments |
| Jamf | device_inventory、encryption_status、endpoint_compliance、software_inventory、security_configurations、hardware_lifecycle、maintenance_records |
| Google | user_inventory、mfa_status、access_logs、device_inventory |
| GitLab | project_inventory、user_inventory、audit_logs、change_management、branch_protection、access_tokens |
| Jira | project_inventory、user_inventory、audit_logs、access_control、incident_tracking、improvement_plan、remediation_tracking |
| Zendesk | user_inventory、audit_logs、security_config、incident_tracking、access_control |
| Zoom | user_inventory、meeting_security、data_protection、security_config、access_logs |
| Notion | user_inventory、data_inventory、access_control、audit_logs |
| Slab | user_inventory、data_inventory、topic_structure、access_control |
| SpotDraft | user_inventory、contract_inventory、template_inventory、audit_logs |
| Snowflake | user_inventory、access_policies、authentication_logs、access_logs、data_access_logs |
| Datadog | security_findings、detection_rules、monitoring_coverage、audit_logs、log_retention、threat_register、capacity_monitoring |
### 手动证据控制
所有 106 个 NIST CSF 2.0 子类都有映射配置。38 个控制项（36%）可以通过自动 API 收集满足。68 个控制项（64%）需要手动证据提交，用于无法从 API 拉取的治理、政策和组织流程。
**这是有意为之的设计。** NIST CSF 2.0 包含董事会问责、风险登记册、HR 实践和事件响应计划等控制项，这些存在于文档中，而非 API。
通过 `nisify submit` 提交的手动证据：
- **与自动收集存储在相同的证据系统中**
- **在计算成熟度时映射到控制项**
- **在仪表板评分中反映，与 API 收集的证据一起**
- **像任何证据一样老化——需要定期刷新**
```
nisify submit --control GV.PO-01 --type security_policy --file security-policy.pdf
nisify submit --control GV.RR-01 --type board_minutes --url https://docs.company.com/board/2024-q4
nisify submit --list-types # View all supported evidence types
```
请参阅 **[手动证据指南](docs/manual-evidence.md)**，了解需要手动证据的完整控制项列表以及收集的最佳实践。
## 安全保障
**仅执行只读操作。** Nisify 从不修改您的基础设施。所有平台 API 调用都是 GET/LIST 操作。
**凭据在静态时加密。** API 令牌和密码使用 Fernet 通过 PBKDF2-SHA256 密钥派生加密（600,000 次迭代，符合 OWASP 2023 建议）。最低要求 12 个字符的密码短语。凭据文件权限为 0600（仅所有者可访问）。
**无外部网络调用。** Nisify 仅连接您配置的平台 API。无遥测、无更新检查、无分析。
**本地仪表板。** Web 仪表板默认绑定到 localhost。无外部访问。
**审计跟踪。** 每次收集运行和每个操作都会记录时间戳，供您自己的审计需求使用。
## 运行测试
测试套件使用 Python 内置的 unittest 模块（无需 pytest）。
```
# 运行所有测试
python -m unittest discover tests/
# 运行特定测试文件
python -m unittest tests/test_collectors.py
# 运行详细输出
python -m unittest discover tests/ -v
```
**测试文件：**
| 文件 | 描述 |
|------|-------------|
| tests/test_collectors.py | 使用模拟 API 响应的平台收集器测试 |
| tests/test_mapping | 证据到控制项映射测试 |
| tests/test_scoring.py | 成熟度级别计算测试 |
| tests/test_cli.py | CLI 参数解析和命令测试 |
| tests/test_storage.py | 证据持久化和完整性测试 |
## 安装
**要求：**
- Python 3.11 或更高版本
- pip
**从 PyPI 安装（尚未可用）：**
```
pip install nisify
```
**从源码安装：**
```
git clone https://github.com/clay-good/nisify.git
cd nisify
pip install -e .
```
**可选依赖：**
```
# PDF 报告生成
pip install nisify[pdf]
# Snowflake 收集器
pip install nisify[snowflake]
# Google Workspace 收集器
pip install nisify[google]
# 所有可选功能
pip install nisify[all]
```
## 限制
本节诚实地描述了 Nisify 的限制。在采用该工具前请仔细阅读。
### 框架限制
- **仅支持 NIST CSF 2.0。** Nisify 不支持 SOC 2、ISO 27001、HIPAA、PCI-DSS、FedRAMP 或任何其他合规框架。暂无计划添加多框架支持。如果您需要其他框架，请使用其他工具。
- **无交叉对照。** Nisify 不会将 NIST 控制项映射到其他框架的控制项。它无法帮助您同时满足多个框架。
### 平台限制
- **支持 13 个平台。** Nisify 支持 AWS、Okta、Jamf Pro、Google Workspace、Snowflake、Datadog、GitLab、Jira、Zendesk、Zoom、Notion、Slab 和 SpotDraft。未来版本可能会添加其他平台。
- **不支持自定义平台集成。** 添加新平台需要编写 Python 代码。无插件系统或基于配置的连接器框架。
- **不支持本地基础设施。** Nisify 无法从服务器、网络设备或缺乏云 API 的应用程序收集证据。
- **平台 API 变更可能导致收集器失效。** 如果 AWS、Okta 或其他平台更改其 API，收集器可能停止工作，直到更新。
### 证据限制
- **大约 40% 的 NIST CSF 2.0 控制项需要手动证据。** 许多控制项（尤其是 Govern、Identify 和 Recover 功能中的控制项）需要政策文档、培训记录或其他无法通过 API 收集的证据。Nisify 会识别这些差距，但无法自动填充。
- **证据存在不等于合规。** 拥有 MFA 策略并不意味着 MFA 得到有效执行。拥有审计日志并不意味着有人查看它们。Nisify 报告存在什么，而不是是否有效。
- **不评估证据质量。** Nisify 检查证据是否存在及其时效性，但不分析证据是否展示了有效的控制。弱密码策略和强密码策略都算作“密码策略证据”。
- **点时收集。** 证据反映收集时的状态。收集之间的更改不会被捕获。不支持实时监控。
### 评分限制
- **成熟度评分是近似值。** 评分算法使用基于证据存在和时效性的启发式方法。审计员可能不同意评分。
- **评分可能不符合审计师期望。** 不同的审计师采用不同标准。Nisify 的评分在内部一致，但可能与外部评估不一致。
- **无行业基准。** Nisify 无法告诉您评分与类似组织的比较情况。没有匿名化数据收集或基准数据库。
- **权重简化。** 默认情况下，一个类别中的所有子类别以及一个功能中的所有类别权重相等。实际重要性因组织和风险概况而异。
- **Level 4（优化）很少能通过自动证据单独实现。** 最高成熟度级别需要展示持续改进，这通常需要手动证据和人类判断。
### 技术限制
- **单用户、单组织。** Nisify 不支持多租户。它在一台机器上为一个组织运行。无共享仪表板、无基于角色的访问控制、无团队功能。
- **仪表板仅限本地。** Web 仪表板绑定到 127.0.0.1。无远程访问、无 HTTPS、无多用户支持。
- **无实时监控。** 证据按计划收集（最频繁为每小时）。无流式传输、无 Webhook、无即时告警。
- **大型环境可能收集缓慢。** 拥有数千用户、设备或资源的大型组织可能需要很长时间收集。并行化有限。
- **Snowflake 查询消耗计算信用。** 从 ACCOUNT_USAGE 视图收集证据会执行查询，消耗仓库信用。频繁收集会增加成本。
- **SQLite 可扩展性限制。** 证据数据库使用 SQLite，不适合非常大的数据集。多年证据保留可能对大型组织造成性能下降。
- **基础备份机制。** 内置的 `nisify backup` 和 `nisify restore` 命令创建带有校验和的 tar.gz 存档。无自动备份计划、云同步或增量备份。
### 操作限制
- **无自动修复。** Nisify 识别差距但不会修复它们。它永远不会修改您的基础设施，即使是为了改进合规性。
- **无工单集成。** 差距建议显示在报告和仪表板中。无与 Jira、ServiceNow 或其他工单系统的集成。
- **无通知系统。** Nisify 设计为本地工具。无外部通知（Slack、邮件、短信、PagerDuty）。通过 CLI 或仪表板检查收集状态。
- **CLI 优先设计。** 虽然有仪表板，但大多数操作通过命令行执行。无配置的图形界面。
### 合规限制
- **Nisify 不能使您合规。** 使用 Nisify 并不意味着您通过审计。合规需要实施控制，而不仅仅是收集证据。
- **报告可能不满足审计员要求。** 审计员可能需要 Nisify 未提供的证据格式或细节。PDF 报告仅提供信息，不是审计工件。
- **无法律或认证价值。** Nisify 未获得 NIST 或任何认证机构的认证或批准。使用它不提供法律保护。
- **无法保证审计成功。** 即使使用合规工具，组织也可能审计失败。证据收集是必要但不充分的条件。
### 支持限制
- **开源无 SLA。** 无保证的响应时间。问题支持基于社区。
- **无专业服务。** 无咨询团队帮助实施、定制或审计准备。
### 当前开发限制
- **尚未达到生产就绪。** 这是 Alpha 软件。所有组件已集成，但未针对实时 API 进行测试。边缘情况下可能存在错误。
- **测试仅使用模拟。** 测试套件使用模拟 API 响应，不测试真实平台 API。测试验证内部逻辑，但无法捕获实际 API 集成中的错误。
- **API 可能变更。** 配置文件格式、CLI 参数和内部 API 可能在不通知的情况下更改，直到 1.0 版本。
- **依赖项未打包。** 依赖外部包（boto3、cryptography、requests、snowflake-connector-python），它们可能有自身安全问题。
- **错误处理有限。** 边缘情况和错误条件可能处理不佳。
- **无迁移路径。** 如果数据库模式或配置文件格式更改，无自动迁移工具。
- **收集器未针对实时 API 测试。** 收集器代码根据 API 文档编写，但未针对真实平台 API 进行测试。可能在分页、错误处理或数据解析方面存在错误。
- **Google Workspace 需要服务账户设置。** Google 收集器需要创建具有域范围委派的服务账户，这是一个复杂的手动过程。
- **Snowflake 收集器可能产生成本。** 从 ACCOUNT_USAGE 视图收集证据会执行查询，消耗仓库大小。成本取决于仓库大小和收集频率。
- **SQLite 单写者限制。** 证据存储使用 SQLite，一次只允许一个写入者。多个进程并发收集可能失败或阻塞。
- **未针对大数据集测试存储。** 证据存储引擎未针对大量证据数据进行测试。性能可能随着数千个证据文件或数百万条数据库记录而下降。
- **基础备份机制。** 内置的 `nisify backup` 和 `nisify restore` 命令创建带有校验和的 tar.gz 存档。无自动备份计划、云同步或增量备份。
- **映射配置未经过审计员验证。** 证据到控制项的映射基于对 NIST 要求的合理解释。审计员可能不同意特定映射。
- **成熟度评分是启发式近似值。** 成熟度计算器使用可配置的阈值和修饰符（自动化奖励、改进奖励、覆盖惩罚），它们是合理的默认值，但可能不符合您的审计师期望。
- **默认权重相等。** 一个类别中的所有子类别以及一个功能中的所有类别默认权重相等。这可能无法反映实际的组织风险优先级。
- **改进检测过于简单。** 改进奖励在当前分数超过之前分数时授予。这不考虑分数波动、临时退化或测量噪声。
- **新鲜度阈值是任意的。** 默认 30 天证据过期阈值是合理选择。您的组织或审计师可能有不同的期望。
- **Level 4 要求接近完美的分数。** 默认 Level 4（优化）阈值为 3.5/4.0，这很难通过自动证据单独实现。这是故意设计的，但可能让期望获得可实现 Level 4 分数的用户感到沮丧。
- **差距建议是通用的。** 内置建议涵盖常见场景，但可能不符合您的特定环境或约束。自定义建议需要代码更改。
- **优先级分类是启发式的。**差距优先级基于 NIST 功能（保护和检测默认为关键）以及成熟度级别。您的组织可能有不同的风险优先级。
- **趋势分析需要历史数据。** 有意义趋势至少需要 2 次成熟度快照。新部署将显示“数据不足”，直到收集历史积累。
- **波动检测过于简单。** 如果控制项分数在不同快照间显著波动，则标记为波动。这可能是某些证据类型的正常行为，也可能表明数据质量问题。
- **快速修复可能不快。** 标记为“低努力”的差距基于典型场景。实际工作量取决于您的环境、团队专业知识和现有基础设施。
- **PDF 生成依赖 weasyprint。** PDF 报告需要 weasyprint 库（具有系统依赖项：cairo、pango 等）。无 weasyprint 时，仅生成 HTML 报告。
- **报告样式固定。** PDF 报告采用单色设计，无法自定义样式（颜色、字体和布局硬编码在 CSS 中）。
- **高管摘要使用模板。** 生成的摘要使用固定模板和措辞。语言可能不符合您组织的沟通风格。
- **无自定义报告模板。** 报告结构固定（封面、执行摘要、成熟度、差距、证据）。添加或删除部分需要代码更改。
- **JSON 架构基础。** 导出的架构仅提供结构验证，不验证数据正确性或完整性。
- **大型报告可能失败。** 包含数千个差距或证据项的报告可能超出内存限制或生成非常大的文件。无大数据集的分页或分块处理。
### 仪表板限制
- **仅限本地使用。** 仪表板默认绑定到 127.0.0.1。无身份验证、HTTPS 或多用户支持。将其暴露到网络不安全。
- **自动刷新，非实时。** 仪表板支持自动刷新（默认 60 秒），但无基于 WebSocket 的实时更新。数据更新需要轮询 API。
- **仅 Vanilla JavaScript。** 仪表板未使用任何框架（React、Vue 等），以保持简单。这限制了交互性，可能感觉比现代仪表板陈旧。
- **Canvas 图表基础。** 趋势图直接使用 HTML5 Canvas API 渲染。无缩放、平移或交互功能。图表质量受限于专用图表库。
- **无图表库。** 为避免外部依赖，图表使用原始 Canvas API 渲染。复杂可视化（饼图、堆叠柱状图）未实现。
- **移动端支持有限。** 响应式 CSS 处理基本移动端布局，但体验针对桌面浏览器优化。
- **证据详情视图有限。** 证据浏览器显示元数据，但不显示完整证据内容。大证据负载会被截断。
- **搜索功能基础。** 全局搜索（Ctrl+K）在控制项、差距和证据中按 ID 和名称搜索。不支持证据内容全文搜索、高级筛选和保存的搜索。
- **单请求处理。** Python http.server 是单线程的。多个浏览器标签页的同时请求可能排队。
- **数据无缓存头。** API 响应不包含缓存头。浏览器缓存行为未定义。
- **模板渲染基础。** HTML 模板使用简单字符串替换（`{{variable}}`）。无条件逻辑、循环或转义。所有动态内容通过 JavaScript 处理。
### 调度器限制
- **需要密码短语进行自动收集。** 调度器需要访问加密凭据。对于系统 cron，必须在 cron 环境中设置 NISIFY_PASSPHRASE 环境变量。对于内置守护进程，必须使用密码短语启动或设置环境变量。
- **密码短语存储是安全问题。** 在环境变量或命令行中存储密码短语可能会在进程列表或 shell 历史中暴露它。无可集成系统密钥链用于计划执行。
- **系统 cron 要求 Unix 类系统。** 仅限 Linux、macOS 和其他具有 crontab 命令的 Unix 类系统。Windows 用户必须使用内置调度器。
- **内置调度器需要运行守护进程。** 内置调度器以守护进程形式运行。如果进程死亡，计划收集将停止。无自动重启、服务管理或 watchdog。建议使用 systemd、launchd 或 supervisord 管理守护进程。
- **守护进程在同一进程中运行。** 调度器守护进程在进程中运行收集。如果收集挂起或崩溃，必须手动重启守护进程。
- **每小时收集可能过于频繁。** 每小时从所有平台收集可能达到 API 速率限制、产生成本（Snowflake）或生成过多日志数据。建议大多数用例使用每日或每周。
- **收集时间固定。** 每日收集在 UTC 时间 02:00 运行，每周在周日 UTC 时间 02:00 运行。这些时间无法配置，除非修改代码。
- **无时区支持。** 计划时间仅为 UTC。无本地时区配置。
- **无故障告警。** 当计划收集失败时，错误记录到调度器日志文件。使用 `nisify schedule --logs` 检查日志。无外部通知集成。
- **日志轮转基础。** 日志在文件超过 5 MB 时轮转，保留 3 个备份。无日志压缩、无基于时间的轮转、无与系统日志（journald、syslog）的集成。
- **状态文件未加密。** 调度器状态文件（~/.nisify/scheduler/state.json）包含计划配置和运行历史，但不包含凭据。以明文存储。
- **PID 文件可能过时。** 如果守护进程崩溃而未清理，PID 文件可能包含陈旧 PID。调度器尝试检测并清理陈旧 PID，但可能存在竞争条件。
- **无收集锁定。** 如果手动运行 `nisify collect` 而调度器正在运行，两者可能尝试同时写入证据存储。SQLite 会处理，但其中一个可能被阻塞或失败。
- **无失败重试。** 如果计划收集失败（平台 API 错误、网络问题），调度器不会重试。等待下次计划运行。
- **Windows 支持未经测试。** 内置调度器应在 Windows 上工作，但未经过测试。信号处理和 PID 管理可能表现不同。
### 服务文件示例
以下服务文件使 Nisify 调度器守护进程可以作为系统服务在启动时自动运行并在失败时重启：
#### systemd（Linux）
创建 `/etc/systemd/system/nisify-scheduler.service`：
```
[Unit]
Description=Nisify Evidence Collection Scheduler
After=network.target
[Service]
Type=simple
User=your-username
Environment="NISIFY_PASSPHRASE=your-secure-passphrase"
Environment="HOME=/home/your-username"
ExecStart=/usr/local/bin/nisify schedule --start-daemon --foreground
Restart=on-failure
RestartSec=30
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
```
启用并启动服务：
```
# 重新加载 systemd 配置
sudo systemctl daemon-reload
# 启用服务开机自启
sudo systemctl enable nisify-scheduler
# 启动服务
sudo systemctl start nisify-scheduler
# 检查状态
sudo systemctl status nisify-scheduler
# 查看日志
sudo journalctl -u nisify-scheduler -f
```
#### launchd（macOS）
创建 `~/Library/LaunchAgents/com.nisify.scheduler.plist`：
```
Label
com.nisify.scheduler
ProgramArguments
/usr/local/bin/nisify
schedule
--start-daemon
--foreground
EnvironmentVariables
NISIFY_PASSPHRASE
your-secure-passphrase
RunAtLoad
KeepAlive
SuccessfulExit
StandardOutPath
/tmp/nisify-scheduler.log
StandardErrorPath
/tmp/nisify-scheduler.err
```
加载并启动服务：
```
# 加载服务（立即启动并在登录时启动）
launchctl load ~/Library/LaunchAgents/com.nisify.scheduler.plist
# 卸载服务
launchctl unload ~/Library/LaunchAgents/com.nisify.scheduler.plist
# 检查是否运行
launchctl list | grep nisify
# 查看日志
tail -f /tmp/nisify-scheduler.log
```
**安全说明：** 在服务文件中存储密码短语是一种安全权衡。自动凭证解密需要密码短语。替代方案包括：
- 使用权限受限的环境文件（systemd: `EnvironmentFile=/etc/nisify/env`）
- 使用 macOS 钥匙串配合辅助脚本
- 接受计划收集便利性的风险
## 文档
- [架构](docs/architecture.md) - 系统设计和组件概述
- [配置](docs/configuration.md) - 配置文件参考
- [收集器](docs/collectors.md) - 平台特定设置指南
- [手动证据](docs/manual-evidence.md) - 提交需要手动输入的 68 个控制项的证据指南
- [NIST 映射](docs/nist-mapping.md) - 证据到控制项映射参考
- [CLI 参考](docs/cli-reference.md) - 完整命令文档
- [API 参考](docs/api-reference.md) - 仪表板 API 文档
标签：AWS, Datadog, DPI, ESC漏洞, GitLab, Google Cloud, GRC 替代, Jamf, Jira, NIST CSF 2.0, NIST 控制, NIST 框架, Notion, Okta, SEO: NIST CSF 2.0 合规, SEO: 合规证据聚合工具, SEO: 多云合规平台, Slab, Snowflake, SpotDraft, Zendesk, Zoom, 云平台证据, 可追溯评分, 合规, 合规仪表盘, 合规差距, 合规成熟度, 合规成熟度评估, 合规自动化, 合规证据聚合, 合规追踪, 多云合规, 实时仪表盘, 审计友好, 手动证据, 文档结构分析, 无机器学习, 确定性评分, 证据收集, 证据聚合, 读-only API, 逆向工具, 透明评分, 零锁定