Google Cloud のコンソールや API へのアクセスをアクセス元の IP アドレスで簡単に制限する方法

Published in

google-cloud-jp

16 min readOct 4, 2021

こんにちは。Google Cloud Japan でカスタマーエンジニア（プリセールスエンジニア）をしている有賀です。

クラウドサービス利用のご相談に乗っていると、ときどき(しばしば？)、ウェブコンソール(クラウドサービスを設定するためのウェブページ。Google Cloud では Cloud Console と呼びます。)や、API へのアクセスをアクセス元の IP アドレスで制限したい、というご要望を受けることがあります。

インターネットでサービスを公開する際のアクセス制限として、ID とパスワードだけでは不安（パスワードが漏れたらアクセスされ放題に！）だから、追加でアクセス元の IP アドレスで制限する、というのはそこそこ一般的におこなわれていたかと思います。（ゼロトラストのアプローチもあると思いますが、それはまたの機会に。:-)

こういった機能をオンプレミスで提供する場合は、ファイアウォールやウェブサーバーなどで IP アドレスによるアクセス制限をおこなうと思いますが、クラウドサービスの場合は、コンソールにせよ API にせよ、全ユーザーが共通の宛先にアクセスするので、たとえば自分の家からしかアクセスさせない！といった設定をするわけにはいきません。

そこで Google Cloud では、各ユーザーがアクセス元のアドレスを事前に定義し、そのユーザーとしてアクセスする場合はアクセスを事前に定義されたアドレスからのみに制限するという機能を提供しています。

（ちなみに、楽天銀行さんでも、事前に IP アドレスを登録することで自分のアカウントへのアクセスを IP アドレスで制限できる機能を提供されています。同じような機能ですね。）

実際の動作

では実際にアクセス元を制限した場合、どのように動作するかを見てみましょう。（当たり前ですが、許可されたアクセス元からは普通にアクセスできるので、ここではブロックされる様子だけを確認します。）

まず初めに、許可されていないアクセス元から Cloud Console（https://console.cloud.google.com/）へアクセスするとこんな画面になります。（すでに Google アカウントにログインした状態でアクセスしたので、ログイン画面は省略されてます。）

（URL バーを見ると https://admin.google.com/ になってるのが分かるかと思いますが、これは https://console.cloud.google.com/ → https://accounts.google.com/info/servicerestricted?… → https://admin.google.com/caa/access-denied?… とリダイレクト（HTTP 302）された結果です。）

このように、Cloud Console のトップページも表示されず、当然ですが、各種サービスへもアクセスできません。

では CLI（gcloud コマンド）でのアクセスならどうでしょう。

$ gcloud services list --limit=1
ERROR: (gcloud.services.list) UNAUTHENTICATED: Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.

認証はできてたはずですが、認証が無効だと返ってきてしまいました。ちなみに、この状態でアクセス元の IP アドレスを許可すると、このように問題なくアクセスできるようになります。

$ gcloud services list --limit=1
NAME                           TITLE
accessapproval.googleapis.com  Access Approval API

認証が無効だと言うなら、念の為、再度（アクセスが許可されてないところから）認証をしてみます。

$ gcloud auth login
Your browser has been opened to visit:https://accounts.google.com/o/oauth2/auth?response_type=code...
（ブラウザでアクセスし認証を完了）ERROR: Access was blocked due to an organization policy, please contact your admin to gain access.
ERROR: (gcloud.auth.login) (access_denied) Account restricted

組織のポリシーでアクセスがブロックされたと返ってきました。許可されていないアクセス元からだと認証情報が無効扱いになり、再認証もできないことがわかりました。

このように、アクセス元を制限されたアカウントでアクセスしようとすると、Cloud Console でも gcloud コマンドでもまったくアクセスできなくなることが分かります。

なお、Google Cloud を使ったことがある方は「あれ？プロジェクトの選択もできないの？」って思われたかもしれませんが、その通りです。このアクセス元の制限をすると、制限の対象となったアカウントはプロジェクト等に関係なく、一切の Google Cloud のサービスにアクセスできなくなります。

ちなみに、Google Workspace をお使いの場合も、（ご利用のライセンスによりますが）同じようにアクセス元による制限をかけることができます。

設定

設定の手順は Google Cloud のドキュメントにも載っていますが、以下、簡単に見ていきたいと思います。

なお、本設定をおこなうには、先に Google Cloud における「組織」（Organization）というものが使えるようになっている必要があります。

