計測と配信と管理が同時に止まった
KARTEはWebやアプリ上の行動を計測し、顧客ごとの表示やメッセージ配信、データ分析に使われる。今回の停止対象は一つの画面ではない。公式発表は、計測、各種配信、管理画面を含む全機能を全プロジェクトで止めたと説明する。機能は一斉ではなく順次停止したため、停止の前後で処理結果が分かれる可能性がある。[1]
公式ステータスは、KARTE Messageの一括メールが配信途中で止まる場合と、KARTE Datahubで内外のデータ連携が失敗する場合を挙げた。[2] これは「配信されなかった」と一律に扱えないことを意味する。宛先ごとの送信結果、キュー、連携先の受信記録を見なければ、未送信、送信済み、途中失敗を区別できない。
グループ会社RightTouchも、KARTEを基盤に使うQANT各製品で、管理画面、サポートサイト、サポートアクション配信、SMS送信、有人チャットなどの一部機能を停止した。[3] SaaS一社の停止が、別ブランドの顧客対応業務へ連鎖する例である。
漏えいの可能性と対象範囲を分けて読む
公式ステータスが確認したのは「外部に漏えいした可能性のある情報」があることだ。漏えいが確定した全件数や全顧客への影響を示した発表ではない。連絡対象になった顧客と、連絡を受けていない顧客の安全が同時に証明されたわけでもない。現時点では、個別通知の内容と今後の調査結果を分けて扱う必要がある。[2]
利用企業はまず、プレイドからの個別メールを、あらかじめ登録した管理者用アドレスや契約窓口で確認する。緊急時には、通知を装うフィッシングも起きやすい。メール内のリンクをそのまま開くのではなく、公式サイトや保存済みの窓口から通知の真正性を確かめる。
KARTEに入れていたデータの種類も棚卸しする。氏名やメールアドレスの有無だけでなく、閲覧履歴、会員ID、購入や問い合わせに関するイベント、外部システムから連携した属性を確認する。何を送っていたかは企業ごとに異なる。プレイドの発表だけから、自社の対象データを推測することはできない。
トラボックスは、KARTE停止の影響で一部機能に不具合が生じる可能性を案内する一方、自社システムへの不正アクセスは確認されていないと説明した。[4] この説明も同社が確認した範囲に限られる。KARTE利用企業全体の状況を示す独立調査ではない。
再送する前に三つの記録を突き合わせる
復旧後に最も避けたいのは、止まったと思った処理を再実行し、顧客へ同じメールや通知を二重に送ることだ。反対に、送信済みだと思い込んで必要な連絡を欠落させる問題もある。管理画面が使えない間は、KARTE内の状態だけで判断できない。
利用企業が確認する記録は三つある。第一は、KARTEへ処理を依頼した自社側の時刻、対象、ジョブIDである。第二は、メール配信事業者、アプリ通知基盤、データウェアハウスなど連携先の受信・実行記録だ。第三は、顧客から見える画面、メール到達、アプリイベントなどの実結果である。依頼記録、連携先記録、実結果が一致した処理だけを完了とする。
停止が順次進んだため、境界時刻を一つ決めて全件を処理し直す方法は危険である。公式が示した14時44分の告知より前に止まった機能も、後まで動いた処理もあり得る。処理単位で照合し、状態が分からないものは保留にする。再送時には重複防止キーや送信済みリストを使い、対象を限定する。
自動キャンペーンも確認する。期間限定のクーポン、本人確認、請求や予約に関する通知は、遅れて送ると内容が無効になる場合がある。再開後にキューが一斉消化されないか、期限切れのメッセージを止められるかを確認してから、配信を戻す。
認証情報と埋め込みタグも確認対象になる
侵入経路や取得された情報が未公表の段階で、すべてのAPIキーが盗まれたと断定することはできない。しかし、KARTEと自社システムをつなぐ認証情報がどこにあり、どの権限を持つかは今のうちに確認できる。個別通知や続報で対象になった場合に、停止、再発行、接続先変更を短時間で実行するためである。
APIキー、Webhook、データ連携用アカウント、管理者アカウント、シングルサインオンの設定を一覧にする。再発行する場合は、古い認証情報を無効にした時刻、新しい情報を配布した接続先、動作確認結果を残す。根拠なく一斉変更すると、調査に必要な記録を失ったり、別の業務停止を広げたりする。
Webやアプリに組み込んだタグとSDKも対象だ。計測停止中のサイト表示やアプリ動作に遅延やエラーがないか、ブラウザーの開発者ツール、監視、アプリログで確認する。KARTE側が止まっても、自社側で待ち時間や再試行が増える設計なら、顧客体験へ影響が残る。
再開条件を提供元の復旧だけにしない
サービスが「復旧」と表示されても、利用企業の未完了処理や設定確認が自動で終わるわけではない。再開条件は、公式ステータスの復旧、個別通知への対応、認証情報の判断、未完了ジョブの照合、顧客向け表示の動作確認を分ける。
計測、分析、配信、データ連携を同時に戻さず、影響の小さい機能から段階的に確認する。たとえば計測の受信とデータ欠損を先に確認し、その後にテスト対象へ限定した配信を行い、最後に自動キャンペーンを戻す。実際の再開順は各社の構成とプレイドの案内に従う。
顧客へ説明する場合は、不正アクセスの検知、全機能停止、自社で確認した影響、まだ分からない項目を分ける。「漏えいなし」も「全顧客が漏えい」も、現時点の公式情報からは言えない。確認日時と根拠URLを添え、続報で変わる可能性を示す。
顧客データ基盤が計測と施策実行の両方を担うほど、障害時の確認範囲も広がる。復旧を待つだけでなく、外部の記録で処理の成否を判定できる設計が必要である。
まとめ
- KARTEは全プロジェクトで計測、配信、管理などを停止し、外部に漏えいした可能性のある情報を確認したが、対象範囲と原因は調査中である。
- 利用企業は、依頼記録、連携先の記録、顧客側の実結果を突き合わせ、未完了処理と二重配信を分けてから再開する。
- 個別通知、認証情報、タグやSDK、期限切れキャンペーンを確認し、提供元の復旧と自社業務の復旧を分けて判断する。
読者のコメント (0)
コメントを残す