2026.10.06 セキュリティ

原子力研究開発機構の不正アクセスと身分証画像の漏えい｜研究支援サイトのファイル保管を点検する手順

日本原子力研究開発機構（JAEA）は2026年10月1日、研究用原子炉JRR-3の外部利用者向けに運用している研究支援サイトが不正アクセスを受け、利用者175人分の個人情報が外部に漏えいしたと公表しました。不正にダウンロードされたファイルは2,419件で、運転免許証やマイナンバーカードなど顔写真付きの身分証明書の画像と、放射線業務の特殊健康診断の結果が含まれています。本記事では公式発表を時系列で整理し、外部の利用者から書類を受け取るポータルを運営する側が、同じことを起こさないために何を確かめればよいかを、実行できるコマンドとスクリプトで示します。

まとめ：原子力研究開発機構の不正アクセスで公表された事実と運営側の点検

確定しているのは次の事実です。2026年9月25日、機構が契約するクラウド基盤上の研究支援サイトで、登録ファイルのうち2,419件が外部から不正にダウンロードされていると確認されました。機構は同日、外部からのアクセスを止めています。9月29日には、ダウンロードされたファイルの一部に個人情報が含まれていると確認しました。利用者のIDやパスワードといったアカウント情報は漏えいしていません。

侵入の経路とクラウド基盤の名称は公表されていないため、原因は断定できません。それでも、アカウント情報は無事で、利用者がアップロードした書類のファイルだけが持ち出されたという構図は残ります。書類を受け取るポータルの運営者は、保管しているファイルが外部から直接取得できる設定になっていないか、手続が終わった書類をいつ消すか、1つの接続元が短時間に何件のファイルを取ったかを数えられるか、の3点をまず確かめてください。

項目	公表されている内容
不正アクセスの確認	2026年9月25日（同日に外部アクセスを停止）
不正ダウンロード	登録ファイルのうち2,419件
個人情報を含むファイル	367件（175人分）
漏えいしていない情報	ID、パスワード、登録フォームの氏名など
報告・相談先	個人情報保護委員会、関係官庁、警察
手法・基盤名	非公表

公式発表を確認する｜9月25日の不正ダウンロード確認から10月1日の公表まで

JRR-3の外部利用者が施設利用の手続に使う研究支援サイトという位置付け

JAEAのプレス発表（2026年10月1日）によると、対象のサイトは原子力科学研究所（茨城県東海村）の研究用原子炉JRR-3で、施設の外部利用者が利用時の手続を行うためのものです。構内への入構や放射線管理の手続に必要な書類を、利用者本人が登録する仕組みでした。

サイトは機構が契約するクラウド基盤の上で動いており、機構内の業務ネットワークとは独立して運用されていたと説明されています。そのため他のシステムへの影響はないとしています。研究機関や大学が、外部の研究者や共同利用者向けの受付を本体の業務システムから切り離してクラウドに置く構成は珍しくありません。今回の事案は、切り離したポータル側にも機微な書類が集まるという点を示しました。

9月25日の確認と同日停止、9月29日の個人情報確認までの経緯

機構は9月25日に不正アクセスと2,419件の不正ダウンロードを確認し、同日のうちにサイトへの外部からのアクセスを止めました。その後ダウンロードされたファイルの中身を一つずつ確かめ、9月29日に一部へ個人情報が含まれていると確認しています。公表は10月1日です。

持ち出されたファイルの中身を確定するのに4日かかった点は、運営側にとって調査に要する時間を考える参考です。ファイル名や登録者と、書類の種類との対応がすぐに引けない保管方法だと、漏えいの範囲を確定する作業そのものに時間がかかります。報告の段取りは個人情報保護委員会への報告義務で整理しています。

漏えいした367件175人分の内訳と身分証画像に含まれたマイナンバー

