引言

與當前正在使用的任何其他技術或方法一樣，微服務也有其自己的一套缺陷和問題。儘管如此，微服務架構的採用率不斷增加，預計到 2028 年將達到 1718.2 億美元。

然而，儘管團隊使用微服務，但確保這些微服務的安全性仍然被視爲事後事項。 這可能導致應用程序中的許多安全問題，甚至可能使用戶數據面臨風險，甚至導致應用程序停機。因此，讓我們看看在 2024 年保護微服務的前 10 種方法！

微服務架構的常見威脅是什麼？

在深入研究保護微服務之前，瞭解可能使您基於微服務的應用程序面臨風險的威脅是很重要的。

1. 濫用有缺陷的身份驗證和授權

攻擊者獲取對基於微服務的應用程序的訪問權限的主要原因是身份驗證和訪問策略的配置錯誤。這些策略和機制的配置錯誤將是災難性的，因爲它可能暴露敏感信息，甚至讓攻擊者通過執行遠程代碼來獲得對系統的訪問權限。

2. 基於 API 的攻擊

在微服務架構中，API 安全性的重要性是毫無爭議的，因爲每個組件都與 API 相互連接；此外，當 OWASP 提出其自己的十大最常見問題清單時，您就知道這個方面有多重要。

攻擊者通常通過身份驗證和有效載荷處理配置錯誤來利用 API 端點，通過操縱有效載荷繞過可能已經設置的任何驗證。

3. DDoS 和 DoS 攻擊

在適當的控制措施缺失的情況下，沒有人免疫拒絕服務攻擊。

這是我們必須接受的現實，因爲任何人都可以輕鬆獲取提供 DDoS 服務的服務，價格低至每天 $30，具體取決於攻擊的規模和持續時間。 當您的基於微服務的應用程序可能能夠擴展以抵抗 DDoS 或 DoS 攻擊以保持其服務運行時；

真正的問題是以何種代價？ 在 DDoS 或 DoS 攻擊期間，微服務的擴展將對成本產生重大影響，因爲即使使用諸如 AWS Lambda 等無服務器解決方案，計算資源也不便宜。

保護微服務的策略

既然我們已經確認了即使微服務也會受到攻擊，並且這只是一個 “何時” 的問題。

讓我們看看一些策略，我們可以實施以減少攻擊可能帶來的影響。

1. 安全設計

顧名思義，安全設計或左移安全性意味着安全性必須從設計階段考慮，並必須在整個開發生命週期中應用。這可能不是微服務特有的概念，但由於它帶來的顯著好處，必須遵循此概念。

如果您目前正在實踐 DevSecOps，那麼

您很可能正在遵循左移或安全設計原則，在這裏您在每個開發階段都考慮安全性。這不僅有助於在非常早期階段識別威脅和安全問題，而且由於整個體系結構可以被設計爲以最小的努力解決安全問題，因此還可以減少修復這些問題所需的工作量。

2. 零信任架構

這些架構設計對網絡安全領域並不陌生，多年來我們已經看到其採用率穩步增長。這將我們多年來一直在使用的多種安全技術組合成一個強大的設計，能夠減少甚至是最複雜應用程序的攻擊面。

零信任基於一些共同的關鍵原則，這些原則共同發揮作用，形成了最安全的應用程序部署；其中一些原則是：

• 最小特權 • 持續監控和驗證 • 設備訪問控制 • 微分割

由於微服務獨立於其他服務，這種方法非常適合確保即使一個微服務被攻破，攻擊者也無法危及應用程序的其餘部分。

3. 訪問控制（IAM）

安全性的最重要方面之一是訪問控制，甚至是零信任架構背後的關鍵原則之一，該架構要求僅爲任何給定實體分配最小特權。

將有多個用戶，如果沒有多個賬戶用於允許每個微服務與其他微服務或其他服務（如數據庫）進行通信。在這些部署中，必須分配最小數量的訪問權限，以允許微服務執行定義的任務。

此外，如果您使用諸如 AWS Lambda 之類的解決方案，則建議使用短壽命的憑證，例如 “角色”，這樣用戶帳戶必須假定角色才能執行任務，沒有此角色將沒有任何本機權限。

4. 威脅建模

您可能知道您的微服務在應用程序構建到小規模時做什麼，但是一旦您的應用程序增長並且您的微服務數量失控增長時，所有這些都會發生變化！很快，您將不知道做什麼以及理解的任何意義都開始消失。

