より堅固なセキュリティ キー管理の秘訣

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

暗号化に関するデータ セキュリティにおいて、暗号鍵を保護せずにデータを暗号化するという問題が古くから指摘されてきました。またさらに深刻なケースとして、暗号化されたファイルと同じデータベース内や同じシステム内など、データの近くに鍵を置いてしまうこともありました。そうした習慣が、重大なデータ侵害の大きな発生要因になっていたのです。コンプライアンス要件を満たすためだけに、十分に脅威モデルを検討することなく暗号化が実装されていたことが、調査によって明らかになる場合もありました。鍵の管理が後回しになるか、考慮すらされなかったという状況です。

鍵は暗号化するデータよりも厳格に保護されるべきと言われています（概して、暗号鍵は保護対象のデータよりも厳しく管理される必要があります）。鍵がデータの近くに保存されていれば、その鍵は、データ以上の保護がなされていないと見ていいでしょう。

規制を参照すれば鍵管理についての指針は得られますが、暗号化されたデータに関連する暗号鍵をどこに保存すべきか、明確に示している規制はほとんどありません。鍵をデータから離れた場所に保存することがセキュリティ対策として有効であることは明らかですが、これを誤解している組織も少なくありません。そもそも IT の世界で、どこからが「離れた場所」になるのでしょうか。

現在では、この状況にクラウド コンピューティングを加味する必要があります。「同じデータベース内に鍵を保管すべきでないように、同じクラウド内にも保管すべきでない」という考え方も生まれています。

これに対して、「当然」と思う人もいれば、「それは無理だ」と思う人も半数程度はいらっしゃるでしょう。だからこそ分析に値します。

まず明らかな点を指摘しましょう。それは「クラウド」という特定のモノは存在しないということです。これは一般に思われている、クラウドが「他の誰かのコンピュータ」であるということではありません。「クラウド」と呼ばれる 1 つの実体は存在しないのです。

たとえば保存データを暗号化する場合、さまざまな鍵管理の方法があります。実際私たちは、特定の脅威モデルや要件を考慮することなく、常にデフォルトの暗号化を使用して、鍵を安全かつ暗黙的に保存しています。詳細については、こちらの記事をご覧ください。一方で、そうした鍵は常に、さまざまなタイプの多数の境界によって、暗号化されたデータから離されて保存されていることもわかってくるでしょう。たとえばアプリケーション開発では、ワークロードとは分離されたプロジェクト内に鍵を保管することが一般的なベスト プラクティスになっているため、ネットワーク、ID、構成、サービス、あるいはその他の種類の境界をさらに形成する余地があります。ポイントは、鍵を「同じクラウド内に」保管しても、必ずしも同じデータベース内に鍵を保管するような問題にはつながらないということです。ただし例外もあります（後述）。

むしろクラウドでは、鍵をデータの近くに保管するリスクに新しい観点が生じます。鍵を物理的にどこに保存するかではなく、鍵を誰が管理するかという問題です。たとえば、データと同じネットワーク上にある（または同じクラウド データセンター内にある）安全なハードウェア デバイス（HSM など）内に鍵が保管されているとしたら、その鍵はデータに近いと言えるでしょうか。あるいは、鍵が国外のシステム内にあっても、データにアクセスする認証情報を持つユーザーが鍵にもアクセスできたとしたら、その鍵はデータから離れていると言えるでしょうか。これは、鍵が侵害された場合に最終的に誰が責任を負うのかという、複雑な問題にもつながります。こうした状況について、さまざまな側面から検討する必要があります。

ただしここで取り上げるのは、ほとんどが保存データに関する問題です（転送中のデータについては取り上げますが、使用中のデータについては言及しません）。

リスク

「同じクラウド内」という概念の意味合いを理解したところで、暗号鍵の保存に関する行動に影響するリスクと要件について考えてみましょう。

まず、暗号化されたデータと同じデータベース内や同じディスク上に鍵を保存する、不適切な設計のオンプレミス アプリケーションがあったとします。それをクラウドに移行すれば、当然ながらクラウドでも同じ問題が生じます。これを解決するには、たとえばクラウド ネイティブな鍵管理メカニズムを使用します（これにはもちろん、アプリケーションの変更も含まれます）。

以上をふまえて、関係するリスクと問題を次に示します。

ヒューマン エラー: まず明らかなリスクはもちろん、鍵の開示、紛失、盗難などにつながる悪意のないヒューマン エラーです。デベロッパーのミス、不適切なエントロピー ソースの使用、権限の構成ミス、権限の緩さなどがあります。これらはクラウド固有のものではありませんが、パブリック クラウドではその影響がより大きな形で表れます。理論上は、鍵の開示につながるようなクラウド プロバイダの誤りもここに含まれます。

