JNSA不正アクセス：理解度チェック最大1.5万件の漏えい項目と管理者・開発者の対応

日本ネットワークセキュリティ協会（JNSA）が運営する「情報セキュリティ理解度チェックサービス」に第三者の不正アクセスがあり、最大15,128件の個人情報が漏えいした可能性があると2026年11月6日に公表されました。対象には、サービスを導入した企業の管理者の氏名・企業名・メールアドレスと、受講者のIDとハッシュ化されたパスワードが含まれます。本記事の前半では、第一報で確認できる項目と時系列を整理し、導入企業の管理者が社員へ伝える内容と点検の順番をまとめる構成です。後半は開発者向けに、ハッシュ化パスワードが漏れた場面を前提にした保存方式の棚卸しと、漏えい済みパスワードを登録時に弾く実装をコード付きで示します。

まとめ：JNSA不正アクセスで公表された事実と管理者・受講者・開発者の対応

第一報で確定しているのは「不正アクセスがあった」ことと「漏えいの可能性がある項目」までです。侵入経路・確定件数・パスワードのハッシュ方式は公表されていません。

管理者がまず手を付けるのは、JNSAや勤務先を装ったメールへの注意喚起を社員へ出すことです。受講者の側は、理解度チェックと同じパスワードを他のサービスで使っていないかを確かめれば足ります。開発者にとっての教訓は、ハッシュ化していても方式とコスト設定しだいで守れる時間が変わる点にあります。

JNSA第一報で確かめる理解度チェックの漏えい項目と10月30日からの時系列

管理者の氏名・企業名と受講者のID・ハッシュ化パスワードに分かれる6項目

JNSAの第一報が挙げる項目は次の6つで、対象は「これまで管理者登録された方および利用ユーザ」です。

1. 管理者氏名
2. 管理者企業名
3. 管理者メールアドレス
4. 組織所在地、従業員数、業種
5. 利用ユーザ数
6. 利用者のID/PW（パスワードはハッシュ化されています）

1〜5は導入した組織と、その窓口になった管理者の情報です。受講した社員や職員に関わるのは6番目だけになります。第一報の注記によると、理解度チェックは組織の管理者が事前に受講者を登録し、結果を分析するサービスで、管理者以外の受講者は個人名を使わず「受講者ID」などで管理できます。受講結果や点数は、列挙された項目に入っていません。

10月30日夜の侵入開始から11月6日の個人情報保護委員会報告までの経過

1. 10月30日夜頃：不正アクセスが始まった可能性（その後の調査で判明）
2. 11月4日：第三者による不正アクセスを確認し、サービスを停止
3. 11月4日以降：外部専門事業者の協力のもとで原因と影響範囲を調査
4. 11月6日：第一報を公表し、同日に個人情報保護委員会へ報告予定

侵入の開始から確認までの期間は、5日ほどです。漏えいの可能性が確認された利用者には、対象者の特定が済みしだい個別に連絡するとされています。JNSAは毎年「セキュリティ十大ニュース」を選ぶ団体でもあり、その顔ぶれはJNSA 2025セキュリティ十大ニュース解説で紹介しています。本記事の内容は、11月6日付の第一報を同日に確認した時点のものです。

ブラストメール停止の告知とは別件である点と、最大15,128件という数字の読み方

JNSAのWebサイトには、もう1つの告知が並んでいます。協会がメールマガジンの配信に使う「ブラストメール」への不正アクセスを受けて、メールマガジンとインターンシップの登録機能を止めたという内容です。こちらは配信サービス側の事故で、確認された漏えいの対象にJNSAの情報は含まれていなかったとされています。協会の説明では、ブラストメールに登録していたのはメールアドレスだけです。配信サービス側の事故の経緯はブラストメール不正アクセスと利用企業の報告・通知の手順で追っています。

15,128件は「最大」の見込みです。第一報は、対象件数と影響範囲が今後変わる可能性に触れています。管理者と受講者の内訳、導入組織の数は公表されていません。

利用企業の管理者が今週中に進める受講者への連絡とパスワード使い回しの点検

漏れた管理者メールアドレスを狙うJNSAや勤務先を装ったメールの見分け方

管理者のメールアドレスは、氏名・企業名・従業員数と組み合わさった形で漏れた可能性があります。攻撃者から見ると「どの会社の誰が、社員のセキュリティ教育を担当しているか」が分かる一覧です。JNSAからの続報や、理解度チェックの再開案内を装うメールが届く前提で構えます。