漏えいしたのは、2026年5月以降に利用者本人が登録したファイル367件（175人分）です。内訳は、顔写真付きの公的身分証明書の画像が200件、放射線業務の特殊健康診断の結果が146件、放射線業務従事者証明書が21件です。身分証明書は運転免許証、マイナンバーカード、パスポート、在留カードの画像で、6名分にはマイナンバーが含まれていたと確認されています。従事者証明書は、放射線業務従事者の指定のために利用者の所属機関が提出した書類です。

複数の項目に当てはまる人がいるため、件数の合計と人数は一致しません。機構は対象者へ個別に連絡と謝罪を行い、個人情報保護委員会、関係官庁、警察へ報告と相談をしています。

ファイル2,419件が持ち出された構図｜公表事実から読める研究支援サイトの論点

侵入経路は非公表・公表から確定できる事実と推測で埋めない部分

公表されていないのは、侵入の経路、使われた脆弱性や認証情報、クラウド基盤の名称です。本記事はここを推測しません。確定しているのは、登録ファイルが外部から2,419件取得されたこと、アカウント情報は漏えいしていないこと、業務ネットワークとは独立していたことの三つです。

アカウント情報が無事でファイルだけが取られたという結果は、利用者の情報を持つデータベースと、アップロードされたファイルの保管先とで、守りが別々に働いていた可能性を示します。ポータルを運営する側が確かめるべきなのは、ファイルの保管先に対してアプリの画面を通らずに届く経路が残っていないかです。Gyazoの不正アクセスでも、アップロードされた画像の保管基盤が論点になりました。

手続が終わった書類を保管し続けると漏えいの件数がそのまま増える

入構や放射線管理の手続のために受け取る身分証の画像は、確認が済めば役目を終えます。確認した日時、確認した担当者、確認した書類の種類を記録に残せば、画像そのものを長く持ち続ける必要は薄いはずです。

受け取った書類を確認後に削除する設計なら、同じ侵害を受けても持ち出される件数は、手続中の利用者の分にとどまるはずです。確認済みの書類を残し続けると、利用者が増えるほど漏えいしうる件数も積み上がります。退会者の免許証画像まで残っていた事例はタイムズカーの不正アクセスと免許証画像160万件の流出で扱っています。

本人確認書類と健診結果を受け取る設計｜マイナンバーと要配慮個人情報の扱い

マイナンバーが写った画像は番号法20条の収集・保管制限に触れうる

番号法の第20条は、法で認められた場合を除き、何人も他人の個人番号を含む特定個人情報を収集し、又は保管してはならないと定めています。本人確認のためにマイナンバーカードの画像を受け取る場合、番号が記載された裏面は求めないのが基本です。

利用者に「表面だけ」と案内しても、裏面や番号入りの書類を登録してしまう人は一定数出るものです。受付の画面で両面の画像を求めない、番号が写った画像は担当者が確認時に差し戻して削除する、という運用を決めておくと、意図しない保管を減らせます。今回6名分にマイナンバーが含まれていた点は、この運用の要否を自社で見直すきっかけになります。

特殊健康診断の結果を要配慮個人情報として扱うための保管先と閲覧権限

個人情報保護法施行令の第2条は、医師等が行った疾病の予防と早期発見のための健康診断その他の検査の結果を、要配慮個人情報の記述として挙げています。放射線業務の特殊健康診断の結果は、これに当たると考えるのが自然です。

要配慮個人情報は、漏えいした場合の報告の扱いも一般の個人情報と異なります。身分証の画像と健診結果を同じ保管先、同じ権限で置いているなら、少なくとも保管場所を分け、健診結果は閲覧できる担当者を絞るべきです。保管期間も、手続上必要な期間を書類の種類ごとに決めておきます。

クラウドのファイル保管を点検する手順｜S3の公開設定・削除ルール・取得ログ

機構が使っていたクラウド基盤は公表されていません。ここではアップロードの保管先として広く使われるAmazon S3を例に、同じ点検をどう行うかを示します。他のクラウドでも、確かめる観点は同じです。S3の基本操作はAWS S3の使い方にまとめています。

