火傷をしないために：Azureのネットワークとファイアウォールでよくある構成不備の特定と修正

私どもVaronis Systems, Inc (NASDAQ: VRNS) は、データセキュリティと分析の先駆者で、データ保護、脅威の検出と対応、およびコンプライアンスに特化したソフトウェアを開発しています。このコラムでは、サイバーセキュリティ、プライバシー、データ保護についての最新のトレンドや知見、分析情報、事例などを皆様にご紹介していきたいと考えております。

第53回目となる今回は、「火傷をしないために：Azureのネットワークとファイアウォールでよくある構成不備の特定と修正」と題して、機密性の高いデータやリソースを公開する可能性のあるAzureネットアークアクセス制御で見られるさまざまなニュアンスと一般的な構成不備を探る、Coby Abrams（Varonisのクラウドセキュリティ研究者）によるブログ記事をご紹介いたします。

Azureのネットワークは堅牢な機能を提供し、多くのセキュリティ機能を備え、複雑なワークフローとテナント間のコラボレーションを可能にしています。しかし、利用可能な機能が多岐にわたるため、Azureのネットワークが圧倒的に困難に思える場合があります。

IT部門はネットワークの目標を達成し、さまざまなモデルを導入し、複雑なリソースの組み合わせを管理する必要があります。こうした課題を考えると、業務が多忙になって、特定のセキュリティリスクが見過ごされてしまうのも無理はありません。

この記事では、機密性の高いデータやリソースを公開する可能性のあるAzureネットアークアクセス制御で見られるさまざまなニュアンスと一般的な構成不備を探ります。

Azure Firewall、リソースファイアウォール、ネットワークセキュリティグループ (NSG)

ネットワークアクセス制御は数多く存在します。これらの制御は一見似ているように思えるかも知れませんが、それぞれに特定の用途があり、ます期待通りではない振る舞いをすることがあります。

Azure Firewall

Azure Firewallは従来の物理的なファイアウォールと同様な完全にステートフルなファイアウォールで、脅威インテリジェンスベースのフィルタリング、ネットワークアドレス変換 (NAT) 、インターネットアクセスフィルタリングなどを実行できます。

Azure Firewallをデプロイする際、ユーザーは、高度な脅威保護が含まれない最低レベルのベーシックから、すべての機能が含まれる最高レベルのプレミアムまで、3つの異なるSKUから選択できます。

Azureリソースファイアウォール

多くのAzureリソースにはパブリックエンドポイントがあり、Azureのリソースファイアウォールを使用すると、仮想ネットワークと許可されたIPアドレスのホワイトリストによって、パブリックアクセスを許可したり、アクセスを制限することができます。このアクセス構成は「ファイアウォール」とも呼ばれます。

例えば、ストレージアカウントのインターネットアクセス構成は、「ストレージアカウントファイアウォール」と呼ばれます。各リソースは、パブリックエンドポイントに関して若干異なる振る舞いをし、それぞれの操作モードに微妙な違いがあります。

こうしたバリエーションの1つが、Azure SQL Serverの [Azureサービスおよびリソースにこのサーバーへのアクセスを許可する] 設定で、ストレージアカウントの [信頼されたAzureサービスによるストレージ アカウントへのアクセスを許可する] 設定とは似ているようで全く異なります。

最初のルールは、他のテナントはCloud Shellセッションなど、Azureに属するすべてのIPにデータベースへのアクセスを許可します（基本的にデータベースは公開されます）。2番目のルールでは、信頼されたAzureサービスのサブセットのみがリソースにアクセスできるようになります。

Azureネットワークセキュリティグループ

ネットワークセキュリティグループ (NSG) は、仮想ネットワーク内のAzureリソース間のトラフィックをフィルター処理し、サブネット全体または特定のネットワークインターフェイスに適用できます。これはAzure Firewallとは異なっており、Azure Firewallはフル機能のネットワークアプライアンスであるのに対し、NSGは単純に5タプル情報（送信元、送信元ポート、宛先、宛先ポート、プロトコル）に基づくアクセスルールです。この違いの一例として、Azure Firewallはインターネット ゲートウェイとして使用できますが、NSGは使用できません。

プライベートエンドポイント

