你卖的SaaS,安全分及格了吗?

一、聊聊安全

在SaaS企业成长的过程中,往往会出现这样的转变:从完全不在意安全,到慢慢开始在意,再到非常在意。

这样的转变,主要源于客户群体的变化。

最初服务的客户体量规模较小,使用的人数较少,会把注意力放在是否满足业务场景,是否能够达成业务目标。关心的是能产生对应的结果。

而随着SaaS企业的扩展,服务客户的规模越来越大,到后期行业内的标杆企业也会购买系统,这类客户把安全作为第一要务,用审计、风控、合规等岗位来确保实现安全目标。他们既关心结果,也关心产生结果的过程。

看起来是大客户对安全的关注,倒逼企业来重视和关注系统安全。所以安全模块的设计,在产品设计中处于长期被忽视的状态,往往认为是为了迎合大客户不得去去投入资源的模块,无法产生价值。

但形成这样的既定认知前,有一个问题值得思考:安全需求,真的只是大客户才关心的吗?

先讲一个小故事。

两位农夫在田间劳作,正当正午,日头晒得人头晕眼花,农夫甲擦了擦汗,直起身来望向城里,彷佛视线落在了紫禁城,他艳羡地说:你说皇帝在宫里,过都是什么样的日子?

农夫乙笑着说:那肯定是神仙一样的日子,他坐在屋里,前面一油锅后面一油锅,想吃油条炸油条,想吃麻花炸麻花。

农夫甲接话:“可能还不止,下地干活肯定也用的是金锄头。”

我们已知的是,皇帝日常并不做饭,并不下地,所以农夫的猜测如同坐井观天,和现实并不搭边。

同理,小客户对于SaaS软件的认识,很可能也大大出乎我们的意料。

客户一般数字化程度不高,使用SaaS的经验很少甚至没有,对技术更是毫不了解,系统对于他们而言,就像坐在宫殿里的贵人,只能用自己的思维去猜测。购买一套系统的作用被极致简化,认为是就是这里点点,那里写写,产生数据,大家看看。

他们并不知道系统可能是不安全的,不知道系统一旦被使用,从人,从权限,从操作流程方面等方面都会带来安全隐患,或者并没有对安全隐患的背后的损失有着正确的认识。

用马斯洛需求层次来解释,每个人的底层需求都是安全,同理,每个企业的底层需求也应该是安全。小客户没有明确表达需求,并不代表他们不重视安全。反而由于他们不懂不会,才是需要SaaS企业更好地支持到他们,为客户防患于未然。

从长远来看,这一项工作也非常有意义。进入数字时代后,我们每天产生的数据呈倍数级增长。所以数据的安全显得更加重要。

你卖的SaaS,安全分及格了吗?

同时,在互联网+,产业互联网的共同升级下,安全的定义被极大地延伸,安全不仅要做到保护数据隐私,防范数据流出,也需要呈现准确的数据,因为只有准确的数据,未来才会有连通和衔接的价值。

这就意味做到安全,要符合行业互联网的规范,要减少客户试错成本,要真正以帮客户实现业务目标为核心,去思考系统如何能帮客户做好做对做准确。

二、4类风险与3层限制

1. 4类风险

回到具体的场景,会造成系统不安全的风险一共有四类

它们分别是

  1. 环境的风险:系统登录环境,使用环境带来的风险。
  2. 操作的风险:员工越权操作,或操作无人监管,无据可查带来的风险。
  3. 合规的风险:产生的业务数据是否符合财务规范,符合财务真实准确的要求。以及数据是否符合相关行业规范,采集的过程和结果是否可靠。
  4. 经营的风险:上下游合作伙伴管理不善带来的经营风险,导致收入和成本可能出现剧烈波动。

2. 三层限制

相对应的是,我们需要建好三道门槛,用不同的态度去限制用户,降低风险。

第一层限制:能不能。

在这个层次的限制中,我们扮演的是一个执法者。

执法者面临的是环境的风险,操作的风险,在这些环节出现风险的时候,执法者当机立断,采用一刀切的方式,阻拦用户,告诉用户不能进行某些操作,需要按照规定来操作。