一旦發生這種情況，您將很可能在架構和微服務內留下未計劃的空白，這些空白允許攻擊者進入。

這就是威脅建模派上用場的地方，它允許考慮系統的數據流、服務間通信和外部威脅等多個方面。

威脅建模使架構師能夠可視化和識別體系結構中存在的各種問題，並確保在構建應用程序之前修復了已識別的風險，從而節省了在開發和測試階段所花費的大量金錢和時間。

5. 漏洞管理

我們已經確認微服務運行在不同的語言上，並在單個微服務中有多個組件來啓用其功能。

漏洞管理是一種被忽視的方法，允許工程師和管理員識別和修補這些不同組件，無論是容器基礎架構、代碼還是甚至是使用的第三方庫。

正確的漏洞和補丁管理不僅能夠實現安全應用程序，而且能夠實現嚴格的合規性。

6. 事件響應

這是沒有人願意考慮的事情，因爲每個人都忙於保護他們的應用程序。時代已經改變了，規劃一個合適的事件響應可以幫助您的應用程序從攻擊中恢復。

這是因爲現在不再是如果您的應用程序受到攻擊，而是 WHEN 它將受到攻擊，擁有適當的事件響應程序將有助於準備您的應用程序和團隊更好地應對特定類型的攻擊。

擁有詳細的事件響應手冊還可以幫助發展您的微服務設計，因爲從中學到的經驗可以直接納入應用程序的設計中。

7. 密鑰管理

複雜的應用程序可能有數百甚至數千個微服務協同工作，這些功能可能需要使用 API 密鑰、密碼和其他形式的密鑰以進行身份驗證。

在應用程序中管理數百個密鑰變得很麻煩，當您需要安全地存儲、使用並輪換每個密鑰時，就更是如此。這通常是當開發人員變懶

，將這些密鑰硬編碼到源代碼中或將它們存儲在配置文件中時。將密鑰以明文形式存儲是一場災難，攻擊者可以簡單地讀取源代碼或純文本並檢索這些密鑰。

推薦的密鑰管理方法是將所有密鑰存儲在安全的保險庫中，例如 HashiCorp Vault、AWS Secrets Manager 或 AWS Systems Manager Parameter Store。這些解決方案使開發人員能夠安全地存儲並根據需要檢索他們的密鑰，而無需將它們硬編碼到源代碼中，甚至存儲在配置文件中。

8. 容器安全性

當您在保護微服務架構的所有其他方面時，一個關鍵組件經常被忽視。這是運行所有微服務的組件，在大多數情況下這些是容器！

確保您的容器基礎架構得到安全保護與確保微服務本身的安全性同樣重要，因爲容器安全性中的漏洞可能使攻擊者能夠進入基礎架構並從底層破壞應用程序。

因此，關注關鍵的安全方面，如但不限於容器鏡像、運行時、註冊表、網絡和運行時安全性，至關重要。

此外，關注供應商特定組件，如 Kubernetes Pod Security，確保它們根據規範進行加固，這也將增加您在容器環境中的安全性。

9. 服務網格

這個專用的基礎架構層添加到您的微服務架構之上，允許您控制微服務之間的通信。該層引入了關鍵組件，如：

• 邊車 • 服務發現 • 負載均衡 • 流量管理 • 安全策略 • 可觀察性和分佈式跟蹤

所有這些組件在提供對應用程序中流動數據更多控制方面發揮着至關重要的作用。

10. 可用性的斷路器模式

保護微服務架構不僅意味着加固各個組件，還要使架構能夠在攻擊或可能出現的其他操作問題期間處理故障和錯誤。

斷路器模式的概念使應用程序能夠將特定微服務與應用程序的其餘部分隔離開來，如果連續發生故障，這種隔離可以使應用程序的一部分（取決於哪個微服務有問題）能夠正常運行，但也可以防止資源枯竭。

此外，應用程序將能夠確定故障的微服務是否已恢復，通過優雅地嘗試向先前有問題的微服務發送請求並監視其響應，而不會強制整個負載到它，這可能會導致服務再次失敗。

結論

保護微服務並非總是一帆風順，需要一些計劃。然而，通過正確的技術、工具和程序的組合，您的基於微服務的應用程序可以更安全、更有抵抗力地抵禦攻擊。

希望您找到這篇文章有幫助。

感謝您的閱讀！

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/33MBL812HqS-Gh_ZLjDGKg