弱式驗證機制會讓組織暴露於未經授權存取的風險。

驗證機制可能因各種原因而失敗，例如：
- 低強度密碼
- 驗證不當
- 低強度的認證管理

弱式驗證機制會讓組織暴露於未經授權存取的風險。

驗證機制可能因各種原因而失敗，例如：
- 低強度密碼
- 驗證不當
- 低強度的認證管理

弱式驗證機制會讓組織暴露於未經授權存取的風險。

驗證機制可能因各種原因而失敗，例如：
- 低強度密碼
- 驗證不當
- 低強度的認證管理

弱式驗證機制會讓組織暴露於未經授權存取的風險。

驗證機制可能因各種原因而失敗，例如：
- 低強度密碼
- 驗證不當
- 低強度的認證管理

驗證是安全性的一個重要層面。驗證程序的可靠性取決於登入憑證的安全性和強度。確保使用者建立強式密碼的密碼原則，對於部署安全網站至關重要。密碼強度是衡量其在抵擋猜測和暴力攻擊方面提供的有效性的指標。有些參數有助於定義密碼強度，包括密碼特徵，例如密碼長度、複雜性和隨機性。

客戶自管金鑰未用於加密靜態資料。

客戶自管金鑰讓組織能夠使用自己選擇的加密金鑰來加密資料。這讓組織可以妥善控制加密過程。

因此，客戶自管金鑰通常會納入解決方案的一部分，可滿足包括但不限於以下需求：
- 敏感資料存取的稽核記錄
- 資料落地
- 取代、停用或銷毀金鑰

客戶自管金鑰未用於加密靜態資料。

客戶自管金鑰讓組織能夠使用自己選擇的加密金鑰來加密資料。這讓組織可以妥善控制加密過程。

因此，客戶自管金鑰通常會納入解決方案的一部分，可滿足包括但不限於以下需求：
- 敏感資料存取的稽核記錄
- 資料落地
- 取代、停用或銷毀金鑰

客戶自管金鑰未用於加密靜態資料。

客戶自管金鑰讓組織能夠使用自己選擇的加密金鑰來加密資料。這讓組織可以妥善控制加密過程。

因此，客戶自管金鑰通常會納入解決方案的一部分，可滿足包括但不限於以下需求：
- 敏感資料存取的稽核記錄
- 資料落地
- 取代、停用或銷毀金鑰

客戶自管金鑰未用於加密靜態資料。

客戶自管金鑰讓組織能夠使用自己選擇的加密金鑰來加密資料。這讓組織可以妥善控制加密過程。

因此，客戶自管金鑰通常會納入解決方案的一部分，可滿足包括但不限於以下需求：
- 敏感資料存取的稽核記錄
- 資料落地
- 取代、停用或銷毀金鑰

客戶自管金鑰未用於加密靜態資料。

客戶自管金鑰讓組織能夠使用自己選擇的加密金鑰來加密資料。這讓組織可以妥善控制加密過程。

因此，客戶自管金鑰通常會納入解決方案的一部分，可滿足包括但不限於以下需求：
- 敏感資料存取的稽核記錄
- 資料落地
- 取代、停用或銷毀金鑰

敏感的 Azure ARM 範本參數 (例如密碼) 通常使用 securestring 或 secureobject 類型。

對於使用安全類型的參數，參數值不會記錄或儲存在部署歷程記錄中。

但是，如果為安全類型設定了硬式編碼的預設值，則任何人只要可以存取範本或部署歷程記錄，就可以讀取該預設值。

硬式編碼的機密會導致無法輕易修正的安全性問題。當軟體進入生產階段後，除非更新軟體，否則無法變更遭外洩的機密。

如果是用於加密資料的機密，則必須管理金鑰輪換步驟以解密和重新加密受外洩金鑰保護的所有資料。

範例 1：以下範本顯示一個具有機密類型的參數，而機密類型使用硬式編碼的預設值。

