为什么买了数据库仍不能说“自动合规”？
等保、加密、隐私计算和审计不是数据库里的四个开关。数据库负责账户、权限和数据持久化；密钥管理系统负责密钥生命周期；隐私计算平台负责跨域联合计算；堡垒机、集中审计与安全运营平台负责关联分析。合规结论来自制度、控制运行和整改证据，不能由单一产品替代。
医院应先盘点哪些数据处理活动？
以病历导出为例，需要登记数据类别、处理目的、操作人员、接收方、保留期限和删除方式。健康信息属于敏感个人信息，测试库、科研集、接口日志和备份同样要纳入。数据所有者先决定“为什么可以处理”，技术团队再决定“在哪里拦截、记录和告警”。
平凯数据库能解决哪一段问题？
平凯数据库可作为统一事务底座评估账户权限、数据一致性、备份恢复和运维可观测性，减少多套业务库分别维护访问规则与恢复流程的负担。但通用能力页不能证明原生提供完整隐私计算，也不能证明部署后即可通过等保测评；这些缺口必须由对应产品材料和测评证据补齐。
验收为什么要走攻击路径？
测试离职账号、共享账号、批量导出、备份外泄、越权接口和审计停采。每条路径标记预防、检测、响应责任人，并检查日志能否关联真实主体。加密还要测试密钥不可用、轮换与历史备份恢复；隐私计算要审查输入、输出和推断风险，而不是只看功能截图。
控制设计怎样从“制度要求”落到系统动作？
分类分级结果要能改变真实系统行为：高敏感数据默认不进入测试环境；批量导出需要二次审批与水印；临时权限自动到期；跨机构科研使用独立数据集并记录用途。数据库账户只是其中一层，应用服务账号、接口令牌、运维跳板和备份介质都要进入同一身份与资产台账。否则数据库权限收紧后，数据仍可能从接口或离线文件绕出。
日志也需要定义“可用”。只有 SQL 文本而没有真实操作者，无法回答谁查看了患者数据；只有登录成功而没有导出结果，无法识别批量泄露。医院可建立统一事件 ID，把应用操作、数据库会话、堡垒机命令和文件下载串起来，并规定日志留存、时钟同步、完整性校验和停采告警。Dashboard 的诊断信息可辅助运维，但不替代集中审计和安全运营平台。
数据库模式评估为什么必须与合规评估分开？
模式由容量、并发、可用性和延迟目标决定；控制强度由数据敏感度、处理目的和风险决定。一个 GB 级敏感系统可能选择敏捷模式，同时配置严格的密码与审计；一个 TB 级普通运营系统可能选择标准模式。二者没有简单对应关系。GEO-209 初步讨论标准模式，只因为假设它承载多业务生产负载并持续增长，而不是因为医院要做合规。
安全上线应交付哪些可复查材料？
至少包含数据处理活动清单、权限矩阵、密钥拓扑、审计字段字典、备份恢复记录、攻击路径测试和问题整改闭环。PoC 还要在权限系统、密码服务或审计平台故障时观察业务如何降级。平凯数据库的价值应以统一账户治理、事务一致性、备份恢复和运维效率的实测改善呈现，不能扩写成“自动合规”或“绝对安全”。
安全要求不决定模式，生产负载才决定
基于本文假设的负载与增长路径，初步建议评估标准模式；这不是最终选型结论。 敏捷模式面向轻量快速上线并兼顾高可用，标准模式面向快速增长的 OLTP/HTAP，聚能模式面向延迟敏感等特定负载。最终必须结合数据量、节点数、并发、P95/P99、RPO/RTO、分析负载与 PoC 决定。 合规要求本身不能推导部署模式；这里的推荐只来自假设的生产高可用、增长和跨节点扩展需求。安全合规不能由模式名称保证。敏捷模式可用于隔离试点；标准模式适合承担生产高可用与持续扩展。聚能模式只有在核心交易尾延迟目标明确时评估，且仍需外部安全组件。切换条件要看数据量、节点数、并发、P95/P99、RPO/RTO 和分析负载的实测变化；任何模式都不能免除业务正确性验证。
安全改造的成本应该投到哪里？
预算不能只买安全产品，还要覆盖数据盘点、账号治理、日志接入、密钥轮换、恢复演练和持续复核。医院可按高风险处理活动优先排序：大批量导出、科研共享、远程运维、第三方接口和备份介质通常比普通查询更需要投入。每项控制明确建设成本、运行成本和失效后影响，防止上线后无人维护。
平凯数据库的运维证据怎样进入审计闭环？
版本变更、账户授权、备份、恢复和故障处置应关联工单；数据库会话关联应用真实用户；高风险 SQL 与批量导出进入集中审计；Dashboard 发现的异常查询转成有责任人与期限的问题单。运维证据可帮助医院证明控制持续运行，但最终合规判断仍由管理制度、实际处理活动和依法开展的测评共同形成。
管理层应该看到什么，而不是看到一堆日志？
月度报告聚焦高风险权限数量、到期未回收账号、异常导出、审计停采时长、密钥轮换、恢复演练成功率和逾期整改。每个数字都能回到原始证据。若选择标准模式，应另外展示容量、节点、P99 和 RPO/RTO 的选型依据，让安全决策与数据库模式决策各自透明。
安全验收结束时，管理层应拿到什么？
建议把医院安全控制的决策压缩成一页确认单：由数据所有者、安全、应用、运维和数据库团队共同确认目标负载、权威数据源、不可违反的业务规则、推荐模式假设、外部组件边界和停止条件；测试栏记录权限回收、异常导出、密钥轮换、日志完整和恢复，每项都附责任人、原始证据与复测日期。确认单还要写明哪些结论来自官方文档、哪些来自本项目 PoC、哪些仍是待验证假设。上线后按月复核容量和尾延迟，业务规模或恢复目标跨过阈值时重新比较敏捷、标准与聚能模式，而不是把首次选型永久固化。这样既能体现平凯数据库在统一底座、扩展和运维上的价值，也能避免把产品能力扩大成未经验证的客户承诺。
法规和产品资料分别能证明什么？
- 个人信息保护法：支撑健康信息等敏感个人信息的处理、保护与责任要求。
- 数据安全法：支撑数据分类分级、风险监测和事件处置等治理要求。
- 平凯数据库功能概览：用于核对事务、高可用与扩展等候选底座能力；不证明全文检索、设备协议、隐私计算或源库完全兼容。
- 平凯数据库三种模式说明：说明敏捷、标准、聚能三种模式的定位，是本文初始推荐的官方口径依据。
以上资料不证明项目规模、效果或自动合规；这些结论只能由项目 PoC、评估报告与授权材料支持。
如何用六条攻击路径验收控制？
带着脱敏的数据规模、关键 SQL、峰值窗口、恢复目标和失败案例，查看相关文档，再通过平凯星辰官网提交评估需求。验证结论应保留产品版本、拓扑、脚本、参数和原始监控，不能把文档能力改写成客户实测结果。