第一報は、協会がメール本文のURLからIDやパスワードの入力・変更を求めることはないと明記しています。したがって、本文のリンクからログインを求めるメールは、差出人がJNSAに見えても開かずに削除して構いません。続報はJNSAのWebサイトを自分で開いて確かめます。

受講者IDを実名や社員番号で登録していた場合と、パスワードを使い回していた場合

受講者の影響は、登録の仕方で2通りに分かれます。受講者IDを連番などの記号で作っていれば、IDから本人は特定しにくく、漏れて困るのはパスワードの側です。社員番号や「氏名＋数字」でIDを作っていた場合は、管理者の企業名と組み合わせて本人が推定される余地が生まれます。

どちらの場合も、確かめるべきはパスワードの使い回しです。ハッシュ化されていても、よく使われる文字列は総当たりで元に戻される可能性があります。理解度チェックと同じパスワードを社内システムやメールで使っていた社員には、そちらの変更を優先してもらう対応が必要です。理解度チェック自体は止まっているため、そちらの変更は再開時の案内に従えば足ります。

利用企業側の個人情報保護委員会への報告要否と、社内向け案内に入れる4項目

委員会への報告は、運営者であるJNSAが11月6日に行う予定です。利用企業が自社としても報告するかは、受講者の情報を委託として預けていた関係にあたるかで変わります。利用規約と契約を確かめ、報告の判断と書き方は個人情報保護委員会への報告義務の実務を参照してください。社内向けの案内には、次の4つを入れれば足ります。

• 漏えいの可能性がある項目（受講者IDとハッシュ化パスワード）と、点数は対象外であること
• 同じパスワードを使っている他のサービスで、先に変更すること
• JNSAや情報システム部門を名乗る、ログインを求めるメールのリンクを開かないこと
• JNSAから個別連絡が来た場合の転送先（社内の窓口）

案内を出す前に、受講者の登録一覧を手元に控えておくと、JNSAから個別連絡が来たときに照合しやすくなります。

ハッシュ化パスワードが漏れたときに開発者が確かめる保存方式とコスト設定

ハッシュ化でも安全とは限らない理由：方式未公表と使い回しパスワードの照合

「パスワードはハッシュ化されています」という一文だけでは、どの程度守られているかは判断できません。ソルトの無いMD5やSHA-1なら、一般的なGPUで大量の候補を短時間に試せます。ソルト付きのArgon2idやbcryptで十分なコストを掛けていれば、1件ごとの試行に時間が掛かり、総当たりは現実的でなくなります。JNSAは方式を公表していないため、本記事ではどちらとも書きません。

ただ、強い方式でも防げないものがあります。「Password1」のような、漏えい済み一覧の上位にある文字列は、少ない試行で当たってしまいます。開発者が自社で手を打てるのは、保存方式を強くすることと、弱いパスワードをそもそも登録させないことの2つです。

OWASPとNISTが示すArgon2id・bcrypt・PBKDF2の基準値

OWASPのPassword Storage Cheat Sheetは、2026年11月時点で次の最低構成を示しています。

bcryptは入力が72バイトまでで、それを超える部分は使われません。NIST SP 800-63B-4も、パスワードはソルトを付けたうえで適切なハッシュ方式で保存すること（ソルトは32ビット以上）と、コスト係数を性能が許す範囲で高くすることを求めています。bcryptのコスト係数と72バイト制限の詳細はbcryptのコスト係数とArgon2idへの移行コードで扱っています。

自社DBに残る旧方式のハッシュを接頭辞で数えるSQLとログイン時の再ハッシュ

Argon2idとbcryptのハッシュは、$argon2id$や$2b$のような接頭辞で方式が分かります。接頭辞の無い16進文字列は、ソルトの無い旧方式の可能性が高い行です。PostgreSQLのusers表を例に、方式ごとの件数を数えます。

SELECT CASE
         WHEN password_hash LIKE '$argon2id$%' THEN 'argon2id'
         WHEN password_hash ~ '^\$2[aby]\$' THEN 'bcrypt cost=' || substr(password_hash, 5, 2)
         WHEN password_hash ~ '^[0-9a-f]{32}$' THEN 'hex32（MD5の疑い）'
         WHEN password_hash ~ '^[0-9a-f]{40}$' THEN 'hex40（SHA-1の疑い）'
         WHEN password_hash ~ '^[0-9a-f]{64}$' THEN 'hex64（SHA-256の疑い）'
         ELSE 'その他'
       END AS scheme,
       count(*) AS users
