Cloud SQL の承認済みネットワーク検証
コネクタ接続にIP登録は必要なのか
- 1. はじめに
- 2. 承認済みネットワークとは何か
- 3. なぜ判断がつかなかったのか
- 4. 検証：ファイアウォールが効いている状態で繋ぐ
- 5. 結論：登録は不要。公式はコネクタ接続を推奨していた
- 6. さいごに
1. はじめに
Cloud SQL でパブリックIPを有効にすると、「承認済みネットワーク」という設定項目が現れます。ここに接続元のIPアドレスを登録して、外部からの接続を許可する仕組みです。
先日、Cloud SQL とデータポータル（旧称：Looker Studio）を繋ぐ記事を書きました。
【関連記事】Cloud SQL とデータポータルを繋いでみた ～マネージドDBの作成から、ダッシュボード完成まで～
そのときに迷ったのが、この「承認済みネットワーク」にデータポータルのIPアドレスを登録する必要があるのかどうかです。公式ドキュメントを読むと、必要とも不要とも取れました。そこで、実際に検証して確かめてみました。
結論から書くと、Cloud SQL for MySQL コネクタで繋ぐなら、承認済みネットワークへの登録は不要でした。そしてむしろ公式は、パブリックIP接続ではコネクタを使うことを推奨しています。
以下、なぜ判断がつかなかったのか、どう検証したのかを書いていきます。
なお、本記事の内容は2026年9月時点のものです。
2. 承認済みネットワークとは何か
公式ドキュメントには、こう書かれています。
承認済みネットワークのリストは、ローカル ファイアウォールによって Cloud SQL インスタンス VM に実装されています。
出典：Cloud SQL「承認済みネットワークを使用して承認する」
https://docs.cloud.google.com/sql/docs/mysql/authorize-networks?hl=ja
インスタンスのVM上で動くファイアウォールそのものです。ファイアウォールなので、登録した範囲がそのままデータベースのポートに到達できる範囲になります。リストが空であれば、パブリックIPに宛ててデータベースのポート（MySQLなら3306）へ送られた通信はすべて落とされます。この点は4章で実際に確認します。
【注意】手間を省くために広いレンジを登録しない
「面倒だから全部許可しておく」という設定を見かけますが、広げた分だけそのままポートが到達可能になります。そこを通過されると、あとは MySQL の認証だけが残ります。
3. なぜ判断がつかなかったのか
登録が必要に見える理由
データポータルの Cloud SQL for MySQL コネクタの公式ドキュメントには、「ファイアウォールとデータベースへのアクセス」という項目があり、こう書かれています。
データポータルがファイアウォールの内側にあるデータベースに接続してクエリを実行できるようにするには、次のいずれかの IP アドレスへのアクセスを可能にする必要があります。また、これらのアドレスからのトラフィックを受け入れるようにデータベースを設定する必要があります。詳しい手順については、該当するデータベースの各ドキュメントをご覧ください。
出典：データポータル ヘルプ「Google Cloud SQL for MySQL に接続する」
https://docs.cloud.google.com/data-studio/connect-to-google-cloud-sql-for-mysql?hl=ja
ドキュメントには具体的なアドレスが列挙されていて、その中に 142.251.74.0/23 が含まれています。
2章に記載したとおり、承認済みネットワークはインスタンスVM上のローカルファイアウォールです。Cloud SQL のパブリックIPで特定の送信元アドレスからの通信を受け入れる設定は、承認済みネットワークしか用意されていません。「承認済みネットワークに登録してください」と直接書かれてはいないものの、ここに登録する必要があるように見えます。
登録が不要に見える理由
Cloud Shell でインスタンスの設定を出力してみます。
gcloud sql instances describe demo-sales-db --format="value(settings.ipConfiguration)"
出力の中に、Google Cloud 公式によるこんな説明が含まれています。
message: Configuring authorized network or using CloudSQL auth proxy or language
connectors is a prerequisite for connecting to Public IP.パブリックIPに接続するための前提条件として、次のいずれか1つが挙げられています。
| 経路 | 概要 |
|---|---|
| 承認済みネットワークの設定 | 接続元IPを登録して、ファイアウォールを通す |
| Cloud SQL Auth Proxy | 専用のプロキシを経由して接続する |
| 言語コネクタ | 各言語向けのライブラリがインスタンス接続名を解決して接続する |
つまり、承認済みネットワークは3本ある道のうちの1本にすぎません。データポータルからは Cloud SQL for MySQL コネクタで繋ぐので、接続経路の1本を満たしています。だとすれば、承認済みネットワークへの登録は不要のはずです。
そして、承認済みネットワークが必要になる条件そのものにも限定が付いていました。2章で引用したドキュメントには、登録が必要になる場合としてこう書かれています。
クライアント アプリケーションが、パブリック IP アドレスで Cloud SQL インスタンスに直接接続している。
出典：Cloud SQL「承認済みネットワークを使用して承認する」
https://docs.cloud.google.com/sql/docs/mysql/authorize-networks?hl=ja
「パブリックIPを使うなら必要」ではなく、「パブリックIPに直接接続するなら必要」と書かれているのです。
どちらとも取れる
| 読み取れること | |
|---|---|
| データポータル側 | ファイアウォールの内側にあるDBなら、IPレンジへのアクセスを許可する必要がある（「直接」に当たる限定はない） |
| Cloud SQL 側 | 必要なのは直接接続する場合。コネクタなら3本のうち別の1本を通る |
以上のことから、承認済みネットワークへの登録は不要なのか必要なのか、公式ドキュメントを読んだだけでは判断がつきませんでした。
4. 検証：ファイアウォールが効いている状態で繋ぐ
関連記事で作成した最小構成のインスタンスをそのまま使いました。
| 項目 | 値 |
|---|---|
| インスタンス | Cloud SQL for MySQL（Enterprise / サンドボックス） |
| バージョン | MySQL 8.0 |
| 接続方式 | パブリックIP 有効 |
| 承認済みネットワーク | 空 |
| データベース | sales（売上データ900件） |
| 接続ユーザー | looker_ro（sales に対する SELECT のみ） |
図1 承認済みネットワークが空の状態のコンソール画面
検証として、3通りの接続を試しました。
ただ「承認済みネットワークが空のままコネクタで繋がった」という結果だけでは、なぜ繋がるのかを1つに絞れません。3章で見たように、「コネクタが3本ある道のうち別の1本を通っているから」かもしれませんが、そもそも承認済みネットワークが何も遮断していないかもしれません。後者であれば、単にどこからでも入れる状態だったことになります。
そこで、失敗するはずの接続を混ぜて検証しました。承認済みネットワークが空であることが実際に通信を遮断している証拠を取るためです。
なお、データポータルには MySQL に繋ぐコネクタが2種類あります。Cloud SQL 専用の「Cloud SQL for MySQL」と、汎用の「MySQL」です。前者は接続先にインスタンス接続名を指定し、後者はホスト名かIPアドレスを指定します。3章で挙げたIPレンジの記述がどちらの経路に向けたものなのかも確かめたいので、両方を試しました。
| 接続方法 | 接続先の指定 | 期待 |
|---|---|---|
| Cloud Shell の mysql コマンド（対照） | パブリックIP | 失敗するはず |
| MySQL（汎用）コネクタ | パブリックIP | 失敗するはず |
| Cloud SQL for MySQL コネクタ | インスタンス接続名 | 成功するはず |
対照に使ったのは、パブリックIPを直接指定した接続です。
mysql -h <インスタンスのパブリックIP> -u looker_ro -p
ここで gcloud sql connect を使ってしまうと対照になりません。承認済みネットワークが空のままでも成功してしまうためです。また、データポータル側は2つのコネクタでそれぞれ新規にデータソースを作成しました。既存のデータソースを更新するだけでは接続情報がキャッシュされていて、確かめたいことが確かめられません。
結果は次のとおりです。
| 接続方法 | 接続先の指定 | 結果 |
|---|---|---|
| Cloud Shell の mysql コマンド（対照） | パブリックIP | ❌ ERROR 2003 (HY000) ... (110) |
| MySQL（汎用）コネクタ | パブリックIP | ❌ 読み込み中のまま応答なし |
| Cloud SQL for MySQL コネクタ | インスタンス接続名 | ⭕️ 接続成功 |
1つ目の Cloud Shell の mysql コマンドで、ファイアウォールが効いていることが確認できました。ERROR 2003 の末尾の 110 は Linux の ETIMEDOUT（接続タイムアウト）です。もし接続を拒否されていれば 111（ECONNREFUSED）が返るはずで、そうならないのはパケットが応答を返さずに破棄されているからです。タイムアウトそのものは経路上のどこで捨てられたかまでは示しませんが、承認済みネットワークがインスタンスVM上のファイアウォールだという2章の説明と一致する結果です。
図2 Cloud Shell から接続を試みて失敗した画面
2つ目の MySQL（汎用）コネクタは、読み込み中の表示が回り続けるだけで明確なエラーが返ってきません。接続先にパブリックIPを指定する方式なので、mysql コマンドと同じところで止まっていると考えられます。承認済みネットワークに登録していないアドレスからの接続は、コネクタの形をしていても通らないということです。
【Tips】すぐにエラーが返らないことが、ネットワークで止まっているサインです
接続できないときの切り分けは、この違いを見ると早くなります。すぐに Access denied が返るなら、パケットは届いているので原因は認証情報です。逆に、何の反応もないなら、パケットが途中で捨てられています。ネットワーク周りを確認するべき状況です。
そして3つ目の Cloud SQL for MySQL コネクタです。同じデータポータルからの接続で、承認済みネットワークも同じく空。その中でこれだけが接続に成功しました。
図3 Cloud SQL for MySQL コネクタで接続に成功した画面
5. 結論：登録は不要。公式はコネクタ接続を推奨していた
Cloud SQL for MySQL コネクタを使う場合、承認済みネットワークへのIP登録は必要ありません。3章で見た3本の道のうち、「言語コネクタ」の道を通っていると考えられます。
裏付けとして、データポータルの Cloud SQL for MySQL コネクタは、接続方式として JDBC URL も選べるのですが、その形式が公式ドキュメントに載っています。
jdbc:google:mysql://INSTANCE_CONNECTION_NAME/DATABASE
出典：データポータル ヘルプ「Google Cloud SQL for MySQL に接続する」
https://docs.cloud.google.com/data-studio/connect-to-google-cloud-sql-for-mysql?hl=ja
jdbc:mysql: ではなく jdbc:google:mysql: です。これは Cloud SQL Java コネクタ（言語コネクタ）のスキームで、IPアドレスではなくインスタンス接続名を解決して接続する仕組みです。
公式ドキュメントでは専用コネクタの内部実装そのものを明記していないので、URLの形式からの推定ですが、承認済みネットワークとは別の道を通っていることが、URLの形から読み取れます。
そして、3本の道は横並びではありませんでした。「一般的な推奨事項」という見出しの下に、こう書かれています。
パブリック IP アドレスを使用してインスタンスに接続する場合は、Cloud SQL コネクタ（Cloud SQL Auth Proxy または Cloud SQL 言語コネクタのいずれか）を使用します。
出典：Cloud SQL「Cloud SQL への接続方法を選択する」
https://docs.cloud.google.com/sql/docs/mysql/connect-overview?hl=ja
公式は、パブリックIP接続ではコネクタを推奨しています。承認済みネットワークについては、公式ドキュメントの同じページに「パブリック IP アドレスを使用してインスタンスに直接接続する場合は、承認済みネットワークを構成する必要があります」と、必要になる条件として説明されているだけです。
さらに同じページに、コネクタが役立つ場面として次の項目が挙げられています。
- [承認済みネットワーク]を構成せずにパブリック IP アドレスを使用して Cloud SQL インスタンスに接続する場合。
「承認済みネットワークを構成せずにパブリックIPで接続する」ことが、コネクタの用途としてそのまま挙げられています。つまり、承認済みネットワークを空のままコネクタで繋ぐという構成は公式が案内している形そのものでした。「登録しないほうが推奨に沿っている」が今回の結論です。
コネクタは何を根拠に通しているのか
コネクタは、チェックを飛ばしているのではなく、チェックする対象を入れ替えています。コネクタの1つである Cloud SQL Auth Proxy の説明には、こう書かれています。
Cloud SQL Auth Proxy は、承認済みネットワークや SSL の構成を必要とせず、安全にインスタンスにアクセスできる Cloud SQL コネクタです。
Cloud SQL Auth Proxy は、TLS 1.3 を使用してデータベースとの間で送受信されるトラフィックを自動的に暗号化します。
Cloud SQL Auth Proxy では、IAM 権限を使用して、Cloud SQL インスタンスに接続できるユーザーと対象を制御します。
出典：Cloud SQL「Cloud SQL Auth Proxy について」
https://docs.cloud.google.com/sql/docs/mysql/sql-proxy?hl=ja
利用には cloudsql.instances.connect 権限を含むロールが必要です。通信先も通常の MySQL とは異なり、「ポート 3307 にのみ Cloud SQL インスタンスへの送信（または外向き）接続が作成されます」と書かれています。
つまり、「IPで判断するのをやめて、IAMで判断させている」ということです。そもそもIPアドレスは変わりうるもので、共有レンジであれば自社専用でもありません。判断材料としてはIAMのほうが確実です。
4章で試した2つのコネクタの違いを整理すると、こうなります。
| Cloud SQL for MySQL | MySQL（汎用） | |
|---|---|---|
| 接続先の指定 | インスタンス接続名 | ホスト名またはIPアドレス |
| 通る道 | 言語コネクタ（JDBC URLの形式からの推定） | 承認済みネットワーク |
| 通す根拠 | 誰であるか（IAMの権限と資格情報） | どこから来たか（送信元IP） |
| 通信の暗号化 | 自動でTLS。証明書の管理も不要 | SSLの構成を自分で行う必要がある |
| 必要なIAM権限 | Cloud SQL クライアント（roles/cloudsql.client）以上 | 不要 |
| 承認済みネットワーク | 登録不要 | 142.251.74.0/23 の登録が必要 |
| 公式ドキュメントの扱い | パブリックIPでは推奨 | 権限が取れない場合の代替 |
4章で汎用コネクタが繋がらなかったのは、142.251.74.0/23 を登録していなかったからです。パブリックIP宛の接続という点は対照に使った mysql コマンドと同じで、こちらは読み込み中のまま応答がありませんでした。今回の検証結果からすると、3章で見たあのIPレンジの記述は、汎用コネクタの経路に向けた情報だったということになります。汎用コネクタはオンプレミスのサーバーや他社クラウドの MySQL も含めて繋ぐためのものなので、相手が Google Cloud のサービスだとは限りません。IPアドレスを指定して直接繋ぐしかなく、だからファイアウォールを開ける必要があります。記述が間違っていたわけではなく、こちらの経路の話だったのです。
実際に登録してみた
では、汎用コネクタの場合、142.251.74.0/23 を承認済みネットワークに登録すれば繋がるのでしょうか。実際に登録して試してみたところ、登録しただけでは接続できませんでした。原因はインスタンスのSSL設定でした。
図4 sslMode が ENCRYPTED_ONLY になっているインスタンスの設定
gcloud sql instances describe demo-sales-db --format="yaml(settings.ipConfiguration)"
requireSsl: false
sslMode: ENCRYPTED_ONLYrequireSsl: false だけを見ると「SSLは不要」と読めますが、実際に効いているのは sslMode のほうです。ENCRYPTED_ONLY は「暗号化された接続のみ許可する」という設定で、今回はコンソールから既定のまま作成してこの値になっていました（既定値は変わることがあるので、実際の値は describe で確認してください）。そのため、汎用コネクタで繋ぐなら、コネクタ側でSSLを有効にして証明書を設定する必要があります。
今回は検証のため、暗号化されていない接続も許可する設定に一時的に変更したところ、汎用コネクタでの接続が成功しました。それまで汎用コネクタを止めていたのが承認済みネットワークだったことも、ここで裏付けられました。
なお、暗号化の設定変更は切り分けのための一時的な操作であるため、検証後は sslMode を ENCRYPTED_ONLY に戻しています。
【Tips】requireSsl ではなく sslMode を見る
requireSsl はレガシーなフィールドで、true にすると暗号化に加えて有効なクライアント証明書まで要求します。暗号化そのものを制御しているのは sslMode で、公式も現在は sslMode を使うことを推奨しています。両方が設定されている場合は sslMode が優先されます。
出典：Cloud SQL「SSL / TLS 証明書を構成する」
https://docs.cloud.google.com/sql/docs/mysql/configure-ssl-instance?hl=ja
出典：Cloud SQL Admin API「REST Resource: instances」
https://docs.cloud.google.com/sql/docs/mysql/admin-api/rest/v1/instances?hl=ja
つまり汎用コネクタを選ぶと、承認済みネットワークへの登録とSSLの構成という2つの作業が増えます。専用コネクタではどちらも必要ありませんでした。
そして、登録によって変わったのはこの点です。
- データベースのポートが 142.251.74.0/23 に対して開く
- この /23 は512個のアドレスを含む。データポータルの共通インフラであるため、自社専用のレンジではない
- このレンジの中から接続してくる相手に対しては、DBのユーザー名とパスワードが境界になる
誤解のないように補足すると、これは「誰でもデータベースに入れるようになる」という話ではありません。接続するにはこのレンジの中から通信できることが前提で、そのうえでインスタンスのIPアドレスと認証情報を知っている必要があります。ただ、承認済みネットワークという1枚目の壁が、この範囲に対しては無くなります。
登録しても、専用コネクタの経路が閉じるわけではありません。IAMで判断する入口はそのまま残り、IPで判断する入口が1つ増えます。専用コネクタを使い続けている限り動作は何も変わらないので、ポートが開いたままになっていても気づく機会がありません。
なお、BIツールに渡すユーザーを root ではなく SELECT だけの専用ユーザーにしておくと、こうした場面でも影響が読み取りに限定されます。これは登録の有無にかかわらず有効な備えです。
なお、確認が終わったあとは登録を削除して、承認済みネットワークは空の状態に戻しています。
ただし、専用コネクタを選べない場合がある
ここまでの結論は「データポータルの Cloud SQL for MySQL コネクタを使えばIP登録は不要」でした。ただし、それを選べない場合があります。公式ドキュメントには、こう書かれています。
接続を作成するには、Cloud SQL for MySQL プロジェクトにおいて cloudsql.client 以上の権限が必要です。この権限がない（または取得できない）場合は、代わりに MySQL コネクタを使用してください。
出典：データポータル ヘルプ「Google Cloud SQL for MySQL に接続する」
https://docs.cloud.google.com/data-studio/connect-to-google-cloud-sql-for-mysql?hl=ja
公式が、汎用コネクタを「権限が取れないときの代替手段」として案内しています。
企業環境で起きやすいのは、データポータルにログインしているアカウントと、Google Cloud プロジェクトのアカウントが別ドメインというケースです。データポータル側のアカウントをプロジェクトのIAMに追加できれば cloudsql.client を付与できますが、それが組織ポリシーで止められることがあります。
【注意】組織ポリシーでIAMへの追加が拒否されることがある
「ドメインで制限された共有」（iam.allowedPolicyMemberDomains）が有効だと、他ドメインのアカウントはIAMに追加できません。
この場合にまず検討したいのは、プロジェクトと同じドメインのアカウントでデータソースを作ることです。cloudsql.client を持つアカウントで作成してレポートを共有すれば、専用コネクタのまま進められます。
それも用意できない場合は汎用コネクタしか残らず、データポータルの送信元レンジ（今回は 142.251.74.0/23）の登録が避けられません。構成によって対象のレンジが変わることがあるので、登録前に公式ドキュメントで最新の値を確認してください。
つまり、roles/cloudsql.client を付与できるかどうかが、データベースのポートを外部に開くかどうかの分かれ目になります。
6. さいごに
「承認済みネットワークにデータポータルのIPアドレスを登録する必要があるのか」という疑問から検証を始めて、次のことが分かりました。
- 承認済みネットワークは、インスタンスVM上のローカルファイアウォール。空ならパブリックIP宛のデータベースポートは全遮断
- 登録が必要なのは、パブリックIPに直接接続する場合
- Cloud SQL for MySQL コネクタは別の道（JDBC URLの形式からすると言語コネクタ）を通るので、承認済みネットワークの登録は不要。公式もコネクタ接続を推奨している
- roles/cloudsql.client を付与できない場合は汎用コネクタが選択肢になり、そのときは承認済みネットワークへの登録とSSLの構成が必要になる
データポータルの公式ドキュメントにあったIPレンジへのアクセスを許可する必要があるという記述は、汎用コネクタ経由の接続については完全に正しい内容でした。検証の結果、自分が通ろうとしている経路の話ではなかったということです。
公式ドキュメントを読んで判断がつかないと感じたときは、その記述が自分の状況を指しているのかどうかを確かめる必要があることを、今回改めて実感しました。
本記事が、皆さんの構成検討の参考になれば嬉しいです。Google Cloud の導入や活用でお困りのことがあれば、お気軽にお問い合わせください。