快连VPN:速度和安全性最佳的VPN服务
產品和基礎設施工程團隊的利益與安全工程團隊的利益時常不一致。安全的價值不像業務價值或實用解決方案那樣直接可見，因此很難讓人理解在事故發生前投入資金或努力是值得的。然而，宣傳具有商業價值的安全解決方案比採用傳統的發現漏洞、實施補救措施和通過案例管理進行跟進的循環更有效。例如，使用基於 oauth 和 iam 的訪問代替靜態密鑰，使用加密代替更精細的訪問控制，這些都可以顯著簡化基礎架構、降低複雜性並減輕運營負擔，這對產品和平臺工程團隊都極具吸引力。
產品和基礎設施工程團隊的利益並不總是與安全工程團隊的利益一致。雖然產品和基礎設施專注於推動業務價值和提供實用解決方案，但安全側重於檢測、預防和補救，這些似乎沒有那麼直接的價值。就像保險單一樣，如果還沒有發生事故，就很難看出它爲什麼值得花錢或付出努力。
我發現，與傳統的發現漏洞、實施補救措施和通過案例管理進行跟進的循環相比，倡導能夠帶來商業價值的安全解決方案更爲有效。例如，使用基於 OAuth 和 IAM 的訪問代替靜態密鑰，使用加密代替更精細的訪問控制可以顯著簡化基礎架構、降低複雜性並減輕運營負擔，這對產品和平臺工程團隊都非常有吸引力。
示例：使用基於 IAM 的 OAuth 替換靜態密鑰
傳統上，系統之間的訪問是通過靜態密鑰對實現的。這種方法雖然很常見，但由於管理密鑰生成、輪換和應用程序生命週期的複雜性，往往會導致可靠性問題。平臺團隊還必須投入大量精力來監控和檢測異常，以防止意外的密鑰泄露，例如通過 Slack 或 GitHub 意外泄露。即使開發人員報告並補救泄漏，輪換過程也可能很費力。更糟糕的是，開發人員可能認爲這是低風險泄漏，因此泄漏可能不會被報告。
平臺團隊有兩種選擇：
添加更復雜的訪問控制和批准流程。
用基於 IAM 的 OAuth 替換靜態密鑰對。
第一種選擇可能很誘人，因爲它只需添加 ServiceNow 等供應商，而無需做太多額外工作。然而，第二種選擇雖然需要更多的實施變更，但更安全，並減少了應用程序團隊更新機密、重啓 Pod 和確保機密被獲取的運營負擔。事實上，最近出現了幾家專注於非人類身份驗證的公司，如 P0 和 Clutch，突顯了更安全、更高效的身份驗證方法日益流行的趨勢。
這個例子展示瞭如何通過不同的安全實施方法提高安全標準、簡化基礎設施架構、提高整體開發速度。
數據加密案例
數據加密是另一個例子，雖然安全團隊不能簡單地“添加供應商”，但從安全和架構設計的角度來看，它大大降低了所有平臺的複雜性和實施工作量。
典型的數據流包括：
源應用程序發佈數據
數據被髮送到傳輸層（例如 Kafka、Kinesis）
數據存儲在數據庫（MySQL、Postgres）、數據倉庫（Redshift、Snowflake）或數據湖（S3、Databricks）中
不同的解決方案對“訪問控制”的理解和實現方式不同，導致平臺團隊各自實現不同的版本，這往往導致公司內部實現方式的碎片化。對於安全工程師來說，實現方式越碎片化，就越難實現標準化的治理、控制和監控，最終導致系統安全性下降。
基礎設施/供應商授權和權限比較
| 平臺 | 基於 IAM 的身份驗證 | 行/列權限 |
|---|---|---|
| 數據塊 | 支持基於 IAM 的權限 | 支持行和列級安全性 |
| 雪花 | 本身不支持基於 IAM 的權限 | 支持行和列級安全性 |
| MySQL | 不支持基於 IAM 的權限 | 通過授權和策略支持行級和列級安全性 |
| PostgreSQL | 不支持基於 IAM 的權限 | 支持行和列級安全性 |
結論
藉助數據加密，只需使用加密密鑰配置一次訪問權限，然後就可以將其分配給數據流不同階段的各個工作負載。這大大降低了在不同平臺上實施和協調權限策略的複雜性。加密可確保數據在所有平臺上受到一致保護，從而簡化治理和控制，同時增強整體安全性。
以上就是數據加密如何簡化基礎設施架構的詳細內容，更多請關注本站其它相關文章！
