以雲端創新確保網際網路安全

Clarke Rodgers (00:10)：
回首網際網路普及之前，安全議題顯得更單純且明確，這點實在令人難以想像。過去四十年間，世界經歷了劇烈轉變，如今網路連線已然成為我們生活與商業營運的核心。這樣的轉變帶來更多機會，卻也伴隨著更高的風險。

我是 AWS 的 Director of Enterprise Strategy Clarke Rodgers，也是您在 Executive Insights 的嚮導，帶您一同與 AWS 的安全領導者進行一系列對話。

今天，我們與 AWS Deputy CISO、Vice President 暨 Distinguished Engineer Paul Vixie 對談。Paul 對早期網際網路的發展有著深遠影響，他為 AWS Security 帶來了獨特的觀點。加入我們的對話，探討安全領導者在讓網際網路成為更安全的溝通場所中所扮演的角色。希望您會喜歡本次的對話內容。

Clarke Rodgers (00:57)：
Paul，非常感謝您參加我們今天的訪談。您在網際網路領域已有相當豐富的資歷。能否分享一下您對網際網路從早期至今之發展的觀察，特別是從安全角度來看？

Paul Vixie (01:11)：
其實，安全性當時並非優先考慮事項。這點在早期的確是稍後才有的考量，但網際網路的起源故事卻都是事實。網際網路一開始是作為美國政府的網路。但至少在早期並不曾由軍方使用。因此，人們有流傳這麽一種說法，即通訊協定都是專為防範動能攻擊等狀況而設計的。但那並非事實。網際網路向來是「盡力而為」的系統。運作順暢時，就能造福廣大人群。然而，一旦出問題，其就會遭遇更強固的網路不會面對的嚴重失靈狀況。

Clarke Rodgers (01:48)：
您是在什麼時間點意識到，「糟糕，當初沒有考慮到安全性？」 又是怎麼醒悟到需要採取相應措施的？

Paul Vixie (01:56)：
我蠻早就開始提出警告了，最初關注的是垃圾郵件問題。當時沒有驗證機制，因此沒辦法阻止人們傳送不受歡迎的流量。畢竟在純政府網路中，不會有人會因傳送不受歡迎的流量而獲利。

所以我早在 1992 年就開始提出警告。而在獨立出來提供顧問服務後，我也開始了第一個反垃圾郵件專案，進而將其發展為第一家反垃圾郵件公司。而我們的分散式聲譽管理系統是當時的首創。真可惜我沒為此申請專利。我的意思是，儘管我創辦來對抗垃圾郵件的公司因為訴訟而歇業了，但那個系統至今仍受廣泛使用。所以那家公司不復存在了。但這個想法和技術都還在，這也證明當初我的構思是正確的。

Clarke Rodgers (02:57)：
如您所見，大型雲端服務供應商甚至是客戶公司現在已更認真地對待安全性，我希望這樣的現象至少會讓您備受鼓舞。這是否讓您感到樂觀？

Paul Vixie (03:13)：
我抱持希望，但同時參雜著失望，因為我們所做的遠遠不夠，而且太遲了。但你得等到整個市場覺醒並意識到問題所在。你不能僅以一家公司或個人身分去敲響警鐘。

讓我感到有希望的是，我在加入 Amazon 之後接觸到的一系列技術。事實證明，企業在達到一定規模時，會出現一些你可以歸納的問題，進而部署解決方案，而規模較小的公司無法做到這一點。因此，舉例來說，我們在 Graviton 處理器中所做的一切，是為了讓 VM 更安全地抵禦其他 VM 的攻擊，而除了我們之外，尚未有人做到這點。

再看看 Nitro 晶片組和 Nitro Hypervisor，這目前也只有我們做得出來。舉例來說，Log4j 出現時，我們並非完全不受影響，但卻在幾十個小時內就為所有客戶準備好了修補程式，因為我們公司的規模龐大，人員進而明白該怎麼行動，並能在全球範圍內迅速部署。反之，在去中心化的系統中，每個人只為自己的工作負責，而只能等待供應鏈甦醒過來。

「因此，我抱持希望，僅僅是因為隨著網際網路成為關鍵基礎設施，以及全球數位神經系統和世界經濟的來源，人們開始更認真地看待它。」

