ITValue注
姚凯：欧喜投资（中国）有限公司IT总监。在长期的企业信息化过程中，先后成功上线了Oracle OnDemand、Salesforce，Office 365，并实施了基于阿里云和AWS双机热备的系统。
本文是姚凯先生在ITValue【深V课堂】之中国好SaaS培训课第一期上的分享，主要探讨了企业在采用saas应用时会有哪些安全问题的担忧？以及应对这些风险有哪些“秘笈”。
对于saas初创者来说，如何更好地配合企业降低风险，防患于未然，也是成功“撩”到大企业的重要一环。

精彩观点：
1、对于SaaS而言，企业安全防卫的基本原则就是“defence in depth”，通俗来说就是各司其职、层层防御。

2、整个SaaS的设计，会涉及到数据安全、以及用户和权限管理这两个方面的问题。

3、所有面向企业的SaaS服务，都需要和企业内部的域用户的帐号进行一个集成，所以对于SaaS厂商来说，软件在开发过程中必须符合这样一些域集成的标准。

4、企业对于它的所有数据负有最终的安全治理管理的责任，也是整个的监管的直接对象，因此如果绕开企业直接拿SaaS后台的数据来用，可能会让企业处于一个比较危险的处境。

在过去一个月中，我们听到了不少安全事件，涉及到的都是一些比较大的公司，如雅虎确认的帐户泄露，百度云的帐户泄露，还有像上周的DDos攻击导致美国东海岸的整个服务中断等。

谈及SaaS中的安全，有些SaaS供应商可能会讲，SaaS服务在个人应用领域中已经有了很多年的历史，没有人特别地提出安全的问题。再说对于企业来说，采用一些外包的托管服务也算历史悠久，也没特别强调过安全，为什么在说到企业级SaaS应用的时候，很多企业都严阵以待，认为安全是一个关键因素呢？

今天要分享的，就是对于一个企业来说，在SaaS应用中会考虑到哪些安全问题？以及有哪些可能化解的策略。

SaaS应用的安全问题有哪些？

首先来看一下SaaS应用中的安全责任。



比较一下，如果一个企业采用SaaS模式，会和其之前采取的服务托管模式在责任上有什么区别？
首先，对于SaaS服务，整个软件的所有者是SaaS供应商，而对于托管服务来说，软件的所有者是企业，企业采购了软件，把它部署到托管服务器上。
第二，一个SaaS软件可能有很多企业共用，而对于托管服务来说，所托管的软件是由这个企业单独使用的。

第三点是关于软件的变更。对于SaaS来说，SaaS软件的升级、补丁都是由SaaS厂商来提供，而对于企业托管服务来说，整个变更、发起都是由企业发起，由企业决定是否去做相应的变更。

最后，对于软件的维护，维护本身对于SaaS而言是由SaaS厂商来执行。而对于托管服务来说，托管方要根据企业明确的指令和要求来进行。

由此可以发现，对于一个企业，就软件的整体环境管理来说，如果使用SaaS模式，则企业的管理能力是很弱的。企业可能只知道用的是某一个软件，但并不知道这个软件托管在哪一个数据中心，采用的哪个平台。但对于托管服务来说，托管的软件放在怎样的一个环境，什么地方，它的备份等等一系列的问题，企业都了如指掌。也就是说，企业对SaaS软件的控制力是比较弱的，而对于托管服务的控制力相对比较强。

其次就是我们目前有不同的云平台模式，那对于云平台模式而言，企业在整个的安全架构上的责任是如何界定的？



如上图，随着整个云平台模式从Iaas、Paas向SaaS的迁移，企业的整体责任逐步地变成只负责数据安全和安全治理，而对于服务商来说，他们的责任从物理安全、基础架构、延伸到平台，那对于整个应用安全是由双方共享的。但是，不管企业采用什么样的模式，整个的安全治理或者说供应商怎样才能达到企业的安全目标，这一点是企业的责任，对于整个托管在SaaS平台上的数据，也是企业负最终责任。

当然在实际过程中，很多的SaaS平台自己并不负责基础架构，所以事实上，他会把他的平台基础架构又转嫁到第三方的云平台，如PaaS平台或者是Iaas平台上。这样就会存在一个很大的差距。

一方面对于企业来说，他的整个安全责任及对于数据安全的最终责任并没有减弱，但实际上其对使用的SaaS的安全性能和管控力却在下降。那么企业势必会出现一些焦虑，怎么去弥补这种焦虑呢？

