Azure SQL Database のサーバー用の仮想ネットワーク サービス エンドポイントと規則の使用Use virtual network service endpoints and rules for servers in Azure SQL Database

適用対象: Azure SQL Database Azure Synapse Analytics (SQL DW)

"仮想ネットワーク規則" は 1 つのファイアウォール セキュリティ機能であり、Azure SQL Database 内のデータベースおよびエラスティック プール用、または Azure Synapse 内のデータベース用のサーバーが、仮想ネットワーク内の特定のサブネットから送信される通信を許可するかどうかを制御します。Virtual network rules are one firewall security feature that controls whether the server for your databases and elastic pools in Azure SQL Database or for your databases in Azure Synapse accepts communications that are sent from particular subnets in virtual networks. この記事では、仮想ネットワーク規則機能が、場合によっては Azure SQL Database と Azure Synapse Analytics (以前の SQL Data Warehouse) のデータベースへの通信を安全に許可するための最適な選択肢となる理由を説明します。This article explains why the virtual network rule feature is sometimes your best option for securely allowing communication to your database in Azure SQL Database and Azure Synapse Analytics (formerly SQL Data Warehouse).

注意

この記事は、Azure SQL Database と Azure Synapse Analytics の両方に適用されます。This article applies to both Azure SQL Database and Azure Synapse Analytics. 単純にするために、"データベース" という言葉で Azure SQL Database と Azure Synapse Analytics の両方のデータベースを表すことにします。For simplicity, the term 'database' refers to both databases in Azure SQL Database and Azure Synapse Analytics. 同様に、"サーバー" という言葉は、Azure SQL Database と Azure Synapse Analytics をホストする論理 SQL サーバーを表しています。Likewise, any references to 'server' is referring to the logical SQL server that hosts Azure SQL Database and Azure Synapse Analytics.

仮想ネットワーク規則を作成するには、まず、参照する規則の仮想ネットワーク サービス エンドポイントが必要です。To create a virtual network rule, there must first be a virtual network service endpoint for the rule to reference.

仮想ネットワーク規則の作成方法How to create a virtual network rule

仮想ネットワーク規則を作成するだけであれば、途中を読み飛ばして、この記事で後述している手順と説明に進んでください。If you only create a virtual network rule, you can skip ahead to the steps and explanation later in this article.

仮想ネットワーク規則の詳細Details about virtual network rules

このセクションでは、仮想ネットワーク規則に関する詳細について、いくつか説明します。This section describes several details about virtual network rules.

geography 型の 1 つのリージョンのみOnly one geographic region

各仮想ネットワーク サービス エンドポイントは、1 つの Azure リージョンだけに適用されます。Each Virtual Network service endpoint applies to only one Azure region. エンドポイントが他のリージョンを有効にして、サブネットからの通信を許可することはありません。The endpoint does not enable other regions to accept communication from the subnet.

どの仮想ネットワーク規則も、その基本となるエンドポイントが適用先のリージョンに制限されます。Any virtual network rule is limited to the region that its underlying endpoint applies to.

データベース レベルではなく、サーバー レベルServer-level, not database-level

各仮想ネットワーク規則は、サーバー上の 1 つの特定のデータベースだけではなく、お使いのサーバー全体に適用されます。Each virtual network rule applies to your whole server, not just to one particular database on the server. 言い換えると、仮想ネットワーク規則はデータベース レベルではなく、サーバー レベルに適用されます。In other words, virtual network rule applies at the server-level, not at the database-level.

  • 対照的に、IP 規則はどちらのレベルにも適用できます。In contrast, IP rules can apply at either level.

セキュリティ管理ロールSecurity administration roles

仮想ネットワーク サービス エンドポイントの管理では、セキュリティ ロールが分離されています。There is a separation of security roles in the administration of Virtual Network service endpoints. 以下の各ロールでは、次の操作が必要です。Action is required from each of the following roles:

  • ネットワーク管理者:   エンドポイントを有効にします。Network Admin:   Turn on the endpoint.
  • データベース管理者:  アクセス制御リスト (ACL) を更新して、指定されたサブネットをサーバーに追加します。Database Admin:   Update the access control list (ACL) to add the given subnet to the server.

RBAC による代替:RBAC alternative:

