7月22日，美國東部時間11:45（北京時間23:45），全美再次出現一次重大的互聯網（Internet，下同）斷服斷網事件。據稱，該事件幾乎影響了包括金融、航空、物流、消費在內的各個領域，使得至少50個美國主要網站和一些國際（跨國）公司網站服務器“崩潰”。這次斷服事件是繼6月17日由于Akamai（阿卡邁）公司的“技術故障”，導致一些銀行和航空公司受到斷服斷網影響后，又一起大規模互聯網斷服斷網事件，而“罪魁禍首”還是Akamai。1）7月22日，Akamai在其官方微博發布對上述事件的如下總結：2021年7月22日15:45（國際標準時間，UTC），由于我們對軟件配置的更新觸發了“安全邊緣內容分發網絡”（CDN）中的一個錯誤，影響了該網絡的域名服務系統（DNS），DNS是將瀏覽器的應用請求定向到特定服務的網站。因此導致影響某些客戶網站可用性的中斷，中斷持續了一個小時。在回歸軟件更新前的配置狀態后，服務恢復正常運行。我們對于由此帶來的不便，深表歉意。我們正在審查內部的軟件更新流程，以防止未來出現類似的錯誤。經過進一步調查，確定該技術故障與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）將人類可讀的域名（例如“example.com”）映射到IP地址。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提供商，這種多元化方式似乎使其客戶和用戶免于遭受斷網影響（圖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）非常規作戰的能力，已經形成攻防一體（或推進防御）的模式和實戰。為此，應該且必須形成必要的認識和共識：網信安全的風險管理，不是單調的技術性問題，更不是空洞的口號與吶喊。空話誤國，實干興邦。“沒有意識到風險是最大的風險”，明知風險不能腳踏實地務實地直面盲區、解決問題、排除隱患、預防風險（將風險因素降到最小、最低），也許就是在自覺或不自覺地禍國誤民。（作者：邱實，網絡信息安全技術專家；牟承晉，昆侖策研究院高級研究員、中國移動通信聯合會國際戰略研究中心主任。來源：昆侖策網【原創】，作者授權發布）
【昆侖策研究院】作為綜合性戰略研究和咨詢服務機構，遵循國家憲法和法律，秉持對國家、對社會、對客戶負責，講真話、講實話的信條，追崇研究價值的客觀性、公正性，旨在聚賢才、集民智、析實情、獻明策，為實現中華民族偉大復興的“中國夢”而奮斗。歡迎您積極參與和投稿。
電子郵箱：gy121302@163.com
更多文章請看《昆侖策網》，網址：
http://www.kunlunce.cn
http://www.jqdstudio.net
特別申明：
1、本文只代表作者個人觀點，不代表本站觀點，僅供大家學習參考；
2、本站屬于非營利性網站，如涉及版權和名譽問題，請及時與本站聯系，我們將及時做相應處理；
3、歡迎各位網友光臨閱覽，文明上網，依法守規，IP可查。
