メール配信サービスのセキュリティチェックリスト｜漏えい事例から学ぶ委託先管理

セキュリティ情報漏えい委託先管理APIキー二要素認証個人情報保護法

この記事でできること

メール配信サービス（ESP）を委託先として管理するための確認項目を、契約前・運用中・事故が起きたとき・乗り換えの4つの場面に分けて確認できます。配信先リストは「預けた個人情報」であり、委託先の事故は自社の事故として扱われます。何を確認し、何を自社側で設定するかを整理しました。

注意： 本記事は特定のサービスを評価・非難するものではありません。事例は運営会社の公式発表と報道で確認できる範囲にとどめ、確認できない数字や推測は書いていません。

なぜ必要か（2026年10月の事例から）

2026年10月21日、株式会社ラクスは、子会社の株式会社ラクスライトクラウドが提供するメール配信サービス「ブラストメール」が外部の第三者による不正アクセスを受け、顧客の個人情報を含むデータが外部に持ち出されたことを確認したと発表しました。公式発表（2026年10月28日確認）によると、概要は次のとおりです。

項目公式発表の内容
侵入経路API用サーバー2台に侵入してコマンドを実行し、販売管理システムとサービスのデータベースに接続（経路の詳細は調査中）
持ち出された可能性がある情報全契約者の会社名・担当者名・電話番号・メールアドレス・請求先メールアドレス・契約と支払いの履歴など（クレジットカード番号は保持していない）
配信先リスト一部の契約者について、配信先リストなど配信に関する情報の漏えいを確認。該当者には個別に連絡
サービス停止2026年10月21日 0:30 から停止が継続。再開時期は公式サイトで随時更新

この事例から読み取れることは3つです。

  1. 契約者自身の情報も漏れる。 配信先リストだけでなく、自社の担当者名・電話番号・契約履歴が委託先に保管されています。
  2. 配信先リストは一部の契約者で漏えいした。 自社が該当するかは委託先からの連絡を待つしかなく、把握までに時間がかかります。
  3. サービス停止が長期化する。 配信の代替手段がないと、お知らせや注意喚起そのものを送れなくなります。実際、利用していた企業や自治体が相次いで「なりすましメールへの注意」を自社サイトで告知しています。

個人情報保護法では、個人データの取扱いを委託する場合、委託元に委託先の監督義務があります（第25条）。委託先で漏えいが起きても、委託元である自社に個人情報保護委員会への報告と本人への通知が求められる場合があります（第26条）。「ツール側の問題」で済まない理由はここにあります。

場面1：委託先を選ぶときのチェックリスト（契約前）

#確認項目見るところ
1第三者認証（ISO 27001、SOC 2 など）を取得しているか公式のセキュリティページ、認証書の提示
2データの保管場所（国・リージョン）と、海外移転の扱いプライバシーポリシー、DPA（データ処理契約）
3保存データと通信の暗号化セキュリティページ
4ログインの二要素認証（2FA）があるか。全ユーザーに強制できるかヘルプ、管理画面
5APIキーに対する IP アドレス制限があるか開発者向けドキュメント
6ユーザーごとの権限設定（閲覧のみ・エクスポート不可など）ができるかヘルプ、料金プラン
7操作ログ・ログイン履歴を自社側で確認できるかヘルプ
8連絡先データの削除・エクスポートを自社の操作で完結できるかヘルプ、API リファレンス
9インシデント発生時の通知方針（通知までの時間、連絡手段）が契約書・規約に書かれているか利用規約、DPA
10過去のインシデント公表の有無と、公表のしかた公式サイトの「お知らせ」
11障害・停止時の代替手段（別サービスへの一時切替など）を自社で用意できるか自社の運用設計

ヒント： 「ISO 27001 取得」は入口の確認にすぎません。実際に守られるかは、4〜8 の自社で設定できる機能と、それを使う運用で決まります。

場面2：運用のチェックリスト（契約後）

ログインとアカウント

  • 全ユーザーの二要素認証を必須にする。「任意」のままにしない
  • 共有アカウント（1つのID を複数人で使う）をやめ、人ごとにユーザーを作る
  • 退職・異動・外注契約の終了時に、即日でユーザーを削除する棚卸しの手順を決める
  • ログインに使うメールアドレス自体を、自社ドメインの二要素認証付きアカウントにする

