以下为本页可直接引用的结论要点，均来自正文对应章节的详细论证。
结论：DravenAI 的安全能力按「传输安全、存储安全、访问安全、审计安全」四层构建，四层各自独立生效、互相不替代。任何一层缺失都会形成可被利用的缺口——只做访问控制而不做审计，事后无法定责；只做存储加密而不做传输加密，链路仍可被窃听。安全配置的第一步是确认四层都已启用，而不是急于细化策略。
这四层与等保 2.0（GB/T 22239-2019）的「安全通信网络、安全区域边界、安全计算环境、安全管理中心」四个技术维度是直接对应的：传输安全对应通信网络，访问控制对应区域边界，存储与主机加固对应计算环境，审计日志对应管理中心。这种对应关系可以帮助安全团队把产品配置直接映射到等保测评项，避免重复梳理。
| 安全层 | 解决什么问题 | 核心机制 | 默认是否开启 | 关闭或缺失的后果 |
|---|---|---|---|---|
| 传输安全 | 防止链路窃听与中间人篡改 | 全站 TLS 1.2 及以上、禁用弱加密套件、内网服务间 mTLS、管理端强制 HTTPS | 是，且不可关闭 | 账号口令、检索内容、文件内容在链路中可被还原 |
| 存储安全 | 防止介质丢失或越权读取后的批量泄露 | 对象存储服务端加密、数据库透明加密、备份集加密、密钥独立托管 | 是，算法可选 | 磁盘或备份介质失窃即等于数据全量泄露 |
| 访问安全 | 防止不该看的人看到、不该改的人改了 | 身份认证、多因素认证、四级权限模型、字段级脱敏、IP 与时段策略 | 是，策略需按组织配置 | 内部越权成为主要泄露来源 |
| 审计安全 | 事后可追溯、可定责、可取证 | 全量操作日志、日志防篡改、留存周期策略、异常行为告警 | 是，留存期可调 | 发生泄露事件后无法定位责任人与影响面 |
平台方负责产品自身的安全机制、漏洞修复与安全配置默认值；客户方负责账号生命周期管理、权限策略设计、密钥保管、网络边界策略与人员管理。私有化部署环境下，操作系统补丁、数据库加固、堡垒机与网络隔离由客户负责，产品不越权接管主机。
不建议一开始就把策略开到最严。推荐按「先可视、后管控」推进：第一阶段只开审计与分级标记，观察真实访问行为；第二阶段再对确认的高敏资产收紧权限与外发管控。直接上最严策略往往导致业务绕过系统，反而形成新的不可控渠道。
结论：人数少于 50 人且无统一身份源时可用本地账号；已有企业微信、钉钉、AD 域或统一身份平台时必须对接 SSO，避免账号孤岛；涉及管理员、外部协作与高密级资产访问的角色必须叠加多因素认证。认证方式的选择标准是「账号生命周期能否与企业 HR 流程联动」——离职账号能否自动停用，是判断方案是否合格的关键。
DravenAI 支持三种认证来源并存：本地账号用于应急管理员与自动化账号，OIDC/SAML 用于企业统一身份，LDAP/AD 用于已有目录服务的组织。三种来源可同时启用并按组织单元分配，切换期间不会中断历史数据归属。
| 认证方式 | 适用场景 | 接入要点 | 账号生命周期 | 风险提示 |
|---|---|---|---|---|
| 本地账号 | 小型团队、应急管理员、系统对接账号 | 口令长度 ≥12 位且含三类字符，首次登录强制改密，90 天定期更换 | 手工创建与停用 | 离职未及时停用即产生僵尸账号，需配套季度账号审计 |
| OIDC / SAML 单点登录 | 已上线企业微信、钉钉、飞书或统一身份平台 | 配置签发方地址、客户端 ID 与密钥、回调地址白名单，字段映射以工号为主键 | 随主账号启用/停用自动同步 | 身份源自身故障会导致全员无法登录，须保留 1 至 2 个本地应急管理员 |
| LDAP / AD 目录 | 已有域控，按组织单元管理 | 配置服务地址、Base DN、同步周期与属性映射，建议每 4 小时增量同步一次 | 随目录对象启用/停用同步 | 组织单元调整后可能出现权限继承错乱，需在调整后做一次全量校验 |
| 多因素认证（MFA） | 管理员、外部协作方、高密级资产访问 | 支持动态口令与短信二次校验，可按角色与密级组合开启 | 与主体账号绑定 | 短信通道不可达时需预置备用验证方式，否则会锁死管理员 |
一个容易被忽略的点是「服务账号」的管理。用于系统集成的 API 账号不应绑定个人，应使用独立的服务账号并限制其可访问的资产范围与接口范围；调用凭证应支持按季度轮换，轮换期间保留旧凭证 24 小时以避免中断。服务账号的操作同样进入审计日志，且需标记调用来源系统，便于事后区分人工操作与自动任务。
结论：把权限拆成四级分别授权最易维护——组织级决定「能看到哪些业务域」，角色级决定「能做哪些操作」，资产级决定「能看哪些库与文件」，字段级决定「能看到哪些属性与多少内容」。四级之间是「与」的关系，任一级未授权即不可访问。只做角色级的粗粒度授权，是后续权限失控与频繁改权限的主要原因。
推荐做法是「角色只做标准套餐、例外走资产级授权」。即先定义 5 至 8 个标准角色覆盖 90% 的人，剩余的特殊情况通过把某个资产库单独授权给某个人或小组来解决，而不是为每个特例新建角色。角色数量超过 15 个通常意味着模型设计出了问题，此时应回退检查是否把资产级授权错误地做成了角色。
| 权限层级 | 控制对象 | 典型配置 | 变更频率 | 常见错误 |
|---|---|---|---|---|
| 组织级 | 业务域与部门数据范围 | 按部门树授权，跨部门需显式申请 | 低，随组织调整 | 把组织级当成唯一权限层，导致同部门内敏感资产全员可见 |
| 角色级 | 功能操作集合 | 浏览者、编辑者、审核者、库管理员、系统管理员、审计员 | 低，季度复核 | 角色过多且相互重叠，无法判断某人实际拥有哪些权限 |
| 资产级 | 具体资产库、目录、文件 | 授权到人/小组/组织单元，支持有效期 | 高，随项目启停 | 用全库授权代替目录授权，权限范围远大于实际需要 |
| 字段级 | 元数据字段与正文片段 | 客户名称、金额、身份证号等字段按角色脱敏 | 中，随合规要求调整 | 只脱敏显示不脱敏检索，导致可通过搜索结果反推原文 |
浏览者（只读、可检索、不可下载原文件）、编辑者（可上传与修改本人及本组内容）、审核者（可发布与下线、可驳回）、库管理员（可配置分类与元数据、可授权）、系统管理员（可配置参数与集成，不默认拥有数据权限）、审计员（只可查看日志，不可访问业务数据）。审计员与系统管理员必须分离，否则审计失去独立性。
权限申请应带有效期，默认 3 至 12 个月，到期自动回收并通知申请人续期。临时项目授权建议默认 30 天。回收环节要检查两件事：一是授权记录是否同步失效，二是已下载到本地的文件如何处置——后者需通过水印与外发审批来约束，技术手段无法完全阻断。
结论：加密的重点不在算法强度而在密钥管理。算法选 SM4 或 AES-256 都能满足合规要求，真正决定安全性的是密钥是否独立托管、是否定期轮换、是否能按资产单独销毁。把密钥与密文存在同一套存储里，等同于没有加密。
DravenAI 采用「数据密钥 + 主密钥」两级结构：每个资产库或每个租户使用独立的数据密钥加密内容，数据密钥本身再用主密钥加密保存。这样做的好处是单个密钥泄露只会影响一个库，且可以通过销毁某个数据密钥来让对应数据不可恢复，实现按需的密码级销毁。
| 加密对象 | 推荐算法 | 密钥管理 | 轮换周期 | 验证方法 |
|---|---|---|---|---|
| 传输链路 | TLS 1.2 及以上，优先支持国密套件的双证书模式 | 证书由企业 CA 或权威 CA 签发，私钥不出服务器 | 证书有效期 ≤13 个月 | 用协议检测工具确认已禁用 TLS 1.0/1.1 与弱套件 |
| 文件对象存储 | SM4 或 AES-256 服务端加密 | 数据密钥由主密钥加密托管，支持接入 KMS | 数据密钥 1 年，主密钥 2 年 | 直接读取底层存储文件，确认无法还原明文 |
| 数据库 | 透明加密（TDE）或表空间加密 | 与数据库自身密钥体系集成，或使用国产数据库内置能力 | 跟随数据库策略 | 导出数据文件后尝试直接打开，确认不可读 |
| 备份集 | 与源数据一致，且独立密钥 | 备份密钥与生产密钥分离保管 | 与源数据同步轮换 | 用备份集恢复到隔离环境，确认恢复后数据完整且仍需授权 |
| 索引与向量 | 索引随存储加密，向量单独加密 | 向量不可反推原文，但仍需加密避免语义泄露 | 重建索引时自动轮换 | 确认检索服务返回内容受权限控制，而非仅靠索引隔离 |
国密适配的常见误区是「只换了算法就算完成」。完整适配需同时满足四点：算法使用 SM2/SM3/SM4、证书由支持国密的 CA 签发、依赖的中间件与数据库同样支持国密、以及密码合规检测能通过。实施顺序建议为「先中间件、后应用、再客户端」，因为客户端浏览器与移动端对国密的支持程度差异较大，通常需要保留国际算法作为降级方案。
结论：先分级再脱敏。分级决定管控力度，脱敏只是分级后的执行手段之一。建议采用「公开、内部、秘密、机密」四级，并明确每级的判定标准、默认授权范围与外发要求。分级的常见失败原因是标准写得过于抽象（如「重要数据」），导致不同人判定结果不一致，最终分级形同虚设。
| 密级 | 判定标准 | 典型内容 | 默认可见范围 | 外发要求 |
|---|---|---|---|---|
| 公开 | 可对外发布，泄露无影响 | 产品手册、公开案例、招聘信息 | 全员及外部访客 | 无限制 |
| 内部 | 仅限内部流转，泄露造成轻微影响 | 内部流程、培训材料、一般报表 | 本组织全员 | 需部门负责人同意 |
| 秘密 | 泄露造成经济损失或合作风险 | 报价单、合同、技术方案、客户名单 | 按项目授权的团队成员 | 需审批并加水印，禁止个人邮箱外发 |
| 机密 | 涉及个人信息、财务核心或监管要求 | 身份信息、薪酬、财务凭证、未披露事项 | 指定人员且逐条授权 | 原则上禁止外发，确需外发须双人审批并留痕 |
脱敏策略要与分级对应，并同时作用于「显示、检索、导出」三个环节，只做显示脱敏是典型漏洞：用户虽看不到完整身份证号，却可以通过搜索特定号码片段命中记录并反推。常用策略包括掩码（保留前 3 位与后 4 位）、截断（只显示前 N 字）、泛化（金额显示为区间）、以及按角色返回不同粒度。导出环节必须单独设置开关，默认关闭原样导出，开启时需二次确认并记录导出内容与时间。
先用规则识别结构化敏感字段（身份证、手机号、银行卡、统一社会信用代码），再用关键词与正则识别文档中的敏感表述（合同金额、客户名称、未公开代号）。规则库需按行业补充，通用规则通常只能覆盖 60% 至 70% 的实际敏感内容，剩余部分靠人工复核补齐。
提供「申诉—复核—订正」通道：用户认为分级或脱敏有误时可发起申诉，由数据owner在 2 个工作日内复核并订正。所有订正动作留痕。没有这条通道，业务部门会通过改名、拆分文件等方式绕开规则，反而更难管控。
结论：审计日志至少记录「谁、在什么时间、从哪个地址与设备、对哪个对象、做了什么操作、结果如何」六要素。缺少任一要素都会导致事后无法还原完整链条。留存周期建议不少于 6 个月，涉及等保三级或重要数据的场景建议 12 个月以上，并满足日志本身不可被普通管理员修改或删除的要求。
| 日志类别 | 记录内容 | 建议留存 | 主要用途 |
|---|---|---|---|
| 登录认证日志 | 账号、时间、来源 IP、设备指纹、认证方式、成功或失败、失败原因 | 12 个月 | 发现暴力破解、异常地点登录、僵尸账号 |
| 权限变更日志 | 操作人、被授权人、变更前后权限、有效期、审批单号 | 12 个月 | 追溯越权来源、验证审批流程是否被执行 |
| 数据访问日志 | 访问者、资产 ID、操作类型（查看/检索/下载/预览）、命中条数 | 6 至 12 个月 | 泄露事件影响面评估、异常批量下载识别 |
| 内容操作日志 | 创建、修改、发布、下线、删除及前后版本标识 | 12 个月 | 内容溯源、误删恢复、责任界定 |
| 导出与外发日志 | 导出范围、条数、格式、审批人、接收方 | 24 个月 | 外发合规举证、泄密事件定责 |
| 系统配置日志 | 参数调整、集成变更、密钥轮换、开关启停 | 12 个月 | 故障与配置变更的关联分析 |
日志防篡改的实现方式是「追加写入 + 完整性校验」：日志只允许追加不允许修改，每条记录带上一条记录的校验值形成链式结构，任何中间修改都会导致后续校验失败。同时把日志同步到独立的日志服务器或对象存储，使本机管理员无法同时抹除两处记录。审计员角色只能读取日志，不具备删除权限。
结论：等保 2.0（GB/T 22239-2019）三级要求中，与 DravenAI 直接相关的技术项集中在身份鉴别、访问控制、安全审计、数据完整性与保密性、以及个人信息保护五个方面。产品侧提供机制与配置能力，测评时需由客户方按实际部署环境出具配置证明与截图，二者缺一不可。
| 等保要求 | 产品侧能力 | 客户侧需完成的配置 |
|---|---|---|
| 身份鉴别：口令复杂度与定期更换 | 口令策略可配置、弱口令字典检测、到期强制修改 | 按等级保护要求设置长度与更换周期，并覆盖所有本地账号 |
| 身份鉴别：双因素 | 支持动态口令与短信二次校验，可按角色开启 | 对管理员与高密级访问角色开启双因素，并保留应急通道 |
| 访问控制：最小权限与默认拒绝 | 四级权限模型、默认无授权即不可见 | 角色设计评审、清理默认账号、季度权限复核 |
| 安全审计：覆盖所有用户与关键事件 | 六要素日志、防篡改、可导出 | 开启全部审计项、配置留存周期、接入集中日志平台 |
| 数据完整性：重要数据传输与存储校验 | 传输校验、存储校验、版本留痕 | 启用校验开关，定期抽样验证备份可恢复 |
| 数据保密性：传输与存储加密 | TLS、存储加密、国密算法可选 | 替换自签证书、接入 KMS 或按规范托管密钥 |
| 个人信息保护：采集告知与最小化 | 字段级脱敏、访问范围限制、导出审批 | 明确个人信息字段清单、设置脱敏规则、关闭默认导出 |
| 剩余信息保护：退出与释放 | 会话超时自动登出、缓存清理 | 设置会话超时（建议 ≤30 分钟）并验证共享终端场景 |
结论：安全检查不要依赖记忆，用清单逐项打勾。以下八组共 32 项覆盖了私有化部署上线前的高频风险点，建议在预生产环境完整跑一遍后再投产，并把打勾结果作为上线评审的输入材料。
1. 已删除或停用所有默认账号与测试账号；2. 本地账号口令长度与复杂度策略已生效；3. SSO 字段映射以工号为主键且已验证离职同步；4. 管理员已开启双因素；5. 服务账号已独立创建并限制了接口范围。
1. 角色数量在设计范围内且无重叠；2. 已抽查 10 个账号确认实际权限与预期一致；3. 临时授权均设置了有效期；4. 审计员与系统管理员为不同人员。
1. 已替换为正式证书且禁用 TLS 1.0/1.1；2. 对象存储与数据库加密已开启；3. 密钥已独立托管且备份密钥与生产密钥分离；4. 国密场景已完成全链路适配验证。
1. 分级标准已发布且完成存量标记；2. 识别规则已按行业补充并抽样验证；3. 显示、检索、导出三处脱敏均已生效；4. 导出开关默认关闭且开启需审批。
1. 六要素字段完整；2. 留存周期满足合规要求；3. 日志已同步到独立存储；4. 已验证普通管理员无法删除日志。
1. 仅开放必要端口并配置来源限制；2. 管理端已限制可访问网段；3. 主机补丁与基线加固已完成；4. 数据库与中间件未使用默认口令。
1. 备份策略已配置且至少完成一次恢复演练；2. 备份集已加密且异地保存；3. 应急管理员账号可用且离线保管；4. 已明确安全事件的上报路径与联系人。
1. 分级标准、权限申请流程、外发审批制度已发文；2. 已完成一次全员安全意识说明；3. 已确定季度复核的责任人与时间。
以下问题来自客户实施与测评现场的高频提问，答案给出可直接执行的做法。
通常是缓存未失效。检索结果与预览内容会有短期缓存，权限变更后需等待缓存过期或手动触发刷新。若等待后仍异常，检查该用户是否存在多条授权记录、是否被更高层级组织权限覆盖，以及资产级授权的有效期是否已过期。
技术上可以配置全域只读角色，但不建议默认开启。推荐做法是授予「申请后可查看」的权限：日常不开放，需要时发起申请并留痕。这样既满足管理需要，又避免该账号成为单点泄露源。
必须预置 1 至 2 个不依赖 SSO 的本地应急管理员账号，口令离线保管在保险柜或密码库中，并纳入应急演练。同时确认身份源自身具备高可用，因为 SSO 一旦不可用影响面是全员的。
按「单独组织 + 最短授权 + 有效期」三原则：为外部人员建立独立的外部组织，只授权具体项目目录而非整个库，授权默认 30 天到期回收，并开启双因素与水印。项目结束后立即清理账号而不是禁用。
会影响一部分。脱敏字段不应参与全文检索的分词索引，否则既降低准确率又可能被反推。建议做法是：脱敏字段只用于精确匹配与过滤，语义检索使用非敏感的正文与摘要字段，并在检索结果中返回脱敏后的显示值。
不要靠缩短留存来省空间，而应做分级存储：近 30 天热数据保留在可快速检索的存储中，30 天以上转冷存储，到期自动归档。同时降低低价值日志的记录粒度（如合并频繁的预览请求），但登录、权限、导出三类日志必须全量保留。
主要取决于依赖组件。若数据库与中间件已支持国密，应用层改造通常在 2 至 4 周；若需替换数据库或中间件，周期会延长到 2 至 3 个月，且需要重新做性能压测。建议先在测试环境完成全链路验证再排期投产。
关注四个信号：来源 IP 或地点突变、非工作时段的大批量访问、单次会话内下载或导出条数远超历史均值、以及访问与自己职责无关的资产类型。把这四类做成规则告警比人工翻日志有效得多，注意先用历史数据调阈值以控制误报。
按业务归属定到岗位而非个人：每个资产库明确一个业务部门的指定岗位作为 owner，负责分级判定、授权审批与季度复核。人员变动时 owner 随岗位转移，避免出现无人负责的库。owner 清单本身需要每半年更新一次。
不算。配置是静态的，合规是持续状态。必须建立季度复核机制：复核账号有效性、权限是否与当前职责匹配、分级标记是否随业务变化更新、日志留存是否在有效期内。没有复核机制的配置在半年后通常已经失效。