この記事は、Supershipグループ Advent Calendar 2024の 8日目の記事になります。
私は普段、CCoEとして当社で利用するAWSやGCPといったパブリッククラウドの統制・運用を主な業務としています。
CCoEの活動については過去のAdvent Calendarでも触れられていますので、是非御覧ください。
この記事の内容
各サービスの詳細な説明は割愛しているため、以下に当てはまる方を想定読者としています。
- AWSやGoogle Cloudのサービスについてある程度理解がある方
- マルチアカウント管理についてある程度理解がある方
はじめに
タイトルが Google Cloud についてですが、まず AWS Config について触れさせてください。
AWS Config には Config ルールという機能があります。この機能はリソースが指定したルールに遵守しているか自動でチェックを行い、検出を行います。
また、修復アクションという設定を活用し、検出したリソースを指定したルールに遵守するよう自動で設定変更を行ってくれます。
例えば「VPCセキュリティグループで 0.0.0.0/0 に対して 22/tcp を許可するルールを禁止する。違反している場合は該当ルールを削除する。」といったルールを適用します。適用されたアカウントではSSHを全開放するセキュリティグループのルールは自動で削除され、セキュリティ的なリスクを抑制することができます。
過去のAdvent CalendarでAWS Configルールについて触れていますので、もし興味があれば御覧ください。
この Configルール + 自動修復の機能を Google Cloud 上で実現してみたのが今回の主題となります。
背景
Google Cloudでプロジェクトを作成すると、VPCではデフォルトネットワークが作成されます。(VPC ネットワーク - デフォルトのネットワーク)
デフォルトネットワークに対するファイアウォールルールもデフォルトで作成されます。(デフォルト ネットワークの事前設定ルール
)
このデフォルトで作成されるルールに問題があります。以下は作成されるルールの一部抜粋です。
| ルール名 | 方向 | 優先度 | ソース範囲 | アクション | プロトコルとポート | 説明 |
|---|---|---|---|---|---|---|
| default-allow-ssh | ingress | 65534 | 0.0.0.0/0 | allow | tcp:22 | ssh、scp、sftp などのツールを使用してインスタンスに接続することを許可します。 |
| default-allow-rdp | ingress | 65534 | 0.0.0.0/0 | allow | tcp:3389 | Microsoft リモート デスクトップ プロトコル（RDP）を使用してインスタンスに接続することを許可します。 |
このように、SSHやRDPなどセキュリティリスクの高いポートへの外部からのアクセスを許可しています。
一般的にSSHなどのポートは特定IPからのアクセスに制限することが望ましいです。
実際のプロダクトの利用ではデフォルトのネットワークを利用するケースは基本的にはないと思いますが、これらのルールを理解せずデフォルトVPCネットワークでインスタンスを起動してしまっているケースなど可能性はあります。
Google Cloudのドキュメントでも、本番環境の運用にはデフォルトのVPCネットワークではなく、カスタムモードのVPCネットワークの利用をベストプラクティスとして推奨しています。
カスタムモードの VPC ネットワークを使用する
以上から、デフォルトファイアウォールルールに関してはガードレールとして統制をかけるべきだと判断しました。
なお、組織ポリシーを使用することで、デフォルトで作成されるVPCネットワークを制限する（作成させない）ことも可能です。(組織ポリシーの制約)
しかし、これらは既存のプロジェクトに存在するデフォルトのVPCネットワークには何も制限を課すことはできません。今回は既存のデフォルトファイアウォールルールを対象とするため組織ポリシーについては触れません。（今後検討はしたい。）
対応
ここでは実際に行った対応について記載していきます。
Google Cloudのファイアウォールルールは無効化することができます。
したがって、今回対象とするデフォルトファイアウォールルールは無効化することとしました。
要件は以下としました。
- 既存のプロジェクトのファイアウォールルールを定期的にチェックし、デフォルトファイアウォールルールが有効であれば無効化する
- 無効化したデフォルトファイアウォールルールを有効化された場合は、自動で無効化する
これらを実現できる方法を検討したところ、 Cloud Asset Inventory というサービスを活用することにしました。
このサービスの利用方法について以下に記します。
Cloud Asset Inventory
Google Cloud には Cloud Asset Inventory というアセット管理サービスがあります。
Cloud Asset Inventory は各種リソースの設定情報を集約・検索することができます。
また、モニタリングの設定も可能で設定することで Pub/Subなどのサービスと連携することが可能です。
1つ目の要件である既存のプロジェクトのファイアウォールルールを定期的にチェックし、デフォルトファイアウォールルールが有効であれば無効化するについては、Cloud Asset Inventoryの検索機能を利用します。
Cloud Asset Inventoryのモニタリングの機能は変更を検知した場合に動作する、とあります。（Monitor asset changes with Pub/Sub）
したがって、既存のプロジェクトでは既にデフォルトファイアウォールルールは有効となっており、利用者が当該ルールに対して操作を行わない限り、モニタリングが動作することはありません。
また、新規でプロジェクトを作成した場合も同様にデフォルトファイアウォールルールが作成されますが、この作成のタイミングで Cloud Asset Inventoryのモニタリングは動作しない可能性があります。
（動作するかもしれませんが、こちらは検証できていません。）
以上から、1つ目の要件をファイアウォールルールの定期的なチェックとしました。
構成図としては以下のようなイメージになります。
2つ目の要件である無効化したデフォルトファイアウォールルールを有効化された場合は、自動で無効化する は Cloud Asset Inventory のモニタリングの機能を活用します。
利用者がファイアウォールルールの操作権限を所持している場合、手動でデフォルトファイアウォールルールを有効化することは可能です。
このように有効化された場合に自動的に無効化する仕組みは必要だと考え、モニタリングの機能も活用することとしました。
構成図としては以下のようなイメージになります。
どちらも基本的には Cloud Asset Inventory を使用し、Pub/Sub と Cloud Functions（Cloud Run functions）を連携する構成となっています。
この2つの仕組みを組みわせて導入することでデフォルトのファイアウォールルールの統制を実現しました。
おわりに
この仕組みを導入することで 組織的に Google Cloudのセキュリティの向上に繋げることができました。
Supershipではプロダクト開発やサービス開発に関わる人を絶賛募集しております。
ご興味がある方は以下リンクよりご確認ください。
Supership 採用サイト