定制业务系统的安全基础：审计记录、备份，以及该向开发方问什么

在您委托定制业务系统之前，别人会请您确认界面、功能和价格。却很少有人请您确认系统将如何受到保护，而这恰恰决定了坏日子来临时会发生什么：员工删掉了错误的客户名单，销售的密码被人猜中，价格被改了却没人知道是谁改的，或者服务器恰好在每月28号出故障。

本指南写给不懂技术、即将聘请开发方的老板和经理，无论对方是自由职业者、公司内部开发人员还是软件公司。它不教您自己去加固系统，而是提供用通俗语言就能问的问题、好答案是什么样子，以及书面报价里应当写什么。这是一般性指导，不是法律意见，也不描述任何供应商的做法。关于谁能看什么、做什么，本文只指向已有的指南，不再重复；这里的重点是审计记录、带恢复测试的备份、登录安全，以及把它们串起来的尽职调查（先查证再签约）问题。

用大白话讲安全：三个问题

评估一位开发方，并不需要安全术语。几乎每一项保护措施，都是在回答三个问题之一：

• 谁能进来，进来后能做什么？账号、角色、密码和两步验证。
• 发生了什么，是谁做的？审计记录，以及它背后的活动记录。
• 出了问题，能不能恢复？备份、经过测试的恢复，以及系统怎样托管和更新。

这三个问题底下还有第四个：我们持有哪些个人数据，由谁负责？因为答案涉及法律，下面单独用一节来讲。

如果有人用“别担心，绝对安全”或“100%安全”来回答安全问题，请保持警惕。没有哪个系统是完全安全的。好的开发方会谈到保护了什么、记录了什么、您怎样发现出了问题、以及怎样恢复。如果听到的只有保证，请要求把具体内容写成书面。

谁能看什么、做什么

角色是第一道保护，审计记录也依赖它。如果所有人共用一个登录账号，记录里就只能写“办公室里有人做了这件事”。所以第一项尽职调查很简单：每个人都有自己的账号，每个角色只能查看和修改其工作所需的内容。要把这件事定好（老板、经理和员工三类角色，每类记录要决定的六种操作，审批额度，以及员工入职或离职时怎么办），需要一份专门的指南，所以这里不再重复。请先阅读谁该看到什么：定制业务系统中的用户角色与权限，再回来看下面的审计记录、备份和登录。

审计记录：谁在什么时候改了什么

审计记录（也叫审计日志或操作历史）是系统对重要操作自动保存的记录：谁做的、做了什么、针对哪条记录、什么时候做的。它不同于“最后修改”字段，后者只显示最近一次修改。审计记录会按顺序保留每一次改动。

举一个虚构的例子。客户投诉报价单上的价格上周是 RM2,400，现在却写着 RM2,000。有审计记录的话，您打开这张报价单的历史就能看到：“11月3日下午4:12，Aisha（销售）把单价从 RM2,400 改为 RM2,000，折扣由林先生批准。”没有的话，您只能在办公室里到处问，然后靠猜。

审计记录在日常中有四个用处：

• 化解争议。它回答“这是谁改的？”，既不用责怪，也不用猜测。
• 及早发现错误。错误的批量修改或删除可以被找出并撤回，因为您能看到具体动了哪些记录。
• 防止滥用。人们知道价格、库存和客户资料的改动会被记录，行为就会不同。
• 协助会计师或审计师。清晰的财务改动历史能让年终的疑问容易得多。

审计记录不必涵盖每一次点击。什么都记会让日志庞大到没法读。请和开发方一起决定哪些事件对您的业务重要，只记这些。

该记录什么，不该放什么

请把下表当作起点，再按需要调整。合适的清单取决于您的业务：诊所和贸易公司关心的记录并不相同。

同样重要的是日志里不该有什么：密码、完整的支付卡号或其他机密。日志本身也是一份信息存档，所以请问开发方，像身份证号码这样的敏感资料在日志里是怎么处理的。

