クラウドネイティブを学ぼう！

Google Cloud(GCP)とコンテナのセキュリティ・ベストプラクティス

SHARE:

クラウド環境におけるセキュリティの確保は非常に困難です。中でも、Google Cloud Platform（GCP）におけるセキュリティ確保には特有の難しさがあります。

これは、GCPに欠陥があるという意味ではありません。GCPは、数百万のワークロードを支える信頼性の高い、堅牢で実績あるクラウドプラットフォームです。むしろ、GCPは「ビッグ3」と称される主要なパブリッククラウドの中で最も新しいサービスであり、そのことがセキュリティ対策を複雑にしているのです。

GCPに特化したセキュリティツールは他と比べて少なく、セキュリティベストプラクティスに関する情報も限定的です。また、GCPはAzureやAWSといった他のクラウドプラットフォームとは、技術的にいくつかの重要な点で異なります。特に大きな違いの一つとして、GCPがKubernetesに強く依存している点が挙げられます。GCPは、マネージドコンテナサービスであるGoogle Kubernetes Engine（GKE）や、ハイブリッドクラウド管理フレームワークであるAnthosの基盤としてKubernetesを採用しています。

こうした背景を踏まえ、本記事ではGCPにおけるクラウドセキュリティの要点を解説します。具体的には、Google Cloudにおける「共有責任モデル」、Googleが提供するクラウドネイティブなセキュリティコントロール、そしてGCP上でホストされるアプリケーションやデータを保護するためのベストプラクティスについてご紹介します。

GCP 責任共有モデル

他の主要なパブリッククラウドと同様、GCP は責任共有モデルを採用しています。このモデルでは、セキュリティに関する責任の一部はお客様、一部は Google Cloud が負います。その他の責任は両者が分担します。

セキュリティに関する責任の正確な分担は、クラウドサービスや構成によって異なります。詳細については、Google が提供するドキュメントをご覧ください。一般的に、GCP における責任分担は次のようにまとめられます。

  • Google は、物理ネットワーク、サーバー、ストレージメディアを含む物理インフラストラクチャのセキュリティを確保します。ただし、ハイブリッドクラウドアーキテクチャを介して GCP に接続されているオンプレミスインフラストラクチャは例外です。
  • お客様は、Google Cloud にデプロイするワークロードのセキュリティを確保します。これには、お客様がクラウド VM にインストールするオペレーティングシステム、設定する仮想ネットワーク構成、GKE を通じてデプロイするコンテナ、GCP Cloud Storage にアップロードするデータなどのリソースが含まれます。
  • GCP マネージドサービスの場合、Google はお客様とセキュリティ責任を共有します。たとえば、GCP マネージド Kubernetes サービスである GKE を使用する場合、Google はクラスターを実行するために必要なインフラストラクチャ コンポーネントのセキュリティを確保し、お客様は Kubernetes コンポーネント（API など）の大部分と、GKE を通じてデプロイするアプリケーションのセキュリティを確保します。

GCP のセキュリティおよびコンプライアンスに関する課題

繰り返しになりますが、GCP は他の主要なパブリッククラウドと同様、セキュリティも同様に安全です。ただし、GCP でのワークロードのセキュリティ確保が特に難しい点については、注意が必要です。

より小規模なクラウドエコシステム

課題のひとつは、前述のように、GCP はほとんどの点で Azure や AWS よりも歴史が浅いクラウドであることです。また、これまで市場シェアも低かったため、クラウドエコシステム全体としては、GCP よりも他のクラウドへの対応が進んでいます。これらの要因により、クラウドエコシステム全体として、GCPに対して他のクラウドほど対応が十分ではありません。多くの現代的なクラウドネイティブセキュリティプラットフォームはGCPを完全にサポートしていますが、他のプラットフォームはAWSとAzureのみに対応しています。さらに、多くのエンジニアは、GCPのネイティブセキュリティツール（例えば、アイデンティティとアクセス管理（IAM）フレームワーク）の使用経験が、AWSやAzure上で動作する同等のサービスに比べて少ない可能性があります。

マルチクラウドおよびハイブリッドクラウドへの投資

また、GCP は、市場での優位性により外部環境との互換性がそれほど重要ではない AWS や Azure よりも、マルチクラウドおよびハイブリッドクラウドのユースケースに重点を置いているといえるでしょう（ただし、AWS と Azure もハイブリッドおよびマルチクラウドの統合機能を提供しています）。

この傾向は、たとえば、GCP が、ほぼすべてのタイプのオンプレミスインフラストラクチャで動作するハイブリッドクラウドフレームワーク「Anthos」を、大手パブリッククラウドとして初めて提供した事実からも明らかです。Azure および AWS の同等の製品である Azure Stack および AWS Outposts は、ほとんどの点で Anthos よりも制限が厳しくなっています。

セキュリティの観点からは、GCP はハイブリッドおよびマルチクラウドに重点を置いているため、GCP ユーザーは GCP ワークロードを外部環境と統合する可能性が高くなります。そのため、GCP のネイティブセキュリティツール（通常、サードパーティの環境をサポートしていません）のみに依存してワークロードのセキュリティを確保することは困難です。また、GCP を外部リソースに接続するネットワークインフラストラクチャや API のセキュリティ確保に関連する課題も増えます。

これらの課題はすべて解決可能ですが、Google Cloud にとって最も効果的なセキュリティ戦略を計画するには、GCP セキュリティの特別な要件を認識することが重要です。

GCP クラウドのセキュリティ・ベストプラクティス