而作为执法者,我们凭借什么去阻拦用户呢?

首先依仗的是系统上的,约定俗成的安全性要求。

要保证的是系统里所有用户的账号是安全的,也要确保当前登录的人确实是用户本身。

常见的功能有:

1)登录安全提示:首次登录某个设备需要做二次校验;登录时提示上一次登录地和时间,以便用户及时发觉异常;让用户设置一串文字作为安全码,登录时展示安全码,用户看到安全码和自己设置的一致时,则认为安全。

2)双重校验:例如增加goggle校验,增加短信校验,把新增的校验方式视为临时密码,与用户事先设置的固定性密码组合,共同确保安全。

3)单设备登录校验:不允许用户同时登录两个设备。

4)登录密码安全性设置:可由管理人设置密码的安全性等级,例如是否考虑大小写字母,数字,特殊字符的混用,是否限制长度,以及是否设置过期时间。

除了依赖安全规范,也要依赖法律上、道德上的规范。

这些规范用于限制内部员工的行为,让员工在规范内允许的范围内操作,尽可能减少员工犯错可能。曾有一段时间,银行、支付工具等公司,都屡屡被爆出员工的数据倒卖的情况,但近些年这类新闻少了很多,猜测可能和系统逐步提升安全等级有关。

为了管控员工行为,一共有3类的方向可以去优化。

1)细化数据权限

对于系统而言,有两类数据是最重要的:公司业务数据,合作方隐私数据。

  • 业务数据:包含成本,售价,利润,单数等等信息,应该严格限制,特别是上市公司的经营数据,更应该把可查范围缩小缩小再缩小。
  • 合作方隐私数据:包括证件号码,联系方式,犯罪信息等等,这类有倒卖价值、以及流出后会影响他人的信息,都应设置严格的权限

解决方案

① 敏感信息,界面查看时脱敏处理

例如电话号码,证件信息,可以用只保留首尾数字的方法展示,展示为138****8888。又例如个人姓名,默认展示时仅展示姓氏李**,但点击可以查看到完整的信息。

这两种方式可以适应到不同的情况,前者是无论如何都不展示全部信息,后者是可以展示完整,但多了一层信息保护,避免一目了然看到所有信息。

② 设置敏感信息的统一查看权限

较为敏感的信息,且只有某些角色才需要查看到的,可以设置统一的查看权限,拥有权限的人才可以看到相关信息。

③ 非常敏感的信息设置独立权限。

例如查看犯罪信息,需要有单独的查看和筛选权限。

2)管控关键行为

在使用中,有两类行为是非常值得注意的。

一类是导致数据流出系统的行为,也就是下载。

首先需要重点梳理下载行为涉及的字段。

有些字段在系统中展示和查看问题不大,外流则会造成很大的问题,例如犯罪信息的外流,可想而知会引起多大程度的舆论压力。对于这类情况,需要让用户可以设置,无论权限如何都不能下载的字段。

其次需要限制导出的数据量。

绝大多数场景中,导出是用于做数据分析,按月导出可以满足绝大多数需求。如果一次性导出几年的数据,是有风险的。对于这类情况,需要让用户设置导出的条件限制。

最后导出某些数据,需要受到监管。

或者有统一的下载管理评查,可查看导出的数据内容和信息,或者可以把导出行为设计成需要审批。

另一类值得注意的是修改业务上的关键信息。

例如把已经过期的身份证修改为正常,导致图片和文字信息不匹配,把犯罪信息从无改到有,都是严格的红线行为。

如果系统本身有业务属性,则可以预见并严格限制红线行为。

如果系统不为业务服务,无法知道用户的修改会造成什么问题,至少提供不允许修改的配置,并在培训时着重强调修改信息的权限,请用户思考背后对应的风险。

3)服务合理用户

正常来说,有系统登录权限的人,都应该是在职且有权限的员工。

但事实上总有各种情况,导致不在职的人,无权限的人还可以登录系统,造成系统信息的不安全。

