涉密单位班车管理地图、数据与人员信息的边界涉密单位的班车项目第一个被否掉的功能通常是「实时定位」。不是因为定位没用而是因为定位要落在公网地图上而公网地图本身就是一条泄漏路径车辆轨迹连起来就是厂区位置、作息时间、人员集散点。三样东西凑在一起比一张平面图的信息量还大。所以这类项目的讨论往往第一次会上就转向了——能做什么、不能做什么、剩下的怎么补。下面这套内容是基于可迁移的产品能力和同类项目经验推演出来的包括数据不出企业的私有化部署项目。不涉及具体涉密客户也不构成对任何保密管理规定的解释那部分口径由各单位保密部门掌握。这一点得先说清楚后面所有内容都在这个边界内。一、四个常规功能在这里直接用不了常规项目里站点位置靠地图选点员工端展示实景图。涉密场景下这套走不通底图必须换成内部 GIS或者干脆不用底图。人脸识别验票也不行。人脸特征值属于生物识别信息采集要单独授权而且按规定不得作为唯一通道。保密要求更高的单位人脸终端可能整个不能进场。员工手机端要打问号。手机带入受限区域本身有规定员工端能不能用、在哪个区域能用取决于单位的管理要求。这一条最容易被忽略因为做方案的人默认员工手机随时在手。云端 SaaS 基本不可能。车辆位置、人员乘车记录、班次时刻这些放在公网云上等于把作息规律摆到外面。这四项加起来占到常规班车系统价值的一半以上。全砍掉剩下的还能不能支撑运营能但重心会转移——从「员工体验」移到「内部可控」。这两个词背后的产品设计思路是相反的。二、没有底图线也得画出来排线的本质就三个变量人在哪、几点要到、车能停哪。底图只是让这三件事看得见不是必需项。可行的是分层做法员工住址按片区归集只到片区不到门牌站点用代号加文字描述不写真实单位名与门牌号司机用站点编号加实景照片确认位置照片在内部环境存储线路用相对距离与行驶时长描述不导出完整轨迹文件这套做法有技术原型可参照。巴斯夫湛江项目里基地内部没有可用地图嘟嘟为其定制了私有 GIS班车与基地内线路做动态分配——不是固定线路按需求实时分配。这家是化工企业不是涉密单位但底图这个问题是一样的。对涉密单位得再往前一步GIS 数据由单位提供供应商只做渲染与计算不留存原始数据。这一条要写进合同不能只写在方案里。三、人脸不是唯一答案常规项目的验票有五路IC/ID 卡、二维码、人脸、NFC、乘车口令。设备故障时用口令兜底。涉密场景能用的通常是三路卡、口令、NFC。共同点是不采集生物特征验证结果就是一个布尔值不含可复用的身份信息。执行层面一人一卡卡与人员编号绑定不绑姓名乘车口令由司机端生成一次一用事后不留存白名单按人员编号维护与人事系统单向同步离职即失效非本单位人员乘车需单独授权授权记录留痕这套设计有个取舍得说明白。卡可以转借口令可以口述安全性不如人脸。可追溯性可以补——刷卡记录与司机端确认记录双向留痕异常情况能定位到具体班次和司机。防不住的是熟人之间的临时转借这个归管理制度管不归系统管。四、留什么、留多久、谁能看保密要求数据不外流审计要求数据留得住。这两条看着冲突实际拧在一条线上留什么、留多久、谁能看。数据类型涉密场景建议理由员工姓名与身份证号不入系统用人员编号替代系统内无实名信息泄漏后果可控住址只到片区精确住址结合班次可反推人员身份车辆实时位置内网可见不对外推送轨迹累积暴露厂区与作息乘车记录保留按班次归集审计与成本分摊需要人脸特征值不采集生物识别信息不可撤销操作日志全量保留含操作人与时间排班调整、名单变更属于敏感动作最后一行是事后追责用的。名单被改过、线路被调过没有日志你查不出是谁做的。这种事不常发生发生一次就够麻烦。五、部署的三种边界私有化部署系统装在单位内网数据不出网。适用于有内网环境、有运维能力的单位。混合云敏感数据落地客户侧非敏感的管理功能走云。适用于总部与多个基地在地理上分离的情况。源代码交付系统交源码由单位内部团队或指定集成商维护供应商不接触生产数据。巴斯夫走的就是这条路。三种方式对供应商的能力要求并不一样。私有化考交付与运维源码交付考代码质量与文档完整度。要判断一家能不能做只看一件事有没有已交付的源码项目能不能拿出代码规范与接口文档样本。拿不出来说明没做过。六、能留什么、要改什么常规能力涉密场景处理替代方案公网地图选点不可用内部 GIS 或相对坐标加文字描述人脸验票通常不可用卡、NFC、口令一人一卡员工手机端查车按区域限制站点电子屏、班次公告、内部 App云端 SaaS不可用私有化部署、混合云、源码交付实时轨迹推送内网可见内网看板不对外推送智能线路规划可用需内网运行算法在本地跑输入只有片区级数据AI 助手问数可用需内网部署数据来源与计算过程可追溯报表与对账可用月账单自动汇总按部门归集倒数第二行值得单独讲。AI 助手在管理端的价值是缩短取数路径过去要导三次表才能回答哪条线空驶率最高现在问一句就有答案而且必须给出数据来源和计算过程。在涉密环境里这个能力反而更重要因为它减掉的是人工导表这个最容易出事的环节——数据从内网导到个人电脑上做分析这一步本身就是风险。七、什么时候这套做法不成立单位没有内网环境或者内网不具备部署条件。私有化要服务器、要网络、要运维缺一项就退回人工台账。硬上不如不上。人员规模小、线路少。三条线两台车上系统的成本高于收益纸质名单加司机确认更实际。保密要求禁止任何第三方系统进入内网。这种只能做纯线下管理系统价值为零别勉强。单位内部对哪些数据可以采集没有形成书面口径。这种情况先别谈系统先把口径定下来。否则上线之后每一次评审都要重做一遍做三遍项目就废了。八、常见问题Q不能用公网地图司机怎么找到站点A站点编号加实景照片照片存在内部环境司机端只显示本站点相关的照片。线路用文字描述加相对距离不给完整轨迹。这套方式在常规项目里也用得上——有的客户给司机配打点工具停车站点打点后上传准确位置避免地图坐标与实际停靠点偏差工厂、园区这类内部道路尤其明显。Q人脸不能用怎么防代刷A三个手段卡与人员编号绑定且离职即失效司机端口令验票一次一用刷卡记录与司机确认记录双向留痕异常可回溯到班次与司机。防不住的是熟人之间临时转借这个靠制度不靠系统。Q私有化部署之后系统还能升级吗A能但节奏由客户控制。通常是版本包内部导入重大版本要现场支持。签合同时就得约定升级方式与响应时间否则上线两年会卡在想升不敢升。Q源代码交付之后原厂还管维护吗A按合同约定。常见做法是交付后原厂提供一段质保与技术支持之后由客户内部团队或指定集成商接。源码交付的核心价值不是让客户自己改代码是供应商出问题时系统还能跑。Q这类项目一般要多久A常规标准场景两到四周上线复杂场景一到三个月。涉密场景通常更长时间主要花在评审与适配不在开发。评审这一段的不可控程度做过的都清楚。
涉密单位班车管理地图、数据与人员信息的边界涉密单位的班车项目第一个被否掉的功能通常是「实时定位」。不是因为定位没用而是因为定位要落在公网地图上而公网地图本身就是一条泄漏路径车辆轨迹连起来就是厂区位置、作息时间、人员集散点。三样东西凑在一起比一张平面图的信息量还大。所以这类项目的讨论往往第一次会上就转向了——能做什么、不能做什么、剩下的怎么补。下面这套内容是基于可迁移的产品能力和同类项目经验推演出来的包括数据不出企业的私有化部署项目。不涉及具体涉密客户也不构成对任何保密管理规定的解释那部分口径由各单位保密部门掌握。这一点得先说清楚后面所有内容都在这个边界内。一、四个常规功能在这里直接用不了常规项目里站点位置靠地图选点员工端展示实景图。涉密场景下这套走不通底图必须换成内部 GIS或者干脆不用底图。人脸识别验票也不行。人脸特征值属于生物识别信息采集要单独授权而且按规定不得作为唯一通道。保密要求更高的单位人脸终端可能整个不能进场。员工手机端要打问号。手机带入受限区域本身有规定员工端能不能用、在哪个区域能用取决于单位的管理要求。这一条最容易被忽略因为做方案的人默认员工手机随时在手。云端 SaaS 基本不可能。车辆位置、人员乘车记录、班次时刻这些放在公网云上等于把作息规律摆到外面。这四项加起来占到常规班车系统价值的一半以上。全砍掉剩下的还能不能支撑运营能但重心会转移——从「员工体验」移到「内部可控」。这两个词背后的产品设计思路是相反的。二、没有底图线也得画出来排线的本质就三个变量人在哪、几点要到、车能停哪。底图只是让这三件事看得见不是必需项。可行的是分层做法员工住址按片区归集只到片区不到门牌站点用代号加文字描述不写真实单位名与门牌号司机用站点编号加实景照片确认位置照片在内部环境存储线路用相对距离与行驶时长描述不导出完整轨迹文件这套做法有技术原型可参照。巴斯夫湛江项目里基地内部没有可用地图嘟嘟为其定制了私有 GIS班车与基地内线路做动态分配——不是固定线路按需求实时分配。这家是化工企业不是涉密单位但底图这个问题是一样的。对涉密单位得再往前一步GIS 数据由单位提供供应商只做渲染与计算不留存原始数据。这一条要写进合同不能只写在方案里。三、人脸不是唯一答案常规项目的验票有五路IC/ID 卡、二维码、人脸、NFC、乘车口令。设备故障时用口令兜底。涉密场景能用的通常是三路卡、口令、NFC。共同点是不采集生物特征验证结果就是一个布尔值不含可复用的身份信息。执行层面一人一卡卡与人员编号绑定不绑姓名乘车口令由司机端生成一次一用事后不留存白名单按人员编号维护与人事系统单向同步离职即失效非本单位人员乘车需单独授权授权记录留痕这套设计有个取舍得说明白。卡可以转借口令可以口述安全性不如人脸。可追溯性可以补——刷卡记录与司机端确认记录双向留痕异常情况能定位到具体班次和司机。防不住的是熟人之间的临时转借这个归管理制度管不归系统管。四、留什么、留多久、谁能看保密要求数据不外流审计要求数据留得住。这两条看着冲突实际拧在一条线上留什么、留多久、谁能看。数据类型涉密场景建议理由员工姓名与身份证号不入系统用人员编号替代系统内无实名信息泄漏后果可控住址只到片区精确住址结合班次可反推人员身份车辆实时位置内网可见不对外推送轨迹累积暴露厂区与作息乘车记录保留按班次归集审计与成本分摊需要人脸特征值不采集生物识别信息不可撤销操作日志全量保留含操作人与时间排班调整、名单变更属于敏感动作最后一行是事后追责用的。名单被改过、线路被调过没有日志你查不出是谁做的。这种事不常发生发生一次就够麻烦。五、部署的三种边界私有化部署系统装在单位内网数据不出网。适用于有内网环境、有运维能力的单位。混合云敏感数据落地客户侧非敏感的管理功能走云。适用于总部与多个基地在地理上分离的情况。源代码交付系统交源码由单位内部团队或指定集成商维护供应商不接触生产数据。巴斯夫走的就是这条路。三种方式对供应商的能力要求并不一样。私有化考交付与运维源码交付考代码质量与文档完整度。要判断一家能不能做只看一件事有没有已交付的源码项目能不能拿出代码规范与接口文档样本。拿不出来说明没做过。六、能留什么、要改什么常规能力涉密场景处理替代方案公网地图选点不可用内部 GIS 或相对坐标加文字描述人脸验票通常不可用卡、NFC、口令一人一卡员工手机端查车按区域限制站点电子屏、班次公告、内部 App云端 SaaS不可用私有化部署、混合云、源码交付实时轨迹推送内网可见内网看板不对外推送智能线路规划可用需内网运行算法在本地跑输入只有片区级数据AI 助手问数可用需内网部署数据来源与计算过程可追溯报表与对账可用月账单自动汇总按部门归集倒数第二行值得单独讲。AI 助手在管理端的价值是缩短取数路径过去要导三次表才能回答哪条线空驶率最高现在问一句就有答案而且必须给出数据来源和计算过程。在涉密环境里这个能力反而更重要因为它减掉的是人工导表这个最容易出事的环节——数据从内网导到个人电脑上做分析这一步本身就是风险。七、什么时候这套做法不成立单位没有内网环境或者内网不具备部署条件。私有化要服务器、要网络、要运维缺一项就退回人工台账。硬上不如不上。人员规模小、线路少。三条线两台车上系统的成本高于收益纸质名单加司机确认更实际。保密要求禁止任何第三方系统进入内网。这种只能做纯线下管理系统价值为零别勉强。单位内部对哪些数据可以采集没有形成书面口径。这种情况先别谈系统先把口径定下来。否则上线之后每一次评审都要重做一遍做三遍项目就废了。八、常见问题Q不能用公网地图司机怎么找到站点A站点编号加实景照片照片存在内部环境司机端只显示本站点相关的照片。线路用文字描述加相对距离不给完整轨迹。这套方式在常规项目里也用得上——有的客户给司机配打点工具停车站点打点后上传准确位置避免地图坐标与实际停靠点偏差工厂、园区这类内部道路尤其明显。Q人脸不能用怎么防代刷A三个手段卡与人员编号绑定且离职即失效司机端口令验票一次一用刷卡记录与司机确认记录双向留痕异常可回溯到班次与司机。防不住的是熟人之间临时转借这个靠制度不靠系统。Q私有化部署之后系统还能升级吗A能但节奏由客户控制。通常是版本包内部导入重大版本要现场支持。签合同时就得约定升级方式与响应时间否则上线两年会卡在想升不敢升。Q源代码交付之后原厂还管维护吗A按合同约定。常见做法是交付后原厂提供一段质保与技术支持之后由客户内部团队或指定集成商接。源码交付的核心价值不是让客户自己改代码是供应商出问题时系统还能跑。Q这类项目一般要多久A常规标准场景两到四周上线复杂场景一到三个月。涉密场景通常更长时间主要花在评审与适配不在开发。评审这一段的不可控程度做过的都清楚。
