2026年4月21日8:00
クラウド事業者への依存からの脱却
自社コントロールへのパラダイムシフト
鍵管理に関しては、別の文脈でも同じ問題が起きていました。2つ目のユースケースを紹介します。クラウド移行を進める国内の決済事業者の事例です。
この企業では、AWS、Azure、SaaSなど複数クラウドを利用するマルチクラウド化によって、鍵の乱立という課題が持ち上がっていました。こういった場合、監査ログの形式が不一致で統合監視が困難になりがちです。とはいえ、たとえばZoomもSaaSですし、昨今はどの企業においてもクラウドの利用は避けられない状況です。
こういった場合、クラウド解約時の問題についてもあらかじめ考えておかなければなりません。最終的なデータ削除はクラウド事業者の手に委ねられることになりますので、ユーザー企業が確実にデータが消去されたという証明を得ることはかなり難しいと思われます。どこに鍵を置いているかによって、破棄の仕様も異なります。例えばAWS KMSでは、鍵の削除に最低7日間を要します。クラウド事業者の仕様をきちんと理解したうえでExit戦略を立てることが、ひとつの大事なポイントになります。
それでも、クラウド事業者によるデータ復号の潜在的懸念は残ります。鍵がクラウド上にある限り、第三者へのデータ開示リスクは消えません。
共有責任モデルにおける、ユーザー側のデータの責任範囲はどこまでなのでしょうか。IaaS（Infrastructure as a Service）の場合はO/Sからミッドウェア、Runtime、アプリケーション、データまでがユーザーの責任範囲となります。PaaS（Platform as a Service）の場合はアプリケーションとデータ、SaaS（Software as a Service）の場合はデータがユーザーの責任範囲です。いずれであっても、データの責任はユーザーにあります。その責任を果たしていることをどうやって証明するかということが、今後の大きな課題のひとつになると考えています。
このときに重要になるのも、クラウド上の鍵です。鍵の主権（Key Sovereignty）を確立するためのテクニックはいろいろあります。鍵をクラウドプロバイダに持ち込むBYOK（Bring Your Own Key）、ずっと自分の手元に携えておくHYOK（Hold Your Own Key）、暗号の仕組み自体をクラウドプロバイダに持って行くBYOE（Bring Your Own Encryption）など、さまざまなアプローチ方法があります。
さらに、クラウドの外、自社管理領域でマスター鍵を生成・保管する方法もあります。手前味噌になりますが、われわれは、CSA（Cloud Security Alliance）という団体が出しているベストプラクティス、CCM（Cloud Controls Matrix）に従って、鍵をクラウド上に保管するのではなく、クラウドの利用者または信頼できる鍵管理事業者が保管する体制の整備を進めています。
このケースでは、アーキテクチャのアプローチに際し、鍵の主権の確立と合わせて、暗号化消去が重要なキーワードになりました。先ほども取り上げた暗号化消去、Exit戦略に関しては、クラウド環境に対応した仕組みがあります。われわれも定期的にコンタクトをとっているADEC（データ適正消去実行証明協議会）という団体では、CE-C認証（クラウド上のデータ消去を証明する技術基準）を行っています。この認証を取得済みのクラウド事業者、および、暗号化のサービスや鍵管理サービスの利用を検討することを推奨いたしました。
また、このケースでは、クラウドへの依存からシステムでの証明に移行したことで、監査におけるメリットが生まれています。具体的な成果として、第三者のアクセスを排除したことで、クラウド管理者でもデータを復号できないことを論理的に説明することが可能になりました。合わせて、先ほど紹介したCE-C認証取得済みクラウド事業者、及び、鍵管理サービスを利用することにより、第三者機関がデータの完全消去を証明。これにより、機微な情報も安心して預けられる体制が整いました。
実務上、契約先の候補については常に複数の選択肢を持っていたいものです。しっかり鍵を握っておけば、いつでもクラウドベンダを解約することができます。つまり、特定のクラウドベンダへのロックインを回避できます。クラウド事業者が悪いと言っているわけではありません。「クラウド事業者を信じる」ことから、「自社でコントロールする」ことへのパラダイムシフトが必要だと考えているのです。
また、PANの非保持化を実行している企業もかなり多いのではないかと思います。その場合、APIキーやWebhookシークレットの管理責任は自社側にあります。加えて、決済代行企業のシステムの中で、顧客データ・取引記録の暗号化鍵の主権は誰にあるかということも、今一度確認しておいたほうがいいと思います。
それから、私も使っていますが、AIエージェントですね。この活用が進んでいったとき、APIキーの管理、マシン間通信のシークレット管理が、今後の監査スコープに入ってくる可能性は十分にあると考えています。こういったことも含め、共有責任モデルと同様、データの暗号化の責任は常に自社にあることを認識しておいていただきたいと思います。
耐量子暗号（PQC）時代のHNDLは
明日ではなく、今日のリスク
さらに現代では、量子コンピュータの脅威により、現在の暗号が将来も通用するかどうかが、新たな問いとしてわれわれに突き付けられています。現在の暗号が直ちに破られるわけではありませんが、RSAや楕円曲線暗号を使用しているすべてのシステムは、いずれはPQCへの移行対象になるだろうと思います。特に金融・決済データには長期的な機密性が求められているため、もうすでに脅威にさらされていると考えられます。
これがすなわち、HNDL（Harvest Now, Decrypt Later）の脅威です。量子コンピュータの台頭により暗号はより複雑化しますが、攻撃者は暗号化されたデータを窃取し、あとで解読するために保管します。後々盗んだデータが復号・解読されれば、ダークウェブなどで販売・悪用され、大変な被害がもたらされる危険があります。
想定され得る攻撃シナリオとして、フェーズ１ではヘルスケア・金融・決済データなどで漏えいが徐々に増加していき、フェーズ２では世界的なインフラの信頼を連鎖的に侵食、フェーズ３では経済活動を鈍化させるといったことが考えられます。
そこでわれわれが行っておくべき将来への備えとして、今すぐ全面施行ということではありませんが、アジリティの確保を提示しておきたいと思います。
そのひとつ、クリプト・インベントリとして、自社のどこで、何のアルゴリズム・鍵長・ライブラリが使われているかを、正確に把握・追跡する仕組みを構築しておくことです。もうひとつ、クリプト・アジリティ、つまり暗号の俊敏性の設計としては、将来、アルゴリズムに脆弱性が発見された際、システム全体を作り直すことなく、暗号方式を柔軟に切り替え可能なアーキテクチャを準備しておくことが大切です。先ほど紹介した2つのユースケーのように、暗号化エンジンがサイロ化されているような状態では、こういったクリプト・アジリティの設計が非常に難しいと考えられます。
タレスが提供しているCipherTrust Managerの特徴は、鍵の主権の確立というところにあります。そして、属人的な、人間を信じるTrust（信頼）から、Proof（証明）への転換の推進。さらに、クリプト・アジリティを実現するソリューションになっています。
今日の私の話のまとめとしてお伝えしたい次世代のペイメント・セキュリティを支える3つの原則も、まさにこれと同じです。つまり、鍵の主権の確立、TrustからProofへ、クリプト・アジリティの組み込みの3つです。
最後に私から、経営層・セキュリティチームの皆様にぜひディスカッションしていただきたいこととして、自組織の現在地を確認するための3つの問いを提示したいと思います。
システムのマスター鍵は、誰が生成し、誰がアクセスでき、いつ破棄されたか、即座に証明が可能ですか？ 利用中のクラウド環境から撤退する際、データが完全に消去されたことを自社の統制下で保証できますか？ システム内に存在する暗号アルゴリズム・暗号鍵のリスト（クリプト・インベントリ）を即座に提示することは可能ですか？
これで私の講演を終わります。ご清聴ありがとうございました。
■お問い合わせ先
タレスDISジャパン株式会社
サイバーセキュリティプロダクト事業本部
URL: https://cpl.thalesgroup.com/ja
Mail: cpl.jpsales@thalesgroup.com