ブロックパブリックアクセスとバケットポリシーの状態をCLIで確かめる

S3のブロックパブリックアクセスには、BlockPublicAcls、IgnorePublicAcls、BlockPublicPolicy、RestrictPublicBucketsの4つの設定があります。AWSが推奨するのは、アカウントとバケットの両方で4つともオンにする設定です。アップロード用のバケットについて、次の2つのコマンドで現状を確かめます。

aws s3api get-public-access-block --bucket portal-uploads
aws s3api get-bucket-policy-status --bucket portal-uploads

1つ目で4項目がすべてtrue、2つ目でIsPublicがfalseなら、バケットポリシーやACLによる公開が止まっている状態です。利用者に書類を見せる必要がある場合は、バケットを公開せず、署名付きURLを都度発行します。AWS CLIで発行する場合の有効期限は最大7日ですが、書類の確認なら数分で足ります。

手続が終わった身分証画像を自動で消すS3ライフサイクルルールの設定例

確認が済んだ書類を消し忘れないために、S3ライフサイクルの有効期限アクションで自動削除を設定します。次の例は、身分証画像を置く接頭辞の配下を作成から30日で消すルールです。lifecycle.jsonとして保存します。

{
  "Rules": [
    {
      "ID": "expire-id-documents-30d",
      "Filter": { "Prefix": "uploads/id-docs/" },
      "Status": "Enabled",
      "Expiration": { "Days": 30 },
      "NoncurrentVersionExpiration": { "NoncurrentDays": 1 }
    }
  ]
}

aws s3api put-bucket-lifecycle-configuration --bucket portal-uploads --lifecycle-configuration file://lifecycle.json

バージョニングを有効にしたバケットでは、有効期限が来ても古いバージョンが残るため、NoncurrentVersionExpirationを併記しています。ルールは既存のファイルにも適用されるため、30日を過ぎた書類も削除の対象です。日数は手続の実態に合わせて決め、健診結果の接頭辞には別のルールを置きます。

CloudTrailのS3データイベントから1接続元の取得件数を数えるスクリプト

大量の持ち出しに気付くには、ファイルの取得を記録している必要があります。AWSのドキュメントのとおり、CloudTrailはS3のGetObjectのようなデータイベントを既定では記録せず、有効にすると追加料金がかかります。書類のバケットに絞って有効にしておけば、次のスクリプトで集計できるのは、1時間ごと、接続元ごとの取得ファイル数です。Python 3の標準ライブラリだけで動きます。count_getobject.pyとして保存します。

import collections, gzip, json, pathlib, sys

LOG_DIR = pathlib.Path(sys.argv[1])
THRESHOLD = int(sys.argv[2]) if len(sys.argv) > 2 else 50

files = collections.defaultdict(set)
for path in LOG_DIR.rglob("*.json.gz"):
    with gzip.open(path, "rt", encoding="utf-8") as f:
        for r in json.load(f)["Records"]:
            if r.get("eventName") != "GetObject":
                continue
            who = r.get("userIdentity", {}).get("arn", "unknown")
            ip = r.get("sourceIPAddress", "-")
            hour = r["eventTime"][:13]
            files[(hour, ip, who)].add(r["requestParameters"]["key"])

hits = 0
for (hour, ip, who), keys in sorted(files.items(), key=lambda x: -len(x[1])):
    if len(keys) >= THRESHOLD:
        hits += 1
        print(f"{hour.replace('T', ' ')}時台 {ip} {who} 取得ファイル数={len(keys)}")
print(f"しきい値{THRESHOLD}件以上: {hits}組")
sys.exit(1 if hits else 0)

2026年10月6日に、通常の利用者120人が自分の書類を1〜3件ずつ見たログと、1つの接続元が1時間に2,419件を取得したログを混ぜた架空データで実行した結果です。

