SMBC日興証券の不正アクセス：持株会会員最大5.6万人の範囲と受託システムの分離設計

SMBC日興証券は2026年11月11日、持株会の事務受託業務で使っている持株会管理システムが第三者の不正アクセスを受け、最大56,487人の会員の個人情報が漏えいしたと公表しました。漏えいした可能性がある項目には、氏名・住所に加えて持株会名・持分残高・振替先口座情報が含まれます。本記事では公表文をもとに経過と範囲を整理し、電話番号やメールアドレスが漏れていなくても残る詐欺の経路と、会員と持株会事務局が今日やる点検をまとめる構成です。後半では、多数の持株会のデータを1つのシステムで預かる側が、持株会ごとにデータを分けて口座情報を暗号化する実装を、そのまま試せるコードで示します。

まとめ：SMBC日興証券の持株会システム不正アクセスで確定した事実と今やること

公表文で確定しているのは、11月9日に不正アクセスを確認して同日中にシステムへのアクセスを遮断し、サービスを一時停止したこと、その後の調査で外部への漏えいを確認したこと、対象が最大56,487人の会員であることです。侵入の経路と時期、影響を受けた持株会の数は明らかにされていません。

会員がまず備えるのは、同社や勤務先の持株会事務局を名乗る郵便・電話・メールです。開発者の側で見るべき論点は別にあります。1つの事務受託システムに、多数の企業の持株会と会員のデータが同居していた点です。1か所が破られると全ての委託元に被害が及ぶ構造を、テナント分離と暗号化の設計で小さくできるかを自社に引き寄せて点検します。

公表内容を時系列で確認する｜11月9日の遮断から11月11日の公表までの経過

持株会の事務受託で使う管理システムが第三者の不正アクセスを受けた経過

SMBC日興証券の公表文（2026年11月11日）によると、同社は持株会から会員持分の計算などの事務を受託しており、事務を委託している持株会とその会員に持株会管理システムを提供していました。このシステムが第三者による不正アクセスを受け、一部の持株会の会員の個人情報が外部へ漏えいしたと説明しています。

不正アクセスを確認したのは2026年11月9日（月）です。同社は被害拡大の防止を最優先に、同日中にシステムへのアクセスを遮断し、サービスを一時停止しました。その後の調査の過程で漏えいを確認し、確認から2日後に公表しています。システムの再開は、個別の連絡や同社のホームページで知らせるとしています。

最大56,487人と8項目の内訳、電話番号とメールアドレスが対象外の理由

漏えいした、またはその可能性がある項目として公表文が挙げているのは次の8つです。

• 持株会名
• 投資銘柄情報
• 会員識別番号
• 氏名
• 住所
• 配当金および諸税
• 持分残高
• 振替先口座情報

公表文は、漏えいした項目は会員ごとに異なり、対象の会員全員について8項目全てが漏れたわけではないと補足しています。電話番号とメールアドレスは、このシステムにもともと登録されていないため漏えいはありません。対象になった会員は最大56,487人です。

侵入経路・時期・影響した持株会の数が未公表の段階で書けないこと

公表文は、どの経路から入られたか、いつから不正アクセスが続いていたか、何社の持株会が影響を受けたかに触れていません。同社は関係各所と連携して原因と影響範囲の詳細な調査を進めているとしており、2026年11月11日時点で続報は出ていません。

そのため本記事では、特定の脆弱性や製品に結び付けた推測はしません。読み取れるのは構図です。多数の企業の持株会が、1つの事務受託システムに会員の名簿と口座情報を預けていて、そこが破られました。後半の実装の話は、この構図を前提にしています。

持株会名と振替先口座の組み合わせで起きる悪用｜電話とメールが無くても残る詐欺の経路

持株会名から勤務先が分かることで成り立つ社内向けのなりすまし

