Red Hat Enterprise Linux（RHEL）以穩定且一致的方式為應用程序提供全生命周期托管支持，極大簡(jiǎn)化了用例開(kāi)發(fā)體驗。而作為用戶(hù)，我們也應主動(dòng)積極如何在開(kāi)發(fā)中有效運用RHEL，以可預測且可重復的方式保證開(kāi)發(fā)成果在轉移至生產(chǎn)環(huán)境時(shí)不會(huì )發(fā)生任何意外。
近來(lái)，紅帽正式宣布將Red Hat Enterprise Linux （RHEL） 面向個(gè)人生產(chǎn)用戶(hù)以及部分符合特定要求的開(kāi)發(fā)者團隊免費開(kāi)放。這不僅給整個(gè)RHEL用戶(hù)社區帶來(lái)顛覆性變化，同時(shí)也讓之前只能使用下游或“重現版”RHEL的個(gè)人及開(kāi)發(fā)者真正獲得原汁原味的系統體驗。在本文中，我們一起聊聊RHEL給開(kāi)發(fā)者帶來(lái)的額外助益。
"簡(jiǎn)單來(lái)說(shuō)，免費RHEL才是RHEL。"這看著(zhù)像句廢話(huà)，但背后卻有不少潛臺詞。
多年以來(lái)，紅帽一直在公開(kāi)發(fā)布操作系統源代碼，且覆蓋范圍遠超GNU公共許可（GPL）等各類(lèi)開(kāi)源許可的要求。因此，其他各方可以使用這批寶貴的源代碼重構RHEL的各類(lèi)替代方案——CentOS Linux、Scientific Linux等就是典型代表。如果需要，開(kāi)發(fā)者及個(gè)人完全可以使用這些“重現版”系統構建應用程序，并確保開(kāi)發(fā)成果能夠在RHEL上穩定部署。但隨著(zhù)此次面向個(gè)人及開(kāi)發(fā)團隊的正式開(kāi)放，RHEL將可直接供大家用于構建應用程序、并免費在個(gè)人生產(chǎn)場(chǎng)景下進(jìn)行部署。
過(guò)去25年間，紅帽在與眾多客戶(hù)的交互當中積累起關(guān)于操作系統方案的廣泛運營(yíng)知識。經(jīng)過(guò)提煉，這些知識化為基于A(yíng)I/ML的云服務(wù)，即Red Hat Insights。Red Hat Insights能夠顯著(zhù)減輕RHEL帶來(lái)的管理負擔。而在此次RHEL全面免費之后，各合格開(kāi)發(fā)團隊及個(gè)人都能獲得Insights帶來(lái)的便利，其成果也將獲得相應的認證與技能資質(zhì)。
如果源代碼相同、又經(jīng)過(guò)RHEL認證，那么各衍生版本是否相當于同時(shí)得到了認證？
作為一家企業(yè)，紅帽投入了大量時(shí)間與資金才得以滿(mǎn)足各行業(yè)、國際與國內法規提出的認證與許可要求。具體要求往往與特定RHEL的二進(jìn)制版本或測試/驗證條件相關(guān)。在大多數情況下，無(wú)論是二進(jìn)制文件還是特定測試條件/結果都無(wú)法輕松重現，因此相關(guān)認證并不能直接適用于采用相同源代碼的其他衍生版本。而且除了源代碼之外，各同源操作系統之間還存在配置差異、庫差異與模塊差異，強行給予認證將缺乏現實(shí)意義。
但是，各版本間的源代碼還是相同的嗎？
只能說(shuō)大體相同，但二進(jìn)制文件會(huì )存在差別。這種差異源自構建過(guò)程、編譯器版本與配置選項，再加上對RHEL發(fā)行版做出的具體優(yōu)化——這一切都會(huì )給二進(jìn)制文件造成重大影響。紅帽投入了大量精力并配合強有力的流程，才維持起目前這套包含編譯器、工具與清潔底層架構的完整供應鏈。而這一切，都是為了在用戶(hù)群體內建立信心，證明紅帽核心操作系統穩定且值得信賴(lài)。
那么，認真進(jìn)行重構能不能解決問(wèn)題？
重構當然應該認真謹慎，但這里也要提醒大家，除非準確選取完全相同的編譯器版本、優(yōu)化與軟件包組合，否則二進(jìn)制文件必然會(huì )有所不同。例如，CentOS Linux包與RHEL包非常相似，但二者的編譯庫與可執行文件仍有區別。這就是相似，但不相同。這一點(diǎn)在認證方面非常重要，也是RHEL發(fā)布認證硬件、軟件與應用程序的根本原因。而新的開(kāi)發(fā)者計劃允許直接獲取RHEL二進(jìn)制文件，就是說(shuō)在需要投入生產(chǎn)或獲取支持時(shí)，能夠直接更新訂閱而不再重新安裝任何操作系統、應用程序或者其他組件。一切都已準備就緒，可以直接使用。
最近，GSA的FedRAMP項目也就此事對CentOS Linux做出重申。作為RHEL的下游衍生方案，CentOS Linux社區致力于對RHEL的加密模塊進(jìn)行重構與重新編譯。但是，CentOS上所運行的Red Hat加密模塊并未經(jīng)過(guò)FIPS-140驗證，因此FedRAMP無(wú)法在CentOS（包括CentOS 7）上對這些模塊做出FIPS-140驗證保證。
源代碼完全一致，二進(jìn)制文件也大差不差，能有什么問(wèn)題？
源代碼一致、二進(jìn)制文件相似，但配套的軟件包仍然不同——這非常重要。認證工作的核心，就是在兩種高度相似的二進(jìn)制文件之間找出兼容性差異。這事有點(diǎn)像照著(zhù)食譜做蛋糕——雖然每個(gè)人都能?chē)L試，但最終成品往往與食譜里的圖片相差甚遠。而認證則像是對實(shí)際成品的驗證，參照食譜但卻不限于食譜。在中立第三方的驗證之下，符合或優(yōu)于某些既有標準的方案就會(huì )贏(yíng)得用戶(hù)們的信任。但除非RHEL源代碼的各衍生重現版本也接受相同的認證過(guò)程，否則我們絕不能說(shuō)其屬于認證版本。
安全與信任緊密相關(guān)，其中二進(jìn)制文件的保障至關(guān)重要。下面來(lái)看幾個(gè)具體案例。美國國家標準與技術(shù)研究院（NIST）負責管理著(zhù)加密模塊驗證計劃（CMVP），此項計劃負責驗證模塊的二進(jìn)制文件是否符合聯(lián)邦信息處理標準140-2與140-3。提交至計劃的各加密模塊將經(jīng)過(guò)第三方的測試與審查，以驗證其是否符合既定FIPS標準。只有通過(guò)審查，我們才能斷言相關(guān)模塊擁有可靠的正確運行效果。
更重要的是，RHEL的多個(gè)發(fā)行版及庫都經(jīng)歷了這樣的驗證。
NIST將使用未經(jīng)驗證的密碼技術(shù)，視為未對信息或數據加以保護——換言之，視為將數據以未保護明文形式使用。如果機構稱(chēng)其信息或數據受到加密保護，則必須符合FIPS 140-2（有效期至2026年9月22日）或FIPS 140-3（自2020年9月22日起）。若需要使用加密技術(shù)，則必須進(jìn)行驗證。如果加密模塊未能通過(guò)審查，即代表不得使用該模塊。
大家當然可以不理FIPS驗證，但至少不能認定未經(jīng)驗證的加密模塊默認滿(mǎn)足FIPS要求。隨著(zhù)對供應鏈安全問(wèn)題的持續關(guān)注，安全管理者們越來(lái)越抗拒使用來(lái)自未知來(lái)源、也未經(jīng)過(guò)任何驗證的技術(shù)方案。
再來(lái)看一個(gè)例子。國防信息系統局（DISA）與供應商合作發(fā)布了針對各供應商產(chǎn)品的安全技術(shù)實(shí)施指南（STIG）。DISA還維護著(zhù)一套Linux/Unix STIG內容列表，RHEL在其中多次出現。美國國防部的多項計劃都曾針對STIG進(jìn)行全面的測試及/或操作，用以證明系統變更與配置切實(shí)符合安全控制要求。值得注意的是，指南中甚至明確禁止將STIG與某些衍生操作系統共同使用。也就是說(shuō)，RHEL STIG不適用于CentOS Linux，RHEL的安全測試結果只適用于RHEL自身。將測試結果直接推廣至衍生操作系統屬于一類(lèi)安全發(fā)現（CAT 1），即最高嚴重性級別。CAT 1問(wèn)題不存在爭議，必須立即處理。
RHEL向個(gè)人及開(kāi)發(fā)團隊的免費開(kāi)放實(shí)現了Red Hat技術(shù)儲備的真正大眾化推廣。RHEL Insights等衍生系統所不具備的成果將給希望簡(jiǎn)化運營(yíng)、并保持合規性水平的個(gè)人及團隊帶來(lái)巨大價(jià)值。當然，對于某些特定用例，此次免費開(kāi)放也可能沒(méi)有任何影響。總之，請大家務(wù)必明確區分認證與許可用例的區別，Red Hat免費開(kāi)放RHEL的意義也正在于此。衍生系統供應商當然可以主動(dòng)申請相同的認證與許可，但絕不能直接宣稱(chēng)RHEL認證也適用于他們的版本。
