セキュリティパッチ

このドキュメントでは、Google が Google Kubernetes Engine（GKE）と GKE Enterprise のセキュリティ脆弱性とパッチをどのように管理しているかについて説明します。特に記載のない限り、GKE Enterprise には GKE プラットフォームと GKE Enterprise プラットフォームの両方が含まれています。

このページは、サポートからエスカレーションされたインシデントや問題など、戦略的な支援が必要なセキュリティの問題や脆弱性の解決をサポートするセキュリティスペシャリストを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

パッチ適用に関する共有責任

パッチ適用については、Google とお客様の間の共同責任になります。共同責任は、プラットフォームによって異なります。詳細については、各プラットフォームに関する次のトピックをご覧ください。

脆弱性の検出方法

Google は、プロアクティブなセキュリティ設計や強化に莫大な投資を行ってきましたが、設計済みのソフトウェアシステムに脆弱性が存在することもあります。Google では、こうした脆弱性を悪用される前に見つけてパッチ適用を行うために、複数のフロントエンドに多額の投資を行ってきました。

パッチ適用の目的のため、GKE Enterprise がオペレーティングシステム（OS）レイヤとして機能し、そのうえでコンテナが実行されます。オペレーティングシステム（Container-Optimized OS または Ubuntu）はセキュリティが強化され、コンテナの実行に必要な最小限のソフトウェアが含まれています。GKE Enterprise の機能はベースイメージ上でコンテナとして実行されます。

Google は、脆弱性と欠落しているパッチを次の方法で特定し、修正します。

Container-Optimized OS: Google はイメージをスキャンして脆弱性やパッチ欠落の問題を特定します。Container-Optimized OS チームが問題を確認して解決します。
Ubuntu: 使用可能なすべてのセキュリティパッチを適用済みの OS ビルドが Canonical から Google に提供されます。

Google は Container Registry Artifact Analysis を使用してコンテナをスキャンし、Kubernetes コンテナと Google マネージドコンテナの脆弱性とパッチの欠落を検出します。修正が可能な場合、スキャナはパッチ適用とリリースプロセスを自動的に開始します。

自動スキャンに加えて、Google では次の方法でスキャナが認識できない脆弱性を特定し、パッチを適用します。

Google は、すべての GKE Enterprise プラットフォームで独自の監査、ペネトレーションテスト、脆弱性検出を行います。Google 内部の専門チームと信頼できるサードパーティセキュリティベンダーがそれぞれ独自に攻撃を調査しています。また、Google は CNCF と協力し、Kubernetes セキュリティ監査について組織的また技術的なコンサルティング情報を数多く提供しています。

Google は、複数の脆弱性報奨プログラムを通じて、セキュリティ研究コミュニティと積極的に連携しています。専用の Google Cloud 脆弱性報奨金プログラムでは、毎年発見される最も優れたクラウドの脆弱性に対して支払う $133,337 をはじめ、多額の報奨金を用意しています。GKE の場合、Google のセキュリティ管理を破ることができたセキュリティ研究者に報酬を支払うプログラムがあります。このプログラムは、GKE ソフトウェアのすべての依存関係に対応しています。

Google では、脆弱性を一般公開する前に、脆弱性、セキュリティ研究、パッチを共有する他の業界やオープンソースソフトウェアパートナーと提携します。この連携の目的は、この脆弱性を一般に発表する前に、多数のインターネットインフラストラクチャにパッチを適用することです。場合によっては、Google が検出された脆弱性をこのコミュニティに提供する場合もあります。たとえば、Google の Project Zero で Spectre と Meltdown の脆弱性が発見され、公開されました。また、Google Cloud セキュリティチームは、カーネルベースの仮想マシン（KVM）の脆弱性を定期的に検出して修正します。

Google のセキュリティコラボレーションは、さまざまなレベルで行われます。これは、組織がプロダクト（Kubernetes、Envoy など）のソフトウェアの脆弱性に関するリリース前の通知を受け取るために登録するプログラムを通じて、正式に行われることもあります。また、Linux カーネル、コンテナランタイム、仮想化テクノロジーなどの多くのオープンソースプロジェクトとの連携により、コラボレーションが非公式に行われることもあります。

Kubernetes の場合、Google は Security Response Committee（SRC）で積極的に活動している創設メンバーであり、セキュリティリリースプロセスの大部分を執筆しています。Google は、脆弱性に関する事前の通知を受け取り、Kubernetes の重大なセキュリティの脆弱性に関するほぼすべてのトリアージ、パッチ適用、緩和策、コミュニケーションに関与している、Kubernetes Distributors List のメンバーです。また、Google 自体も、Kubernetes の脆弱性を複数検出してきました。

それほど深刻ではない脆弱性が発見された場合には、これらのプロセス外でパッチが適用されますが、重大度が最も高いセキュリティ脆弱性については、これまでに挙げたチャネルのいずれかを通して非公開で報告されます。早期に報告することによって、脆弱性が公表される前に、Google で GKE Enterprise に与える影響を調査してパッチや緩和策を開発し、お客様へのアドバイスやお知らせを準備する時間を確保できます。Google では、脆弱性が公開される前にすべてのクラスタにパッチを適用します。

脆弱性の分類方法