一般的に、Google Cloud のセキュリティリスクの管理は、他のクラウドのセキュリティ確保と同じアプローチに基づいています。

  • GCP IAM を使用する：IAM は、クラウドのワークロードを保護するための最も強力なツールの 1 つです。Google Cloud の IAM フレームワークを最大限に活用して、GCP 環境内で最小権限を実施してください。たとえば、次のような GCP IAM ポリシー（YAML で定義）は、カスタムロールにストレージ バケットの一覧表示と表示の権限を付与します。
description: My custom role description.
etag: BwVkBkbfr70=
includedPermissions:
- iam.roles.get
- iam.roles.list
- storage.buckets.get
- storage.buckets.list
name: projects/my-project-id/roles/myCompanyAdmin
stage: ALPHA
title: My Company AdminCode language: PHP (php)

さらに、IAM ポリシーを監査して、セキュリティ侵害につながる可能性のある設定ミスを検出してください。

  • クラウドネットワークを分離します：GCP Virtual Private Cloud などのリソースを使用して、関連のないワークロードを独自のプライベートネットワークに分離し、セキュリティ問題がワークロード間で波及するリスクを軽減します。
  • ラベルとタグを使用する：GCP では、ラベルとタグを使用してワークロードを整理することができます。ラベルやタグを付けないことは、それ自体がセキュリティリスクになるわけではありませんが、適切に整理されていないリソースは、その存在を忘れてしまったり、監査の対象から除外してしまったりする可能性が高いため、侵害される可能性が高くなります。
  • 機密データを分離する：GCP 環境内で、機密データ（個人を特定できる情報を含むデータなど）がどこにあるかを把握しておいてください。Google Cloud DLP を使用して、見落としがちな場所に存在する機密データを検出することを検討してください。
  • マネージドサービスの責任を理解する：マネージドサービスの場合、クラウドプロバイダーがセキュリティにおいてどの程度の役割を果たすかについて、誤った仮定を立てやすい傾向があります。これは、このテーマが複雑で、ベンダーの責任がサービスごとに異なるためです。使用する各マネージドサービスの固有の側面を確実に理解してください。

これらの対策に加えて、Google Cloud の特別なセキュリティ課題に対処するために、追加の対策を取ることをお勧めします。以下の戦略をご検討ください。

  • 外部セキュリティ監視および監査ツールを使用する：GCP には、クラウドリソースのセキュリティ確保に役立つSecurity Command Center などのツールがいくつか用意されていますが、前述のように、これらのツールの主な制限は、GCP 内で実行されているワークロードにしか機能しないことです。ハイブリッド環境やマルチクラウド環境を運用している場合、あるいは GCP のネイティブツールよりも高度なセキュリティ監視、分析、アラート機能が必要な場合は、複数のクラウド環境およびオンプレミス環境に対応できるサードパーティのセキュリティプラットフォームの利用をご検討ください。
  • Kubernetes セキュリティへの投資：GCP は、一部の主要サービスの基盤として Kubernetes に特に大きく依存しているため、Kubernetes セキュリティを習得することは、GCP ユーザー、特に Anthos などの Kubernetes ベースのフレームワークを使用しているユーザーにとって特に重要です。
  • マネージドと非マネージドの Kubernetes セキュリティを理解する：GCP では GKE 経由で Kubernetes をマネージドサービスとして実行できますが、自社インフラストラクチャ上で Kubernetes を自分で設定することも可能です。後者の場合、すべての Kubernetes セキュリティの責任はユーザーに帰属します。つまり、GCP 内の異なる Kubernetes デプロイメントモデルにおけるセキュリティ責任の微妙な違いを理解する必要があります。

GCP コンテナのセキュリティ・ベストプラクティス

これまで、GCPセキュリティにおけるKubernetesセキュリティの重要な役割について詳しく解説してきました。では、実際にGoogle Cloud上で稼働するKubernetesクラスターやコンテナを、どのようにしてセキュリティで保護すればよいのでしょうか。

この問いに対する包括的な答えを本記事の中で網羅することは困難なため、ここでは基本的なベストプラクティスをいくつかご紹介します。

  • コンテナイメージのセキュリティ保護：Google Cloudでは、コンテナイメージに対してマルウェアや脆弱性の自動スキャンは行われません。そのため、GKEや他のGCPホスト環境にイメージをデプロイする前に、ご自身で脆弱性スキャンを実施する必要があります。これにより、リスクの高いイメージが本番環境に展開されるのを防ぐことができます。
  • Kubernetes セキュリティ監査を使用する：Kubernetes セキュリティ監査は、クラスタ内で発生するイベントを記録し、潜在的な不正使用や異常なアクティビティを早期に発見するための有力な手段です。監査ログを有効化し、不審な動作を検知可能なツールでこれらのイベントを分析してください。
  • コンテナ環境の監査：Kubernetes セキュリティ監査は、Kubernetes API へのリクエストのみを監視します。また、外部ツールを使用して、古いソフトウェアバージョン、安全でないアクセス制御設定、脆弱なランタイムバージョンなどをチェックし、コンテナソフトウェアスタックの設定全体を監査する必要があります。
  • コンテナの権限を制限：Kubernetes セキュリティコンテキストなどのツールを使用して、コンテナがアクセスできるリソースを制限し、コンテナを互いに分離します。

基本から始めましょう

GCP のセキュリティは複雑なトピックですが、いくつかの比較的基本的な要素に分解することができます。まず、あらゆるタイプのクラウド環境で実施するセキュリティとコンプライアンスのベストプラクティスに従います。そこから、Kubernetes 中心のアーキテクチャや、マルチクラウドまたはハイブリッドクラウドアーキテクチャの一部となる傾向など、GCP の特別な特性に対応するセキュリティ制御も実装する必要があります。