第八十七章

WSaiOS Security Architecture

WSaiOS 安全架构

87.1 工程目标

WSaiOS 安全架构用于保障系统在运行过程中的：

• 身份可信（Authentication）
• 权限可控（Authorization）
• 数据完整（Integrity）
• 配置安全（Configuration Security）
• 插件可信（Plugin Trust）
• 审计可追踪（Auditability）

安全架构覆盖 Core、Plugin、Workflow、API 等所有模块。

87.2 安全原则

WSaiOS 建议遵循以下原则：

1. 最小权限（Least Privilege）
2. 默认拒绝（Default Deny）
3. 显式授权（Explicit Authorization）
4. 可审计（Auditable）
5. 职责分离（Separation of Duties）

例如：

Plugin 默认没有文件写入权限，只有在配置中明确授权后才能访问指定目录。

87.3 安全模型

系统安全模型：

Application
      │
Authentication
      │
Authorization
      │
Capability
      │
Service
      │
Kernel

所有外部请求首先经过身份认证和权限检查，再进入业务层。

87.4 身份认证（Authentication）

对于本地单机版：

可以采用：

Local User

对于服务器部署：

可以支持：

• 用户名/密码；
• API Token；
• OAuth2（可选）。

认证模块只负责确认是谁。

87.5 权限控制（Authorization）

权限建议分层：

权限判断应在 API 层完成，而不是散落在各个 Service 中。

87.6 Plugin 安全

Plugin 必须经过 Loader 验证：

检查：

• Manifest 是否存在；
• 版本是否兼容；
• 依赖是否满足；
• 签名（可选）是否有效。

禁止：

Plugin 直接访问 Kernel 内部对象。

Plugin 只能通过公开 API 工作。

87.7 配置安全

配置文件建议分离：

config/

config.yaml

secret.yaml

其中：

• config.yaml 保存普通配置；
• secret.yaml 保存敏感配置（如 Token、密码）。

建议：

敏感配置不写入代码仓库。

87.8 数据完整性

对于重要数据：

例如：

• Workflow；
• Experience；
• Configuration；

建议记录：

ID

Timestamp

Checksum

保证：

数据未被意外修改。

如果需要更高安全等级，可增加数字签名。

87.9 日志审计

系统应记录关键操作：

例如：

审计日志应与普通运行日志分离。

87.10 Workflow 安全

Workflow 创建后：

应验证：

• Workflow 是否合法；
• 节点是否存在；
• Capability 是否已注册；
• Plugin 是否启用。

执行过程中：

禁止动态修改 Workflow 结构。

87.11 API 安全

API 建议统一支持：

• 身份认证；
• 权限验证；
• 请求校验；
• 错误处理；
• 访问日志。

这样：

业务模块无需重复实现安全逻辑。

87.12 安全验证

建立最小验证：

尝试：

未授权用户

↓

调用

↓

Execution Service

预期：

返回：

Permission Denied

再验证：

授权用户：

执行成功。

87.13 工程目录

建议新增：

security/

├── authentication.py
├── authorization.py
├── policy.py
├── audit.py
├── integrity.py
└── validator.py

各模块职责单一，便于维护。

87.14 本章总结

完成：

WSaiOS Security Architecture

建立：

• 身份认证
• 权限控制
• Plugin 安全
• 配置安全
• 数据完整性
• Workflow 安全
• API 安全
• 日志审计
• 安全验证