Zendesk は旧サポートデータを顧客信頼の説明責任の試金石とした

概要

• Zendesk の更新された FAQ によると、同社は2019年に、2016年11月より前にアクティベートされた Support および Chat の顧客アカウントに関するセキュリティ問題について警告を受け、それ以前に顧客アカウント情報が不正アクセスされていたとしている。
• 中心的な説明責任の問いはこれだ：サポートデータベースの保持、認証情報やトークンの露出、顧客通知のタイミング、テナントのセグメンテーション、監査再構築、そしてチケット内容の範囲が限定されていたことの証明について、誰が実質的な管理権限を持っていたのか？
• 初期の公開報道では、影響を受けたのは約10,000の Support および Chat アカウントとされていた。後の Zendesk の FAQ では約15,000アカウントと特定し、約7,000の顧客アカウントについて特定の認証情報がアクセスされたと述べている。
• Zendesk をサポート、チャット、ヘルプセンター、統合機能、顧客業務に利用していた顧客は、古いサポートのメタデータが依然としてエージェント、エンドユーザー、統合機能、証明書、あるいは下流の顧客信頼を露出させる可能性があるかどうかを判断しなければならなかった。
• この公開記録は、データ保持、認証、通知、証拠の境界に関する高い確度の説明責任の結論を支持する。しかし、すべてのテナント、すべてのチケット、すべてのアプリ認証情報、すべての TLS キー、あるいはすべての下流の顧客判断について、私的な事実を創作することは支持しない。

証拠記録とその使用方法

本記事は、公開記録を単一の完全な説明としてではなく、層状の証拠として扱う。企業の記録は、Zendesk が公に述べたことに使用される。セキュリティ報道、開発者ドキュメント、法的資料、プライバシーガイダンス、脆弱性技術リファレンス、標準資料は、時系列、管理責任、影響を受けた当事者への影響を枠組みづけるために使用される。この分析は、公開記録が示していない私的事実の証明として二次報道を扱うものではない。

説明責任の枠組みは非難よりも狭く、古いデータベースよりも広い

Zendesk が旧サポートデータを顧客信頼の説明責任の試金石としたのは、このインシデントが単なる過去の侵害通知ではなかったからだ。公開記録は、2016年11月より前にアクティベートされたアカウントに関わるセキュリティ問題が2019年に発見・伝達され、その後の Zendesk FAQ 更新で個人情報、ソルト付きハッシュ化パスワード、特定の認証情報、アプリ構成設定、少数の TLS 証明書項目が特定されたことを示している。同じ FAQ は、Zendesk はこのインシデントに関連してチケットデータがアクセスされた証拠は見つからなかったと述べている。この組み合わせが実践的な疑問を生んだ。関連するアカウント、トライアル、アプリ、証明書が最初に作成されてから何年も経った後、古いサポートシステムに何が依然として価値を保っていたのか？

非難はその問いに対してあまりにも鈍感だ。説明責任は、各段階でリスクを低減するための権限、証拠、ツール、義務を誰が持っていたかを問う。Zendesk はサポートおよびチャットのアカウントデータベース、レガシー保持の選択、アプリケーション構成記録、アップロードされた証明書の処理、パスワードローテーション計画、顧客通知、公開 FAQ を管理していた。顧客は自社のエージェント、エンドユーザー、インストール済みアプリ、統合認証情報、TLS 証明書の置き換え、規制分析、ローカルのチケット保持ルールを管理していた。サードパーティのアプリプロバイダーは、自社の認証フローの一部を管理していた。規制当局は現地法に基づく正式な判断を管理していた。各当事者に役割があったが、侵害の境界をサービス側から可視化できたのは Zendesk だけだった。

その境界がこのケースの核心である。サポートプラットフォームは、企業とその顧客との関係に近い位置にある。侵害がサポートプラットフォームのアカウント層に影響し、チケット本体には影響しなかったとしても、顧客はエージェント、エンドユーザー、アプリ、証明書、ヘルプセンターの信頼がリスクにさらされるかどうかを問わなければならない。プロバイダーの義務は、その答えを曖昧ではなく、利用可能な形で提供することだ。

公開記録が確立するもの

Zendesk の更新された FAQ は、いくつかの確固たる点を確立している。同社は、2016年11月より前にアクティベートされた Support および Chat 製品と顧客アカウントに影響した可能性があるセキュリティ問題について、第三者から警告を受けたと述べた。Zendesk のセキュリティチームと外部のフォレンジック専門家が調査したとしている。2016年11月より前に、少数の顧客に属する情報がアクセスされたと述べた。現在の FAQ では、約15,000の Support および Chat アカウント（期限切れトライアルやアクティブでなくなったアカウントを含む）のアカウント情報が不正アクセスされたと特定している。また、露出したデータベースには、エージェントとエンドユーザーのメールアドレス、ユーザー名、電話番号、そしてソルト付きハッシュ化パスワードが含まれており、それらのパスワードがインシデントに関連して Zendesk サービスへのアクセスに使用された証拠はないと述べている。

