Google Cloud Platform
ファイアウォール ルールを堅固にする 3 つの方法
Google Cloud VPC（Virtual Private Cloud）のファイアウォール ルール管理者は、社内の開発者がルールを正しい VM インスタンスに適用できるように設定を施す必要があります。この保証がなければ、VPC 内の VM に置かれた機密データへのアクセスを管理しきれなくなったり、これらのインスタンスへの外部アクセスを許したりする恐れが出てきます。
管理者は、インスタンスの監視や監査体制を強化し、タグを使った不正なアクセスを食い止めなければなりません。その手助けとなるべく、Google VPC には必要なレベルの管理を実現する方法が複数用意されています。本稿ではそれを詳しく説明します。
例として、VPC 内の一連の VM で実行されているデータ ストアにおいて、利用者の課金データという機密情報へのアクセスを制限するファイアウォール ルールの設定について見ていきます。さらに、アプリケーションで使われる VM のうち、課金フロントエンド以外のものを作成できる開発者に対して、課金データへのアクセスを許可しないようにルールを設定してみます。
こうしたケースでは、従来は VM にタグを付け、特定のタグだけにアクセスを認めるファイアウォール ルールを作成するのが一般的でした。たとえば上の例では、billing-frontend タグを持つすべての VM に対して、billing-data タグを持つすべての VM へのアクセスを許可するファイアウォール ルールを作るのです。しかしこの方法には、プロジェクトの Compute InstanceAdmin ロールを持つ開発者が自身の VM に billing-frontend タグを与えると、機密データに不正アクセスできてしまうという欠点があります。
サービス アカウントを用いたファイアウォール ルールの設定
タグの代わりにサービス アカウントを用いたファイアウォール ルールの設定機能が正式リリース（GA）されたことにより、中央で一元管理されているサービス アカウントにアクセスできない開発者は、自身のインスタンスにファイアウォール ルールを適用できなくなりました。サービス アカウントは、VM 上で実行されるアプリケーションやサービスに属する特殊な Google アカウントで、それらのアプリケーションやサービスがリソースにアクセスするのを認証するために使われます。上の例で言うと、アクセス元のサービス アカウントが billing-frontend@ の場合のみ billing-data@ サービス アカウントへのアクセスを許可するファイアウォール ルールを作成できます。
このファイアウォール ルールを作成する gcloud コマンドは以下のとおりです。
gcloud compute firewall-rules create secure-billing-data \--network web-network \--allow TCP:443 \--source-service-accounts billing-frontend@web.iam.gserviceaccount.com \--target-service-accounts billing-data@web.iam.gserviceaccount.com
上の例で、課金フロントエンドと課金データの両アプリケーションが自動スケーリングされる場合は、VM 作成用のインスタンス テンプレートでそれぞれのアプリケーションにサービス アカウントを指定できます。
この方法の利点は、ファイアウォール ルールをいったん設定してしまえば、IAM パーミッションを変更してもルールを変える必要がないことです。ただし、現時点では VM に関連づけられるサービス アカウントは 1 つだけであり、サービス アカウントを変更する際はインスタンスを停止状態にする必要があります。
InstanceAdmin のためのカスタム IAM ロールの作成
タグの柔軟性やサービス アカウントの制限が気になるのであれば、VM にタグを設定できないように権限を縮小したカスタム ロールを作るという方法もあります。具体的には、compute.instances.setTag パーミッションを取り除くのです。このカスタム ロールは、InstanceAdmin ロールが持つその他の権限を備え、社内の開発者に安心して与えることが可能です。このカスタム ロールを使用すれば、タグを使ってファイアウォール ルールを作成できます。
gcloud compute firewall-rules create secure-billing-data \--network web-network \--allow TCP:443 \--source-tags billing-frontend \--target-tags billing-data
ただし、カスタム ロールに与えた権限はその性質上静的であり、InstanceAdmin ロールに新しい権限が追加されたときなどは手作業で更新する必要があります。
サブネットワークを使ったワークロードの分割
次の図のように、ワークロードを異なる範囲のサブネットワークに分割できる場合は、送信元および宛先 IP アドレスの CIDR レンジをファイアウォール ルールで指定することも可能です。
特定のサブネットワークに compute.networkUser ロールを付与する開発者を絞り込んだり、共有 VPC を使ったりすれば、これらのサブネットワーク内で VM を作成する権限を制限できます。
送信元および宛先 IP レンジを gcloud コマンドでファイアウォール ルールに指定する方法は以下のとおりです。
gcloud compute firewall-rules create secure-billing-data \--network web-network \--allow TCP:443 \--source-ranges 10.20.0.0/16 \--destination-ranges 10.30.0.0/16
この方法なら、大規模な VPC でスケーラビリティが向上し、ネットワーク トポロジーを変えないかぎり管理下の VM の変更が可能になります。ただし、VM インスタンスが can_ip_forward を有効にしていると、上の送信元 IP レンジを使ってトラフィックを送れるため、機密性の高いワークロードにアクセスできてしまいます。
以上のように、VPC のファイアウォール ルールを設定するときには、考慮すべき点がたくさんあります。よりセキュアで効率的なファイアウォール ルールを設定するうえで、本稿の内容がお役に立てば幸いです。ファイアウォール ルールの詳細な設定方法はこちらのドキュメントを参照してください。
* この投稿は米国時間 1 月 12 日、Staff Software Engineer である Neha Pattan によって投稿されたもの（投稿はこちら）の抄訳です。
- By Neha Pattan, Staff Software Engineer
