SSLエラーがSSLだけの問題ではない場合：TIBCO Masheryの障害を深掘り

インターネットスタック全体のレイヤー監視が、障害を未然に防止する

2025年1月16日
著者: Wasil Banday, Moiz Khan
翻訳: 永 香奈子

この記事は米Catchpoint Systems社のブログ記事「When SSL Issues aren’t just about SSL: A deep dive into the TIBCO Mashery outage」の翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。

2024年10月1日、世界的に有名なブランドが活用する企業向けAPI管理プラットフォーム「TIBCO Mashery」で重大な障害が発生しました。
東部標準時午前7時10分頃、ユーザは一見すると単純なSSL接続エラーに遭遇し始めました。

当社のインターネットパフォーマンス監視（IPM）ツールの一つである「Internet Sonar」は、このインシデントを正確に捕捉しました。
他のソリューションでは見逃された可能性があるが、Internet SonarはDNS、SSL、応答時間、「エンドユーザ」ネットワークからの到達可能性を含むインターネットスタックのすべてのレイヤーを監視しているため、問題を特定することができました。
この包括的な監視により、根本原因はSSL障害ではなく、主要サービスへのアクセスに影響を及ぼすDNSの誤設定であることが判明しました。

何が起こったのか？

ブラウザに表示されたSSLエラー（以下の画像に示されている）によると、証明書が pantheonsite.io を指しています。

Catchpointプラットフォームの詳細を確認したところ、同じ問題が観測された。
developer.mashery.com への接続を試みた際、DNSの名前解決は成功したものの、接続先のIPがMasheryドメインを示していませんでした。
一部の地域では依然として接続が可能で、正しい証明書が返されていました。

正しいSSLハンドシェイクでは、mashery.comがコモンネーム（CN）またはサブジェクト代替名（SAN）として表示されるはずです。
以下のスクリーンショットで確認できます。

本件はSSLエラーに関連していたため、SSLテストを実施したところ、CN/SANが一致しなかったためにサイトへの接続に失敗したことが確認されました。

インシデントの理解

当初、ユーザはSSLエラーに遭遇しました。
これは、接続が期待されるAWS ELBのIPアドレス（54.160.170.229、54.235.15.197、44.211.103.199）ではなく、PantheonのIPアドレス（23.185.0.3）に向けられたために発生しました。
この誤ったルーティングは、"ns65.worldnic.com" および "ns66.worldnic.com" に接続する再帰的リゾルバが原因で発生しました。

対照的に、8.8.8.8（Google）や1.1.1.1（Cloudflare）などの代替DNSリゾルバは、正しくAWSへトラフィックを誘導していました。
以下のDNSエクスペリエンステストの記録で、同様の状況を確認できます。

このチャートは、正しく動作していた場合の状態を示しています（正常に動作していた一部の都市）。

Query using Google DNS Resolver –8.8.8.8

この問題は地理的な場所によって異なる形で発生しました。これは、おそらくDNSレコードの提供方法に影響を与えるGeo-IPベースの設定が原因です。
このような変動性は、グローバルな監視戦略の重要性を強調しています。
クラウドインスタンスだけに依存していたのでは、この問題の全容を把握することはできませんでした。

地域ごとのユーザ体験を正確に理解するためには、実際のネットワークに近づくことが不可欠です。
時間が経過するにつれ、"101 Not Implemented"、"Query Refused"、"Server Failure" などのDNSエラーが世界各地で発生しました。
これは、システム内で継続的な変更が行われていたことを示しています。
CatchpointのDNS監視により、これらの問題が検出され、約4.5時間後、正しいネームサーバーとAレコードの伝播が進むにつれて、問題が解消され始めました。

実世界への影響

Masheryを利用してシームレスなAPI管理を行っているユーザにとって、このインシデントは深刻な影響を及ぼしました。
リクエストのルーティングが一貫せず、一部は意図されたAWS ELBではなくFastlyのIPに到達するケースもあり、サービスの中断を引き起こす可能性がありました。
この事象は、インターネットインフラの脆弱性を浮き彫りにしました。わずかなDNSの誤設定が、即座にユーザ体験やサービスの可用性に影響を与える可能性があることを示しています。

当初は単なるSSLエラーのように見えたものの、問題の調査が進むにつれて、DNSの信頼性、SSL設定、およびCDNパフォーマンスに関する重大な弱点が明らかになりました。
このインシデントは、インターネットが極めて相互依存的であることを改めて示しています。
また、一つの地域で発生した問題が、他の地域では影響を受けない場合もあります。

そのため、グローバルな可視性と積極的な監視が不可欠であることが再認識されました。

Masheryの障害から学ぶこと

Masheryの障害は、重要な教訓を示しています。
SSLエラーは、しばしば氷山の一角にすぎません。
実際の問題はより深い部分にあり、今回のケースではDNSの誤設定が原因でした。

DNSが適切に設定・監視されていなければ、システム全体が機能不全に陥る可能性があり、一見すると単純なSSLエラーが、より大規模な問題へと発展してしまいます。
このインシデントは警鐘となる出来事です。
インターネットの相互接続性の高さを考えると、DNSのような単一点の障害が、世界中のサービスに影響を及ぼすことがあります。

さらに、地理的な違いが問題の検出と解決をより困難にします。そのため、グローバルな監視戦略が不可欠です。
インターネットの脆弱性に対処するためには、DNSからSSL、さらにはその先のレイヤーに至るまで、インターネットスタック全体の可視性を確保することが必要です。

インターネットスタック全体を監視し、障害を未然に防ぐ

このインシデントは、DNS、SSL、CDN、サードパーティサービスといったインターネットスタックのあらゆるレイヤーを監視する必要性を強調しています。
Internet Sonar のような強力なIPM（Internet Performance Monitoring）ツールを活用することで、企業はこれらの依存関係全体にわたる回復力を確保できます。

Internet Sonarが提供する機能

比類のないグローバルおよび地域レベルの可視性

CatchpointのGlobal Observability Network を活用し、100か国以上、300以上のプロバイダ、2700以上のノードからの監視を実現。さらに、新たなノードが常に追加され続けています。

数百種類の主要なインターネットサービスを監視

• インターネットインフラ：CDN、DNS、クラウド、ISP
• SaaS：メール、SaaS、UCaaS、SECaaS
• マーテック（MarTech）：広告配信、アナリティクス、動画配信

リアルタイム通知とシームレスな統合

メール通知 や Webhook/APIアクセス によるアラートを提供し、あらゆるアプリケーションへの統合が容易。

AI駆動の自動データ相関

アクティブモニタリングと連携し、リアルタイムのステータス情報をシンプルに提供。

今日はMasheryの問題でしたが、明日はあなたのサービスかもしれません。
強力で継続的な監視の必要性は、決して過小評価できません。
デモハブでInternet Sonarの実際の動作を確認するか、詳細についてお問い合わせください。