加密密钥管理不善会导致各种安全漏洞。对于重要的数据资源，组织不应依赖平台管理的密钥。

物理媒介盗用是攻击者获取机密信息的常用手段。

默认情况下，Azure SQL 数据库使用透明数据加密 (TDE) 来加密和保护静态数据。

对 Azure SQL 数据库禁用 TDE 会使数据面临潜在的盗用风险。

示例 1：以下示例显示的 Terraform 配置定义了一个未启用数据加密的 Azure SQL 数据库。

resource "azurerm_mssql_database" "aztf008-tp-01" {
  name           = "aztf008-db-d"
  ... 
  sku_name       = "DW100c"
  ...
  transparent_data_encryption_enabled = false
}

实现缺陷、错误配置和密钥泄露这些问题会导致单层加密无法充分保护高度敏感的数据。组织应采用深度防御方法来保护高度敏感的数据，并避免在其安全设计中出现单点故障。

实现缺陷、错误配置和密钥泄露这些问题会导致单层加密无法充分保护高度敏感的数据。组织应采用深度防御方法来保护高度敏感的数据，并避免在其安全设计中出现单点故障。

能够确保及时修补已知软件漏洞的自动软件升级已被禁用。

云服务通常使用缓存、复制和负载平衡等技术来促进服务可扩展性、加快内容交付以及减轻容量耗尽攻击的影响。可用性功能禁用或错误配置会降低服务性能，但通常不会造成明显的直接影响，直到最后发生流量峰值和硬件故障等极端事件。

Azure 提供了多个加密选项，每个选项都有特定的优点和限制。例如，Azure 存储服务器端加密 (SSE) 会默认执行加密，无需使用计算资源，但是它不会加密临时磁盘或缓存。该选项也不会保护从计算实例流向存储的数据。Azure 磁盘加密 (ADE) 可加密临时磁盘和缓存，以及流向存储的数据，但要使用计算资源。

加密密钥管理不善会导致各种安全漏洞。对于重要的数据资源，组织不应依赖平台管理的密钥。

加密密钥管理不善会导致各种安全漏洞。对于重要的数据资源，组织不应依赖平台管理的密钥。

数据备份经常被忽视，其作为资产，需要获得与原始数据同等程度的保护。

未加密的备份会导致备份数据易受潜在攻击者访问。

默认情况下，Azure SQL 虚拟机自动备份设置不强制执行数据备份加密。

示例 1：以下示例显示的 Terraform 配置定义了不强制执行备份数据加密的 Azure SQL 虚拟机自动备份设置。

resource "azurerm_mssql_virtual_machine" "aztf009-tn-03" {
  virtual_machine_id               = data.azurerm_virtual_machine.example.id
  ...
  auto_backup {
    retention_period_in_days = 1
    storage_blob_endpoint = ""
    storage_account_access_key = azurerm_storage_account.example.primary_access_key
  }
}

加密密钥管理不善会导致各种安全漏洞。对于重要的数据资源，组织不应依赖平台管理的密钥。

实现缺陷、错误配置和密钥泄露这些问题会导致单层加密无法充分保护高度敏感的数据。组织应采用深度防御方法来保护高度敏感的数据，并避免在其安全设计中出现单点故障。

加密密钥管理不善会导致各种安全漏洞。对于重要的数据资源，组织不应依赖平台管理的密钥。

Azure 提供了多个加密选项，每个选项都有特定的优点和限制。例如，Azure 存储服务器端加密 (SSE) 会默认执行加密，无需使用计算资源，但是它不会加密临时磁盘或缓存。该选项也不会保护从计算实例流向存储的数据。Azure 磁盘加密 (ADE) 可加密临时磁盘和缓存，以及流向存储的数据，但要使用计算资源。

加密密钥管理不善会导致各种安全漏洞。对于重要的数据资源，组织不应依赖平台管理的密钥。

弱身份验证机制使组织面临未经授权的访问风险。

身份验证机制可能因各种原因而失败，例如：
- 弱密码
- 验证不当
- 弱凭据管理

弱身份验证机制使组织面临未经授权的访问风险。

身份验证机制可能因各种原因而失败，例如：
- 弱密码
- 验证不当
- 弱凭据管理

弱身份验证机制使组织面临未经授权的访问风险。

身份验证机制可能因各种原因而失败，例如：
- 弱密码
- 验证不当
- 弱凭据管理

弱身份验证机制使组织面临未经授权的访问风险。

身份验证机制可能因各种原因而失败，例如：
- 弱密码
- 验证不当
- 弱凭据管理

Apache Ivy 自动化依赖项管理系统允许用户为依赖项指定版本状态（称为动态修订），而不是列出特定版本。如果攻击者能够危及依赖项存储库或诱骗编译系统从攻击者控制的存储库下载依赖项，那么编译系统可能只需提供动态修订说明符即可静默下载并运行受损的依赖项。除安全风险之外，动态修订还会引发代码质量风险：动态修订将软件安全性和稳定性控制权交到开发和发布软件所使用的依赖项的第三方的手中。

编译时，Ivy 连接存储库并尝试检索与列出的状态匹配的依赖项。

Ivy 接受以下动态修订说明符：

- latest.integration：选择最新修订版依赖项模块。
- latest.[any status]：选择至少为指定状态的最新修订版依赖项模块。例如，latest.milestone 将选择作为里程碑或发布版本的最新版本，latest.release 只会选择最新发布版本。
- 任何以 + 结尾的修订版本：选择最新子修订版依赖项模块。例如，如果修订版本 1.0.3、1.0.7 和 1.1.2 中存在依赖项，则指定为 1.0.+ 的修订版本将选择修订版本 1.0.7。
- 版本范围：范围的数学符号（例如 < 和 >）可用于匹配一系列版本。

示例 1：以下配置条目指示 Ivy 检索最新发布版 Clover 组件：

<dependencies>
        <dependency org="clover" name="clover"
                    rev="latest.release" conf="build->*"/>
	...

如果存储库受损，攻击者可以直接上传符合动态标准的版本，诱使 Ivy 下载恶意版本依赖项。