Googleが勧める対策、クラウドにおける暗号鍵の保存方法とは：3つのセキュリティアプローチを比較

Googleはクラウドにおける暗号鍵の保存について、同社の関連サービスを引き合いに出して解説した。暗号鍵に対する5つの主要なリスクに続いて、リスクに対応する3つの手法を利点と欠点を示しながら紹介した。

[＠IT]

　Googleは2020年12月22日（米国時間）、公式Blogにおいてクラウドセキュリティについての考え方を紹介した。クラウドではどのように暗号鍵を保存すればよいのか、何を目指すべきなのか、同社の関連サービスを引き合いに出して解説した。

　以下にその概要を紹介する。

古典的な間違い　暗号鍵とデータを同じ場所に保存する

　暗号化を用いたデータセキュリティ対策には古典的な間違いがある。その一つが「暗号鍵を、暗号化したデータと同じデータベースや同じディスクに保存する」というものだ。こうした手法が大規模なデータ流出につながった事例が過去に報じられている。

　暗号鍵は、暗号化されるデータよりも厳しく保護しなければならない。

　暗号鍵をデータと一緒に保存しているオンプレミスアプリケーションを使っていたとしよう。クラウドに移行すると、当然のことながら、この問題もクラウドに残ってしまう。解決策は、クラウドネイティブな暗号鍵管理メカニズムを使用することだ。これには、アプリケーションに変更を加えることも含まれる。

　クラウド環境で暗号鍵を適切に保存するには、この前提を押さえることが第一だ。さらにクラウドにおける暗号鍵の保存に関してさまざまなリスクを理解しなければならない。

人的ミスは必ず起こる

　悪意のない人的ミスが暗号鍵の漏えい、紛失、盗難につながる場合がある。開発者のミスや、暗号鍵の作成に（規則性が残っている）低品質なエントロピー源を用いてしまうこと、権限の構成ミスや管理の緩さといった問題が起こり得る。クラウド固有の問題ではないものの、いざ問題が起こったときにパブリッククラウドの被害が大きくなる傾向がある。理論上とはいえパブリッククラウドプロバイダーのミスが暗号鍵の漏えいにつながる可能性もある。

外部からの攻撃者を無視しない

　クラウド以前の時代から、外部攻撃者による暗号鍵の窃盗が問題になっている。鍵管理システム（KMS）を攻撃し、幅広いデータにアクセスしようとする手口が知られている。アプリケーションログにアクセスして読み取る方法や、アプリケーションネットワークトラフィックを観察する方法にも攻撃者は精通している。こうした手法によって、暗号鍵の在りかについてのヒントが漏れてしまう可能性がある。クラウド以前に経験を積んだセキュリティ担当者は、KMSがファイアウォールの内側にあると、本能的に安心する。だが、外部攻撃者は、人的ミスをなんとか発見して侵害につなげようとする。

2種類の内部者のどちらが狙われるのか

　クラウドコンピューティングモデルでは、内部者は2種類に分かれる。クラウドを利用するユーザー組織の内部者と、クラウドサービスプロバイダー（CSP）の内部者だ。CSPの内部者の一部は、クラウドデータにアクセスできる可能性がある。ユーザー組織の内部者は、クラウドデータにアクセスするための有効な資格情報を持っている。脅威モデリングの観点からすると、ほとんどの攻撃者は、まず“最も弱いリンク”（恐らく、ユーザー組織の中にある）を見つけ、悪用しようとする。

クラウドがコンプライアンスから漏れていないか

　暗号鍵の扱い方を規定する基準や規制はさまざまだ。多くはクラウドコンピューティングが登場する前からある。そのため、暗号鍵の保存にクラウドを使用する場合に関しては、明確なガイダンスがないかもしれない。明示的な要件、暗黙の要件（解釈された要件といえるもの）、内部的な要件を区別するとよい。

　一部のグローバル企業は、実施中の規制順守の取り組みとは別に、地方自治体や政府機関が定めた何らかの法的事項の適用を受けるかもしれない。こうした場合、義務を果たすために、社内で広く共有できない何らかの技術的な保護が必要かもしれない。

サイバーセキュリティ以外の問題：データ主権

　この分野では、物事が急速に変化しており、サイバーセキュリティ以外のリスクが存在している。これらのリスクは、データ主権やデジタル主権、さらには地政学リスクと関連している。こうしたリスクを背景に、暗号鍵を直接管理する必要性が高まっている。

Googleが紹介するアーキテクチャとアプローチとは

　ここまでに紹介したリスクを踏まえ、クラウドを使って暗号鍵を適切に保存するには、どのようなアーキテクチャとアプローチを採用すべきか、Googleが推奨するのは次のような手法だ。

