就在30多年前，虛擬化僅適用于擁有大型機和大型小型計算機的用戶，而安全問題僅僅存在于物理計算機中;20年前，VMware發布了其第一款產品，網絡邊界安全性仍處于起步階段，依賴于防火墻;12年前，AWS推出，網絡安全成為一個問題;5年前，由于Docker容器成為主流，主機安全成為焦點。今天，隨著無服務器安全性的增長，應用程序級安全性終于受到計算和網絡層的挑戰。

[[241449]]

應用程序級安全性受到計算和網絡層的挑戰

隨著應用程序，計算和網絡安全都被審計，通過SOC類型等報告，管理層和客戶端都可以更加了解安全問題。隨著客戶端透明度的提高，安全專業人員是確保部署資產的關鍵生產更加具有堅實的安全性，并且根據正在使用的部署類型，此配置文件的大小可能會增加。這就是理解不同類型即容器，無服務器計算和虛擬機之間的安全細微差別的原因。下面，我們將比較他們的安全差異。

無服務器安全性

首先，我們先討論無服務器安全性問題，因為無服務器應用程序通常是純粹執行單個函數的代碼，因此被稱為函數即服務。除了遵循安全編碼最佳實踐，例如僅返回處理請求絕對需要的數據，并讓應用程序使用僅具有允許其完成工作所需的訪問權限的服務帳戶，任何發現的漏洞都將導致數據被泄露的東西遠遠超出了無服務器應用程序的范圍。

另一個主要關注領域是應用程序中包含的任何第三方庫，以提供增強功能，并節省開發團隊的開發時間。第三方庫的示例包括用于驗證電話號碼或郵政編碼的庫，以及連接到外部PostgreSQL數據庫所需的JDBC驅動程序等客戶端庫。如果不使用自動更新并定期掃描構建的工件的掃描工具，那么在組織內使用的所有第三方庫以及觀察所有各種漏洞公告列表的過程中，這是一項巨大的手動工作。

容器的安全性

從本質上講，無服務器應用程序通常在后臺運行在容器中，因此容器將承載與無服務器相同的所有問題，以及容器為開發人員提供的附加功能的新問題。特定于容器的安全問題可以簡化為兩個不同的區域：基于部署的容器的源的可信度，以及容器對主機操作系統的訪問級別。

在任何主機(無論是Windows還是Linux)上運行容器時，不應使用root或管理員權限運行容器。使用命名空間和卷等功能而不是原始磁盤訪問允許這些容器守護程序在一個或多個容器之間共享存儲以獲取持久數據，而不需要容器本身具有升級的權限。甚至還有一些項目，例如谷歌的gVisor，它們更進一步，隱藏了除容器需要運行的確切系統調用之外的所有項目。

對容器的更大關注是構建容器的層的可信度。有多種方法可以解決這個問題。它們包括指向您已經測試并確定的特定版本，而不是依賴于最新的標記。您還可以擴展針對無服務器應用程序中的第三方庫所進行的任何掃描范圍，以便掃描整個容器以查找已知漏洞。此掃描可以在源注冊表中提前執行，也可以在構建過程中執行，因為可以將它們用作構建的基礎。

虛擬機安全

虛擬機是另一個需要解決的問題的集合。一種改進upis的方法是將運行服務限制為絕對需要的服務。例如，默認的HTTP服務器很適合查看日志，但是當應用程序在Java中運行時，可以看到是否需要可用的產品，哪些產品可以通過SSH連接并集中整合日志;另一種選擇是在發布后盡快應用補丁，一些補丁每月發布，包括微軟的“ 補丁星期二 ”，而其他更關鍵的補丁在有可用修復的那天發布(這些被稱為帶外補丁)。與容器和無服務器不同，在完整虛擬機上需要應用任何給定補丁的幾率要高得多，因為需要和安裝的軟件包要多得多。

總結

通過了解開發團隊正在部署應用程序的計算環境類型，以及最有可能應用所有安全性的最佳實踐。理想情況下，安全投資中的每個應用程序都可以并且將被評估，也希望你能使用最合適和簡化的部署選項。通過將更多應用程序移動到容器，并在適當的時候無服務器，它將使得類似生產的安全實踐能夠在開發周期的早期實施，并最終提高企業的整體安全性。