セキュリティを意識した Google Cloud で構築する開発環境プラクティス

先日の OpenSSH の脆弱性の件を受けて、チーム内にあらためて Google Cloud で開発環境を構築する際のセキュリティ観点でのプラクティスを展開しました。自分自身セキュリティで痛い目にあったことがあるため、これから Google Cloud で開発環境を構築を検討される方の一助になればと思いこちらでも発信しようと思います。

ここでは Compute Engine を立てて、そこを開発環境とすることを想定しています。

※ 各項目は個人的なプラクティス集です。
※ 各項目について、Google Cloud 公式ドキュメントに「ベストプラクティス」が存在する場合は、項目内に記載しています。
※ 内容についてより良い方法がある場合にはコメントいただけると幸いです。

この記事のターゲット

• Google Cloud で開発環境を構築を検討している方
• 現在の環境にセキュリティ観点で不安がある方

セキュリティを甘くする怖さ

必ず起こるわけではない

セキュリティインシデントは交通事故などと同じでいつ襲ってくるかわかりません、逆を言えば必ず襲ってくるものでもないので油断してしまうところがあります。例えば、信号を無視しても必ず事故に出くわすわけではないですが、事故に出くわす確率は高くなるのと似ていると思っています。（もちろん、信号無視はダメですよ！例えばの話です）

この何かしらがすぐに起こるわけではないというのが脇が甘くなってしまう由縁なのだと思います。検証のために少しセキュリティを甘くしてそのままにしてしまう・・・なんてこともあるのではないでしょうか。

どんなインシデントがあるか

セキュリティ起因のインシデントの具体例を考えてみましょう。例えば、開発環境で利用していた Compute Engine に侵入されたとします。侵入された Compute Engine がマイニングに利用されるかもしれないし、他社・他国をアタックする踏み台サーバーに利用されるかもしれません。

他社・他国をアタックする踏み台として利用された場合は、訴訟に発展することもあるかもしれませんね。想像するだけでお腹が痛くなります。。

また、1 台が利用される程度であれば大したことはないと思うかもしれません。たしかにそこまでサイズの大きくない Compute Engine だけであればそうかもしれませんが、同一ネットワークで複数のサーバーに侵入される可能性もありますし、そのサーバーが持っている権限が強力であれば何でもできてしまいます。

特に後者は「開発環境だし、とりあえず管理者相当のオーナー権限を付与して検証しやすい状態にしよう」という方もいるかもしれません。気持ちはわかりますが、こういった事例を想像すると非常に怖いですよね。

どんな心構えでいるべきか

システムやセキュリティーに 100% はないと思っていますが、安全性を 100% に極力近づけることはできると思っています。以降に記載する内容にはそういったセキュリティイインシデントに出くわす可能性を極力引き下げるためのプラクティスをまとめています。

ポイントは下記の 2 点になります。この点を意識してすることでプロアクティブ/リアクティブのどちらにも効果がある環境構築できると考えています。

• ポイント①：セキュリティイインシデントに出くわす可能性を極力下げる
• ポイント②：セキュリティイインシデントが発生した際に原因調査を楽にする

では、実際に何を意識して開発環境を構築していくとよいか見ていきましょう！

※ 以降は、個人でプロジェクトを利用しているケースとチームでプロジェクトを利用しているケースの区別はつけていない点をご留意いただければと思います。
※ 項目によっては、開発環境には関係ないセキュリティ関連の話をしています点もご留意いただければと思います。

ネットワーク関連

VPC を含むリソースの管理者を明確にする

開発環境として Compute Engine インスタンス（以降、インスタンスと呼びます）を作成するのであれば、VPC を作成しましょう。　Google Cloud には default という VPC が既存で存在しますが、自身の開発環境用として VPC を作成するのが望ましいです。