目前常用的办法就是SaaS厂商通过一定的安全认证来满足客户对于安全的要求。通过提供一个第三方的认证说明，证明其安全达到了一定的程度，是一个可信任的平台，企业可以放心使用。



上图是目前比较常用的一些安全认证方法，分别是TUV的认证，CSA的认证，还有欧盟的一些认证，在这些认证中，国内比较熟悉的可能就是最右边的ISO27001认证。ISO27001是一个比较通用的认证，但是它有一些缺陷。ISO27001本身并不是针对第三方的独立服务做的一个认证，对于风险管理、云数据安全、云接口安全、互操作性和可移植性等方面并没有一些对应考核的标准，而且，27001更多是一次性的认证。

或者更准确的来说，27001是一个静态的认证，它只是表明企业在提供云服务时，管理流程达到了一些认证的要求，但是在日常操作中是否严格遵循了这样一些原则却并没有一个持续性的检验。而且，对于风险的评估，以及对于一个SaaS来说，它对于特定平台的要求这部分都没有进行适合的考量。可以说，ISO27001只是一个基础。如果没有27001，企业对于整个SaaS平台的安全就没有信心，但是有了27001并不表示企业整个的SaaS安全就是必然可信的，所以这里引入另外一个概念叫做SOC。

在此要强调一下SOC。这是一个叫“SSAE16”具体审核的报告格式要求。SSAE16是美国注册会计师协会制定的叫鉴证业务准则公告第16号，是负责企业的信息安全的审计报告。
SOC具体有三种：SOC1是关于财务报表，SOC2和SOC3内容基本接近，都是关于第三方服务企业的安全策略、安全控制的文档以及日常操作的一个审计报告。

SOC2和SOC3略有不同。相较而言，SOC3更像是一个通用的报告，隐含了涉及到的所有具体的客户信息，它更多的是SaaS厂商安全能力的一个证据，又或者说是作为潜在的市场营销的一个证明。那么SOC2里面会包含着针对特定客户的信息，服务情况、问题、审计结果等，很少会提供给第三方。

需要指出的是，对于SOC来说，目前大部分审计公司至少四大审计公司都是可以提供的。

保证SaaS安全的两大“护法”

随着云的引入，企业安全边界发生了很大变化，风险暴露也更多。在传统企业里，一般以防火墙为边界，防火墙以内是企业来管，防火墙以外是外部的供应商来负责。那么随着SaaS还有移动化的引入，这个边界越来越模糊，怎样才能保证达到一定的安全等级？又能通过哪些途径来实现？

通常来讲，如果做完软件之后发现有安全问题再来打补丁，会有一定的效果，但还远远不够。最好的安全是未雨绸缪。对于SaaS而言，企业安全防卫的基本原则就是“defence in depth”，通俗来说就是各司其职、层层防御。之所以要各司其职，是因为对于客户来说，SaaS供应商有一个数据保管的责任，另一方面对于他所使用的第三方服务来说，他也有一个保证服务品质的问题。

所以整个的SaaS设计，会涉及到数据安全、以及用户和权限管理这两个方面的问题。
对于数据来说，会存在三个状态，第一个是保存的数据，也就是在服务器上保存的、通常是以数据库的形式存储的数据；第二个是传输中的数据；第三个是客户端正在被使用的数据。

对于保存的数据来说，首先要明确的就是要对数据进行分类识别，敏感数据的识别可能是基于一些既定的规章。一些常见的行业规则，比如支付需要遵循的是PCIDSS的一些要求。对于一些医疗数据，国内没有强制性的要求，但是国外，像美国就有HIPAA标准的要求。更多的是基于SaaS服务所涉及到的一些数据，尤其是一些敏感数据，比如HR数据，工资肯定是一个高度机密的信息，再比如客户体检信息，也是机密性的。那对于其它的信息如采购供应链，企业采购价格、供应商等都可能会是一些保密信息。

因此在整个的SaaS架构设计中，最基本的要求就是客户数据的隔离，通常有三种做法。第一种是每个客户会有一个独立的数据库，第二种是每个客户有一个独立的schema，第三种是每个客户有一个独立的ID，数据通过ID来进行区分。这三种架构各有优略，最多的还是通过客户的ID形式来区分，这样能保证整个云架构的弹性。在这种情况下，企业对于数据的一个要求就是加密，这就保证了每位客户的数据是不可见的，尤其是一些机密的数据，更需要加密。

