脆弱な認証メカニズムは、組織を不正アクセスの危険にさらします。

認証メカニズムは、次のようなさまざまな理由で失敗する可能性があります。
- パスワードが脆弱である
- 不適切な検証
- 資格情報の管理が弱い

脆弱な認証メカニズムは、組織を不正アクセスの危険にさらします。

認証メカニズムは、次のようなさまざまな理由で失敗する可能性があります。
- パスワードが脆弱である
- 不適切な検証
- 資格情報の管理が弱い

脆弱な認証メカニズムは、組織を不正アクセスの危険にさらします。

認証メカニズムは、次のようなさまざまな理由で失敗する可能性があります。
- パスワードが脆弱である
- 不適切な検証
- 資格情報の管理が弱い

脆弱な認証メカニズムは、組織を不正アクセスの危険にさらします。

認証メカニズムは、次のようなさまざまな理由で失敗する可能性があります。
- パスワードが脆弱である
- 不適切な検証
- 資格情報の管理が弱い

認証はセキュリティの重要な側面です。認証プロセスの信頼性は、ログイン資格情報の安全性と強度によって決まります。ユーザーが強力なパスワードを作成できるようにするパスワード ポリシーは、安全な Web サイトを展開するために重要です。パスワードの強度は、推測やブルート フォース攻撃に対するパスワードの有効性の尺度となります。パスワードの強度の定義に役立つ要素には、パスワードの長さ、複雑さ、ランダム性などの特性が含まれます。

カスタマーマネージド キーは、保存データの暗号化には使用されません。

カスタマーマネージド キーを使用すると、組織は、選択した暗号鍵を使用してデータを暗号化できます。これにより、組織は暗号化プロセスをより適切に制御できます。

そのため、カスタマーマネージド キーは通常、次のような要件 (これに限らない) に対処するソリューションの一部です。
- 機密データへのアクセスの監査ログ
- データ所在地
- キーの交換、無効化、または破棄

カスタマーマネージド キーは、保存データの暗号化には使用されません。

カスタマーマネージド キーを使用すると、組織は、選択した暗号鍵を使用してデータを暗号化できます。これにより、組織は暗号化プロセスをより適切に制御できます。

そのため、カスタマーマネージド キーは通常、次のような要件 (これに限らない) に対処するソリューションの一部です。
- 機密データへのアクセスの監査ログ
- データ所在地
- キーの交換、無効化、または破棄

カスタマーマネージド キーは、保存データの暗号化には使用されません。

カスタマーマネージド キーを使用すると、組織は、選択した暗号鍵を使用してデータを暗号化できます。これにより、組織は暗号化プロセスをより適切に制御できます。

そのため、カスタマーマネージド キーは通常、次のような要件 (これに限らない) に対処するソリューションの一部です。
- 機密データへのアクセスの監査ログ
- データ所在地
- キーの交換、無効化、または破棄

カスタマーマネージド キーは、保存データの暗号化には使用されません。

カスタマーマネージド キーを使用すると、組織は、選択した暗号鍵を使用してデータを暗号化できます。これにより、組織は暗号化プロセスをより適切に制御できます。

そのため、カスタマーマネージド キーは通常、次のような要件 (これに限らない) に対処するソリューションの一部です。
- 機密データへのアクセスの監査ログ
- データ所在地
- キーの交換、無効化、または破棄

カスタマーマネージド キーは、保存データの暗号化には使用されません。

カスタマーマネージド キーを使用すると、組織は、選択した暗号鍵を使用してデータを暗号化できます。これにより、組織は暗号化プロセスをより適切に制御できます。

そのため、カスタマーマネージド キーは通常、次のような要件 (これに限らない) に対処するソリューションの一部です。
- 機密データへのアクセスの監査ログ
- データ所在地
- キーの交換、無効化、または破棄

パスワードなどの機密性の高い Azure ARM テンプレート パラメーターでは、通常、securestring または secureobject タイプを使用します。

セキュア タイプを使用するパラメーターの場合、パラメーター値はログに記録されず、デプロイメント履歴に保存されません。

しかし、ハードコーディングされたデフォルト値がセキュア タイプに設定されている場合、そのデフォルト値は、テンプレートまたはデプロイメント履歴にアクセスできるすべてのユーザーが読み取ることができます。

ハードコーディングされたシークレットはセキュリティを危険にさらす可能性があり、この問題への対策は簡単ではありません。ソフトウェアが実運用に入った後は、侵害されたシークレットを変更するためのアップデートが必要です。

データの暗号化に使用されるシークレットの場合、侵害されたキーによって保護されているすべてのデータを復号化および再暗号化するために、キーローテーション手順を実行する必要があります。

例 1: 次のテンプレートは、ハードコーディングされたデフォルト値を持つ、シークレット タイプのパラメーターを示しています。

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

HTTP 経由で送信されるデータはすべて閲覧可能であるため、危険にさらされる可能性があります。
例 1:

"supportsHttpsTrafficOnly": "false"

パブリック アクセス可能な Kubernetes API サーバーは、組織を攻撃にさらす危険性があります。

例 1: 次の例は、API サーバーへの接続を許可される IP アドレスの範囲を制限しない Kubernetes サービス クラスターを定義するテンプレートを示しています。

{
    "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 App Service を定義しています。

{
    ...
    "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 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": "*"
            }]
        }
        ...
}

クロスオリジン リソース シェアリングは、一般に CORS と呼ばれ、ドメインが、そのリソースが別のドメインでホストされている Web ページからアクセスされるポリシーを定義できるようにするテクノロジーです。これまで、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"
            }]
    ...
}