Google Cloud でパブリック IP を制限

※この投稿は米国時間 2021 年 2 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

「セキュリティに関しては、期待は戦略になり得ない」という言葉があります。セキュリティに関する開発や運用の負担を最小限に抑えつつ、あらゆる角度からアプローチする必要があります。しかし、エンドポイントやネットワーク、攻撃対象の数が増え続けるなか、クラウド インフラストラクチャ全体でセキュリティ ポリシーを自動設定し、徐々に浸透させるのは簡単なことではありません。さらに、管理者はワークロードがセキュリティ要件や業界の規制に常に準拠していることを確認するガードレールを設置する必要があります。

パブリック IP の使用は、インターネットに公開されているエンタープライズ環境が攻撃やデータ漏洩の影響を受けやすくなってしまう一般的な要因の一つです。そのためこうした環境を防護するうえで、パブリック IP を制限することが極めて重要です。Google Cloud Platform では、ネットワークのパブリック IP をどのリソースが使用しているかを把握しておくことが重要です。リソースには以下のようなものがあります。

• VM

• ロードバランサ

• VPN ゲートウェイ

開発者によってパブリック IP アドレスが割り当てられる可能性のあるインスタンスの数は数千にもおよぶ場合があります。管理者は本番環境レベルのシステムのデプロイを始める前に、こうしたインスタンスの管理方法を考える必要があります。

組織のポリシー

組織のポリシーを使用すると、組織の Google Cloud リソースを一元管理できます。組織のポリシー管理者は、リソース階層全体にわたって制限を設定することができます。

たとえば、最上位の GCP 組織、ネストされたフォルダ、プロジェクトに、組織のポリシーを設定することができます。これらのポリシーは、ネストされたフォルダやプロジェクトから継承することも、状況に応じてオーバーライドすることも可能です。組織のポリシーを使用すれば、VM やロードバランサなどの Google Cloud リソースに制約を課して、基本的なセキュリティ要件を常に遵守できます。

組織のポリシーをガードレールとして使用し、Google Cloud ネットワークでパブリック IP が許可されないようにすることができます。これは IT 管理者やセキュリティ管理者にとって、すべてのクラウド デプロイメントでセキュリティ基準を遵守するために最適な方法です。それでは設定方法を説明していきます。

VM のパブリック IP を制限する

Compute Engine インスタンスは、次の場合に直接インターネットに公開される可能性があります。

• VM にパブリック IP を割り当てる

• VM のエンドポイントとしてプロトコル転送を使用する

Compute Engine インスタンスがパブリック IP を取得しないようにするには、まずご自身が組織のポリシー管理者のロールを持っていることを確認します。このロールにより、組織のポリシーの追加や編集を行うことができます。

[カスタム値] に、外部 IP の作成を許可するインスタンスのパスを貼り付けます。例:

これで、明示的に指定したインスタンスのみがパブリック IP を作成できるよう制限し、組織内の他のインスタンスはパブリック IP を作成できなくなります。

VM へのプロトコル転送を禁止する

プロトコル転送を有効化できないようにするには、constraints/compute.restrictProtocolForwardingCreationForTypes という名前の組織のポリシー制約を使用し、次の値に設定します。ポリシー値では大文字と小文字が区別されます。

この制約を使用すると、組織内で Compute Engine VM インスタンスによるパブリック IP の仮想ホスティングを制限できるようになります。

VPN ゲートウェイのパブリック IP を制限する

VPN の場合、VPN ゲートウェイで、オンプレミス環境を Google Cloud に接続するためのパブリック IP アドレスが必要になります。VPN ゲートウェイを確実に保護するには、constraints/compute.restrictVpnPeerIPs という名前の組織のポリシー制約を使用します。この制約は、VPN ゲートウェイで IPSec セッションの開始を許可するパブリック IP を制限します。

ロードバランサのパブリック IP を制限する

Google Cloud には、さまざまな内部ロードバランサと外部ロードバランサが用意されています。あらゆるタイプの外部ロードバランサが作成されないようにするには、constraints/compute.restrictLoadBalancerCreationForTypes という名前の組織のポリシー制約を使用します。その後ポリシー値としてすべての外部ロードバランサを次のように追加します。

ロードバランサごとに手動入力する代わりに、in:EXTERNAL を追加して、常にすべてのタイプの外部ロードバランサを対象にすることもできます。そうすることで、ロードバランサの新しいタイプが導入された場合でも、インフラストラクチャの安全を保つことができます。

GKE サービスを制限する

Google Kubernetes Engine（GKE）を使用すると、開発者は簡単にサービスを作成してインターネットに公開できます。しかし前述の VM やロードバランサのポリシーを適用すれば、組織管理者の知識がなくても、新しい GKE サービスがインターネットに公開されることはなくなります。

たとえば開発者が外部ロードバランサを使用して GKE サービスを作成しようとした場合、組織のポリシー制約が適用されている状態では、必要なロードバランサに対する転送ルールを作成することはできません。さらに、GKE サービスのステータスを確認することで、外部 IP を保留することができます。また kubectl describe service を実行すると、ロードバランサの組織のポリシー制約が適用されていることにより、エラーが発生します。

組織のポリシーが過去に遡って適用されることはありません。ポリシーが設定された後に行われたインフラストラクチャのリクエストにのみ適用されます。そのため、組織のポリシーを組織に追加しても、既存のワークロードの中断について心配する必要はありません。組織階層全体またはリソースのサブセットに対して、一元化された場所から簡単かつ効果的に組織のポリシーを適用でき、パブリック IP を持つ必要のないリソースにパブリック IP を割り当ててしまう事態を避けることができます。ご自身の組織でぜひお試しください。詳しくは、組織のポリシー制約に関するドキュメントをご参照ください。

クラウド コンテンツについてさらに詳しくお知りになりたい場合は、Twitter で @stephr_wong をフォローしてください。

-デベロッパー アドボケイト Stephanie Wong