前端安全沙箱技術如何解決開源安全問題？

2020年12月針對SolarWinds®的 "供應鏈攻擊"被認為是網路安全界的一個里程碑事件。這次攻擊是由SolarWinds的Orion軟體中的安全漏洞導致的，使駭客能夠入侵全球數百家公司的系統。

早在2017年，駭客實施了 "NotPetya "供應鏈攻擊。透過在廣泛使用的會計軟體中植入一個 "後門"，他們能夠感染數百家公司的系統並竊取資料。多年來，駭客透過攻擊PDF編輯器應用程式、第三方資料聚合器，甚至是暖通空調服務供應商（2014年臭名昭著的Target攻擊）來發動供應鏈攻擊。

開源軟體運動如火如荼的進行了二十四五年，極大程度的改變了軟體業的面貌。當前全球企業超過90%直接或者間接甚至在無意識中使用了開源技術。享受便利的同時問題也隨之而來，以上的軟體供應鏈安全事件也層出不窮。為了保護自己免受此類攻擊，企業必須超越傳統的、有風險的 "信任但核實 "的網路安全方法。

軟體供應鏈的四大風險

對於企業來說，當前軟體供應鏈起碼面臨四類風險。

1、軟體質量風險。企業軟體表面上由IT或者外包商開發，可是實質上背後是成千上萬的第三方開原始碼，企業的QA工程質量管理方法和流程，對於第三方完全失控無效。

2、長期支援風險。企業軟體所間接依賴的一些第三方開源零部件，並沒有商業體在背後提供質量承諾和長期支援。開源專案因創始人退出或者社群活躍度低而不再維護、半途而廢的，不在小數。產生維護支援需求時，企業自己不得不安排人手去處理該部分程式碼，先不說有沒有這個意願，企業自己的IT工程師是否有這個能力也難說。

3、智慧財產權風險。開源軟體的智慧財產權機制，反映在著佐權（Copyleft）和許可證（Permissive）。後者約束了你的軟體的分發傳播需要滿足的條件，前者則往往更進一步要求你用開源元件開發的軟體本身的原始碼必須沿用同樣的開源條款，導致你的軟體智慧財產權不得不公開。國內軟體企業在使用開源、貢獻開源的過程中規則意識普遍薄弱，存在錯誤混用不相容的許可證，違反許可證規定二次釋出等問題，帶來更為複雜的智慧財產權問題和法律合規風險。

4、資訊保安風險。在開發人員寫第一行程式碼前，一個系統可能就註定繼承了一堆“安全債務” - 部分取決於這個系統的設計者、開發者選擇採用什麼第三方元件，部分取決於這些第三方元件的開發者又選擇依賴於什麼別的元件。反正安全風險是傳遞的，只要有一個零部件有安全漏洞、甚至是在漫長複雜的網際網路分發鏈路上被篡改過注入了惡意程式碼，你的系統就繼承了所有這些風險。

在資訊化程度比較高的金融業，軟體作為金融資訊基礎設施的重要組成部分，安全問題將直接影響金融資訊系統的安全穩定執行。對於企業來說，如何把軟體供應鏈裡的“惡意”關在籠子裡？或許安全沙箱一種可操作的手段。

前端安全沙箱技術應用案例：

虛擬世界的“惡意”程式碼，也只能用虛擬的“牢籠”去“關住”它。安全沙箱（Security Sandbox），就是這麼一種數字牢籠，它的形態和技術實現方式有很多種，本質上它是一種安全隔離機制，透過構建一個封閉的軟體環境，隔離了它所在的“宿主”的資源包括記憶體、檔案系統、網路等等的訪問許可權。執行在這個封閉環境中的程式，其程式碼不受信任，程式不能因為其自身的穩定性導致沙箱的崩潰從而影響宿主系統，程式也無法突破沙箱的安全管控以讀寫宿主系統的資源。

沙箱類技術以各種形態出現：在BSD等作業系統裡就提供直接叫做“Jail”的虛擬化隔離；在JVM裡為了支援Java Applet這裡網路載入的程式碼的執行，實現了sandbox機制；瀏覽器裡的HTML渲染引擎，一定程度上也可以視為一種在使用者態的基於安全能力模型（Capability-based）的沙箱技術。

在雲端計算的環境下，雲原生型安全沙箱技術也在演進，有望在企業環境中，對軟體供應鏈安全問題提供一部分“治標”的解決方案（“治本”還得更加長期、綜合、涉及面更廣的綜合策略）。

FinClip：前端安全沙箱技術

