了解如何利用數據加密功能來改進安全標準、簡化基礎架構并提高開發人員的速度。

　　產品和基礎設施工程團隊并不總是與安全工程團隊的利益保持一致。當產品和基礎設施專注于驅動業務價值和交付實用的解決方案時，安全性專注于檢測、預防和補救，這些似乎沒有立即的價值。就像保險單一樣，在還沒有發生事故的情況下，為什么它值得花錢或付出努力，這并不是很明顯。

　　與傳統的識別漏洞、應用補救和通過案例管理跟蹤的循環不同，我發現倡導同時提供業務價值的安全解決方案要有效得多。例如，使用基于OAuth和Iam的訪問而不是靜態密鑰和加密，而不是更細粒度的訪問控制，可以顯著簡化基礎設施，降低復雜性，減輕操作負擔，使它們對產品和平臺工程團隊都非常有吸引力。

　　示例:將靜態密鑰替換為基于Iam的OAuth

　　傳統上，系統之間的訪問是通過靜態密鑰對實現的。雖然很常見，但由于管理密鑰生成、輪換和應用程序生命周期的復雜性，這種方法經常導致可靠性問題。平臺團隊還必須投入大量精力來監控和檢測異常情況，以防止意外的密鑰泄露，例如通過Slack或GitHub意外暴露。即使開發人員報告并修復泄漏，輪換過程也會很費力。更糟糕的是，開發人員可能會認為這是一個低風險的泄漏，并且泄漏可能不會被報告。

　　根據ISO/IEC27001:2022.A.9.1：

　　組織必須實施政策和程序來控制對信息的訪問，確保只有那些有合法需求的人才能訪問信息。

　　平臺團隊有兩種選擇：

　　(1)添加更復雜的訪問控制和審批流程。

　　(2)用基于Iam的OAuth替換靜態密鑰-秘密對。

　　第一種選擇可能很誘人，因為它只需要添加一個像ServiceNow這樣的供應商，而不需要額外的工作。然而，第二種選擇雖然需要更多的實現更改，但更安全，并且減少了應用程序團隊更新秘密、重新啟動pod和確保秘密被提取的操作負擔。事實上，最近出現了幾家專注于非人類身份認證的公司，如P0和Clutch，突顯了更安全和高效的認證方法的發展趨勢。

　　這個示例演示了一種不同的安全實現方法如何改進安全標準、簡化基礎設施體系結構并提高開發人員的總體速度。

　　數據加密的案例

　　數據加密是另一個例子，盡管安全團隊不能簡單地添加一個供應商，但從安全性和體系結構設計的角度來看，它顯著降低了所有平臺的復雜性和實現工作。

　　典型的數據流包括:

　　源應用發布數據

　　數據被發送到傳輸層(例如，Kafka,Kinesis)

　　數據存儲在數據庫(MySQL,Postgres)，數據倉庫(Redshift,Snowflake)或數據湖(S3.Databricks)中。

　　不同的解決方案對“訪問控制”有不同的解釋和實現，導致平臺團隊實現他們自己的版本。這通常會導致整個公司出現碎片化的實現。對于安全工程師來說，實現越分散，實現標準化的治理、控制和監視就越困難，最終使系統不那么安全。

　　結論

　　使用數據加密，只需使用加密密鑰配置一次訪問權限，然后就可以在數據流的不同階段將其分配給各個工作負載。這大大降低了跨不同平臺實現和調整權限策略所涉及的復雜性。加密確保數據在所有平臺上得到一致的保護，簡化了治理和控制，同時增強了整體安全性。