邱实牟承晋：Akamai断服断网深层原因的再警示

点击：作者：邱实牟承晋来源：昆仑策网【原创】发布时间:2021-08-06 06:53:09

7月22日，美国东部时间11:45（北京时间23:45），全美再次出现一次重大的互联网（Internet，下同）断服断网事件。据称，该事件几乎影响了包括金融、航空、物流、消费在内的各个领域，使得至少50个美国主要网站和一些国际（跨国）公司网站服务器“崩溃”。

这次断服事件是继6月17日由于Akamai（阿卡迈）公司的“技术故障”，导致一些银行和航空公司受到断服断网影响后，又一起大规模互联网断服断网事件，而“罪魁祸首”还是Akamai。

一、Akamai公司的官方解释

1）7月22日，Akamai在其官方微博发布对上述事件的如下总结：

2021年7月22日15:45（国际标准时间，UTC），由于我们对软件配置的更新触发了“安全边缘内容分发网络”（CDN）中的一个错误，影响了该网络的域名服务系统（DNS），DNS是将浏览器的应用请求定向到特定服务的网站。因此导致影响某些客户网站可用性的中断，中断持续了一个小时。在回归软件更新前的配置状态后，服务恢复正常运行。

我们确认，这不是针对Akamai平台的网信攻击。

我们对于由此带来的不便，深表歉意。我们正在审查内部的软件更新流程，以防止未来出现类似的错误。

2）7月23日，Akamai补充更新：

经过进一步调查，确定该技术故障与Akamai“安全边缘内容分发网络”（CDN）中的DNS无关。

二、思科“千眼”的监测和观察以及定量和定性的分析

“千眼”（Thousand Eyes）是思科公司（Cisco，全球的网络解决方案及核心设备供应商）的一个互联网络实时监测平台，对由于Akamai“技术故障”导致大规模断服断网另有定量的分析，对Akamai的“事件总结”有独立的见解。

7月22日，“千眼”就当天断服断网事件发布分析报告“Akamai边缘DNS的断服分析”，其概要强调：了解7月22日Akamai的边缘DNS断服是如何发生的真相，为什么相同的断服方式却导致不同的服务体验，以及应该从这次断服事件中吸取的三个教训。

该分析报告的参考译文如下。

7月22日，太平洋时间上午8点38分左右，Akamai的边缘DNS（是将用户定向到其CDN边缘服务器的关键服务）发生断服，导致全球用户无法访问其客户的站点。试图访问托管在Akamai站点的用户收到错误消息，显示所请求的域名无法解析为IP地址。大约一小时后，太平洋时间上午9点45分，该问题被解决，服务恢复（以下简称“断服事件”）。

通过域名系统（DNS）将域名解析为IP地址，是访问网络资产的关键第一步。虽然Akamai边缘DNS断服的时间不算长，但是所影响的范围却很广泛，大量网站和应用程序，从游戏到主要银行、航空公司等，完全或间断性地无法访问。尽管在Akamai DNS 断服期间，其CDN边缘基础设施（服务器）仍保持着运行，但是，如果没有CDN边缘DNS的权威域名服务器解析域名，用户就无法访问被托管在Akamai的网站和应用程序。

在断服事件期间，“千眼”观察到网站和应用程序被断网的数量激增，所有这些网站和应用程序都是被托管在Akamai的服务器上。

【译注：“自治系统”是在互联网中互联互通的网络基本单元，是可以独立管理的网络单元，也被称为是一个路由选择域，由包括路由器、交换机、服务器等基础设施组成。每一个自治系统都被分配全球唯一的编号（ASN），亦是被统一管理的互联网数字化资源。Akamai在全球有多个自治系统，图1中的自治系统AS16625在美国，自治系统AS20940在荷兰。】

“千眼”还进一步观察到Akamai CDN的边缘DNS无法提供在Akamai CDN中所托管域名的解析服务。

DNS在CDN数据流管理中的作用

域名系统（DNS）将人类可读的域名（例如“example.com”）映射到IP地址。CDN提供商通常使用DNS来平衡其基础架构中的流量负载，并根据终端用户的地理位置、服务器可用性或性能以及其他因素将用户重定向到最佳的边缘服务器。

以这种方式使用DNS，互联网服务提供商必须：

1）在其CDN的分布节点中掌控DNS记录。

2）托管服务和数据的企业，通常会将诸如“www”（网站）之类的域名配置为“别名”（CNAME）记录，该记录可能指向其他CNAME，并最终以提供IP地址的A记录结束域名解析服务。