ここで重要なのは、その VPC を誰が責任を持って管理しているかという点です。例えば、default という名のデフォルト VPC は利用しやすいように色々設定されていますが、管理について責任を持っている人がいないケースが多いです。また、チームで default を共通で使っている場合には、自身が意図しないネットワーク設定が他の人によって行われるケースもあります。

既存の設定として把握していない設定が入っていたり、誰も責任を持って管理していないことで意図しないネットワーク設定が反映されるリスクを避けるためにも、VPC は開発用として新たに作成して自身が責任を持って管理することが重要と考えています。

余談

デフォルト VPC ネットワークについてこちらの記事で解説がなされています。この中でも下記のような言及があります。

もちろん、サクッとプロジェクトを作って、サクッと検証したい場合などにデフォルトネットワークが存在すると便利な側面はあります。
しかし、セキュリティの面を考えると、特に本番稼働するシステムにおいては、使用しない方が良いのではないかと思います。
Google Cloud の VPC デフォルトネットワークは使わないで！ - まとめ

本番環境ではもちろんですが、加えて私自身は開発環境での利用も避けた方がよいと考えています。その理由は次の項目を考慮するためです。

ファイアウォールによって攻撃される範囲を最小限にする

VPC に設定するファイアウォールルールは目的ごとに作成して必要最低限の IP 範囲とポート設定にしましょう。 悪意を持った人間から攻撃される範囲は常に最小限に抑えることが望ましいです。

1 つのルールに多くの目的を持たせようとするとアクセス元に色々な IP 範囲やポートを設定することになり、結果としてある IP 範囲に対して不要なポートを許可することになります。

広い IP 範囲と多くのポートの許可は攻撃される範囲を拡大することを意味します。攻撃範囲が広い例でいうと、default-allow-ssh というデフォルトファイアウォールが存在しますが、IP 範囲に 0.0.0.0/0 でプロトコル/ポートに tcp:22 を許可する設定されています。このファイアウォールルールを使用するとインターネット上のすべての IP アドレスから 22 番ポートでアクセスを許可することになります。

不要なアクセスを弾くためにもファイアウォールルールは目的ごとに必要最低限の IP 範囲とポートを設定し、責任を持って管理することが重要だと考えています。

特に SSH に関するファイアウォールルールは、特定の IP 範囲からのみ許可し、他の IP 範囲からのアクセスはブロックするなどケアをしましょう。後述する Identity-Aware Proxy の利用を検討しましょう。

ベストプラクティス

ファイアウォールルールは Cloud NGFW というサービスのリソースという形で整理されています。詳しくはこちらの記事が綺麗にまとっています。

なお本サービスは、かつて Cloud Firewall と呼ばれていましたが、2024年4月8日にリブランディングし、Cloud NGFW へと改称されました。
Cloud Next Generation Firewall(Cloud NGFW)を徹底解説！

この Cloud NGFW の公式ドキュメントの中では下記のようにベストプラクティスが記載されています。（一部抜粋）

ファイアウォールルールを設計および評価するときは、次のベスト プラクティスを考慮してください。

• 最小権限の原則を実装する。デフォルトでは、すべてのトラフィックをブロックし、必要な特定のトラフィックのみを許可します。また、ルールを必要なプロトコルとポートのみに制限します。
  ...
• 「許可」ルールの場合は、VM のサービス アカウントを指定して、特定の VM に制限する。
• IP アドレスに基づいてルールを作成する必要がある場合は、ルール数を最小限に抑えるようにする。別々のルール 16 個を追跡するよりも、16 個の VM の範囲へのトラフィックを許可するルール 1 つを追跡するほうが簡単です。
  ...
  公式ドキュメント - ファイアウォールルールのベストとプラクティス

改めて、ベストプラクティスを読んで私自身勉強になりました。上から 2 つ目に言及されている内容は、ファイアウォールルールで指定する「ターゲット」に関連するものでしょうか。こちらの設定では「ネットワーク上のすべてのインスタンス」「指定されたターゲットタグ」「指定されたサービスアカウント」から選択できるので、その中で「指定されたサービスアカウント」を選択して、対象となる VM を制限しましょうという話のようですね。

