保護你微服務架構安全的三個最佳實踐

　　最近，很多業務都是在作為獨立單元開發的單體應用程式上執行的。而對單體應用程式輕微調整都會影響整個過程並降低了執行速度。

　　例如，對一小部分程式碼進行編輯和修改需要開發和部署一個全新版本的應用程式。而且，如果擴充套件單體應用程式的一些特定功能，則必須擴充套件整個應用程式。

　　在過去的幾年，對微服務架構或微服務的需求已經成倍增長。由於企業對可用性、可擴充套件性和彈性的需求，微服務架構透過將單體系統分解為更小但可管理的獨立服務來解決單體系統帶來的挑戰。

　　這些以不同程式語言編寫的自治服務在它們自己的程式上執行。此外，這些可獨立部署的服務可以使用其他資料儲存介質，並使用與語言無關的協議進行通訊，以有效地執行任務。

　　本文揭示了圍繞微服務架構安全的一些誤區，指出了其面臨的安全挑戰，並提供瞭解決方案。此外，還提供了構建基於微服務的應用程式的三大優秀安全實踐。

　　 微服務架構的好處

　　微服務架構為企業提供了許多好處。但是，只有正確完成從單體式應用程式到微服務架構的遷移，才能獲得好處。其主要好處包括：

　　1.與單體架構不同，微服務架構讓企業可以專注於由團隊管理的較小但自主的服務，而不是將每個團隊的注意力轉移到一個更廣泛的應用程式上。

　　2.企業可以使用自己選擇的程式語言開發微服務，並按照自己的節奏獨立釋出和擴充套件。

　　3.單體架構提供更快的上市時間和更好的可擴充套件性。

　　4.它提供了更好的故障隔離，因為一個特定微服務中的錯誤可以在不影響架構其餘部分的情況下得到控制。

　　5.DevOps和敏捷團隊也受益於微服務。亞馬遜、Netflix、eBay、PayPal和Twitter等科技巨頭已經從單體架構遷移到微服務。

　　微服務架構規模在過去幾年中一直呈上升趨勢。2018年，全球微服務架構市場規模約為21億美元。此外，預計到2026年將超過80億美元，在預測期內複合年增長率(CAGR)將超過18%。

　　 微服務架構安全面臨的挑戰

　　實現一個微服務架構存在一些挑戰，該架構利用幾個具有不同技術、程式語言、工具和框架的小型獨立服務。

　　以下了解微服務架構中的一些主要安全挑戰：

　　 1.更大的攻擊面

　　微服務架構是多個服務的集合體，這些服務開放不同的埠，並開放多個應用程式程式設計介面(API)，從而增加了網路攻擊面，這帶來了嚴峻的安全挑戰。因此，所有微服務都應該得到充分保護，以克服這種安全威脅。

　　 2.隔離

　　在典型的微服務架構中，應用程式可以獨立開發、測試、擴充套件、部署和維護。這意味著這些活動中的任何一個都不應影響應用程式中其他微服務的工作。

　　為了增強程式的安全性，需要在資料庫級別實現隔離。換句話說，每個微服務必須擁有自己的資料副本，並且不應該讓它訪問應用程式中其他微服務的資料。而實現各層隔離使企業基於微服務的應用程式更加安全。

　　 3.傳統日誌記錄

　　基於微服務的應用程式通常具有無狀態、分散式和獨立的服務，這些服務是使用跨越地理邊界的多種技術開發的。因此，在基於微服務的應用程式中，單體應用程式中相同的傳統日誌記錄是無效的。與其相反，應用程式應該聚合日誌，並跨多個平臺和服務關聯事件，以實現有效的日誌記錄。

　　 4.DevOps團隊的協作

　　透過獨立開發、部署和管理服務來建立應用程式是有好處的，但是當它們在沒有經過全面測試的情況下發布時，安全漏洞就會增加。基於微服務的應用程式雖然可以頻繁地釋出，但這種改進的敏捷性是以犧牲安全性為代價的。

　　為了應對微服務架構安全問題，DevOps團隊之間的更密切協作對於企業至關重要。他們應該密切互動，對流程有很好的理解，並減輕安全威脅。此外，他們的協作必須在開發、安全和運營(DevSecOps)生態系統中進行，以防止未經授權訪問應用程式中的任何資源。

　　 5.容錯

　　在一個或多個元件發生故障的情況下，應用程式仍然可以正常工作的能力稱為容錯。它通常是透過設定像斷路器模式這樣的後備機制來完成的。然而，在基於微服務的應用程式中實現容錯是一項具有挑戰性的工作。有時，其實現變得比單一應用程式更復雜、更具挑戰性。

　　微服務架構擁有更多的服務並處理更多的請求。當大量服務透過網路進行通訊時，就會增加複雜性。此外，微服務架構應該是容錯的，這意味著它應該處理服務故障，因為頻繁的服務故障會破壞整個應用程式的穩定性。

　　 微服務架構中的三個安全實踐

　　在瞭解微服務架構面臨的安全挑戰之外，以下了解一些安全實踐：

　　 1.縱深防禦(DiD)策略

　　縱深防禦策略可以為應用程式新增許多安全層，也可以用來保護基本服務。因此，網路攻擊者成功利用微服務一個安全漏洞並不能保證能夠利用另一個安全漏洞。換句話說，如果網路攻擊者已經成功攻擊了基於微服務的應用程式中的一層保護，那麼破壞其他的應用程式安全層可能並不容易。

　　 2.API閘道器

　　在典型的基於微服務的應用程式中，使用者無法與微服務直接通訊。API閘道器擁有通往各種微服務的單一入口點，而這種機制不允許使用者直接訪問和使用服務。

　　企業應將API閘道器置於防火牆後面，以便在網路攻擊面新增一層保護。它還有助於保護在應用程式中使用的每個微服務。通常情況下，基於令牌的身份驗證用於保護API閘道器。

　　 3.API和資料安全

　　在典型的基於微服務的應用程式中，服務應該相互通訊，並且應該在不影響應用程式效能的情況下保護資料。為此，應該正確地維護安全證書以及加密和保護傳輸中的資料。

　　應透過僅允許授權使用者訪問來保護API。企業還可以利用對資源的受限訪問，這意味著只有在需要時才提供對資源的訪問。

　　 制定微服務安全策略

　　在典型的單體架構中，安全問題不那麼重要，但在安全性是一個複雜挑戰的微服務生態系統中，同樣的方法不起作用。例如，保護企業資料和應用程式的標準防火牆不能滿足基於微服務應用程式的安全需求。事實上，需要強大的防禦機制來對抗安全威脅。

　　因此，企業應制定安全策略來應對這些挑戰。應實施自動化以監控應用程式和潛在的安全威脅。除此之外，還應該部署一個集中的安全系統和工具來有效地監控基於微服務的應用程式。因此，建議企業採用頻繁更新的自動程式碼掃描和安全程式碼保護以加強安全性。

　　原文連結：https://www.itbusinessedge.com/it-management/securing-microservices-architecture/