設定の流れは以下の通りです。

許可するアクセス元の定義
アクセス制限の対象とするユーザーの定義
上記を使って実際にアクセス制限を有効化

許可するアクセス元の定義

まず初めに、許可するアクセス元を定義します。

Cloud Console・API へのアクセス制限を有効にすると、デフォルトではアクセスが拒否されるので、アクセスしたい IP アドレス（ネットワークアドレス）を定義します。

Google Cloud（と Google Workspace）では、そのようなアクセス元の定義に Access level という設定を使います。Access level には IP アドレス（ネットワークアドレス）だけでなく、アクセス元地域やアクセス元デバイスの状態なども条件として定義できますが、本記事では IP アドレスだけを使います。

まず Access level の設定は Access Context Manager でおこなうので、Cloud Console のメニューから「セキュリティ」ー「Access Context Manager」へ行きます。すると「この機能には組織が必要です」となるので、組織を選択します。

Access level の新規作成を選択します。

Access level に名前(例：”console_access”）を付け、条件として「IP サブネットワーク」を選び、例として「203.0.113.0/28」「192.51.100.40/32」をアクセス元として定義します。

アクセス制限の対象とするユーザーの定義

許可するアクセス元の定義ができたので、次にこの Cloud Console・API へのアクセス制限を適用するユーザーを定義します。

ユーザーの定義には Google groups の仕組みを使ってます。Google groups はもともとメーリングリスト（とネットニュース。ネット上のニュースのことじゃないですよ。:-）のサービスですが、Google Cloud ではユーザーをグループとして扱う際の仕組みとして使っています。

というわけで、まずは Cloud Console のメニューで「IAM と管理」ー「グループ」へ行きます。（ここでも上と同じように「組織」を選びます。）

なお、すでに例えば「管理者グループ」等のグループを使っている場合は、もちろんそれをそのまま使っていただくこともできます。

新規にグループを作成します。

グループの名前、グループのメールアドレス、説明、そしてグループに属するメンバーのアカウント（メールアドレス）を追加していきます。なお、メンバーとして他のグループを追加する（入れ子にする）ことも、もちろんできます。

一つ注意点として、すべてのユーザーを制限の対象としてしまうと、たとえば許可したアクセス元からの接続できなくなってしまった場合などに、すべてのユーザーが締め出されてしまうため、たとえば普段は使わない組織の管理者アカウントなどは対象外としておくのがよいでしょう。

もし本当に全員が締め出されてしまった場合は、Google group のメンバーの設定を Google Workspace 側の管理コンソールからでも変更できますので、そちらで制限対象ユーザーを変更していただけます。

実際にアクセス制限を有効化

ここまでで、アクセス元の定義、制限対象ユーザーの定義ができたので、実際にアクセスの制限をしていきたいと思います。

Cloud Console のメニューで「セキュリティ」ー「BeyondCorp Enterprise」へ行きます。ここからの画面の遷移がちょっと分かりにくいので、気をつけてください。

（2023–04–21追記：なお「BeyondCorp Enterprise」のメニューの中にありますが、IP アドレスによるアクセス制限だけであれば、ご利用に当たって BeyondCorp Enterprise のライセンスは不要です。）

まず、上記メニューを選んだ際にすでに「組織」を選択していた場合は次のように「プロジェクト」を選ぶ画面に遷移します。その場合、何でもいいので一つ「プロジェクト」を選んでください。

すると以下のように「BeyondCorp Enterprise で GCP Console と API を保護します。」という選択肢が出てくるので、そこをクリックします。（なお、メニューでの遷移の際にすでに「プロジェクト」を選択していた場合は、すぐにこの画面に遷移します。）

(2023–04–21：スクリーンショットを更新)

すると「Cloud Console と API の保護」というカードが出てきますので「アクセスを管理」をクリックします。（右上に「プロジェクトを選択」という、いかにも先に選ばないといけなさそうなリンクもありますが、こちらは無視して進んでください。）

アクセス制限の設定を追加します。

制限対象として2つ目のステップで作ったグループを選択、許可するアクセス元として1つ目のステップで作った Access level を選択し、保存します。

これでアクセス制限ができました。「追加」となっていることから分かるように、Google グループごと（つまり、アカウントごと）に異なるアクセス制限を定義することが可能です。たとえば、拠点の異なる開発チームがあるとして、それぞれ別のアクセス元（IP アドレス）からのアクセスを許可することができます。

アクセス制限を再度無効にしたいばあいは、上で作成したアクセス制限の設定を削除すれば、すべてのユーザーがアクセスできるようになります。（グループやアクセス元の定義は削除してもそのままにしても大丈夫です）

その他の細かいポイント

Q. 設定の反映にはどれくらい時間がかかりますか？

A. ドキュメント的には「最大 24 時間かかります」が回答になりますが、実際のところ数分くらいで反映されることが多いと思います。

Q. アクセス制限の設定を複数できるということは、あるユーザーがある設定では許可されてるけど、他の設定では許可されてない、という状態になり得ると思いますが、その場合はどうなりますか？

A. そのユーザーが対象となる設定のうち、一つでもアクセスを許可する設定になっている場合、アクセスできこととなります。（OR 判定ですね）

Q. 組織外のアカウント（ie. アカウントのメールアドレスのドメインが違う）を制限対象グループに入れたら、アクセス元を制限できますか？

A. できません。上の方で見た動作の様子から類推いただけると思いますが、このアクセス制限は認証の仕組みに依存しています。組織外のアカウントの場合、認証の仕組みはそのアカウントの組織側でおこなわれるため、本機能によるアクセス制限の対象とはなりません。（というわけで、組織外のアカウントをプロジェクトに追加したくなった時は、そのことによる影響を少し考えてみましょう。）

Google Cloud の組織ポリシーサービスという機能を使うと、組織外のアカウントの追加を制限することができます。
（ constraints/iam.allowedPolicyMemberDomains という制約を使います。）

(2021–10–14 追記)

逆に、この「アクセス制限の対象となっている組織内のアカウント」を外部の何ら制限されてないプロジェクトに追加した場合でも、当該プロジェクトには「アクセス制限の対象となっているアカウント」からは（許可された接続元以外から）アクセスできません。

これは「Cloud Console と API のアクセスの管理」が、「どのプロジェクト」や「どの組織の」といった区別はなく、「Google Cloud 全体の Cloud Console と API へのアクセスの制限」であるためです。

Q. この機能で Cloud VPN（IPsec VPN）や Cloud Interconnect（専用線）で接続されたオンプレミスからのアクセス元を、たとえば一部のネットワーク（アドレス）だけに制限できますか？

A. 残念ながらできません。Access level に設定できるアクセス元のアドレス（ネットワーク）はパブリック IP アドレスの範囲だけになります。（ちなみに、オンプレミスから Cloud VPN、Cloud Interconnect を経由しての Cloud Console へのアクセスは、Google Cloud 内に用意いただいた Compute Engine の VM をプロキシとして使っていただくことで可能です。）

Q. 許可するアクセス元は何個くらい定義できるのでしょうか？（ie. Access level には何個くらい IP アドレス（ネットワーク）を設定できるのでしょうか？）

A. 各 Access level ごとに 200 個です。

Q. API にアクセスできるソース IP アドレスでの制限をしちゃうと、サービスの動作に影響が出そうな気がするんですが、大丈夫なんでしょうか？

A. 本制限は制限対象としたアカウントでのみ有効になり、たとえばサービスアカウントは対象とならないので、サービス間の API 連携などには影響はありません。(逆に言うと、サービスアカウントのキーファイルを使った認証などは制限できませんので、お気をつけください。)

このように簡単に Google Cloud のコンソールや API へのアクセスをアクセス元の IP アドレスで制限することができました。

なお、この制限は組織単位（とアカウント/グループ単位）での制限となるため、たとえば本番プロジェクトは制限したいけど、開発プロジェクトは制限したくない、といったプロジェクトの単位での制限の可否は選べません。

また、たとえば BigQuery へのアクセスは制限したいけど、Compute Engine の操作は特に制限しなくてもいい、といったサービスごとの制限の可否も選べません。

もしそのような、もう少し粒度の細かいアクセス制限をしたい場合は、単なるアクセス元による Cloud Console・API へのアクセス制限だけではなく、もう少し広い制限も提供する VPC Service Controls という機能で実現することができます。（少し前の記事ですが、BigQuery へのアクセス制限を VPC Service Controls で実現する方法を開設した記事があります。→ 「GCP を利用したセキュリティ要件対応：VPC Service Controls を試してみた」）

VPC Service Controls まで含めた包括的なアクセス制限の話を始めると膨大になってしまうので、この記事では一旦ここまでとしたいと思います。

もし質問等がございましたら、コメントをいただけると嬉しいです！