你卖的SaaS，安全分及格了吗？
一、聊聊安全
在SaaS企业成长的过程中，往往会出现这样的转变：从完全不在意安全，到慢慢开始在意，再到非常在意。
这样的转变，主要源于客户群体的变化。
最初服务的客户体量规模较小，使用的人数较少，会把注意力放在是否满足业务场景，是否能够达成业务目标。关心的是能产生对应的结果。
而随着SaaS企业的扩展，服务客户的规模越来越大，到后期行业内的标杆企业也会购买系统，这类客户把安全作为第一要务，用审计、风控、合规等岗位来确保实现安全目标。他们既关心结果，也关心产生结果的过程。
看起来是大客户对安全的关注，倒逼企业来重视和关注系统安全。所以安全模块的设计，在产品设计中处于长期被忽视的状态，往往认为是为了迎合大客户不得去去投入资源的模块，无法产生价值。
但形成这样的既定认知前，有一个问题值得思考：安全需求，真的只是大客户才关心的吗？
先讲一个小故事。
两位农夫在田间劳作，正当正午，日头晒得人头晕眼花，农夫甲擦了擦汗，直起身来望向城里，彷佛视线落在了紫禁城，他艳羡地说：你说皇帝在宫里，过都是什么样的日子？
农夫乙笑着说：那肯定是神仙一样的日子，他坐在屋里，前面一油锅后面一油锅，想吃油条炸油条，想吃麻花炸麻花。
农夫甲接话：“可能还不止，下地干活肯定也用的是金锄头。”
我们已知的是，皇帝日常并不做饭，并不下地，所以农夫的猜测如同坐井观天，和现实并不搭边。
同理，小客户对于SaaS软件的认识，很可能也大大出乎我们的意料。
客户一般数字化程度不高，使用SaaS的经验很少甚至没有，对技术更是毫不了解，系统对于他们而言，就像坐在宫殿里的贵人，只能用自己的思维去猜测。购买一套系统的作用被极致简化，认为是就是这里点点，那里写写，产生数据，大家看看。
他们并不知道系统可能是不安全的，不知道系统一旦被使用，从人，从权限，从操作流程方面等方面都会带来安全隐患，或者并没有对安全隐患的背后的损失有着正确的认识。
用马斯洛需求层次来解释，每个人的底层需求都是安全，同理，每个企业的底层需求也应该是安全。小客户没有明确表达需求，并不代表他们不重视安全。反而由于他们不懂不会，才是需要SaaS企业更好地支持到他们，为客户防患于未然。
从长远来看，这一项工作也非常有意义。进入数字时代后，我们每天产生的数据呈倍数级增长。所以数据的安全显得更加重要。
同时，在互联网+，产业互联网的共同升级下，安全的定义被极大地延伸，安全不仅要做到保护数据隐私，防范数据流出，也需要呈现准确的数据，因为只有准确的数据，未来才会有连通和衔接的价值。
这就意味做到安全，要符合行业互联网的规范，要减少客户试错成本，要真正以帮客户实现业务目标为核心，去思考系统如何能帮客户做好做对做准确。
二、4类风险与3层限制
1. 4类风险
回到具体的场景，会造成系统不安全的风险一共有四类。
它们分别是
- 环境的风险：系统登录环境，使用环境带来的风险。
- 操作的风险：员工越权操作，或操作无人监管，无据可查带来的风险。
- 合规的风险：产生的业务数据是否符合财务规范，符合财务真实准确的要求。以及数据是否符合相关行业规范，采集的过程和结果是否可靠。
- 经营的风险：上下游合作伙伴管理不善带来的经营风险，导致收入和成本可能出现剧烈波动。
2. 三层限制
相对应的是，我们需要建好三道门槛，用不同的态度去限制用户，降低风险。
第一层限制：能不能。
在这个层次的限制中，我们扮演的是一个执法者。
执法者面临的是环境的风险，操作的风险，在这些环节出现风险的时候，执法者当机立断，采用一刀切的方式，阻拦用户，告诉用户不能进行某些操作，需要按照规定来操作。
而作为执法者，我们凭借什么去阻拦用户呢？
首先依仗的是系统上的，约定俗成的安全性要求。
要保证的是系统里所有用户的账号是安全的，也要确保当前登录的人确实是用户本身。
常见的功能有：
1）登录安全提示：首次登录某个设备需要做二次校验；登录时提示上一次登录地和时间，以便用户及时发觉异常；让用户设置一串文字作为安全码，登录时展示安全码，用户看到安全码和自己设置的一致时，则认为安全。
2）双重校验：例如增加goggle校验，增加短信校验，把新增的校验方式视为临时密码，与用户事先设置的固定性密码组合，共同确保安全。
3）单设备登录校验：不允许用户同时登录两个设备。
4）登录密码安全性设置：可由管理人设置密码的安全性等级，例如是否考虑大小写字母，数字，特殊字符的混用，是否限制长度，以及是否设置过期时间。
除了依赖安全规范，也要依赖法律上、道德上的规范。
这些规范用于限制内部员工的行为，让员工在规范内允许的范围内操作，尽可能减少员工犯错可能。曾有一段时间，银行、支付工具等公司，都屡屡被爆出员工的数据倒卖的情况，但近些年这类新闻少了很多，猜测可能和系统逐步提升安全等级有关。
为了管控员工行为，一共有3类的方向可以去优化。
1）细化数据权限
对于系统而言，有两类数据是最重要的：公司业务数据，合作方隐私数据。
- 业务数据：包含成本，售价，利润，单数等等信息，应该严格限制，特别是上市公司的经营数据，更应该把可查范围缩小缩小再缩小。
- 合作方隐私数据：包括证件号码，联系方式，犯罪信息等等，这类有倒卖价值、以及流出后会影响他人的信息，都应设置严格的权限
解决方案
① 敏感信息，界面查看时脱敏处理
例如电话号码，证件信息，可以用只保留首尾数字的方法展示，展示为138****8888。又例如个人姓名，默认展示时仅展示姓氏李**，但点击可以查看到完整的信息。
这两种方式可以适应到不同的情况，前者是无论如何都不展示全部信息，后者是可以展示完整，但多了一层信息保护，避免一目了然看到所有信息。
② 设置敏感信息的统一查看权限
较为敏感的信息，且只有某些角色才需要查看到的，可以设置统一的查看权限，拥有权限的人才可以看到相关信息。
③ 非常敏感的信息设置独立权限。
例如查看犯罪信息，需要有单独的查看和筛选权限。
2）管控关键行为
在使用中，有两类行为是非常值得注意的。
一类是导致数据流出系统的行为，也就是下载。
首先需要重点梳理下载行为涉及的字段。
有些字段在系统中展示和查看问题不大，外流则会造成很大的问题，例如犯罪信息的外流，可想而知会引起多大程度的舆论压力。对于这类情况，需要让用户可以设置，无论权限如何都不能下载的字段。
其次需要限制导出的数据量。
绝大多数场景中，导出是用于做数据分析，按月导出可以满足绝大多数需求。如果一次性导出几年的数据，是有风险的。对于这类情况，需要让用户设置导出的条件限制。
最后导出某些数据，需要受到监管。
或者有统一的下载管理评查，可查看导出的数据内容和信息，或者可以把导出行为设计成需要审批。
另一类值得注意的是修改业务上的关键信息。
例如把已经过期的身份证修改为正常，导致图片和文字信息不匹配，把犯罪信息从无改到有，都是严格的红线行为。
如果系统本身有业务属性，则可以预见并严格限制红线行为。
如果系统不为业务服务，无法知道用户的修改会造成什么问题，至少提供不允许修改的配置，并在培训时着重强调修改信息的权限，请用户思考背后对应的风险。
3）服务合理用户
正常来说，有系统登录权限的人，都应该是在职且有权限的员工。
但事实上总有各种情况，导致不在职的人，无权限的人还可以登录系统，造成系统信息的不安全。
可以从功能设计上防范这些情况：
- 控制超级管理员人数：超级管理员的赋予和取消都应有通知和留档，甚至可以设置为需要审批。
- 人员退出机制：尽量把系统人员状态和其他系统打通，例如OA和办公协同系统，这样员工离职后，可以自动变更账号状态。
- 人员回收机制：如果某些用户长期未登录，可以把状态自动变更为冻结。
- 临时登录机制：如果某些用户需要临时登录，可以开始有登录有效期的临时账号，满足短期内使用的需求。
第二层限制：对不对。
第一层限制里，我们关注的是用户能不能这么做，而在第二层限制，我们扮演的是一个老师，来告诉客户这么做是否对，在合规层面，操作是否符合规范。
企业留存在系统中的业务数据，最后都会变成财务数据，甚至有些客户希望把系统打通，直接按系统金额去进行支付，这就要求系统的数据最后应该是符合财务的规范的。
就实践而言，系统应该重点关注以下几个场景，数据是否做到了真实、准确、及时。
1）信息采集
主要是基础数据的准确。例如订单系统需要维护商品和客户数据，物流系统需要维护司机和车辆数据。
2）信息修改
基础信息的修改往往会导致业务数据，财务数据变化。例如商品价格没有及时更新，导致订单价格错误，而此时已经走完打款开票流程，就显而易见地已经造成了损失。
3）对账过程
一般需要内部和外部的审核，在这些场景中，是否可以提示风险点和审核要点，快速帮助定位问题，避免自动化工作造成的人工错误。
这些场景，是在对行业、业务有深度认知上才能认识到重要性，且能够给到解决方案的。
通过给到专业的解决方案，达成数据真实、准确、及时的目标，达成最终的财务合规目标，这就是产品隐形实力的体现，是硬功夫的细节，是不容易抄走的理念。
第三层限制：好不好。
在这个层次里，系统扮演的是专家，可以给出关于企业经营的意见。
企业能够顺利运转，很大程度上都依赖于合作伙伴，那么合作方的带来风险也可以被关注起来。
例如一个固定项目，长期都是一个供应商来承接，那么代表着项目可能存在一家独大的风险，项目风险无法分摊，对于成本也很难有议价权。
那么系统是不是可以给出项目经营的风险预警呢？
除此以外，对于合作方的资质要求，保证金管理，系统是否对应的能力和预警，也是可以考虑的。
对于上游客户，如果连续出现某类客户的订单下降，是否可以给到预警，提示持续流失风险。
以上只是一些例子，可以挖掘的场景应该还有很多。毕竟企业经营，是上游下游都好，才是真的好。
系统能做到这一点，也是真的能够把SaaS的双重性都体现出来了，既是经营思路，又是经营工具。
除了三个层次的限制，我们也要有一些兜底的能力。
目标是尽量增加违规操作的成本，或者在事后能尽快定位。例如增加可查验的、完整的系统日志，以及设置系统全局的水印。
三、总结
回顾本文，我们聊了SaaS企业的安全意识，并把安全指代的场景扩大化。
安全不仅仅是信息储存安全，也代表着信息生成的过程合规，上下游的运营安全。
与之对应，我们聊了4种风险，并一一对应了三类解决办法。
- 环境的风险：系统登录环境，使用环境带来的风险。用“不能”的态度去拦截。
- 操作的风险：员工越权操作，或操作无人监管，无据可查带来的风险。用“不能”的态度去拦截。
- 合规的风险：产生的业务数据是否符合财务规范，符合财务真实准确的要求。以及数据是否符合相关行业规范，采集的过程和结果是否可靠。用“不对”的态度去规劝。
- 经营的风险：上下游合作伙伴管理不善带来的经营风险，导致收入和成本可能出现剧烈波动。用“不好”的态度去提示。
SaaS系统既然是理念和工具的合并，也同时也代表着执法者，老师，专家三类角色，三者背后的服务理念各不相同，从低到高，服务于用户的不同需求。
经常听到创业者说SaaS功能太容易被抄袭了。那么我想说：未来SaaS的竞争核心，或许不是功能的竞争，而是理念的竞争。
作者：假装是运营，微信公众号：SaaS学姐
本文作者 @假装是运营
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