外部の攻撃者: 第 2 に、外部の攻撃者による鍵の盗難もまた、クラウド以前の時代からの問題です。攻撃者が鍵管理システム（KMS）を攻撃し、広範なデータにアクセスするものです。これらの攻撃者はまた、アプリケーションのログにアクセスして読み取る方法や、アプリケーション ネットワーク トラフィックを監視する方法を知っています。そうした手段を利用して、鍵の場所を探るわけです。経験のほとんどをクラウド以前に蓄積してきたセキュリティ専門家は感覚的に、KMS がファイアウォールのレイヤの背後にあることで安心しますが、外部の攻撃者は多くの場合、上述のヒューマン エラーを見つけて、その弱点をデータ侵害に利用します。

内部の脅威: 第 3 に、内部関係者による問題も見逃せません。クラウド コンピューティング モデルでは 2 つの異なる内部関係者のモデルが想定されています。クラウド ユーザーの組織とクラウド プロバイダ（CSP）の内部関係者です。一般には CSP に関わる内部関係者に注目が集まることが多いのですが、データにアクセスするための有効な認証情報を持っているのは、通常は顧客の内部関係者です。CSP の従業員の一部は（理論的に、また大規模な共謀によるセキュリティのコントロールができれば）、たしかにデータにアクセスできます。しかし実際に有効な認証情報を利用してクラウド内のデータに直接アクセスできるのは、クラウドの顧客の内部関係者です。脅威モデリングの観点から見ると、ほとんどの攻撃者は、（多くの場合クラウド ユーザーの組織の）最も脆弱な部分を探し出して侵害し、そこから次の段階に進みます。

コンプライアンス: 第 4 に、特定の方法で鍵を処理するよう規定する義務や規制の存在です。その多くはクラウド コンピューティングの前の時代から存在するため、クラウドについての明確な指針にはなりません。明示的な要件、暗黙の要件、さらには解釈で運用されている要件や、内部要件を区別することが重要です。たとえば、特定の方法で保護された特定のシステム内に暗号鍵を常に保管することが、組織のポリシーとして規定されていることもあるでしょう。こうした内部ポリシーは数十年前のものである場合があり、そのリスク管理上の根拠をたどることは困難です。実際には、古くからある複雑なセキュリティ システムとセキュリティ対策は、クラウド コンピューティング リソースと対策による最新の手法を導入すれば、シンプルに、また包括的になります。

さらに一部のグローバル企業には、なんらかの法令遵守とは別に、政府機関との間で合意した和解条件を遵守するよう求められるケースもあり、その場合は義務として、組織内で広く共有できない技術的な安全保護対策が求められる場合があります。

データ主権: 最後に、デジタル領域では対処できない、サイバーセキュリティ分野以外のリスクが存在します。これらは、データ主権とデジタル主権におけるさまざまな問題、さらには地政学的なリスクに関係している場合があります。端的に言えば、これらのリスクが現実に存在するか、感覚的なものであるか（あるいは鍵を保有するだけで最終的に開示を防げるか）にかかわらず、暗号鍵を直接管理する必要が生ずるということです。たとえば、ブラインド召喚状や第三者召喚状に対する懸念から、組織のデータ セキュリティに関する意思決定が影響される場合があるとのレポートが存在します。

上述の 5 つのリスクは現実的なものでしょうか。または、リスクが現実的ではないとしても、現実であると組織が認識して対処を計画してもよいものでしょうか。そして、組織がそれらのリスクを深刻に受け止めた場合、設計上どのような選択肢があるでしょうか。

アーキテクチャとアプローチ

まず概して、最新のクラウド アーキテクチャを導入することで実際に、暗号化に関するある種のミスの発生が抑制されます。もし特定のユーザーロールでクラウド KMS にアクセスできない場合、鍵を「偶然に」入手する方法はありません（それはたとえば共有ディレクトリ内のディスクで鍵を発見するようなものです）。実際上、ID がクラウド内で強力な境界として機能しているからです。

適切に設計された認証システム（ID 境界）よりもファイアウォール（ネットワーク境界）が信頼できると考えるのは、クラウド以前の時代の思い込みにすぎません。さらに、クラウドのアクセス制御やクラウドログによって、鍵を使用するたびに誰がどのようにアクセスしたかが管理されます。したがってほとんどの場合、オンプレミスでの管理よりも確実なセキュリティが得られます。

ソフトウェア ベースのシステムに保存されるクラウドの暗号鍵