APIキーと連携

  • 用途ごとに別のキーを発行する（フォーム連携用、ECサイト連携用、BI用など）。1つのキーを使い回すと、漏えい時にすべて止めることになる
  • キーは発行時に1回しか表示されないため、パスワード管理ツールなど暗号化された場所に保管する。チャットやスプレッドシートに貼らない
  • ソースコードに直書きせず、環境変数やシークレット管理を使う。Git リポジトリにコミットしない
  • 固定の IP アドレスから呼び出す連携は、サービス側の IP 制限を有効にする
  • 使っていないキーは削除する。担当者の退職や外注先の変更時は必ず再発行する
  • Webhook を受けるエンドポイントは、推測されにくい URL にし、受信側で送信元を検証する（詳しくはWebhookペイロード）

権限設計

  • 「全員が管理者」をやめる。配信担当は配信とレポート、デザイナーはテンプレートのみ、のように分ける
  • 連絡先のエクスポートとAPIキーの発行ができる人を最小限にする。漏えいの多くはこの2つの操作から起きる
  • 外注先（制作会社・広告代理店）には期限付きで権限を渡し、終了時に削除する

配信リストの保管と削除

  • 預けるデータを最小限にする。配信に不要な項目（住所、生年月日、購入履歴の詳細など）はアップロードしない
  • 配信停止した人・ハードバウンスした人を定期的に削除する。「いつか再配信するかも」で残したリストは、漏えい時に被害を増やすだけ
  • 保存期間のルールを決める（例：最終反応から24か月で削除）。オプトイン同意の記録と削除基準をセットで文書化する
  • インポート用の CSV を自分の PC や共有フォルダに残さない。取り込み後に削除する
  • 配信ログ（誰にいつ送ったか）の保存期間も確認する。サービス側で自動削除されるのか、自社で削除するのかを把握しておく

分離と監視

  • 本番の配信アカウントと、テスト・開発用のアカウント（または連絡先リスト）を分ける
  • 月1回、ユーザー一覧・APIキー一覧・権限を見直す。見覚えのないキーや IP アドレスがあれば即時に無効化する
  • 送信ドメインの認証（SPF・DKIM・DMARC）を自社ドメインで設定し、DMARC レポートで自社ドメインを名乗る未知の送信元がないかを見る（送信者ドメインの認証）

場面3：漏えいが起きたときの初動

委託先から通知が来た時点で、次の順に動きます。

  1. 事実の確認：何が、いつから、どの範囲で漏れた可能性があるかを委託先に確認する。公式発表のURLと日時を記録する
  2. 鍵の無効化：そのサービスの APIキーをすべて再発行し、パスワードを変更する。同じパスワードを他のサービスでも使っていた場合はそちらも変更する
  3. 影響範囲の特定：預けていた項目（メールアドレスだけか、氏名や属性も含むか）と件数を、自社側の記録で確認する
  4. 報告の要否を判断：要配慮個人情報、財産的被害のおそれ、不正目的の可能性、1,000人超のいずれかに当たれば、個人情報保護委員会への報告と本人への通知が必要です（個人情報保護法第26条）。速報は把握後おおむね3〜5日以内、確報は30日以内（不正目的の場合は60日以内）。委託先と連名で報告できる場合もあります
  5. 受信者への注意喚起：漏えいした配信先に向けて、なりすましメールへの注意を告げる。配信サービスが停止していると送れないため、Webサイトでの告知と、別の送信手段を用意する
  6. 記録を残す：判断の経緯、連絡の日時、公表文を時系列で残す。後日の問い合わせや監査に備える

重要： 「配信サービスの問題なので自社は無関係」という説明は通りません。委託元として、本人への通知と報告の判断は自社が行います。

場面4：乗り換えに備える

事故や長期停止が起きてからでは遅いので、平時に次を整えておきます。

  • 連絡先と配信停止リストをいつでもエクスポートできることを確認し、四半期に1回は実際に書き出して保管する（保管場所は暗号化し、不要になったら削除）
  • 配信停止した人のリストは乗り換え先にも必ず引き継ぐ。引き継ぎ漏れは、解除済みの人に再送する事故になる
  • 送信ドメインは自社ドメインで認証しておく。サービス固有のドメインで送っていると、乗り換え時に評判をゼロから作り直すことになる
  • フォームや API 連携は、サービス固有の仕様を1か所にまとめておき、差し替えやすくする
  • 乗り換え先の候補を1つ決め、無料プランでアカウントを作って認証まで済ませておく。HubSpot から Brevo への移行チェックリストは、他サービスからの移行でも手順の参考になります

Brevoでの対応状況

