Azure Database for PostgreSQL - フレキシブル サーバーのネットワークの概要

  • [アーティクル]

適用対象: Azure Database for PostgreSQL - フレキシブル サーバー

この記事では、Azure Database for PostgreSQL - フレキシブル サーバーの接続とネットワークの概念について説明します。

Azure Database for PostgreSQL - フレキシブル サーバー インスタンス ("フレキシブル サーバー") を作成する際、次のいずれかのネットワーク オプションを選択する必要があります: プライベート アクセス (VNet 統合) またはパブリック アクセス (許可された IP アドレス)。

Note

サーバーの作成後にネットワーク オプションを変更することはできません。

プライベート アクセスまたはパブリック アクセスのどちらのオプションを使用するかに関係なく、次の特性が適用されます。

  • 許可された IP アドレスからの接続では、有効な資格情報を使用して PostgreSQL サーバーに対して認証を行う必要があります。
  • ネットワーク トラフィックに対して接続の暗号化が適用されます。
  • サーバーには完全修飾ドメイン名 (FQDN) があります。 接続文字列の hostname プロパティには、IP アドレスではなく FQDN を使用することをお勧めします。
  • どちらのオプションでも、データベースまたはテーブルのレベルではなく、サーバー レベルでアクセスが制御されます。 PostgreSQL のロールのプロパティを使用して、データベース、テーブル、その他のオブジェクトのアクセスを制御します。

Note

Azure Database for PostgreSQL はマネージド データベース サービスであるため、pg_hba.conf などの構成ファイルを表示、変更するためのホストまたは OS アクセスはユーザーに提供されません。 ファイルの内容は、ネットワーク設定に基づいて自動的に更新されます。

プライベート アクセス (VNet 統合)

フレキシブル サーバーは、Azure 仮想ネットワーク (VNet) にデプロイできます。 Azure の仮想ネットワークでは、非公開の、セキュリティで保護されたネットワーク通信が提供されます。 仮想ネットワーク内のリソースは、このネットワークで割り当てられたプライベート IP アドレスを介して通信できます。

次の機能が必要な場合は、このネットワーク オプションを選択します。

  • プライベート IP アドレスを使用して、同じ仮想ネットワーク内の Azure リソースからフレキシブル サーバーに接続する。
  • VPN または Azure ExpressRoute を使用して Azure 以外のリソースからフレキシブル サーバーに接続する。
  • フレキシブル サーバーが、インターネット経由でアクセスできるパブリック エンドポイントを持たないようにする。

いずれかにフレキシブル サーバーが含まれている仮想ネットワーク間のピアリングのしくみを示す図。

前の図で:

  • フレキシブル サーバーは、VNet-1 仮想ネットワークのサブネット 10.0.1.0/24 に導入されています。
  • 同じ仮想ネットワーク内の異なるサブネットにデプロイされたアプリケーションは、フレキシブル サーバーに直接アクセスできます。
  • 別の仮想ネットワーク (VNet-2) にデプロイされたアプリケーションは、フレキシブル サーバーに直接アクセスできません。 それらがフレキシブル サーバーにアクセスできるようにするには、プライベート DNS ゾーンの仮想ネットワーク ピアリングを実行する必要があります。

仮想ネットワークの概念

Azure 仮想ネットワークには、用途に合わせて構成されたプライベート IP アドレス空間が含まれます。 ご利用の仮想ネットワークは、フレキシブル サーバーと同じ Azure リージョンに存在する必要があります。 仮想ネットワークの詳細については、Azure Virtual Network の概要に関するページを参照してください。

