メモリも暗号化が必要？ Google Cloud （GCP）によるソフトウェアサプライチェーンリスクの防止方法を徹底解説！

本記事は、2021年12月1日に開催された Google の公式イベント「セキュリティサミット」において、 Google Cloud カスタマーエンジニアの桃井啓行氏が講演された「メモリも暗号化してソフトウェアサプライチェーンのリスクを防ぐ方法について」のレポート記事となります。

今回は、ソフトウェアサプライチェーンに潜むリスクを解説し、このリスクを低減するために Google Cloud （GCP）ではどのような対策があるのか、をわかりやすくご説明します。 Google Cloud （GCP）の画面を使って、デモンストレーションも行っていますので、ぜひ最後までご覧ください。

なお、本記事内で使用している画像に関しては、セキュリティサミット「メモリも暗号化してソフトウェアサプライチェーンのリスクを防ぐ方法について」を出典元として参照しております。

それでは、早速内容を見ていきましょう。

ソフトウェアサプライチェーンに潜むリスク

ソフトウェアサプライチェーン攻撃の歴史

まずは、ソフトウェアサプライチェーン攻撃の歴史についてご紹介します。

以下は、代表的なサプライチェーンに対する攻撃とその被害を時系列で表したものです。

上図からわかる通り、ソフトウェアサプライチェーン攻撃は最近始まったものではありません。サプライチェーン攻撃に用いられる技術は、1984年の時点で既に発見されていました。 Unix の作成者の一人である Ken Thompson が、どのシステムにもログインできるようにコードを挿入し、それが技術的に可能であることを論文で発表したのです。ただし、これはあくまで研究の一環として行ったことであり、悪意のあるソフトウェアサプライチェーン攻撃ではありません。

そして、悪意を持ったソフトウェアサプライチェーン攻撃は2000年代後半から始まりました。2007年、ロシアのハッカーが Software Update を MEDoc から乗っ取り、悪意あるコードを配布しました。その結果、被害総額は100億米ドルにものぼり、甚大な経済的被害が発生したのです。

2007年以降もソフトウェアサプライチェーン攻撃は複数報告されており、2020年代に入ってからも様々な種類の攻撃が起きています。このように、ソフトウェアサプライチェーンの攻撃手法は多岐にわたり、場合によっては非常に大きな被害をもたらすリスクがある、という点を覚えておきましょう。

CI / CD プロセス

最近では、ソフトウェアサプライチェーンのセキュリティとして、 CI / CD プロセスにおけるセキュリティ対策の話をよく目にします。 Google からも Google 内でのコードレビュープロセスやソフトウェアサプライチェーン、インフラストラクチャのセキュリティについて、ホワイトペーパーを発表しています。

ソフトウェアサプライチェーンは、開発者がコードを書くところから、アプリケーションがランタイムにデプロイされ、エンドユーザーに提供されるまでの一連のプロセスです。では、このプロセスにおいて、どのような脅威が想定されるのでしょうか？

ソフトウェアサプライチェーンにおける脅威

以下は、ソフトウェアサプライチェーンの各箇所で想定される脅威を図で表したものです。

ご覧の通り、一連のプロセスの中に様々な脅威が潜んでいることがわかります。例えば、不正なコード挿入やソース管理システムの侵害、ビルドパイプラインの変更など、その内容は多岐にわたります。

このように、ソフトウェアサプライチェーンには多種多様なリスクがあり、これらを回避して安全性を担保するためには、各プロセスの構成や状況に応じたセキュリティ対策が重要になります。

ソフトウェアサプライチェーンの物理とインフラ

ここで、ソフトウェアサプライチェーンにおけるランタイムやソフトウェアの信頼性について考えてみましょう。

クラウドは高度に抽象化されたインフラサービスですが、一番下のレイヤーには当然ながらハードウェアが存在します。では、ハードウェアやファームウェア、 OS などを信頼できるものとして、受け入れても問題ないのでしょうか？

この点において、 Google では、コンポーネントの信頼が確認されない限り、使用しない方針となっています。ハードウェアや UEFI 、ブートローダーなどの必要最小限のバージョンは使用しており、これらを厳密に管理し、サーバーを起動する度に信頼性を確認しています。

Google Cloud （GCP）を利用すれば、これらの仕組みを使うことはできますが、どのように自社環境に適用すれば良いのか、悩んでしまう方も多いのではないでしょうか？

次章以降では、 Google Cloud （GCP）を活用したソフトウェアサプライチェーン攻撃に対するセキュリティ対策についてご説明します。

Google Cloud （GCP）によるサプライチェーンリスクの防止方法

Google Cloud （GCP）におけるセキュリティのコンセプトは「 Defense in Depth 」です。日本語では「階層型防御」や「多層防御」と呼ばれており、ある一点を強固にするのではなく、各レイヤーに応じた対策を行い、多角的な観点で脅威に備える、というものです。