さらに FAQ は第二の層を加えている。Zendesk は、約7,000の顧客アカウント（期限切れトライアルや非アクティブなアカウントを含む）について、特定の認証情報がアクセスされたと述べた。これには、顧客提供の TLS 暗号化キーや、マーケットプレイスまたはプライベートアプリのアプリ構成設定が含まれ、これらのアプリがサードパーティサービスに対して認証するために使用する統合キーも含まれる可能性がある。Zendesk は、特定の顧客に対して、アプリ認証情報のローテーション、まだ有効なアップロード済み証明書の置き換え、および2016年11月以前に使用された他の認証資料のローテーションを検討するよう助言した。また、このインシデントに関連してチケットデータがアクセスされた証拠は見つからなかったと述べている。

二次報道は、インシデントの最初の公的な輪郭を捉えている。CyberScoop、SecurityWeek、BleepingComputer は2019年10月に、Zendesk が約10,000のアカウントに影響を与えた過去の侵害を開示したと報じた。その数の違いは、一方の記録を選んでもう一方を捨てる理由にはならない。むしろ、インシデントを段階的に読むべき理由である。公的な理解は、初期の10,000アカウントという枠組みから、後の FAQ による追加のアカウントおよび認証情報の詳細へと移行した。

公表数の不一致それ自体が説明責任の証拠である

本記事の宣言では、Zendesk が2019年に、2016年のインシデントで約10,000の Support および Chat アカウントに関連する不正アクセスを特定したと述べた公開記録を使用している。これが初期の公的な枠組みだった。Zendesk の現在の FAQ では約15,000アカウントとされ、さらに約7,000の顧客アカウントについて特定の認証情報が対象内とされている。両方の事実が重要である。初期の数値は、顧客や報道機関が最初に何を材料にしなければならなかったかを示す。更新された数値は、公開記録が後に、より詳細で複雑になったことを示す。

段階的な侵害記録は本質的に疑わしいものではない。調査では、ログの精査、休眠アカウントの照合、重複の削除、データカテゴリの分離に伴い、しばしば数が変わる。説明責任の問題は、顧客がその違いを理解できるかどうかである。Support と Chat のアカウントの数は、認証情報を持つ顧客の数と同じではない。トライアルアカウントはアクティブなエンタープライズテナントとは異なる。パスワードハッシュは OAuth トークンとは異なる。TLS キーはチケット内容とは異なる。もし公開記録がこれらのすべての面を一つの数字で記述するなら、顧客は誤った判断を下すだろう。

Zendesk の FAQ は、アカウント情報、認証情報、パスワードローテーション、アプリ認証情報のローテーション、証明書の置き換え、製品への影響、チケットデータの証拠を分離することで助けとなっている。すべての数値とデータクラスを一つの公的な年表で容易に調整できれば、記録はさらに強固となるだろう。教訓は、初期の数値がすべて最終版でなければならないということではない。教訓は、それぞれの数の理由が明確でなければならないということだ。

信頼の対象はサポートリレーションシップだった

このケースの信頼対象はサポートリレーションシップだった。Zendesk は単なるログインページではない。エージェント、エンドユーザー、チケット、チャット、ヘルプセンター、アプリ、統合機能が、企業が顧客リレーションシップを管理するのを助けるカスタマーサポート環境である。サポートシステムには、名前、メールアドレス、電話番号、製品の問題、アカウント識別子、トラブルシューティングの詳細、添付ファイル、そして企業と顧客のリレーションシップの運用状態が含まれうる。チケット内容へのアクセスが証明されなかったとしても、周辺のサポートアカウントデータは依然として重要でありうる。

だからこそ、このインシデントは古いユーザーテーブル以上の重みを持った。エージェントの名前と連絡先情報は、サポートスタッフを標的にするのに利用できる。エンドユーザーの名前と連絡先情報は、Zendesk の顧客の顧客を標的にするのに利用できる。ソルト付きハッシュ化パスワードは、リセット義務と再利用の懸念を生む。アプリ構成設定と統合キーは、サポートシステムを他のシステムに接続する。TLS 証明書資料は、顧客ブランドのヘルプセンターに影響しうる。各項目は、サポートリレーションシップの異なる部分に触れる。

また、信頼の対象は、顧客がチケットデータの範囲が限定されていることの証拠を必要とした理由を説明する。チケットデータがアクセスされなかった場合、顧客の作業負荷は依然として深刻だが、認証情報、アプリ、証明書、連絡先、通知分析とより狭まる。もしチケット本体がアクセスされた場合、作業負荷はエンドユーザー通知、製品の機密性、添付ファイル、サービス履歴、規制対象データへと拡大しうる。したがって、Zendesk がチケットデータへのアクセスの証拠は見つからなかったとする公的声明は、重要な境界主張だった。

レガシー保持が古いアカウントを運用上現在のものにした