プライベートエンドポイントは、Azure Storageのような一般的にパブリックエンドポイントしか持たないリソースが、仮想ネットワーク内のネットワークインターフェイスを持つことを可能にするソリューションを提供します。リソースのプライベートエンドポイントをデプロイすると、仮想ネットワークにネットワークインターフェイスが追加されます。これには、パブリックエンドポイントをインターフェイスの内部IPアドレスにリダイレクトするDNSエントリーが含まれています。

Azureリソースファイアウォール

前述のリソースファイアウォールは、パブリックIPアドレスにのみ影響します。プライベートエンドポイントへのトラフィックには影響しないため、エンドポイントがデプロイされている仮想ネットワークに接続されている任意のエンティティのネットワークアクセスが許可されます。内部ネットワークからのアクセスを制限するには、別の方法を使うことをお勧めします。

Azureネットワークセキュリティグループ (NSG)

プライベートエンドポイントを使用して仮想ネットワーク内に内部エンドポイントを作成した場合、NSGを使用してアクセスを制限することは合理的です。かなりの混乱を引き起こす可能性があるのは、各サブネットの [プライベートエンドポイントのネットワークポリシー] 設定です。この設定は、NSGルールをサブネット内のプライベートエンドポイントに適用するかどうかを指定し、既定ではこれらのルールは適用されません。つまり、ネットワークエンジニアがNSGを使用してVNET内のリソースへのアクセスを制限するために一見セキュリティで保護された環境のように見えるものを設計したとしても、これらのルールが自動的にプライベートエンドポイントを通じてデプロイされたリソースには自動適用されません。これにより、セキュリティ脆弱性が生じる可能性があります。

次のAzureリソースグラフクエリーでは、プライベートエンドポイントにNSGを適用していない問題を抱えたサブネットを持つ仮想ネットワークを検索できます：

		resources
| where type =~ "microsoft.network/virtualnetworks"
| extend subnets = properties.subnets
| mv-expand subnets
| project subscription=subscriptionId, resourceGroup=resourceGroup, vnetId=id, vnetName=name, subnetName=subnets.name, nsgsEnforcedOnPrivateEndpoints=subnets.properties.privateEndpointNetworkPolicies
| where nsgsEnforcedOnPrivateEndpoints == "Disabled"

上記の設定をすべての仮想ネットワークで変更して、プライベートエンドポイントにNSGを強制することをお勧めします。ネットワーク管理者は、ポータル経由でストレージアカウントを作成し、そのプロセスの途中でプライベートエンドポイントを追加する際、誤って [プライベートエンドポイントのネットワークポリシー] を既定値にリセットしないように注意する必要があります。ストレージアカウントの作成後にプライベートエンドポイントを追加すると、 [プライベートエンドポイントのネットワークポリシー] 設定を個別に選択できるため、この方法をおすすめします。

ストレージアカウントのネットワーク設定の不正使用

Azure Storageアカウントは、重要なアプリケーションとワークフローのデータを保存し、アクセスするために不可欠です。そのため、ストレージアカウントを保護しながら、さまざまなネットワーク設定と可能性を利用できるようにする必要があります。ただし、ネットワーク設定の柔軟性により、時として潜在的な脆弱性や攻撃ベクトルが生じる可能性があります。

Azure StorageアカウントNFS

ネットワークファイルシステム (NFS) は、Azure Storageアカウントで使用できる分散ファイル共有用のネットワークプロトコルです。プライベートエンドポイント用のNSGは、BLOGストレージがNFSで機能する仕組みから、非常に重要です。BLOGストレージはNFS経由でアクセス可能ですが、これはパブリックエンドポイントを除く仮想ネットワークに制限されています。この機能には承認が含まれていないため、NFS経由のBLOBストレージへのアクセス制御は、プライベートエンドポイントのNSGやサービスエンドポイントの許可された仮想ネットワークなどのネットワークセキュリティ設定によってのみ決定されます。これにより、認証を必要とするストレージコンテナーは、NFSでアクセスすると認証をバイパスしてしまうため、セキュリティ上の問題が生じます。deBLOBストレージに対してNFS 3.0が無効化されていることを確認することをお勧めします。

次のAzureリソースグラフクエリーでは、BLOBストレージに対してNFSが有効になっているストレージアカウントを検索できます：

		resources