FinClip是一種新型的輕應用技術，它有一個比較有趣的邏輯： 企業的軟體供應鏈在數字化時代可能是需要被重新定義的 - 有可能你的合作伙伴的程式碼執行在你這裡、也有可能你的程式碼借道合作伙伴的平臺去觸達對方的客戶。FinClip的核心是一個可嵌入任何iOS/Android App、Windows/MacOS/Linux Desktop Software、Android/Linux作業系統、IoT/車載系統的多終端安全執行沙箱。

FinClip安全沙箱中執行的輕應用，選擇了相容網際網路主流的小程式規範。這是一個非常明智的設計，FinClip的開發團隊沒有重新發明自己的技術規格，而是全力支援小程式這種形態的輕應用，一方面是因為小程式類技術的體驗和效果在網際網路上得到充分驗證、獲得巨大成功，另一方面是網上積累了豐富的技術生態、開發框架、以及更重要的 - 人才資源，從而讓企業IT幾乎是無縫掌握這個技術，能迅速投入應用。

FinClip的嵌入式安全沙箱，又被稱之為小程式容器，它的本質其實是建立在Security Capability model基礎上的瀏覽器核心的擴充套件，其沙箱的特點，體現在三個方面：

• 沙箱內小程式之間的隔離
• 沙箱對執行其中的小程式程式碼，隔離其對宿主環境的資源訪問。以一家銀行與它的合作生態為例，銀行在自己的App上引入了衣食住行各類消費場景的小程式，這些小程式均非本行開發，也不能訪問到當前宿主App的任何資料資源
• 沙箱隔離了宿主對於沙箱中執行的小程式所產生的資料。以一家銀行與一家券商的合作為例，券商把自己的業務小程式投放到銀行的App中，銀行App作為宿主，並不能訪問沙箱內部該小程式的執行資料（當然，這是需要有一定的行業規範、監管政策去約束，但技術上首先是完全可能）

換句話說，FinClip試圖構建一個Zero Trust（“零信任”）環境，不管小程式的“供應商”是誰，它們的程式碼都被隔離、同時也被保護在沙箱環境中。

FinClip安全沙箱還配備了雲端的管控後臺，讓任何小程式可以被關聯到指定的App宿主所嵌的沙箱例項中，從而能且僅能執行在某一款App或者某一個終端上。像網際網路小程式一樣，FinClip的小程式也可以被實時上下架，對於金融機構來說，起到“實時風控”的效果，因為上下架的管理工具和許可權，都由企業私有化執行、自行負責。任何有潛在安全風險的前端程式碼，一經發現即可瞬間下架，使用者端再也無法開啟使用。這些安全管控的能力，可以說是企業尤其是金融機構數字化轉型所必須。對於企業而言，內部IT、外部合作伙伴，均可以作為“供應商”以小程式方式實現、提供數字化場景，從而形成數字生態。

Deno：雲端安全沙箱技術
Deno是Node.js的發明者Ryan Dahl的重新發明。在推動伺服器端JavaScript的應用生態獲得巨大成功後，Ryan也看到Node.js的很多存在問題，在2018年的一次公開演講中，提到了其為Node.js感到後悔的十件事。最終他另起爐灶，按自己的理想重新打造一個新的技術，也就是Deno，其中最重要的設計考慮就是安全優先、為deno技術設計的第一性、並採用V8引擎作為JavaScript執行的安全沙箱。
deno-sandbox

[預設執行在Deno的沙箱裡的程式碼，沒有對沙箱以外任何資源的訪問權]
當然，Deno不僅是一個安全沙箱，在本文我們僅從這個角度去談論它。它的野心不僅在於替代Node.js把之前沒有做對的事情做對，它基於Rust語言實現，支援WebAssembly，提出了“Isolated Cloud”（隔離雲）的概念，給網際網路提供比docker等容器類技術更加輕量和啟動時間更短、實現程式級隔離的新一代安全基礎技術設施，最新訊息是幾天前由紅杉資本領投獲得了新一輪2100萬美元的投資。

企業必須面對真實存在的網路攻擊威脅，這就是不可改變的事實，一旦遭遇軟體供應鏈攻擊，其造成的破壞都是非常嚴重的，數字化企業需要去除不言而喻的、隱含的對內外網任何應用、網路、使用者的信任假設，應用之間、服務之間、元件之間的通訊連線，並不建立在假設的安全信任基礎上，完全隔離、大家都是陌生人、每一次的互動都必須做足安全認證、不因為在同一組織或者網路下就可以安全降級，並且任何程式碼的執行始終受到監控以捕捉任何可疑行為。

不錯，就是一種“草木皆兵、疑神疑鬼”的架構準則。但是對於透過供應鏈汙染而“播種”內鬼的安全攻擊，似乎這是最有效的手段。