ネットワーク管理およびデータベース管理のロールには、仮想ネットワーク規則の管理に必要とされる機能以外もあります。The roles of Network Admin and Database Admin have more capabilities than are needed to manage virtual network rules. それらの機能のうち 1 つのサブネットだけが必要になります。Only a subset of their capabilities is needed.

必要な機能のサブセットのみを保持する単一のカスタム ロールを作成するために、Azure には Azure ロールベースのアクセス制御 (Azure RBAC) を使用するオプションがあります。You have the option of using Azure role-based access control (Azure RBAC) in Azure to create a single custom role that has only the necessary subset of capabilities. ネットワーク管理またはデータベース管理に関連付ける代わりに、カスタム ロールを使用できます。カスタム ロールにユーザーを追加する場合と、他の 2 つの主要な管理者ロールにユーザーを追加する場合では、前者の方がセキュリティ脅威にさらされる領域が少なくなります。The custom role could be used instead of involving either the Network Admin or the Database Admin. The surface area of your security exposure is lower if you add a user to a custom role, versus adding the user to the other two major administrator roles.

注意

Azure SQL Database 内のデータベースと VNet サブネットが異なるサブスクリプションに存在する場合があります。In some cases the database in Azure SQL Database and the VNet-subnet are in different subscriptions. このような場合は、次の構成を確認する必要があります。In these cases you must ensure the following configurations:

  • 両方のサブスクリプションが同じ Azure Active Directory テナントに存在する必要がある。Both subscriptions must be in the same Azure Active Directory tenant.
  • ユーザーに操作 (サービス エンドポイントの有効化や、特定のサーバーへの VNet サブネットの追加など) を開始するために必要な権限がある。The user has the required permissions to initiate operations, such as enabling service endpoints and adding a VNet-subnet to the given Server.
  • 両方のサブスクリプションに Microsoft.Sql プロバイダーが登録されている。Both subscriptions must have the Microsoft.Sql provider registered.

制限事項Limitations

Azure SQL Database の場合、仮想ネットワーク規則機能には以下のような制限事項があります。For Azure SQL Database, the virtual network rules feature has the following limitations:

  • Azure SQL Database 内のデータベースのファイアウォールでは、各仮想ネットワーク規則はサブネットを参照します。In the firewall for your database in Azure SQL Database, each virtual network rule references a subnet. これらの参照されるサブネットはすべて、データベースがホストされているのと同じ地理的リージョンでホストされている必要があります。All these referenced subnets must be hosted in the same geographic region that hosts the database.

  • 各サーバーは、指定された仮想ネットワークに対して最大 128 個までの ACL エントリを保持できます。Each server can have up to 128 ACL entries for any given virtual network.

  • 仮想ネットワーク規則はクラシック デプロイ モデル ネットワークではなく、Azure Resource Manager の仮想ネットワークのみに適用されます。Virtual network rules apply only to Azure Resource Manager virtual networks; and not to classic deployment model networks.

  • Azure SQL Database に対する仮想ネットワーク サービス エンドポイントを有効にすると、MySQL および PostgreSQL Azure サービスに対してもエンドポイントが有効になります。Turning ON virtual network service endpoints to Azure SQL Database also enables the endpoints for the MySQL and PostgreSQL Azure services. ただし、エンドポイントを有効にすると、エンドポイントから MySQL または PostgreSQL インスタンスへの接続の試行は失敗します。However, with endpoints ON, attempts to connect from the endpoints to your MySQL or PostgreSQL instances may fail.

    • 根本的な理由は、MySQL および PostgreSQL には仮想ネットワーク規則が構成されていない可能性があるためです。The underlying reason is that MySQL and PostgreSQL likely do not have a virtual network rule configured. 接続を成功させるには、Azure Database for MySQL と Azure Database for PostgreSQL の仮想ネットワーク規則を構成する必要があります。You must configure a virtual network rule for Azure Database for MySQL and PostgreSQL and the connection will succeed.
  • ファイアウォールでは、IP アドレスは以下のネットワーク項目に適用されますが、仮想ネットワーク規則は適用されません。On the firewall, IP address ranges do apply to the following networking items, but virtual network rules do not:

サービス エンドポイントを使用する場合の考慮事項Considerations when using Service Endpoints

