Interop 2026 Cybertrust Day イベントレポート～前編～

当社ブログで定期的に最新の「脅威動向と代表的な攻撃」を解説する OSS のセキュリティ専門家面和毅氏が、先月行われた「Interop Tokyo 2026」（以下、Interop）を速報レポートします。

2026 年 6 月 12 日に Interop 2026 にて「Interop 2026 Cybertrust Day」と題してサイバートラストおよびパートナー企業から「信頼をどう担保し続けるか」というセキュリティ全般に関する企画講演が行われました。

当日は昼過ぎに雷雨となるような天候でしたが、足元が悪い中でも Interop に訪れる人たちは非常に多く、サイバートラストのセミナー会場も非常に賑わっておりました。今回、Interop の来場者は 3 日間で 14 万人を超え、サイバートラストのセミナー会場には 529 人がセミナーに足を運びました。

会場内にはサイバートラストとパートナー企業のロゴが随所にあしらわれ、一体感あふれる雰囲気に包まれていました。

以下では、各セッションの講演内容を、筆者の知識を交えて補足しながら纏めたいと思います。各講演動画は、本レポート末尾に記載の「オンデマンド配信」ページよりご覧いただけます。

1. 変わり続ける SSL 証明書の最新動向と " 失敗しない運用 " のポイント

最初の講演は、さくらインターネット株式会社の永岡侑起様による、SSL 証明書の最新動向と運用方法についてでした。

2025/04/11 の CA/Browser Forum（CA/ ブラウザフォーラム：電子証明書を発行する認証局や主要な Web ブラウザベンダーが参加する任意団体）における投票で「TLS ベースライン要件の改正」が採決されました。これにより、TLS の証明書の有効期限が 398 日間から 47 日間へと段階的に短縮されることになりました。

この TLS 証明書の有効期限短縮は、主にセキュリティ上の懸念からです。
証明書の有効期限を短くすることで以下のメリットがあります。

アジリティ：証明書の使用者が短い間隔でも更新できるような運用体制に切り替わるため、以前のHeartBleed のような OpenSSL の緊急脆弱性に対処できるような組織になる。
耐量子コンピュータ暗号などの最新技術への対応：耐量子コンピュータ暗号への対応などで、移行時には証明書を複数回変更しなくてはならない可能性があるが、これにも対応しやすくなる。
証明書に含まれる情報の信頼性確保：時間が経過すると担当者や所有者の情報など、証明書に含まれる情報の信頼性が徐々に低下することへの対応が可能。
失効処理の課題が解消される：ブラウザ側で OCSP を利用して CA に失効情報を確認しに行く際にタイムアウトとなった場合にアクセスを許可させる (Soft-fail)手法を取っていたが、MITM（中間者攻撃）に弱くなるため OCSP Must-Staple などの extension で解決する必要があった。また CRL はファイルサイズや適時性といった点で問題になっていた。しかし証明書の有効期間を短くすることで、これらのサービスに依存することがなくなる。

短縮のタイムラインは

2026/03/15 以降は、TLS 証明書の最長有効期間を 200 日とする。
2027/03/15 以降は、TLS 証明書の最長有効期間を 100 日とする。
2029/03/15 以降は、TLS 証明書の最長有効期間を 47 日とする。

となっていますが、いずれ証明書の有効期限が 47 日になることに備えて今から運用方法を変えていかなくてはなりません。

こちらのセッションでは、以上の動向とセキュリティ上の懸念点を纏めた上で、実際に運用していった際のデメリットと見直しの箇所を挙げていました。

講演資料から抜粋

運用者にとっては

約 30 日に一回程度で、更新のための購入手続きが必要になる
約 30 日に一回程度で、更新作業が必要になる

というところが大変になります。

1. 約 30 日に一回程度で、更新のための購入手続きが必要になる

購入手続きについては（期限のバッファーを考慮して）都度 30 日ごとに行うと、購入手続きに際してのワークフローなどが回らなくなってしまいます。そのため、現在はサブスクリプション化の検討もされており、認証局ベンダーに確認をする必要があるとのことでした。

