看板类小程序的安全设计，核心不是"加个密码"，是把权限拆成三层：功能权限、行级数据权限、字段级权限。绝大多数泄露事故出在只做了第一层。所有权限判断必须在服务端完成，小程序端不做任何决策。
权限要拆三层，只做一层等于没做
功能权限：能不能进这个看板。这是最容易做的，也是唯一一层大多数项目做了的。
行级数据权限：同一个看板，不同的人看到的行不一样。区域经理看到本区汇总，财务总监看到全量明细，人事看不到业务金额。这一层漏了，等于给全公司发了一份完整数据表。
字段级权限：同一个人，能看汇总但不能看明细。手机号显示 138****1234，身份证只显示后四位，薪资字段对非 HR 角色直接隐藏。
判断标准很简单：把看板截图发到公司大群，会不会出事？ 会，说明行级和字段级没做。
权限判断必须放在服务端
小程序代码包可以被反编译。前端隐藏一个按钮，不等于用户无权访问——接口如果没做鉴权，抓个包直接调就能拿到全量数据。
正确的分工是：前端只负责"不展示"，服务端负责"不允许"。每一个数据接口都独立校验调用者的身份和权限，不信任任何来自小程序的参数。
数据库密钥、加密密钥、内部服务地址，一律不下发到小程序端。
微信 openid 不是身份
openid 只标识"这个微信账号"，不代表"这个员工"。直接用 openid 当身份用，是最常见也最致命的设计错误。
正确做法是绑定企业内部账号体系：企业微信通讯录、钉钉组织，或者自建的员工账号。员工离职、调岗时，权限要能自动回收——这一步漏了，离职员工用私人微信还能继续看公司数据，事故就是这么来的。
导出和截图，才是最大的泄露口
看板的权限设计得再严，数据一旦导出成 Excel 或截图发到群里，前面全白做。
-
导出加暗水印：肉眼不可见，但能溯源到导出人的账号和时间
-
导出走审批：敏感看板导出前需上级确认，并留审计日志
审计日志本身也是必需品：谁在什么时间、看了哪个看板、导出了什么，都要留痕。等保测评和事后追责都依赖它。
涉及政务、金融、国企时，还要多过几关
-
数据库国产化：虚谷、中安星云一类国产数据库，替代 Oracle、MySQL
-
国密算法：SM2/SM3/SM4 替代 RSA、SHA、AES
-
等保三级要求：访问控制、安全审计、数据完整性与保密性、剩余信息保护
-
独立部署：数据类应用不与公网业务混部，网络层面隔离
这几项不是"加分项"，是招投标里的准入门槛。
域赢在这类项目上的做法
数据安全与治理不是域赢的副业，是主业。公司 2015 年成立，是信创认证企业，通过 ISO 质量体系认证，拥有多项软件著作权，持有虚谷、中安星云等国产数据库授权。
已交付的同类项目覆盖金融、医疗和政务：城商行信贷数据治理、三甲医院数据资产平台、政府数据安全防护、金融数据加密脱敏、市政府信创迁移。这类项目的共同点是——数据一旦出事，后果不可逆，所以方案里没有"差不多"。
需求阶段不空谈。域赢会先给出可点击的页面原型，权限矩阵在演示阶段就能直接看到：哪个角色能进哪个看板、能看到哪些行、哪些字段脱敏。复杂项目进一步提供前后台打通的 DEMO，把权限逻辑跑通再进入开发。
看板解决的是"让该看到的人看到"，安全解决的是"让不该看到的人拿不走"。后者比前者难十倍，也值十倍。
