我有一個應用程式將用于處理一些高度敏感的檔案。
目的是通過我的應用程式將這些檔案上傳到 S3。這些檔案也只會根據需要由我的應用程式檢索。
正如我一直在閱讀的那樣，S3 提供服務器端加密 (SSE)，其中資料在上傳/下載時分別進行透明加密和解密。
在這種情況下，這似乎是我對 S3 存盤桶所做的任何錯誤配置，或者如果我的 AWS 憑證遭到破壞，攻擊者將可以訪問我在 S3 中的所有敏感資料。我知道我應該確保不會錯誤配置 S3 并保護我的憑據，但我也知道事情會發生。
基本上，據我所知，服務器端加密實際上是一個“勾選框”型別選項，它允許您說您有靜態加密，但不能保護您免受最常見的 S3 資料泄漏（存盤桶配置錯誤和信用受損）。
切入正題，客戶端加密似乎是我最好的選擇。也就是說，我還沒有讀過很多關于在整個資料生命周期中管理用于在客戶端加密我的資料的密鑰的好選擇。
我的問題是
- 我是否正確理解服務器端加密？
- 客戶端會是我最安全的選擇嗎？
- 在使用客戶端加密時，您建議使用哪些策略/工具來管理密鑰？
uj5u.com熱心網友回復：
域名注冊地址：
CSE 實際上是在 S3 中存盤資料的最安全方式，前提是您可以保證您的密鑰安全。
使用 CSE，亞馬遜自己可以保證永遠無法訪問私鑰，而不是 SSE，并且無法在任何時間查看/共享您的資料，例如當被迫通過傳票時。
出于教育目的，理論上最安全的方式是 CSE SSE-KMS 的 2 層組合加密。這應該只在極端情況下使用，但它最終是在 S3 中存盤資料的最安全的方式。
CSE SSE-S3 也不會造成任何傷害，因為 SSE-S3 是免費的。
更深入的解釋：
我是否正確理解服務器端加密？
是的，服務器端加密 (SSE) 允許您進行靜態加密。
但是，使用 SSE 并不一定意味著您無法避免存盤桶配置錯誤或信用受損。
SSE有3種型別。
它們都有一個共同點，即資料的加密和解密都由 AWS 管理：
- SSE-S3：使用 S3 管理的密鑰進行服務器端加密
- SSE-KMS：使用存盤在 AWS KMS 中的 KMS 密鑰進行服務器端加密
- SSE-C：使用客戶提供的加密密鑰進行 S3 服務器端加密
SSE-S3
? 防止物理訪問
? 防止存盤桶錯誤配置
? 防止憑據泄露
? AWS 在任何情況下都無法查看您的資料
SSE-S3 至少可以確保，如果有人從存盤有您資料的 AWS 資料中心中取出硬碟驅動器，您的資料將被加密。
任何s3:GetObject有權訪問您的物件的IAM 委托人都能夠讀取您未加密的物件，因此如果可以訪問該物件的 AWS 憑證被泄露，任何惡意行為者都將能夠訪問您檔案的解密版本。
使用 SSE-S3 意味著 - 是的，如果您的存盤桶配置錯誤或憑據泄露，惡意行為者可以訪問您未加密的資料。
但它不是為了保護你。
在實踐中，更重要的是允許 AWS 遵守安全合規性認證并防止濫用 Amazon 的內部網路和/或對物理 S3 基礎設施的人身安全（盡管這種情況極為罕見）。
使用 SSE-S3 的成本為 0.00 英鎊，任何加密都比沒有好。
知識管理系統
? 防止物理訪問
? 防止存盤桶錯誤配置
? 防止憑據泄露
? AWS 在任何情況下都無法查看您的資料
使用 SSE-KMS，您有一層額外的保護 - KMS 密鑰 - 以防您早上醒來并隨機決定向全世界打開您的存盤桶。
它要求任何想要讀取或寫入物件的惡意行為者都可以訪問物件和密鑰。您必須錯誤配置 S3 權限和 KMS 密鑰權限才能意外授予訪問權限，而不僅僅是 SSE-S3 中的 S3 權限。
此選項雖然不是免費的，但可以防止存盤桶配置錯誤，但不會損壞信用。
您的存盤桶可以打開，但所有無法訪問 KMS 密鑰的人都會被加密。
僅供參考：AWS KMS 的設計使得包括 AWS 員工在內的任何人都無法從該服務中檢索您的明文密鑰。
上證所
? Protects against physical access
? Protects against bucket misconfiguration
? Protects against leaked credentials
? AWS cannot view your data in any circumstance1
SSE-C protects against bucket misconfiguration & compromised AWS creds.
You manage your own keys & S3 manages the encryption and decryption process. You do need to provide an encryption key as part of your request, but you don’t need to write any code to perform object encryption or decryption.
In this case, nobody has the key to unlock the files other than you.
Your bucket could be open to anyone & your credentials could be leaked for anyone to be able to get an object. But if you're the only one with the key needed for unlocking the file, all anyone could get is encrypted gibberish.
While this SSE option keeps you safe against bucket misconfiguration & compromised creds, you're now also responsible for securing your creds, bucket and your key (which is arguably a larger attack vector).
1 Technically, Amazon has had access to your key at some point as you've sent it to them but according to the docs, Amazon S3 does not store the encryption key you provide. Obviously, S3 source code is not open source and we cannot 100% guarantee this. I would be very surprised if AWS was lying as it would affect their reputation but for the sake of correctness, I will mark this down as uncertain.
Would client-side be my most secure option?
? Protects against physical access
? Protects against bucket misconfiguration
? Protects against leaked credentials
? AWS cannot view your data in any circumstance
Client-side encryption (CSE) would be more "secure" than SSE for S3 storage in that you manage everything. You manage the encryption process, the encryption keys, and related tools as opposed to AWS doing it.
You are encrypting objects before they are uploaded to S3 & you are decrypting them after they are downloaded from S3. S3 does not have any knowledge of how you do that and is only storing your files.
You are the weakest (or strongest) link when using CSE but in terms of data security, CSE is more secure than SSE.
What strategies/tools do you recommend for managing keys when using client-side encryption?
這是一個非常廣泛的問題，但就 S3 CSE 而言，您有2 個選擇：
- 使用存盤在 AWS Key Management Service (AWS KMS) 中的密鑰
- 使用您在應用程式中存盤（和檢索）的密鑰
選擇哪個選項取決于您對 AWS 的信任程度。
使用哪種方法的答案取決于您的檔案的敏感性以及您對 AWS 的信任程度和/或您保持密鑰安全的能力。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/376115.html