PostgreSQL フレキシブル サーバーで仮想ネットワークを使用する場合に理解しておくべきいくつかの概念を以下に示します。

  • 委任されたサブネット。 仮想ネットワークには、サブネット (サブネットワーク) が含まれます。 サブネットを使用すると、仮想ネットワークをより小さなアドレス空間に分割できます。 Azure リソースは、仮想ネットワーク内の特定のサブネットにデプロイされます。

    フレキシブル サーバーは、"委任された" サブネット内に存在する必要があります。 つまり、そのサブネットを使用できるのは Azure Database for PostgreSQL - フレキシブル サーバー インスタンスだけだということです。 委任されたサブネットに他の Azure リソースの種類を含めることはできません。 サブネットを委任するには、その委任プロパティを Microsoft.DBforPostgreSQL/flexibleServers として割り当てます。 サブネットに指定できる最小 CIDR 範囲は /28 で 14 個の IP アドレスが得られますが、ネットワークまたはサブネット内の最初と最後のアドレスは、個々のホストに割り当てることができません。 5 つの IP は、Azure ネットワークで内部的に利用するために予約されています。ホストに割り当てることのできない前述の 2 つの IP もそこに含まれます。 その結果、/28 の CIDR 範囲で使用可能な IP アドレスは 11 個残りますが、高可用性機能を備えた 1 つのフレキシブル サーバーでは 4 つのアドレスが使用されます。

    重要

    AzureFirewallSubnet、AzureFirewallManagementSubnet、AzureBastionSubnet、GatewaySubnet を含む名前は、Azure 内で予約されています。 これらのいずれも、サブネット名として使用しないでください。

  • ネットワーク セキュリティ グループ (NSG) 。 NSG のセキュリティ規則を使用して、仮想ネットワークのサブネットとネットワーク インターフェイスに出入りできるネットワーク トラフィックの種類をフィルター処理できます。 詳細については、NSG の概要に関するページを参照してください。

    アプリケーション セキュリティ グループ (ASG) を使用すると、フラットなネットワークで NSG を使用して、レイヤー 4 のセキュリティを簡単に制御できます。 以下を迅速に実行できます。

    • ASG に仮想マシンを参加させる、または ASG から仮想マシンを削除する。
    • これらの仮想マシンに対する規則を動的に適用または削除する。

    詳細については、ASG の概要に関するページを参照してください。

    現時点では、Azure Database for PostgreSQL - フレキシブル サーバーを含む規則の一部に ASG が含まれている NSG はサポートしていません。 現在、NSG では IP ベースのソースまたは宛先のフィルター処理を使用することをお勧めします。

    重要

    Azure Database for PostgreSQL - フレキシブル サーバーの高可用性およびその他の機能には、Azure Database for PostgreSQL - フレキシブル サーバーがデプロイされている Azure 仮想ネットワーク サブネット内の宛先ポート 5432、およびログ アーカイブ用の Azure Storage へのトラフィックの送信および受信機能が必要です。 Azure Database for PostgreSQL - フレキシブル サーバーがデプロイされているサブネット内での送受信のトラフィック フローを拒否するネットワーク セキュリティ グループ (NSG) を作成する場合は、サブネット内の宛先ポート 5432 へのトラフィックと、サービス タグ Azure Storage を宛先として使用して Azure Storage へのトラフィックを必ず許可してください。 また、Azure Active Directory 認証を使用してAzure Database for PostgreSQL - フレキシブル サーバーへのログインを認証する場合は、Azure AD サービス タグを使用して Azure AD への送信トラフィックを許可してください

  • プライベート DNS ゾーン統合。 Azure プライベート DNS ゾーン統合により、現在の仮想ネットワーク、またはリージョン内でピアリングされた仮想ネットワーク (プライベート DNS ゾーンがこれにリンクされている) 内でプライベート DNS を解決できます。

プライベート DNS ゾーンを使用する

Azure portal または Azure CLI を使用して仮想ネットワークでフレキシブル サーバーを作成する場合、サブスクリプション内のサーバーごとに新しいプライベート DNS ゾーンが、指定したサーバー名を使用して自動的にプロビジョニングされます。

Azure API、Azure Resource Manager テンプレート (ARM テンプレート)、または Terraform を使用する場合は、.postgres.database.azure.com で終わるプライベート DNS ゾーンを作成します。 これらのゾーンは、プライベート アクセスでフレキシブル サーバーを構成するときに使用します。 たとえば、[name1].[name2].postgres.database.azure.com または [name].postgres.database.azure.com の形式を使います。 [name].postgres.database.azure.com の形式を使うことを選んだ場合、その名前をフレキシブル サーバーのいずれかに使われている名前にすることはできません。そのようにすると、プロビジョニング時にエラー メッセージが表示されます。 詳細については、プライベート DNS ゾーンの概要に関するページを参照してください。

