加密金鑰管理不善，是導致各種安全漏洞的原因。組織不應依賴平台管理的金鑰來保護關鍵資料資源。

竊取實體媒體是攻擊者取得機密資訊的常用手段。

依預設，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 自動化 dependency 管理系統，使用者可為 dependency 指定版本狀態 (也稱為動態版本)，而非列出特定版本。如果攻擊者能夠危害 dependency 儲存庫，或欺騙 build system 從攻擊者控制的儲存庫下載 dependency，那麼 build system 只需下載動態修正說明符號，而該說明符號可能執行受危害的 dependency。除了安全性風險之外，動態修正還會為 Code Quality 帶來下列風險：動態修正使軟體的安全性和穩定性受控於第三方，即開發和發行軟體所使用的 dependency 的第三方。

在建置過程中，Ivy 會連接到儲存庫並企圖擷取與所列出狀態相符的 dependency。

Ivy 接受以下的動態修正說明符號：

- latest.integration：選擇 dependency 模組的最新修正。
- latest.[any status]：選擇至少處於指定狀態的 dependency 模組的最新修正。例如，latest.milestone 會選擇重要的修正版本，或是發行版本，而 latest.release 僅會選擇最新發行版本。
- 任何結尾為 + 的修正：選擇 dependency 模組的最新子修正。例如，如果 dependency 存在於 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 下載 dependency 的惡意版本。