很多老板第一次接触野草，可能都会想问一个问题： 野草安全吗？ 但是我想先问一句： 你觉得，这个世界上有绝对安全吗？ 如果有人告诉你： “我的系统绝对不会被攻击。” “你的数据绝对不会泄露。” “你的数据绝对不会丢失。” 那么，我建议你保持一点怀疑。 因为，我认为没有任何人能够真正做到这些。 野草也是。 野草真正希望做到的，我更愿意称它为「相对安全」。 不是保证永远不会出问题。 而是真的出了问题以后，也能尽可能降低损失，保护顾客隐私。 提高恶意者攻击成本，降低攻击性价比。 下面，我用一些偏技术性的语言来说明一下关于野草的数据和安全思维 ⸻ 一、野草的数据安全理念 1. 先说清楚：野草保证不了什么（这叫丑话讲在前头，哈哈） 数据永远不会泄露 数据永远不会丢失 数据永远不会损坏： 任何软件、任何店、任何云，都做不到「绝对零风险」。野草不拿这种空话当卖点。 2. 那野草追求什么？ 野草换了一个更实在的目标： 就算坏人真的偷到了数据库，也尽量拼不回顾客的完整隐私。 这叫「先当坏人已经得手」来设计（手册里叫 Assume Breach，白话就是：别假装库永远偷不走）。 配套四句话： 非必要，不透露： 能少存就少存；不该看的人，就应该看不到！ 用过的信息，按规则模糊： 送完餐、结完单，详细地址等该脱敏就脱敏 任何一处单独被偷，都拼不全隐私： 库、备份、云、认证中心——单独拿一份，都不该等于「开箱即读全部顾客信息」 保护的是顾客隐私，不是保护数据库文件本身： 文件被偷了可以认；隐私被还原才是要极力避免的 3. 数据归谁？ 归开店的人（服务器 / 店铺拥有者），不归野草当「中央大平台」收着。 野草是工具；怎么装、怎么管、怎么备份、出了事谁担责——开店的人是运营责任主体。 野草开发者提供软件和规则说明；店铺正式营业之后的日常安全与合规，不能指望野草替店背锅。 这些话可能有点不近人情。 但现实就是这样。 真正需要承担经营责任的人，最终还是店铺老板自己。 野草只能尽力帮你降低风险，而无法替你承担风险。 二、第一阶段：数据安全打算怎么搭？ 重要：下面很多是规则和施工目标。截至现阶段，通道拆分（①②③ 分门）、隐私加密分存等，规则方向已基本定下，但是代码尚未全部落地！ 1. 三层「单线联络」——像「机房 + 店内柜台 + 网上柜台」 野草不用「全平台一个大库」，而是一家店一套结构，用三个角色分工（代号 ①②③）： ① 野草本体 机房 + 真账本 订单、菜品、顾客隐私等权威数据在这里；不是日常收银台 ② 本地联络员 店里 Wi-Fi 上的柜台 堂食扫码、员工干活、老板日常管店——走这里 ③ 通信转接节点： 互联网上的柜台（可选） 外面的人远程下单——走这里；可自己装，也可用公共节点（订阅服务），不碰货款 单线联络的意思是：公网消息不能直扑机房，必须按固定路线走： 外面客人 → ③ → ② → ①（机房） 店里客人 → ② → ① ③ 禁止直连 ①——就像不允许外卖客人从后门直接进仓库。 标准化配置 只有 ①： 不能对外营业 ① + ②： 标准主体：店里照常营业（堂食为主）；没有 ③ 也行 ① + ② + ③： 在上面基础上，再加网上远程下单（可选升级） 为什么要分开？ 把「日常营业入口」和「机房」分开，攻击面变小：就算网上柜台被打扰，也不等于坏人直接坐在账本上改数。 2. 权限：谁能看什么 买家： 自己的订单 店主 / 员工： 本店经营需要的；不需要顾客身份证等 骑手： 配送需要的地址、电话；不需要完整实名档案，订单完成后，顾客个人情报模糊化处理 联盟 / 认证中心： 只做信任与通信节点，不碰营业 修电脑做维护的服务商： 默认不能碰库；有必要碰数据库，须老板明确授权，计划是一次性或限时授权，用完即失效 登录也有分工：买家、店主走「生态登录」；员工走「店铺工作台」，两扇门不混用，减少串号、误权限。 3. 怎么提高攻击者的成本（第一阶段目标） 分门进出： 营业走 ② / ③，机房走另一条维护通道，不能和收银混一门 互相验身份： ② 和 ③ 之间要验「钥匙对不对」「程序是不是正版」（凭证 + 程序指纹；规则已定，代码逐步做） 访客 Wi-Fi 不上公网： 客人连 Wi-Fi 只为打开店里 ②，不占满带宽、也不给坏人多开一条路 桌码用店内局域网地址： 不依赖宽带公网 IP；本地营业不要求有公网 出事可先关公网 ③： 网上柜台有问题，店里 ② 仍可照常（不是「云挂了全店停」） 隐私加密、分开存： 手机、地址、姓名等加密，和一般业务数据分库 / 分存——正式上线前必须做到。 HTTPS、关调试、密钥不进代码： 对外加密访问；生产环境不暴露详细报错；密码钥匙用环境配置，不写在程序里 备份至少两份： 一份在本地；一份可上云，但必须是加密后的，云服务商默认读不懂 目标不是「没人来攻」，而是：攻了也得不偿失——偷来的东西拼不出完整隐私，或者代价远大于收益。 4. 备份怎么做（第一阶段） 至少两份。 本地自动备一份。 可再有一份加密后放云盘；云盘被偷也应读不出明文。 可选：自己用 U 盘再拷一份加密备份。 5. 第一阶段还没完全做到、但规则已写死的 ①②③ 物理分门、维护通道独立——目标态已定，程序仍在逐步改（过去可能是「一个入口包打天下」）。 合法授权解密流程全文——占位，待专门设计。 部分通道安全 细则——规则有，代码未全落地。 未完成隐私加密分存，不应该被用于对外营业。 三、最终阶段：数据安全打算长什么样？ 野草路线是 三阶段：单店 → 区域联盟 → 认证完善。安全构想随阶段加厚，但核心理念不变。 1. 第二阶段（区域联盟） 店铺数据仍以店铺为准： 区域服务器主要是副本、名录、自由骑手池、区域规则——不是把全区订单集中成一个大库让谁都能看 联盟默认「最小知情」： 例如：联盟服务器默认不知道用户详细地址；各模块只留履职必须的信息 认证中心开始部署： 先做一些基础能力（如唯一账号等），还不是最终完整形态 备份与脱敏深化： 与区域副本、授权流程等衔接，字段级脱敏规则更细 2. 第三阶段（认证完善） 认证中心： 不负责替你跑日常生意；侧重：实名与唯一身份、跨区信用互通、联盟之间传重要数据时的「通信信任节点」、规则包审计等 跨区传重要数据： 须过认证中心的许可，不是随便拷库 解密仍须授权： 认证中心批的是「能不能、批多少」，不是默认握有一把「万能解密钥匙」长期开着 规则治理： 规则修改走提案、公示、投诉等机制（与数据安全相关的元规则也有上限约束） 单一对象仍拼不全隐私： 店、联盟、认证中心、云、备份——任一块单独失窃，仍不应等于完整隐私 3. 最终形态的「理想画面」（白话） 店：机房在店（或店节点），数据主人是老板。 营业：只经柜台（② / ③），消息单线进机房。 隐私：加密分存；用完该模糊的模糊。 联盟 / 认证：各管各的，默认不看不该看的订单明细。 备份：多份、加密；云也只是存「看不懂的密文」。 授权：谁、何时、为何解密有流程、有记录；临时解密，用完就失效。 攻击者：偷到某一处，仍要跨越多道门才能还原隐私——成本高、收益低。 四、理念和构造的弱势点（须知情） 诚实说：野草不是银弹。下面是目前设计里固有的短板或依赖人的环节。 1. 理念层面的「不保证」 不承诺不泄露、不丢失、不损坏——只承诺尽量让泄露后的伤害变小。 若期待「绝对安全」，会与野草的设计前提不一致。 2. 依赖开店的人会不会做 图方便全体云部署： 例如整店只有「云上一台」（旧称纯云）：云挂了只能手工营业；危险系数高不推荐 不做加密分存就营业： 原则上禁止，但是开源项目，若有人硬上，隐私保护大打折扣 备份不做或只做一份： 硬盘坏了、误删了，照样丢数据 密钥管理马虎： 密码写在便签、发给不该给的人——这是人性的弱点，我也有这种不良习惯，但是网络安全意识，必须提高啊 乱授权服务商： 图方便，长期开放远程、不限时——这是信任与人性的问题，野草无能为力 3. 架构与实现上的弱项 规则领先于代码： ①②③ 分门、维护通道、规则的规划，我跑的飞快，但是代码实现和实际测试，双拳难比四手，我是业余开发者，请见谅！ 第一阶段 ①② 可同机： 省事，但物理上不如「机房和柜台两台机器」隔离得干净，野草的建议是，只要有条件，①②分机，安全性更高 ② / ③ 仍有缓存与会话： 原则上不存完整库，但前台会有临时数据；这是流转过程无法避免的问题 浏览器「记住密码」： 野草可不勾选自记，但无法 100% 禁止浏览器自己弹「保存密码」 4. 运营与人为环节 员工账号与权限： 店内有人恶意或疏忽，内鬼风险靠店主管人，人性是最无法把握的，切记 公网 ③ 仍是高暴露面： 有网络营业就有被扫、被试的风险；靠 HTTPS、限流、验钥匙等抬高成本，不是「没有攻击」，野草尽量做到，③被击破，也不会影响本地本体 断网与支付： ② 不能上网时，线上支付会受影响；规则允许现金等兜底，不是全自动 远程批准、第三方： 微信、云主机、公共转接节点等都在生态外；野草管的是怎么接，管不了对方出不出事 5. 阶段演进带来的复杂度 联盟、认证中心加入后，参与方变多——协调、授权、审计要求更高；设计目标是各怀其责、不集中成超级库，但实施难度更大。 跨区互通后，配置错误或授权滥用的影响面可能变大，更依赖流程与审计做对。 6. 和「大平台」比的心理预期 野草没有大厂那种 24 小时安全运营团队替每家店扛。 好处是数据在店、不抽佣、不中央囤数据；代价是安全 largely 是店主的责任与选择。 五、给不同对像的一句话 想开店的老板们： 数据是你的；按 ①②③ 分开装、隐私加密、双备份；正式营业前完成硬门槛。 身为顾客的亲们： 野草倾向少存、加密、分门；但不保证绝对不出事，店仍是责任主体。