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

By 清水 孝郎 - FEBRUARY 20, 2022
Topics: クラウド セキュリティ, コンテナ、Kubernetes、ホストのセキュリティ

SHARE:

本文の内容は、2022年2月21日現在における、Sysdig Cloud Native Learning Hub上のGCP Cloud & Container Security Best Practices(https://sysdig.com/learn-cloud-native/cloud-security/gcp-security/) を元に日本語に翻訳・再構成した内容となっております。

どんなクラウドでもセキュリティを確保するのは大変です。ある意味では、Google Cloud Platform（GCP）のセキュリティ確保は特に難しいと言えます。

それは、GCP自体に欠陥があるからではありません。GCPは、何百万ものワークロードに対応する、定評のある堅牢で信頼性の高いクラウドプラットフォームです。むしろ、GCPが「ビッグ3」と呼ばれるパブリッククラウドプラットフォームの中で最も新しいという事実が、セキュリティの確保を難しくしています。GCP専用に設計されたセキュリティツールは少なく、GCPのセキュリティベストプラクティスに関するアドバイスも少ないのが現状です。

また、GCPは、AzureやAWSなどのクラウドとは技術的に異なる点があります。例えば、GCPはKubernetesに大きく依存しており、マネージド・コンテナ・サービス（Google Kubernetes Engine）に加えて、ハイブリッド・クラウド管理フレームワーク（Anthos）の基盤として使用していることが大きな違いとなっています。

以上のことを踏まえて、この記事では、GCPのクラウドセキュリティについて知っておくべきことを説明します。ここでは、Google Cloudにおける共有責任、Googleがクラウドワークロードに提供するネイティブなセキュリティコントロール、Google Cloudでホストされているアプリケーションとデータを保護するためのベストプラクティスについて説明します。

GCPの責任共有モデル

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

具体的なセキュリティ責任の取り決めは、クラウドのサービスや構成によって異なりますが、詳細をお知りになりたい場合は、Googleが87ページの文書ですべてを説明しています。一般的に、GCPでの責任分担は以下のようにまとめられます。

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


GCPのセキュリティとコンプライアンスの課題

繰り返しになりますが、GCPは他の主要なパブリッククラウドと同様に安全です。しかし、GCP上のワークロードのセキュリティを確保することが特に困難な場合があることは、注目に値します。

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

1つの課題は、先に述べたように、GCPはAzureやAWSに比べてほとんどの点で歴史の浅いクラウドであるということです。また、歴史的に見ても、GCPの市場シェアは低くなっています。これらの要因は、クラウド・エコシステム全体が、他のクラウドほどGCPに対応していないことを意味しています。最近のクラウド・ネイティブなセキュリティ・プラットフォームの多くはGCPを完全にサポートしていますが、AWSやAzureにしか対応していないものもあります。また、IAM（Identity and Access Management）フレームワークなど、GCPのネイティブ・セキュリティ・ツールの使用経験は、AWSやAzure上の同等のサービスの使用経験に比べて少ないエンジニアが多いようです。

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

GCPはまた、AWSやAzureよりもマルチクラウドやハイブリッドクラウドのユースケースに注力していることは間違いありません。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 Admin


さらに、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とアンマネージドなKubernetesのセキュリティを理解する：GKEを介してGCP上のマネージドサービスとしてKubernetesを稼働させることができる一方で、自分のインフラ上にKubernetesを自分でセットアップすることもできるということに注意することが重要です。後者の場合、Kubernetesのセキュリティ責任はすべてあなたにあります。つまり、GCP内のさまざまなタイプのKubernetesデプロイメントモデルにおけるセキュリティ責任のニュアンスを学ぶことができます。

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

GCPセキュリティにおいてKubernetesセキュリティが中心的な役割を果たしていることについて多くを語ってきました。しかし、Google Cloud上で動作するKubernetesやコンテナを実際にどのようにセキュリティするのでしょうか？

その質問に対する完全な答えはこの記事の範囲を超えていますが、従うべき基本的なベストプラクティスは以下の通りです。

  • コンテナイメージを保護する：Google Cloudは、マルウェアや脆弱性を見つけるためにコンテナイメージを自動的にスキャンすることはありません。GKEやGCPでホストされている他のコンテナベースの環境にイメージをデプロイする前に、自分でスキャンを行う必要があります。
  • Kubernetesのセキュリティ監査を利用する：Kubernetesのセキュリティ監査は、クラスター内で起きていることを監視し、潜在的な悪用を早期に発見するための強力な機能です。セキュリティ監査を有効にして、疑わしい動作パターンを検出できるツールで監査イベントを分析するようにしてください。
  • コンテナ環境の監査：Kubernetesのセキュリティ監査では、Kubernetes APIへのリクエストのみを監視します。また、外部ツールを使用して、古いソフトウェアバージョン、安全でないアクセス制御構成、脆弱なランタイムバージョンなどをチェックして、コンテナソフトウェアスタック構成全体を監査する必要があります。
  • コンテナのパーミッションを制限する：Kubernetes Security Contextsなどのツールを使用して、コンテナがアクセスできるリソースを制限し、コンテナ同士を隔離します。

基本的なことから始める

GCPのセキュリティは複雑なテーマですが、比較的基本的なものに分解することができます。まず、あらゆる種類のクラウド環境で実施されている、セキュリティとコンプライアンスのベストプラクティスに従うことから始まります。その上で、Kubernetesを中心としていることや、マルチクラウドやハイブリッドクラウドのアーキテクチャの一部となる傾向があることなど、GCPの特徴に対応したセキュリティ管理を実施する必要があります。