　暗号鍵の保存という観点からすると、モダンクラウドアーキテクチャは、問題の一部をそもそも起こしにくいという特徴がある。特定のユーザーロール（役割）に、クラウドKMSへのアクセス権が割り当てられていなければ、ユーザーが“うっかり”暗号鍵を取得することはあり得ない。実際、クラウドにおいてアイデンティティー（ID）は、強力な境界として機能する。

　ファイアウォール（ネットワーク境界）を、的確に設計された認証システム（ID境界）よりも信頼してはいけない。ファイアウォールを重視する考え方はクラウド以前の時代の名残にすぎない。クラウドにおいては、暗号鍵が使われるたびにアクセス制御を実行し、誰がどのように使ったのか、ログを記録しやすい。ほとんどのオンプレミス環境で実現できるレベルよりも優れたセキュリティを維持できる可能性がある。

クラウドで暗号鍵を取り扱う便利な方法がある

　例えば、特定の鍵管理プラクティス（内部コンプライアンス、リスク、場所、取り消しなどに関する）を適用する必要がある場合、Googleの「Cloud Key Management Service」（KMS）と「顧客管理の暗号鍵（CMEK）」を組み合わせて利用できる。

　この場合、暗号鍵が暗号化対象のデータと同じクラウド（Google Cloud）にあるものの、クラウドにおける暗号鍵の保存場所（保存方法の詳細）は、データとは全く異なる。

　有効な資格情報などを使えるユーザー組織の内部者はデータにアクセスできものの、KMSへのアクセス権限を持っていなければ、暗号鍵にアクセスできない。IDが強力な境界として機能している形だ。そのため、アプリケーション開発者がうっかり暗号鍵を取得してしまったり、暗号鍵が組み込まれたアプリケーションを設計したりすることはあり得ない。

　この方法では、紹介したリスクのほとんどに対処できる。対処できないリスクも明らかに残る。暗号鍵とデータを分離する保護策を管理していないユーザー組織であっても、それらについての情報を読み出すことが可能だ。

暗号鍵をハードウェアに保存するとどうなるか

　アカウントの権限にかかわらず、ユーザーが暗号鍵にアクセスできないようにする必要がある場合にはどうしたらよいのだろうか。

　例えばGoogleの「Cloud HSM」（ハードウェアセキュリティモジュール）を使って、暗号鍵をハードウェアデバイス内に保存する方法がある。

　この場合、暗号鍵とデータを分離する境界は、IDではなく、ハードウェアデバイスのセキュリティ特性と、デバイスの保存場所に適用された検証済みの全てのセキュリティ対策だ。

　ハードウェアを使うと紹介したほぼ全てのリスクに対処できるが、まだリスクが残る。コストも増え、手間がかかる可能性もある。

　クラウドを利用するユーザー組織は、ハードウェアセキュリティデバイスの使用を求めたり、保証を求めたりできる。だが暗号鍵とデータを分離する保護策を管理できない。つまり、CSPがどのようにハードウェアを扱うかという信頼に依存している。

　そのため、HSM鍵ではソフトウェア鍵と比べて、暗号鍵への物理的アクセスはより制限されるものの、暗号鍵を使用するためのアクセスがより安全だとはいえない。さらに、CSPによってホストされるHSM内の暗号鍵は、CSPの論理的または物理的管理下にあると考えられる。真の「Hold Your Own Key」（HYOK：鍵を自ら管理する）という要件を満たすことはできない。

クラウドの外部パートナーインフラに暗号鍵を保存する手法はかなり強力だ

　地政学の問題に関連するデータ主権リスクを含め、紹介した全てのリスクに対処できる方法がある。Google Cloudの外部で暗号鍵を管理し、ユーザーがその暗号鍵を使用して保存データを暗号化できるGoogleの「Cloud External Key Manager」（EKM）のような技術を使ってHYOKを実装することだ。

　このシナリオでは、CSPのバグやミス、CSPネットワークへの外部者の攻撃、CSPの内部者は、いずれも問題とならない。暗号鍵がCSPのクラウドには一切現れないからだ。CSPは暗号鍵を持っていないため、CSPから暗号鍵が漏えいすることもあり得ない。

　クラウドを利用するユーザー組織は、暗号鍵とデータを分離する保護策を管理するとともに、EKM技術の実装方法について、保証をリクエストできる。

　この手法では、上の全てのリスクに対処できるが課題もある。コストがかかる他、手間が増える可能性もあるからだ。さらにユーザー組織が管理するHSMデバイスがCSPのデータセンターに設置された場合でも、同等のセキュリティを保証できない。