接着要问日志本身如何受到保护。被记录的人自己就能编辑或删除的记录，价值不大。可以向开发方提出这些问题：

• 谁能查看？通常是老板和指定的经理，而不是全体员工。
• 有人能编辑或删除条目吗？普通用户不应该能，管理员也应受到限制。
• 保存多久？约定一个适合您业务的期限。会计记录需要保留多久，请问您的会计师。
• 能搜索和导出吗？如果不能按记录或按人搜索，到需要时就很难用。
• 开发范围包含它吗？不要想当然。请把它作为报价里的单独一项列明。

备份：复制什么、多久一次、放在哪里

备份是单独保存的一份数据副本，以便在东西丢失、损坏或被删除时可以恢复。对业务系统来说，“备份”并不是一件事。请问清楚覆盖了下面哪些：

• 数据库。客户、订单、发票、库存和所有其他记录。这通常是最有价值的部分。
• 上传的文件。报价单、照片、已签署的文件和附件，它们常常和数据库分开存放。
• 设置和程序代码。配置和程序本身，这样才能在不从零开始的情况下搭建替换的服务器。

然后问四个关键问题：

• 多久一次？请换成“能承受丢失多少工作”来想。如果系统在下午5点出故障，您能接受丢失一整天的录入、一小时的录入，还是一条都不能丢？这个答案决定备份频率，而丢得越少，可能越贵。
• 副本放在哪里？只放在同一台服务器上的备份，会和那台服务器一起消失。请要求至少有一份在别的地方。
• 保留多少份过去的副本？旧副本是挽回几天后才发现的错误的办法，例如错误导入的文件。
• 谁能访问或删除？备份里有您的全部数据，所以访问权限应限于指名的人，副本也应该不容易被误删，或被接管了某个账号的人删掉。

托管公司的备份和您系统的备份，不一定是一回事。主机可能按计划复制服务器上的文件，却没有人检查您系统的数据库能否恢复到可用状态。请要求开发方书面说明系统数据有哪些备份、各由谁负责、谁来付费。网站这一部分有它自己的文件和数据库，请参阅网站备份指南；本指南讲的是业务系统内部的数据。

恢复测试：从未恢复过的备份只是一种希望

您能向开发方提出的最有用的问题，也是最简单的一个：“你们上一次从备份恢复是什么时候，成功了吗？”备份可以连续运行几个月，却在需要的那天失败，原因可能是缺了文件、副本损坏，或者恢复流程从未演练过。恢复测试能证明整条链路是通的。

请要求开发方在上线前做一次，使用系统的一份独立测试副本，这样正式数据完全不受影响：

1. 选一份备份。选真实的备份，不要用专门为测试做的副本。
2. 恢复到单独的环境。不要覆盖在正式系统上。
3. 检查。登录，把记录数量和已知数字对照，打开几张最近的订单，确认上传的文档能打开，并检查备份时间点的最新录入是否都在。
4. 计时。写下花了多久，因为这大致就是您没有系统可用的时间。
5. 写下步骤和负责人。在坏日子里，当初开发的人可能联系不上。
6. 约定何时重复。书面约定一个节奏，例如重大改动之后以及按约定的间隔。

把它当作验收的一部分。用户验收测试指南介绍了如何做验收清单，“恢复测试通过”应当列在其中。

登录：密码与两步验证

大多数入侵靠的是被盗、重复使用或被猜中的密码，而不是高明的技术手段。所以基础比任何花哨的东西都重要：

• 一人一个账号。不共用登录，审计记录才有意义。
• 不留默认密码。要求在上线前更改或删除任何初始密码或内置管理员密码。
• 长而唯一的密码。长度比花哨的符号更有用，密码管理器能让它变得可行。员工不应在多个网站重复使用同一个密码。
• 防止反复猜测。多次失败尝试后，系统应放慢速度或锁定账号。
• 安全的重置流程。重置不应让陌生人只凭知道一个邮箱地址就接管账号。
• 密码安全存放。问问密码是否以连开发人员也无法读回的形式保存。答案应当是肯定的。