Azure 仮想ネットワークにプライベート ネットワーク アクセスを使用している場合は、API、ARM、Terraform などのさまざまなインターフェイスでプライベート DNS ゾーン情報の指定が必須です。 そのため、API、ARM、Terraform でプライベート ネットワーク アクセスを使用して Azure Database for PostgreSQL フレキシブル サーバーを新しく作成する場合は、プライベート DNS ゾーンを作成し、それを使用してプライベート アクセスでフレキシブル サーバーを構成します。 詳細については、Microsoft Azure の REST API 仕様に関するページを参照してください。 フレキシブル サーバーの作成に Azure portal または Azure CLI を使用する場合は、同じまたは異なるサブスクリプションで以前に作成したプライベート DNS ゾーン名を指定できます。そうしない場合は、サブスクリプションに既定のプライベート DNS ゾーンが自動的に作成されます。

Azure Database for PostgreSQL - フレキシブル サーバーの作成時に指定したプライベート DNS ゾーンは、Azure Portal、CLI、または ARM を使用して、同じまたは異なるサブスクリプションに存在する別のプライベート DNS ゾーンに変更することもできます。

重要

現在、Azure Database for PostgreSQL - フレキシブル サーバーの作成時に提供したプライベート DNS ゾーンを別のプライベート DNS ゾーンに変更する機能は、高可用性機能が有効なサーバーでは無効になっています。

カスタム DNS サーバーとの統合

カスタム DNS サーバーを使用する場合は、DNS フォワーダーを使用して Azure Database for PostgreSQL - フレキシブル サーバーの FQDN を解決する必要があります。 フォワーダーの IP アドレスは、168.63.129.16 である必要があります。

カスタム DNS サーバーは、仮想ネットワーク内にあるか、仮想ネットワークの DNS サーバー設定を使用して到達可能である必要があります。 詳細については、「独自の DNS サーバーを使用する名前解決」を参照してください。

プライベート DNS ゾーンと仮想ネットワーク ピアリング

プライベート DNS ゾーンの設定と、仮想ネットワーク ピアリングはそれぞれ独立しています。 同じリージョンまたは異なるリージョンの別の仮想ネットワークでプロビジョニングされたクライアントからフレキシブル サーバーに接続する必要がある場合は、プライベート DNS ゾーンをその仮想ネットワークにリンクさせる必要があります。 詳細については、「仮想ネットワークのリンク」を参照してください。

Note

リンクできるのは、名前が postgres.database.azure.com で終わるプライベート DNS ゾーンのみです。 DNS ゾーン名をフレキシブル サーバーと同じにすることはできません。同じ場合、名前解決に失敗します。

ハブ アンド スポーク プライベートネットワーク設計の使用

ハブ アンド スポークは、一般的な通信またはセキュリティ要件を効率的に管理するためのよく使われるネットワーク モデルです。

ハブは、外部接続を管理するための中心的な場所として機能する仮想ネットワークです。 また、複数のワークロードで使用されるサービスをホストします。 ハブでスポーク間のすべての通信が調整されます。 セキュリティのような IT のルールまたはプロセスによって、トラフィックを検査、ルーティング、集中管理できます。 スポークは、ワークロードをホストし、仮想ネットワーク ピアリングを介して中央のハブに接続する仮想ネットワークです。 共有サービスは、スポークと共有するための独自のサブネットでホストされます。 境界サブネットが次に、セキュリティ アプライアンスとして機能します。

スポークは、個々のワークロードを分離するために使用される Azure の仮想ネットワークでもあります。 オンプレミスの本社と Azure の間のトラフィック フローは、ハブ仮想ネットワークに接続されている ExpressRoute またはサイト間 VPN を介して接続されます。 スポークからハブへの仮想ネットワークがピアリングされ、オンプレミス リソースへの通信が可能になります。 ハブと各スポークは、別々のサブスクリプションまたはリソース グループに実装できます。