たとえば、特定の鍵管理の手法（内部コンプライアンス、リスク、ロケーション、取り消しなど）を適用する必要がある場合は、Google Cloud KMS を CMEK で使用できます。その場合、鍵は広義では同じクラウド（Google Cloud）上にありますが、決してデータと同じ場所にあるということにはなりません（鍵が保存される方法の詳細）。データにアクセスできるユーザー（データにアクセスできる有効な認証情報を持つ、クライアントの内部関係者など）でも、KMS にアクセスできる権限を持たない限り、鍵を入手することはできません（ID が強力な境界として機能するため）。したがって、デベロッパーが鍵を偶然入手することはできず、また鍵を埋め込んだアプリを設計することもできません。

これにより上述のリスクの大半が解決されますが、もちろん解決されないものもあります。クラウドの顧客がデータと鍵を分離する安全保護対策を管理することはできませんが、関連情報を確認することは可能です。

ハードウェア ベースのシステムに保存されるクラウドの暗号鍵

次に、アカウント権限にかかわらず誰も鍵を入手できないようにする必要がある場合は、ハードウェア デバイス内に鍵を保存する方法として、Cloud HSM を使用できます。その場合は、ID だけでなく、ハードウェア デバイスのセキュリティ特性が、データから鍵を分離する境界になります。また、デバイスの場所とその周囲に適用されている、検証済みのあらゆるセキュリティ管理機能も有効に機能します。これにより上述のリスクのほとんどが解決されますが、すべてではありません。またこれにより、費用や食い違いが発生する可能性があります。

ここでもまた、クラウドの顧客はハードウェア デバイスやその他の管理機能の使用の保証をリクエストできますが、鍵とデータを分離する安全保護対策の管理はできません。クラウド サービス プロバイダによるハードウェア処理を信頼するだけです。キー マテリアルへのアクセスについては、ソフトウェア キーではなく HSM キーを使用することで制限を強化できますが、鍵の使用に関する安全性が本質的に高くなることはありません。また、プロバイダによりホストされている HSM の内部鍵は、クラウド プロバイダの論理的または物理的な管理下にあると見なされるため、Hold Your Own Key（HYOK）要件の文言や精神に合致しません。

プロバイダのインフラストラクチャの外部に保存されたクラウド暗号鍵

ここで、上述のリスクに実際に対応する方法が存在します（地政学的な問題に関連する最後の項目など）。それは、Google Cloud External Key Manager（EKM）などの技術を使用して実装した、Hold Your Own Key（HYOK）を実践することです。このシナリオでは鍵にアクセスできないため、プロバイダのバグ、ミス、外部からプロバイダ ネットワークへの攻撃、クラウド プロバイダの内部関係者については問題になりません。クラウド プロバイダは暗号鍵を持たないため、それを開示することはできません。これにより上述のリスクのすべてが解決されますが、費用や食い違いが発生する可能性があります。ここで、クラウドの顧客は鍵をデータから分離する安全保護対策を管理し、EKM 技術が実装される方法の保証をリクエストできます。

このアプローチは、他のアプローチとは決定的に異なります。クラウド プロバイダのデータセンターに配置された顧客管理の HSM デバイスでも、同じレベルの保証は得られないためです。

重要ポイント

• データを保管しているのと同じクラウド プロバイダに鍵を保管することが、全面的に禁止されているわけではありません。「同じクラウド内に」鍵があるかどうかは、規制や脅威モデルに照らして、具体的に見直す必要があります。新しいリスクがあるとしても、クラウドに移行することで、総体的に軽減される場合もあります。鍵管理の意思決定に影響する、リスク、リスクの許容範囲、動機について見直してみましょう。

• 鍵の一覧を作成し、データとの距離を明確にするようにしてください。一般的には、鍵がデータよりも厳重に保護されているか、想定している脅威モデルに実際の保護がフィットしているかを確認してください。新しい潜在的な脅威が見つかったら、必要な管理機能を環境内にデプロイしてください。

• Google Cloud の KMS を使用した鍵管理のメリットとしては、包括的で一貫性のある IAM、ポリシー、アクセスの正当性、ロギングに加え、クラウド ネイティブ技術を使用するプロジェクトに対するアジリティが得られる可能性が高いということが挙げられます。したがって、クラウド プロバイダの KMS は、外部化された信頼または他の状況を要求することなく、ほとんどの状況で使用できます。

• 鍵をクラウドから分離する必要があるケースは、規制やビジネス上の要件によって明確になります。よくある状況について、次のブログで取り上げます。引き続きご注目ください。

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

-プロダクト マネージャー Honna Segel