外文翻譯：英文原文

前言

在三十多年前，虛擬化僅適用於擁有大型機和眾多小型計算機的使用者，而安全問題僅僅是物理上的。 二十年前，VMware釋出了其第一款產品，網路邊界安全性仍處於起步階段，依賴於防火牆。 十二年前，AWS推出，網路安全成為一個問題。 五年前，由於Docker，容器成為主流，主機安全成為焦點。 今天，隨著無伺服器安全性的增長，應用程式級安全性終於受到已經存在多年的計算和網路層全面審查。隨著應用程式，計算和網路安全都被審計，通過SOC type 2等報告，管理層和客戶端都可以更加了解安全問題。隨著客戶端透明度的提高，安全專業人員是確保部署資產和使生產具有堅實安全性的關鍵。 根據正在使用的部署型別，相應的配置規模大小可能會急劇增加。以上就是理解不同型別的新興部署技術（即容器，無伺服器計算和虛擬機器）之間的安全細微差別的原因。 下面，我們對比一下他們的安全方面。

無伺服器安全

首先，讓我們解決無伺服器安全問題，因為無伺服器應用程式通常是純粹執行單個函式的程式碼——因此叫做function-as-a-service。 你實際部署平臺可能對無伺服器應用程式中發生的最常見安全問題無動於衷。除了遵循安全編碼最佳實踐，例如僅返回處理請求絕對需要的資料並讓應用程式使用僅具有允許其執行其工作所需的訪問許可權的服務帳戶，發現的任何漏洞都將導致資料被洩露， 這遠遠超出了無伺服器應用程式的範圍——這可能導致公關噩夢。另一個主要關注領域是應用程式中包含的任何第三方庫，這些第三方庫主要是為了提供增強功能，並節省開發團隊的開發時間。 比如用於驗證電話號碼或郵政編碼的庫，以及連線到外部PostgreSQL資料庫所需的JDBC驅動程式等客戶端庫。 如果不使用自動更新並定期掃描構建的工件的掃描工具，那麼在組織內針對所有第三方庫的監控所有各種漏洞公告列表的過程，將是一項巨大的手動工作。

容器安全

實際上，由於無伺服器應用程式通常在後臺執行在容器中，因此容器將承載與無伺服器相同的所有問題，以及容器為開發人員提供的附加功能的新問題。針對容器的特定安全問題可以簡化為兩個不同的區域：您基於部署的容器源的可信度，以及容器對主機作業系統的訪問級別。在任何主機（無論是Windows還是Linux）上執行容器時，不應使用root或管理員許可權執行容器。 使用名稱空間和卷等功能而不是原始磁碟訪問，允許這些容器守護程式在一個或多個容器之間共享儲存以獲取持久資料，而不需要容器本身具有升級的許可權。 甚至還有一些專案，例如谷歌的gVisor，它們更進一步，隱藏了除容器需要執行的確切系統呼叫之外的所有專案。對容器的更大關注是構建容器的層的可信度。 有多種方法可以解決這個問題。 它們包括指向您已經測試並確定的特定版本，而不是依賴於最新的tag。 您還可以擴充套件針對無伺服器應用程式中的第三方庫所進行的任何掃描範圍，以便掃描整個容器以查詢已知漏洞。 此掃描可以在容器源中提前執行，也可以在構建過程中執行，因為您將它們用作構建的基礎。

虛擬機器安全

虛擬機器是另一個需要解決的大問題。 有不少關於如何保護作業系統的書籍和最佳實踐指南。 甚至美國政府也有一個團體在NIST網站上釋出一些清單。 最近推出的作業系統提供了開箱即用的合理安全配置檔案，但它們總需要進行改進。一種改進upis的方法是將執行服務限制為絕對需要的服務。 例如，預設的HTTP伺服器很適合檢視日誌，但是當您的應用程式在Java中執行時，有不少可用的產品，哪些產品可以通過SSH連線並集中整合日誌？另一種選擇是在釋出後儘快應用補丁。 一些補丁每月釋出。 還有微軟的“Patch Tuesday”，而其他更關鍵的補丁在有可用修復的那天釋出（這些被稱為out-of-band patch）。 與容器和無伺服器不同，在完整虛擬機器上需要應用任何指定補丁的機率要高得多，因為需要和安裝的軟體包要多得多。

結論

只有瞭解您和您的開發團隊正在部署應用程式的計算環境型別，您才可能應用所有安全性最佳實踐。 理想情況下，您的每個應用程式都可以被評估，並且我們鼓勵您使用最合適和簡化的部署選項。 通過將更多應用程式遷移到容器，並在適當的時候使用無伺服器，它將使得類似生產的安全實踐能夠在開發週期的早期實施，並最終提高您的整體安全性。