了解如何利用數(shù)據(jù)加密功能來改進安全標準、簡化基礎(chǔ)架構(gòu)并提高開發(fā)人員的速度。

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

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

　　示例:將靜態(tài)密鑰替換為基于Iam的OAuth

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

　　根據(jù)ISO/IEC27001:2022.A.9.1：

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

　　平臺團隊有兩種選擇：

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

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

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

　　這個示例演示了一種不同的安全實現(xiàn)方法如何改進安全標準、簡化基礎(chǔ)設(shè)施體系結(jié)構(gòu)并提高開發(fā)人員的總體速度。

　　數(shù)據(jù)加密的案例

　　數(shù)據(jù)加密是另一個例子，盡管安全團隊不能簡單地添加一個供應(yīng)商，但從安全性和體系結(jié)構(gòu)設(shè)計的角度來看，它顯著降低了所有平臺的復(fù)雜性和實現(xiàn)工作。

　　典型的數(shù)據(jù)流包括:

　　源應(yīng)用發(fā)布數(shù)據(jù)

　　數(shù)據(jù)被發(fā)送到傳輸層(例如，Kafka,Kinesis)

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

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

　　結(jié)論

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