为什么 Disable-AzureRmVMDiskEncryption 不需要密钥加密密钥或磁盘加密密钥 url答案

【问题标题】：Why Disable-AzureRmVMDiskEncryption doesn't need either key encryption key or disk encryption key urls为什么 Disable-AzureRmVMDiskEncryption 不需要密钥加密密钥或磁盘加密密钥 url
【发布时间】：2018-10-02 13:23:34
【问题描述】：

Disable-AzureRmVMDiskEncryption cmdlet（我相信禁用 = 解密）只需要 VM 的名称即可禁用加密。

在没有任何密钥的情况下禁用加密不是安全问题吗？如何通过 RBAC 防止磁盘禁用加密？

【问题讨论】：

静态加密几乎不会增加安全性，因为任何攻击者都可以像访问数据一样访问密钥。这是一个旨在通过使用“加密”假装更安全来遵守法规的骗局。使用数据旁边的密钥进行加密是毫无价值的。
我认为这就是密钥加密密钥 (kek) 有用的地方。用kek加密磁盘加密密钥并保护它。但是，如果没有适当的 RBAC 应用于 VM 加密权限，任何有权访问 VM 的人都可以使用 Disable-AzureRmVMDiskEncryption 命令对其进行解密。

标签： azure encryption azure-disk

【解决方案1】：

在没有任何密钥的情况下禁用加密不是安全问题吗？

这看起来不像是安全问题，因为这里有两个不同的问题：

保护静态数据 - 由 Azure 磁盘加密处理（仅当您根据 Azure 数据安全和加密最佳实践启用它时）
保护对 VM 本身及其资源的访问 - 由 RBAC 负责。

当您禁用磁盘加密时

它确实确保当前加密的数据被解密回来并且不再在静态时加密。

由于 Azure 在您首先启用加密时就已经知道有关密钥加密密钥 (KEK) 和磁盘加密密钥 (DEK) 的详细信息，因此实际上不需要按顺序询问这些详细信息解密当前加密的信息。

以下是来自 Microsoft Docs 的解密流程的详细信息：

Decryption workflow

如何防止磁盘禁用加密，通过 RBAC ?

可以通过使用 Azure Portal/PowerShell 等中的 RBAC 分配（或删除）正确的角色（如 Owner 或 Virtual Machine Contributor）来控制谁可以管理 VM 或启动/禁用磁盘加密的真正问题。

【讨论】：