インシデントの古さこそがポイントである。2016年11月より前にアクティベートされたアカウントは、古い記録が運用上の意味を持ち続ける可能性があるため、2019年においても依然として関係があった。Zendesk の FAQ は、期限切れのトライアルアカウントやもはやアクティブでないアカウントに明示的に言及している。これらのカテゴリは重要だ。顧客は、非アクティブまたはトライアルの記録にはほとんど価値がないと想定するかもしれないからだ。サポートプラットフォームでは、古い記録にもユーザー名、メールアドレス、電話番号、ハッシュ化パスワード、アプリ設定、または証明書資料が残りうる。休眠状態は一部のリスクを低減するが、データを消去するわけではない。

保持の説明責任は、単にプライバシーの問題にとどまらない。それはセキュリティと顧客の作業負荷の問題でもある。古いアカウントがデータベースに残っている場合、プロバイダーは、なぜそれらが保持されているのか、どのように保護されているのか、いつ削除または非識別化されるのか、そしてもしアクセスされた場合に顧客が何をすべきかを知っていなければならない。GDPR 第5条のデータ最小化と保存制限の用語は、保持を単なる保存習慣としてではなく管理義務として位置づけるため、ここで有用である。NIST のサイバーセキュリティフレームワークは、識別・保護・検知・対応・復旧という、より広範な規律を追加する。

公開記録は、2016年の Zendesk のすべての保持ルールやその後のすべての変更を示してはいない。Zendesk は2016年以降に投資を行い、機密性の高い個人データ保護の追加や、ログとデータ保持の GDPR 準拠への調整を含むと述べた。この声明は有用だが、顧客は依然としてインシデント固有の証拠を必要とした：どの古い記録が残っており、どれがアクティブで、どれが非アクティブで、どれが認証資料を保持しており、どのようなローテーションや置き換えが必要か、というものだ。

パスワードハッシュは顧客の行動計画を必要とした

Zendesk の FAQ は、エージェントとエンドユーザーのパスワードはソルト付きハッシュ化されており、インシデントに関連してそれらのパスワードが Zendesk サービスへのアクセスに使用された証拠は見つからなかったと述べている。これは平文パスワード盗難の記録よりはましだが、何もしなくて良いという記録ではない。ソルト付きハッシュ化パスワードは、ハッシュ化手法、ワークファクター、ユーザーのパスワードの品質、攻撃者のリソース次第で、依然としてオフライン攻撃を受けうる。ユーザーが Zendesk の外でパスワードを再利用していた場合、たとえ Zendesk 自体が関連するアクセスを認識していなくても、コピーされた検証子が下流のリスクを生み出しうる。

Zendesk のパスワードローテーション計画は、そのリスククラスに対処した。FAQ では、ローテーションは、2016年11月1日より前に作成され、Zendesk がその日以降にユーザーがパスワードを変更したことを特定できず、かつそのユーザーがシングルサインオンを使用していなかった特定のエージェントとエンドユーザーに適用されたと述べている。またローテーションは、Support と認証を共有する製品（Guide、Talk、Explore を含む）にも影響した。これは、誰が行動をとらなければならず、なぜかを顧客に伝えるため、説明責任の詳細である。

NIST デジタルアイデンティティガイダンスと OWASP パスワードストレージガイダンスは、ここで管理クラスを枠組みづけるために使用される。正確なプライベートパスワードアーキテクチャは公開記録には見えず、本記事はそれを創作しない。関連するポイントは、パスワード検証子を保持するプロバイダーは、盗難が可能であると想定し、オフライン攻撃から検証子を保護し、正しいユーザーに届くリセットまたはローテーション計画を、シングルサインオンを使用する顧客を混乱させることなく実行しなければならないということだ。

認証情報が、このケースをパスワードリセット以上に拡大した

Zendesk の FAQ で最も重要な更新は、認証情報の層である。FAQ では、約7,000の顧客アカウントについて特定の認証情報がアクセスされたと述べている。列挙された項目には、顧客提供の TLS 暗号化キーや、マーケットプレイスまたはプライベートアプリのアプリ構成設定が含まれ、これらのアプリがサードパーティサービスへの認証に使用する統合キーも含まれる可能性がある。この文言は、ケースを通常のパスワードローテーションを超えたものにする。

アプリ認証情報と TLS 資料は、異なる顧客の義務を生む。パスワードリセットは、多くの場合、各ユーザーが次回ログイン時に対応できる。アプリ認証情報は Zendesk を CRM、請求、データウェアハウス、メッセージング、ワークフロー、アイデンティティシステムに接続しうる。TLS 秘密鍵は、顧客ブランドのヘルプセンターやホストマッピングに影響しうる。それらの義務を担う人々は、日常的に Zendesk を使用するエージェントとは限らない。彼らはセキュリティエンジニア、アプリケーションオーナー、ウェブ管理者、またはベンダー管理チームかもしれない。

Zendesk は、2016年11月1日より前にマーケットプレイスまたはプライベートアプリをインストールし、インストール時に認証情報を保存した顧客に対して、関連するアプリの認証情報をローテーションするよう助言した。また、その日より前にまだ有効な TLS 証明書をアップロードした顧客に対して、それを置き換えて古い証明書を失効させるよう助言した。これらの指示は具体的であり、インシデントがアカウントパスワードのローテーションだけで片付けられなかった理由を示している。

