オンプレミスからの移行に伴う変化: 暗号化、鍵管理、真のセキュリティ
Google Cloud Japan Team
※この投稿は米国時間 2020 年 9 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。
コンプライアンスを徹底しているからといって、安全であるとは限りません。「安全である」の定義、つまり、何に対して安全かは、業種、組織、脅威プロファイルによって大きく異なり、部外者が作成したチェックリストを使っても確認することはできません。
このため、コンプライアンスとセキュリティは独特の関係を築いてきました。規制は、特定領域の知識体系のなかで受け入れられているベスト プラクティスを通じて、ガイダンスを提供することを目的としています。しかし、法律や規制の進化はテクノロジーよりも遅い傾向があり、コンプライアンス体制は多くの新しいテクノロジーを見越したものではありません。このことは、セキュリティを確保するためのテクノロジーとツールの両方に当てはまります。多くのセキュリティ専門家は「コンプライアンスはセキュリティではない」と言いますが、結局は予算を獲得し、実施する管理方法を決定するために外部の指令書を利用します。
それでも、コンプライアンスは一部のセキュリティに関する決定の要因であり、金融やヘルスケアなどの「規制産業」ではさらに重要となります。コンプライアンスは、セキュリティに取り組み始めたばかりの組織にとって、リスク管理よりも強い動機にもなっています。
今回の記事では、多くの規制で要求される主要な制御の一つであるデータ暗号化について説明します。具体的には、暗号鍵の管理がデータ セキュリティ全体にとっていかに重要であるかを説明し、暗号鍵の管理を検討する際に留意すべきベスト プラクティスを考察していきます。
今日のコンプライアンスと暗号化
多くの規制や指令書に含まれる制御の一つがデータ暗号化です。ほとんどの IT 関連のコンプライアンスは、患者情報、財務記録、支払いカード番号などの特定のタイプのデータに適用されます。Unified Compliance Framework（UCF）のデータにより、暗号化は最も一般的な制御の一つであり、UCF が追跡する何百もの規制や指令に含まれていることが示されています（こちらも参照）。「支払いデータを暗号化する」、「患者データを暗号化する」、「データ保護のために暗号化などの手段を使用する」、「送信中のデータを暗号化する」といった文言は、US HIPAA から シンガポール個人情報保護法まで、世界中の規制文書に記載されています。
しかし、暗号鍵の管理について詳細に取り扱っている規制はほとんどありません。一部の規制の中には「鍵を暗号化されたデータとともに保存しない」などの最小限のガイダンスを含むものや、「鍵は安全に保管する必要がある」と示唆するものもあります。しかし、詳細まで取り扱っている規制はわずかです。たとえば、PCI DSS では、鍵を「少なくともデータ暗号鍵と同等に強い鍵暗号鍵で暗号化し、データ暗号鍵とは別に保存する」こと、そしてクライアントは「すべての鍵管理とカード所有者データの暗号化に使用する暗号鍵のプロセスと手順を完全に文書化して実装する」こととしています。さらに PCI DSS は鍵管理の技術面とプロセス面の両方を取り扱い、「暗号鍵管理者が、鍵管理者の責任を理解して受け入れることを正式に承諾する必要がある」などを記載しています（出典: PCI DSS 3.2.1）。
もう一つの例は、NIST 800-53（および FedRAMP）で、「組織は必要な暗号のために暗号鍵を確立して管理する（後略）」と記載されています。これは組織が独自の暗号鍵を管理する必要があるとするものですが、詳細は取り扱っていません。（注記: NIST 800-57 ドキュメントは鍵管理の詳細を取り扱っています。）ヨーロッパの一部の銀行規制では、銀行はプロバイダが管理する暗号化に依存するのではなく、独自の暗号鍵を管理することも規定しています。
それでも、詳細かつ包括的な鍵管理ガイダンスは、コンプライアンスの世界には滅多にありません。
暗号化のためのハードウェア セキュリティ モジュール（HSM）の使用を規定する指令書や標準も多くはありません（たとえば、この UCF リンクを参照）。PCI DSS などの一部のドキュメントは、HSM を許容可能な選択肢として言及していますが、その使用を組織に強制していません。しかし、実際に HSM の展開を必要とする特定の命令書、法律、規制を挙げることができなくても、「コンプライアンスのために」HSM が必要であると考えるセキュリティ リーダーもいます。
データ保護のためにはデータを暗号化する必要がありますが、最終的に、使用する鍵の運命は、規制当局ではなく組織にかかっています。
脅威に対して暗号化の威力を発揮させるには、適切な鍵管理が必要です。
この一連のコンプライアンスの事実を他の事実と関連付けてみましょう。最近のテクノロジーの進歩により、暗号化は至るところに普及しました。たとえば、暗号化されたモバイル デバイスの急増やウェブ トラフィックにおいて TLS カバレッジが増加していることなどです。つまり、エンタープライズの鍵管理は、多くの組織にとってこれからも課題になるということです。
事実、コンプライアンスのチェック項目を満たすだけでなく、効果的なセキュリティのために暗号化を使用して実際の脅威を阻止するには、しっかりとした鍵管理が必要です。一般的には、暗号化によるセキュリティ上のメリットは、アルゴリズムや数学的な強度だけでなく、鍵管理もあいまって得られるものです。暗号化の使用法が遵守すべき指令に準拠していても、データを狙う脅威にその鍵管理が耐えられないことは十分にあり得ます。
したがって、規制によって、鍵管理を使用してデータ保護を最大化することを強いられなくても、脅威によって、それを強いられる場合があります。実際、奇妙なことに、一部のランサムウェア犯罪グループは、一部の組織を超える高度な暗号鍵管理を実現していました。
次に、この鍵管理においてもう一つの重要な側面であるクラウドについて議論しましょう。
クラウド鍵管理
規制の進化はテクノロジーに追いついていません。実際、暗号化に関連する命令書の一部は、約 20 年前に書かれています（たとえば、FIPS 140-2 が最後に更新されたのは 2002 年）。一方、クラウドは、新しいセキュリティ メカニズムを可能にする手段であると同時に、セキュリティで保護される対象である新しい環境として登場しました。
脅威と規制当局の両方に後押しされ、クラウド コンピューティング ユーザーは、データの暗号化に取り組み始めました。今日、その対象はほとんどが転送中データと保存データですが、将来は Confidential Computing などの方法でも使用されます。これにより、少なくとも情報に通じている人にとっては、クラウドで効果的な鍵管理を行うという課題が生じました。
しかし、「効果的」とはどういう意味でしょうか。
オンプレミスのプロプライエタリなアプライアンスベース モデルにおける鍵管理関連のコンプライアンス要件を満たすために使用する方法は、クラウドにそのまま適用できません。
最終的には、クラウドは優れた暗号鍵管理のデプロイと運用を容易にします。ほとんどのクラウド サービスの場合と同様に、鍵管理を API で行うことで、複雑さを大きく取り除き、物事を安全に行うことが容易になります。これにより、開発が加速し、多くのコンプライアンス フレームワークに含まれる、より堅牢な変更管理が可能になります。
今日、鍵管理はクラウドに合わせてスケールする必要があります。レイテンシ、可用性、クラウド サービスの統合は、クラウドの可能性を実現するために不可欠ですが、従来のアプライアンス HSM はクラウド時代向けに設計されていません。データセンターからクラウド HSM に移行することで、このような懸念に対処し、コンプライアンス、セキュリティ、クラウドのアジリティを実現することができます。
オンプレミスのコンテキストでコンプライアンス評価を実施するために従来使用していた方法やツールは、多くの場合クラウドにそのまま流用することができません。そこで登場したのが、お客様とクラウド プロバイダの間で責任を共有することです。たとえば、物理的なセキュリティ制御は現在クラウド プロバイダによってサポートされているため、標準のダウンロード可能なコンプライアンス ドキュメントで対応できます。
しかし、時間の経過とともに新しい規制上の懸念が生じる可能性があります。たとえば、データ所在地の限定に関する規制は、すべてのデータがオンプレミスの場合は問題ではありませんが、ワークロードと鍵管理をクラウドに移行した場合は、新しく理解、作業、監査が必要になります。実装担当者は、鍵マテリアルに対するデータ所在地の制御と、鍵がサポートするワークロードのデータ所在地（そして場合によってはデータ主権も）の制御をクラウド プロバイダがサポートできることを確認する必要があります。
コンプライアンスに加えて、多くの作業がお客様の物理的境界の外で行われている場合、留意すべき脅威も変化します。すなわち、「内部の脅威」が異なる意味を持つということです。たとえば、お客様にとって重要な課題は従来の物理的なアクセス制御から仮想マシンへのアクセスを確実にロックダウンすることに変化すると考えられます。
それでは変わらない点は何でしょうか。強力なアクセス制御とガバナンスを維持することは今後も重要となります。今でもアカウントの侵害は、攻撃が成功しやすい最も一般的な方法です。
これは、IT 全体とセキュリティのデプロイと運用の方法における非常に大きなシフトです。消費モデルも異なります。従来の何年にも及ぶメンテナンスが伴い、初期に投資額が偏る設備投資を行うモデルに対して、クラウドでは無制限に鍵が利用できて可用性の向上が約束され、すぐに使える消費ベースの運用コストモデルが採用されています。
ベスト プラクティスと次のステップ
コンプライアンス フレームワークの進化の遅れにかかわらず、クラウドで簡素化された鍵管理機能を使用して鍵管理ガバナンスを構築すると、セキュリティが向上します。制御手段に幅広い選択肢があるため、適切なものをワークロードに適用することができます。
暗号鍵管理に関して Google Cloud ユーザーが覚えておくべき重要な項目をいくつか以下に示します。
コンプライアンスは暗号化を強制しますが、脅威は暗号化と鍵管理の両方の実行を強制します。暗号化と鍵管理を実装するときは、コンプライアンスの命令書だけでなく、脅威の評価結果に焦点を当てます。
鍵管理は、暗号化という制御を効果的なものにする要素です。これはコンプライアンスだけでなく、特にセキュリティのために重要です。暗号化は信頼をもたらしますが、それは鍵管理の透明性が確保されており、鍵を攻撃者から遠ざけることに成功している場合に限られます。
クラウドに移行するにあたり、制御を導入して、コンプライアンスの要求とセキュリティ要件の最終的なバランスを取りながら、ビジネスに必要なクラウドのアジリティを実現します。
特定の脅威評価結果または特定の命令書のために本当に必要な場合は、ハードウェアベースの暗号化を利用します。同様に、脅威プロファイルや規制によって、より高い信頼性のために必要であると示唆される場合は、自ら鍵の管理を行います。
同時に、ソフトウェア格納型鍵の費用とスケーラビリティのメリットが、所有および運用しているマシンのハードウェア格納型鍵を使用するための古い要件を上回るかどうかを評価します。
Google が世界各地におけるコンプライアンス要件に対応している方法と、データを保護するために確立する必要がある制御に関するお客様の責任を把握します。
コンプライアンス規制は、機密データを安全に保つためのフレームワークを組織に提供するために整備されたものです。しかし、前述のように、コンプライアンスと真の安全性はまったく異なるものです。暗号鍵管理は、このギャップを埋める重要な方法の一つなのです。
Google Cloud のセキュリティの詳細をご覧ください。
-ソリューション戦略担当責任者 Anton Chuvakin
-プロダクト マネージャー Honna Segel