ここからは、 Google Cloud （GCP）を活用して、信頼できるセキュリティ対策を行うためのポイントをご紹介します。結論としては「 Trusted Computing （信頼されたコンピューティング）」の環境を用意することが重要になりますが、この Trusted Computing は大きく分けて以下3つの要素に分解できます。

• 信頼された環境構築
• 信頼されたコード
• 信頼されたアクセス

それぞれの要素について、詳しく見ていきましょう。

信頼された環境構築

1つ目は信頼された環境構築です。身元のはっきりしている環境を使い、不正な変更がないように各層の信頼性を確認します。

Google では専用のハードウェアを用意しており、チップやサーバー、ストレージ、ネットワーク、データセンターなど、すべて既知の専用スタックを揃えているため、ハードウェアの調達に関連するリスクを大幅に低減することができます。

専用設計であるため、 Google のサーバーから不要なコンポーネントを排除しており、 Google Cloud （GCP）の利用者は、日常的にこの環境を利用可能な状態となっています。これにより、最も低レイヤー部分の攻撃対象が大幅に少なくなり、かつ、壊れてしまうものも少なくなるため、セキュリティと信頼性が向上し、消費電力を抑えることができます。

また、 Google Cloud （GCP）では Titan チップが信頼性の根拠となっています。 Titan チップとは、サーバーと周辺機器にインストールされて信頼の基盤となる、環境構築の信頼性を確認する専用チップです。

以下は、 Titan チップが信頼を積み上げていく確認プロセスを図で表したものです。 Titan チップは信頼の基盤となり、ホストの環境構築における各層の信頼の確認プロセスを順序立てて実行します。

ここまでは、 Google のホストの信頼性をご説明してきましたが、お客様の VM における各層の信頼性はどのようになっているのでしょうか？

下図の左側に VM 作成画面におけるセキュリティ設定のスクリーンショットがありますが、 Shielded VM という機能を利用することで、信頼確認プロセスが続き、 VM における各層の信頼性を確認できます。

また、お客様から「 Shielded VM は Google Kubernetes Engine （GKE）でも使えますか？」という質問をいただくケースが多いですが、 Google Kubernetes Engine （GKE） でも問題なく利用可能です。

Shielded GKE Nodes を利用すれば、信頼された環境構築の上でコンテナをデプロイできるため、この点もあわせて覚えておいてください。

信頼されたコード

2つ目は信頼されたコードです。お客様のソフトウェアデリバリープロセスで承認されたコードのみが、本番環境にデプロイされるようにします。

以下、 Google におけるコードの信頼性を確認するためのプロセスを図で表したものです。

Google では、安全なコーディングの認識やルール、ピアレビューなどから始まり、 Cloud Build で CI/CD プロセスの各段階を通してイメージに署名を行います。そして、 Google Container Registry でイメージをスキャンし、脆弱性を明確にした上で、 Binary Authorization を利用して、署名されたイメージのみをデプロイします。

この内容を Google Cloud （GCP）の各サービスで構成した場合、以下のようになります。

細かい説明をすると長くなりますので、今回は詳しい内容は割愛しますが、ポイントしては「 Google Cloud （GCP）という1つの世界の中で、信頼できるイメージだけを本番環境にデプロイするような構成を構築できる」という点です。このように、サプライチェーンリスクを低減する上で、 Google Cloud （GCP）はとても有効なサービスだと言えるでしょう。

信頼されたアクセス

3つ目は信頼されたアクセスです。承認されたアカウントのみが会社のデータにアクセスできるようにします。

Google では、デバイスやサーバー、サービス、ユーザー、コードなど、すべてに ID を付与しています。そして、 ID と状況の組み合わせが承認された場合のみ、アクセスを許可する仕組みとなっています。

また、人間的なアクセスは制限されており、ログ記録や監査も提供しているほか、仮に顧客データにアクセスがあった場合は、ログで内容を確認できるようになっています。さらに、データ保存と通信はデフォルトで暗号化されているため、高い信頼性を担保しながら、アクセスを管理することができます。

Google のデータ保護に関する取り組み

お客様から頻繁に問い合わせを受ける内容として「センシティブなデータの保護」が挙げられます。組織のプライバシーポリシーやコンプライアンス、法規制対応、守秘義務要件など、厳しい要件がありつつも、クラウドのメリットを享受したまま環境を構築したい、というニーズです。

ここまで、通信時や保存時にデータが暗号化されていることをご説明しましたが、処理中のセンシティブデータに関しては、どのようになっているのでしょうか？特定の要件があるシチュエーションにおいては、データがメモリ上で処理されている間も保護されている必要があるかもしれません。

Google は AMD とパートナーを組み、 SEV というチップを提供しています。 SEV は　 Secure Encrypted Virtualization　の略であり、メモリが処理しているデータを暗号化してくれるものです。