2. 約 30 日に一回程度で、更新作業が必要になる

更新作業は手動の代わりに自動更新（ACME）の適用が考えられるそうです。ACME は Let's Encrypt で有名ですが、自動で証明書の更新を行ってくれるものになります。これには認証局側での対応も必要となり、JPRS などの認証局では ACME 対応のドメイン認証が提供されています。また、証明書利用者側では ACME できちんと更新が行われているかを確認するための監視／管理体制が必要になります。

以上のことから、証明書の有効期限が 47 日になることを見越すと、下記が必要になるとのことでした。

購入方法（サブスクリプション）や、ACME 対応しているかなどの認証局ベンダー検討
更新を手動対応で行うか、自動更新 (ACME) の導入をするのか検討
有償証明書 / 無料証明書 (Let's Encrypt) どちらを利用するか検討
ACME 対応を実施する場合には、更新を監視し失敗時の対応をする体制およびフローの構築

ちなみにサイバートラストから「SureHandsOn ACME」という、有償 SSL 証明書の発行・更新を自動化し、証明書の有効期間短縮における運用負荷と更新漏れリスクを軽減するソリューションが紹介されていました。

本講演のオンデマンド配信はこちら

https://www.cybertrust.co.jp/webinar/ctd26-s1.html

2.「不正アクセスの根本対策：デバイス証明書×多要素認証で実現する」入り口は厳格に、運用はシンプルに

次の講演は、株式会社インターナショナルシステムリサーチの市川聡太様による、デバイス証明書と多要素認証を使ったソリューションのお話でした。

昨今のサイバー脅威は巧妙化しており、フィッシングやランサムウェアのツールがパッケージ化・サブスク化（PaaS / RaaS）されていて、知識のない人間でも攻撃が可能になっているほか、2025 年 9 月に登場しアジアの中小企業を猛烈に標的にしているランサムグループ「The gentleman」の台頭、さらには人間の指示を最小限に抑えて自律的に認証情報を奪いにくる「AI エージェント」による攻撃など、境界防御が完全に崩壊しています。

さらに企業への不正アクセスの入り口としては、やはり「認証情報関連」を悪用したものが少なくありません。例えば Google( 旧 Mandiant) が毎年出しているM-Trends の 2026 年版の PDF（2025 年の脅威纏め）によると、ランサムウェア攻撃の初期段階（Initial Access）として、「Stolen Credential（盗まれた認証情報の利用）」が 9% と全体の 1 割になっています。この数字自体は 2024 年の 16% よりも下がっているのですが、代わりに「OAuth トークン」の侵害が増えており、2025 年にはパスワードの侵害よりもセッションクッキーやリフレッシュトークンの窃取を優先するようになっています。

従来のパスワード情報の窃取では、たとえパスワードが盗み出されたとしても OTP（ワンタイムパスワード）などを導入して MFA（多要素認証）にすることで回避が可能でした。OTP などはログイン時（認証フェーズ）のなりすましを防ぐものだからです。例えばパスワードのみのものは多要素認証としてパスワード＋OTP とすることで、認証フェーズで二重のログインが必要となっていました。ログインに成功すると、セッションクッキー（言ってみれば、通行手形）などが払い出されます。

これに対し、セッションクッキーやリフレッシュトークンが盗み出された場合には、話が変わってきます。先述のように、OTP などを組み合わせた MFA が効いてくるのはセッションクッキーの払出し前であり、MFA 後に払い出されたセッションクッキーが盗まれてしまった場合には、MFA ではどうしようもないからです。

この「セッションクッキーの盗難」に対抗する手段は色々ありますが代表的なものとして

FIDO2 を使用する（セッションクッキーの盗難自体を防ぐ）
デバイス証明書を使ってデバイス認証を行う（もう一つの認証を付け加える）

などがあります。

1. FIDO2 を使用する（セッションクッキーの盗難自体を防ぐ）

FIDO2 は、モバイルおよびデスクトップ環境の多要素パスワードレス認証のオープンな標準です。従来の MFA では以下のように MITM などの攻撃の問題があります。

攻撃者が用意した偽のログイン画面などに誘導されて ID・パスワード・MFA のコード（OTP など）を入力すると、攻撃者はその情報を本物のサイトに転送します。
本物のサイトは「正しいユーザーが MFA までをクリアしている」と勘違いしてセッションクッキーを発行しています。
攻撃者はそのセッションクッキーを横取りし、自分のブラウザに設定してログイン状態をのっとってしまいます。

一方で、FIDO2 の場合には

FIDO2 を使ったログイン機能を提供している、本物の認証サイト（例えば id.hogehoge.com）に接続した時点で、本物の認証サイトの URL を元にして認証器（スマホやセキュリティキー）が公開鍵・秘密鍵のペアを作ります。
公開鍵は id.hogehoge.com に登録されます。
以降、FIDO2 を使った認証の際には、認証サイトから送られてくるチャレンジに対して、ブラウザが「チャレンジ＋ブラウザ上で認識している Origin( プロトコル＋ホスト名＋ポート番号）」を用意し、認証器が秘密鍵で署名して認証サイト (id.hogehoge.com) に送ります。
本物の認証サーバー (id.hogehoge.com) は署名を公開鍵で検証し、それが Origin 含めて正しければ、セッションクッキーを発行します。

これにより、攻撃者が用意した偽のログイン画面に接続した場合には、偽のログインで FIDO2 をサポートしていなければその時点で偽物とバレます。
また攻撃者が用意した偽のログイン画面で FIDO2 をサポートしていて MITM を試みた場合には、上の「チャレンジ＋Origin」を秘密鍵で署名したものを本物の認証サーバーに転送しても、その Origin と異なる場所からのリクエストとなるため、MITM が失敗します。このように、FIDO2 は MITM などの「セッションクッキーの盗難」のハードルを上げるものになります。

ただし、仮に FIDO2 で認証を行ったとしても、やはりセッションクッキーが発行されるため、セッションクッキーが盗まれた場合には不正な認証をされてしまいます。これを防ぐために、次の「デバイス認証」と組み合わせることになります。

2. デバイス証明書を使ってデバイス認証を行う（もう一つの認証を付け加える）

デバイス証明書は、認証サーバー側でのもう一つの鍵になります。仕組みとしては以下のようになります。

企業があらかじめ管理している端末（社給 PC やスマートフォン）に対してのみ、固有の「デバイス証明書」をインストールしておきます。
認証サーバーでは、「セッションクッキーの正当性」と「その端末に正しいデバイス証明書が入っているか」をチェックします。
「端末のデバイス証明書」が不正なものであった場合には、たとえセッションクッキーが正当だったとしてもアクセスが拒否されます。

この「デバイス認証」を用いることで、たとえセッションクッキーが盗み出されたとしても、不正な認証を防ぐことが可能になります。

このセッションでは、これらの知識を踏まえ、ゼロトラストの核となる「ID とデバイス」の話を中心に、サイバートラストのデバイス証明書「デバイス ID」を用いた「CloudGate UNO」による認証を説明していました。特に 2019 年から FIDO2 に対応したパスキー認証を提供していると言うことで、長期間にわたる実績が信頼性をあげています。

また、顧客事例として馬淵建設株式会社様の事例をあげ、どのように導入を進めていったかを紹介していました。中でも段階的な移行ではなく、導入初日からパスキーを標準化することで、「パスワード認証に慣れさせて移行させる」場合に起きるユーザーの抵抗感を最小限に抑えた、と言うところが非常に考えられた策となっていました。
さらに面白かった点としては、この移行を「全員が必ず受ける健康診断の待ち時間（約 10 分）」を利用して、スマホのキッティング（デバイス証明書入れ替えと Face ID 設定）を強制的に完了させた、という工夫です。これによってユーザーを確実に移行させることができた、ということでした。