3）这种分层方法允许CDN服务提供商（或代理商）控制客户端所接收CDN中的IP地址，并具有对所提供端到端的最终连接IP地址更改的动态性和灵活性，以优化客户端的“加速”体验。

例如，“千眼”使用Akamai的CDN服务托管门户网站“www.thousandeyes.com”。此域名被解析为Akamai边缘DNS的“edgekey.net”区域中的CNAME。该CNAME再被解析为“akamaiedge.net”区域中的Akamai CNAME，然后该域名被解析为连接CDN边缘服务器IP地址的DNS的A记录（图3）。

一旦CDN的DNS断服，那么CDN边缘服务器实际上也将无法访问。这就是Akamai的DNS断服事件期间发生的情况，而不论客户和用户被断网的影响程度可能存在的多种各异因素。

由断服造成断网的现象形形色色

Akamai是全球顶级CDN提供商之一，拥有庞大的客户群，从大型银行和“软件作为服务”（SaaS）提供商，到亚马逊等主要电子商务网站。在断服事件期间，“千眼”观察到使用Akamai服务的网站（或站点）之间的影响存在显著差异，其中一些网站保持着更高的可用性。

在DNS断服期间，一些Akamai客户网站（例如图4中所示的网站）呈现断网。这些客户所托管的站点完全依赖于Akamai的DNS和CDN服务，使得请求与这些站点的所有连接都返回DNS解析错误，或在尝试访问客户权威域名服务器时出现超时错误。而在断服事件开始之前已经与CDN服务或其他客户站点建立会话的用户不会受到影响，因为他们已经查询并接收了对DNS记录的响应。只有新的域名查询请求（即通过DNS的解析服务开始建立与网站或站点的连接）才会遭遇“断网”。

并非每个Akamai客户都受到类似的影响。亚马逊的电子商务网站几乎没有受到断服事件的影响。与上述客户的不同之处在于，亚马逊使用多元化的CDN提供商来托管其站点的内容，并利用自有的DNS服务来平衡每个CDN提供商之间的流量。这种结构有如下优点：

● 多元化的CDN可以提高用户的性能；

● 多元化的CDN提供商可能具有不同的地理覆盖范围或经过优化以提供某些类型的内容；

● 多元化的CDN提供商可以共同提供更多选项来优化用户的内容分发；

● 多元化CDN的方法还可以提高站点弹性，因为可以避免单个CDN服务提供商成为潜在的单点故障。

亚马逊能够在整个断服事件期间将流量分配给其他CDN提供商，这种多元化方式似乎使其客户和用户免于遭受断网影响（图5）。

在断服事件期间，亚马逊并未完全取消通过Akamai CDN的内容分发，而是利用其中某些边缘服务器的托管内容，并没有降低用户体验（图6）。

另一家电子商务提供商在断服事件期间仍然可以联网，但是由于等待DNS响应的时间过长，使得访问该网站的用户在页面加载时间更长（图7）。

虽然这家电子商务提供商将继续应用Akamai CDN作为其站点的根对象（root object），但是利用其他CDN服务提供商来处理其页面元素（page elements）的重要部分。

从断服事件中汲取的教训

Akamai的边缘DNS断服事件再一次地警示，断服责任不仅仅是由服务提供商承担。无论使用哪个运营商或服务商，断服都是不可避免的。

但是，机构和单位、行业和企业可以、而且应该采取措施，通过实施对关键服务的冗余保障并制定备份计划以解决不可避免的意外断服的问题，从而降低其数字化业务和服务的安全风险。

从这次断服事件中应汲取的三个重要教训：

1）关键服务应采用冗余的服务提供商的方案，例如CDN和DNS。多元化的CDN提供商可以提高服务弹性，并改进用户的体验。在断服事件中，基于多元化CDN服务提供商的Akamai客户遭受此次断网的影响最小。

2）一旦事件不可避免地发生了，能够有备应对。即使已实施了最佳实践、具有备份的服务体系架构，但是无法预见的事故或事件仍然是不可避免的。因此，还必须制定处理突发事件的应急行动手册，以最大限度地减少断服时间或断网影响。

3）确保主动地掌握所属网站、客户端以及关键的依赖关系，以便清晰地了解在何时实施备份计划；对所有应用程序组件（包括构成服务交付链中的任何第三方依赖关系）的可视化，能够提供最有效的方法以确定何时启动备份计划、知道执行什么策略，对于避免或缓解断服断网的损失至关重要。

三、对“深度依赖”现象和状况的再警示