GKE では、適切なデフォルト、セキュリティで強化された構成、マネージドコンポーネントに加えて、OS、コンテナ、Kubernetes、ネットワークレイヤなど、スタック全体の強化に多大な投資を行っています。これらを組み合わせることで、脆弱性の影響と可能性を軽減できます。

GKE Enterprise セキュリティチームは、Kubernetes の脆弱性スコアシステムに従って脆弱性を分類しています。分類では、GKE と GKE Enterprise の構成やセキュリティ強化など、さまざまな要素が考慮されます。これらの要因と GKE のセキュリティ強化のため、GKE と GKE Enterprise の脆弱性の分類は他の分類ソースと異なる場合があります。

次の表は、脆弱性の重大度カテゴリを示しています。

重大度	説明
重大	認証されていないリモートの攻撃者によってすべてのクラスタで簡単に悪用され、システム全体のセキュリティが侵害されることにつながる脆弱性。
高	多くのクラスタで簡単に悪用される可能性があり、機密性、完全性、可用性の損失につながる脆弱性。
中	脆弱性、整合性、または可用性の損失が、一般的な構成、悪用の難易度（必要なアクセス権やユーザーの操作など）で制限されていて、一部のクラスタで悪用される可能性がある脆弱性。
低	その他のすべての脆弱性。悪用や攻撃が繰り返される可能性はほとんどありません。

脆弱性、修正、緩和策とそれらの評価については、セキュリティに関する情報をご覧ください。

脆弱性に対するパッチの適用方法

脆弱性にパッチを適用するには、新しい GKE または GKE Enterprise のバージョン番号にアップグレードする必要があります。GKE と GKE Enterprise のバージョンには、オペレーティングシステム用のバージョニングされたコンポーネント、Kubernetes コンポーネント、GKE Enterprise プラットフォームを構成するその他のコンテナなどが含まれます。脆弱性の修正には、Google によって GKE 上で自動的に実行され、コントロールプレーンのアップグレードのみを必要とするものと、コントロールプレーンとノードのどちらもアップグレードする必要があるものがあります。

クラスタにパッチを適用し、あらゆる重大度の脆弱性に対して強化するために、GKE のノード自動アップグレード（デフォルトで有効）を使用することをおすすめします。リリースチャンネルに登録されているクラスタの場合、パッチリリースは各チャンネルの資格要件を満たすため、プロモートされています。クラスタのチャンネルに到達する前に GKE パッチリリースが必要な場合、パッチリリースがクラスタのリリースチャンネルで利用可能なマイナーバージョンと同じであれば、パッチバージョンに手動でアップグレードできます。

他の GKE Enterprise プラットフォームでは、少なくとも月に 1 回 GKE Enterprise コンポーネントをアップグレードすることをおすすめします。

一部のセキュリティスキャナや手動バージョンチェックでは、runc や containerd などのコンポーネントに特定のアップストリームセキュリティパッチが欠落していると誤って想定されることがあります。GKE はコンポーネントに定期的にパッチを適用し、必要に応じてパッケージバージョンのアップグレードのみを行います。つまり、GKE コンポーネントのバージョン番号がアップストリームのバージョン番号と一致しない場合でも、GKE コンポーネントは機能的にアップストリームコンポーネントと類似しています。特定の CVE の詳細については、GKE のセキュリティに関する公開情報をご覧ください。

パッチ適用のタイムライン

Google の目標は、存在するリスクに適した期間内に、検出された脆弱性を緩和することです。GKE は Google Cloud の FedRAMP Provisioningal ATO に含まれています。ここでは、FedRAMP 継続的モニタリング戦略ガイドの「継続的モニタリングアクティビティと成果物に関する概要」の表のコントロール RA-5（d）で指定されている重大度レベルに従って、特定の期間内に既知の脆弱性を修復する必要があります。Google Cloud の FedRAMP Provisioningal ATO には Google Distributed Cloud と GKE on AWS は含まれていませんが、これらのプロダクトでも同じ修復期間を目標としています。

脆弱性とパッチの通知方法

脆弱性とセキュリティパッチに関する最新情報の最適なソースは、次のプロダクトのセキュリティに関する情報フィードにあります。

GKE
Google Distributed Cloud
GKE on AWS
GKE on Azure
Google Distributed Cloud

これらの情報は、共通の Google Cloud 脆弱性番号スキームに従っており、Google Cloud 情報のメインページと GKE リリースノートからリンクされています。各セキュリティ情報ページに RSS フィードがあり、ユーザーは登録すると、更新情報を受け取ることができます。

脆弱性は限られた期間中、情報制限付きの非公開の状態になることがあります。情報制限を行うと、脆弱性が早期に公開されることにより、対処の手順を実施する前に悪用を試みる行為が広く行われるのを防ぐことができます。情報制限が実施されている状況では、情報制限が解除されるまでの間、リリースノートに「セキュリティに関する更新情報」だけが表示されます。制限が解除されると、Google はリリースノートを更新し、脆弱性に関する具体的な情報を提供します。

GKE Enterprise セキュリティチームは、重大度が「高」や「重大」の脆弱性のセキュリティに関する公開情報を公表しています。このような重大度が「高」や「重大」の脆弱性に対処するためにお客様の対応が必要な場合は、Google からメールでご連絡いたします。また、Google はサポートチャネルを通じてサポート契約を結んでいるお客様にご連絡する場合もあります。

セキュリティ パッチ