{
    ...
    "parameters": {
        "rootPassword": {
            "defaultValue": "HardcodedPassword",
            "type": "secureString"
        },
        "adminLogin": {
            "type": "string"
        },
        "sqlServerName": {
            "type": "string"
        }
    },
    ...
}

透過 HTTP 傳送的所有資料都會顯示，安全性可能降低。
範例 1：

"supportsHttpsTrafficOnly": "false"

可公開存取的 Kubernetes API 伺服器可能會使組織暴露於攻擊的風險中。

範例 1：以下範例顯示一個定義 Kubernetes 服務叢集的範本，該叢集未限制允許連線至 API 伺服器的 IP 位址範圍。

{
    "name": "TestCluster",
    "type": "Microsoft.ContainerService/managedClusters",
    "apiVersion": "2020-02-01",
    "location": "[resourceGroup().location]",
    "properties": {
    ...
    "servicePrincipalProfile": {
        "clientId": "422313d8-123a-41ea-8f8e-90821ff61c05",
        "secret": "xxxxxxxxxxxxxxxxx"
    },
    }
}

除錯介面為攻擊者提供資訊，他們可以利用這些資訊進行更具目標性的攻擊。

範例 1：以下範例範本定義一個啟用了遠端除錯的 Azure 應用服務。

{
    ...
    "type": "Microsoft.Web/sites/config",
    "properties":
    {
        ...
        "remoteDebuggingEnabled": true,
    }
}

依預設，Azure Blob 儲存體容器會阻止匿名存取其 Blob。

存取組態不足會將系統暴露在外，並擴大組織的受攻擊面。開放公開存取的資源可能會無意間洩露敏感資料。

範例 1：以下範例範本將定義一個 Azure Blob 儲存體容器，其中 publicAccess 屬性設定為 Container。這會允許匿名存取容器的所有 Blob 和資料。

{
    "type": "Microsoft.Storage/storageAccounts/blobServices/containers",
    "apiVersion": "2021-04-01",
    "name": "[format('{0}/default/{1}', parameters('storageAccountName'), parameters('containerName'))]",
    "properties":{
        "publicAccess": "Container"
    }
    ,
    "dependsOn": [
        "[resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName'))]"
    ]
}

受基本驗證保護的系統為攻擊者提供了一個潛在弱連結。攻擊者可透過暴力破解、猜測或社交工程破解密碼 (尤其是低強度的密碼)。

範例 1：以下範例顯示允許 SSH 基本驗證的 VM。

{
    "resources": [
        {
            "type": "Microsoft.Compute/virtualMachines",
            "apiVersion": "2021-03-01",
            "name": "[variables('vmName')]",
            "location": "[parameters('location')]",
            ...
            "osProfile": {
                "computerName": "[variables('vmName')]",
                "adminUsername": "[parameters('adminUsername')]",
                "linuxConfiguration": {
                    "disablePasswordAuthentication": false
                }
            },
            ...
        }
    ]
}

存取組態不足會將系統暴露在外，並擴大組織的受攻擊面。開放與網際網路互動的服務會受到惡意實體連續的掃描和探測。

在發現並發佈針對公開服務的零時差攻擊 (例如 Heartbleed) 時問題特別大。攻擊者可主動追蹤和搜尋未修補和暴露的系統以進行攻擊。

範例 1：以下範例範本透過啟用 publicNetworkAccess 屬性且不建立任何 IP 限制來定義未限制網路存取的 Azure Container Registry。