持株会名は、多くの場合そのまま勤務先の社名を表します。氏名と持株会名がそろえば、攻撃者にとって「どの会社に勤める誰か」を知る手掛かりになるのです。電話番号とメールアドレスは漏れていませんが、勤務先が分かれば、会社のメールアドレスの付け方から宛先を推測される余地は残ります。

想定されるのは、持株会事務局や人事部を名乗り「持株会システム停止に伴う登録内容の再確認」などを装う社内向けの偽メールです。本物の事故が報じられた直後は、こうした文面が信じられやすくなります。仕組みの全体はフィッシング詐欺とはで解説しています。

住所と持分残高を使った郵便・訪問の詐欺と振替先口座の書き換え依頼

住所・持分残高・配当金の額が分かると、「持株会の残高の返金手続き」や「配当金の再計算」を装った郵便を、実在の金額を書き込んで送れます。金額が正しい書面は、受け取った側が本物と判断しやすい材料です。

振替先口座情報は、払い出しや退会のときに引き出したお金を振り込む先です。この口座番号だけで預金を引き出すことはできません。警戒するのは、口座番号を示して本人らしさを装い、振込先の変更や「手数料」の振込を求める連絡です。

持株会の会員と事務局が今日やる点検手順｜SMBC日興を名乗る連絡の見分け方

会員が確認する連絡の経路と公表文が示した問い合わせ窓口の番号

同社は、漏えいまたはその可能性が確認された持株会の会員に個別に連絡するとしています。公表文に記載された会員向けの問い合わせ窓口は0120-715-250です。届いた郵便やメールに書かれた電話番号やリンクは使わず、公表文か同社の公式サイトで確かめた窓口へかけ直すのが確実です。

暗証番号やログイン用のパスワード、ワンタイムパスワードを電話やメールで聞かれたら、その時点で詐欺を疑ってください。不審なメールを受け取ったら、フィッシング対策協議会のサイトで同じ文面の報告が出ていないかを確認できます。持株会そのものの仕組みや加入の判断は持株会はやめたほうがいい？で別に整理しています。

持株会事務局（勤務先の担当部署）が社員へ出す注意喚起の要点と順番

勤務先の持株会事務局がまずやるのは、自社の持株会が対象かどうかをSMBC日興証券に確認することです。そのうえで社員への周知を、次の順番で出します。

1. 自社の持株会が対象か、どの項目が漏れたかを証券会社に確かめる
2. 事務局からメールで口座番号や暗証番号を聞くことは無いと社員に伝える
3. 振込先の変更や返金の手続きは、社内の決まった窓口でしか受けないと明示する
4. 不審な連絡を受けた社員の報告先を1つに決める

周知文そのものを偽メールの見本にされないよう、社内ポータルなど社員が自分で開く場所に掲示し、メールには掲示場所だけを書く形が安全です。

事務受託のシステムが狙われる理由｜複数の持株会の名簿が1か所に集まる構図

1つのシステムに多数の委託元が同居するマルチテナントの到達範囲

持株会の事務を受託する側は、多数の企業の持株会を1つのシステムで処理します。会員の名簿、持分、配当、振込先が、委託元の数だけ同じデータベースに並びます。運用の効率は上がりますが、攻撃者から見れば、1回の侵入で複数の企業の社員名簿と口座情報にまとめて届く場所です。

この到達範囲を決めるのは、侵入された後に「どこまで読めるか」です。アプリケーションの画面が持株会ごとに分かれていても、データベースの接続ユーザーが全ての行を読める作りなら、1つの経路が破られただけで全テナントの行が取り出せます。侵入の痕跡をログでどう追うかは不正アクセスの調べ方で整理しています。

提供側から漏れる同型事例：大和証券・ferret One・FaveConnect

同じ構図は2026年10月以降も続いています。問い合わせ管理の委託先から約11万人分の口座番号が漏れた大和証券の不正アクセスでは、大和証券自身のシステムへの侵入は確認されていません。ferret Oneの不正アクセスでは、利用企業3社が管理していた問い合わせ情報16,970件が提供元の基盤から取得されました。複数のファンクラブ会員11万7,392件が対象になったFaveConnectの不正アクセスも、入口はサービスの管理画面でした。