また、IP アドレスに基づいてルールを作成する場合は、ルール数を最小限にするという点もなるほどという感じでした。

余談

先日の OpenSSH の件でも、こちらの記事に記載がある通り default-allow-ssh の利用がクリティカルでした。（default-allow-ssh ルールは、インターネット上のあらゆる場所から SSH アクセスを許可してしまうため、攻撃者による不正アクセスやマルウェア感染のリスクが高まります。） default という VPC にはこちらのファイアウォールに加えて他のデフォルトファイアウォールが複数紐づいているため不要なアクセスを招きかねないと思っていますので、開発環境においても default ネットワークの利用は避けた方がいいのではと考えています。

https://zenn.dev/cloud_ace/articles/cve_2024-040

フローログ/ファイアウォールルールのログで追跡を可能にする

VPC 内のサブネットのフローログはオンにしましょう。 フローログにはインスタンスによって送受信された通信の情報が記録されます。フローログの収集によって費用が発生しますが後述するユースケースは多くの場合に役立つのでオンにすることが望ましいです。

フローログのユースケースの中でも「ネットワークフォレンジック」はセキュリティ観点で特に重要となります。（ユースケースの詳細は公式ドキュメントを参照ください。）

ネットワークフォレンジック
VPC フローログをネットワークフォレンジックに利用できます。たとえば、インシデントが発生した場合、以下を調べることができます。
・ どの IP が、いつ、どの相手と情報をやり取りしたか
・ 不正使用された IP（すべての受信と送信のネットワーク フローを分析して調査）
公式ドキュメント：VPCフローログ - ユースケース

セキュリティインシデントが起きた際に現状把握としてどのような通信が発生していたのかを調査する必要があります。その調査に有効な情報の 1 つがフローログとなります。

フォレンジック（Forensics）という言葉はもともと医学用語として使用されているものです。「法医学的な分析および調査」という意味があり、警察が事件/事故現場で行う「鑑識」をイメージすると分かりやすいでしょう。事件/事故が発生した際には、現場の状況を保全し、調査し、解析します。
このフォレンジックにネットワークを付け足したのがネットワークフォレンジックです。一般的に情報セキュリティインシデントが発生することを想定して、ネットワーク上のデータの動きを調査/解析して、「どの端末が/いつ/どのような経路で/何を送信したのか」といった内容の情報を、完全性を保った状態で記録しておくものです。
ネットワークフォレンジックとは一体なんなのか？基本を解説

また、ファイアウォールルールのロギングは下記の情報が記録されます。

ファイアウォール ルールのロギングでは、Compute Engine 仮想マシン（VM）インスタンス間のトラフィックが記録されます。これには、Google Kubernetes Engine（GKE）クラスタや App Engine フレキシブル環境のインスタンスなど、Compute Engine VM 上に構築された Google Cloud プロダクトが含まれます。
ファイアウォール ルールに対してロギングを有効化すると、そのルールによってトラフィックが許可または拒否されるたびに、Google Cloud が接続レコードと呼ばれるエントリを作成します。
接続レコードごとに、送信元 IP アドレス、宛先 IP アドレス、プロトコルとポート、日時、およびトラフィックに適用されたファイアウォール ルールへの参照が記録されます。
公式ドキュメント：ファイアウォールルールロギングの概要

ファイアウォールルールの効果を監査/検証/分析の目的で、ルールのロギングを使用することが推奨されています。ファイアウォールが意図通りに機能しているかやセキュリティインシデントが発生した際の原因が何であるのかの調査のために分析するケースもあるため、ロギングはオンが望ましいです。

セキュリティインシデントが起きた際に経路が特定できないことはその後の根本対応ができないことを意味します。そんな状況を防ぐためにもフローログおよびファイアウォールルールのロギングは必ずオンにして、もしもの状況に備えておくことが重要だと考えています。