アプリと統合機能がサポートを接続されたシステムに変えた

Zendesk の開発者向けドキュメントは、なぜアプリ構成が重要かを示している。Apps API は Zendesk アプリを管理しやり取りすることができ、ドキュメントには、これらのエンドポイントからのアクションは影響を受ける Support アカウントの監査ログに記録されると記されている。アプリリクエストのドキュメントは、アプリが REST API 呼び出しやその他の HTTP リクエストを行え、サードパーティサービスの OAuth アクセストークンを処理しうることを説明している。API セキュリティドキュメントは、リクエストを認可する方法として API トークンと OAuth トークンを特定している。OAuth トークンのドキュメントは、管理者にトークンのプロパティを確認する方法を提供する。

これらの現在の文書は、2016年のすべてのアプリ構成の証明ではない。それらは管理面を識別するために使用される。Zendesk アプリは単なる視覚的なアドオンではない。サポートワークスペースを他のシステムに接続し、認証資料を保持または使用することができる。古いアプリ設定がアクセスされた場合、顧客はどのアプリか、どの認証情報か、どの日付か、どの宛先か、そして Zendesk の外でローテーションが必要かを知る必要がある。

これは繰り返し発生するクラウドサービスの問題である。顧客はプラットフォームを購入し、やがて統合機能を追加して、そのプラットフォームが運用ハブになる。侵害がそのハブに影響するとき、プロバイダーは顧客が接続されたシステムをマップするのを助けなければならない。そのマップなしでは、顧客は、多くの場合インストールから数年経った後で、時間的プレッシャーの下、アプリを一つひとつ検査しなければならない。

TLS 証明書資料は別個の証明負担を生んだ

TLS 証明書資料は通常のアカウントデータではない。顧客がブランドのヘルプセンターのために証明書と秘密鍵をアップロードしていた場合、その資料へのアクセスは、ドメインに対する管理を証明する能力や暗号化されたトラフィックを保護する能力に影響を与える可能性がある。Zendesk の FAQ は、少数の顧客グループの TLS 証明書がアクセスされたが、FAQ 公表時点でそれらのほとんどが期限切れだったと特定している。同社は、2016年11月1日より前にアップロードされまだ有効な証明書を持つ顧客に対して、新しい証明書のアップロードと古い証明書の失効を助言した。

Zendesk の証明書アップロード準備サポートガイダンスは、顧客が証明書ファイルを特定し、バンドルを作成し、キーファイルを取得する必要があるかもしれないと説明している。このドキュメントは、証明書の取り扱いがいかにセンシティブかを示している：アップロードプロセスにはプライベートキー資料が含まれうる。したがって、インシデントは証明書のメタデータと証明書の秘密、期限切れ証明書と有効な証明書、Zendesk 管理の証明書オプションを使用した顧客と独自の資料をアップロードした顧客を区別しなければならなかった。

公開記録は TLS キーの悪用を証明しない。しかし、特定の顧客クラスに対する顧客の行動義務を確立する。説明責任の教訓は、顧客がアップロードした暗号化資料には、別個のインベントリ、保持ルール、通知経路が必要だということだ。それは一般的なサポートアカウント侵害メッセージの中に埋もれさせてはならない。

チケット内容は、顧客が最も必要とした境界だった

Zendesk の FAQ は、インシデントに関連してチケットデータがアクセスされた証拠は見つからなかったと述べている。また、もし Zendesk が顧客のサービスデータ（個人情報を含む）が侵害されたと判断した場合、その判断を顧客に個別に伝達したとも述べている。Zendesk 顧客にとって、その境界は中心的なものだった。チケット内容には、顧客に応じて、苦情、アカウント履歴、製品の問題、添付ファイル、トラブルシューティングの詳細、不正報告、健康に関する言及、学生記録、人事の問い合わせ、支払い問題、または本人確認情報が含まれうる。

チケット内容がそれほどセンシティブでありうるため、証拠なしという声明は有用だが、完全な答えではない。顧客は、どのログが精査されたか、どのデータベーステーブルが分離されたか、添付ファイルが範囲内だったか、Chat のトランスクリプトが Support チケットと異なっていたか、非アクティブアカウントがアクティブなテナントにどのようにマッピングされたか、といった証拠のクラスを理解する必要があった。公開 FAQ は結論を述べ、外部のフォレンジックが関与したとしている。完全な証拠の道筋は示しておらず、センシティブな詳細すべてを公開できないのももっともだ。

説明責任の基準は、顧客が自ら法的・運用上の決定を下せるだけの十分な構造を提供することである。チケットデータの範囲が限定されていれば、顧客は不必要なエンドユーザー通知を避けられるかもしれない。チケットデータが不確かであれば、規制上の閾値を評価する必要があるかもしれない。サポートプラットフォームプロバイダーは、サービスデータの管理者はプロバイダーではなく顧客である可能性があるため、その不確実性を迅速に低減しなければならない。

管理者と処理者の役割が通知の作業負荷を変えた