CPU の中の AES 暗号化エンジンが暗号キーを管理しますが、一つの暗号キーではなく、それぞれの VM は専用の暗号キーを利用し、ホストにも専用の暗号キーが適用されます。これにより、 Google を含めた他社が介入できない、セキュアな環境を構築することができるのです。

Confidential VM のデモンストレーション

最後に、先程ご紹介した Confidential VM のデモンストレーションを行います。

Compute Engine で Confidential VM を作成する

まずは、 Compute Engine で Confidential VM を作成する方法をご紹介します。

Google Cloud （GCP）のコンソール画面から「 Compute Engine 」を選択します。

次に「インスタンスを作成」のボタンをクリックして、インスタンスの作成画面に遷移します。

インスタンス作成画面に移ったら、その中にある「 Confidential VMs サービス」にチェックを入れます。

チェックを入れるとサービスに関する説明事項がポップアップで表示されるので、内容を確認して「有効にする」をクリックします。

次に、インスタンス作成画面の中の「セキュリティ」の項目を見ると、セキュアブートに関するチェックボックスがあるので、これにチェックを入れてセキュアブートをオンにします。

最後に、各項目の内容を確認の上、画面最下部の「作成」ボタンをクリックしてインスタンスを作成します。

以上で、メモリが暗号化された Confidential VM の作成が完了します。

実際にインスタンスのプロパティを見てみると、 Confidential VM が有効になっていることが確認できます。

ここまでご説明した通り、インスタンスの作成画面で2つチェックを入れるだけで Confidential VM を作成できます。とても簡単に操作できることをご理解いただけたのではないでしょうか？

Google Kubernetes Engine （GKE）で Confidential VM を作成する

次に、 Google Kubernetes Engine （GKE）で Confidential VM を作成する方法をご紹介します。

Google Cloud （GCP）のコンソール画面から「 Google Kubernetes Engine （GKE）」を選択します。

次に「作成」ボタンをクリックして、 Google Kubernetes Engine （GKE）のクラスタを作成します。

クラスタ作成画面の中にある「セキュリティ」をクリックし、「 Confidential GKE Node を有効にする」にチェックを入れます。

すると、 Compute Engine の時と同様にサービスに関する説明事項がポップアップで表示されるので、内容を確認して「変更を適用」をクリックします。

最後に、最下部の「作成」をクリックしてクラスタを作成します。

以上で、 Google Kubernetes Engine （GKE） に Confidential VM のノードを作成することができました。

実際にプロパティを確認すると、「シールドされた GKE ノード」と「 Confidential GKE Node 」が有効になっていることが確認できます。

Compute Engine の場合と同様に、チェックを入れるだけで簡単に Confidential VM を作成できることをご理解いただけたのではないでしょうか？

Confidential VM に関する Q&A

Q.Confidential VM が利用できるマシンタイプに制限はありますか？

A.はい。 Confidential VM は AMD Epyc の第2世代をベースに実行される N2D Compute Engine VM でご利用いただけます。詳しくはこちらのドキュメントをご参照ください。

Q.Confidential VM を利用することによるデメリットはありますか？

A.強力なセキュリティとのトレードオフとして、暗号化によるパフォーマンス観点でのオーバーヘッドが考えられます。ただし、 AMD 第2世代の暗号化なしと比較すれば「2〜5%のパフォーマンス影響」となっており、得られるものに対しての利点は大きいと考えます。

まとめ

今回は、ソフトウェアサプライチェーンに潜むリスクを解説し、このリスクを低減するために Google Cloud （GCP）ではどのような対策があるのか、をわかりやすくご説明しました。 Google Cloud （GCP）の実際の画面を使ったデモンストレーションにより、具体的なイメージをお持ちいただけたのではないでしょうか？

Google Cloud （GCP）は Titan チップと Shielded VM によって、信頼された環境構築を実現でき、 Binary Authorization を使えば、信頼されたコードが自社環境にデプロイされることを保証できます。さらに、データ通信やデータ処理、データ保存なども暗号化できるため、信頼されたアクセスも実現可能になります。

このように、 Google Cloud （GCP）はソフトウェアサプライチェーンリスクを回避するためには非常に有効なサービスとなっています。本記事を参考にして、ぜひ Google Cloud （GCP）の導入を検討してみてはいかがでしょうか？

弊社トップゲートでは、Google Cloud (GCP） 請求代行手数料無料、請求書払い可能などGoogle Cloud (GCP）をお得に便利に利用できます。さらに専門的な知見を活かし、幅広くあなたのビジネスを加速させるためにサポートをワンストップで対応することが可能です。

Google Workspace（旧G Suite）に関しても、実績に裏付けられた技術力やさまざまな導入支援実績があります。あなたの状況に最適な利用方法の提案から運用のサポートまでのあなたに寄り添ったサポートを実現します！

Google Cloud (GCP）、またはGoogle Workspace（旧G Suite）の導入をご検討をされている方はお気軽にお問い合わせください。

お問い合わせする