インターネットから接続可能なインスタンスを最小限にする

インスタンスにパブリック IP を付与するのは必要最低限な時のみにしましょう。 パブリック IP を付与することは、インターネットを介してアクセスが可能になることを意味します。（もちろん、パブリック IP のみに依存する話ではないですが。）逆を言えば、インターネットを介してアクセスされるリスクが上がるので必要最低限の払い出し・付与が望ましいです。

開発環境であればインスタンスにパブリック IP を付与してローカルから SSH するという構成が思いつきますが、必ずしもパブリック IP は必要ありません。Identity-Aware Proxy という機能を利用することで実現できるので、気になる方は読み進めていただければと思います。

パブリック IP の付与はアクセスされる余地を作るというだけなので上述した中でもファイアウォールをきちんと最小限に管理していればリスクは極力下げられると考えていますが、例えば使用頻度が下がったインスタンスにパブリック IP を付与しっぱなしというケースを思い浮かべると攻撃される対象の拡大につながることが想像されるため、やはりパブリック IP は必要最低限の払い出し・付与であるべきと考えています。

IAM関連

付与する権限を最小限にする

インスタンスに設定するサービスアカウントに付与する権限を最小限にしましょう。インスタンスにはサービスアカウントを設定することでき、インスタンス上から他の Google Cloud サービスにアクセスする際にはそのサービスアカウントの権限を利用するので、インスタンスに侵入されることを想定するなら付与する権限は最小限が望ましいです。

Google Cloud での権限（storage.buckets.create のような特定の操作を実行可能とする最小単位）はロールという形で 1 つ以上にグルーピングされて、プリンシパル（ユーザー、グループ、サービスアカウントなど）に付与されます。このロールは下記の 3 種類が存在して、それぞれ特徴があります。

IAM には、次の 3 種類のロールがあります。
・ 基本ロール: IAM の導入前に存在していたオーナー、編集者、閲覧者のロールが含まれます。
・ 事前定義ロール: 特定のサービスへのアクセスを細かく制御します。また、Google Cloud により管理されます。
・ カスタムロール: ユーザー指定の権限のリストに応じたきめ細かなアクセス権が提供されます。
公式ドキュメント：ロールと権限 - ロールのタイプ

冒頭にも書きましたが、開発環境だから検証しやすいようにオーナーロールや編集者ロール（広く権限が紐づいている基本ロール）を付与してしまうという気持ちはわかりつつ、次に書くサービスアカウントキーの払い出しの際のリスクも高めるため最小限の事前定義ロールもしくはカスタムロールでの権限付与が必要だと考えています。

ベストプラクティス

上記の内容に関しては公式ドキュメントでは、下記のように記述されています。（一部抜粋）

最小限の権限
❑ 基本ロールには、すべての Google Cloud サービスにかかわる多くの権限が含まれます。本番環境では、他に選択肢がない限り、基本ロールを付与しないでください。代わりに、ニーズに合わせて最も制限された事前定義ロールまたはカスタムロールを付与します。
...
次のような場合には、基本ロールの付与をおすすめします。

• Google Cloud サービスで事前定義ロールを利用できない場合。使用可能なすべての事前定義済みロールのリストについては、事前定義済みのロールの表をご覧ください。
• プロジェクトに関する幅広い権限を付与する必要がある場合。この状況は、開発環境またはテスト環境で権限を付与する場合によく生じます。
• メンバーがきめ細かい権限を必要としない小規模なチームで働いている場合。

...
❑ 必要最小限の範囲のロールを付与します。たとえば、Pub/Sub トピックをパブリッシュするアクセス権だけを必要とするユーザーには、そのトピックのパブリッシャーのロールを付与します。
...
❑ 条件付きロール バインディングを使用してアクセスを自動的に期限切れにし、ジャストインタイムでのみ特権アクセスを付与することを検討します。
公式ドキュメント：IAM を安全に使用する - 最小限