可以从功能设计上防范这些情况:

  • 控制超级管理员人数:超级管理员的赋予和取消都应有通知和留档,甚至可以设置为需要审批。
  • 人员退出机制:尽量把系统人员状态和其他系统打通,例如OA和办公协同系统,这样员工离职后,可以自动变更账号状态。
  • 人员回收机制:如果某些用户长期未登录,可以把状态自动变更为冻结。
  • 临时登录机制:如果某些用户需要临时登录,可以开始有登录有效期的临时账号,满足短期内使用的需求。

第二层限制:对不对。

第一层限制里,我们关注的是用户能不能这么做,而在第二层限制,我们扮演的是一个老师,来告诉客户这么做是否对,在合规层面,操作是否符合规范。

企业留存在系统中的业务数据,最后都会变成财务数据,甚至有些客户希望把系统打通,直接按系统金额去进行支付,这就要求系统的数据最后应该是符合财务的规范的。

就实践而言,系统应该重点关注以下几个场景,数据是否做到了真实、准确、及时。

1)信息采集

主要是基础数据的准确。例如订单系统需要维护商品和客户数据,物流系统需要维护司机和车辆数据。

2)信息修改

基础信息的修改往往会导致业务数据,财务数据变化。例如商品价格没有及时更新,导致订单价格错误,而此时已经走完打款开票流程,就显而易见地已经造成了损失。

3)对账过程

一般需要内部和外部的审核,在这些场景中,是否可以提示风险点和审核要点,快速帮助定位问题,避免自动化工作造成的人工错误。

这些场景,是在对行业、业务有深度认知上才能认识到重要性,且能够给到解决方案的。

通过给到专业的解决方案,达成数据真实、准确、及时的目标,达成最终的财务合规目标,这就是产品隐形实力的体现,是硬功夫的细节,是不容易抄走的理念。

第三层限制:好不好。

在这个层次里,系统扮演的是专家,可以给出关于企业经营的意见。

企业能够顺利运转,很大程度上都依赖于合作伙伴,那么合作方的带来风险也可以被关注起来。

例如一个固定项目,长期都是一个供应商来承接,那么代表着项目可能存在一家独大的风险,项目风险无法分摊,对于成本也很难有议价权。

那么系统是不是可以给出项目经营的风险预警呢?

除此以外,对于合作方的资质要求,保证金管理,系统是否对应的能力和预警,也是可以考虑的。

对于上游客户,如果连续出现某类客户的订单下降,是否可以给到预警,提示持续流失风险。

以上只是一些例子,可以挖掘的场景应该还有很多。毕竟企业经营,是上游下游都好,才是真的好。

系统能做到这一点,也是真的能够把SaaS的双重性都体现出来了,既是经营思路,又是经营工具。

除了三个层次的限制,我们也要有一些兜底的能力。

目标是尽量增加违规操作的成本,或者在事后能尽快定位。例如增加可查验的、完整的系统日志,以及设置系统全局的水印。

三、总结

回顾本文,我们聊了SaaS企业的安全意识,并把安全指代的场景扩大化。

安全不仅仅是信息储存安全,也代表着信息生成的过程合规,上下游的运营安全。

与之对应,我们聊了4种风险,并一一对应了三类解决办法。

  1. 环境的风险:系统登录环境,使用环境带来的风险。用“不能”的态度去拦截。
  2. 操作的风险:员工越权操作,或操作无人监管,无据可查带来的风险。用“不能”的态度去拦截。
  3. 合规的风险:产生的业务数据是否符合财务规范,符合财务真实准确的要求。以及数据是否符合相关行业规范,采集的过程和结果是否可靠。用“不对”的态度去规劝。
  4. 经营的风险:上下游合作伙伴管理不善带来的经营风险,导致收入和成本可能出现剧烈波动。用“不好”的态度去提示。

SaaS系统既然是理念和工具的合并,也同时也代表着执法者,老师,专家三类角色,三者背后的服务理念各不相同,从低到高,服务于用户的不同需求。

经常听到创业者说SaaS功能太容易被抄袭了。那么我想说:未来SaaS的竞争核心,或许不是功能的竞争,而是理念的竞争。

 

作者:假装是运营,微信公众号:SaaS学姐

本文作者 @假装是运营

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部