而許多我們在當初每個電晶體值一美元的時代憑藉極其有限的資源所做的事情，正逐漸遭淘汰。除了打從一開始就不做那些讓我們能比 OSI 通訊協定更快進入市場的蠢事，沒有別的方法可以解決這個問題，除非用得上像我們這樣的雲端服務。

Clarke Rodgers (05:09)：
展望未來幾年，是否有任何您特別期待的技術或方法，將不僅幫助像我們這樣的公司，還能幫助我們的客戶在安全和合規工作負載方面取得進展？

Paul Vixie (05:31)：
當然，有件在公司內部很振奮人心的事，那就是容器發展的趨勢。我們能在單一晶片上運作 10,000 個容器，並在負載高峰時每秒啟動數千個容器，卻不用要求別人徹底改變他們的軟體工程做法，這點很令人振奮，因為隨著人們轉向這種模式，我們就能擺脫現有問題，例如修補程式。

幾乎每一天，總會有東西需要修補。除非你有專門的負責團隊，否則你會拖延這項工作，一週或一個月才會做一次。而你這麼做時，可能會發現：「天哪，為了讓這個修補程式符合我的系統，我還得升級這些其他東西，這意味著我得將它們全都一一測試。」 因此，從發現某些東西真正迫切需要修補程式，到最終在系統中安裝該修補程式的時候，已經是幾個月後的事了。

►  收聽播客：零日安全情境中的漏洞管理

本人認為，如果繼續這樣下去，那我們將不可能達到如《星際爭霸戰》中一切完美運作的輝煌未來。因此，容器等事物，無論是 Lambda、Kubernetes、Firecracker，都能讓您有機會建立所謂的 CICD 建構管道，製作映像檔並執行其測試。如果通過，即可將其投入服務中。

您不必擁有具備足夠內建工具和邏輯的 VM，以便在實際情況下加以連接並用於自行修補。這就是我們現在所做的事，而這種方式不會擴展。雖然我因個人習慣而依循舊法，但這套方法已經出現了一些問題，我並不建議其他人效仿。他們沒有理由繼續這樣做，而如果我們能達成共識，並表示：「是的，我們會建構好系統，然後就不再更動它」，這會帶來很多好處。

另一個令人振奮的想法是，我們將不再需要人類介入。這麼說很遺憾，因為這是人類的想法，也是人類打造的成品，但如果想要擁有不會隨著時間過去而降低的安全性，我們就必須減少人為參與因素。

介於人類與交付給客戶的價值之間的軟體和硬體數量前所未有地多。而人們的理解程度相對固定，也就是說，隨著軟硬體數量增長，我們能夠理解的比例反而越來越小。這行不通。我們必須找出方法，確保複雜性不會造成不良的結果。必須再度強調的是，這取決於我們是否有更高的紀律，並減少人類的介入。

「我很遺憾這麼說，因為這是人類想出來的，也是人類建造的，但如果我們想要有不會隨著時間過去而降低的安全，就必須減少人為參與因素。」

Clarke Rodgers (08:18)：
隨著人類存取和網路的理念持續發展，零信任的概念在多年來不斷演變。您對零信任有何看法？無論是從 AWS 的觀點 (例如我們內部思考與實作的方式)，或是從客戶角度，他們該如何看待零信任？

Paul Vixie (08:39)：
零信任的關鍵不可簡化元素遭到誤解。例如，我聽過有人這樣說：「把所有東西都放在網路上，全部開放存取，然後保護服務和伺服器本身。」在沒有週邊的情況下保護網路。」 這不是零信任的重點，而且行不通。您還是需要防火牆，只是進入防火牆後，您會發現僅是處於週邊內，並不能代表擁有任何特殊信任。

因此，它消除了「可達性」表示了「可信度」的假設。這兩者以往稱為「酥脆的外皮」和「軟黏的內部」。 因此，即使仍有酥脆的外皮，我們也不想要軟黏的內部。所以，你需要一套可大規模自動化身分識別、驗證和權限的系統。舉例來說，我們在進行這場對話時，Amazon Cloud 上每秒正發生數十億起驗證事件。

我們也沒有投機取巧，例如快取最近的驗證結果，然後說：「如果你在一秒前還擁有權限，那現在應該也是如此。」不，我們每次都會檢查，並在某個時間點咬緊牙關應付，並表示：「唯有嚴格的驗證機制才能把安全做到滴水不漏。」

