你卖的SaaS,安全分及格了吗?
2022/5/8 18:00:00 人人都是产品经理

     关注并将「人人都是产品经理」设为星标

     每天早 07 : 45 按时送达

    

     随着社会对数据安全、信息安全等方面的注重,企业也需要提升安全意识,比如SaaS企业,在为客户提供服务时,就需要考虑如何降低风险,提升安全保障。本篇文章里,作者就SaaS产品的风险控制等问题做了解读,一起来看一下。

     作者:假装是运营

     微信公众号:SaaS学姐

     编辑:尹茜茜,人人都是产品经理实习生

     题图来自Unsplash,基于CC0协议

     全文共 4777 字,阅读需要 10 分钟

     ——————/ BEGIN /——————

    

    


     聊聊安全

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

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

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

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

     他们既关心结果,也关心产生结果的过程。

     看起来是大客户对安全的关注,倒逼企业来重视和关注系统安全。

     所以安全模块的设计,在产品设计中处于长期被忽视的状态,往往认为是为了迎合大客户不得去去投入资源的模块,无法产生价值。

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

     先讲一个小故事:

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

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

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

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

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

     客户一般数字化程度不高,使用SaaS的经验很少甚至没有,对技术更是毫不了解,系统对于他们而言,就像坐在宫殿里的贵人,只能用自己的思维去猜测。

     购买一套系统的作用被极致简化,认为是就是这里点点,那里写写,产生数据,大家看看。

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

     用马斯洛需求层次来解释,每个人的底层需求都是安全,同理,每个企业的底层需求也应该是安全。

     小客户没有明确表达需求,并不代表他们不重视安全;反而由于他们不懂不会,才是需要SaaS企业更好地支持到他们,为客户防患于未然。

     从长远来看,这一项工作也非常有意义。

     进入数字时代后,我们每天产生的数据呈倍数级增长,所以数据的安全显得更加重要。

    

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

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

    

    


     4类风险与3层限制

     1. 4类风险

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

     它们分别是:

     环境的风险:系统登录环境,使用环境带来的风险。

     操作的风险:员工越权操作,或操作无人监管,无据可查带来的风险。

     合规的风险:产生的业务数据是否符合财务规范,符合财务真实准确的要求。以及数据是否符合相关行业规范,采集的过程和结果是否可靠。

     经营的风险:上下游合作伙伴管理不善带来的经营风险,导致收入和成本可能出现剧烈波动。

     2. 3层限制

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

     第一层限制:能不能。

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

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

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

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

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

     常见的功能有:

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

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

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

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

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

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

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

     1)细化数据权限

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

     业务数据:包含成本,售价,利润,单数等等信息,应该严格限制,特别是上市公司的经营数据,更应该把可查范围缩小缩小再缩小。

     合作方隐私数据:包括证件号码,联系方式,犯罪信息等等,这类有倒卖价值、以及流出后会影响他人的信息,都应设置严格的权限

     解决方案:

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

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

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

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

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

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

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

     2)管控关键行为

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

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

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

     有些字段在系统中展示和查看问题不大,外流则会造成很大的问题,例如犯罪信息的外流,可想而知会引起多大程度的舆论压力。

     对于这类情况,需要让用户可以设置,无论权限如何都不能下载的字段。

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

     绝大多数场景中,导出是用于做数据分析,按月导出可以满足绝大多数需求。如果一次性导出几年的数据,是有风险的。

     对于这类情况,需要让用户设置导出的条件限制。

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

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

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

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

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

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

     3)服务合理用户

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

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

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

     控制超级管理员人数:超级管理员的赋予和取消都应有通知和留档,甚至可以设置为需要审批。

     人员退出机制:尽量把系统人员状态和其他系统打通,例如OA和办公协同系统,这样员工离职后,可以自动变更账号状态。

     人员回收机制:如果某些用户长期未登录,可以把状态自动变更为冻结。

     临时登录机制:如果某些用户需要临时登录,可以开始有登录有效期的临时账号,满足短期内使用的需求。

     第二层限制:对不对。

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

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

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

     1)信息采集

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

     2)信息修改

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

     3)对账过程

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

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

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

     第三层限制:好不好。

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

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

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

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

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

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

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

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

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

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

    

    


     总结

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

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

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

     环境的风险:系统登录环境,使用环境带来的风险。用“不能”的态度去拦截。

     操作的风险:员工越权操作,或操作无人监管,无据可查带来的风险。用“不能”的态度去拦截。

     合规的风险:产生的业务数据是否符合财务规范,符合财务真实准确的要求。以及数据是否符合相关行业规范,采集的过程和结果是否可靠。用“不对”的态度去规劝。

     经营的风险:上下游合作伙伴管理不善带来的经营风险,导致收入和成本可能出现剧烈波动。用“不好”的态度去提示。

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

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

     —————— / END / ——————

    

    


     产品经理培训产品运营培训企业内训服务

     请在公众号后台回复「培训」了解更多

     ▼ 喜欢请分享&收藏,满意点个赞,最后点「在看」 ▼

    源网页  http://weixin.100md.com
返回 人人都是产品经理 返回首页 返回百拇医药