Zendesk の FAQ は、サービスデータについては顧客をデータ管理者、Zendesk サービスを実行する際には Zendesk をデータ処理者と明確に位置付けている。この区別は、なぜ顧客が単に Zendesk があらゆる規制上の判断を下すのを待てなかったのかを説明するため、重要である。GDPR 第33条の下で、管理者は個人データ侵害が法的閾値を満たす場合、監督当局への通知義務を負う可能性がある。Zendesk の FAQ は、顧客がその判断を行うのを支援するために、自らが有する情報を利用可能にすると伝えた。

これは共有される法的役割についての公正な説明だが、処理者に高い証拠負担を生じさせる。顧客は、どのデータカテゴリが影響を受けたか、サービスデータがアクセスされたかどうか、どのエージェントとエンドユーザーが範囲内か、認証資料が他のシステムに影響を与える可能性があるかどうかを知らずに、規制当局やエンドユーザーに通知するかどうかを決定することはできない。プロバイダーがこれらの事実を握り、曖昧にまたはゆっくりとしか公開しないなら、顧客は解決に必要な証拠のないまま、法的な不確実性を抱えることになる。

Zendesk のデータ処理契約と GDPR 関連資料は、一般的な法的文脈を提供する。2016年のインシデント記録は、その文脈の運用版を示している。顧客は自社のサービスデータに関する決定について法的責任を負うかもしれないが、その決定を行うために Zendesk の調査記録に依存する。だからこそ、証拠の共有は単なる礼儀ではない。それは処理者の説明責任機能の一部なのである。

テナントセグメンテーションは目に見えない保証の層だった

テナントセグメンテーションは、プラットフォーム侵害が限定的にとどまるかどうかを決定づける。Zendesk の FAQ は、影響を受けたアカウントは少数の顧客であり、サービスデータが侵害されたと判断された顧客には個別に通知したと述べている。また、Support と Chat 以外の製品には影響があった証拠はないとしているが、パスワードローテーションは Support と認証を共有する製品に及んだ。これらの声明は、顧客が独自に検証できないセグメンテーションの証拠に依存している。

サポートプラットフォームにおけるセグメンテーションには、データベースの分離以上のものが含まれる。製品の境界、認証レルム、アプリ設定、顧客アップロードの証明書、チケットストア、期限切れトライアル、非アクティブアカウント、共有サービス、ログ、および Zendesk スタッフが使用するサポートツールが含まれる。セグメンテーションが強固で文書化されていれば、プロバイダーは、たとえアカウントメタデータが影響を受けても、なぜチケットデータは範囲外だったのかを顧客に伝えることができる。セグメンテーションが脆弱であれば、古い記録が予期せぬ影響範囲を生み出しうる。

公開記録は Zendesk の完全なテナントアーキテクチャを明らかにしない。それは普通のことだ。しかし同社は、影響を受けたアカウントの日付、影響を受けた製品名、データカテゴリ、パスワードローテーション条件、認証情報カテゴリ、チケットデータの境界、顧客固有の通知など、行動に移せるだけの具体的な顧客向け結論を提供する必要があった。これらが、プライベートなセグメンテーション証拠の公的な出力である。

監査再構築は回復の一部であり、背景作業ではなかった

Zendesk は、外部のフォレンジック専門家を雇い、データセキュリティ対応チームを起動し、法執行機関と適切なグローバル規制当局に通知し、調査を継続したと述べた。これらは標準的なインシデント対応アクションだが、このケースでは特別な機能を果たした。それは、過去の出来事を再構築することだ。2016年のインシデントが2019年に公に開示されたとき、同社はログ、アカウント状態、データベース記録、アプリのインストール日付、証明書のアップロード日付、パスワード変更履歴、製品境界、顧客ステータスをさかのぼって作業しなければならなかった。

その再構築は、リアルタイムの封じ込めよりも難しい。ログは消えているかもしれない。アカウントは非アクティブかもしれない。トライアルアカウントにはアクティブな所有者がいないかもしれない。アプリの認証情報は置き換えられているか、あるいはビジネスプロセスで静かに使用され続けているかもしれない。TLS 証明書は期限切れ、更新、または置き換えられているかもしれない。アプリをインストールした従業員は退職しているかもしれない。顧客の法的連絡先が変わっているかもしれない。これらの通常の事実が、古い侵害を運用上現在のものにする。

したがって、記録は監査再構築を背景のフォレンジック詳細としてではなく、回復の証拠として扱うべきである。顧客は、どの日付の区切りが重要か、どのインストール日付がアクションをトリガーするか、どの認証情報クラスがローテーションを必要とするか、どの記録を Zendesk が十分な確信をもって除外できたかを知る必要があった。強固な再構築記録は、過小反応も不必要な過剰反応も防ぐ。

現在の信頼記録は有用な文脈だが、遡及的な証明ではない

Zendesk の Trust Center は、現在のセキュリティ、コンプライアンス、暗号化、データセンター、保証の実践を説明している。データ処理契約は、サービスデータと保護措置に関する現在の法的枠組みを説明している。開発者ドキュメントは、現在の API 認証、アプリ管理、OAuth トークンの可視性、アプリリクエストパターンを説明している。これらの記録は、今日 Zendesk を評価する際に顧客が使用する管理語彙を示しているため有用である。

