外部IPアドレスを持たないCloud SQL環境を構築する
外部IPアドレスを持たないCloud SQLを構築し、メンテナンスのための踏み台サーバーを用意する
Table of contents
author: kwgc-t
はじめに
データベースのセキュリティ強化は、現代のITインフラにおいて不可欠な要素です。
本記事では、Google CloudのCloud SQLにおいて、外部からの直接アクセスを遮断し、セキュリティを向上させるための「外部IPアドレスを持たない環境」の構築方法を解説します。
具体的な手順に加え、関連するネットワーク設定やセキュリティ上の考慮点なども掘り下げ、読者が安全かつ堅牢なデータベース環境を構築できるよう支援します。
前提
本記事はGoogle Cloudのサービスやインフラに関する知識が一定程度あることを前提とします。
データ保護の重要性
データについて
現代社会において、データは企業の生命線とも言えるほど重要な資産です。
顧客情報、内部データ（財務データ、人事データなど）、知的財産など、あらゆる情報がデジタル化され、データベースに保存されています。
個人情報などセンシティブデータの流出は企業の信用を失墜させますし、コアコンピタンスに関わるデータの流出は競合他社にその情報を利用され、ビジネスの機会を失うことにもなります。
クラウド上のデータベースの特性
クラウド上でクラウドベンダーが提供するデータベースサービス（Google CloudであればCloud SQL、AWSであればRDS等）はインターネットを介してのアクセスが可能であり、第三者による不正なアクセスの危険に晒される可能性があります。
適切なアクセス制御やアクセス制限、認証を設けていないとデータの流出につながります。
それらを踏まえて、以降でCloud SQLを構築する上で取れる対策の1つである外部IPアドレスを持たないCloud SQLおよびそのメンテナンス方法をご紹介いたします。
アーキテクチャ
全体アーキテクチャ
まず、おおまかな全体アーキテクチャが以下です。
図1.
アクセスのフロー
ユーザーはまず、Compute Engineにログインし、そこからCloud SQLに接続します。
Cloud SQLは内部IPアドレスのみ持つように作成し、インターネットから直接アクセスできないようにします。
以下、代表的な個別のサービスの説明をいたいします。
Compute Engine
利用目的
いわゆる踏み台サーバーとして利用します。
外部IPアドレスを持たないCloud SQLインスタンスは、インターネットからの直接アクセスを遮断することでセキュリティを向上させています。しかし、管理やメンテナンスのためにデータベースにアクセスする必要がある場合、安全な接続手段を確保しなければなりません。
ここで登場するのが「踏み台サーバー」です。踏み台サーバーは、隔離されたネットワークに配備され、外部からのアクセスを許可された唯一のサーバーとなります。ユーザーはまずこの踏み台サーバーに接続し、そこから内部のCloud SQLインスタンスにアクセスします。これにより、データベースへのアクセス経路を限定し、セキュリティリスクを低減できます。
Compute Engineのセキュリティ対策
Cloud SQLと同様、Compute Engineにも外部IPアドレスを付与しません。そのため、通常通りのインターネット経由のアクセスは不可能になります。
Compute EngineにアクセスするためにはIAP(Identity Aware Proxy)を利用します。IAPを利用することでVPNのようにネットワークレベルの制御ではなく、ユーザーやグループ単位でアクセス制御を柔軟に行えるようになります。アクセス可能なユーザー、グループはIAMを利用して管理します。
Cloud NAT
利用目的
Compute Engineがインターネットにアクセスするために設置します。
Compute Engineの章での通り、外部IPアドレスを持っていないためそのままではインターネットに接続できません。
Cloud SQL
利用目的
今回の保護する対象です。データを格納するデータベースとして利用します。
Cloud SQLのセキュリティ対策
Cloud SQLに外部IPアドレスを付与するとインターネット経由で誰でもアクセス可能な状態に晒されます。これを防止するためにCloud SQLには内部IPアドレスのみ付与します。
構築手順
ここまで代表的なサービスの利用目的とセキュリティ対策を説明いたしました。
ここからは構築について説明いたします。
構築
terraformスクリプトをご用意しました。こちらを使って構築します。
Cloud SQLの構築に数分かかります。
variables.tfの以下変数を設定してください。
project_id- terraformを適用したいプロジェクトのプロジェクトIDを設定してください。
your_account- 作業者のGoogleアカウントを設定してください。
設定後、以下コマンドを実行します。
terraform apply
~~~中略~~~
# yesの入力を求められるため、yesを入力します。
Enter a values: yes
接続手順
構築した環境への接続をします。前の記載の通り、作業者はまずCompute Engineにログインし、そこからCloud SQLへログインします。
まずは以下コマンドを実行します。
# PROJECT_IDの設定。
$ PROJECT_ID=variable.tfのproject_idに設定した値
# Compute EngineへSSH接続。IAP経由での接続を行う。
$ gcloud compute ssh --project=${PROJECT_ID} private-access-db-bastion
# 接続に成功すると以下メッセージが表示される
No zone specified. Using zone [asia-northeast1-a] for instance: [private-access-db-bastion].
External IP address was not found; defaulting to using IAP tunneling.
# Compute Engineへ接続後、Cloud SQL Proxyを立ち上げ。
$ cloud-sql-proxy sandbox-kawaguchi-t:asia-northeast1:private-access-db --private-ip
別のターミナルを立ち上げ、以下コマンドを実行します。
# PROJECT_IDの設定。
$ PROJECT_ID=variable.tfのproject_idに設定した値
# Compute EngineへSSH接続。IAP経由での接続を行う。
$ gcloud compute ssh --project=${PROJECT_ID} private-access-db-bastion
# PostgresSQLへ接続
psql "host=127.0.0.1 port=5432 sslmode=disable user=postgres"
# パスワード入力を求められるため、"abcABC123!"を入力する。
上記手順でPostgreSQLへ接続ができます。
リソースの削除
terraformで構築したのでterraformで削除します。
ただし、今回の構築でterraformで管理されていないリソース（Google Cloudが自動作成するリソース）があるため、一度に全ては削除できません。1度目は必ずエラーが発生します。
terraform destroy
~~~中略~~~
# yesの入力を求められるため、yesを入力します。
Enter a values: yes
# エラーが発生する
│ Error: Unable to remove Service Networking Connection, err: Error waiting for Delete Service Networking Connection: Error code 9, message: Failed to delete connection; Producer services (e.g. Cloud SQL, Cloud Memstore, etc.) are still using this connection.
エラーが発生したのちにGoogle Cloudのコンソールから対象リソースの削除をします。
VPCネットワーク > VPCネットワークピアリングから対象のリソースを削除します。
図2.
コンソールから削除後、再度terraformで削除をします。
terraform destroy
~~~中略~~~
# yesの入力を求められるため、yesを入力します。
Enter a values: yes
まとめ
環境の構築のポイント
今回の事例のCloud SQLへのアクセス制御にかかわらず重要なポイントがいくつかあります。
- 必要な通信のみを許可すること
- 必要なユーザーのみにIAMロールを割り当てること
- 必要最低限のIAMロールを割り当てること
Google Cloudのベストプラクティスとして提示されている最小権限の原則を遵守することです。
おわりに
本記事では、Cloud SQLのセキュリティ対策の一例を挙げました。ただし、本記事の対策は完璧ではなく、シチュエーションに応じて様々な対策が必要になってきます。データベースのセキュリティ対策は、絶え間ないアップデートと改善が必要です。本記事がその一助となれば幸いです。
参考
※本記事は、ジーアイクラウド株式会社の見解を述べたものであり、必要な調査・検討は行っているものの必ずしもその正確性や真実性を保証するものではありません。
※リンクを利用する際には、必ず出典がGIC dryaki-blogであることを明記してください。
リンクの利用によりトラブルが発生した場合、リンクを設置した方ご自身の責任で対応してください。
ジーアイクラウド株式会社はユーザーによるリンクの利用につき、如何なる責任を負うものではありません。