Azure Blob自定义密钥加密：CustomerProvidedKey与EncryptionPolicy差异咨询

这两种自定义加密方式确实容易搞混，我来给你拆解清楚它们的核心差异和适用场景：

第一种：BlobClientOptions 配置 CustomerProvidedKey（服务端加密） #

这种方式属于Azure存储服务端加密，简单来说就是：你提供加密密钥，Azure负责在存储Blob的时候用这个密钥加密数据，读取的时候再解密。

• 密钥类型：必须是对称密钥（AES-256），你需要自己生成和管理这个密钥，Azure不会存储它，每次Blob操作（上传、下载、修改）都需要传递这个密钥（通过BlobClientOptions）。
• 作用范围：设置在BlobServiceClient/BlobContainerClient级别后，该客户端实例下的所有Blob操作都会自动应用这个加密规则，不用每次上传下载都单独配置。
• 核心特点：加密/解密操作由Azure存储服务执行，Azure能看到加密后的Blob但不会存储你的密钥；登录Azure的用户如果没有这个密钥，就算有Blob的访问权限也无法解密查看内容。

第二种：BlobEncryptionPolicy + BlobRequestOptions（客户端加密） #

这种方式属于客户端本地加密，加密操作完全在你的应用代码里完成，Azure存储服务拿到的只是加密后的密文，根本接触不到原始数据。

• 密钥类型：通常使用非对称密钥（RSA），你用私钥来加密数据加密密钥（DEK），实际加密Blob内容用的是随机生成的对称密钥；或者也可以直接指定对称密钥，但RSA更适合密钥管理场景。
• 作用范围：属于单操作级别，每次调用UploadFromStream/DownloadToStream等方法时，都需要单独传入配置了EncryptionPolicy的BlobRequestOptions。
• 核心特点：加密/解密全在客户端完成，Azure存储服务对原始数据和加密密钥完全不可见；就算有人拿到Azure存储的Blob文件，没有你的密钥也绝对无法解密。

核心差异对比 #

• 加密执行位置：第一种在Azure服务端，第二种在你的客户端代码中
• 密钥类型要求：第一种必须是AES对称密钥，第二种支持RSA非对称密钥或对称密钥
• 作用范围：第一种是客户端实例全局生效，第二种仅针对单个Blob操作
• Azure对数据的可见性：第一种Azure能处理加密过程但看不到密钥；第二种Azure完全看不到原始数据
• 适用场景：
  • 如果你信任Azure的服务端加密能力，只是不想使用Azure托管的密钥，选第一种
  • 如果你需要完全确保Azure不接触任何原始数据，选第二种

内容的提问来源于stack exchange，提问作者kosnkov