两步验证（也叫双重验证或 2FA）在密码之外要求第二项证明，例如手机应用里的验证码。这样，被盗的密码本身就不够用了。至少要为管理员和任何能看到金钱或个人数据的人开启，并问问能否为所有人开启。一般认为应用生成的验证码比短信验证码更强，不过短信验证码也比没有好。还要问某人丢了手机会怎样，因为那个找回步骤不能变成容易闯入的后门。

员工离职当天就要停用其账号；角色指南中的入职、调岗和离职流程讲了这一点。至于托管账号本身的登录，请参阅保护您的 cPanel 主机账号。

托管与更新，简单说

您不需要学服务器管理，但应当知道几个问题的答案，因为它们影响上面的一切：

• 在哪里运行，由谁运行？您自己的托管账号、开发方的账号，还是第三方？账号登记在谁的名下？
• 连接加密吗？系统应通过 HTTPS 访问，也就是浏览器里的小锁图标，这样数据在传输中不会被读取。
• 有单独的测试副本吗？改动应先在测试副本上试，而不是在员工使用的正式系统上。
• 谁来更新，怎样通知您？系统所依赖的软件会不断更新，修补已知漏洞要靠有人去做。请问这包含在开发范围内、在维护安排里，还是没人负责。上线后的软件维护解释了其中的区别。
• 谁能访问正式数据？开发人员有时在项目结束后仍保留访问权限。请要求访问仅限于必要范围，不需要时就撤销。

个人数据：谨慎处理，并确认相关规定

大多数业务系统都保存客户和员工的个人数据：姓名、电话号码、地址，有时还有身份证号码或健康资料。作为老板，原则很简单：只收集需要的，只让合适的人看到，只保留需要的时间，并知道怎样更正或删除。

请用实际的说法向开发方提出：

• 我们到底需要这个字段吗？不要仅仅因为表单可以收集，就收集身份证号码。
• 能找到、更正和删除某个人的数据吗？问问具体怎么做，包括备份里的部分。
• 能导出我们持有的数据吗？您可能因某项请求需要它，这也意味着您不会被锁定。
• 测试副本里用了真实客户数据吗？如果是，它需要和正式系统同样的保护，或者改用虚构数据。
• 出了问题怎么办？提前约定通知谁、谁来调查、谁来决定对受影响的人说什么。

马来西亚有数据保护法律，即《2010年个人资料保护法令》（PDPA），近年已有修订，包括针对某些数据泄露的新义务。它是否适用于您的业务、如何适用，取决于您的具体情况。本指南不是法律意见，请向官方来源，即个人资料保护专员的官方资料，或向律师确认适用于您的规定，然后把您的要求写进需求说明。

向开发方提问的清单

请把这些问题带到第一次会面，并要求以书面回答。简短、具体的回答是好迹象；含糊的回答值得追问。

• 每位用户都有自己的账号吗？角色如何设置？
• 审计记录会记录什么？普通用户或管理员能编辑它吗？
• 保存多久？我能搜索和导出吗？
• 备份了什么（数据库、上传文件、设置和代码）？
• 多久一次，副本放在哪里，保留多久？
• 上一次恢复测试是什么时候？能在上线前做一次吗？
• 系统故障后，需要多久才能让我们重新运转？
• 密码如何保存？有什么措施阻止反复猜测？
• 有两步验证吗？适用于谁？丢了手机怎么办？
• 系统托管在哪里，登记在谁的名下，连接是否加密？
• 谁来做更新？费用包含在价格里吗？
• 你们这边有谁能接触正式数据？这项权限何时撤销？
• 系统存储哪些个人数据？我们如何更正或删除？
• 如果合作结束，我的数据和访问权限会怎样？

