租赁软件安全:把业务数据交给平台之前该问的问题

一家租赁企业的软件,哪怕只用了短短几个月,也已经积累了一批真正敏感的信息。客户的姓名、地址和电话号码。支付卡信息和押金金额。已签署的租赁合同和送货单。而且越来越多的是,客户在带走价值数千美元的设备之前,为证明身份而上传的身份证件。再加上运营层面的细节——谁签出了哪件物品、哪位司机在什么时间拜访了哪个地址、哪位员工处理了哪笔退款——一个租赁平台最终看起来就不再只是一个排期工具,而更像是一份把企业客户、资金和员工自身行为全都汇总在一处的完整记录。

这一切都不算反常,也无法避免。这只是报价变成合同、合同变成配送、配送变成付款之后自然发生的事。真正可以避免的,是这些数据在采购过程中通常受到的审视少得可怜。大多数软件评估会花上几周时间比较功能:能不能处理带序列号的资产,能不能对接会计软件,司机端应用在工地没有信号时能不能用。安全通常只占一行,如果有这一行的话——「安全吗?」——得到的回答往往是一句安抚,而不是一个真正的问题,而且被照单全收,因为没人愿意成为那个因为一件感觉很抽象的事情而拖住决策的人。

这是本末倒置的做法,因为安全漏洞不会像一个笨拙的预订界面那样自己跳出来提醒你。没有人会注意到问题,直到一名离职员工的登录账号在他离开数周后仍然有效,或者一次与客服的对话透露出,任何员工都能看到任何客户的卡片信息,而不论其岗位实际是否需要这些信息。解决办法不是在签合同之前把自己变成安全专家,而是提出一份简短、具体、可以得到明确答案的问题清单——对自家产品有信心的供应商,理应能够清楚作答的那种问题。本文将讨论其中四个:登录、权限、审计日志和API访问——并且始终以Renttix自己的答案作为示例,说明每个问题的一个好答案应该是什么样子。

单靠一个密码是一道脆弱的关卡。人们会在不同服务之间重复使用同一个密码,把密码写在什么地方,或者干脆选一个很容易被猜到的密码——这其实不太算是粗心,而是当每个人都被期望为一周只用几次的系统记住几十个独一无二的密码时,自然会出现的结果。这是安全研究中已经被充分论证的领域:现代身份验证方式能够以可衡量的幅度降低与密码相关的入侵事件发生率,因为它们消除了密码所代表的那个单点故障。

因此,值得向任何供应商提出三个具体问题。是否提供双重验证(2FA),让被盗或被猜中的密码本身不足以登录?团队能否通过公司自己的单点登录(SSO)登录,让访问租赁系统的权限随每个人的中央公司账号一起增加或撤销,而不是依赖一个需要有人记得单独维护的独立登录?是否提供密钥(passkey)——一种较新的身份验证方式,用绑定在设备上的加密密钥取代需要手动输入的密码,让最常见的钓鱼手法(一个要求输入密码的假登录页面)基本失效,因为根本已经没有密码可以输入了。

这三者分别针对不同的失败方式。2FA能在一个泄露的密码演变成入侵之前将其拦截。SSO意味着当有人离开公司时,撤销其中央身份账号会一次性移除其对所有关联系统(包括租赁平台)的访问权限,而不必依赖有人记得单独关闭一个很容易被遗忘的租赁软件登录账号。密钥则干脆彻底消除了那个薄弱环节——一个可能被钓鱼、被猜中或被重复使用的密码。

Renttix对这个问题的回答很直接:SSO、密钥和2FA适用于每一次登录,而不是被保留给企业版套餐、或者藏在一张支持工单背后的附加选项。无论你正在评估哪家供应商,都值得准确地问出这句话:这三者中你们支持哪几项,而且这是我们作为客户今天就能用上的功能,而不是路线图上的某一项。

这是大多数买家从来想不到要问的问题,因为表面上看,市面上几乎每一套租赁系统的权限似乎都在正常运作。司机的移动应用不会显示客户价格。办公室的初级用户看不到发起退款的菜单选项。这看起来像是访问控制在发挥作用——但它只能证明某些选项在某些界面上被隐藏了。它并没有说明,如果有人通过另一条路径到达同一个操作,会发生什么。

区别在于,授权是在界面层面被强制执行,还是在服务器层面被强制执行。仅在界面层面强制执行,意味着限制完全取决于某个界面选择显示哪些按钮和菜单——对于按预期方式点击应用的诚实用户来说,这没有问题,但对于一个具备技术能力的人来说毫无意义:他可以打开浏览器的开发者工具,拦截应用发出的底层请求,然后直接发送同一个请求,绕过原本应该拦住他的那个界面。如果服务器本身从来不检查发出该请求的人是否真的有权这么做,那么这项限制其实从未真正存在过——它只是被藏在了看不见的地方。

服务器端强制执行的权限工作方式则不同:无论请求经由什么路径到达,在任何事情发生之前,都会根据该用户当前的角色和权限进行核验,而不论界面原本会显示什么。这是一种明显更强的保证,因为它不依赖于「相信员工中没有人、也没有任何取得设备、账号或旧集成令牌访问权限的人会去寻找绕开界面的捷径」这种信任。无论请求经由哪条路径到达,这项保证都能站得住脚。

一个示例说明

