Azure SQL Database のサーバー用の仮想ネットワーク サービス エンドポイントと規則の使用
適用対象: Azure SQL データベース
Azure Synapse Analytics
"仮想ネットワーク規則" はファイアウォール セキュリティ機能であり、Azure SQL Database 内のデータベースおよびエラスティック プール用、または Azure Synapse Analytics 内の専用 SQL プール (旧称 SQL DW) データベース用のサーバーが、仮想ネットワーク内の特定のサブネットから送信される通信を許可するかどうかを制御します。 この記事では、仮想ネットワーク規則が、場合によっては SQL Database および Azure Synapse Analytics のデータベースへの通信を安全に許可するための最適な選択肢となる理由について説明します。
Note
この記事は、SQL Database と Azure Synapse Analytics の両方に適用されます。 簡潔にするために、"データベース" という用語で、SQL Database と Azure Synapse Analytics の両方のデータベースを表します。 同様に、"サーバー" という言葉は、SQL Database と Azure Synapse Analytics をホストする論理サーバーを表します。
仮想ネットワーク規則を作成するには、まず、参照する規則の仮想ネットワーク サービス エンドポイントが必要です。
Note
Microsoft Entra ID の、旧称は Azure Active Directory(Azure AD)です。
仮想ネットワーク規則を作成する
仮想ネットワーク規則の作成のみが必要であれば、途中を読み飛ばして、この記事で後述している手順と説明に進んでください。
仮想ネットワーク規則の詳細
このセクションでは、仮想ネットワーク規則に関する詳細について、いくつか説明します。
geography 型の 1 つのリージョンのみ
各仮想ネットワーク サービス エンドポイントは、1 つの Azure リージョンだけに適用されます。 そのエンドポイントにより、他のリージョンでサブネットからの通信の受け入れが可能になることはありません。
どの仮想ネットワーク規則も、その基本となるエンドポイントが適用先のリージョンに制限されます。
データベース レベルではなく、サーバー レベル
各仮想ネットワーク規則は、サーバー上の 1 つの特定のデータベースだけではなく、お使いのサーバー全体に適用されます。 言い換えると、仮想ネットワーク規則はデータベース レベルではなく、サーバー レベルに適用されます。
対照的に、IP 規則はどちらのレベルにも適用できます。
セキュリティ管理ロール
仮想ネットワーク サービス エンドポイントの管理では、セキュリティ ロールが分離されています。 以下の各ロールでは、次の操作が必要です。
- ネットワーク管理者 (ネットワーク共同作成者ロール): エンドポイントを有効にします。
- データベース管理者 (SQL Server 共同作成者ロール): アクセス制御リスト (ACL) を更新して、指定されたサブネットをサーバーに追加します。
Azure RBAC による代替
ネットワーク管理およびデータベース管理のロールには、仮想ネットワーク規則の管理に必要とされる機能以外もあります。 それらの機能のうち 1 つのサブネットだけが必要になります。
必要な機能のサブネットのみを保持する単一のカスタム ロールを作成するために、Azure にはロールベースのアクセス制御 (RBAC) を使用するオプションがあります。 ネットワーク管理またはデータベース管理に関連付ける代わりに、カスタム ロールを使用できます。カスタム役割にユーザーを追加する場合と、他の 2 つの主要な管理者の役割にユーザーを追加する場合では、前者の方がセキュリティ脅威にさらされる領域が少なくなります。
Note
SQL Database 内のデータベースと仮想ネットワーク サブネットが異なるサブスクリプションに存在する場合があります。 このような場合は、次の構成を確認する必要があります。
- どちらのサブスクリプションも同じ Microsoft Entra テナントに存在する必要があります。
- ユーザーに操作 (サービス エンドポイントの有効化や、特定のサーバーへの仮想ネットワーク サブネットの追加など) を開始するために必要な権限がある。
- 両方のサブスクリプションに Microsoft.Sql プロバイダーが登録されている。
制限事項
SQL Database の場合、仮想ネットワーク規則機能には以下のような制限事項があります。
- SQL Database 内のデータベースのファイアウォールでは、各仮想ネットワーク規則はサブネットを参照します。 これらの参照されるサブネットはすべて、データベースがホストされているのと同じ地理的リージョンでホストされている必要があります。
- 各サーバーは、任意の仮想ネットワークに対して ACL エントリを 128 個まで保持できます。
- 仮想ネットワーク規則はクラシック デプロイ モデル ネットワークではなく、Azure Resource Manager の仮想ネットワークのみに適用されます。
- SQL Database に対する仮想ネットワーク サービス エンドポイントを有効にすると、Azure Database for MySQL と Azure Database for PostgreSQL に対してもエンドポイントが有効になります。 エンドポイントが [オン] に設定されている場合、エンドポイントから Azure Database for MySQL または Azure Database for PostgreSQL のインスタンスに接続しようとすると、失敗する場合があります。
- 根本的な理由は、Azure Database for MySQL と Azure Database for PostgreSQL に仮想ネットワーク規則が構成されていない可能性があるためです。 Azure Database for MySQL と Azure Database for PostgreSQL の仮想ネットワーク規則を構成する必要があります。
- プライベート エンドポイントを使用して既に構成されている SQL 論理サーバー上で仮想ネットワークのファイアウォール規則を定義するには、 [Deny public network access](パブリック ネットワーク アクセスの拒否) を [いいえ] に設定します。
- ファイアウォールでは、IP アドレスの範囲は以下のネットワーク項目に適用されますが、仮想ネットワーク規則は適用されません。
サービス エンドポイントを使用する場合の考慮事項
SQL Database に対してサービス エンドポイントを使用する場合は、次の考慮事項を確認してください。
- Azure SQL Database のパブリック IP へのアウトバウンドが必要です。 ネットワーク セキュリティ グループ (NSG) は、接続を許可するために SQL Database IP に対して開かれている必要があります。 これは、SQL Database 用の NSG サービス タグを使用して行うことができます。
ExpressRoute
パブリック ピアリングまたは Microsoft ピアリングのためにオンプレミスから ExpressRoute を使用する場合、使用される NAT の IP アドレスを特定する必要があります。 パブリック ピアリングの場合、既定で、Azure サービスのトラフィックが Microsoft Azure のネットワーク バックボーンに入ったときに適用される 2 つの NAT IP アドレスが各 ExpressRoute 回線に使用されます。 Microsoft ピアリングの場合、使用される NAT の IP アドレスは、お客様またはサービス プロバイダーが指定します。 サービス リソースへのアクセスを許可するには、リソースの IP ファイアウォール設定でこれらのパブリック IP アドレスを許可する必要があります。 パブリック ピアリングの ExpressRoute 回線の IP アドレスを確認するには、Azure Portal から ExpressRoute のサポート チケットを開いてください。 ExpressRoute のパブリックおよび Microsoft ピアリングの NAT の詳細については、「Azure パブリック ピアリングの NAT 要件」を参照してください。
回線から SQL Database への通信を許可するには、NAT のパブリック IP アドレスに対する IP ネットワーク規則を作成する必要があります。
Azure Storage で仮想ネットワーク サービス エンドポイントを使用した場合の影響
Azure Storage は、Azure ストレージ アカウントへの接続を制限できる同じ機能を実装しています。 SQL Database で使用されている Azure Storage アカウントでこの機能を使用することにした場合は、問題が発生する可能性があります。 この影響を受ける SQL Database と Azure Synapse Analytics の機能の一覧と説明を次に示します。
Azure Synapse Analytics PolyBase と COPY ステートメント
PolyBase と COPY ステートメントは、高スループットのデータ インジェストのために、Azure Storage アカウントから Azure Synapse Analytics にデータを読み込むために一般的に使用されます。 データの読み込み元の Azure Storage アカウントでアクセスが一連の仮想ネットワーク サブネットだけに制限されている場合は、そのストレージ アカウントへの PolyBase と COPY ステートメントを使用した接続は切断されます。 仮想ネットワークに対してセキュリティ保護された Azure Storage に接続している Azure Synapse Analytics で COPY と PolyBase を使用して、インポートおよびエクスポートのシナリオを有効にするには、このセクションの手順に従います。
前提条件
- Azure PowerShell をインストールします。 詳細については、「Azure Az PowerShell モジュールをインストールする」を参照してください。
- 汎用 v1 または Azure Blob Storage アカウントが存在する場合は、「汎用 v2 ストレージ アカウントにアップグレードする」の手順に従って、最初に汎用 v2 にアップグレードする必要があります。
- Azure Storage アカウントの [ファイアウォールと仮想ネットワーク] 設定メニューで、 [信頼された Microsoft サービスによるこのストレージ アカウントに対するアクセスを許可します] をオンにする必要があります。 この構成を有効にすると、PolyBase と COPY ステートメントは、ネットワーク トラフィックが Azure バックボーン上に残る強力な認証を使用してこのストレージ アカウントに接続できるようになります。 詳細については、こちらのガイドを参照してください。
重要
PowerShell Azure Resource Manager モジュールは Azure SQL Database で引き続きサポートされますが、今後の開発はすべて Az.Sql
モジュールを対象に行われます。 AzureRM モジュールのバグ修正は、少なくとも 2020 年 12 月までは引き続き受け取ることができます。 Az モジュールと AzureRm モジュールのコマンドの引数は実質的に同じです。 その互換性の詳細については、「新しい Azure PowerShell Az モジュールの概要」を参照してください。
手順
スタンドアロンの専用 SQL プール (旧称 SQL DW) がある場合は、PowerShell を使用して SQL サーバーを Microsoft Entra ID に登録します。
Connect-AzAccount Select-AzSubscription -SubscriptionId <subscriptionId> Set-AzSqlServer -ResourceGroupName your-database-server-resourceGroup -ServerName your-SQL-servername -AssignIdentity
Azure Synapse Analytics ワークスペース内の専用 SQL プールでは、この手順は必要ありません。 ワークスペースのシステム割り当てマネージド ID (SA-MI) は、Synapse 管理者ロールのメンバーであるため、ワークスペースの専用 SQL プールに対する昇格された特権を持っています。
「ストレージ アカウントを作成する」の手順に従って、汎用 v2 ストレージ アカウントを作成します。
- 汎用 v1 または Blob Storage アカウントが存在する場合は、「汎用 v2 ストレージ アカウントにアップグレードする」の手順に従って、"最初に v2 にアップグレードする" 必要があります。
- Azure Data Lake Storage Gen2 に関する既知の問題については、「Azure Data Lake Storage Gen2 に関する既知の問題」を参照してください。
自分のストレージ アカウント ページで [アクセス制御 (IAM)] を選択します。
[追加]>[ロールの割り当ての追加] を選択して、[ロールの割り当ての追加] ページを開きます。
次のロールを割り当てます。 詳細な手順については、「Azure portal を使用して Azure ロールを割り当てる」を参照してください。
設定 値 Role ストレージ BLOB データ共同作成者 アクセスの割り当て先 ユーザー、グループ、またはサービス プリンシパル メンバー Microsoft Entra に登録した専用 SQL プールをホストしているサーバーまたはワークスペース Note
ストレージ アカウントの所有者特権を持つメンバーのみが、この手順を実行できます。 さまざまな Azure の組み込みロールについては、「Azure 組み込みロール」を参照してください。
Azure Storage アカウントへの PolyBase 接続を有効にするには、次のようにします。
データベースのマスター キーをまだ作成していない場合は、作成します。
CREATE MASTER KEY [ENCRYPTION BY PASSWORD = 'somepassword'];
IDENTITY = 'Managed Service Identity' を使用して、データベース スコープ資格情報を作成します。
CREATE DATABASE SCOPED CREDENTIAL msi_cred WITH IDENTITY = 'Managed Service Identity';
このメカニズムは内部的にマネージド ID を使用するため、Azure Storage アクセス キーを使用して SECRET を指定する必要はありません。 Azure Synapse Analytics ワークスペース内の専用 SQL プールでは、この手順は必要ありません。 ワークスペースのシステム割り当てマネージド ID (SA-MI) は、Synapse 管理者ロールのメンバーであるため、ワークスペースの専用 SQL プールに対する昇格された特権を持っています。
仮想ネットワークに対してセキュリティ保護された Azure Storage アカウントを操作するには、PolyBase 接続用の IDENTITY の名前を "Managed Service Identity" にする必要があります。
PolyBase を使用して汎用 v2 ストレージ アカウントに接続するための
abfss://
スキームを使用して外部データ ソースを作成します。CREATE EXTERNAL DATA SOURCE ext_datasource_with_abfss WITH (TYPE = hadoop, LOCATION = 'abfss://myfile@mystorageaccount.dfs.core.windows.net', CREDENTIAL = msi_cred);
- 汎用 v1 または Blob Storage アカウントに外部テーブルが既に関連付けられている場合は、まずそれらの外部テーブルを削除する必要があります。 その後、対応する外部データ ソースを削除します。 次に、前に示したように、汎用 v2 ストレージ アカウントに接続する
abfss://
スキームを使用して外部データ ソースを作成します。 そして、この新しい外部データ ソースを使用して、すべての外部テーブルを再作成します。 [スクリプトの生成とパブリッシュ] ウィザードを使用して、すべての外部テーブルを簡単に作成するスクリプトを生成できます。 abfss://
スキームの詳細については、「Azure Data Lake Storage Gen2 URI を使用する」を参照してください。- T-SQL コマンドの詳細については、CREATE EXTERNAL DATA SOURCE に関するページをご覧ください。
- 汎用 v1 または Blob Storage アカウントに外部テーブルが既に関連付けられている場合は、まずそれらの外部テーブルを削除する必要があります。 その後、対応する外部データ ソースを削除します。 次に、前に示したように、汎用 v2 ストレージ アカウントに接続する
外部テーブルを使用して、通常どおりクエリを実行します。
SQL Database BLOB の監査
Azure SQL 監査では、SQL 監査ログを独自のストレージ アカウントに書き込むことができます。 このストレージ アカウントで仮想ネットワーク サービス エンドポイント機能を使用する場合は、VNet とファイアウォールの背後にあるストレージ アカウントに監査を書き込む方法を参照してください。
仮想ネットワーク ファイアウォール規則をサーバーに追加する
この機能が強化される前は、ライブ仮想ネットワーク規則をファイアウォールに実装するには、仮想ネットワーク サービス エンドポイントを有効にする必要がありました。 それらのエンドポイントが特定の仮想ネットワーク サブネットを SQL Database 内のデータベースに関連付けていました。 2018 年 1 月以降、IgnoreMissingVNetServiceEndpoint フラグを設定することでこの要件を回避できます。 仮想ネットワーク サービス エンドポイントを有効にすることなく、仮想ネットワーク ファイアウォール規則をサーバーに追加できるようになりました。
単にファイアウォール規則を設定するだけでは、サーバーのセキュリティ保護には役立ちません。 セキュリティを有効にするには、仮想ネットワーク サービス エンドポイントを有効にする必要もあります。 サービス エンドポイントをオンにすると、オフからオンへの切り替えが完了するまで仮想ネットワーク サブネットでダウンタイムが発生します。 このダウンタイムの期間は、特に大規模な仮想ネットワークの状況で当てはまります。 IgnoreMissingVNetServiceEndpoint フラグを使用すると、切り替え中のダウンタイムを軽減するか、なくすことができます。
PowerShell を使用して、IgnoreMissingVNetServiceEndpoint フラグを設定できます。 詳細については、PowerShell での仮想ネットワーク サービス エンドポイントと SQL Database の規則の作成に関する記事を参照してください。
Note
Azure Synapse Analytics での同様の手順については、「Azure Synapse Analytics の IP ファイアウォール規則」を参照してください
Azure portal を使用して仮想ネットワーク規則を作成する
このセクションでは、Azure portal を使用して、SQL Database 内のデータベースに "仮想ネットワーク規則" を作成する方法について説明します。 この規則は、"仮想ネットワーク サービス エンドポイント" としてタグ付けされた特定のサブネットからの通信を許可するようにデータベースに指示します。
Note
サーバーの仮想ネットワーク ファイアウォール規則にサービス エンドポイントを追加する場合は、まず、サービス エンドポイントがそのサブネットに対して有効になっていることを確認します。
サービス エンドポイントがサブネットに対して有効になっていない場合、それらを有効にするようポータルから求められます。 規則を追加する場合と同じペインの [有効化] ボタンを選択してください。
前提条件
保持している 1 つのサブネットが、SQL Database に関連する特定の仮想ネットワーク サービス エンドポイントの "種類名" で既にタグ付けされている必要があります。
- 関連するエンドポイントの種類名は Microsoft.Sql です。
- サブネットが種類名でタグ付けされていない場合は、「自分のサブネットがエンドポイントであることを確認する」をご覧ください。
Azure Portal の手順
Azure portal にサインインします。
SQL サーバーを検索して選択してから、使用するサーバーを選択します。 [セキュリティ] で [ネットワーク] を選択します。
[パブリック アクセス] タブで、[パブリック ネットワーク アクセス] が [ネットワークの選択] に設定されていることを確実にします。それ以外の場合、[仮想ネットワーク] の設定は非表示になります。 [仮想ネットワーク] セクションで [+ 既存の仮想ネットワークを追加] を選択します。
新しい [作成/更新] ペインで、お使いの Azure リソースの名前をボックスに入力します。
ヒント
お使いのサブネットの正しいアドレス プレフィックスを含める必要があります。 [アドレス プレフィックス] 値はポータルで確認できます。 [すべてのリソース]>[すべての種類]>[仮想ネットワーク] の順に移動します。 フィルターにお使いの仮想ネットワークが表示されます。 仮想ネットワークを選択し、 [サブネット] を選択します。 [アドレス範囲] 列に、必要なアドレス プレフィックスが含まれています。
[ファイアウォール] ペインで結果の仮想ネットワーク規則を確認します。
[Azure サービスおよびリソースにこのサーバーへのアクセスを許可する] を [いいえ] に設定します。
重要
[Azure サービスおよびリソースにこのサーバーへのアクセスを許可する] をオンのままにすると、サーバーは Azure 境界内の任意のサブネットからの通信を受け付けます。 これは、Azure データセンター用に定義された範囲内として認識された IP アドレスのいずれかから発信された通信です。 この制御を有効にしたままにすると、セキュリティの観点から見れば過度なアクセスになる可能性があります。 Microsoft Azure Virtual Network サービス エンドポイント機能は、SQL Database の仮想ネットワーク規則機能と共に使用することで、セキュリティ脅威にさらされる領域を減少させることができます。
ペインの下部付近にある [OK] ボタンを選択します。
Note
規則には次の状態が適用されます。
- 準備完了:開始した操作が成功したことを示します。
- [失敗] : 開始した操作が失敗したことを示します。
- 削除済み:
Delete
操作にのみ適用されます。規則が削除され、適用されなくなったことを示します。 - 進行中:操作が進行中であることを示します。 操作がこの状態にある間は、古い規則が適用されます。
PowerShell を使用して仮想ネットワーク規則を作成する
スクリプトで PowerShell コマンドレット New-AzSqlServerVirtualNetworkRule
または az network vnet create を使用して、仮想ネットワーク規則を作成することもできます。 詳細については、PowerShell での仮想ネットワーク サービス エンドポイントと SQL Database の規則の作成に関する記事を参照してください。
REST API を使用して仮想ネットワーク規則を作成する
SQL 仮想ネットワーク アクション用の PowerShell コマンドレットは、内部的に REST API を呼び出します。 REST API を直接呼び出すことができます。 詳細については、仮想ネットワーク規則: 操作に関するページをご覧ください。
エラー 40914 および 40615
接続エラー 40914 は、Azure portal の [ファイアウォール] ペインで指定されている "仮想ネットワーク規則" に関係があります。
エラー 40615 も同様ですが、ファイアウォールでの "IP アドレス規則" に関係している点が異なります。
エラー 40914
メッセージ テキスト: "Cannot open server '[server-name]' requested by the login. (ログインにより要求されたサーバー ' [server-name] ' を開くことができません。) Client is not allowed to access the server. (クライアントはサーバーへのアクセスを許可されていません。)"
エラーの説明: クライアントは、仮想ネットワーク サーバーのエンドポイントを持つサブネット内にあります。 しかし、サーバーには、データベースと通信する権限をサブネットに付与する仮想ネットワーク規則がありません。
エラーの解決策: Azure portal の [ファイアウォール] ペインで、仮想ネットワーク規則コントロールを使用して、サブネットの仮想ネットワーク規則を追加します。
エラー 40615
メッセージ テキスト: "Cannot open server '{0}' requested by the login. (ログインにより要求されたサーバー '{0}' を開くことができません。) Client with IP address '{1}' is not allowed to access the server. (IP アドレス '{1}' のクライアントはこのサーバーへのアクセスを許可されていません。)"
エラーの説明: サーバーへの接続を許可されていない IP アドレスからクライアントが接続しようとしています。 サーバーのファイアウォールには、指定された IP アドレスからデータベースへの通信をクライアントに許可する IP アドレス規則がありません。
エラーの解決策: IP ルールとしてクライアントの IP アドレスを入力します。 この手順を実行するには、Azure portal の [ファイアウォール] ペインを使用します。