尽职调查表：好答案与警示信号

比较开发方或审阅方案时，请使用此表。它列出了合理的回答是什么样子、什么情况应让您停下来想一想，以及要求写进书面的内容。

如果开发方声称拥有独立的安全认证或报告，请要求查看，并问清它涵盖什么。这类文件说明的是某个时间点上的特定范围，并不证明不会出问题，小项目也不一定需要。同样，也不要把没有证书当作自动不合格；请根据上面那些具体答案来判断。

书面报价里该写什么

如果某项保护措施没有写下来，您就不能假定它包含在内，缺失的部分日后还可能被当作额外项目。请要求在报价或规格说明里加一节简短的“安全与恢复”，涵盖：

• 角色和登录。个人账号、约定的角色、密码规则以及两步验证的适用范围。
• 审计记录。记录的事件、谁能查看，以及条目保存多久。
• 备份。复制什么、多久一次、副本放在哪里、保留多少份以及由谁负责。
• 恢复测试。上线前一次，加上约定的重复节奏，以及由谁来做。
• 托管与更新。在哪里运行、登记在谁的名下、谁来做更新，以及这笔费用是否包含在内。
• 个人数据。存储的字段、记录怎样更正或删除，以及出了问题要通知谁。
• 访问与退出。开发方对正式数据的访问权限、何时结束，以及您怎样拿到导出文件。相关的归属问题请见谁拥有源代码。
• 验收。在您支付最后一期款项之前必须通过的测试。

把同样的一节交给每家供应商，报价才能公平地逐项比较；如何比较定制软件报价介绍了方法。为第一次会面做准备，请见与软件开发人员交谈前要准备什么。如果您要把现有记录迁入新系统，数据迁移指南讲了切换期间如何保留安全垫。

常见错误

• 以为安全“已经包含”。除非写在报价里，否则可能并不包含。
• 相信从未恢复过的备份。未经测试的备份失败得足够频繁，不容忽视。
• 备份只放在同一台服务器上。服务器一旦出故障，数据和副本会一起没了。
• 为了省事共用登录。这会毁掉审计记录，也让离职人员的权限难以撤销。
• 管理员不开两步验证。他们手里握着一切的钥匙。
• 什么都记，或什么都不记。请挑选真正重要的事件。
• 把个人数据的决定交给开发人员。收集和保留什么，是您的业务决定。
• 忘了项目的收尾。开发方的访问权限和旧的测试副本都需要关闭。

Gotka Technologies 的角色

Gotka 的应用与系统开发服务开发手机应用、网络应用和业务系统，网络应用和仪表板的参考起价为 RM8,000，业务系统和集成为 RM12,000，手机应用为 RM15,000，均在评估您的需求后以书面报价为准。本指南是一般性建议，并不说明 Gotka 所开发系统的任何具体安全功能、备份安排或合规状态，所以，和对待任何供应商一样，请要求把以上各点写进书面报价。Gotka 的主机方案将每日备份和免费 SSL 列为方案功能；备份是否适用于定制系统、如何适用，应在报价中约定，而不是本指南所作的承诺。您可以通过联系页面联络团队。

本指南中的关键术语

• 审计记录（审计日志）：自动记录谁做了什么、针对哪条记录、什么时候做的。
• 备份：单独保存的一份数据副本，以便原件丢失或损坏时可以恢复。
• 恢复测试：把备份还原到单独的测试副本中，证明它可用并记录所需时间。
• 两步验证（2FA）：除密码之外还需要的第二项证明，例如应用验证码。
• 角色：赋予某一类用户的一组权限，例如老板、经理或员工。
• HTTPS：浏览器与系统之间的加密连接，以小锁图标显示。
• 个人数据：能识别某个人的信息，例如姓名、电话号码或身份证号码。
• 保存期限：记录或日志条目在被移除之前保留多久。