安全措施
ProcessMind 安全措施
生效日期：2026年9月14日
本文档说明 ProcessMind B.V. 为保护客户数据的机密性、完整性和可用性而维持的技术和组织措施（“TOM”）。ProcessMind 采用纵深防御方法，通过多个相互独立的安全层，在各个层面保护客户数据——从网络和基础设施，到身份、授权、数据隔离、加密、监控和软件开发。这些措施是对数据处理附录、隐私政策和SaaS 托管政策的补充。ProcessMind 至少每年审查并更新这些措施。
客户数据绝不会出售给第三方、与第三方共享，或供第三方用于其自身目的。
1. 基础设施安全
**1.1 云平台。**ProcessMind 仅托管于欧盟（德国法兰克福，eu-central-1）的 Amazon Web Services (AWS)。AWS 持有 ISO 27001、ISO 27017、ISO 27018、SOC 1/2/3 和 PCI DSS 认证。完整清单请参阅AWS 合规计划。
**1.2 无服务器架构。**ProcessMind 应用程序逻辑运行于 AWS Lambda 和 AWS 托管服务。ProcessMind 不运营由客户管理的长期运行应用程序服务器，因此无需进行大量操作系统修补和服务器强化工作。
**1.3 网络边界。**ProcessMind 维护 AWS VPC，以实施数据库和网络控制。Aurora PostgreSQL 在无互联网出口的私有子网中运行，无法公开访问，并已启用 VPC 流日志。默认情况下，ProcessMind 不会将应用程序 Lambda 函数置于 VPC 内。Lambda 通过 AWS RDS Data API 使用 TLS，并通过 IAM 和 Secrets Manager 身份验证连接 Aurora。
**1.4 内容交付与边缘控制。**面向客户的网站、前端 SPA 和公共资源流量均通过 Amazon CloudFront 提供服务。所有 CloudFront 分配均强制执行最低 TLS 1.2 (2021) 策略。网站和前端 SPA 分配还会添加安全响应标头，包括 HTTP 严格传输安全（HSTS）、内容安全策略（CSP）、frame-ancestors 'none'、X-Frame-Options: DENY、X-Content-Type-Options、引荐来源策略和权限策略。公共资源分配使用 CloudFront Origin Access Control，使源存储桶保持私有。面向客户的 API 流量通过 Amazon API Gateway 单独处理：HTTPS 请求/响应流量通过专用 API 子域上的 HTTP API 提供服务，实时客户端连接则通过专用 WebSocket 子域上的独立 API Gateway WebSocket API 提供服务。
**1.5 环境隔离。**生产环境和开发环境使用不同的 AWS 账户、不同的数据库和不同的基础设施堆栈。开发人员凭据不提供访问生产客户数据的权限。
2. 数据加密
**2.1 传输中加密。**客户端与 ProcessMind 服务之间传输的所有数据均使用 TLS 1.2 或席位等级为流程架构或以上加密。面向客户的端点通过 HTTPS 提供服务。由 ProcessMind 直接创建的 S3 存储桶、SNS 主题和 SQS 队列均强制仅允许 SSL 访问。通过 RDS Data API 进行的数据库访问及其他 AWS 服务调用均使用 HTTPS/TLS。
**2.2 静态数据加密。**Aurora PostgreSQL 使用客户管理的 AWS KMS 密钥进行静态数据加密，并自动轮换密钥。由 ProcessMind 直接创建的客户数据和运营 S3 存储桶（包括上传、资源和访问日志存储桶）均使用客户管理的 KMS 密钥。由 ProcessMind 直接创建的 CloudWatch 日志组、SNS 主题和 SQS 队列也使用客户管理的 KMS 密钥。由 SST 管理的网站和前端源存储桶使用 AWS 管理的 S3 服务器端加密（SSE-S3 / AES-256），而非客户管理的 KMS 密钥。
**2.3 密钥管理与机密信息。**数据库加密密钥通过 AWS KMS 集中管理，密钥访问权限依据最小权限原则由 IAM 策略管控。数据库凭据存储在 AWS Secrets Manager 中。Aurora 主密钥和受限应用程序用户密钥每三十（30）天自动轮换。生产密钥和机密信息绝不存储在源代码中；仅供开发使用的凭据与生产环境隔离。对于服务或框架未提供客户管理密钥配置选项的部分 AWS/CDK/SST 管理的支持资源，仍使用 AWS 管理的加密。
3. 数据隔离与驻留
3.1 租户隔离。 每个客户租户在共享的 Aurora 集群内拥有专用的 PostgreSQL 数据库，并设有按租户划分的访问控制。客户数据在数据库层面绝不会与其他客户的数据混合。共享元数据（例如账户记录、账单信息、用户与租户之间的映射）存储在单独的多租户数据库中，并受到严格的访问控制。按租户和组织范围划分的共享表还受到 PostgreSQL 行级安全（RLS）策略的保护，该策略通过请求范围的数据库上下文强制执行。
**3.2 数据驻留。**所有客户数据，包括数据库、文件上传、备份和查询结果，均专门存储在欧盟（德国法兰克福）。如为特定处理活动（例如 AI 模型处理或支付处理）聘用位于欧洲经济区以外的次级处理者，则根据《数据处理附录》所述的适当传输机制对该传输予以保障，并在《次级处理者名单》中列明该次级处理者及其处理地点。
**3.3 数据保留和删除。**数据保留和删除期限载于数据处理附录第 6 节。客户可随时通过应用程序删除其数据，或联系 ProcessMind 删除。备份副本将在适用的备份保留期限届满时移除（第 7.1 节）。
4. 身份与访问管理
**4.1 身份验证。**ProcessMind 支持通过 Microsoft Entra ID (Azure AD)、Google OAuth 2.0/OIDC 和 LinkedIn OAuth 2.0/OIDC 进行单点登录（SSO）。ProcessMind 作为依赖方，不存储用户密码。多因素身份验证由身份提供商强制执行——例如，组织连接 Microsoft Entra ID (Azure AD) 时，适用该组织自身的 MFA 和访问政策。
**4.2 会话管理。**浏览器会话使用签名的 JSON Web Token（JWT），通过带有 SameSite 和 Secure 标志的安全 HttpOnly Cookie 传输。每次经过身份验证的请求都会验证令牌签名。
**4.3 授权模型。**ProcessMind 的核心应用程序 API 不依赖 API Gateway 原生授权器。授权由共享 Lambda 处理程序包装器强制执行；该包装器会在业务逻辑运行前验证会话状态和租户范围。对于未经过身份验证的流程、webhook、事件接收和 CORS 预检请求，公共路由均通过明确的允许列表指定。外部 API 端点使用专用身份验证处理程序。客户数据的访问范围限定为经过身份验证的租户或组织上下文。
**4.4 最小权限。**内部系统遵循最小权限原则。在框架允许精确限定范围的情况下，IAM 角色仅限于所需的最低资源范围。部分 SST/CDK 生成的角色会使用范围较广的托管策略或内联策略，以支持绑定和运行时操作；这些情况会经过审查，在可能的情况下限定资源范围，并作为明确例外进行跟踪。
**4.5 员工访问控制。**员工通过 Active Directory 管理对内部系统的访问，并使用 SSO 和强制 MFA。基于角色的访问控制（RBAC）确保仅在有业务需要知悉的基础上，向获授权人员开放客户数据访问权限。访问权限会定期审查。
5. 日志记录、监控与审计
**5.1 集中式日志记录。**已启用 HTTP API 访问日志记录和 WebSocket 访问日志记录，日志包含结构化 JSON 字段，并写入 Amazon CloudWatch Logs，保留期限为一年（1 年）。这些访问日志组使用客户管理的 AWS KMS 密钥加密。应用程序日志集中存储在 Amazon CloudWatch 日志组中，使用客户管理的 AWS KMS 密钥加密，保留期限为十年（10 年）。单独的审计和遥测日志组也使用客户管理的 AWS KMS 密钥加密，保留期限为十年（10 年）。Aurora PostgreSQL 引擎日志导出组的保留期限为一周（1 周）。
**5.2 记录和未记录的内容。**ProcessMind 会记录 HTTP API 和 WebSocket 访问事件——请求时间、请求标识符、路由或路径、响应状态和延迟。访问日志不包含调用方的源 IP 地址或用户代理。ProcessMind 还会将身份验证事件、异步故障路径以及支持 Lambda 的应用程序活动记录到集中式 CloudWatch 日志组中。已启用 VPC 流日志。目前，ProcessMind 尚未在网站、前端 SPA 或公共资源分配上启用 CloudFront 标准访问日志记录。
**5.3 监控和警报。**CloudWatch 警报和仪表板用于监控系统运行状况、死信队列和与安全相关的故障。异步处理故障会被路由至加密的死信队列（保留十四（14）天；缩略图和搜索索引队列保留两（2）天），死信队列警报会触发 SNS 通知以供调查。此外，ProcessMind 使用 Sentry 进行前端错误实时跟踪、性能监控和会话回放。仅当会话发生错误时才会录制会话回放，且回放中的文本、表单输入和媒体均会被遮蔽或屏蔽。Sentry 数据在欧盟（法兰克福）接收，且仅限于 ProcessMind 使用数据（浏览器错误、性能跟踪、设备元数据和经遮蔽的回放录制）。Sentry 列于次级处理者名单中。
**5.4 日志保护。**日志存储在专用且受访问控制的 CloudWatch 日志组中，并进行静态加密。生产环境和开发环境的日志按环境和账户边界隔离。
6. 自动化控制验证与漏洞管理
**6.1 ProcessMind 的做法。**ProcessMind 在基础设施合成和部署工作流中运行cdk-nag，使用多个行业规则包（包括 AWS Solutions、NIST 800-53 和 PCI DSS）。每个堆栈都会生成报告，并作为基础设施变更管理的一部分进行审查。调查结果会分类为已修复、已接受的风险或计划改进。
**6.2 例外的管理方式。**在框架允许的情况下，抑制项会记录在中央登记册中，限定于受影响的堆栈，并须提供书面理由；如果某个堆栈包含内联抑制项，则会在该堆栈旁附带记录。发现项得到补救后，相应的抑制项将予以更新或移除。ProcessMind 不会将抑制视为一概免于审查。
**6.3 ProcessMind 目前未采取的措施。**ProcessMind 会跟踪并审查重大的基础设施控制例外。主要例外如下：
- 默认情况下，应用程序 Lambda 不部署在 VPC 内；它们通过 RDS Data API 使用 IAM 和 Secrets Manager 身份验证，经 TLS 连接至 Aurora
- 本服务的任何部分均未受 AWS WAF 保护：AWS WAF 不支持 API Gateway HTTP APIs，其余入口点也未受 WAF 保护（WebSocket 连接使用短期 HMAC 令牌；与支付相关的地理限制由支付系统执行）；静态分发也未启用 CloudFront 标准访问日志记录
- 数据库恢复依赖 Aurora 自动备份和时间点恢复，而非单独的 AWS Backup 计划或 Aurora Enhanced Monitoring
- 可变存储桶未配置跨区域 S3 复制或 S3 Object Lock
- 部分由 AWS/CDK/SST 管理的支持资源使用 AWS 管理的加密或范围较广的生成式 IAM 策略，因为该服务未提供由客户控制的替代方案
完整的抑制注册表与基础设施代码一并维护，并可应要求提供。使用 cdk-nag 规则包属于工程控制验证，并非外部认证、审计意见或关于符合 HIPAA、NIST 或 PCI DSS 的法律证明。
**6.4 依赖项管理。**持续监控软件依赖项是否存在已知漏洞。对于严重和高危漏洞，修补目标为七（7）天内完成。依赖项按定期周期更新。
**6.5 安全软件开发生命周期（SDLC）。**ProcessMind 在软件开发中采用纵深防御方法。对生产环境的每项变更在部署前都必须通过多个相互独立的自动化验证层：
- **静态分析和类型安全：**TypeScript 严格模式和 ESLint 在编译时强制执行类型正确性、空值安全以及与安全相关的编码模式。
- **AI 辅助代码审查：**AI 辅助分析为拉取请求提供额外的审查视角，以识别安全风险、逻辑错误和规范偏差，作为自动化测试的补充。
- **单元测试和集成测试：**全面的 Vitest 测试套件在开发环境中针对实时 AWS 资源验证业务逻辑、数据访问模式、API 行为和错误处理。
- **端到端测试：**基于 Playwright 的浏览器测试验证关键用户工作流，包括身份验证、数据上传、流程建模、模拟和多租户隔离。
- 基础设施合规扫描：
cdk-nag在每次变更时，针对多个合规框架验证基础设施即代码。 - **依赖项漏洞扫描：**自动化依赖项审计会阻止已知的严重和高危漏洞进入生产环境。
人工审查侧重于架构、安全边界和设计层面的决策，而非逐行检查代码。涉及结构性、安全敏感或基础设施变更时，除自动化验证外，还必须获得明确的人工批准。
所有验证层均通过 CI 强制执行，作为应用程序和基础设施变更合并至主分支的必要合并门禁。网站内容和静态资源发布遵循单独的、已记录的发布流程，并在部署时进行检查——包括自动检查法律文件是否为最新版本——而非通过应用程序 CI 门禁。紧急生产修复可以绕过 CI 门禁，但必须在二十四（24）小时内补做完整流水线运行并进行事后事件审查。
7. 备份和灾难恢复
**7.1 自动备份。**Amazon Aurora 持续执行自动备份，保留期限为七（7）天。备份使用与源数据库相同的客户管理 KMS 密钥进行加密。
**7.2 时间点恢复。**Aurora 支持在备份保留期限内恢复至任意秒级时间点，从而能够在数据损坏或意外删除时迅速恢复。
**7.3 S3 持久性和版本控制。**文件上传和运营工件存储在 Amazon S3 中，该服务提供 99.999999999%（11 个 9）的持久性。上传存储桶和资源存储桶已启用版本控制，以支持恢复和回滚。网站和前端部署存储桶中的内容属于可重现的构建工件，不作为备份系统。ProcessMind 目前未启用跨区域 S3 复制。
**7.4 业务连续性。**灾难恢复程序均有书面记录并定期测试。摘要载于灾难恢复、业务连续性和事件响应文件。该架构依赖eu-central-1区域内由 AWS 管理的服务，AWS 在多个可用区运营这些服务；Aurora 集群目前运行单个写入器实例，因此数据库恢复依赖自动备份和时间点恢复，而非区域内备用实例。Aurora 备份、S3 持久性、死信队列以及从源代码重建的静态资产均属于恢复策略的一部分。
8. 事件响应
**8.1 事件通知。**发生安全事件（定义见 DPA）时，ProcessMind 将在不无故拖延的情况下通知受影响客户；在可行的情况下，将于知悉事件后七十二（72）小时内通知。
**8.2 事件处理。**ProcessMind 制定并维持书面事件响应程序，涵盖识别、遏制、根除、恢复和事件后审查。摘要载于灾难恢复、业务连续性和事件响应文件。从事件中吸取的经验教训将纳入安全控制措施和流程。
**8.3 沟通。**事件通知包括事件的性质和范围、受影响的数据类别、为遏制事件所采取的措施，以及建议客户采取的行动。
9. 组织措施
**9.1 信息安全管理。**ProcessMind 维护一套符合 ISO 27001 原则的信息安全管理体系。ProcessMind 已选定 ISO 27001 认证和 SOC 2 Type II 鉴证的认证路径；正式认证流程尚未启动。
**9.2 安全意识。**所有有权访问客户数据的人员均接受安全意识培训。安全最佳实践已融入入职流程、开发工作流和运营程序。
**9.3 供应商和次级处理者管理。**次级处理者在合同中受约束，须遵守与本文档所述标准同等的数据保护标准。ProcessMind 维护公开的次级处理者名单，并在聘用新的次级处理者前至少提前三十（30）天发出通知。每年审查次级处理者的合规情况。
**9.4 保密。**所有获授权处理客户数据的人员均受书面保密义务约束。
10. 合规与认证
| 框架 / 标准 | 状态 |
|---|---|
| GDPR（欧盟《通用数据保护条例》） | 符合要求 |
| 欧盟数据驻留（德国法兰克福） | 已实施 |
| AWS 基础设施认证（ISO 27001、SOC 2、PCI DSS） | 通过 AWS 继承 |
| ISO 27001（ProcessMind） | 计划中——已选定认证路径；尚未启动正式流程 |
| SOC 2 Type II（ProcessMind） | 计划中——已选定认证路径；尚未启动正式流程 |
自动化基础设施控制验证（cdk-nag涵盖 AWS Solutions、HIPAA Security、NIST 800-53 R4/R5、PCI DSS 3.2.1、Serverless） | 已作为工程控制验证实施，并非认证 |
| 国际传输的标准合同条款（SCC） | 已实施（参见DPA） |
| 数据处理附录（DPA） | 已公开提供 |
使用 cdk-nag 规则包并不意味着 ProcessMind 已正式获得认证，或已就 HIPAA、NIST 或 PCI DSS 接受独立审计。这些规则包用作工程防护措施，以验证基础设施设计并明确跟踪差距。
如有关于安全或合规的问题，或需索取审计报告、已填写的安全问卷等文件，请联系support@processmind.com。