Azure SQL Database のサービス エンドポイントを使用する場合、次の考慮事項を確認してください。When using service endpoints for Azure SQL Database, review the following considerations:

  • Azure SQL Database のパブリック IP へのアウトバウンドが必要:ネットワーク セキュリティ グループ (NSG) は、接続を許可するために Azure SQL Database IP に対して開かれている必要があります。Outbound to Azure SQL Database Public IPs is required: Network Security Groups (NSGs) must be opened to Azure SQL Database IPs to allow connectivity. Azure SQL Database に NSG のサービス タグを使用して、この設定を行うことができます。You can do this by using NSG Service Tags for Azure SQL Database.

ExpressRouteExpressRoute

パブリック ピアリングまたは Microsoft ピアリングのためにオンプレミスから ExpressRoute を使用している場合、使用されている NAT の IP アドレスを識別する必要があります。If you are using ExpressRoute from your premises, for public peering or Microsoft peering, you will need to identify the NAT IP addresses that are used. パブリック ピアリングの場合、既定で、Azure サービスのトラフィックが Microsoft Azure のネットワーク バックボーンに入ったときに適用される 2 つの NAT IP アドレスが各 ExpressRoute 回線に使用されます。For public peering, each ExpressRoute circuit by default uses two NAT IP addresses applied to Azure service traffic when the traffic enters the Microsoft Azure network backbone. Microsoft ピアリングの場合、使用される NAT の IP アドレスは、ユーザーが指定するか、サービス プロバイダーが指定します。For Microsoft peering, the NAT IP address(es) that are used are either customer provided or are provided by the service provider. サービス リソースへのアクセスを許可するには、リソースの IP ファイアウォール設定でこれらのパブリック IP アドレスを許可する必要があります。To allow access to your service resources, you must allow these public IP addresses in the resource IP firewall setting. パブリック ピアリングの ExpressRoute 回線の IP アドレスを確認するには、Azure Portal から ExpressRoute のサポート チケットを開いてください。To find your public peering ExpressRoute circuit IP addresses, open a support ticket with ExpressRoute via the Azure portal. 詳細については、ExpressRoute のパブリック ピアリングと Microsoft ピアリングの NAT に関するセクションを参照してください。Learn more about NAT for ExpressRoute public and Microsoft peering.

回線から Azure SQL Database への通信を許可するには、NAT のパブリック IP アドレスに対する IP ネットワーク規則を作成する必要があります。To allow communication from your circuit to Azure SQL Database, you must create IP network rules for the public IP addresses of your NAT.

Azure Storage で VNet サービス エンドポイントを使用した場合の影響Impact of using VNet Service Endpoints with Azure storage

Azure Storage は、Azure ストレージ アカウントへの接続を制限できる同じ機能を実装しています。Azure Storage has implemented the same feature that allows you to limit connectivity to your Azure Storage account. Azure SQL Database で使用されている Azure ストレージ アカウントでこの機能を使用することにした場合は、問題が発生する可能性があります。If you choose to use this feature with an Azure Storage account that is being used by Azure SQL Database, you can run into issues. 次に、この影響を受ける Azure SQL Database と Azure Synapse Analytics の機能の一覧と説明を示します。Next is a list and discussion of Azure SQL Database and Azure Synapse Analytics features that are impacted by this.

Azure Synapse PolyBase と COPY ステートメントAzure Synapse PolyBase and COPY statement

PolyBase と COPY ステートメントは、高スループットのデータ インジェストのために、Azure Storage アカウントから Azure Synapse Analytics にデータを読み込むために一般的に使用されます。PolyBase and the COPY statement is commonly used to load data into Azure Synapse Analytics from Azure Storage accounts for high throughput data ingestion. データを読み込んでいる Azure Storage アカウントでアクセスが一連の VNet サブネットだけに制限されている場合は、ストレージ アカウントへの PolyBase と COPY ステートメントを使用した接続は切断されます。If the Azure Storage account that you are loading data from limits access only to a set of VNet-subnets, connectivity when using PolyBase and the COPY statement to the storage account will break. VNet に対してセキュリティ保護された Azure Storage に接続している Azure Synapse Analytics で COPY と PolyBase を使用したインポートおよびエクスポート シナリオを有効にするには、下に示されている手順に従います。For enabling import and export scenarios using COPY and PolyBase with Azure Synapse Analytics connecting to Azure Storage that's secured to VNet, follow the steps indicated below:

