クラウドの信頼性に関するパラドックス: クラウドから暗号鍵を遠ざけることが必要になる 3 つのシナリオ

※この投稿は米国時間 2021 年 2 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

「クラウドの信頼性に関するパラドックス: より信頼できるクラウド コンピューティングを実現するには」と、「より堅固なセキュリティ キー管理の秘訣」でご紹介したように、暗号鍵をクラウド プロバイダ環境から遠ざけておくことが必要となる状況があります。このような状況は珍しいことですが、実際に存在します。この状況に陥ると、多くの場合、疑わしいデータや解決中の問題が極めて重要になります。

鍵をクラウドから遠ざけることが本当に必要な場合、またはクラウドベースでの鍵管理よりもメリットが大きい場合について、3 つのパターンをご紹介します。

シナリオ 1: クラウドに移行しにくいデータ

企業がデータ処理のワークロードをクラウドに移行する場合は通常、「簡単に移行できない」データが存在します。たとえば極めて機密性が高いデータ、厳しく規制されているデータ、内部の厳格なセキュリティ管理要件が存在するデータです。

機密性の高いデータは業界によって異なります。また、企業によっても異なります。あるグローバル企業は、規制を行っている世界中の施設に外部キーアクセスを行うとすると、堅固な鍵管理プロセスによる承認が必要になるだろうと述べています。別の企業は、PCI DSS 要件と社内要件の解釈に基づき、所有および運営する FIPS 140-2 レベル 3 HSM で独自のマスター鍵を管理しています。

これは、こうしたデータセットを保存または処理するためにそれらをパブリック クラウド プロバイダに送信することは不可能ではないにせよ、リスク、コンプライアンス、ポリシー上の理由で困難が生じることを意味します。このような事例は、規制が厳しい大企業（金融、医療、メーカーなど）に特に当てはまります。特定の「優先度」で対応する患者のデータや、特定の種類の金融取引に関連するデータなどが考えられます。

それでも、企業はこうしたデータセットをできるだけ暗号化してクラウドに移行し、複数の暗号鍵を単独で所有したいと考えているかも知れません。そのため移行に関する決定は、リスク、信頼性、監査におけるフィードバックを組み合わせて行われる可能性があります。または、特定のコンプライアンス規定をどのように解釈するかによって、顧客キーの保有が正当化されるかもしれません。

「クラウドに移行すべきではないデータがある」という意見はあるでしょう。これが当てはまる場合もありますが、デジタル トランスフォーメーション プロジェクトにはクラウドのアジリティが必要であることも広く認識されているため、完全に合意が得られるソリューションが見つからなくても、受け入れ可能なものが得られる可能性は高いといえます。

シナリオ 2: 地域における規制と懸念

クラウド コンピューティングが進化するにつれ、企業がどのようにクラウドに移行するか、またパブリック クラウドでワークロードをどのように運用するかを決定する際、特定地域の要件が果たす役割が大きくなってきています。このシナリオでは、ある国の外部にある企業（組織）が別の国でクラウドを使うことを希望しているものの、すべての保存データの暗号鍵にアクセスできるプロバイダに信頼していないという状況にフォーカスして説明していきます。暗号化されていないデータが同じクラウドで処理される場合でも、そのプロバイダはある時点でそのデータにアクセスするものとします。こうした企業は、そうしたクラウド プロバイダの理論的または物理的管理下にある暗号化デバイス（HSM など）に保存されている鍵も信頼できていない可能性もあります。彼らは、このようなアプローチは本当の Hold Your Own Key（HYOK）ではないと考えます。

このことは、それらの企業が所属する国の政府の管理下にある規制、または前述のすべての規制に関する問題が原因になっている可能性があります。さらに、欧州、日本、インド、ブラジルなどでは、暗号化されていないデータや暗号鍵を自国内に留めることに関する規制を検討または強化しています。ここに示す例では、クラウド プロバイダがいかなる状況でも企業のデータ、場合によっては暗号鍵にもアクセスできないようにすることを明記または示唆する、特定の業界における規制（欧州の TISAX など）について取り上げています。一方予備データから、暗号鍵は顧客企業のみが保有し、顧客が所属する国内に保存されているため、クラウド プロバイダがアクセスできる範囲外にある（暗号化されたデータは外部に存在する）というモデルが受け入れられている可能性もあることがわかっています。