これらを2016年のすべての管理の遡及的証明と読むべきではない。現在の Trust Center は、レガシーデータベースにどの記録が存在したかを証明しない。現在の API トークンページは、2016年にどのトークンや設定が存在したかを証明しない。現在の証明書ヘルプページは、インシデント期間中のすべての顧客アップロードキー処理の詳細を証明しない。正しい使用法は、より狭く、より規律あるものだ：現在の文書は、2016/2019インシデントを意味あるものにする管理の種類と顧客責任を特定する。

この区別は二つのよくある誤りを防ぐ。一つ目は、実際の信頼面を挙げている現在の企業記録を無視すること。二つ目は、現在の信頼に関する文言を過去の侵害への完全な答えとして扱うこと。成熟した読み方は、インシデントの FAQ を出来事に使用し、現在の文書を顧客が検討すべき管理クラスを理解するために使用する。

公開記録が証明しないもの

慎重な記事は、知らないことを明記すべきだ。公開記録は、2016年に使用された正確な最初の技術的経路を示していない。影響を受けたすべてのテーブル、すべてのログエントリ、すべてのテナント、すべてのアプリインストール、すべての証明書、またはすべての顧客とのコミュニケーションを明らかにしていない。すべてのハッシュ化パスワードがクラックされたことを証明しない。アプリ認証情報がサードパーティサービスに対して使用されたことを証明しない。TLS キーが悪用されたことを証明しない。チケットデータがアクセスされたことを証明しない。その後のすべてのセキュリティ管理やすべての規制当局とのやり取りを示していない。

これらの限界は分析の弱点ではない。それらは説明責任の表面である。顧客は、何をローテーションし、何を置き換え、エージェントやエンドユーザーに何を伝え、プライバシー法の下で何を評価し、チケット内容が限定されていたかどうかを判断するのに十分な証拠を必要とした。Zendesk は、サービス側の事実について不確実性を低減する上で、どの個別の顧客よりも有利な立場にあった。

したがって、最も強力な発見は限定的である。Zendesk は、古いサポートアカウントのインシデント、パスワードローテーション、アプリ認証情報のレビュー、証明書の置き換え、顧客固有の通知、チケット境界の保証を管理しなければならなかった。公開記録はこれらの義務を支持する。しかし、インシデントを裏付けのないチケット内容の盗難や裏付けのないサードパーティ侵害に拡大することは支持しない。

より強固な公開記録は、影響を受けた各面を分離するだろう

より強固な公開記録は、主要な面を単一のアクションマップにまとめるだろう。Support と Chat のアカウント情報を認証情報から分離する。アクティブな顧客を期限切れトライアルや非アクティブアカウントから分離する。ハッシュ化パスワードをアプリ認証情報や TLS キーから分離する。ユーザーパスワードローテーションをアプリ認証情報ローテーションや証明書置き換えから分離する。チケットデータをアカウントメタデータから分離し、その境界の根拠をクラスレベルで説明する。

アクションマップは顧客の役割も説明するだろう。エージェントとエンドユーザーはパスワードガイダンスを必要とする。Zendesk 管理者は影響を受けたアカウントと製品のガイダンスを必要とする。アプリ所有者は統合認証情報のガイダンスを必要とする。ウェブ管理者は証明書ガイダンスを必要とする。プライバシーチームは管理者と処理者の証拠を必要とする。セキュリティチームは監査、トークン、アクセスレビューのガイダンスを必要とする。経営幹部は残留リスクと顧客影響の簡潔な声明を必要とする。これらの対象者は互換性がない。

これはセンシティブな詳細の公開を要求するものではない。決定木を要求するのだ。あなたのアカウントがカットオフ日以降に作成された場合、これが証拠の境界だ。あなたのアカウントがシングルサインオンを使用していた場合、これが変わるものと変わらないものだ。カットオフ日以前にアプリをインストールしシークレットを保存した場合、それらをローテーションせよ。まだ有効な証明書をアップロードした場合、新しいものに置き換えて古いものを失効させよ。チケットデータが範囲外だった場合、その主張の背後にある証拠のクラスはこれだ。

バイヤーは契約更新前に古いサポートデータについて尋ねるべきだ

Zendesk 顧客とバイヤーは、古いサポートデータについて尋ねるのにインシデントを待つべきではない。サポートプラットフォームは、エージェント、エンドユーザー、チケット、カスタムフィールド、マクロ、アプリ、ウェブフック、証明書、API トークン、OAuth クライアント、トライアル記録を静かに蓄積しうる。そのデータの一部は監査、カスタマーサービス、または法的防御のために必要かもしれない。一部は単に削除が難しいため残っているかもしれない。契約更新の瞬間は、顧客がどれがどれかを尋ねるレバレッジを持つときだ。