こちらではユースケースによっては、基本ロールの付与をすすめていますね。極力最小の方が良いと思いますが、例えば多くのリソースをデプロイするためのアカウントに対して幅広い権限を必要とする場合は、広く権限を持った基本ロールを付与することはあるなと思いました。

サービスアカウントは目的ごとに作成する/定期で棚卸しをする

サービスアカウントの目的ごとに作成は今まで記述したものと意図は同様です、一方で目的ごとに作成しているとサービスアカウントが多くの作成されることが予想されます。不要なリソースを残しておくと、「このアカウントって削除していいんだっけ？」と時間が経った後のリソース掃除の時に困ることが多かったりするので定期的な棚卸しも合わせて実施することが望ましいです。

また、1 つのサービスアカウントを多くの目的で使用することは結果として多くの権限を付与することにつながります。多くの権限を持っていると「とりあえずこのサービスアカウントを使っておけばいい」と使い回しや共有につながりかねません。

そうすると、そのサービスアカウントは強力な権限を持った状態で多くのリソースに使われることになります。複数人で使っていたら意図しない権限をいつの間にか付与されることもあるかもしれません。さらに、そういったサービスアカウントを持ったインスタンスに悪意を持った侵入があった場合には被害は大きくなるでしょう。

少し妄想が過ぎたかもしれませんが、万が一のこのようなリスクを回避するためにも目的ごとに作成すること・定期的な棚卸しによって開発環境でも必要なサービスアカウントを明確にしておくことが重要だと考えています。

ベストプラクティス

IAM を安全に使用するという項目にはこのように記述されています。

サービスアカウント
❑ サービスアカウントを操作するためのベストプラクティスを採用します。サービス アカウントで権限が制限されていることを確認し、潜在的なセキュリティの脅威から保護します。
❑ インスタンスを実行するために使用中のサービス アカウントを削除しないでください。これを削除すると、先に別のサービス アカウントを使用するよう移行していなかった場合に、アプリケーションの全体または一部が失敗することがあります。
❑ サービス アカウントの表示名を使用して、そのアカウントの用途やアカウントに必要な権限を管理できるようにします。
公式ドキュメント：IAM を安全に使用する - サービスアカウント

さらにサービスアカウントを操作するためのベストプラクティスには下記の項目ごとにベストプラクティスが載っています、詳細はドキュメントを参照ください。

サービス アカウントの使用に関するベストプラクティス
・サービスアカウントを管理する
・サービスアカウントの権限を制限する
・権限昇格の脅威からの保護
・情報開示の脅威からの保護
・否認防止の脅威からの保護
公式ドキュメント：サービス アカウントの使用に関するベストプラクティス

改めてドキュメントを見てみると、サービスアカウントの操作だけでもこれだけ考慮すべきことがあるんだなと勉強になりました。私が上記で書いた項目は、この中の 1 つの項目に過ぎないので興味ある方はぜひ一読されてはいかがでしょうか。

サービスアカウントキーの払い出しは最小限にする

権限が付与されたサービスアカウントのキーの払い出しは最小限にしましょう。 払い出したサービスアカウントキーが何らかのミスで漏洩した際に、付与されている権限を簡単に行使されてしまうので、影響範囲を狭くするためにも目的に応じてロールを絞って権限を付与する上でサービスアカウントキーの払い出しは最小限が望ましいです。

公式ドキュメントの中でも下記のような警告がなされています。

サービス アカウント キーは、Google Cloud サービスの認証によく使用されます。ただし、適切に管理されていない場合、認証情報の漏洩、権限昇格、情報開示、否認防止などの脅威に対する脆弱性が高まる可能性もあります。
公式ドキュメント：サービスアカウントキーから移行する

サービスアカウントキーのようなクレデンシャルキーは作成してダウンロードした時点で漏洩する危険を 1 ミリでもはらむと思っています。なので、サービスアカウントキーの払い出しは最小限にして不要になったら削除を徹底するという意識が重要だと考えています。

ベストプラクティス