请注意，“千眼”观察到的断网网站和应用程序的数量“激增”，其中包括中国（17个，图1）。但是，国内并没有直接感受到此次断服的明显影响，其中一个主要原因是：断服发生时是北京时间23:45（午夜时分）。

而国内托管在Akamai CDN的业务和服务（网站、站点、邮件服务器和数据库的数量）远超出17个，没有遭受到断服事件的影响，仅仅是在时间差上的一次“侥幸”。试想，如果发生在北京时间白天9:45-15:45之间，会是怎样？如果是网信攻击，又会是怎样？

“千眼”定量分析的问题根源具有普遍性，定性分析的教训警示具有典型性，值得高度警惕，并亟待采取相应措施。反之，倘若仍抱着“无所谓”的观望态度，“不可避免”的断服事件（如CDN和DNS）再次发生，如果没有时间差“侥幸”的眷顾，而是针对性地网信攻击，必将波及你、我、他，后果不堪设想。

我们已在早前的《Fastly和Akamai断服断网深层原因的分析》一文中提出：“零信任”不仅是网信三元组（triad）“安全性、隐私性和合规性”的关键基础，而且是信任与信赖的（杠杆）支点，以及对避免“深度依赖”技术和服务的权衡点。

在构建多元化的“服务交付链”（Service Delivery Chain）中，尤其需要重视的是对“任何第三方的依赖关系”，包括信息和通信技术供应链（ICT Supply Chain）。其中，在核心技术和关键服务中，任何以“马甲”形式的变通（Workaround）“包装”，都无疑是自掘自留的安全漏洞和自行埋藏的安全隐患。

综上，基于事件驱动、问题导向，再次郑重建议：

1）对国家关键基础设施的网信业务应自上而下地审视并重构服务系统结构，在避免“深度依赖”（尤指CDN和DNS）的同时，由一体化的指挥和控制指导，向多元化技术和服务体系的过渡转型。

2）在关键数据安全保障中，重塑甲方和乙方的关系，建立共同担当责任的常态化机制和赋能，以避免或缓解“无法预见”的安全事故或单方面“不可避免”的安全事件，有备无患（少患）。

3）加强对基于弥补缺失和短板的核心技术的积累性自主研发，主动且切实地落实对“任何第三方依赖关系”的可视化管理和监督。

此外，从上述CDN引发的断服断网事件中，另一个关联的网络安全问题必须且应该得到高度关注（和纠偏）。

近年来，不论是美国或是欧洲，也不论是美国国家安全局（NSA）/网信安全与基础设施安全局（CISA）或是境外安全企业，发布的所有安全警报和分析报告，无不是以战术、技术和过程（简称TTP）作为溯源、定位和画像的基本手段，并由此给出漏洞指标（IOC）、解决方法和缓解建议。其中，IP地址多是与域名和自治系统相关联（或是通过多源DNS记录的反向分析），而传统的IP地址属性己被赋予动态可变性，即不再具有网络通信端到端连接标识的唯一性。例如：在CDN中通过域名系统（DNS）的“别名”（CNAME）转换之“旋转门”。

因此，把遭受攻击（或安全事件）的证据简单地归咎于IP地址属地的方式或方法，如同于“有罪推定”（缺乏类似TTP的证实和证据），既约束了已方的认知和能力（甚至是误导），也难以形成对彼方的警告和威慑（或是反制）。尤其是，在信息通信技术和服务（ICTS）供应链中，任何技术缺陷或人为失误，都可能是导致断服断网的单点故障；而在网信空间（Cyberspace）非常规作战的能力，已经形成攻防一体（或推进防御）的模式和实战。

为此，应该且必须形成必要的认识和共识：网信安全的风险管理，不是单调的技术性问题，更不是空洞的口号与呐喊。空话误国，实干兴邦。“没有意识到风险是最大的风险”，明知风险不能脚踏实地务实地直面盲区、解决问题、排除隐患、预防风险（将风险因素降到最小、最低），也许就是在自觉或不自觉地祸国误民。

（作者：邱实，网络信息安全技术专家；牟承晋，昆仑策研究院高级研究员、中国移动通信联合会国际战略研究中心主任。来源：昆仑策网【原创】，作者授权发布）

【昆仑策研究院】作为综合性战略研究和咨询服务机构，遵循国家宪法和法律，秉持对国家、对社会、对客户负责，讲真话、讲实话的信条，追崇研究价值的客观性、公正性，旨在聚贤才、集民智、析实情、献明策，为实现中华民族伟大复兴的“中国梦”而奋斗。欢迎您积极参与和投稿。