开放平台的安全性考量 （下）

开放平台的安全独立性问题

安全独立性是一个非常容易被忽视或者误解的问题。很多应用开发者或者厂商投入了大量的精力和成本在维护“自身”应用安全方面，但是往往忽略了和自己的应用共同构成客户使用环境的系统其他组成部分。举个例子：很多大的网站被发现挂马，追查到最后发现不是自己网站应用程序的问题。而是广告系统中往往在引用第三方站点的资源。而黑客攻击的，却正是这些防范意识和能力相对薄弱的第三方站点。最近两年连续出了数起银行官方网站被挂马的恶性案例，结果无一例外，都是由于网站做资源引用的第三方站点被攻击所造成的。

2010年安全界公认的最烂的两款软件Adobe Reader和Adobe Flash Player，都出自同一家公司Adobe之手。之所以被诟病主要是源于这两款软件的0day漏洞实在是太多了，层出不穷。与此相对的又是它们的客户端占有率相当的高。因此，假如你的网站使用了Flash技术，即使不是由于你的应用的原因，你的客户也有可能成为黑客攻击的牺牲品。

在上述案例中，你很难理直气壮地讲：这个不是我们的问题，我们“自身”的应用还是很安全的。

开放平台也带来了同样的安全独立性问题。你很难忽视第三方应用安全漏洞带来的隐患而把平台安全性单独衡量。

但是，正如我们自己都不可能100%写出没有安全漏洞的程序一样，要求所有的第三方开发者（尤其是一些作坊工厂和个人开发者）开发出非常安全的应用也是不现实的。解决这个问题，需要从以下方向入手：

1. 1. 服务分级开放。在认证和授权中，曾经提到“最小化授权”的概念。在API服务里面，对接入的API进行分级开放是非常有必要的。与传统的OOD和SOA的划分不同，这种接入分级往往不是基于领域模型，而是基于安全域的。例如，某一级别的API在纵向的业务领域中代表了不同的业务，但是由于它们都是只读API，相对来讲被滥用造成的危害属于同一级别，因此在横向的安全域划分中，可以将其划分为同一安全级别进行开放管理。在实际实施中，这种管理由于对API提供者的设计侵入性较强，所以我们在实施中将其实现在平台层面。这事实上也意味着，平台对服务的管理粒度需要细分到单个API层面。

    

   此外容易引起误解的是安全域的划分。上文中提到只读API，事实上这是一种非常粗略的划分方式，也不太科学。目前比较流行和通用的是基于后果的安全域划分。这意味着：某API划分在某个安全域，取决于该API的任何不正当访问所可能造成的可能后果。与传统的风险管理模型（Risk Management Model：风险=后果*可能性）不同，风险不再考虑其可能性因子，因为公开的API和第三方应用的风险发生可能性是不可控的。对开放平台来说，掉在地上的蛋糕，有奶油的那一面一定是先着地的，我们往往需要考虑到最坏结果。

2. 2. 责任域划分。这个事实上属于企业架构的领域，超出了系统架构的范畴。服务分级的一个附加目的是识别可能的风险并适当将风险控制转移。比如对某第三方应用的安全攻击对平台其它用户并无太大影响，而只是影响到该应用开发者自身数据或者其直接用户，那么这种情况下我们可以将该应用的安全责任更多地移交给应用开发者。针对自负责的开发者和应用，平台可能只需要尽到告知、合作的义务。而更多的工作，需要应用开发者自行解决。如果针对某API的攻击会蔓延到平台的其它客户数据或者间接客户，那么平台就应该对其安全负起责任来。
3. 3. 开发者审查。对很多以娱乐、社交类应用的开放API来说，引入开发者审查往往是不太现实的。但是对于电子商务、支付交易等类型的API来说，针对开发者的资质审查和必要的安全告知，是必须做到的。例如eBay在其开放平台的注册申请页面，会逐一询问开发者针对OWASP Top 10的对应解决方案。
4. 4. 应用接入审查。这个没有什么好说的，即使如新浪微博这样的纯粹社交类网站的API，在接入第三方应用的时候也会有对应的接入审查。当然应用接入审查不仅包括安全检查，更多的可能还是业务规则检查。但是有针对性的渗透测试基本上可以解决掉大部分的问题。通常在做接入检查时，对第三方应用的Injection, XSS, CSRF, BAC等常见安全问题的针对性检查，会帮助安全平台解决掉大部分潜在的安全漏洞。同时针对应用审查的结果，可以对开发者的安全开发能力做一个评估。

马其诺防线不是被从正面攻破的。基于自身安全域的API一旦开放，引入第三方应用，将没有严格意义上的“我”安全。而是随之而来的集体安全。这个责任必将落在作为平台和API提供者的厂商肩上。

 

开放平台的抗DOS与DDOS (Anti-DoS/DDoS in Open Platform)

这里只谈软件防护，网络层面该上的IDS, IPS还是得上，能用设备解决的问题都不是大问题。

首先谈谈开放平台自身的Anti-DoS & Anti-DDoS。开放平台也是一个Web应用（利用Protocol Buffers开放的API不属此列，但是原理相通），因此传统应用的Anti-DoS和Anti-DDoS措施也都适用。我的一点小经验是：使用反向代理和验证前置。使用合适的反向代理软件（例如nginx）可以极大地优化应用出口的单机并发能力和网络IO吞吐效率，强烈推荐。此外针对一些无聊的洪水攻击，考虑将验证（Authentication）前移+黑名单可以解决掉很大一部分问题。如果使用nginx的话，nginx filter是个很好的选择。选择在这个地方做验证，需要注意将验证数据缓存起来，尽量不要使验证操作产生额外的API开销。针对普通开放平台的第三方开发者和应用，App Token数据量不会太大，做全表内存缓存应该是可行的。

此外反向代理中的验证操作已经足够解决一些问题了，但是过犹不及。如果把平台的API授权（Authorization）甚至输入校验都做在nginx filter中，反而会造成性能下降，形成新的系统瓶颈。

此外由于API调用来自第三方应用，还需要特别注意来自于第三方应用的DoS和DDoS转嫁。一般情况下针对洪水攻击，第三方应用会比平台本身更早垮掉。但是实际场景中，如果有一个精心策划的针对多个应用的DDoS攻击，依然会对平台的安全造成严重威胁。此外某些应用由于其比较简单，自身资源消耗较少，也有可能会对平台产生影响。应对这种威胁，主要的手段和设计思路以下两点：

1. 1. 设置阈值，在平台端截断异常应用的API调用。针对第三方应用，需要在平台监控层设置其API调用频率的阈值。这种阈值可以是每秒调用数，以及每月总调用数。在没有预先申请和知会的情况下，开放平台应该对超出阈值的API调用予以抛弃并报警处理。阈值的具体设定，需要结合应用的业务发展情况和开发方讨论决定。但是作为平台内部监控，超出正常值一定百分比的调用增长一定要发出内部警报以便于安全团队做出及时处理。
2. 2. 提高API调用的成本。针对第三方开发者，在业务上鼓励他们开发更多应用是应该的。但是应该在API调用成本上予以控制。比如超出调用限额的API Call需要付费。这样会迫使开发者在开发时需要更多考虑API调用的非技术成本，从而不得不采取措施优化程序（例如本地缓存），减小服务开销。

 

后面本来有提纲，拖太久不想写了。就这样吧，提纲还在机器上，哪天想起来再继续。