设想一位仓库经理因为与公司关系恶化而离职。理论上,他的账号会在当天就被停用。如果权限检查只存在于界面层面,一个尚未过期的旧会话、一部仍在私人手机上保持登录状态的移动应用,或是以他账号名义签发的一个集成令牌,仍然可能放行请求,因为服务器端根本没有任何东西真正在重新核验请求发起人的身份。如果权限是在服务器端强制执行的,那么在那个账号被停用或角色发生变化的瞬间,以他名义发出的每一个请求——无论来自哪台设备、经由哪条路径——都会根据当前的权限集合被核验并拒绝。这个差别不是表面文章,而是「真的撤销了访问权限」与「只是看起来撤销了」之间的差别。

值得向供应商提出的问题很直接:如果我直接发送这个请求,完全绕过你们的界面,你们的服务器是否仍然会检查我是否有权这样做?Renttix的答案是,权限在服务器端按角色对每一个请求强制执行——而不是仅仅由某个特定界面选择显示什么内容来控制。

问问任何一家供应商,是否存在一份记录谁在何时做了什么的日志——价格被修改、发票被作废、押金被提前放行、客户档案被编辑。没有这样的日志,关于某个订单到底发生了什么的争议,就会变成关于一通电话内容的各执一词的回忆。有了它,同样的争议只需两分钟查询,凭一个时间戳和一个名字就能一锤定音。

但审计日志会引出第二个同样重要、却常常被忽视得多的问题:到底谁能真正读取它,它又会向他们展示什么?如果一份日志让每一个拥有访问权限的员工都能看到任何条目所关联的完整支付卡号、身份证件或个人数据,那么它就不只是在记录问责——它悄悄变成了另一个敏感数据泄露给本不需要看到它的人的地方。一名试图弄清楚某个订单状态为何变化的客服人员,并不需要看到客户的完整卡号就能回答这个问题;他需要看到的是状态发生了变化、何时发生、由谁发生。

因此,关于审计的问题更尖锐的版本是:这份日志本身是否也遵循「按需知悉」的原则,根据查看者的身份对敏感字段进行遮蔽,而不是向任何有理由打开它的人展示一切?Renttix的答案是一份会遮蔽敏感信息的审计日志——敏感字段会根据查看者身份保持隐藏,即便是在这份本应用来记录发生了什么的日志内部也是如此。这就是「一份能建立问责的日志」和「一份悄悄制造出同一批数据第二次暴露的日志」之间的区别。

大多数租赁企业最终都会把自己的租赁软件与其他系统连接起来——会计平台、营销工具、自定义报表看板,或者自己用于在线预订的网站。这些连接通常都依靠一把API密钥运行:另一个系统用这把密钥,以企业的名义与租赁平台通信。

这里值得问的问题是,这把密钥是否被限定了范围并且可以撤销,还是要么全有要么全无。一把限定范围的密钥可以被精确限制在某个特定集成实际需要的权限内——比如只给某个报表工具提供对预订数据的只读访问,而不具备发起退款或修改价格的能力。一把可撤销的密钥可以在不再需要时、或者一旦怀疑其已经泄露时被单独关闭,而不会影响任何依赖自己独立密钥的其他集成。

另一种做法是使用一把共享密钥,赋予对账号所能做的一切事情的完整访问权限,并在企业运行的每一项集成中通用。这就是一个单点故障:如果它被误传进了公开代码仓库,被粘贴进了错误的聊天频道,或者留在了后来自身遭遇数据泄露的第三方工具里,任何拿到它的人都可以做账号能做的任何事情。而为了阻止泄露而关闭它,就意味着要轮换所有其他集成也依赖的那唯一一把密钥,为了解决一个只由某一项集成造成的问题,却让所有集成同时中断。

Renttix的开发者API颁发限定范围、可单独撤销的API密钥,因此一把泄露或被淘汰的凭证不会把与之相连的所有系统一并拖垮。也值得就客户端的信息暴露提出一个相关问题:客户在线登录自己账号时能看到什么?Renttix的客户门户被设计成让客户只能看到自己的数据——自己的订单、发票和已保存的付款方式——而看不到其他任何内容。这是个不起眼的细节,但同样的原则被应用在了另一群受众身上:访问权限被限定在某个特定的人实际需要看到的范围内。

以上四个问题都不需要技术专长才能提出——需要的只是坚持要求一个具体机制,而不是接受一句笼统的安抚。「你们重视安全吗」这个问题,在每一通销售电话里都会从每一家供应商那里得到同样自信的「是」。而「你们的服务器是否在每一个请求上都检查权限,不论界面显示了什么」这个问题,得到的会是截然不同类型的回答;而一家供应商能否准确描述其运作方式,与另一家只是绕着问题打转,这两者之间的差别本身就很能说明问题。

作为一份可以带进供应商对话的简短清单:平台是否支持2FA、SSO和密钥登录?权限是否在服务器端对每一个请求进行检查,还是仅由界面显示的内容来控制?是否存在审计日志,它是否根据查看者身份遮蔽敏感字段?API密钥是否被限定在每项集成实际需要的范围内,并且可以单独撤销,而不是在所有连接之间共用?

这四个问题不会告诉你一个平台是如何构建的一切,但它们会告诉你很多关于一家供应商对即将托付给它的数据究竟有多认真思考过——而且值得在数据转移之前提出,而不是等出了问题之后。如果你想看看Renttix如何在一个真实系统上、而不是在一张幻灯片上回答这些问题,预约演示,自己去问。