{
    "name": "[variables('acrName')]",
    "type": "Microsoft.ContainerRegistry/registries",
    ...
    "properties": {
        "publicNetworkAccess": "Enabled",
        ..
}

範例 2：以下範例範本透過指定廣泛的允許清單給 networkRuleSet 屬性來定義未限制網路存取的 Azure Container Registry。

{
    "name": "[variables('acrName')]",
    "type": "Microsoft.ContainerRegistry/registries",
    ...
    "properties": {
        "publicNetworkAccess": "Enabled",
        "networkRuleSet":
        {
            "defaultAction": "Allow",
            "ipRules":[{
                "action": "Allow",
                "value": "*"
            }]
        }
        ...
}

Cross-Origin Resource Sharing 通常簡稱為 CORS，是一種允許網域為其資源定義原則，讓託管在不同網域上的網頁存取其資源的技術。根據過去經驗，網頁瀏覽器已限制其網域資源不得由不同網域載入的指令碼所存取，以遵守相同來源原則。
CORS 為網域提供了一種允許其他網域並讓它們可以存取其資源的方法。

定義 CORS 原則時務必小心，因為在伺服器層級為網域或網域上的目錄所設定的原則若過度允許，公開給跨網域存取的內容可能會高於預期。CORS 可能使惡意應用程式與受害應用程式進行不當通訊，進而可導致資訊外洩、詐騙、資料竊取、轉送或其他攻擊。

實作 CORS 可能增加應用程式的受攻擊面，所以僅在必要時才應使用。

範例 1：以下範例範本為 Azure SignalR Web 應用程式定義過度允許的 CORS 原則。

{
    ...
    "type": "Microsoft.SignalRService/SignalR",
    ...
    "properties": {
    ...
        "cors": {
            "allowedOrigins": ["*"]
        },
    ...
}

範例 2：以下範例範本為 Azure Web 應用程式定義過度允許的 CORS 原則。

{
    "apiVersion": "2020-12-01",
    "type": "Microsoft.Web/sites",
    ...
    "properties": {
        ...
        "siteConfig": {
            ...
            "cors": {
                "allowedOrigins": [
                    "*"
                ]
            },
    ...
}

範例 3：以下範例範本為 Azure Maps 帳戶定義過度允許的 CORS 原則。

{
    "apiVersion": "2021-12-01-preview",
    "type": "Microsoft.Maps/accounts",
    ...
    "properties":{
        "cors":{
            "allowedOrigins": ["*"]
        }
    },
    ...
}

範例 4：以下範例範本為 Azure Cosmos DB 帳戶定義過度允許的 CORS 原則。

{
    "type": "Microsoft.DocumentDB/databaseAccounts",
    ...
    "properties": {
        "cors": [{
            "allowedOrigins":"*"
        }],
    ...
}

範例 5：以下範例範本為 Azure 儲存體 Blob 服務定義過度允許的 CORS 原則。

{
"type": "Microsoft.Storage/storageAccounts/blobServices",
    ...
    "properties": {
        "cors": {
            "corsRules": [
                {
                    "allowedOrigins":["*"],
                    ...
                }
            ]
        }
    }
    ...
}

自訂 Azure 訂閱擁有者角色提供對訂閱下所有資源的無限制存取，大大增加了組織暴露於風險並違反了最低權限原則。

範例 1：以下範例顯示一個具有所有可能權限的自訂擁有者角色定義。

{
    "resources": [
        {
            "name": "roleDef",
            "type": "Microsoft.Authorization/roleDefinitions",
            "apiVersion": "2018-01-01-preview",
            "properties": {
                "roleName": "InfraAdmin",
                "description": "Infrastructure Admin",
                "permissions": [
                    {
                        "actions": [
                            "*"
                        ]
                    }
                ],
                ...
            }
        }
    ]
}

寬鬆的存取組態會將系統暴露在外，並擴大組織的受攻擊面。開放與網際網路互動的服務會受到惡意實體幾乎連續的掃描和探測。

在發現並發佈針對公開服務的零時差攻擊 (例如 Heartbleed) 時問題特別大。攻擊者可主動追蹤和搜尋未修補和暴露的系統以進行攻擊。

範例 1：以下範例範本將定義一個未限制網路存取的 Azure Cosmos DB。publicNetworkAccess 屬性設定為 Enabled，且 IP 位址範圍包括所有 IP。

{
    "type": "Microsoft.DocumentDB/databaseAccounts",
    "apiVersion": "2021-04-15",
    ...
    "properties": {
        ...
        "publicNetworkAccess": "Enabled",
        "ipRules":[{
                "ipAddressOrRange":  "0.0.0.0"
            }]
    ...
}