FROM users
GROUP BY 1
ORDER BY 2 DESC;

旧方式の行は、パスワードの平文が無いので一括では変換できません。作り直すタイミングは次回ログインの成功時で、受け取ったパスワードを使う手順です。OWASPも、この「次の認証時に新しいワークファクターで再ハッシュする」方法を一般的な手順として挙げています。argon2-cffiのAPIでは、check_needs_rehash()が現在の設定と違うパラメータで作られたハッシュを見分けます。

import bcrypt
from argon2 import PasswordHasher
from argon2.exceptions import VerifyMismatchError

# OWASPの最低構成（memory_cost の単位は KiB）
ph = PasswordHasher(time_cost=2, memory_cost=19456, parallelism=1)

def verify_and_upgrade(user, password):
    stored = user["password_hash"]
    if stored.startswith("$argon2id$"):
        try:
            ph.verify(stored, password)
        except VerifyMismatchError:
            return False
        if ph.check_needs_rehash(stored):  # 古いパラメータなら作り直す
            user["password_hash"] = ph.hash(password)
        return True
    if stored.startswith(("$2a$", "$2b$", "$2y$")):
        if not bcrypt.checkpw(password.encode("utf-8"), stored.encode("utf-8")):
            return False
        user["password_hash"] = ph.hash(password)  # bcrypt から Argon2id へ
        return True
    return False  # 旧方式はパスワード再設定へ回す

argon2-cffiの既定値（25.1.0時点でt=3・m=65536・p=4）はRFC 9106の低メモリ向け推奨に合わせたもので、OWASPの最低構成より重い設定です。上のSQLとPythonは本記事の環境では実行しておらず、argon2-cffi 25.1.0のAPIとOWASPの推奨値に基づいて書いています。長くログインしない利用者の旧ハッシュは残り続けるため、期限を決めて削除し、次回はパスワード再設定に誘導します。

漏えい済みパスワードを登録時に弾くPwned Passwords照合の実装と運用

NIST SP 800-63B-4が求めるブロックリスト照合と定期変更を求めない方針

NIST SP 800-63B-4は、パスワードの設定・変更のたびに、よく使われる値や漏えい済みの値を集めたブロックリストと照合することを必須（SHALL）としています。一方で、定期的なパスワード変更を利用者に求めてはならないとし、侵害の証拠がある場合に限って変更を強制します。単独で使うパスワードの最小長は15文字、多要素認証の一部なら8文字です。

今回のように運営者から漏えいの連絡があった場面は、この「侵害の証拠がある場合」に当たります。全社員に一律の変更を求めるより、使い回しのあった社員に絞って変更を求め、登録時の照合で弱いパスワードを入れさせないほうが、規定の考え方に沿います。

k匿名性のrange APIでハッシュ先頭5文字だけを送るPython実装例

Have I Been PwnedのAPIにあるPwned Passwordsは、APIキー不要で使えます。パスワードのSHA-1の先頭5文字だけを送り、同じ先頭を持つハッシュの残りと出現回数の一覧を受け取って、手元で照合する方式です。パスワードそのものも完全なハッシュも外へ出ません。Add-Padding: trueを付けると応答の件数が800〜1,000件に水増しされ、通信量から推測されにくくなります。水増し行の回数は0です。

import hashlib
import sys
import urllib.request

def pwned_count(password):
    sha1 = hashlib.sha1(password.encode("utf-8")).hexdigest().upper()
    prefix, suffix = sha1[:5], sha1[5:]
    req = urllib.request.Request(
        f"https://api.pwnedpasswords.com/range/{prefix}",
        headers={"Add-Padding": "true", "User-Agent": "password-policy-check"},
    )
    with urllib.request.urlopen(req, timeout=10) as res:
        for line in res.read().decode("utf-8").splitlines():
            h, count = line.split(":")
            if h == suffix:
                return int(count)
    return 0

if __name__ == "__main__":
    n = pwned_count(sys.argv[1])
    print("漏えい済み" if n else "一覧になし", n)

このコードは2026年11月6日にPython 3.14で実行し、passwordが52,372,427回、無作為に作った長い文字列が0回と返ることを確かめました。登録・変更の画面では、回数が1以上なら別のパスワードを求めます。APIに届かないときに登録を止めるか通すかは先に決めておき、止めない場合は後から照合し直す仕組みを用意します。