前提条件Prerequisites

  • このガイドを使用して、Azure PowerShell をインストールします。Install Azure PowerShell using this guide.
  • 汎用 v1 または BLOB ストレージ アカウントを使用している場合は、このガイドを使用して、最初に汎用 v2 にアップグレードする必要があります。If you have a general-purpose v1 or blob storage account, you must first upgrade to general-purpose v2 using this guide.
  • Azure ストレージ アカウントの [Firewalls and Virtual networks](ファイアウォールと仮想ネットワーク) 設定メニューで、 [Allow trusted Microsoft services to access this storage account](信頼された Microsoft サービスによるこのストレージ アカウントに対するアクセスを許可します) をオンにする必要があります。You must have Allow trusted Microsoft services to access this storage account turned on under Azure Storage account Firewalls and Virtual networks settings menu. この構成を有効にすると、PolyBase と COPY ステートメントは、ネットワーク トラフィックが Azure バックボーン上に残る強力な認証を使用してこのストレージ アカウントに接続できるようになります。Enabling this configuration will allow PolyBase and the COPY statement to connect to the storage account using strong authentication where network traffic remains on the Azure backbone. 詳しくは、このガイドをご覧ください。Refer to this guide for more information.

重要

PowerShell Azure Resource Manager モジュールは Azure SQL Database で引き続きサポートされますが、今後の開発はすべて Az.Sql モジュールを対象に行われます。The PowerShell Azure Resource Manager module is still supported by Azure SQL Database, but all future development is for the Az.Sql module. AzureRM モジュールのバグ修正は、少なくとも 2020 年 12 月までは引き続き受け取ることができます。The AzureRM module will continue to receive bug fixes until at least December 2020. Az モジュールと AzureRm モジュールのコマンドの引数は実質的に同じです。The arguments for the commands in the Az module and in the AzureRm modules are substantially identical. その互換性の詳細については、「新しい Azure PowerShell Az モジュールの概要」を参照してください。For more about their compatibility, see Introducing the new Azure PowerShell Az module.

手順Steps

  1. PowerShell で、Azure Synapse をホストしているサーバーを、Azure Active Directory (AAD) に登録しますIn PowerShell, register your server hosting Azure Synapse with Azure Active Directory (AAD):

    Connect-AzAccount
    Select-AzSubscription -SubscriptionId <subscriptionId>
    Set-AzSqlServer -ResourceGroupName your-database-server-resourceGroup -ServerName your-SQL-servername -AssignIdentity
    
  2. このガイドを使用して、汎用 v2 ストレージ アカウントを作成します。Create a general-purpose v2 Storage Account using this guide.

    注意

    • 汎用 v1 または BLOB ストレージ アカウントを使用している場合は、このガイドを使用して、最初に v2 にアップグレードする必要があります。If you have a general-purpose v1 or blob storage account, you must first upgrade to v2 using this guide.
    • Azure Data Lake Storage Gen2 に関する既知の問題については、このガイドをご覧ください。For known issues with Azure Data Lake Storage Gen2, please refer to this guide.
  3. お使いのストレージ アカウントで、 [アクセス制御 (IAM)] に移動し、 [ロール割り当ての追加] を選択します。Under your storage account, navigate to Access Control (IAM), and select Add role assignment. 手順 1 で Azure Active Directory (AAD) に登録した Azure Synapse Analytics をホストするサーバーに、ストレージ BLOB データ共同作成者 Azure ロールを割り当てます。Assign Storage Blob Data Contributor Azure role to the server hosting your Azure Synapse Analytics which you've registered with Azure Active Directory (AAD) as in step #1.

    注意

    ストレージ アカウントの所有者特権を持つメンバーのみが、この手順を実行できます。Only members with Owner privilege on the storage account can perform this step. さまざまな Azure の組み込みロールについては、こちらのガイドをご覧ください。For various Azure built-in roles, refer to this guide.

  4. Azure ストレージ アカウントへの Polybase 接続:Polybase connectivity to the Azure Storage account:

    1. データベースの マスター キー をまだ作成していない場合は、作成します。Create a database master key if you haven't created one earlier:

      CREATE MASTER KEY [ENCRYPTION BY PASSWORD = 'somepassword'];
      
    2. IDENTITY = 'Managed Service Identity' を使用して、データベース スコープ資格情報を作成します。Create database scoped credential with IDENTITY = 'Managed Service Identity':

      CREATE DATABASE SCOPED CREDENTIAL msi_cred WITH IDENTITY = 'Managed Service Identity';
      

      注意

      • このメカニズムは内部的にマネージド ID を使用するため、Azure Storage アクセス キーにシークレットを指定する必要はありません。There is no need to specify SECRET with Azure Storage access key because this mechanism uses Managed Identity under the covers.
      • VNet に結び付けられた Azure ストレージ アカウントを PolyBase 接続で操作するためには、ID の名前を "Managed Service Identity" にする必要があります。IDENTITY name should be 'Managed Service Identity' for PolyBase connectivity to work with Azure Storage account secured to VNet.
    3. PolyBase を使用して汎用 v2 ストレージ アカウントに接続するための abfss:// スキームを使用して外部データ ソースを作成します。Create external data source with abfss:// scheme for connecting to your general-purpose v2 storage account using PolyBase:

      CREATE EXTERNAL DATA SOURCE ext_datasource_with_abfss WITH (TYPE = hadoop, LOCATION = 'abfss://myfile@mystorageaccount.dfs.core.windows.net', CREDENTIAL = msi_cred);
      

      注意

      • 汎用 v1 または BLOB ストレージ アカウントに外部テーブルが既に関連付けられている場合は、まずそれらの外部テーブルを削除した後、対応する外部データ ソースを削除する必要があります。If you already have external tables associated with general-purpose v1 or blob storage account, you should first drop those external tables and then drop corresponding external data source. 次に、上に示すように汎用 v2 ストレージ アカウントに接続する abfss:// スキームを使用して外部データ ソースを作成し、この新しい外部データ ソースを使用してすべての外部テーブルを再作成します。Then create external data source with abfss:// scheme connecting to general-purpose v2 storage account as above and re-create all the external tables using this new external data source. スクリプトの生成とパブリッシュ ウィザードを使用して、すべての外部テーブルを簡単に作成するスクリプトを生成できます。You could use Generate and Publish Scripts Wizard to generate create-scripts for all the external tables for ease.
      • abfss:// スキームの詳細については、このガイドを参照してください。For more information on abfss:// scheme, refer to this guide.
      • 外部データ ソースの作成の詳細については、このガイドをご覧ください。For more information on CREATE EXTERNAL DATA SOURCE, refer to this guide.
    4. 外部テーブルを使用して、通常どおりクエリを実行します。Query as normal using external tables.

