零信任與保護雲端
發現雲端的零信任機會
雖然「零信任」一詞經常遭到誤解及濫用，但這個方法的真正價值在於協助降低系統性的網路風 險並提升彈性。
移轉到雲端為零信任架構提供了新的契機。
怎樣才算或不算是零信任？
有部分廠商表示零信任幾乎都與身分和存取管理有關。也就是企業如何讓獲授權的使用者存取資源。雖然它確實是 零信任的構成要素，但也只是整個大型策略的其中一個環節，因為企業在營運時必須將身分、基礎結構、產品、程 序和供應鏈中的所有風險列入考量。
幾乎每一名安全專業人員都會告訴您從過往經驗來看，完全信任架構和網路總是會造成很大的風險。包括連線到數 據中心網路的受信任網路可能會遭到入侵、端點會遭到駭客攻擊、持有「天國之鑰」的受信任使用者可能會形成內部人員威脅、受信任的作業系統程序會遭到木馬程式劫持，受信任的檔案具惡意性質等等。
因此，零信任可提供一種策略性方法來消除技術性實體之間所有隱含的信任。舉例來說，就像是我們不只會在俱樂 部門口，也會在俱樂部店內和車庫設置保全人員，同時雇用一些保鑣來保護俱樂部外頭的顧客。不過，零信任真有 這麼簡單？只要提升安全性就能解決問題？
老實說，企業的關鍵問題本來就不在於是否應採用零信任，而是在於為什麼目前是採用的時機，以及哪些部門應開 始考量高成本還有不願改變的心態。
適用於黑天鵝的零信任
就我的經驗來說，成功採用零信任政策的企業通常都是先將計劃的重心放在風險管理上。由於我已經在大型金融服 務企業任職超過十年，因此我對於風險管理相當了解。尤其是有時候一些小事件可能都會造成企業甚至是整個產業 的重大損失。
這一類的系統事件，也就是所謂的黑天鵝，最近在我們的網路安全元宇宙中也變得非常普遍。勒索軟體和供應鏈事 件可能是我們在最近的新聞媒體中最常看到的報導。這些風險都是零信任計劃應關切的對象。
從這類技術性系統風險的根本原因來看，可以分為不同的類型，一旦結合多種類型，則情況更加糟糕：
- 單點故障。其中包括將所有技術堆疊結合在一起的核心基礎結構。不安全或架構不適當的 Active Directory、 WebSSO 或 DNS 基礎結構會迅速演變成一場災難。
- 過時的軟體單一文化。 整體企業採用率高但未定期修補的作業系統、韌體和軟體。單一弱點會導致災難性的勒索 軟體或攻擊風險。
- 扁平式網路效應。 在 IT (考量您所有未受管理的裝置)、OT 和 IoT 中缺乏適當區隔或網路控制的企業。對所有入 侵者或病毒/勒索軟體來說能輕鬆展開行動。
零信任金字塔
繼承所有這類系統性風險的傳統公司通常會根據以下這兩種構成要素而展開零信任計劃：協調他們的身分和存取管 理堆疊並協調其連線環境。這可以為額外的零信任構成要素建立基礎以因應其他的系統性風險，例如韌體單一文 化、應用程式等等。
零信任中的平台角色
通常我會藉由以下的說法來解釋何謂網路安全彈性：若要建立一個高彈性的企業，我們必須要讓安全性成為一種系 統，而不是一種組成目標。例如，不要將您的重點放在沙箱控制效果的測試上。而是必須排定優先順序，決定您的 沙箱該如何與企業中的其他安全控制進行整合。或者，若您最關鍵的應用程式是連線到與價值數百萬美元的 IoT 裝 置相同的網路，並在伺服器上執行一些額外暴露的服務，就不要花費數百萬美元來針對該應用程式進行滲透測試。
在去中心化和片段化的世界中，由於工作負載和身分會散佈在網際網路的各個角落，若不針對安全營運所需的一些 核心功能進行協調，這一類的系統性網路安全觀點就很難真正落實：
- 共同的身分和政策堆疊。
- 對於可展開行動的威脅具有共同的了解。
- 共同的通訊協定/控制，以於整個系統執行您的政策和威脅資訊。
您可以參閱 Phil Venables 最近的部落格，了解他如何透過不同的方式來進行說明。他寫道，「對於許多企業的企 業安全性來說，其中一個最成功的技巧就是建立一個適用於任何地方的普遍性基準，然後藉由單位控制成本 (現有和新增) 的降低，以更經濟實惠的方式提高基準。」
他在部落格中以汽車業為例子指出，賽車安全功能商品化朝著家庭房車發展的模式也可以複製到網路安全領域。事 實上，網路安全性和連線就是一個絕佳的範例。
在過去，網路安全性的運作方式就是只要位於企業內的就一律信任，企業外的一切則一律不予信任，安全性的實施 只會以企業的邊界作為基準。然而，對於遠端工作者、雲端、邊緣和行動存取需求來說，該模式卻早已不適用。
如今，所有這些環境都會直接連線至網際網路。不過，它們全都缺乏最基本的控制，例如區隔或入侵偵測。其原因 就在於個別控制和政策的測試和部署會導致較高的成本，讓企業幾乎無法負擔大部分的網路安全控制。
這也是為什麼網路安全平台會成為部署零信任策略的最佳選項，對於大部分的長期網路安全計劃來說也是一種經濟 性差異化因素。
零信任的雲端契機
置換舊型的連線或安全堆疊是至關重要的大事，除了您的雲端和遠端工作者計劃以外，有時候也需要藉助極端的方 式 (勒索軟體) 來推動，但零信任計劃的出現可說是一種全新的契機，不但不容忽視也不應再被浪費！
隨著企業的工作負載、應用程式和使用者不斷朝向雲端發展並大量採用 DevOps，是時候從頭開始架構您的安全 性，而不要事後再來補救。在此脈絡中，若您想要採行一種系統性的方式，除了生產環境的安全性以外，您還必須 儘早思考 CI/CD 管道的安全性以及管道中的安全控制整合。現在就讓我們以零信任語言來系統地闡述一些問題， 若您認真看待 DevOps 和雲端環境中的安全性，更應將這些問題納入您的工作簿中：
- 您是否相信軟體工程師的裝置並未遭到入侵？
- 您是否相信您的程式碼儲存庫並未遭到入侵？
- 您是否信任開發和部署程序中的程式碼完整性？
- 您是否信任您的第三方基礎結構即程式碼 (IaC) 範本或 Docker 容器？請記住，平均來說，其中有一半都存在與 其本身有關的惡意弱點。
- 您在專案中使用的其他軟體應用程式相依性又是什麼情況？
- 您是否相信您的身分已被指派至適當的權限？
- 您是否相信您的程式碼已經過安全性或錯誤設定檢查，例如硬式編碼憑證、過度授權網路設定等等？
- 您是否相信您的微服務協調器未遭到入侵？
雖然仍有許多其他問題尚待解決，但重點在於無論是 DevOps 環境的垂直或水平方向，系統性的風險仍持續增 加。就垂直方向來看，相較於傳統環境，我們必須考量更多的風險。就水平方向來看，就如同我們在 SolarWinds 等許多案例所看到的，單一套件一旦受到污染，其影響將非常巨大。
切勿再錯過這次機會，請務必在 DevOps 和雲端之旅的一開始就建置零信任的基礎。