委託元の企業からは、受託先のデータベースの作りは見えません。受託する側がテナント分離と暗号化を設計に入れておくことが、委託元の社員を守る唯一の手段になります。委託先を経由した攻撃の型はサプライチェーン攻撃とはで整理しています。

持株会ごとにデータを分けるPostgreSQL行レベルセキュリティの実装手順

current_settingでテナントIDを渡して行レベルのポリシーを書くSQLの例

PostgreSQLには、テーブルの行ごとに読める範囲を制限する行セキュリティポリシー（Row Level Security）があります。2026年11月時点の現行版18系の文書では、行セキュリティを有効にしたテーブルはポリシーで許可された行しか読み書きできず、ポリシーが1つも無ければ全ての行が見えない既定拒否になると説明されています。次は持株会ID（kai_id）ごとに会員を分ける例です。

-- 持株会（テナント）ごとに会員データを分ける（PostgreSQL 18）
CREATE TABLE members (
  member_id   bigint  PRIMARY KEY,
  kai_id      integer NOT NULL,      -- 持株会ID
  name        text    NOT NULL,
  address     text,
  account_enc bytea                  -- 振替先口座（アプリ側で暗号化した値）
);

ALTER TABLE members ENABLE ROW LEVEL SECURITY;
ALTER TABLE members FORCE ROW LEVEL SECURITY;   -- 所有者にもポリシーを適用する

CREATE POLICY members_by_kai ON members
  USING      (kai_id = current_setting('app.kai_id')::integer)
  WITH CHECK (kai_id = current_setting('app.kai_id')::integer);

-- アプリ用のロール（テーブルの所有者でもBYPASSRLSでもない）
CREATE ROLE app_user LOGIN NOBYPASSRLS;
GRANT SELECT, INSERT, UPDATE ON members TO app_user;

-- リクエストごとに、トランザクションの中でテナントを指定する
BEGIN;
SELECT set_config('app.kai_id', '1024', true);  -- true＝このトランザクションの間だけ有効
SELECT member_id, name FROM members;            -- 持株会1024の行だけが返る
COMMIT;

set_configの第3引数をtrueにすると、設定はトランザクションの終了で消えます。接続プールで同じ接続を使い回しても、前のリクエストの持株会IDが残りません。設定しないまま問い合わせると型変換か未定義の設定でエラーになり、行が返らない側に倒れます。

所有者とBYPASSRLSのロールがポリシーを素通りする落とし穴の点検

公式文書は、スーパーユーザーとBYPASSRLS属性を持つロールは常に行セキュリティを迂回し、テーブルの所有者も通常は迂回すると明記しています。マイグレーションに使う所有者ロールのままアプリを接続していると、ポリシーを書いても効きません。次のSQLで、素通りするロールと行セキュリティが無効なテーブルを洗い出せます。

-- 行セキュリティを素通りするロール
SELECT rolname, rolsuper, rolbypassrls
  FROM pg_roles
 WHERE rolsuper OR rolbypassrls;

-- 行セキュリティが無効なテーブル（publicスキーマ）
SELECT relname, relrowsecurity, relforcerowsecurity
  FROM pg_class
 WHERE relkind = 'r'
   AND relnamespace = 'public'::regnamespace
   AND NOT relrowsecurity;

1つ目の結果にアプリの接続ユーザーが出たら、その時点でテナント分離は成り立っていません。2つ目に会員や口座を持つテーブルが出たら、ポリシーの書き忘れです。APIの入口側で認可を固める手順はAPI不正アクセス対策の実装手順と組み合わせて点検します。

振替先口座をアプリ側で暗号化する｜持株会ごとの鍵でAES-GCMを使うPython実装

cryptographyのAESGCMで口座暗号化と持株会IDの関連データ指定