但話說回來，大多數系統的設計思維是：如果您能進入系統，那由於缺乏大規模運作的精細存取控制，您就可以在其中為所欲為。這就是我們正在改變的事情。而且，業界内有很多不同的驗證標準。我們的驗證標準雖然率先推出且規模龐大，但我們從未想過要讓其成為產業標準。而其他雲端業者也有類似的開發方向，有些業界標準也在醞釀之中。

而且就我所知，在沒有與服務團隊討論的情況下，我們將確保任何想要這樣操作的客戶都能這樣做。

Clarke Rodgers (10:49)：
過去一年左右，生成式 AI 頻繁出現在新聞媒體上，幾乎每天都能看到相關報導。從安全從業人員的角度來看，您對此有何看法？ 您認為安全專業人員該如何運用這項技術來協助防護、調查這類問題？

Paul Vixie (11:10)：
我們必須拋開過度的炒作，並思考：「當熱潮退去後，這項技術的真正價值會是什麼？」 在某些情況下，我們難以判斷。這是相當新的技術，很多人正在為其打造硬體和軟體。而直到一項工具被創作者以外的人使用，我們才能真正了解其影響力。就好比你把扳手當成錘子使用，這可能並非扳手製造商的本意，但或許能在某些情況下奏效。

我們尚未看到強烈的跡象顯示，在炒作週期結束、其他搶佔頭條新聞的事物出現後，生成式 AI 能真正實現哪些可能性。話雖如此，Amazon 至少在過去十多年來一直在進行 AI 解決方案的研究、開發及部署。所以，生成式 AI 對我們而言並非完全陌生的領域。

我們已經有一個範例，就是 CodeWhisperer 系統，它使用了生成式 AI 技術，但與近期備受矚目的應用有著截然不同的樣貌。我認為這種情況會在各式各樣的系統上發生。例如，執行異常偵測時，您會查看系統的遙測流程，您會查看表示問題可能出現或有人可能正攻擊您的事件。現在藉由生成式 AI，即可進一步交叉比對這些資訊。我要再次強調，目前我們所看到的只是未來可能性的冰山一角。

►  觀看影片：生成式 AI 的現況

因此，一方面我鄙視炒作週期，希望我們從一開始就能認真對待這項技術，但另一方面我也明白其確實擁有真正的潛力。我正在與 AWS Security 內部的一些團隊合作，他們試圖回答這個確切的問題：「既然生成式 AI 已普遍可用且受到一定程度的理解，我們能如何進一步服務客戶？」

Clarke Rodgers (13:14)：
那麼，從技術角度來看，企業是否能運用生成式 AI 協助安全從業人員處理大量繁瑣的工作呢？

Paul Vixie (13:25)：
是的，我並非要將此作為產品宣傳，但 Amazon 在雲端方面最大的成功，一直都是我們協助客戶採用和建置的工作流程。因此，我們在大型語言模型領域率先推出的服務之一就是 Bedrock。核心概念在於，如果你想使用大規模語言模型，那你是否也願意支付訓練成本？ 你希望自己建立模型嗎？

因為這可能需要數千或上萬小時的昂貴電腦時間才能完成。若能提供多樣化的預先建置模型，讓使用者可以從功能表上挑選所需模型，而無須支付將模型複製到自有系統的費用，則即可直接在 VPC 或在 AWS 雲端環境執行的任何專案中，放置能直接存取 API 的邏輯，而這些 API 知道它們有權存取這些訂閱模型。

因此，當時我並不知道最初的成功條件，是來到這裡後才學會的。雲端之所以能成功是因為它擁有彈性運算容量，因此，無論你真正需要多少運算容量、多少彈性儲存容量，你都能在沒有存取罰則的前提下取得這些，這就是我們發展到如此大規模的訣竅。現在我們在生成式 AI 上複製了這個成功模式，讓各領域中富有企圖心的使用者能在我們的雲端服務和 LLM 的結合下，完成他們一直以來在沒有 LLM 的情況下，利用我們的雲端完成的工作。我們很喜歡這樣。我喜歡這樣，因為這項技術的真正威力將來自於客戶如何運用它。

Clarke Rodgers (15:13)：
而且，客戶對多年來使用的所有安全工具及其他方面的信任早已建立起來，現在可以延伸到 Bedrock 等工具，以及其他未來可能出現的新產品。

Paul，非常感謝您參加我們今天的訪談。

Paul Vixie (15:26)：
很開心與您交談。再次感謝您邀請我。