Azure SQL Database BLOB の監査Azure SQL Database Blob Auditing

BLOB 監査では、監査ログをユーザー独自のストレージ アカウントにプッシュします。Blob auditing pushes audit logs to your own storage account. このストレージ アカウントが VNet サービス エンドポイント機能を使用している場合、Azure SQL Database からストレージ アカウントへの接続は切断されます。If this storage account uses the VNet Service endpoints feature then connectivity from Azure SQL Database to the storage account will break.

VNet サービス エンドポイントをオンにすることなく VNet ファイアウォール規則をサーバーに追加するAdding a VNet Firewall rule to your server without turning On VNet Service Endpoints

この機能が強化される以前は、ライブ VNet ルールをファイアウォールに実装するには、VNet サービス エンドポイントをオンにする必要がありました。Long ago, before this feature was enhanced, you were required to turn VNet service endpoints On before you could implement a live VNet rule in the Firewall. エンドポイントが特定の VNet サブネットを Azure SQL Database 内のデータベースに関連付けていました。The endpoints related a given VNet-subnet to a database in Azure SQL Database. しかし、2018 年 1 月現在からは、IgnoreMissingVNetServiceEndpoint フラグを設定することでこの要件を回避できます。But now as of January 2018, you can circumvent this requirement by setting the IgnoreMissingVNetServiceEndpoint flag.

単にファイアウォール規則を設定するだけでは、サーバーのセキュリティ保護には役立ちません。Merely setting a Firewall rule does not help secure the server. セキュリティを有効にするには、VNet サービス エンドポイントをオンにする必要もあります。You must also turn VNet service endpoints On for the security to take effect. サービス エンドポイントをオンにする場合、オフからオンへの切り替えが完了するまで VNet サブネットでダウンタイムが発生します。When you turn service endpoints On, your VNet-subnet experiences downtime until it completes the transition from Off to On. これは、大規模 VNet のコンテキストに特に当てはまります。This is especially true in the context of large VNets. IgnoreMissingVNetServiceEndpoint フラグを使用すると、切り替え中のダウンタイムを軽減するか、なくすことができます。You can use the IgnoreMissingVNetServiceEndpoint flag to reduce or eliminate the downtime during transition.