スポーク仮想ネットワークを相互に接続するには、主に次の 2 つのパターンがあります。

  • スポークが相互に直接接続される。 仮想ネットワーク ピアリングまたは VPN トンネルがスポーク仮想ネットワーク間に作成され、ハブ仮想ネットワークを通過することなく直接接続できます。
  • スポークはネットワーク アプライアンス経由で通信します。 各スポーク仮想ネットワークは、Virtual WAN またはハブ仮想ネットワークにピアリングされます。 アプライアンスは、スポークからスポークへのトラフィックをルーティングします。 アプライアンスは、 (Virtual WAN と同様に) Microsoft が管理するか、ユーザーが管理することができます。

Express Hub 経由のハイブリッド接続を使用した基本的なハブ アンド スポーク アーキテクチャを示す図。

Azure Virtual Network Manager (AVNM) を使用すると、接続とセキュリティ制御を一元管理するために、ハブ アンド スポーク仮想ネットワーク トポロジを新規に作成したり (既存のものをオンボードしたり) することができます。

プライベート ネットワークを使用した Azure リージョンと仮想ネットワーク間のレプリケーション

データベース レプリケーションは、中央またはプライマリ サーバーからレプリカと呼ばれる複数のサーバーにデータをコピーするプロセスです。 プライマリ サーバーは読み取りおよび書き込み操作を受け入れますが、レプリカは読み取り専用トランザクションを処理します。 プライマリ サーバーとレプリカを合わせてデータベース クラスターが形成されます。データベース レプリケーションの目的は、特にトラフィックの多いミッション クリティカルなアプリケーションにおいて、データの冗長性、一貫性、高可用性、アクセシビリティを確保することです。

Azure Database for PostgreSQL - フレキシブル サーバーには、組み込みの読み取りレプリカ機能と論理レプリケーションを使用した物理的な (つまりストリーミング) 2 つのレプリケーション方法が用意されています。 どちらも異なるユース ケースに最適であり、ユーザーは最終目標に応じてどちらか一方を選択できます。

各リージョンに個別の仮想ネットワーク (VNET) がある Azure リージョン間のレプリケーションでは、仮想ネットワーク ピアリングを介して、またはネットワーク アプライアンス経由のハブ アンド スポーク アーキテクチャにおいて提供可能なリージョンの仮想ネットワーク境界を越えた接続が必要です。

既定では、DNS 名前解決のスコープは仮想ネットワークです。 つまり、ある仮想ネットワーク (VNET1) 内のクライアントは、別の仮想ネットワーク (VNET2) 内のフレキシブル サーバー FQDN を解決できません。

この問題を解決するには、VNET1 のクライアントがフレキシブル サーバー プライベート DNS ゾーンにアクセスできることを確認する必要があります。 これを実現するには、フレキシブル サーバー インスタンスの プライベート DNS ゾーンに仮想ネットワーク リンクを追加します。

サポートされない仮想ネットワークのシナリオ

仮想ネットワークで作業する場合の制限事項を次に示します。

  • 仮想ネットワークにデプロイされたフレキシブル サーバーには、パブリック エンドポイント (またはパブリック IP あるいは DNS) を設定できません。
  • フレキシブル サーバーを仮想ネットワークおよびサブネットにデプロイした後、それを別の仮想ネットワークまたはサブネットに移動することはできません。 仮想ネットワークを別のリソース グループまたはサブスクリプションに移動することはできません。
  • サブネットにリソースを配置した後、そのサブネットのサイズ (アドレス空間) を増やすことはできません。
  • フレキシブル サーバーは、Azure Private Link をサポートしていません。 代わりに、仮想ネットワークの導入により、仮想ネットワーク内でフレキシブル サーバーを使用できるようにしています。

重要

Azure Resource Manager は、セキュリティ制御としてリソースをロックする機能をサポートしています。 リソース ロックはリソースに適用され、すべてのユーザーおよびロールが対象になります。 リソースのロックは 2 種類あります｡CanNotDelete と ReadOnly です。 これらは、プライベート DNS ゾーンまたは個別のレコード セットのいずれかに適用できます。 プライベート DNS ゾーンまたは個々のレコードセットにいずれかの種類のロックを適用すると、Azure Database for PostgreSQL の機能が妨げられる場合があります - フレキシブル サーバー サービスが DNS レコードし、プライマリからセカンダリへの高可用性フェールオーバーなど、DNS の重要な操作中に問題が発生する可能性があります。 以上の理由から、Azure Database for PostgreSQL - フレキシブル サーバーで高可用性機能を利用する場合は、DNS プライベートゾーンまたはレコードロックを使用しないようにしてください。

