--- title: "ブラストメール不正アクセス：配信先288件の漏えいと利用企業の報告・通知の手順" url: "https://www.issoh.co.jp/tech/details/18827/" published: 2026-10-24 updated: 2026-10-24 categories: ["セキュリティ"] publisher: "株式会社一創" --- # ブラストメール不正アクセス：配信先288件の漏えいと利用企業の報告・通知の手順 ラクスの子会社ラクスライトクラウドが提供するメール配信システム「ブラストメール」に外部から不正アクセスがあり、全契約者の登録情報と、一部の契約者の配信先リストが持ち出されました。サービスは2026年10月21日0時30分から止まったままで、再開日時は未定です。本記事の前半では、公式発表で確認できる漏えいの範囲・件数・時系列と、メルマガの読者が自分は対象かを確かめる方法を整理します。中盤は利用企業の担当者向けに、10月29日締切の連名報告と読者への通知の段取りをまとめました。後半は開発者向けに、漏れた配信先へのなりすましに備えるDMARCの確認と、APIサーバーから届くデータベースを洗い出すコマンドを示します。 ## まとめ：ブラストメール不正アクセスで公表された事実と利用企業・読者の対応 持ち出しは2系統に分かれます。販売管理システムからは全契約者の会社名・担当者名・連絡先・契約と支払いの履歴が、サービスのデータベースからは一部の契約者の配信先リストなどが持ち出されました。配信先リストの漏えいが確認された契約は、10月23日17時時点で288件です。 | 項目 | 公表内容（2026年10月23日17時更新版） | | ------ | ----------------------- | | サービス停止 | 10月21日0時30分から継続 | | 侵入の経路 | API用サーバー2台から社内DBへ | | 全契約者分 | 会社名・担当者名・連絡先など | | 配信先リスト | 288件の契約で漏えいを確認 | | カード番号 | 保持しておらず対象外 | | 再開日時 | 未定（外部調査が進行中） | | 連名報告 | 10月29日まで受付 | 利用企業がまず決めるのは、個人情報保護委員会への報告を連名で出すか自社で出すかです。配信先リストが漏れた288件に入っていれば、読者への通知は自社で行います。読者の側は、配信元からの個別の案内を待ちつつ、メルマガの差出人を名乗る不審なメールのリンクを開かないことが当面の備えになります。 ## 公式発表で確かめるブラストメール不正アクセスの漏えい範囲と時系列 ### 全契約者の販売管理情報と配信先リスト288件に分かれる漏えいの範囲 [ラクスの10月21日の第2報](https://www.rakus.co.jp/news/2026/1021-3.html)によると、販売管理システムから持ち出されたのは全契約者の会社名・担当者名・電話番号・メールアドレス・請求先メールアドレス・契約と支払いの履歴などです。クレジットカード番号は同社が保持しておらず、対象に入っていません。 読者の情報に関わるのは、もう一方の配信先リストです。[ブラストメールのお知らせページ](https://info.blastmail.jp/information%5F20261021.html)の10月23日17時更新版は、契約者情報以外の漏えいが確認された契約を288件とし、288件すべてへの個別連絡が済んだと書いています。同ページは数値が調査の進み具合で変わる可能性にも触れており、対象の調査は継続中です。 ここでいう288件は契約の数で、読者の人数ではありません。1つの契約が数万件のアドレスを持つリストを預けていることもあり、影響を受けた読者の総数は公表されていません。 ### 10月21日0時30分の緊急停止から10月23日17時更新までの時系列 1. 10月21日0時30分頃：不審なアクセスを検知し、サービスを緊急停止（メール配信は1時頃から停止） 2. 10月21日：[ラクスが第1報](https://www.rakus.co.jp/news/2026/1021-2.html)を公表し、個人情報保護委員会とJIPDECへ報告済みと説明 3. 10月21日：第2報で不正アクセスとデータの持ち出しを確認したと公表 4. 10月23日14時：お知らせページで調査の進み具合を報告 5. 10月23日17時：288件の契約で配信先リスト等の漏えいを確認し、個別連絡を完了と更新 同ページは、社内の調査を10月24日10時頃に終える予定とし、専門機関による外部調査は完了の目途が立ちしだい知らせるとしています。管理画面とAPIも使えない状態です。本記事は10月24日に公式ページを確認した時点の内容で、その時点の最新は10月23日17時更新版でした。 ### メルマガの読者が自分のアドレスの漏えいを確かめる方法と不審メールの見分け方 読者が自分で照会できる窓口は、ブラストメール側には設けられていません。配信先リストを預けていたのは各メルマガの配信元なので、自分のアドレスが含まれるかは、登録していた企業・自治体・団体からの案内で確かめます。配信元のWebサイトに「ブラストメール」や「ラクスライトクラウド」の名前を含むお知らせが出ていれば、その配信元が利用者です。 漏れたのがメールアドレスなら、狙われやすいのは差出人を装ったフィッシングメールです。見分けるときは、普段のメルマガと送信元のドメインが同じか、ログインやカード情報の入力を急かしていないかを見ます。疑わしいメールのリンクは開かず、配信元の公式サイトを自分で開いて確かめる方法が確実です。 ## 利用企業が今週中に進める連名報告・本人通知・代替配信の段取り ### 10月29日締切の連名報告と、Pマーク事業者や自治体が別に動く範囲 [連名報告の案内ページ](https://info.blastmail.jp/information%5Fjoint%5Freport.html)によると、ラクスライトクラウドは個人情報保護委員会への報告を利用企業と連名で出す手続きを用意しています。申込みはGoogleフォームで、期限は10月29日です。連名を選べば利用企業が個別に報告する必要はなく、速報の目安期間を過ぎても遅延として扱わないことを委員会に確認済みとしています。 連名での報告でも、自社で対応する部分は次の2つです。プライバシーマークの付与事業者は、JIPDECへの報告を個別に行います。配信先リストの漏えいが確認された企業は、本人への通知を自社で行います。 [個人情報保護委員会の案内](https://www.ppc.go.jp/personalinfo/legal/leakAction/)では、不正の目的によるおそれがある漏えいは件数にかかわらず報告対象で、確報の期限は発覚から60日以内です。行政機関等は本人の数が100人を超えると報告対象になるので、防災・防犯メールを配信していた自治体は件数の基準でも該当しやすくなります。速報と確報の書き方は[個人情報保護委員会への報告義務の実務](https://www.issoh.co.jp/column/details/17840/)で解説しています。 ### 配信先リストが漏れた288件の利用企業が読者へ送る通知の4項目 個別連絡を受けた企業が読者に伝える内容は、次の4つに絞れます。 - 漏えいした項目（メールアドレスのみか、氏名や属性も含むか）と、預けていたリストの名前 - 委託先のメール配信サービスへの不正アクセスが原因であること - 差出人を装ったメールへの注意と、正規の連絡で使う送信元ドメイン - 問い合わせ窓口と、配信を止めたい場合の手続き 通知の手段で迷うのは、普段の配信手段そのものが止まっている点です。数千件を超える宛先へ一斉に送る代替手段が用意できないうちは、公式サイトのお知らせを先に掲載し、メールでの通知はその掲載ページへ誘導する形にすると、なりすましとの区別もつけやすくなります。 ### サービス停止中の緊急連絡を別の配信手段で送るときの同意と送信元 防災情報や予約の通知など、止められない配信を別のサービスへ移す場合は、配信先リストの最新版が手元にあるかが最初の関門です。ブラストメールの管理画面は使えないため、自社の会員データベースや申込みフォームの記録から作り直すことになります。 移す先でも、特定電子メール法が求める送信者の名称と受信拒否の連絡先の表示、配信停止を受け付けた宛先の除外は引き継ぐ必要がある項目です。送信元ドメインのSPFやDKIMを新しい配信サービス向けに追加しないと、迷惑メールに振り分けられる率が上がります。配信サービスを選び直す際の比較軸は[メール配信システムの選定軸（到達率・機能・料金）](https://www.issoh.co.jp/column/details/15318/)にまとめています。 ## なりすましメールに備える送信ドメイン認証：DMARCの確認と段階的な強化 ### 漏れた配信先リストが狙われる手口と、送信元ドメインを守るDMARC 配信先リストを手にした攻撃者にとって効率のよい手口は、そのメルマガの差出人を装って同じ宛先へ送ることです。読者はその配信元からのメールを日頃から受け取っているため、件名や差出人名が似ていれば開いてしまいます。 送信元ドメインの詐称を受信側に拒否させる仕組みがDMARCです。2026年に公開された[RFC 9989](https://www.rfc-editor.org/info/rfc9989/)が従来のRFC 7489を置き換えましたが、ドメイン所有者がDNSのTXTレコードで方針（`p=none`・`quarantine`・`reject`）を宣言する骨格は同じです。`p=none`のままでは、SPFとDKIMに失敗した詐称メールも受信側の判断で届いてしまいます。 ### digで自社ドメインのSPF・DMARCを確かめ、p=rejectへ上げる手順 自社のメルマガで使っている送信元ドメインについて、現在の設定を確かめます。`example.co.jp`を自社のドメインに置き換えて実行してください。 ``` # 1. SPF：v=spf1 で始まる行に、今使っている配信サービスの記述があるか dig +short TXT example.co.jp # 2. DMARC：_dmarc サブドメインの TXT レコード。何も返らなければ未設定 dig +short TXT _dmarc.example.co.jp # 3. 段階的に強める DMARC レコードの例（DNS のゾーンに登録する） # まず quarantine で迷惑メールフォルダへ、集計レポートで正規の送信元が漏れていないか確かめる _dmarc.example.co.jp. 3600 IN TXT "v=DMARC1; p=quarantine" # 正規の送信元が全て SPF か DKIM で合格するのを確かめてから reject へ _dmarc.example.co.jp. 3600 IN TXT "v=DMARC1; p=reject" ``` 集計レポートを受け取るには`rua`タグに受信用のアドレスを加えます。いきなり`p=reject`にすると、SPFに書き忘れた請求システムや問い合わせフォームのメールまで届かなくなる場合があります。上のコマンドとレコードは本記事の環境では実行しておらず、RFC 9989の方針タグの定義に基づく記載です。 実務でまず確かめるのは2番目のコマンドです。何も返らない、または`p=none`のままなら、漏れたリストへの詐称メールを止める手段を持っていない状態にあります。 ## APIサーバーから販売管理DBへ届いた構造：開発者が見直す接続経路と権限 ### 公開APIサーバー2台への侵入が販売管理システムとサービスDBに広がった経路 お知らせページは原因を「API用のサーバー2台に侵入してコマンドを実行し、そこから販売管理システムとサービスのデータベースに接続して、データを持ち出した」と説明しています。侵入経路の詳細は調査中です。 確かなのは、外部からの要求を受けるAPIサーバーから、契約や請求を管理する販売管理システムのデータベースへ接続できたという点です。配信に使うデータベースへの接続はAPIの役割上必要でも、販売管理側まで同じサーバーから届く必要はありません。侵入口を塞ぐ対策（レート制限・認可・トークン失効）は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)で扱っています。ここでは、突破された後に届く範囲を狭める側の点検を示します。 なお、ブラストメールが使っているクラウドやデータベース製品は公表されていません。以下のAWSとPostgreSQLは、同じ構造を点検するための例です。 ### AWS CLIでAPIサーバーから届くDBのセキュリティグループを洗い出す AWSのセキュリティグループでは、許可元として別のセキュリティグループを指定することが可能です。[Amazon VPCのセキュリティグループのルール](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html)の説明どおり、その場合は指定したグループに属するインスタンスからの通信が許可されます。APIサーバーのグループを許可元に持つルールを数えれば、侵入されたAPIサーバーから届く先が一覧になります。 ``` # APIサーバーのセキュリティグループを許可元に持つグループ（＝APIサーバーから届く先） aws ec2 describe-security-groups \ --filters Name=ip-permission.group-id,Values=sg-0123456789abcdef0 \ --query 'SecurityGroups[].[GroupId,GroupName]' --output table # データベースのポート（PostgreSQL なら 5432）を開けているグループと許可元 aws ec2 describe-security-groups \ --filters Name=ip-permission.from-port,Values=5432 \ --query 'SecurityGroups[].{id:GroupId,name:GroupName,from_sg:IpPermissions[].UserIdGroupPairs[].GroupId,from_cidr:IpPermissions[].IpRanges[].CidrIp}' \ --output json ``` フィルタ名`ip-permission.group-id`と`ip-permission.from-port`は[AWS CLIのdescribe-security-groupsのリファレンス](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-security-groups.html)に載っているものです。1本目の結果に販売管理や請求のデータベースが出てきたら、今回と同じ条件がそろっています。上のコマンドは本記事の環境では実行していません。 ### pg\_hba.confとDBユーザーで販売管理DBへの接続元を絞る設定例 ネットワークで届いても、データベース側で接続元と接続先を絞れば、もう一段で接続を止めることが可能です。PostgreSQLでは[pg\_hba.conf](https://www.postgresql.org/docs/current/auth-pg-hba-conf.html)に、接続の種類・データベース・ユーザー・接続元アドレス・認証方式を1行ずつ書きます。上から順に評価して最初に一致した行が使われるため、許可を先に、拒否を最後に置きます。 ``` # TYPE DATABASE USER ADDRESS METHOD # 販売管理DBは社内の業務用サブネットからだけ受ける hostssl sales sales_app 10.0.20.0/24 scram-sha-256 # APIサーバーのサブネットからは配信用DBの専用ユーザーだけ hostssl delivery api_rw 10.0.10.0/24 scram-sha-256 # ほかの組み合わせは全て拒否 host all all 0.0.0.0/0 reject -- 編集後、スーパーユーザーで再読み込みし、読み込まれた規則を確かめる SELECT pg_reload_conf(); SELECT line_number, type, database, user_name, address, auth_method FROM pg_hba_file_rules ORDER BY line_number; ``` この設定なら、APIサーバーのサブネットから`sales`へ接続しようとしても最後の行で拒否されます。APIサーバーに置く接続情報も`api_rw`の1つだけにし、販売管理DBのパスワードを置かないことが前提です。設定は本記事の環境では実行しておらず、PostgreSQL公式ドキュメントの書式に基づきます。データベースユーザーに渡す列や行を絞る方法は[ACCESS CROS不正アクセスとDB権限の締め方](https://www.issoh.co.jp/tech/details/18799/)で、APIサーバーに置く鍵の失効手順は[APIキー管理の発行・保管・失効](https://www.issoh.co.jp/tech/details/16300/)で解説しています。 ## 利用企業の判断：外部のメール配信サービスに預けるデータと点検の範囲 ### 配信先リストに氏名や属性を載せない設計と、自前構築を選ばない場面 今回、配信先リストの漏えいが確認された契約は288件でした。リストにメールアドレスしか載せていなければ、漏れる項目もメールアドレスだけで済みます。氏名・会社名・購買履歴などの属性を差し込みや絞り込みのために配信サービスへ預けているなら、配信に本当に要る列かを見直す時期です。 外部サービスでの事故を受けて、配信基盤を自前で作る選択肢を考える企業もあります。ただし、月数万通以下の配信で専任の運用担当を置けないなら、自前構築は過剰です。到達率の維持・バウンス処理・ブラックリスト対応を自社で抱えることになり、侵入された場合の責任も全て自社に移ります。自前構築の作業量は[メール配信システムの自作とSMTP基盤設計](https://www.issoh.co.jp/tech/details/15331/)で確かめられます。預けるデータを減らし、DMARCを`p=reject`まで上げるほうが、多くの企業には効果が大きいはずです。 ### APIサーバーと業務DBを同じ網に置く自社システムで見直しを急ぐ構成 見直しを急ぐべきなのは、外部に公開しているAPIやWebアプリのサーバーと、販売管理・請求・会員管理のデータベースが同じネットワークにあり、接続制限が無い構成です。点検は3点に絞れます。公開サーバーのセキュリティグループから業務DBへ届くか、公開サーバーに業務DBの接続情報が置かれていないか、データベース側で接続元のアドレスとユーザーを絞っているか、です。1点目と2点目がそろうと、公開サーバー1台の穴が業務データ全体の穴になります。 この3点は設定を見れば判断できますが、実際に外から突ける穴があるかは、運用担当者が自分で確かめられる範囲に限界があります。公開APIと業務DBの接続経路を外部の目で点検するなら、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で相談できます。 ## よくある質問 ブラストメールへの不正アクセスについて、利用企業の担当者や読者から出やすい質問をまとめました。 ### ブラストメールの不正アクセスで漏れた情報は何ですか？ 全契約者について、会社名・担当者名・電話番号・メールアドレス・請求先メールアドレス・契約と支払いの履歴などが販売管理システムから持ち出されました。加えて、一部の契約者の配信先リストなど配信に関する情報も漏えいしており、10月23日17時時点で288件の契約が該当するとされています。 ### メルマガを受け取っていただけの自分のメールアドレスも漏れましたか？ 配信先リストが漏れたのは288件の契約に限られ、全ての読者が対象ではありません。自分が対象かは、メルマガの配信元である企業や自治体からの案内で確かめます。ブラストメール側に読者が直接照会する窓口は案内されていません。配信元を名乗る不審なメールのリンクは開かないでください。 ### ブラストメールのサービスはいつ再開しますか？ 10月23日17時更新版のお知らせでは、再開日時は未定です。社内の調査は10月24日10時頃に終える予定で、専門機関の外部調査は完了の目途が立ちしだい知らせるとしています。管理画面とAPIも使えない状態のため、止められない配信は別の手段を用意する必要があります。 ### クレジットカード情報は漏れましたか？ ラクスの第2報は、クレジットカード番号は同社が保持していないと説明しています。持ち出された販売管理の情報には契約と支払いの履歴が含まれますが、カード番号は対象外です。請求先のメールアドレスが漏れているため、請求や支払いを装うメールには注意が要ります。 ### ラクスが10月22日に出したPHPの脆弱性の告知とは関係がありますか？ ラクスは10月22日、[特定脆弱性への対応状況](https://www.rakus.co.jp/news/2026/1022-2.html)としてPHPの脆弱性（CVE-2026-109618・CVE-2026-109619）への対応を公表し、自社の全サービスで影響はないとしています。この告知にブラストメールの記載はなく、今回の侵入経路との関係は公表されていません。 ## 関連記事 - [API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効](https://www.issoh.co.jp/tech/details/18346/)：APIサーバーへの侵入口を塞ぐ対策 - [ACCESS CROS不正アクセス：BIツール起点の15万件流出とDB権限・送信キーの締め方](https://www.issoh.co.jp/tech/details/18799/)：同時期にメール送信の鍵が悪用された別の事例 - [情報漏洩対策とは：原因別4類型の防ぎ方と発生時の報告義務【2026年10月版】](https://www.issoh.co.jp/column/details/18315/)：委託先経由を含む漏えいの防ぎ方 - [不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順](https://www.issoh.co.jp/column/details/18313/)：企業として点検する範囲の全体像 - [メール配信システムのおすすめ比較と選び方｜到達率・機能・料金の選定軸を解説](https://www.issoh.co.jp/column/details/15318/)：配信サービスを選び直すときの比較軸 --- 出典: [ブラストメール不正アクセス：配信先288件の漏えいと利用企業の報告・通知の手順]()（株式会社一創）