第一生命の人事システム不正アクセス（約12万人、うち退職者7万人）。内勤1967年以降・営業2017年以降という50年差は保存期間ではなく、二つの社員マスタの起点ではないか。第一生命自身が公開したNotes→ServiceNow（DNOW）の資料にある「社員マスタ」「上長定義」から、個人情報の寿命は「いちばん長生きしたコピー」で決まる、という問いを立てる。
2026年10月2日、第一ライフグループと第一生命は、両社が利用する従業員向け人事システムが第三者による不正アクセスを受けたと公表した。
不正アクセスを確認したのは9月24日。
保存されていた個人情報が第三者に閲覧され、外部へ流出した可能性があるという。
対象は約12万人。
現在の従業員が約5万人、退職者が約7万人。
漏えいした可能性がある情報には、従業員番号、氏名、住所、電話番号、性別、所属、職位、職務、管理職上司氏名が含まれる。
ただ、私が最も気になったのは12万人という数字ではなかった。
内勤職員は1967年以降。 営業職員は2017年以降。
なぜ同じ「従業員向け人事システム」の中で、データの起点が50年も違うのだろう。
ここから先は、公表されていない部分についての仮説である。
最初は、内勤職員の古い個人情報を60年近く保存していた、と考えた。
しかし、それでは営業職員が2017年からしか存在しない理由を説明しにくい。
むしろ逆ではないか。
1967年と2017年は、二つの社員マスタの「データ系列の起点」なのではないか。
1967年に現在のシステムが作られた、という意味ではない。
古い人事データが後のシステムへ移行され、さらに次のシステムへ引き継がれ、その系列の最古のデータが1967年だった可能性だ。
一方、営業職員については2017年前後に別の社員マスタや業務基盤を作り、その時点からデータを持ち始めた。
そう考えると、50年という不自然な差が一つのシステム史として読める。
この仮説を考えながら第一生命の過去のIT資料を読み直すと、非常に興味深い資料が出てくる。
第一生命は1997年、FAXや電話を中心としていた社内業務をシステム化するため、オンプレミスのグループウェアを導入した。
その後、業務部門が作るEUCが積み重なり、2021年時点では約4,000システム、約5万データベースが稼働していたと第一生命自身が説明している。
そして、この旧グループウェアはNotesだった。
第一生命は2020年から「DNOW」プロジェクトを開始し、Notes上の掲示板、申請・決裁、EUCなどをMicrosoft 365とServiceNowへ段階的に移行していった。
ここまでは単なるシステム刷新の話である。
ところが2021年の第一生命によるServiceNow講演資料には、移行対象となるNotesアプリの名前が掲載されている。
そこには、
「漢字アドレス帳」
「担当報告DB」
「上長定義」
「機関ID」
「社員ポータルログインDB」
といった名前が並んでいる。
さらに同じ資料の「今後のDNOWでの開発イメージ」には、業務共通で利用するデータとして、
「社員マスタ（アドレス帳）」
「上長定義、担当報告」
と明記されている。
承認処理についても、
「上長＋担当DBを使った承認プロセス」
という説明がある。
今回公表された漏えい可能性のある項目をもう一度見る。
従業員番号。
氏名。
所属。
職位。
職務。
管理職上司氏名。
かなり似ている。
もちろん、今回不正アクセスを受けたシステムがServiceNowだったという証拠ではない。
しかし少なくとも第一生命には、社員マスタ、アドレス帳、上長定義、社員ポータルログインDBを業務基盤で共通利用する設計思想が実在していたことは、第一生命自身の資料から確認できる。
ここでもう一度、公表文の「従業員向け人事システム」という表現を考えてみる。
今回挙げられているのは従業員番号、住所、電話番号、所属、職位、職務、上司などだ。
現時点の公表には、給与、賞与、人事評価、銀行口座、マイナンバーといった典型的な給与・人事コア情報は出ていない。
だからといって、それらが存在しなかったとは言えない。
ただ、公開されている項目だけを見ると、
給与計算をする本体の人事DBより、「この社員は誰で、どこに所属し、誰が上司か」を各業務システムへ供給する社員ディレクトリ
の姿にも見える。
外向けの公表で、それを「社員ディレクトリ」「人事参照マスタ」「IDプロビジョニング用マスタ」などと説明する必要はない。
人事情報を持つ社員向けシステムなら、「人事システム」と表現しても不思議ではない。
ここで第一生命のシステム史と今回の公表文がつながる。
1997年にNotesを導入。
その後、約4,000システム・約5万DBまでEUCが増えた。
そこには社員アドレス帳、上長定義、担当報告、社員ポータルログインDBなども存在した。
そして2020年から、それらをServiceNowを中心とするDNOWへ移していく。
画面やワークフローは新しくできる。
しかし、
データの年齢まで新しくなるとは限らない。
Notes時代の社員マスタをServiceNowへコピーしたのかもしれない。
あるいは社員マスタ自体はオンプレミスに残し、ServiceNowから参照していたのかもしれない。
さらにその元には、Notesより前から存在した人事データがあったのかもしれない。
そう考えると、
内勤職員は1967年以降
という数字が突然違う意味を持ち始める。
1967年は「60年間保存する」という保存ルールではなく、
何度もシステム移行を繰り返してきた内勤社員マスタの最古のレコード
だったのではないか。
営業職員の2017年についても同じだ。
営業側では別の業務基盤や社員マスタが2017年前後から使われ、そのデータ系列だけが現在の共通基盤へ入っている。
もしそうなら、
1967年と2017年は、二つの社員マスタの起点
ということになる。
ここが今回最も面白いところだ。
第一生命が2021年に公開したServiceNow構成図を見ると、クラウド側のServiceNowとオンプレミス側が明確につながっている。
オンプレミス側にはNotes DB、Notesアプリサーバ、ホスト、全社基盤システム、ワークフローシステム。
その間にはMIDサーバがあり、ServiceNow側には、
SSO（SAML認証）
ユーザー管理
データ連携機能
データ送受信
が描かれている。
さらにServiceNow側には、本番、UAT、テスト、開発、サンドピットの複数インスタンスが用意されていた。
つまり公開資料だけでも、
ServiceNow上に社員マスタをコピーする構成、
オンプレミス側の社員マスタをServiceNowから参照する構成、
旧Notesや別の人事基盤を正として複数のシステムへ同期する構成、
そのどれも成立し得る。
現時点では、どれだったのかは分からない。
しかし、人事データが「一台の人事DB」に閉じていたと考える方が、むしろ第一生命自身が公表したシステム構成とは合わない。
「人事システムへ不正アクセス」と聞くと、インターネットに人事DBが公開されていて、そこを直接攻撃されたように想像してしまう。
だが、公開資料から見える構造はもっと複雑だ。
社員はSAMLで認証され、ServiceNowのポータルやワークフローを使う。
ServiceNowはデータ連携を通じてオンプレミス側とも通信する。
社員マスタや上長定義は複数の業務アプリから共通利用される。
別の公開事例では、第一生命が現在5万人以上の職員に提供する環境でも統合Windows認証を利用し、アカウント管理を「社内人事システム」と日次連携していることが明らかになっている。
つまり人事マスタは、単なる保存場所ではない。
他のシステムへ「この人は誰か」を供給する側にいる。
そこへ到達する経路としては、社員SSO、ポータル、APIや連携アカウント、MIDサーバを介した連携、運用・保守経路など、複数を考える必要がある。
現時点ではどの経路だったかは公表されていない。
今回実施した dai-ichi-life.co.jp と dai-ichi-life-hd.com の外形調査では、ServiceNowを直接示すホストは確認できなかった。
しかし、これも矛盾ではない。
ServiceNowのインスタンスは標準では <instance>.service-now.com というServiceNow側のドメインを利用する。企業独自のURLを設定することもできるが、企業ドメインのサブドメイン列挙だけでは見つからない場合がある。
したがって「外形から見えない＝ServiceNowはすでに廃止された」とは言えない。
逆に、現在の第一生命環境で今回のDNOWがどこまで残っているかについても、2021年の導入事例だけでは断定できない。
もう一つ、非常に気になる偶然がある。
2026年9月24日、ServiceNow AI Platformについて CVE-2026-13016 が公開された。
認証していないユーザーが一定の条件下で、インスタンスの基盤データベースに対して任意のSQL文を実行し、本来想定されていないデータへアクセスまたは変更できる可能性があるSQL Injectionで、CVSSは9.3とされている。
第一生命が不正アクセスを確認した日も9月24日だ。
ただし、この二つを結び付ける根拠は現在まったくない。
ServiceNowはホスト型インスタンスへセキュリティ更新を展開済みとしており、悪用を把握していないとも説明している。第一生命が影響を受けるバージョンだったかも分からない。公表日と侵入日も同じ意味ではない。
したがって、このCVEを今回の原因候補として扱うのは早い。
ただ、今後の続報で製品名や侵入経路が明らかになれば、確認すべき材料の一つにはなる。
侵入経路とは別に、今回もう一つ残る問題がある。
第一ライフグループは、自らの安全管理措置として、個人データについて「業務上利用する必要が無くなった時点で削除」を行い、データ保持の最小化に努めるとしている。
また、業務上の必要性に応じて保存期間を定め、期間経過後は廃棄・消去するとしている。
もちろん、1967年以降の社員情報に現在も業務上の保存理由があった可能性はある。
それは現時点では分からない。
しかし、もし今回のデータが人事本体ではなく、Notes時代から移行された社員マスタや社員ディレクトリだったとすれば、別の問題が見えてくる。
人事本体では退職処理を行う。
ADのアカウントは無効にする。
しかし、ワークフローや社員アドレス帳へコピーされたデータは消えない。
さらにシステム刷新時に、それを新しいServiceNowのテーブルへ移す。
すると、
必要だから保存したのではなく、昔から存在したから次のシステムにも持っていった
ということが起きる。
個人情報の寿命は、本体のデータベースだけを見ても分からない。
個人情報の寿命は、いちばん長生きしたコピーで決まる。
今回の事案で私が知りたいのは、攻撃者が使った脆弱性番号だけではない。
1967年と2017年は何の境界だったのか。
今回侵害された「人事システム」は、人事の本体だったのか、それとも社員マスタだったのか。
Notes時代の「漢字アドレス帳」「上長定義」「社員ポータルログインDB」は、その後どこへ移ったのか。
そして、社員が退職したとき、元の人事情報だけでなく、そのコピーまで削除する仕組みは存在していたのか。
12万人という数字の裏には、第一生命の約30年にわたる社内システムの歴史が残っているのかもしれない。
次の報告で答え合わせしたい。
Aikido Community Japan
公開日: 2026/10/2
最終更新: 2026/10/2
セキュリティの最新情報をお届けします。