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

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

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

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

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

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

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

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

身份验证是安全性的一个重要方面。身份验证过程的可靠性取决于登录凭据的安全性和强度。确保用户创建强密码的密码策略对于部署安全网站至关重要。密码强度可衡量密码在抵抗猜测和暴力攻击方面的有效性。有助于定义密码强度的部分参数包括密码特征，例如密码长度、复杂性和随机性。

客户管理的密钥不用于加密静态数据。

客户管理的密钥允许组织使用他们选择的加密密钥来加密数据。这使组织可以更好地控制加密过程。

因此，客户管理的密钥通常是满足以下要求的解决方案的一部分，包括但不限于：
- 敏感数据访问的审核日志
- 数据驻留
- 更换、禁用或销毁密钥

客户管理的密钥不用于加密静态数据。

客户管理的密钥允许组织使用他们选择的加密密钥来加密数据。这使组织可以更好地控制加密过程。

因此，客户管理的密钥通常是满足以下要求的解决方案的一部分，包括但不限于：
- 敏感数据访问的审核日志
- 数据驻留
- 更换、禁用或销毁密钥

客户管理的密钥不用于加密静态数据。

客户管理的密钥允许组织使用他们选择的加密密钥来加密数据。这使组织可以更好地控制加密过程。

因此，客户管理的密钥通常是满足以下要求的解决方案的一部分，包括但不限于：
- 敏感数据访问的审核日志
- 数据驻留
- 更换、禁用或销毁密钥

客户管理的密钥不用于加密静态数据。

客户管理的密钥允许组织使用他们选择的加密密钥来加密数据。这使组织可以更好地控制加密过程。

因此，客户管理的密钥通常是满足以下要求的解决方案的一部分，包括但不限于：
- 敏感数据访问的审核日志
- 数据驻留
- 更换、禁用或销毁密钥

客户管理的密钥不用于加密静态数据。

客户管理的密钥允许组织使用他们选择的加密密钥来加密数据。这使组织可以更好地控制加密过程。

因此，客户管理的密钥通常是满足以下要求的解决方案的一部分，包括但不限于：
- 敏感数据访问的审核日志
- 数据驻留
- 更换、禁用或销毁密钥

敏感的 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：以下示例模板定义了 publicAccess 属性设置为 Container 的 Azure Blob 存储容器。这允许匿名访问该容器的所有 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 容器注册表。

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

示例 2：以下示例模板通过为 networkRuleSet 属性指定宽松的允许列表，定义了具有不受限制的网络访问权限的 Azure 容器注册表。

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

跨域资源共享，通常称为 CORS，是一种允许域为其资源定义策略，以供托管在不同域上的网页访问的技术。在过去，Web 浏览器始终限制从其他域加载的脚本访问其域资源，以遵守同源策略。
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"
            }]
    ...
}