有用な質問は実践的だ。非アクティブアカウントはどれくらい保持されるのか？期限切れトライアルはどのように削除または非識別化されるのか？古いエージェントやエンドユーザーの記録はどうなるのか？パスワード検証子はどのように保護されているのか？顧客はインストール済みアプリとそのインストール日付をどのようにリストできるのか？管理者は OAuth トークンと API トークンをレビューできるのか？顧客がアップロードした TLS キーはどのように保存され、廃止されるのか？チケットストアはアカウントメタデータからどのようにセグメント化されているのか？古いインシデントが発見された場合、プロバイダーはどのような証拠を共有するのか？

これらの質問は敵対的ではない。障害発生時に双方をより良くする。プロバイダーはどの証拠を保存し開示すべきかを知る。顧客はどのローカル所有者が行動すべきかを知る。Zendesk のインシデントは、古いサポート記録がいかに新たな作業を生み出しうるかを示しているため、依然として有用である。

取締役会はサポートシステムを顧客信頼インフラとして扱うべきだ

取締役会はしばしばサポートシステムを、顧客信頼インフラではなく運用ツールとして扱う。Zendesk の記録は、それがなぜあまりにも狭い見方なのかを示している。サポートシステムには、連絡先データ、認証情報、統合機能、証明書、チケット内容、サポート履歴が含まれうる。企業とその最も苛立った、または脆弱な顧客との間に位置しうる。また、アプリや API を通じて他の多くのシステムに接続しうる。もしそのプラットフォームにレガシー侵害があれば、それを使用する企業は、ベンダー管理チームからだけでなく、自社の顧客からの質問に答えなければならない。

したがって、取締役会の質問には、保持、アクセス、統合、通知が含まれるべきだ。どのサポートプラットフォームが顧客データを保持しているのか？どのアプリがシークレットを持っているのか？どの証明書やカスタムドメインがそこでホストされているのか？どのユーザーが特権ロールを持っているのか？どの記録が現在のビジネスニーズよりも古いのか？どのプロバイダー通知が規制当局の分析をトリガーするのか？どのチームがパスワードローテーション、アプリ認証情報ローテーション、証明書置き換えを所有しているのか？

プロバイダーにも取締役会レベルの義務がある。どの古い記録が残っているのか、保持が実際の目的を果たしているか、認証情報は分離されているか、顧客アップロードキーは追跡されているか、アプリ設定は監査可能か、インシデント通知は顧客が行動するのに十分な証拠を提供しているか、を知らなければならない。証拠がエンジニアリングログにある場合でも、それらはガバナンス上の問いだ。

契約文言はサポートプラットフォームの面に従うべきだ

一般的な侵害条項は、サポートプラットフォームには薄すぎる。契約文言は重要な面に従うべきだ。プロバイダーがアカウントデータを保持する場合、契約はパスワード検証子保護、シングルサインオンステータス、アクティブおよび非アクティブアカウント、パスワードローテーションに対処すべきだ。プロバイダーがサポートチケットをホストする場合、契約はチケットデータ、添付ファイル、カスタムフィールド、保持、削除、顧客固有の通知に対処すべきだ。プロバイダーがアプリと API をサポートする場合、契約は統合認証情報、トークンレビュー、アプリインベントリ、監査ログに対処すべきだ。プロバイダーが顧客アップロードの TLS 資料を保存する場合、契約はキー処理、期限切れ、置き換え、失効ガイダンスに対処すべきだ。

また、契約はインシデント後の証拠カテゴリを明示すべきである。顧客は、影響を受けた日付範囲、影響を受けた製品名、データクラス、認証情報クラス、顧客アクション、除外された面、レビュー方法を必要とする。通常のユーザー通知とは別の管理者連絡先を必要とする。サービスデータの管理者である場合に規制通知が必要かどうかを判断するのに十分な情報を必要とする。

Zendesk の記録は良い例だ。公のインシデントは、古いアカウント、認証情報、証明書、アプリ設定、パスワードローテーション、チケット境界の保証に触れたからだ。個人データのみに言及する契約は、アプリのシークレットを見逃すかもしれない。アプリケーションの稼働時間のみに言及する契約は、過去の保持を見逃すかもしれない。説明責任は、障害が起きた面に従う。

運用指標が将来の主張をテスト可能にするだろう

いくつかの指標が、将来のサポートプラットフォームインシデントをよりテストしやすくするだろう。アカウントデータについて、プロバイダーは影響を受けたアカウント作成日、アクティブ対非アクティブのアカウント数、エージェント対エンドユーザーのカテゴリ、パスワード変更状況、シングルサインオン除外、ローテーション状況を述べることができる。認証情報について、アプリインストール日付範囲、認証情報タイプ、OAuth および API トークンレビューオプション、アプリ所有者ガイダンス、サードパーティローテーション推奨を述べることができる。TLS 資料について、証明書が期限切れか有効か、プライベートキーが範囲内だったか、顧客がどのように置き換え失効させるべきかを述べることができる。チケットデータについて、どのストアがレビューされ、どのような証拠が除外を支持するかを述べることができる。