IAM を安全に使用するという項目にはこのように記述されています。

サービスアカウントキー
❑ 別のオプションがある場合は、サービス アカウント キーを使用しないでください。サービスアカウントキーが正しく管理されていない場合は、セキュリティ リスクが発生します。可能であれば、サービスアカウントキーよりも安全な代替手段を選択してください。サービス アカウント キーで認証する必要がある場合は、秘密鍵のセキュリティと、サービスアカウントキーを管理するためのベストプラクティスで説明されているその他の操作は、ユーザーの責任で実施してください。サービス アカウント キーを作成できない場合は、組織でサービス アカウント キーの作成が無効になっている可能性があります。詳細については、デフォルトで安全な組織リソースの管理をご覧ください。
❑ IAM Service Account API を使用して、サービス アカウント キーをローテーションします。キーをローテーションするには、新しいキーを作成し、新しいキーを使用するようにアプリケーションを切り替えます。その後、古いキーを無効にして、不要になった古いキーを削除します。
❑ ユーザーが管理するサービス アカウント キーを管理するためのプロセスを実装します。
❑ 暗号化キーとサービス アカウントキーを混同しないように注意してください。一般的に、暗号鍵はデータの暗号化に使用され、サービス アカウント キーは Google Cloud APIs への安全なアクセスのために使用されます。
❑ サービス アカウント キーをソースコードに組み込んだり、ダウンロード ディレクトリに置いたままにしたりしないでください。
公式ドキュメント：IAM を安全に使用する - サービスアカウントキー

さらにサービスアカウントキーを管理するためのベストプラクティスには下記の項目ごとにベストプラクティスが載っています、詳細はドキュメントを参照ください。

サービス アカウントの使用に関するベストプラクティス
・認証情報の漏えいを防ぐ
・権限昇格からの保護
・情報漏えいの脅威からの保護
・否認防止の脅威からの保護
公式ドキュメント：サービスアカウントキーを管理するためのベストプラクティス

私の考えはそもそもセキュリティインシデントを招きかねないサービスアカウントキーは極力払い出ししないようにということを記載しましたが、こちらのベストプラクティスでは払い出した場合の対策が記載されている印象でした。

Workload Identity 連携を利用する

Github Actions や外部クラウドサービスから連携する際には Workload Identity 連携を積極的に利用しましょう。今回の開発環境から話は逸れてしまいますが、サービスアカウントキーの払い出しを上記で書いたのでついでにこちらにも触れておきます。

Workload Identity 連携を利用する理由は下記のように記載されています。外部サービスからの連携にサービスアカウントキーを用いずに実現することが可能になります。

Google Cloud の外部で実行されているアプリケーションは、サービスアカウントキーを使用して Google Cloud リソースにアクセスできます。ただし、サービスアカウントキーは強力な認証情報であり、正しく管理しなければセキュリティ上のリスクとなります。Workload Identity 連携により、サービスアカウントキーに関連するメンテナンスとセキュリティの負担が軽減されます。
公式ドキュメント：Workload Identity 連携を使用する理由

以上が、自身が Compute Engine を開発環境として利用する際のセキュリティ観点でのプラクティスになります。以降の項目は私自身の最近の開発環境構築の選択肢について記載していますので、興味ある方は読み進めていただければと思います。

個人的な開発環境構築の選択肢

Cloud Shell を利用できるか検討する

Google Cloud には Cloud Shell というブラウザでターミナルやエディタを利用できる環境を提供しています。どこからでもコンソールからアクセスすることができて開発に必要な様々なパッケージがプリインストールされている点や Code OSS ベースのエディタも提供している点が便利だと感じています。コードをシンプルに編集するなら十分ですし、gcloud コマンドや terraform コマンドなどもインストールなしに利用できるため開発にすぐに取りかかれる点も嬉しいです。

