第45章 沈黙リスト
- 山崎行政書士事務所
- 5月7日
- 読了時間: 17分
午前七時五十五分。
三枝涼真は、昨夜のDMARCレポートを閉じる前に、取引先向け注意喚起の配信結果を確認した。
前日の偽メール事件を受け、駿河メディカルロジスティクスは正式な注意喚起を出した。
公式ドメインから届いたメールでも、メール認証だけで判断しないこと。確認方法変更、確認ポータル移行、問い合わせ番号入力依頼は登録済み連絡先で確認すること。SPF、DKIM、DMARCがpassしても、会社の現行承認を意味するわけではないこと。
送信元は、現行メール基盤。DKIMは現行セレクタ。DMARCもpass。PublicNoticeHubにも掲載。問い合わせ番号も付与。Evidence Chainにも追加済み。
正しい経路で、正しい文面を、正しい承認で送った。
そのはずだった。
だが、配信結果の一覧を見て、三枝は眉をひそめた。
重要取引先の一部に、メールが届いていない。
配信ステータス。
Suppressed
抑止済み。
対象には、県立東駿河医療センター、東部検査センター、清水臨床資材センターが含まれていた。
三枝は、思わず声を出した。
「なんで抑止されているんだ……」
黒崎課長が、すぐに顔を上げた。
「どうした」
「昨日の正式注意喚起が、一部の重要取引先に届いていません。配信ステータスがSuppressedです」
「配信停止か？」
「そう見えます。でも、重要通知です。マーケティングメールではありません」
三枝は、配信抑止リストを開いた。
Global Suppression List
理由。
Recipient opted out of incident-related updates
三枝の手が止まった。
インシデント関連通知を受け取らない。
そんな選択肢を、取引先が選ぶはずがない。
少なくとも、県立東駿河医療センターは、昨日も今後の確認を求めていた。
山崎行政書士事務所の山崎が、会議室に入ってきた。
「おはようございます」
三枝は、画面を見たまま言った。
「先生。正式な注意喚起が届いていません。重要取引先が、インシデント関連通知の配信停止リストに入っています」
山崎は、すぐに画面を見た。
そして、ホワイトボードへ向かい、黒いペンで書いた。
沈黙リスト
その下に、もう一行。
届かない通知も、攻撃である。
三枝は、その文字を見た。
前日は、偽の声が出た。
今日は、本物の声が届いていない。
攻撃者は、会社の声を偽るだけではなく、会社の声を沈黙させようとしている。
午前八時十分。
望月社長、秋山法務総務部長、大石倉庫部長、久我真琴が緊急参加した。
三枝は、配信抑止リストを共有した。
県立東駿河医療センター。東部検査センター。清水臨床資材センター。その他、主要取引先が十数件。
抑止理由。
Recipient opted out of incident-related updates
登録時刻。
昨夜二十三時四十七分から本日午前一時十二分まで。
申請元。
Preference Center API
利用キー。
pref-api-legacy
秋山が、顔をしかめた。
「Preference Center？」
広報担当が答えた。
「メール配信設定を管理するサービスです。マーケティングメールの配信停止や、ニュースレターの受信希望を管理しています」
山崎が聞いた。
「インシデント関連通知も、そこに含めていたのですか」
広報担当は、少し青ざめた。
「以前、配信カテゴリを整理した時に、“重要なお知らせ”というカテゴリを追加しました。取引先向けの障害情報や重要通知も、同じPreference Centerで管理する形にしていたと思います」
山崎が、静かに言った。
「マーケティング配信停止と、インシデント通知停止は同じではありません」
ホワイトボードに書く。
配信停止 ≠ 重要通知拒否
三枝は、ログをさらに追った。
Preference Center APIでは、対象取引先の複数アドレスがまとめて更新されていた。
変更内容。
incident_updates: falsedelivery_alerts: falsesecurity_notices: false
三枝は、息を呑んだ。
インシデント通知。配送アラート。セキュリティ通知。
全部、false。
久我が低い声で言った。
「攻撃者は、正式な注意喚起が重要取引先へ届かないようにした可能性があります」
望月が言った。
「当社の説明を偽るだけではなく、説明を届かなくする」
山崎は頷いた。
「はい。説明の倉庫から、出荷先を消したようなものです」
三枝は、時系列表を開いた。
08:12 正式注意喚起メールの配信結果確認で、複数重要取引先がSuppressedとなっていることを確認。理由：Recipient opted out of incident-related updates。Preference Center API pref-api-legacyにより、incident_updates、delivery_alerts、security_noticesがfalseへ変更されていた。正式通知の到達妨害可能性。
保存。
画面右下。
保存しました。
午前八時三十五分。
Preference Centerの設定が確認された。
サービス名。
ContactChoice Hub
用途。
メール配信設定、ニュースレター、セミナー案内、重要通知カテゴリ管理。
契約状態。
現行。
ただし、旧APIキー。
pref-api-legacy
作成日。
三年前。
用途。
旧メール配信基盤との同期。
所有者。
営業企画部。
外部関係者。
MailKite導入支援会社。
状態。
Active。
MFA。
なし。
認証。
APIキー。
三枝は、短く息を吐いた。
また、旧メール配信基盤に関連している。
山崎が言った。
「昨日のMailKiteとつながっていますね」
広報担当が頷いた。
「MailKiteとContactChoiceは、以前セットで使っていました。配信停止と購読設定を同期するために」
久我がログを追った。
「pref-api-legacyの昨夜の利用元は、昨日のMailKite偽メール送信元と同じクラウドレンジです」
黒崎が言った。
「攻撃者は、偽メールを送って、その後に本物の注意喚起が届かないよう抑止した」
山崎が、ホワイトボードに流れを書いた。
偽メール送信↓確認ポータル誘導↓正式注意喚起配信↓重要取引先を抑止リストへ投入↓本物の声を届かなくする
「これは、説明システムへの攻撃です」
三枝は入力した。
08:38 ContactChoice Hub確認。pref-api-legacyは旧メール配信基盤MailKiteとの同期用APIキーで、MFAなし、状態Active。昨夜の抑止リスト更新元はMailKite偽メール送信元と近接するクラウドレンジ。偽メール送信後、正式注意喚起の到達を妨害した可能性。
保存。
午前九時。
Blue Heronからメールが届いた。
件名は、Silence preference。
本文は、短かった。
They chose silence.We helped them choose.
彼らは沈黙を選んだ。我々が、その選択を手伝った。
三枝は、保全した。
望月の表情が硬くなった。
「取引先は、沈黙を選んでいません」
山崎が、静かに答えた。
「はい。攻撃者が選択を偽装しました」
秋山が言った。
「法的にも、配信停止や同意管理の扱いを整理しないといけません」
山崎は頷いた。
「重要です。マーケティングメールの配信停止は尊重すべきです。しかし、契約上・安全上・セキュリティ上必要な通知を、同じ配信停止設定で止めてよいのか。カテゴリを分ける必要があります」
ホワイトボードに書く。
販促通知業務通知安全通知セキュリティ通知法令・契約通知
「これらは同じではありません」
三枝は、配信カテゴリを見た。
すべてが一つのPreference Centerで管理されている。
カテゴリ名はある。だが、制御上は同じように止められる。
山崎が言った。
「重要通知は、解除不能という意味ではありません。ただし、解除方法、代替連絡先、契約上の通知先、本人確認、記録が必要です」
三枝は入力した。
09:00 不明差出人より件名“Silence preference”のメール受信。取引先が沈黙を選んだように見せる内容。攻撃者が配信停止・同意管理を悪用した可能性。対応方針：販促通知、業務通知、安全通知、セキュリティ通知、法令・契約通知を分類し、重要通知を単純な配信停止で止めない設計へ見直し。
保存。
午前九時二十五分。
緊急対応が始まった。
まず、pref-api-legacyを保全。
APIキー識別子。利用ログ。更新対象。変更前後の設定。リクエストIP。User-Agent。同期元。関連するMailKite連携。
その後、無効化。
pref-api-legacy: Revoked
次に、抑止リストへ入れられた重要取引先を保留解除。
ただし、単に戻すだけではない。
山崎が言った。
「変更前に、取引先へ確認します。攻撃者が“配信停止を無視された”と揺さぶる可能性があります」
秋山が頷いた。
「登録済み連絡先で、重要通知の受信確認を取ります」
営業部は、主要取引先へ電話した。
県立東駿河医療センターは即答した。
「インシデント関連通知、配送アラート、セキュリティ通知は受け取ります。配信停止はしていません」
東部検査センターも同様。清水臨床資材センターも同様。
三枝は、取引先確認記録に入力した。
重要通知受信意思確認済み
そして、抑止を解除。
incident_updates: truedelivery_alerts: truesecurity_notices: true
三枝は入力した。
09:32 pref-api-legacyを保全後失効。Suppressedとなった重要取引先について、登録済み連絡先で重要通知受信意思を確認し、incident_updates、delivery_alerts、security_noticesを復旧。マーケティング配信設定とは分離して記録。
保存。
午前十時。
ContactChoice Hub社との緊急確認が始まった。
相手は、カスタマーセキュリティ担当の野々村と、技術担当の金森。
山崎が質問した。
「pref-api-legacyを用いて、昨夜から本日未明にかけて複数の重要取引先のincident_updates、delivery_alerts、security_noticesがfalseへ変更されました。当社では実施していません。御社側ログでも確認できますか」
金森が答えた。
「はい。御社テナントのAPIキーから更新されています」
久我が聞いた。
「APIキーにMFAやIP制限は？」
「旧APIキーのため、MFAはありません。IP制限も未設定です」
黒崎が言った。
「旧APIキーなのに、重要通知まで変更できるのか」
金森は、苦い顔で答えた。
「当時の設計では、カテゴリ全般の設定変更権限を持っていました。後にスコープ分割機能が追加されましたが、旧キーには適用されていませんでした」
山崎は、ホワイトボードに書いた。
旧APIキーは、新しい分類を知らない。
三枝は、その文字を見て納得した。
会社は、後からカテゴリを分けた。販促通知、業務通知、安全通知、セキュリティ通知。
だが、旧APIキーはそれを知らない。全部まとめて変更できる。
システムは、新しい方針を自動では理解しない。
山崎が続けた。
「重要通知カテゴリは、旧APIキーで変更できないようにしてください」
金森は頷いた。
「設定変更を支援します。重要通知カテゴリについては、管理者承認必須、API変更不可、または専用スコープ制限が可能です」
三枝は入力した。
10:08 ContactChoice Hub社確認。pref-api-legacyは旧APIキーで、MFA・IP制限なし。後年追加された通知カテゴリ分割前のキーであり、incident_updates、delivery_alerts、security_noticesを含むカテゴリ全般変更権限あり。重要通知カテゴリについて旧API変更不可・管理者承認必須へ設定変更予定。
保存。
午前十時三十五分。
Blue Heronからメールが届いた。
件名は、Old keys do not read policy。
本文は、短い。
Old keys do not read your new policy.
古い鍵は、あなたたちの新しい方針を読まない。
三枝は、保全した。
山崎が言った。
「その通りです。だから、古い鍵を新しい方針に合わせて失効・再発行する必要があります」
秋山が頷いた。
「規程を変えても、旧APIキーがそのままなら意味がない」
「はい」
久我が言った。
「技術設定と規程の同期です」
三枝は、時系列表に入力した。
10:35 不明差出人より件名“Old keys do not read policy”のメール受信。旧APIキーが新しい通知分類方針を理解せず、重要通知カテゴリを変更できたことを示唆。対応方針：規程変更時に関連APIキー・権限・スコープを再発行または失効する。
保存。
山崎は、未了事項台帳に追加した。
U-175 規程変更時の技術権限再評価プロセス未整備
責任者。
秋山・三枝・山崎行政書士事務所
期限。
三十日以内に方針案
状態。
開始
午前十一時十五分。
重要通知の再配信が行われた。
対象は、抑止されていた取引先。
ただし、再配信前に、山崎が確認した。
「件名に“再送”と入れましょう。なぜ再送するのかを明記します」
文面。
昨日送信した重要注意喚起について、一部取引先様において配信設定が不正に変更された可能性があるため、登録済み連絡先で確認のうえ再送いたします。
当社は、重要なセキュリティ通知、配送アラート、安全通知を、単なるマーケティング配信停止設定とは分けて管理します。
本通知の受信を停止する必要がある場合は、登録済み窓口へご連絡ください。代替連絡先を確認します。
営業部長が言った。
「配信停止を完全に無視するのではなく、代替連絡先を確認する」
山崎は頷いた。
「はい。取引先の事情もあります。重要なのは、攻撃者が勝手に沈黙を選ばせないことです」
望月が承認した。
三枝は再配信した。
今度は、Suppressedにならない。配信成功。
入力。
11:22 重要通知がSuppressedとなった取引先へ、登録済み連絡先で確認後、重要注意喚起を再送。再送理由として配信設定の不正変更可能性を明記。重要通知はマーケティング配信停止と分離し、停止時は代替連絡先確認を行う方針を案内。
保存。
午後零時十分。
Blue Heronからメールが届いた。
件名は、Loud again。
本文は、一行。
You found their silence and made them loud again.
彼らの沈黙を見つけ、また騒がしくした。
三枝は、保全しながら、少しだけ笑った。
「騒がしい方がいいですね」
大石が頷いた。
「重要な通知なら、届いた方がいい」
山崎が言った。
「はい。必要な声は、届かなければなりません」
三枝は入力した。
12:10 不明差出人より件名“Loud again”のメール受信。重要通知再配信に反応した可能性。“沈黙を見つけ、また騒がしくした”と記載。証跡保全。
保存。
午後一時。
配信カテゴリの見直し会議が行われた。
参加者は、広報、営業、法務総務、情シス、山崎。
山崎は、最初に言った。
「まず、通知を五種類に分けます」
ホワイトボードに書く。
販促通知セミナー、ニュースレター、営業案内。
業務通知配送予定、仕様変更、定期メンテナンス、契約関連。
安全通知火災、災害、定温異常、緊急配送変更。
セキュリティ通知インシデント、偽メール、偽サイト、連絡先改ざん、注意喚起。
法令・契約通知個人情報、契約上必要な通知、行政報告関連、権利義務に関わる通知。
「販促通知は、配信停止を簡単にできるべきです。一方、セキュリティ通知や法令・契約通知は、単純なAPIで一括停止できてはいけません。停止する場合は、代替連絡先や通知方法を確認します」
広報担当が言った。
「一つのPreference Centerで全部を管理するのは危険ですね」
三枝が答えた。
「重要通知カテゴリは別システム、または少なくとも別権限にします」
秋山が言った。
「法務的にも、同意管理と契約上の通知先管理を分けます」
山崎は頷いた。
「はい。配信設定は、単なるマーケティング設定ではなく、契約・安全・セキュリティの連絡経路です」
三枝は、通知カテゴリ台帳を作った。
通知カテゴリ停止可否停止方法代替連絡先要否変更承認者API変更可否ログ保存取引先確認要否
保存。
午後二時二十分。
ContactChoice Hubの設定変更が完了した。
重要通知カテゴリは、旧APIキーでは変更不可。APIで変更できるのは販促通知のみ。安全通知、セキュリティ通知、法令・契約通知は、管理者二名承認。変更時には旧登録連絡先で確認。変更ログはEvidence Chainへ定期連携。異常な大量変更はSOCアラート。
三枝は、テストを行った。
旧APIキーは失効済み。
新しい販促用APIキーで、セミナー案内配信設定を変更。
成功。
同じAPIキーで、security_noticesをfalseへ変更。
Denied: category protected
三枝は、画面を見て入力した。
14:25 ContactChoice Hub設定変更完了。重要通知カテゴリはAPI変更不可または二名承認必須。販促APIでsecurity_notices変更を試行した結果、Denied: category protected。重要通知保護が有効に機能。
保存。
山崎が言った。
「良い拒否ログです」
三枝は頷いた。
また一つ、拒否できるようになった。
午後三時十五分。
Blue Heronからメールが届いた。
件名は、Category protected。
本文は、短い。
You made silence a privilege.
沈黙を特権にしたのか。
三枝は、保全した。
山崎が言った。
「面白い表現です。重要通知を受け取らない選択には、確かに手続きが必要になりました」
秋山が頷いた。
「沈黙も、権利である場合があります。でも、攻撃者が勝手に作る沈黙は違う」
山崎は答えた。
「はい。重要通知の停止は、本人確認と代替連絡先確認が必要です。沈黙にも真正性が必要です」
三枝は、その言葉をノートに書いた。
沈黙にも、真正性が必要。
時系列表にも入力する。
15:15 不明差出人より件名“Category protected”のメール受信。重要通知カテゴリ保護に反応した可能性。“沈黙を特権にした”と記載。対応方針：重要通知停止には本人確認・代替連絡先確認・承認ログを必須化。
保存。
午後四時半。
配信抑止リストの過去履歴も確認された。
過去六か月で、重要通知カテゴリがfalseになっていた取引先が複数あった。
理由はさまざまだった。
担当者退職に伴うメール不達。迷惑メール判定。旧配信基盤からのエラー。営業が誤って販促停止と一緒に重要通知を停止。取引先がセミナー案内停止を希望し、全カテゴリ停止として登録。
攻撃だけではない。
運用ミスもあった。
山崎が言った。
「ここも分けます。攻撃、誤設定、取引先希望、メール不達。それぞれ対応が違います」
三枝は、抑止理由分類を作った。
攻撃疑い取引先希望不達処理社内誤設定システム同期エラー旧サービス同期
営業部長が言った。
「重要通知が止まっている取引先には、再確認が必要ですね」
秋山が頷いた。
「契約上の通知先も見直します」
三枝は入力した。
16:36 過去六か月の重要通知抑止履歴を確認。攻撃疑い以外に、取引先希望、不達処理、社内誤設定、旧サービス同期等を確認。重要通知停止理由を分類し、対象取引先へ代替連絡先・通知希望確認を実施する方針。
保存。
午後五時半。
主要取引先の通知先再確認が始まった。
県立東駿河医療センター。東部検査センター。清水臨床資材センター。医療機器商社。配送協力会社。検査資材メーカー。
営業部は、取引先ごとに確認した。
販促通知は不要。配送通知は必要。セキュリティ通知は必要。安全通知は複数担当へ。法令・契約通知は総務と法務へ。
三枝は、取引先通知設定を見て思った。
一つのメールアドレスで、すべてを受ける時代ではないのかもしれない。
通知の種類ごとに、受ける部署や責任者が違う。営業案内を止めたい人も、セキュリティ通知は必要だ。配送遅延は物流管理課へ。個人情報は総務や法務へ。安全通知は現場へ。
通知先は、業務の責任分界そのものだった。
山崎が、三枝の画面を見て言った。
「通知先も、責任分界表ですね」
三枝は頷いた。
「はい。誰が何を受け取るかで、対応が変わります」
山崎は、静かに言った。
「その通りです。通知分類は、責任分界です」
三枝は、ノートに書いた。
通知分類は、責任分界である。
保存。
午後六時四十五分。
Blue Heronから、その日最後のメールが届いた。
件名は、Too many inboxes。
本文は、一行だけ。
Noise has become organized.
雑音が、整理されてしまった。
三枝は、保全した。
望月が言った。
「整理しましょう。必要な声が、必要な人に届くように」
山崎が頷いた。
「はい。雑音と重要通知を分ける。それが、沈黙リストへの対策です」
久我が言った。
「攻撃者は、重要通知を雑音扱いにして止めようとした。こちらは、分類して守った」
大石が言った。
「現場にも、重要通知は埋もれないようにします」
三枝は入力した。
18:45 不明差出人より件名“Too many inboxes”のメール受信。通知分類・重要通知保護に反応した可能性。“雑音が整理された”と記載。証跡保全。
保存。
午後八時。
その日の最終会議で、山崎はまとめた。
ホワイトボードには、今日の言葉が並んでいる。
沈黙リスト届かない通知も、攻撃である。配信停止 ≠ 重要通知拒否旧APIキーは、新しい分類を知らない。沈黙にも、真正性が必要。通知分類は、責任分界である。
山崎は言った。
「今日、攻撃者は本物の通知を止めようとしました。会社の声を偽るだけでなく、会社の声を届かなくする攻撃です」
望月が頷いた。
「必要な声を、必要な相手に届ける」
「はい」
秋山が言った。
「同意管理と重要通知管理を分けます」
広報担当が言った。
「販促メールとセキュリティ通知を一緒にしない」
営業部長が言った。
「取引先ごとに通知先を確認します」
黒崎が言った。
「旧APIキーとCRM同期を止めます」
三枝は、全員の言葉を記録した。
会社の声の出口を数えた。今度は、声の届き先を数え始めた。
出口だけでは足りない。
届かなければ、声は声にならない。
午後十時。
三枝は、一人でContactChoice Hubの設定を見ていた。
incident_updates。delivery_alerts。security_notices。legal_contract_notices。marketing_newsletters。
これまで、ただの配信カテゴリだと思っていた。
今は違う。
それぞれが、会社と取引先をつなぐ線だ。
攻撃者は、その線を切った。
会社は、線を分類し、守り直した。
三枝は、自分のノートに書いた。
声は、出すだけでは届かない。届く道を守って、初めて説明になる。
保存。
山崎が、背後から言った。
「今日の結論ですね」
三枝は振り返った。
「先生、通知って奥が深いですね」
山崎は頷いた。
「はい。通知は、会社の神経です。前にも言いましたね」
「神経を切られたら、痛みも伝わらない」
「その通りです」
三枝は、画面を閉じた。
午前零時。
三枝は、時系列表の最後に入力した。
00:00 正式注意喚起メールの配信結果において、複数重要取引先がSuppressedとなっていることを確認。旧MailKite連携由来のpref-api-legacyを用い、ContactChoice Hub上でincident_updates、delivery_alerts、security_noticesがfalseに変更されていた可能性。pref-api-legacyを保全後失効し、登録済み連絡先で重要通知受信意思を確認後、抑止解除・再配信。重要通知カテゴリを販促通知と分離し、API変更不可または二名承認必須へ変更。通知カテゴリ台帳、抑止理由分類、重要通知先再確認を開始。
保存。
画面右下。
保存しました。
三枝は、自分のメモにも一行追加した。
沈黙は、選ばれた時だけ尊重する。攻撃者に作られた沈黙は、解除する。
保存。
第三会議室の外では、倉庫が静かに動いていた。
通知が届く。配送が進む。取引先が確認する。現場が受け取る。
会社の声は、また少し届きやすくなった。
雑音ではなく、必要な声として。
コメント