顧客アクションについて、プロバイダーは個別ユーザーステップを管理者ステップから分離できる。ユーザーはパスワードをリセットする必要があるかもしれない。管理者はアプリをリストし、シークレットをローテーションし、トークンをレビューし、証明書を置き換え、プライバシー分析を文書化する必要があるかもしれない。プライバシーチームは、第33条またはその他の通知義務が適用されるかどうかを判断する必要があるかもしれない。セキュリティチームは、関連する不審なアクセスがないかログを検査する必要があるかもしれない。サポートリーダーはエージェントに警告し、エンドユーザー向けの回答を準備する必要があるかもしれない。

これらの指標は生ログを要求しない。公的な主張を利用可能にする。Zendesk の FAQ は、カットオフ日付、影響を受けた製品、パスワードローテーションルール、認証情報、アプリ認証情報、TLS キー、チケットデータ境界、管理者と処理者の役割、顧客固有の通知など、正しいカテゴリの多くを含んでいる。より強固な記録は、時系列と数の調整をさらに容易にするだろう。

再発の問題は Zendesk よりも広い

再発の問題は、Zendesk が同じイベントを繰り返すかどうかではない。問題は、サポートプラットフォーム、CRM ツール、チャットシステム、ワークフローハブが古いデータの教訓を学んだかどうかである。サポートシステムは、アイデンティティ、運用コンテキスト、顧客連絡先記録、認証資料、統合シークレットの長期保存庫になりうる。数年後に発見された侵害は、顧客が依然として何をローテーションし、置き換え、通知し、監視するかを決定しなければならないため、古いデータを再び現在のものにする。

Zendesk の記録は、クラウドサービス依存とエンタープライズソフトウェア自動化の、より広範な説明責任カタログに属する。自動化は、インストール後に忘れられがちな場所に記録と認証情報を集中させる。クラウド依存は、顧客が法的・運用上の決定に必要とする証拠の管理権限をプロバイダーに与える。データローカリティと主権は、同じプラットフォームインシデントが影響しても、異なる地域の顧客が異なる通知義務を持つ可能性があるため、別の層を追加する。

建設的な教訓は、サポートプラットフォームを最初から説明責任のあるデータシステムとして設計することだ。目的のあるものだけを保持せよ。コピーされた記録が攻撃されることを前提に認証情報を保護せよ。アプリとトークンのインベントリを容易にせよ。チケットデータをアカウントメタデータからセグメント化せよ。侵害前に顧客固有の通知経路を準備せよ。ニュースサイクルが移っても顧客の義務が残っているとき、古い記録をより説明しやすくせよ。

説明責任の総括

総括すると、Zendesk は顧客が必要としたレガシーサービス側の証拠を管理していた。ユーザーはパスワードを変更でき、管理者はアプリ認証情報をローテーションでき、ウェブチームは証明書を置き換えられ、プライバシーチームは通知義務を評価できた。しかし、これらの当事者の誰も、サポートデータベースの境界、認証情報の範囲、チケットデータの除外、またはテナントセグメンテーションの証拠を独自に検証することはできなかった。そのため、Zendesk の公開 FAQ と顧客固有の通知が、顧客の意思決定の主要なツールとなった。

最も強力な説明責任の発見は、恐れられていたすべての害が起きたということではない。最も強力な発見は、古いサポート記録が、何年も経った後でも新たな顧客作業を生み出すのに十分な価値を保持しうるということだ。公開記録は、保持、パスワードローテーション、アプリ認証情報、TLS 資料、顧客通知、チケット境界の証明に関する義務を支持する。また、公的証拠が確立しない主張については自制を支持する。

バイヤーにとっての教訓は、更新前に証拠カテゴリを要求することだ。取締役会にとっては、サポートシステムを顧客信頼インフラとして扱うことだ。規制当局にとっては、古い記録が、管理者が自ら決定を下せる方法で保持・保護・説明されていたかどうかを検討することだ。顧客にとっては、次の古いインシデントが到着する前に、サポートプラットフォームのアプリ、証明書、トークン、管理者ロールのインベントリを維持することだ。

読者の判断

読者は実践的な問いを持ち帰るべきだ。今日、サポートプラットフォームが、古いアカウント、パスワードハッシュ、アプリ設定、統合認証情報、TLS 資料が何年も前にアクセスされていたと開示した場合、プロバイダーは、各顧客が散在する記録から推測することを強いることなく、影響を受けた日付範囲、アクティブおよび非アクティブアカウントクラス、トークンとアプリの証拠、証明書の置き換えパス、チケットデータ境界、顧客固有の通知、規制上の意思決定支援を示すことができるだろうか？もし答えがノーなら、Zendesk の記録は説明責任の教訓として依然として現代的である。

公正な基準は、センシティブな技術的詳細すべての公開露出ではない。公正な基準は、規律ある公的証明だ。何が起きたかを述べよ。何が分かっているかを述べよ。どの記録が影響を受けたかを述べよ。どの記録が影響を受けず、なぜかを述べよ。誰が行動すべきかを述べよ。調査が進むにつれて何が変わったかを述べよ。顧客が自分自身の状態をどのように検証できるかを述べよ。Zendesk の記録では、これらの義務が、どの単一のアカウント数よりも明確に顧客信頼の表面を定義している。