一、引言

與當前正在使用的任何其他技術或方法一樣，微服務也有其自己的一套缺陷和問題。盡管如此，微服務架構的采用率不斷增加，預計到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. 可用性的斷路器模式

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

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

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

結論

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