別の例として、国固有のデータセットの鍵を、各国の担当者または国の管理下で保有するケースもあります。たとえば銀行取引に関するデータが該当し、各データセットの暗号鍵を国ごとに保存する必要があります。すべての暗号鍵がスイスのある山の下に保存されていると主張する銀行が一つの例としてあげられるかもしれません。一方で別の例として、鍵の管理者に関する包括的な知識とコントロール、そしてすべての鍵アクセス アクティビティに関するローカルの監査ログを保持するという要件（規制または内部）が考えられるかもしれません。

Thomas Kurian はこちらの投稿で次のように述べています。「データ主権は、プロバイダがお客様のデータにアクセスすることを防ぎ、お客様が必要だと考える特定のプロバイダの行動のみにアクセスを認めるメカニズムを提供します。Google Cloud が提供する顧客コントロール機能の例には、クラウドの外部で暗号鍵を保管、管理する、アクセスの詳細な理由に基づいてこれらの鍵へのアクセス権を付与する権限をお客様に提供する、使用中のデータを保護するなどがあります。こうした機能を通じて、お客様は自身のデータへのアクセスを完全に管理することができます。」

以上により、このシナリオでは、企業は物理的および管理的コントロールの下、任意のロケーションに暗号鍵を保管しつつ、Google Cloud を活用することが可能になります。

シナリオ 3: 暗号鍵の一元管理

こちらの事例では、対象の監査要件を難しくするような脅威はありません。業務の効率化を中心に解説していきます。Gartner の最新のレポートによると、鍵管理ツールの数を減らす必要性は、1 つのシステム内にすべての鍵を保持して複数のクラウド環境とオンプレミス環境に対応する強い動機となっています。

これは決まり文句のように聞こえるかもしれませんが、複雑さはセキュリティにとって非常に大きな問題です。任意のタスク（ログ管理や暗号鍵の管理など）に、複数の「一元化された」システムで対応すると、複雑さが増し、セキュリティを破る新たなポイントが生まれることになります。

この点から、クラウドかどうかにかかわらず、暗号鍵の大半に対して 1 つのシステムを使用したいという欲求は理解できます。暗号化を必要とするワークロードに対して、現在 100% クラウドベースの企業は少数であることから、すべての鍵をオンプレミスに保管するのは当然といえます。補助的なアクセス コントロールおよびポリシー ポイントと同じベンダーを使用することで付加的なメリットも生じます。単一セットの鍵を利用することで複雑性が軽減されます。適切なセキュリティと冗長性を備え、正しく実装されたシステムが 1 つあれば、複数のシステムを用意する必要性は低くなります。

また暗号鍵へのアクセスをコントロールすることで、データ処理の包括的なコントロールを保つこともできます。クライアントがボタンを押した時点でクラウド プロバイダが鍵にアクセスできなくなると、データには他の誰もアクセスできなくなり、誰からも盗まれません。

鍵管理を一元化すると、クラウド ユーザーに鍵アクセスに関するポリシーを適用する一元的な場所が与えられ、保存データにアクセスできるようになります。

次のステップ

ご紹介したシナリオは、暗号鍵をクラウド プロバイダから物理的に遠ざける、また、鍵を物理的な管理から解放するために本当に必要なものです。顧客が管理する HSM（CSP ロケーション）では実現されません。

• より堅固なセキュリティ キー管理の秘訣で、クラウドでの鍵管理をさらに学べます。

• 攻撃者、規制、地政学的なリスクなどに関するデータリスクを評価します。

• 本投稿で解説した 3 つのシナリオを理解し、ご自身の要件をそれらに対応したものにします。クラウドのデータ処理に脅威モデルの考えを適用し、クラウドから鍵を除外することが本当に必要か確認します。

Google EKM とパートナーの対象となるサービスを確認し、クラウドとオンプレミスから鍵を遠ざけるための暗号鍵の管理を実現します（Ionic、Fortanix、Thales など）。

-ソリューション戦略担当責任者 Anton Chuvakin

-Google Cloud シニア プロダクト マネージャー Il-Sung Lee