| where type == "microsoft.storage/storageaccounts"
| where properties['isNfsV3Enabled'] == "true"
| project tenant=tenantId,subscriptionId=subscriptionId, resourceGroup=resourceGroup, storageAccountName=name, storageAccountId=id, isNFSEnabled=properties['isNfsV3Enabled']

Azure Storageファイアウォールとオブジェクトレプリケーション

NSG、リソースファイアウォール、適切な認証方法と設定を使用してストレージアカウントへのネットワークアクセスを保護していても、Azure Storage Account Contributorロールを持つユーザーは、任意のIPアドレスからストレージアカウント内のすべてのデータにアクセスすることができます。これは、ネットワーク設定を変更することなく実行できるため、検出が困難です。どうやって？オブジェクトレプリケーションを使用します。

オブジェクトレプリケーションがオブジェクトを別のストレージアカウントにレプリケーションするように設定されている場合、このアカウントが同じテナント内にあるか、テナントを跨いだレプリケーションであるかにかかわらず、既存のネットワークレベルのルールとアクセスレベルのルールはレプリケーションプロセスに影響しません。これはつまり、Storage Account Contributorロールを持つ攻撃者は、テナント間のオブジェクトレプリケーションを構成して、アカウント内のすべての既存データと新規データにアクセスできるということです。

必要な権限を持つ攻撃者は、テナント間レプリケーションを有効にし、自分がコントロールするストレージアカウントへのオブジェクトレプリケーションを構成することにより、この機能を悪用することができます。可能であれば、テナント間レプリケーションを無効にし、できない場合には、送信元アカウントと宛先アカウントの両方に同様のレベルの保護が設定されていることを確認してください。次のAzureリソースグラフクエリーでは、テナント間レプリケーションが有効になっているストレージアカウントを一覧表示できます：

		resources
| where  type == 'microsoft.storage/storageaccounts'
| where properties.allowCrossTenantReplication == 'true'
| project tenant=tenantId,subscriptionId=subscriptionId, resourceGroup=resourceGroup, storageAccountName=name, storageAccountId=id, isCrossTenantReplicationEnabled=properties.allowCrossTenantReplication

攻撃者がアクセス権を取得する別の方法は、パブリックストレージアカウントやアクセス許可を持つアカウントにオブジェクトを複製することです。これは、次のPowerShellスクリプトで検出でき、オブジェクトレプリケーションポリシーと、宛先コンテナーが外部サブスクリプションまたはパブリックコンテナーのどちらにあるかを一覧表示します。

		$Subscriptions = Get-AzSubscription | ForEach-Object { $_.id }

$ORPolicies = Get-AzStorageAccount | ForEach-Object{ Get-AzStorageObjectReplicationPolicy -ResourceGroupName $_.ResourceGroupName -StorageAccountName $_.StorageAccountName}
foreach ($Policy in $ORPolicies) {
    foreach ($Rule in $Policy.Rules) {
$destContainer = Get-AzResource -ResourceId ($Policy.DestinationAccount + "/blobServices/default/containers/" + $Rule.DestinationContainer) -ErrorAction SilentlyContinue
            $Custom = [pscustomobject]@{
                SourceStorageAccount = $Policy.SourceAccount
                SourceContainer = $Rule.SourceContainer
                DestinationStorageAccount = $Policy.DestinationAccount
                DestinationContainer = $Rule.DestinationContainer
                IsToExternalTenant = ($Subscriptions -contains $Policy.DestinationAccount.split('/')[2])
                IsPublicAccessEnabledOnDest = $destContainer.Properties.publicAccess
            }
            $Custom | Format-Table
    }
}

まとめ

Azureのさまざまなネットワーク設定が、リソースアクセスに対して、特定、あるいは予期せぬ方法で影響を与えることを紹介しました。

デプロイ時に、これらのネットワーク設定が環境とデータに与えるセキュリティ上の影響を理解することが重要です。  
環境を監視し、実効データリソースアクセス権を計算することができるセキュリティプラットフォームを使用すると、データの安全を確保することができます。

ブログ著者について

Coby Abrams

Coby AbramsはVaronisのクラウドセキュリティ研究者であり、AzureとIaaSのリサーチ、各種サービスの詳細な概要を専門としています。さまざまな種類のセキュリティリサーチで、5年以上の経験を有しています。

（翻訳：跡部 靖夫）