Strategic Products Engineering Unit(SPEU)チーム所属で名刺メーカーのインフラを担当している川村です。
営業DXサービス「Sansan」では、既存の社内インフラサービスを活用して名刺作成業務を効率化する名刺メーカーという機能があります。
sansan-meishi-maker.com
自己紹介はここまでとし、今回の本題に入ります。
Google Cloudを利用する上で使うことが多いCloudSQLですが、開発者が自端末から接続するためにパブリックIPを使うケースは一般的だと思います。
認証機能によって誰でもアクセスできるわけではないとはいえ、パブリックIPを利用することでどこからでもアクセスできる可能性を排除できません。
今回はCloudSQLのアクセス経路、アクセスユーザを制限してCloud SQLのパブリックIPを削除したセキュアな構成について説明していきたいと思います。
CloudSQLのパブリックIPを利用する際の注意点
CloudSQLのパブリックIP設定部分には次の説明が記載されています。
ここの注意点なのですが実際の仕様は
- 認可済みネットワークからのアクセスはOK
- CloudSQL Proxyを使うと認可済みネットワーク以外からでもアクセスがOK
というところです。つまり、接続情報、認証情報が何かしらの形で漏れてしまった場合、CloudSQL Proxyを利用して世界中のどこからでもCloudSQLにアクセスが行えてしまいます。図に表すと次のような状態となります。
利便性とセキュリティリスクのバランスを考慮し、セキュリティ対策としてはこれで十分と判断するケースもありますが、今回はさらにセキュリティレベルを上げてアクセスできるネットワーク、ユーザを絞った構成を作りました。
パブリックIPの排除とそれに伴うアクセス経路の変更
CloudSQL Proxyを使われた場合アクセス元は制限できない。という状態を防ぐためにCloudSQLのパブリックIPを削除する方針は確定しました。では、その状態で開発者はどのようにCloudSQLを利用するかという課題が残ります。
Google Cloudのコンソールを使うなどしてデータにアクセスは行えますが、やはり慣れたツールを使って開発したいものです。それを実現するために、CloudSQL Proxyを使用した踏み台GCEを作成し、これをに使う構成を考えました。
ただ、踏み台GCEにパブリックIPを使うと単純にリスクを転移しただけになってしまうため、IAP(Identity-Aware Proxy)を使って踏み台GCEのパブリックIPを使わず、かつ利用できるユーザ、ネットワークを制限した上で踏み台GCEにアクセスし、そこからCloudSQLに接続する方式としました。
実際に行った設定
踏み台GCEを作成します。踏み台GCEにはCloudSQL Proxyをインストールし、サービスとして起動するようsystemctlの定義(例:/etc/systemd/system/cloud-sql-proxy.service)を作成します。
systemctl定義における実行コマンドは以下となります。systemctlの設定をenableとすることで(例:systemctl enable cloud-sql-proxy.service の実行)、踏み台GCE起動時にCloudSQL Proxyサービスが自動起動するように設定が行えます。
ExecStart=/usr/local/bin/cloud-sql-proxy --address [リッスンIPアドレス] --port [リッスンポート番号] --private-ip [DB接続名]
IAPのメニューから該当の踏み台GCEに対してIAP Secured Tunnel UserとしてDBにアクセスする開発者のIAMユーザを追加します。
あわせて、この時はIAMの条件にオフィスからインターネットにアクセスする際のIPアドレスのみアクセスを許可する設定を追加しました。これによって、踏み台GCEにアクセスできるユーザと場所の制限が行えます。
開発者の方は自端末で次のコマンドを実行してIAPトンネルを作成の上、各自が利用しているツールで接続先にlocalhost、ローカルホストで使用するポート番号を指定することで、透過的にCloudSQLにアクセスを行えるようになります。
gcloud compute start-iap-tunnel \ <踏み台GCEのホスト名> \ <踏み台GCEのCloudSQL Proxyのリッスンポート番号> \ --local-host-port=localhost:<ローカルホストで使用するポート番号> \ --zone=<踏み台GCEのゾーン>
最後に
今回はCloudSQLにどこからでもアクセスできる可能性をなくした構成を作成しました。
認証情報、接続情報が漏れなければパブリックIPを使っても問題がない、という判断も一定ありますが今回の構成は導入にあまり手間はかからず、かつ「仕組み上どこからでもアクセスが可能」というセキュリティ上の懸念点を排除できるという点では積極的に導入を検討してもよい構成ではないかと思います。