パブリック アクセス (許可された IP アドレス)

パブリック アクセス方法を選択すると、インターネット経由でパブリック エンドポイントを介してフレキシブル サーバーにアクセスできます。 パブリック エンドポイントは、パブリックに解決できる DNS アドレスです。 "許可された IP アドレス" という語句は、サーバーへのアクセス許可を付与することにした IP アドレスの範囲を意味します。 これらのアクセス許可は、ファイアウォール規則と呼ばれます。

次の機能が必要な場合は、このネットワーク オプションを選択します。

  • 仮想ネットワークをサポートしていない Azure リソースから接続する。
  • VPN または ExpressRoute によって接続されていない、Azure 外部のリソースから接続する。
  • フレキシブル サーバーが、インターネット経由でアクセスできるパブリック エンドポイントを持つようにする。

パブリック アクセスの方法には、次のような特性があります。

  • 許可した IP アドレスにのみ、PostgreSQL フレキシブル サーバーにアクセスするためのアクセス許可が付与されます。 既定では、許可されている IP アドレスはありません。 IP アドレスの追加は、サーバーの作成時または後で行えます。
  • PostgreSQL サーバーには、パブリックに解決できる DNS 名があります。
  • フレキシブル サーバーは、Azure 仮想ネットワークのいずれにも存在しません。
  • サーバーとの間のネットワーク トラフィックは、プライベート ネットワークを経由しません。 このトラフィックでは、一般的なインターネット経路が使用されます。

ファイアウォール規則

ファイアウォール規則で許可していない IP アドレスから接続が試みられた場合、送信元のクライアントにエラーが返されます。

すべての Azure IP アドレスを許可する

ご使用の Azure サービスに対して固定の発信 IP アドレスが使用できない場合は、Azure データセンターのすべての IP アドレスからの接続を有効にすることを検討できます。

重要

[Azure サービスおよび Azure 内のリソースからのパブリック アクセスを許可する] オプションを選択すると、他の顧客のサブスクリプションからの接続を含め、Azure サービスからのすべての接続を許可するようにファイアウォールが構成されます。 このオプションを選択する場合は、許可されているユーザーのみがアクセスできるように、サインインおよびユーザーのアクセス許可が制限されていることを確認してください。

パブリック アクセスに関する問題のトラブルシューティング

Azure Database for PostgreSQL サービスに期待どおりにアクセスできない場合は、次の点を検討してください。

  • 許可リストに対する変更がまだ有効になっていない。 Azure Database for PostgreSQL サーバーのファイアウォール構成に対する変更が有効になるまで 5 分程度の遅延が発生する場合があります。

  • 認証に失敗した。 ユーザーが Azure Database for PostgreSQL サーバーに対するアクセス許可を持っていないか、パスワードが正しくない場合、Azure Database for PostgreSQL サーバーへの接続は拒否されます。 ファイアウォール設定を作成しても、クライアントはサーバーへの接続を試行できるようになるだけです。 各クライアントは、必要なセキュリティ資格情報を提供する必要があることに変わりはありません。

  • 動的なクライアント IP アドレスによりアクセスが妨げられている。 動的 IP アドレス指定によるインターネット接続を使用しており、ファイアウォールの通過に問題が発生している場合は、次の解決策のいずれかをお試しください。

    • Azure Database for PostgreSQL サーバーにアクセスするクライアント コンピューターに割り当てられている IP アドレス範囲について、インターネット サービス プロバイダー (ISP) に問い合わせます。 その後、ファイアウォール規則としてその IP アドレス範囲を追加します。
    • 代わりに、クライアント コンピューター用に静的 IP アドレスを取得し、ファイアウォール規則としてその静的 IP アドレス範囲を追加してください。

  • ファイアウォール規則が IPv6 形式で使用できない。 ファイアウォール規則は IPv4 形式である必要があります。 IPv6 形式でファイアウォール規則を指定すると、検証エラーが返されます。

ホスト名

