私有化部署安全检查表

安全检查表怎样服务真实业务？

先列需要保护的对象，再确定访问它们的身份和路径。管理账号、消费者资料、交易记录、私有附件、渠道配置和数据库备份各有不同的授权边界。检查表应写谁能读取、谁能修改、谁能导出，以及通过什么证据证明限制有效。只写“已做安全配置”无法用于验收，也难以在故障或人员变动时复查。

源码事实仅说明存在的检查入口，实际网络、账号、运维权限和渠道资料需要在目标环境核对。未发现问题与未执行检查必须分开记录，不能将空白项自动填成通过。

哪些路径应该出现在公网入口？

整理消费者访问、管理端操作、渠道回调和运行诊断四类入口。每项记录实际域名、路径、方法和授权机制；相同的路径在不同环境可能走不同代理，不能只查看应用代码。数据库端口、对象存储控制台和临时诊断页应逐项确认是否有必要暴露，默认配置不是访问批准。

现有发行入口范围为：现有发行网关代理 /api/ 并保留原路径与请求；对象入口仅允许指定公开桶的 GET，私有桶无公开代理。 正式HTTPS和外部回调还需按项目实施，不能把现有HTTP入口直接当作公网完整方案。检查时既访问允许路径，也验证不允许的路径和方法，确保不存在宽泛代理绕过应用授权的情况。相关工程说明见域名与HTTPS文档。

账号和业务范围应该怎样一起测试？

登录成功只能证明身份认证成立，不能证明拥有全部业务操作权限。用不同真实角色的合成账号测试读取、修改与导出，覆盖本范围和不属于本范围的对象。操作岗位变化后及时调整权限，保留人员交接和账号撤销的记录，不让共享管理员成为长期协作方式。

单体版存在账号类型声明、权限目录和业务审计声明；检查授权需同时核对请求方法、主体权限与业务数据范围。 接口授权应核对请求方法、主体权限和对象归属。检查用例要写期望允许或拒绝的理由，并通过正常业务入口读取结果；不能依靠直接修改数据库权限样本来制造通过。对敏感详情和批量导出，也要确认字段范围与运行留痕。

Cookie与请求防护该检查什么？

单体版管理会话使用会话 Cookie 与 X-CSRF-TOKEN；公开 storefront 只读链路与管理链路分别配置。 目标环境应核对Cookie的域、路径、安全属性以及实际代理链中的行为。若入口变化导致会话无法携带，不能通过关闭请求防护来快速修复。确认登录、正常保存、会话失效和退出后的结果，区分未登录与已登录但权限不足。

第三方回调与浏览器管理请求的验证方式不同，应按各自接口设计核验。需要签名或凭据的入口要测试错误、过期和重复请求，保留不含秘密的结果记录。浏览器检查通过也不等于外部渠道验签通过，渠道测试需要相应商户资料与独立场景。

配置秘密怎样离开代码和公开资料？

口令、保护钥匙、渠道密钥和会话材料不能进入源码、公开构建文件或可访问的静态目录。配置清单记录秘密类型、受控保管位置和负责人即可，不填写真实值。构建日志、运行错误与支持工单也应检查，避免为了排障打印整个环境或请求头。

长期保护钥匙与临时访问凭据的轮换方式不同。更换长期保护资料之前须判断既有密文如何继续读取，并准备恢复方案；不能在重启脚本中每次生成新值。外部实施方的临时账号要有用途和回收条件，交接完成后重新核对实际访问权限，而不只是收回文档中的账号列表。

附件与备份怎样防止错误公开？

公开商品素材和私有业务附件应采用不同访问规则。上传成功后检查文件类型、引用关系及读权限；删除页面链接不能证明文件已经不可访问。对象存储策略、代理路径和业务授权共同决定最终结果，必须测试匿名读取、正常主体读取和其他主体读取。

上传服务区分公开地址与私有对象；私有读取需要先做领域授权，过期地址不能作为持久业务链接。 私有地址的有效期与业务对象权限要分别确认。备份资料还可能包含更完整的业务信息，应保存在受限位置并记录访问和保留规则。恢复演练使用隔离环境，结束后处理临时副本与账号，不把真实个人资料长期留在开发目录。

怎样检查部署和变更权限？

检查项	允许的责任范围	验证方式	不应自动视为通过
程序发布	指定版本与批准窗口	产物校验、操作者和安装记录	有服务器登录权限
结构迁移	专门迁移角色与核定变更	迁移历史及运行角色权限	应用使用数据库超级账号
存储策略	指定桶与授权读取	匿名、合法与越权用例	合法上传一次成功
渠道配置	指定主体和测试生产范围	设置状态与渠道结果查询	模拟回调返回成功
备份恢复	受限恢复位置和批准用途	恢复记录、资料核对与清理	备份任务退出码正常
临时诊断	限定访问时段、入口和岗位	访问检查与到期回收	诊断后页面不再使用

发布工具的访问权限应与业务后台权限分别管理。技术人员能够替换程序时，可能影响全部运行规则，因此需要独立的变更记录和复核。直接进入数据库修数据属于不同的高影响操作，要核对范围、版本与业务后果，不能当作常规页面配置。

外部接口和依赖更新怎样纳入检查？

支付、短信和物流设置涉及外部主体和秘密，其测试环境、生产环境及授权范围应独立记录。检查真实渠道时限制测试资金、资料和通知对象，不向真实客户随意发送验证消息。未知结果先查询业务状态，再决定是否重试，避免把安全检查变成重复业务操作。

依赖清单应对应最终发行产物，包括后端包、前端运行依赖和随包工具。发现需要更新的组件时，沟通使用路径和影响，再安排构建与回归；不能为了追求版本新直接修改所有技术栈。完整清单和更新责任由项目确认，不把源目录里存在依赖声明等同完整SBOM已经交付。

检查结论应怎样交给客户？

将每项结果分为通过、未通过、未检查和不适用，附环境、版本、执行身份和脱敏证据位置。高影响未通过项写明业务风险与处理条件，由相关负责人决定能否继续，而不是在清单末尾统一勾选。补修后复验受影响入口，不用重复产生没有新信息的全量截图。

使用私有化部署检查清单记录项目状态，结合安全技术说明核对源码边界，并通过私有化部署服务确定客户与实施方的责任。回到部署专题把安全检查接入上线流程；