Cloud Shell は、ブラウザから場所を問わずにアクセスできる、オンラインの開発および運用環境です。gcloud コマンドライン ツールや kubectl などのユーティリティがプリロードされたオンライン ターミナルを使用して、リソースを管理できます。また、オンラインの Cloud Shell Editor を使用して、クラウドベースのアプリの開発、ビルド、デバッグ、デプロイを行うこともできます。
公式ドキュメント：Cloud Shell - 概要

また、開発したアプリケーションの動作確認をしたい場合に任意のポートでブラウザアクセスしたいケースもあるかと思います。Cloud Shell ではその点もサポートしており、アプリケーションを実行後に「ウェブでプレビュー」機能によって任意のポートを指定することでローカルのブラウザに localhost:xx でアクセスしているのと似た挙動を実現できます。

Identity-Aware Proxy を利用する - SSH -

Cloud Shell ではなく Compute Engine で開発する際には上記で記載した内容に従って構築します。その中でパブリック IP を付与せずにローカルから SSH する手段として Identity-Aware Proxy を利用します。

詳細はこちらの記事が丁寧に説明してくれているので、ぜひご一読ください。
https://blog.g-gen.co.jp/entry/login-your-vm-with-iap

こちらの機能を使うとターミナルでの操作には十分なのですが、コードを編集しようとすると不便さが生じます。（コンソールから直接ターミナル画面を開くこともできますし、ローカルのターミナルからコマンドでアクセスすることも可能です。）

私の場合は、IDE として VS Code を使用しているので VS Code の Remote SSH と併用して、パブリック IP を持たない Compute Engine に VS Code から編集を行なっています。

https://qiita.com/daredeshow/items/1c939f03f6c05086e382

こうすることで開発用 Compute Engine にパブリック IP を持たせる必要がなく、適用するファイアウォールルールの IP 範囲は 35.235.240.0/20 のみとなり、インターネットに接続できるのであればどこからでも VS Code でコードの編集が可能となります。

パブリック IP を持たせてファイアウォールルールに自宅 IP を登録し、接続元が複数あればその IP を追加していくという従来の作業がなくなり管理するスコープも狭められたことでかなり利用しやすくなったと感じています。

Identity-Aware Proxy を利用する - 任意のポート -

また、Compute Engine 上でアプリケーションを開発して任意のポートでアクセスしたいことも多いです。その場合は、ローカルのターミナルで下記のコマンドを実行して、トンネリングをはります。こうすることで、ポートフォワーディングが可能となり、ローカルで指定した任意のポートからインスタンス上の任意のポートにアクセス可能となります。

Terminal

gcloud compute start-iap-tunnel [インスタンス名] [アクセスしたいポート] \
  --local-host-port=localhost:[ローカルで指定する任意のポート] \
  --zone=[インスタンスのゾーン]

# Ex. asia-northeast1-b にある instance-for-dev というインスタンスの 8000 番にアクセス
gcloud compute start-iap-tunnel instance-for-dev 8000 \
  --local-host-port=localhost:8000 \
  --zone=asia-northeast1-b

こちらもファイアウォールには上記の特定の IP のみ設定して、ポートだけルールに加えればいいので管理が楽になる点が嬉しいと感じています。

以上が、私が開発環境を構築する際の最近の選択肢です。パブリック IP 不要・ファイアウォールルールに特定の IP のみ設定・インターネットがあればどこからでもアクセス可能 というのがメリットと考えています。

さいごに

チームに展開した内容を一般的な話やベストプラクティスと照らし合わせて、改めて勉強になった部分や考えに自信が持てた部分がありました。また、改めて眺めると最小権限の原則がいかに重要かがわかりました。この何を最小限にすべきかを理解した上で、利用することを徹底したいと思いました。

すべてを厳密にやるのは大変かもしれませんので、どこを緩めるとどんなリスクが生じるかを理解した上で必要なプラクティスを取り入れてもらえたら幸いです。

こちらの内容が今後の Google Cloud で開発環境を構築する方のセキュリティ観点の一助になればと思います。