選択するネットワーク オプションに関係なく、フレキシブル サーバーに接続する場合は常に、ホスト名として FQDN を使用することをお勧めします。 サーバーの IP アドレスが静的のままであることは保証されていません。 FQDN を使用すると、接続文字列を変更せずに済みます。

ホスト名として FQDN を使用する例は、hostname = servername.postgres.database.azure.com です。 可能であれば、hostname = 10.0.0.4 (プライベート アドレス) または hostname = 40.2.45.67 (パブリック アドレス) の使用は避けてください。

TLS と SSL

Azure Database for PostgreSQL - フレキシブル サーバーでは、トランスポート層セキュリティ (TLS) を使用して、PostgreSQL サービスへのクライアント アプリケーションの接続を強制します。 TLS は、データベース サーバーとクライアント アプリケーションの間で、暗号化されたネットワーク接続を保証する業界標準のプロトコルです。 TLS は、Secure Sockets Layer (SSL) が更新されたプロトコルです。

世界には、ネットワーク セキュリティに関する TLS のガイドラインを維持する政府機関がいくつか存在し、米国の保健福祉省 (HHS) や国立標準技術研究所 (NIST) などがあります。 TLS が提供するセキュリティのレベルは、TLS プロトコルのバージョンとサポートされている暗号スイートによって最も大きな影響を受けます。 暗号スイートは、暗号、キー交換アルゴリズム、ハッシュ アルゴリズムなどの一連のアルゴリズムであり、これらをまとめて使用することで、セキュリティで保護された TLS 接続を確立します。 ほとんどの TLS クライアントとサーバーはそれらの代わりとなるものを複数サポートしています。そのため、これらは、セキュリティで保護された接続を確立するときにネゴシエートして、一般的な TLS バージョンと暗号スイートを選択する必要があります。

Azure Database for PostgreSQL では TLS バージョン 1.2 以降をサポートしています。 インターネット技術標準化委員会 (IETF) は RFC 8996 で、TLS 1.0 と TLS 1.1 を使用してはならないことを明記しています。 どちらのプロトコルも、2019 年末までに非推奨となりました。

TLS 1.0 や TLS 1.1 など、以前のバージョンの TLS プロトコルを使用する受信接続は既定ですべて拒否されます。

Note

SSL と TLS の証明書により、接続が最先端の暗号化プロトコルで保護されていることが証明されます。 通信中の接続を暗号化することで、転送中のデータへの不正アクセスを防ぐことができます。 このため、最新バージョンの TLS を使用して、Azure Database for PostgreSQL - フレキシブル サーバーへの接続を暗号化することを強くお勧めします。 推奨はされませんが、必要であれば、require_secure_transport サーバー パラメーターをオフに更新することで、Azure Database for PostgreSQL - フレキシブル サーバーへの接続で TLS\SSL を無効にできます。 また、ssl_min_protocol_version と ssl_max_protocol_version のサーバー パラメーターを設定することで、TLS バージョンを設定することもできます。

証明書認証は、認証用の SSL クライアント証明書を使用して実行されます。 このシナリオでは、PostgreSQL サーバーは、提示されたクライアント証明書の CN (共通名) 属性を、要求されたデータベース ユーザーと比較します。 Azure Database for PostgreSQL - フレキシブル サーバーでは、現時点で SSL 証明書ベースの認証をサポートしていません。

現在の SSL 接続の状態を確認するには、sslinfo 拡張機能を読み込み、ssl_is_used() 関数を呼び出して SSL が使用されているかどうかを確認します。 この関数は、接続で SSL を使用している場合は t を返し、それ以外の場合は f を返します。 また、次のクエリを使用して、Azure Database for PostgreSQL - フレキシブル サーバー インスタンスの SSL 使用状況に関するすべての情報をプロセス、クライアント、アプリケーション別に収集することもできます。

SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
   FROM pg_stat_ssl
   JOIN pg_stat_activity
   ON pg_stat_ssl.pid = pg_stat_activity.pid
   ORDER BY ssl;

次のステップ

  • Azure portal または Azure CLI でプライベート アクセス (VNet 統合) オプションを使用してフレキシブル サーバーを作成する方法を説明します。
  • Azure portal または Azure CLI でパブリック アクセス (許可された IP アドレス) を使用してフレキシブル サーバーを作成する方法を説明します。