PowerShell を使用して、IgnoreMissingVNetServiceEndpoint フラグを設定できます。You can set the IgnoreMissingVNetServiceEndpoint flag by using PowerShell. 詳細については、PowerShell での仮想ネットワーク サービス エンドポイントと Azure SQL Database の規則の作成に関する記事をご覧ください。For details, see PowerShell to create a Virtual Network service endpoint and rule for Azure SQL Database.

エラー 40914 および 40615Errors 40914 and 40615

接続エラー 40914 は、Azure Portal の [ファイアウォール] ウィンドウで指定されている "仮想ネットワーク規則" に関係があります。Connection error 40914 relates to virtual network rules, as specified on the Firewall pane in the Azure portal. エラー 40615 も同様ですが、ファイアウォールでの "IP アドレス規則" に関係している点が異なります。Error 40615 is similar, except it relates to IP address rules on the Firewall.

エラー 40914Error 40914

メッセージ テキスト: ログインで要求されたサーバー ' [サーバー名] ' を開くことができません。Message text: Cannot open server '[server-name]' requested by the login. クライアントはサーバーへのアクセスが許可されていません。Client is not allowed to access the server.

エラーの説明: クライアントは、仮想ネットワーク サーバーのエンドポイントを持つサブネット内にあります。Error description: The client is in a subnet that has virtual network server endpoints. しかし、サーバーには、データベースと通信する権限をサブネットに付与する仮想ネットワーク規則がありません。But the server has no virtual network rule that grants to the subnet the right to communicate with the database.

エラーの解決策: Azure portal の [ファイアウォール] ウィンドウで、仮想ネットワーク規則 コントロールを使って、サブネットの仮想ネットワーク規則を追加します。Error resolution: On the Firewall pane of the Azure portal, use the virtual network rules control to add a virtual network rule for the subnet.

エラー 40615Error 40615

メッセージ テキスト: ログインにより要求されたサーバー {0} を開けません。Message text: Cannot open server '{0}' requested by the login. IP アドレス '{1}' のクライアントはこのサーバーへのアクセスが許可されていません。Client with IP address '{1}' is not allowed to access the server.

エラーの説明: クライアントは、サーバーへの接続を許可されていない IP アドレスから接続しようとしています。Error description: The client is trying to connect from an IP address that is not authorized to connect to the server. サーバーのファイアウォールには、指定された IP アドレスからデータベースへの通信をクライアントに許可する IP アドレス規則がありません。The server firewall has no IP address rule that allows a client to communicate from the given IP address to the database.

エラーの解決策: IP ルールとしてクライアントの IP アドレスを入力します。Error resolution: Enter the client's IP address as an IP rule. それには、Azure Portal の [ファイアウォール] ウィンドウを使います。Do this by using the Firewall pane in the Azure portal.

Portal で仮想ネットワーク規則を作成するPortal can create a virtual network rule

このセクションでは、Azure portal を使用して、お使いの Azure SQL Database 内のデータベースに "仮想ネットワーク規則" を作成する方法を説明します。This section illustrates how you can use the Azure portal to create a virtual network rule in your database in Azure SQL Database. この規則は、"仮想ネットワーク サービス エンドポイント" としてタグ付けされた特定のサブネットからの通信を許可するように、お使いのデータベースに指示します。The rule tells your database to accept communication from a particular subnet that has been tagged as being a Virtual Network service endpoint.

注意

サーバーの VNet ファイアウォール規則にサービス エンドポイントを追加する場合は、まず、そのサブネットに対するサービス エンドポイントを有効にする必要があります。If you intend to add a service endpoint to the VNet firewall rules of your server, first ensure that service endpoints are turned On for the subnet.

サブネットに対するサービス エンドポイントが有効になっていない場合、それらを有効にするようポータルから求められます。If service endpoints are not turned on for the subnet, the portal asks you to enable them. 規則を追加するブレードの [有効にする] ボタンをクリックしてください。Click the Enable button on the same blade on which you add the rule.

PowerShell による代替PowerShell alternative

スクリプトでは、PowerShell コマンドレット New-AzSqlServerVirtualNetworkRule または az network vnet create を使用して仮想ネットワーク規則を作成することもできます。A script can also create virtual network rules using PowerShell cmdlet New-AzSqlServerVirtualNetworkRule or az network vnet create. ご興味がある方は、PowerShell での仮想ネットワーク サービス エンドポイントと Azure SQL Database の規則の作成に関する記事をご覧ください。If interested, see PowerShell to create a Virtual Network service endpoint and rule for Azure SQL Database.

