--- title: "GCP セキュリティ強化チェックリスト | Snow Tree" url: "https://www.snow-tree.com/ja/gcp-security-hardening/" --- 安全な GCP インフラストラクチャ # 中小規模チーム向け GCP セキュリティ強化チェックリスト 専任のセキュリティ部門を持たずに Google Cloud で本番ワークロードを運用するチームのための、実践的なベースラインです。重大なインシデントにつながる可能性が最も高く、かつ最も減らしやすい経路から始めましょう。 ## このページの内容 1. [GCP でよくある脅威の経路](https://www.snow-tree.com/ja/#threat-paths) 2. [ID とアクセス](https://www.snow-tree.com/ja/#identity) 3. [ネットワークとエッジ](https://www.snow-tree.com/ja/#network) 4. [データとシークレット](https://www.snow-tree.com/ja/#data) 5. [GKE のセキュリティ強化](https://www.snow-tree.com/ja/#gke) 6. [検出と復旧](https://www.snow-tree.com/ja/#detection) 7. [優先順位付けされた 30 日、60 日、90 日のチェックリスト](https://www.snow-tree.com/ja/#checklist) 8. [公式リファレンス](https://www.snow-tree.com/ja/#references) ## GCP でよくある脅威の経路 クラウドのインシデントの多くは、責任の所在や構成の小さな抜けから始まります。攻撃者より先に、次の経路を確認してください。 - 権限が過剰なユーザー、サービス アカウント、ワークロード ID があると、盗まれた認証情報 1 つがプロジェクトをまたぐ広範なアクセスにつながるおそれがあります。 - 公開された管理エンドポイント、デバッグ ポート、許可範囲の広いファイアウォール ルールがあると、通常のアプリケーション トラフィック向けに設計されたあらゆる制御が回避されるおそれがあります。 - 公開ストレージ バケットや範囲が広すぎる署名付き URL は、アプリケーションが侵害された形跡がないまま顧客データを漏えいさせるおそれがあります。 - 古いイメージ、忘れられた Namespace、未使用のサービス アカウント、所有者のいないリソースがデプロイ可能なまま残っていると、放置されたワークロードが長期的なリスクになります。 - 監査証跡が欠けていたり保持期間が短かったりすると、誰がポリシーを変更したのか、いつアクセスが始まったのか、どのデータに到達されたのかを特定するのが難しくなります。 - テストしていないバックアップは希望的観測にすぎません。復元の失敗、不完全な保持、アクセスできない暗号鍵によって、セキュリティ イベントが恒久的な損失に変わるおそれがあります。 ## ID とアクセス ID を主要なコントロール プレーンとして扱います。すべての人、自動化プロセス、ワークロードに、目的を限定した個別の ID を持たせる必要があります。 ### リソースの境界を明確にする ガードレールには組織とフォルダを使用し、開発、ステージング、本番環境をプロジェクト単位、またはより強固な信頼境界で分離します。組織のポリシーは実用上可能な限り上位のレベルで適用し、サービスの使用を制限して、無関係なプロダクト間で本番プロジェクトを共有しないようにします。 ### 最小限のロールを最も狭い範囲で付与する 広範な基本ロールよりも事前定義ロールやカスタムロールを優先してグループやワークロード ID に付与し、リソース名やタグでアクセスを絞り込める場合は IAM 条件を使用します。未使用の権限を見直し、ブレークグラス（緊急時アクセス）プロセスでのみ必要な常設の本番アクセスを削除します。 ### 長期間有効な認証情報を削除する Workload Identity Federation for GKE を使用して、サービス アカウント キーをエクスポートせずに Pod が有効期間の短い認証情報を受け取れるようにします。可能な場合は組織のポリシーでキーの作成とアップロードをブロックし、残っているキーを棚卸しして、Cloud Audit Logs でリスクの高い IAM の変更を検知したらアラートを出します。 ## ネットワークとエッジ アプリケーションの欠陥にいずれネットワークから到達されることを前提とし、その欠陥からアクセスできる範囲を制限します。 ### すべて拒否から始め、明示した経路だけを追加する VPC ファイアウォール ルールは最小権限で構成し、Pod のトラフィックには Kubernetes NetworkPolicy を使用します。環境ごとにネットワークを分け、すべての上り（内向き）経路を文書化し、広いアドレス範囲から管理ポートや全プロトコルを許可する広範なデバッグ用ルールを削除します。 ### ノードとコントロール プレーンを非公開に保つ GKE ノードの外部 IP アドレスを無効にします。DNS ベースのプライベート コントロール プレーン エンドポイントを優先し、IP エンドポイントが避けられない場合は承認済みネットワークで制限します。ワークロードには、広範なインターネット アクセスではなく、意図して設計した下り（外向き）経路を用意します。 ### 意図した公開サービスだけを公開する アプリケーションは、偶発的な Pod やノードのアドレスではなく、レビュー済みのゲートウェイやロードバランサを通じて公開します。TLS はマネージド証明書で終端し、Ingress のホストとパスを制限し、リクエスト制限とレート制限を適用して、管理インターフェースは ID 認識型のアクセス制御の背後に置きます。 ## データとシークレット 保存中、転送中、使用中のデータを保護し、そのうえで復旧できることを実証します。データの検出も制御の一部です。 ### 意図しない公開アクセスを防ぐ Cloud Storage では公開アクセスの防止と均一なバケットレベルのアクセスを適用します。バケットを機密度で分類し、オブジェクトと鍵へのアクセスを制限し、価値の高いデータのロギングを有効にして、リスクモデルやコンプライアンス モデルで必要な場合は顧客管理の暗号鍵を使用します。 ### シークレットをイメージやソースコードに含めない 認証情報は Secret Manager に保存し、特定のワークロード ID と特定のシークレット バージョンに限定してアクセス権を付与します。シークレットは計画的にローテーションし、Git やコンテナ イメージにコピーせず、通常の Kubernetes Secrets を完全な保護境界とみなさないでください。 ### バックアップの作成だけでなく、復旧をテストする 目標復旧時点（RPO）と目標復旧時間（RTO）を定義し、本番環境の障害ドメインの外にコピーを保持し、バックアップと暗号鍵へのアクセスをワークロード ID から保護します。定期的に隔離環境へ復元してデータを検証し、所要時間と手動手順を記録します。 ## GKE のセキュリティ強化 GKE はマネージド コントロール プレーンを保護しますが、クラスタの構成、Namespace、アドミッション ポリシー、ワークロードの管理は引き続きお客様の責任です。 ### Namespace を分離の契約として扱う チームと環境を Namespace またはクラスタで分離し、そこに範囲を絞った Kubernetes RBAC ロールをバインドして、リソース割り当てと NetworkPolicy を適用します。アプリケーションのデリバリーにクラスタ全体への書き込みアクセスを使わず、個別の ID が必要なワークロードにはそれぞれ専用のサービス アカウントを割り当てます。 ### 信頼できるイメージと構成のみを許可する 制限付き（Restricted）の Pod Security 標準、または同等の Policy Controller ルールを適用します。イメージは不変のダイジェストでデプロイして脆弱性をスキャンし、来歴が重要な場合は Binary Authorization を使用して、想定外のホストアクセス、権限昇格、cluster-admin のバインディングを拒否します。 ### 不要なコンテナ権限を削除する 非 root ユーザーとして実行し、Linux ケーパビリティを削除し、可能な場合は読み取り専用のルート ファイルシステムを使用して、RuntimeDefault の seccomp プロファイルを適用します。必要がない限りサービス アカウント トークンをマウントせず、特権コンテナとホストの Namespace を避け、ノードのサービス アカウントの権限を最小限に保ち、Shielded Nodes と Container-Optimized OS を使用します。 ## 検出と復旧 制御は失敗するものです。誰もミスをしていないという思い込みではなく、証跡とリハーサル済みの対応に頼ってください。 ### 必要な証拠を収集する Cloud Audit Logs と GKE のシステムログおよびワークロード ログを、調査の要件に合った保持期間で一元的な保存先に保管します。機密データに対してはデータアクセス監査ログを選択的に有効にし、ログへのアクセスを制限して、IAM、ファイアウォール、ストレージ、クラスタ構成に対する管理上の変更を記録します。 ### セキュリティ上重要な変更をアラートで通知する ストレージの公開、広範なファイアウォールや IAM の変更、想定外のサービス アカウント キー、アドミッションによる拒否、コントロール プレーンの露出、認証の繰り返しの失敗、ロギングの無効化、バックアップの失敗、期限切れが迫った証明書についてアラートを出します。各アラートは、それを確認または却下する手順とともに担当者へ転送します。 ### 対応をリハーサルする 認証情報の漏えい、データの公開、ワークロードの侵害、リージョンやプロジェクトの喪失に備えた短いランブックを作成します。封じ込めを承認できる人、アクセスを取り消す方法、証拠を保全する方法、サービスを復旧する方法を盛り込みます。ランブックは、実際に使用する担当者と一緒にテストします。 ## 優先順位付けされた 30 日、60 日、90 日のチェックリスト ベースラインが整っていない状態から始める場合は、まずリスクへの露出を減らし、その後のレビューを繰り返し実施できるように作業の順序を決めます。 ### 1～30 日目: 明らかな経路を塞ぐ プロジェクトと所有者を棚卸しし、未使用の認証情報や長期間有効な認証情報を削除し、監査ロギングを確認し、公開バケットをブロックし、最も広範なファイアウォール ルールと IAM の付与を見直し、本番バックアップの不備を特定し、所有者のいない公開エンドポイントを修正します。すべての検出事項に担当者と期限を割り当てます。 ### 31～60 日目: ベースラインを繰り返し適用できるようにする ネットワーク、ID、ワークロードの構成を、レビューを経る Infrastructure as Code と GitOps によるデリバリーに移行します。Workload Identity、プライベート ノード、制限付きの Pod Security、信頼できるイメージのチェック、ログの一元化、最も重要な変更に対するアラートを導入します。 ### 61～90 日目: 実証し、維持する 復元テストとインシデントの机上演習を実施し、特権アクセスと例外の有効期限を見直し、イメージと依存関係を再度スキャンし、所有者がアラートを受け取れることを確認して、残っているギャップを測定します。証跡が古くなる前に、これらのチェックを定期的なレビュー サイクルに組み込みます。 このチェックリストを出発点としてご活用ください。Snow Tree は、マネージドプラットフォームの運用、または課題を絞ったコンサルティングを通じて、このベースラインを適用できます。 [マネージドプラットフォーム](https://www.snow-tree.com/ja/managed-platform/) [コンサルティング](https://www.snow-tree.com/ja/consulting/) ## 公式リファレンス プラットフォームのデフォルトや製品の機能が変更された場合は、Google の最新のガイダンスを信頼できる技術的情報源として使用してください。 - [Google Cloud: GKE クラスタのセキュリティ強化に関するベスト プラクティス](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster) - [Google Cloud: GKE セキュリティのベスト プラクティス](https://docs.cloud.google.com/docs/security/gke-security-bps) マネージドプラットフォーム ## ソフトウェアの構築、ホスティング、運用をSnow Treeにお任せください。 [プロジェクトを始める](mailto:support+snow-tree-platform-1-issue-@gitlab.snow-tree.com?subject=Snow%20Tree%20project)