教育・研修SaaSに社員情報を預けるときの判断：登録する項目と認証の選び方

受講者を実名で登録しない設計と、SSO連携が過剰になる小規模利用の場面

今回の第一報で受講者側の項目がIDとハッシュ化パスワードに限られたのは、理解度チェックが実名なしで受講者を管理できる作りだったからです。研修やテストのSaaSを選ぶときは、受講者を記号のIDで登録できるか、点数を部署単位で集計できれば足りるかを先に確かめます。社員番号やメールアドレスをIDに使えば管理は楽になりますが、漏れたときに本人へたどり着く材料を増やすことになります。

パスワードを預けない手としてSAMLやOIDCのSSO連携もありますが、年に1回、数十人が受けるテストのために社内のIDプロバイダーと連携するのは過剰です。この規模なら、記号のIDと使い捨てのパスワードを配り、他のサービスと同じパスワードを使わせない運用で十分です。数百人以上が常時使う研修基盤になって初めて、SSO連携の手間が見合います。

自社で研修・テストの仕組みを作るときにパスワード保存と公開範囲を診断へ回す判断

社内向けの研修やテストの仕組みを自社で作る場合は、前章のハッシュ方式の棚卸しとブロックリスト照合を最初から組み込みます。加えて確かめる項目は、管理画面がインターネットに開いているか、管理者のログインに多要素認証があるかの2点です。APIのレート制限や認可の確認項目はAPI不正アクセス対策の実装手順にまとめています。

侵入の開始から確認まで5日空いた今回の経過を見ると、設定を読むだけでは届かない範囲があります。外から突ける穴があるか、保存方式が想定どおり働いているかを第三者の目で確かめるなら、脆弱性診断・セキュリティ診断で相談できます。

よくある質問

JNSAの理解度チェックサービスへの不正アクセスについて、管理者や受講者から出やすい質問をまとめました。

JNSAの不正アクセスで漏れた可能性がある情報は何ですか？

第一報が挙げるのは、管理者の氏名・企業名・メールアドレス、組織の所在地・従業員数・業種、利用ユーザ数、利用者のIDとパスワードの6項目です。パスワードはハッシュ化されていると説明されています。対象は最大15,128件の見込みで、調査の進み具合で変わる可能性があります。

理解度チェックを受けただけの社員の情報も対象ですか？

受講者に関わる項目は、利用者のIDとハッシュ化されたパスワードです。受講者は個人名を使わず受講者IDで管理できるサービスのため、氏名が登録されていない受講者も多いはずです。受講結果や点数は第一報の項目に入っていません。IDを社員番号や氏名で作っていた場合は、管理者の企業名と組み合わさる点に注意します。

理解度チェックのパスワードを変更する必要はありますか？

サービスが止まっているため、理解度チェック自体のパスワードは再開時の案内に従えば足ります。急ぐべきなのは、同じパスワードを他のサービスで使っている場合で、そちらを先に変更します。JNSAはメール本文のURLからIDやパスワードの入力・変更を求めないとしているため、変更を促すメールのリンクは開かないでください。

情報セキュリティ理解度チェックはいつ再開しますか？

11月6日付の第一報に、再開の時期は書かれていません。サービスは被害拡大を防ぐために止められ、外部専門事業者の協力のもとで原因と影響範囲の調査が続いています。新しい事実が分かればJNSAのWebサイトで知らせるとされているため、再開の案内もそちらで確かめます。

JNSAのメールマガジンやブラストメールの件とは関係がありますか？

別の事案です。JNSAのWebサイトには、メール配信に使うブラストメールへの不正アクセスを受けてメールマガジンとインターンシップの登録機能を止めた告知もありますが、確認された漏えいの対象にJNSAの情報は含まれていなかったとされています。協会はブラストメールにメールアドレスだけを登録していたと説明しています。

関連記事

• bcryptとは：コスト係数・72バイト制限とArgon2idへの移行コード【2026年】：保存方式を移す具体的な手順
• ブラストメール不正アクセス：配信先漏えいと利用企業の公表、報告・通知の手順：JNSAのメール配信も止まった別の事案
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：利用企業が報告を判断するときの基準
• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効：侵入口を塞ぐ側の実装
• 不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順：企業として点検する範囲の全体像