行セキュリティは、アプリの接続ユーザーで読める範囲を絞る仕組みです。データベースの管理者権限やバックアップファイルが奪われた場合は効きません。そこで振替先口座のように悪用の価値が高い列は、アプリ側で暗号化してから保存する設計にするのです。PostgreSQLのpgcryptoも列の暗号化に使えますが、公式文書は全ての関数がサーバー内で動き、データと鍵が平文でサーバーへ渡ると注意しています。管理者を信頼できない前提なら、暗号化はアプリ側で行います。

# 振替先口座をアプリ側で暗号化する（Python 3・cryptography）
import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

def load_kai_key(kai_id: int) -> bytes:
    # 持株会ごとのデータ鍵。本番はKMSで包んだ鍵を復号して使う（ここでは環境変数で代用）
    return bytes.fromhex(os.environ[f"KAI_KEY_{kai_id}"])

def encrypt_account(kai_id: int, account: str) -> bytes:
    nonce = os.urandom(12)                  # 96ビット。同じ鍵で同じ値を使い回さない
    aad = f"kai:{kai_id}".encode()          # 持株会IDを関連データとして結び付ける
    ct = AESGCM(load_kai_key(kai_id)).encrypt(nonce, account.encode(), aad)
    return nonce + ct                       # bytea列にそのまま保存する

def decrypt_account(kai_id: int, blob: bytes) -> str:
    aad = f"kai:{kai_id}".encode()
    return AESGCM(load_kai_key(kai_id)).decrypt(blob[:12], blob[12:], aad).decode()

if __name__ == "__main__":
    os.environ["KAI_KEY_1024"] = AESGCM.generate_key(bit_length=256).hex()
    blob = encrypt_account(1024, "0009-123-1234567")
    print(len(blob), decrypt_account(1024, blob))
    # 別の持株会IDを関連データに渡して復号すると InvalidTag で失敗する

cryptographyのAESGCMは、暗号化と同時に改ざん検知のタグを付けます。持株会IDを関連データ（associated data）に入れておくと、ある持株会の暗号文を別の持株会の行へ書き写しても復号に失敗します。鍵を持株会ごとに分ければ、1つの鍵が漏れても読めるのはその持株会の口座だけです。鍵の包み方と権限設計はAWS KMSとはで、データベース側の暗号化方式の比較はPostgreSQLの暗号化で解説しています。

口座情報の暗号化とテナント分離を採用する条件と過剰になる場面の線引き

複数の委託元のデータを1つのシステムで預かり、その中に口座番号・残高・住所のような財産に結び付く項目があるなら、行セキュリティとアプリ側暗号化の両方を入れます。持株会の事務受託、給与や福利厚生の代行、会員制サービスの基盤がこれに当たります。どちらか一方では、アプリ経由の侵入と管理者権限の奪取のどちらかが素通しになるためです。

一方で、委託元が1社だけの専用システムに持株会ごとの鍵を入れるのは過剰です。テナントが1つなら分ける対象が無く、増えるのは鍵管理の手間だけです。その場合は口座番号の列だけを暗号化し、監査ログで大量の読み出しを検知する方へ手間を回します。ログを欠けなく残す基盤の作り方はFluentdで監査ログ基盤を作るで示しています。

漏えい後の報告義務と委託先の通知｜個人情報保護法第26条と規則第9条の整理

委託元と委託先の双方が負う報告義務と委託元への通知による例外

事務を受託した側で漏えいが起きた場合、個人情報保護委員会への報告は誰が行うのか。個人情報保護委員会のFAQ（Q3-8）は、原則として委託元と委託先の双方が報告義務を負い、連名で報告することもできると説明しています。そのうえで、委託先が報告義務を負う委託元に事態の発生を通知した場合は、個人情報保護法第26条第1項ただし書と施行規則第9条により、委託先の報告義務が免除されるとしています。