REST API の代替手段REST API alternative

内部的には、SQL VNet アクション用の PowerShell コマンドレットは REST API を呼び出します。Internally, the PowerShell cmdlets for SQL VNet actions call REST APIs. REST API を直接呼び出すことができます。You can call the REST APIs directly.

前提条件Prerequisites

保持している 1 つのサブネットが、Azure SQL Database に関連する特定の Virtual Network エンドポイントの種類名で既にタグ付けされている必要があります。You must already have a subnet that is tagged with the particular Virtual Network service endpoint type name relevant to Azure SQL Database.

Azure Portal の手順Azure portal steps

  1. Azure portal にサインインします。Sign in to the Azure portal.

  2. SQL サーバーを検索して選択してから、使用するサーバーを選択します。Search for and select SQL servers, then select your server. [セキュリティ] で、 [ファイアウォールと仮想ネットワーク] を選択します。Under Security, select Firewalls and virtual networks.

  3. [Azure サービスへのアクセスを許可] の制御を [オフ] に設定します。Set the Allow access to Azure services control to OFF.

    重要

    制御を [オン] に設定したままにすると、サーバーは、Azure の境界内のすべてのサブネットからの通信 (つまり、Azure データ センターに定義された範囲内にあるものとして認識されたいずれかの IP アドレスからの発信) を受け入れます。If you leave the control set to ON, your server accepts communication from any subnet inside the Azure boundary i.e. originating from one of the IP addresses that is recognized as those within ranges defined for Azure data centers. 制御を [オン] に設定したままにすると、セキュリティの観点からアクセス過多になる可能性があります。Leaving the control set to ON might be excessive access from a security point of view. Microsoft Azure 仮想ネットワーク サービス エンドポイント機能は、SQL Database の仮想ネットワーク規則機能と共に使用することで、セキュリティ脅威にさらされる領域を減少させることができます。The Microsoft Azure Virtual Network service endpoint feature, in coordination with the virtual network rule feature of SQL Database, together can reduce your security surface area.

  4. [仮想ネットワーク] セクションにある [既存の追加] コントロールをクリックします。Click the + Add existing control, in the Virtual networks section.

    [既存の追加] (SQL 規則としてのサブネット エンドポイント) をクリックします。

  5. 新しい [作成/更新] ペインで、お使いの Azure リソース名をコントロールに入力します。In the new Create/Update pane, fill in the controls with the names of your Azure resources.

    ヒント

    お使いのサブネットの正しいアドレス プレフィックスを含める必要があります。You must include the correct Address prefix for your subnet. ポータルで値を確認できます。You can find the value in the portal. [すべてのリソース] > [すべての種類] > [仮想ネットワーク] の順に移動します。Navigate All resources > All types > Virtual networks. フィルターにお使いの仮想ネットワークが表示されます。The filter displays your virtual networks. お使いの仮想ネットワークをクリックし、 [サブネット] をクリックします。Click your virtual network, and then click Subnets. ADDRESS RANGE 列に、必要なアドレス プレフィックスが含まれています。The ADDRESS RANGE column has the Address prefix you need.

    新しい規則のフィールドを入力します。

  6. ペイン下部付近にある [OK] ボタンをクリックします。Click the OK button near the bottom of the pane.

  7. ファイアウォール ペインで結果の仮想ネットワーク規則を確認します。See the resulting virtual network rule on the firewall pane.

    ファイアウォール ペインで新しい規則を確認する

注意

規則には次の状態が適用されます。The following statuses or states apply to the rules:

  • 準備完了: 開始した操作が成功したことを示します。Ready: Indicates that the operation that you initiated has Succeeded.
  • 失敗: 開始した操作が失敗したことを示します。Failed: Indicates that the operation that you initiated has Failed.
  • 削除済み: 削除操作にのみ適用されます。ルールが削除され、適用されなくなったことを示します。Deleted: Only applies to the Delete operation, and indicates that the rule has been deleted and no longer applies.
  • 進行中: 操作が進行中であることを示します。InProgress: Indicates that the operation is in progress. 操作がこの状態にある間は、古い規則が適用されます。The old rule applies while the operation is in this state.

次のステップNext steps