上のチェックリストを Brevo に当てはめると、2026年10月28日時点で次のとおりです。

項目Brevoでの状況自分でやること
第三者認証・保管場所公式サイトに ISO 27001 認証と EU 内サーバーでの保管を記載契約前にセキュリティページと DPA を確認
二要素認証「Settings（設定）」→「Security（セキュリティ）」→「Two-factor authentication（二要素認証）」タブで有効化。有効にするとアカウントの全ユーザーが次回ログイン時に設定を求められる必ず有効化し、復旧用のバックアップコードを安全に保管
重要操作の再認証二要素認証の設定変更、API・SMTP キーの発行、ログイン用メールアドレスやパスワードの変更時に本人確認を求める（Brevo のリリースノート）なし
API・SMTP キーの IP 制限「Security（セキュリティ）」→「Authorized IPs（許可IP）」で許可リストを作り、「Block unknown IP addresses（未知のIPをブロック）」を有効化。初期状態では無効。許可 IP のリストは API キーと SMTP キーで共通連携サーバーの固定 IP を登録してから有効化
APIキーの発行「SMTP & API」→「API keys（APIキー）」タブで発行。キーは発行時に1回だけ表示。通常の API キーはキー単位で権限を絞れず、アカウント全体にアクセスできる。開発者向けドキュメントは、サーバー間連携には範囲を絞った短命のトークン（M2M 認証）を勧めている用途ごとに発行、保管、不要なら削除。新規のサーバー間連携は M2M を検討
ユーザー数と権限招待できる人数はプランで決まる。Free・Starter はオーナー1人のみ、Standard は最大3人（追加1人あたり月 $12）、Professional は10人、Enterprise は無制限。「Settings（設定）」→「Users（ユーザー）」で招待時に権限を個別に設定。定型の「ロール」は Enterprise プラン向け共有ログインをやめ、1人1アカウントにできるプランを選ぶ。エクスポートとキー発行の権限を絞る
操作ログ「Settings（設定）」→「Users（ユーザー）」→「Activity logs（アクティビティログ）」で、ログイン・ログアウト、ユーザー管理、APIキーの管理、ドメイン・送信者の変更などを、IP アドレス付きで確認できる。保存期間は Enterprise 以外90日、Enterprise は12か月。CSV 出力は Enterprise のみ。現時点ではキャンペーンや連絡先の操作は対象外月1回確認し、見覚えのないログインや APIキーの作成がないか見る
送信ログの保存期間トランザクションメールのログは初期設定では無期限に保存。「Settings（設定）」→「Transactional emails（トランザクションメール）」→「Retention rules（保存ルール）」で1〜24か月に設定できる。送信イベントが1,000万件を超えるアカウントは、設定にかかわらず24か月で自動削除社内の保存方針に合わせて保存期間を設定する
連絡先の削除管理画面と API から削除可能削除基準を決めて定期実行

Brevo の全体像はBrevo（旧Sendinblue）とは？、用語はAPIキー・二要素認証・権限ロールを参照してください。

よくある疑問

Q. 無料プランでも二要素認証や IP 制限は使えますか？ A. 二要素認証と許可 IP の設定はアカウントの「Security（セキュリティ）」メニューにあり、プランによる制限はヘルプに記載されていません。一方、ユーザーの招待は Free・Starter ではできず（オーナー1人のみ）、Standard 以上が必要です。複数人で運用する場合は、ログイン情報を共有せずに済むプランを選んでください。

Q. 委託先がしっかりしていれば、自社の契約は不要ですか？ A. 不要にはなりません。個人情報保護法は委託元に監督義務を課しており、委託契約（または利用規約と DPA）で、取扱いの範囲・再委託・事故時の通知・終了時の削除を確認しておく必要があります。

Q. 配信先のメールアドレスだけなら、漏れても報告は不要ですか？ A. メールアドレスだけでも、1,000人を超える場合や不正目的のおそれがある場合は報告対象になります。氏名と組み合わさっていればなおさらです。「おそれ」の段階で速報の判断をするため、判断を先送りしないでください。

Q. 事故が起きたサービスから、すぐに乗り換えるべきですか？ A. 事故の有無より、公表のしかたと再発防止策の内容で判断することを勧めます。乗り換え自体にもリスク（配信停止リストの引き継ぎ漏れ、ドメイン評判の再構築）があるため、場面4の準備ができているかを先に確認してください。

出典（確認日：2026年10月28日）

関連記事

活用ガイド一覧へ戻る