免除されるのは委託先だけで、委託元の報告義務は残ります。通則編ガイドラインの3-5-3-5は、通知を受けた後も委託先に事態の把握や委託元の報告への協力を求めています。受託システムを運用する側は、どの委託元のどの項目が漏れたかを持株会単位ですぐ出せるようにしておくことが必要です。テナントIDで行を分けておく設計は、この集計にもそのまま効きます。

速報3〜5日・確報30日と不正目的の60日、委託元が準備する記録

個人情報保護委員会の案内によると、報告の対象には本人の数が1,000人を超える漏えいや、不正の目的をもって行われたおそれがある漏えいが含まれます。速報は発覚日から3〜5日以内、確報は30日以内で、不正な目的で行われたおそれがある場合の確報は60日以内です。第三者の不正アクセスによる漏えいは、件数にかかわらず不正目的の類型に当たりえます。

委託元が確報までに用意するのは、委託先からの通知の日時、対象の本人と項目の一覧、本人への通知の方法と日付です。類型の見分け方と報告の段取りは個人情報保護委員会への報告義務で詳しく扱っています。受託システムが外部からどこまで読めるかを第三者の目で確かめたい場合は、脆弱性診断・セキュリティ診断で、ログイン画面からデータベースの権限設定までの経路を含めて点検できます。

よくある質問

SMBC日興証券の不正アクセスについて、持株会の会員と開発者から出やすい質問をまとめました。

SMBC日興証券のどの情報が漏洩したのですか？

公表文によると、持株会管理システムに登録された、持株会名・投資銘柄情報・会員識別番号・氏名・住所・配当金および諸税・持分残高・振替先口座情報が対象になりえます。項目は会員ごとに異なり、全員について全項目が漏れたわけではありません。電話番号とメールアドレスはシステムに登録が無く、漏えいしていません。

SMBC日興証券の証券口座を持っているだけでも対象になりますか？

今回の対象は、同社が事務を受託している持株会の会員です。公表文は持株会管理システムへの不正アクセスとしており、一般の証券口座の取引システムが侵害されたとは書いていません。勤務先の持株会に加入している場合は、持株会事務局か同社からの個別連絡を確認してください。

自分が対象かどうかはどうすれば分かりますか？

同社は、漏えいまたはその可能性が確認された持株会の会員に個別に連絡するとしています。公表文に記載された窓口は0120-715-250です。届いた連絡に書かれた番号やリンクは使わず、公表文か公式サイトで確かめた番号にかけてください。勤務先の持株会事務局に確認する方法もあります。

振替先口座の番号が漏れると預金を引き出されますか？

口座番号だけで預金を引き出すことはできません。警戒が必要なのは、正しい口座番号や持分残高を示して本人らしさを装い、振込先の変更や手数料の振込、暗証番号の入力を求める連絡です。持株会や証券会社がメールや電話で暗証番号を聞くことはないため、聞かれた時点で詐欺を疑ってください。

持株会の事務を受託するシステムは何から見直せばよいですか？

最初に、アプリがデータベースへ接続するユーザーで全テナントの行が読めないかを確かめます。読めるなら、行レベルセキュリティでテナントごとに分け、所有者ロールやBYPASSRLSのロールでアプリを接続していないかも点検します。次に、口座番号のような列をアプリ側で暗号化し、鍵をテナントごとに分けてください。

関連記事

• 大和証券の情報漏洩・不正アクセス：約11万人の対象確認と委託先i-askの経緯、口座番号を委託先に残さない設計：証券会社の委託先から口座番号が漏れた同型の事例
• SMBCコンシューマーファイナンスの情報漏洩：プロミスは対象か、最大32万人の確認先と銀行別の公表一覧：同じSMBCグループで起きた別の漏えい事案
• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：入口側の認可とトークンを固める手順
• PostgreSQLの暗号化｜TLS設定・pgcryptoの列暗号化とTDE不在時の選び方：データベース側の暗号化方式の比較
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：漏えい時の報告の段取り