对于整个的这个加密结构来说，一种理想的做法就是在创建一个客户时，赋予他一个唯一的密钥，因此在整个的客户数据保存时，都以这样的一个密钥来进行加密，客户只有通过这样一个密钥，解密出来才能得到真实的数据。必要时，这个密钥甚至对于SaaS的管理员都是不可见的，只能通过一个计算好的加密后的数据，来对数据库中的数据进行维护，而不是直接对原始数据来进行维护。当然加密会不可避免地带来一些效率的损失，因此只有对一些极其关键的数据才使用。

同样的对于整个数据库服务器来说，需要进行固化，包括对于访问权限的维护，删除不必要的帐户，修改缺省帐户的密码，以及禁用一些特权帐户，这包括关闭不必要的服务和端口，以及对于数据库服务器的访问只能通过特定的IP来访问等方法，减少风险敞口。

其次是关于数据的传输，目前SaaS数据的传输大多都是在公网进行，是不可控的，因此通过加密的途径来数据传输是一个基本的条件，通常的业内标准就是通过SSL和TLS来进行访问。

那么在使用SSL或者TLS的时候，大家需要注意关注目前暴露出来的一些漏洞，比如说SSL，会有心脏出血和水牢漏洞，需要进行及时弥补。另外在传输过程中，建议采用MAC消息认证码的算法。对于发送的信息进行认证，在服务器端对于收到的信息通过MAC码进行认证，保证信息是从一个合法的渠道发送过来的，数据没有被篡改过。

第三是在数据使用过程中，第一个需要注意的是权限管理。不同的人需要有不同的访问权限，看到不同的信息，越是SaaS企业服务的客户规模越大，这一点就越重要。第二点是在客户端的数据显示的时候，除非必要，否则不要去显示不必要的一些信息。第三点，也就是说对于一些敏感信息可以通过星号的形式来进行隐藏。

目前很多SaaS软件习惯的注册模式就是通过手机号来登陆，这在企业用户中基本是不可行的。因为对于企业用户来说，一般都有一个统一的管理员来管理企业内部用户，手机号并不是企业内部管理员所熟悉的一个管理方式，因此所有面向企业的SaaS服务，都需要和企业内部的域用户的帐号进行一个集成，目前业内有一些通用的标准。所以对于SaaS厂商来说，软件在开发过程中必须符合这样一些域集成的标准。大家可以参考比方说SAML，OpenID 等等一些规则来定义这一块的功能。

第二点就是随着移动化的普及，很多时候SaaS软件是在手机终端上使用的，因此单纯的只是一个域帐号的集成可能还不够，在此推荐采用两重认证，比方说你可以通过一些挑战性的问题，或者说把SaaS的一个帐号和我的手机IMEI码进行绑定，来保证安全。与此同时需要保证当手机丢失的时候，管理员可以远程对于这个手机上的SaaS信息进行擦除。

最后是关于整个SaaS使用中的一些隐私保护，这个隐私并不是指的个人隐私，更多指的是所服务企业的一些关键信息。

正如第一部分所提到的，企业对于它的所有数据负有最终的安全治理管理的责任，也是整个的监管的直接对象，因此如果绕开企业直接拿SaaS后台的数据来用，可能会让企业处于一个比较危险的处境。

所以很多时候，在对企业提供SaaS服务的时候，除非企业有一个明确的授权，否则这些数据是不可以被SaaS厂商用做其他用途的。一般在SaaS导入前，企业需要和SaaS厂商签署保密协议，所有的数据需要由SaaS厂商进行相应保密，不能用于商业用途。

如果有些SaaS厂商希望通过这样一种SaaS模式提供一个大数据服务，个人建议这些SaaS厂商要对自己的商业模式进行一个仔细考量，这些数据对于企业来说愿不愿意公开？可以公开到什么程度等等，都需要有一个全面的评估。
Q&Ａ
1
Q：企业和saas去交互的时候，数据是如何保证安全的啊。是使用一些加密算法在里面吗？比如RSA.AES这些。
姚凯：这就是前面说的，对于关键数据的分类，识别，加密和对于传输的验证，提供多渠道来保护。这个主要是效率和安全的平衡，以及对于密钥的分配，尽可能保证用户的数据只有用户可以解密并正确访问。
２

Q：区块链会是这个问题在未来的一个解决方案吗？
姚凯：目前应该不是一个合适的方案。SaaS数据量会大很多。但看到有人提出对于用户的私有密钥是否可以采用区块链的方法保存，这个方法值得进一步研究。