$ python count_getobject.py ./cloudtrail-logs 50
2026-09-25 02時台 203.0.113.50 arn:aws:sts::111122223333:assumed-role/portal-app/i-0abc 取得ファイル数=2419
しきい値50件以上: 1組

署名付きURLを使う構成では、取得したのが誰であってもURLを発行したアプリのロールとして記録されます。そのため利用者の区別に併用しているのが、接続元のIPアドレスです。該当があると終了コード1を返すので、定期実行して通知につなげられます。証跡の設計と料金はCloudTrailとは、ログ全般の調べ方は不正アクセスのログ確認・解析方法が参考になります。

外部利用者ポータルを今すぐ点検すべき運営者と後回しでよい運営者の判断基準

身分証や健診結果のファイルを自前のクラウドに保管している運営者の対応

外部の利用者から身分証の画像、健康診断の結果、資格や従事者の証明書をアップロードで受け取り、自前のクラウドのストレージに置いているなら、今週中に3つの点検を回してください。公開設定の確認、確認済み書類の削除ルール、取得ログの有効化と集計です。

研究機関の共同利用、病院の受託業務、人材派遣の登録、イベントの入場登録のように、本体の業務システムと切り離して急いで立てたポータルはとくに優先度が高いと考えます。受付の仕組みだけを外部に発注し、保管期間や削除の運用が決まらないまま書類がたまっていることがあるためです。

書類を受け取らず確認結果だけを残す構成で自前の削除・集計が過剰になる場面

本人確認を外部の確認サービスに任せ、自社には確認の結果と日時だけが返ってくる構成なら、書類の画像は手元にありません。この場合、ライフサイクルルールや取得ログの集計を自前で組む必要は薄く、受け取る結果の項目と保管先の権限を確かめれば足ります。

判断に迷うのは、どのファイルがどこに置かれ、どの経路で外から届くのかを社内で説明できない場合です。ポータルのファイル保管と公開設定、取得経路を第三者の目で確かめたいときは、脆弱性診断・セキュリティ診断で、アプリの画面を通らずにファイルへ届く経路が残っていないかを含めて点検できます。

よくある質問

原子力研究開発機構の不正アクセスについて、利用者とポータルを運営する担当者から出やすい質問をまとめました。

漏えいしたのは何人分で、どの書類ですか？

2026年5月以降に利用者本人が登録したファイル367件、175人分です。顔写真付きの身分証明書の画像が200件、放射線業務の特殊健康診断の結果が146件、放射線業務従事者証明書が21件で、身分証の画像のうち6名分にはマイナンバーが含まれていました。対象者には機構から個別に連絡が届いています。

研究支援サイトのIDやパスワードは漏れていますか？

機構は、IDやパスワード、登録フォームに入力した氏名などのアカウント情報は漏えいしていないと説明しています。漏えいしたのは、利用者がアップロードした書類のファイルです。身分証の画像が対象になった人は、その画像を使ったなりすましの申込みや、機構を装った連絡に注意してください。

不正アクセスの原因や使われたクラウドは公表されていますか？

公表されていません。発表は、機構が契約するクラウド基盤上で運用していたこと、外部から2,419件が不正にダウンロードされたことまでです。機構は原因を究明して再発防止策を講じるとしており、続報で明らかになる可能性があります。

機構のほかのシステムに影響はありますか？

機構は、研究支援サイトは機構内の業務ネットワークから独立して運用しているため、他のシステムへの影響はないと説明しています。研究支援サイトは、不正アクセスを確認した9月25日から外部からのアクセスを止めています。

自社の外部利用者向けポータルで、何から確かめればよいですか？

最初に、受け取っている書類の種類と、保管しているストレージの一覧を作ります。次に行うのは、ストレージの公開設定の確認と、手続が済んだ書類を自動で消すルールの設定です。最後に、ファイルの取得を記録し、1つの接続元が短時間に何件取ったかを数えられる状態にします。本記事のコマンドとスクリプトはその出発点として使えます。