解決可用性與安全性，IT 中的持續沖突
沖突的業務需求是一個常見問題——您可以在組織的每個角落找到它，包括在信息技術領域。解決這些沖突是必須的，但這并不總是那么容易——盡管有時有一種新的解決方案會有所幫助。
在 IT 管理中，安全團隊和運營團隊之間一直存在斗爭。是的，兩個團隊最終都希望擁有更難被破壞的安全系統。然而，安全性可能以犧牲可用性為代價——反之亦然。在本文中，我們將研究可用性與安全性沖突，以及有助于解決該沖突的解決方案。
運營團隊專注于可用性……安全團隊鎖定
運營團隊將始終將穩定性和可用性作為重中之重。是的，運維團隊也會將安全作為優先事項，但僅限于涉及穩定性或可用性，而不是絕對目標。
它實現了“五個九”的正常運行時間目標，該目標設定了一個令人難以置信的高要求——系統正在運行并且可以在 99.999% 的時間內為請求提供服務。這是一個值得稱道的目標，讓利益相關者感到高興。高可用性等工具通過提供系統或服務級別冗余來提供幫助，但安全目標可能會很快阻礙實現“五個九”。
對于安全團隊來說，最終目標是盡可能鎖定系統，將攻擊面和整體風險級別降至最低。在實踐中，安全團隊可以要求系統必須立即關閉以進行修補，而不是從現在起兩周后，降低可用性以便立即進行修補——不管對用戶造成什么后果。
很容易看出，這種方法會給運維團隊帶來巨大的頭痛。更糟糕的是，高可用性確實幫助運營團隊實現了他們的可用性和穩定性目標，它實際上會讓安全團隊變得更糟，他們現在必須處理成倍增長的服務器或服務，所有這些都需要保護和監控。
遵循哪種最佳實踐？
它在操作和安全之間造成了沖突，這意味著這兩個小組在最佳實踐和流程等主題上很快就會出現分歧。在考慮修補時，基于維護窗口的修補策略將減少中斷并提高可用性，因為修補工作和相關的停機時間之間存在數周的延遲。
但是有一個問題：維護窗口的修補速度不足以正確防御新出現的威脅，因為這些威脅通常在披露后的幾分鐘內（甚至在披露之前，例如 Log4j）就被積極利用。
這個問題發生在所有類型的工作負載中，無論您是使用最新的 DevOps、DevSecOps 還是任何一種運維方法都沒有關系。最終，您要么以犧牲可用性或性能為代價更快地為安全操作打補丁，要么以更慢的速度打補丁并承擔不可接受的安全風險。
它很快變得非常復雜
決定修補的速度只是開始。有時，修補并不簡單。例如，您可能正在處理編程語言級別的漏洞——這反過來會影響使用該語言編寫的應用程序，例如CVE-2022-31626，一個 PHP 漏洞。
發生這種情況時，還有另一組參與可用性與安全性沖突：需要分兩步處理語言級漏洞的開發人員。首先，通過更新有問題的語言版本，這是容易的部分。
但是更新語言版本帶來的不僅僅是安全性改進；它還帶來了其他根本性的變化。這就是為什么開發人員需要進行第二步：補償重寫應用程序代碼帶來的語言級別的變化。
這也意味著在某些情況下需要重新測試甚至重新認證。就像希望避免與重啟相關的停機時間的運維團隊一樣，開發人員確實希望盡可能長時間地避免大量的代碼編輯，因為這意味著主要的工作，是的，可以確保更嚴格的安全性——但否則會使開發人員無所適從.
過程崩潰
您可以輕松了解為什么當前的補丁管理流程會導致團隊之間出現多層次的沖突。自上而下的政策可以在一定程度上解決問題，但這通常意味著沒有人對結果感到真正滿意。
更糟糕的是，這些策略通常會使系統長時間不打補丁而危及安全。每周或每月修補系統，認為風險是可以接受的，在當前的威脅級別上，遲早會導致清醒的現實檢查。
有一種方法可以顯著減輕甚至解決立即修補（和中斷）和延遲修補（和安全漏洞）之間的沖突。答案在于無中斷和無摩擦的修補，在每個級別或至少與實際一樣多的級別。
無摩擦修補可以解決沖突
實時修補是您的安全團隊應該注意的無摩擦修補工具。多虧了實時修補，您的修補速度比常規維護窗口所希望的要快得多，并且永遠不需要重新啟動服務來應用更新。快速安全的修補，幾乎沒有停機時間。一種解決可用性和安全性沖突的簡單有效的方法。
在TuxCare，我們為關鍵的 Linux 系統組件提供全面的實時補丁，以及針對多種編程語言和編程語言版本的補丁，這些補丁專注于安全問題，并且不會引入任何語言級別的更改，否則會強制代碼重構 - 您的代碼將繼續運行 -是，只有安全。即使您的業務依賴于不受支持的應用程序，您也不必擔心漏洞會通過編程語言缺陷滲入您的系統——您也不需要更新應用程序代碼。
因此，總而言之，在可用性與安全性沖突中，實時修補是一種可以顯著減少運營和安全團隊之間緊張關系的工具。
