NEC委託先の不正アクセスとは｜顧客システム暗号化・情報漏えいの経緯と委託元が点検する正規アカウント

NECは2026年10月20日、システム開発と保守を任せていた委託先が9月下旬にサイバー攻撃を受け、盗まれた正規アカウントで顧客の環境に不正アクセスされたと公表しました。顧客のサーバーではファイルが暗号化され、関係者の情報共有に使っていたクラウドストレージからはファイルが漏えいしています。翌21日には大阪公立大学が、10月2日から続くシステム障害の原因が本件だったと発表しました。本記事では両者の公式発表を時系列で整理し、報道だけで伝えられた数値とは分けて扱います。後半は、委託元の立場で委託先アカウントの棚卸し、接続端末の制限、共有ストレージの設定を確かめる手順をコマンド付きで示します。

まとめ：NEC委託先の不正アクセスで公表された事実と委託元が今週確かめる点

NECの公表文で確定しているのは次の4点です。委託先が9月下旬にサイバー攻撃を受けたこと、委託先の端末から正規アカウントで顧客環境に不正アクセスされたこと、顧客のサーバー内のファイルが暗号化されて各種システムが使えなくなったこと、NECが作った共有用クラウドストレージから個人情報やシステム関連情報を含むファイルが漏えいしたことです。影響のあった顧客には個別に連絡済みとしています。

委託先の社名、影響を受けた顧客の数と名前、漏えいした件数は公表されていません。NECのパソコンや一般向けサービスの利用者に対応を求める記載もありません。NECから個別の連絡を受けていない組織が直接の被害者である可能性は低いと読めます。

それでも、システムの開発や保守を外部に任せている組織には他人事ではありません。今週中に確かめたいのは、委託先に発行しているアカウントの一覧と最終利用日、そのアカウントがどの端末からでも使える状態になっていないか、委託先と共有しているストレージに期限の切れた外部共有が残っていないか、の3つです。

NECと大阪公立大学の公表を並べる｜9月下旬の攻撃から10月21日の第5報まで

大学の障害発生から原因の報告まで18日かかった10月の時系列

二つの組織の発表を日付順に並べると、被害を受けた側が原因を知るまでの時間が見えてきます。

大学の障害から原因の報告までは18日です。大学側の初動と仮想化基盤の被害は大阪公立大学のランサムウェア被害で詳しく扱っています。委託先を起点とした事案では、被害を受けた組織が自力で侵入経路を突き止めにくく、委託先からの報告を待つ形になりがちです。

NECの「委託先」が大学から見ると「再委託先」になる二段の委託関係

大阪公立大学の第5報は、基盤システムの保守・運用をNECに委託しており、NECがシステム開発と保守業務を再委託している事業者が攻撃を受けたと説明しています。NECの公表文が「委託先」と呼ぶ会社は、大学から見ると「再委託先」です。

この関係は、委託元の管理の死角を示しています。大学が直接契約しているのはNECだけです。それでも実際に大学のシステムへログインできるアカウントは、契約関係の一段先にある会社が持っていました。自社の環境にログインできる人の所属を、契約書の相手方ではなく実際のアカウント単位で把握しているか。ここが本件で問われている点です。

大学の会見で示された約13万件と今回漏えいした情報が別物である理由

第5報は、NECが利用していたクラウドストレージ内の「本学に関連する個人情報およびシステム関連情報」が漏えいしたと報告を受けたとしています。内容と件数はNECに確認中です。

大学は同じ第5報で、10月5日の会見で示した教務システム関連の情報約13万件は大学の仮想化基盤システム内のもので、NECが管理していたストレージ内の情報とは別だと明記しました。仮想化基盤からの漏えいの有無は調査が続いています。報道で「13万件が漏えい」と読める見出しを見かけても、10月21日時点の公式発表はそう述べていません。

正規アカウントの悪用が防御をすり抜ける理由｜委託先の端末と常設IDの組み合わせ

正規の認証情報と委託先の端末から入られると通常の保守作業と区別しにくい

NECの公表文は、顧客環境への不正アクセスが「委託先の端末から正規アカウントを用いて」行われたと書いています。脆弱性を突く侵入と違い、正しいIDとパスワード、いつもの接続元からのログインは、監視の仕組みから見ると保守担当者の作業そのものです。深夜の作業や大量のファイル操作が保守では珍しくない環境ほど、異常として浮かびにくくなります。

IPAの情報セキュリティ10大脅威 2026では、組織向けの2位が「サプライチェーンや委託先を狙った攻撃」で、8年連続の選出です。1位はランサム攻撃でした。本件はこの1位と2位が一つの事案で重なった例といえます。攻撃の類型はサプライチェーン攻撃とはで整理しています。

関係者全員が使う共有ストレージに顧客の個人情報と構成情報が集まる構造

漏えいが起きたのは、NECが作成し、顧客とNEC、NECと委託先といった関係者の間で情報共有に使っていたクラウドストレージです。中身には顧客の個人情報とシステム関連情報が含まれていました。

システム関連情報には、構成図、サーバー名、作業手順、場合によってはアカウント情報が入ります。共有ストレージは「関係者全員が見られる場所」なので、どこか一社のアカウントが盗まれれば、全員分の情報に手が届きます。ストレージ製品は公表されていないため、以降の設定例は特定の製品を指すものではありません。

委託先アカウントを棚卸しする｜Entra IDの最終サインイン日と作成日を一覧化する

ゲストの最終サインイン日をMicrosoft Graphで取得するPowerShell

委託先の担当者をMicrosoft Entra IDのゲストとして招待している組織なら、最終サインイン日の一覧を数分で作れます。Microsoft Graphの仕様では、signInActivityの取得にEntra ID P1またはP2のライセンスとAuditLog.Read.Allの権限が要ります。

# Microsoft Graph PowerShell SDK で実行する（読み取りのみ）
Connect-MgGraph -Scopes "User.Read.All","AuditLog.Read.All"

$since = (Get-Date).AddDays(-90)

Get-MgUser -All -Filter "userType eq 'Guest'" `
  -Property displayName,userPrincipalName,accountEnabled,createdDateTime,signInActivity |
  Select-Object displayName, userPrincipalName, accountEnabled, createdDateTime,
    @{n='LastSuccess'; e={ $_.SignInActivity.LastSuccessfulSignInDateTime }},
    @{n='Stale90d';    e={ -not $_.SignInActivity.LastSuccessfulSignInDateTime -or
                           $_.SignInActivity.LastSuccessfulSignInDateTime -lt $since }} |
  Sort-Object LastSuccess |
  Export-Csv .\vendor_accounts.csv -NoTypeInformation -Encoding UTF8

lastSuccessfulSignInDateTimeは成功したサインインの日時で、2023年12月1日から記録が始まった項目です。それ以前に最後に使われたアカウントは空欄になるため、Stale90dがTrueと出ます。委託先の担当者を社員と同じメンバーアカウントで作っている場合は、-Filterを委託先用のグループや会社名の属性に置き換えてください。

90日未使用は無効化・契約終了は即日削除と決める棚卸しの判定基準

一覧ができたら、次の順で判定します。保守契約が終わった委託先のアカウントは即日削除する。90日以上成功したサインインのないアカウントは無効化し、委託先から申請があったときだけ戻す。作成日が古いのに担当者名が分からないアカウントは、委託先に所属と利用目的を書面で確認する。

本件のように再委託がある場合、アカウントの持ち主が契約の相手方とは別の会社であることもあります。台帳には「どの会社の誰が使うか」まで記録してください。VPNやActive Directoryに委託先のアカウントがある場合の洗い出し方は、兄弟記事の両毛システムズのランサムウェア被害でPowerShellの例を示しています。

委託先の接続元を管理端末に限る｜条件付きアクセスで準拠デバイスを要求する設定

委託先グループにだけ準拠デバイスと多要素認証を求めるポリシーの作成例

NECは発覚後の対策として、委託先にNEC管理の端末を貸与していると公表しました。盗まれた認証情報があっても、管理していない端末からは入れないようにする考え方です。Entra IDでは、条件付きアクセスで「準拠済みとしてマークされたデバイス」を要求すると同じ制御になります。

条件付きアクセスの作成APIを使い、委託先のグループだけを対象にしたポリシーをレポート専用モードで作る例です。

# 必要な権限: Policy.Read.All, Policy.ReadWrite.ConditionalAccess, Application.Read.All
Connect-MgGraph -Scopes "Policy.Read.All","Policy.ReadWrite.ConditionalAccess","Application.Read.All"

$vendorGroupId = "委託先アカウントをまとめたグループのオブジェクトID"
$breakGlassId  = "緊急用管理者アカウントのオブジェクトID"

$params = @{
  displayName = "Vendor access requires compliant device and MFA"
  state       = "enabledForReportingButNotEnforced"   # まずレポート専用で影響を見る
  conditions  = @{
    clientAppTypes = @("all")
    applications   = @{ includeApplications = @("All") }
    users          = @{
      includeGroups = @($vendorGroupId)
      excludeUsers  = @($breakGlassId)
    }
  }
  grantControls = @{
    operator        = "AND"
    builtInControls = @("compliantDevice", "mfa")
  }
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $params

operatorをANDにすると、準拠デバイスと多要素認証の両方を満たした接続だけが、アクセスを許可される対象です。1〜2週間レポート専用で動かし、サインインログで「本番で有効にしたら止まっていた」接続がないか確かめてからstateをenabledに変えます。多要素認証の方式の選び方は多要素認証（MFA）とはで比べています。

委託先の端末をIntuneに登録できない場合に選ぶ貸与端末と相手方テナントの信頼

Microsoftの手順書は、Intuneの準拠ポリシーを先に作らないと、このポリシーは意図どおりに動かないと警告しています。委託先の端末は委託元のIntuneに登録されていないことが多いので、選択肢は二つです。

一つはNECと同じく、委託元が管理する端末を貸与する方法です。費用はかかりますが、端末の設定とログを委託元が握れます。もう一つは、委託先も自社のEntra IDとIntuneで端末を管理している場合に、テナント間アクセス設定で相手方のデバイス準拠の判定を信頼する方法です。相手方の管理水準をそのまま受け入れることになるため、信頼するのは監査で管理状況を確かめた会社に限ります。緊急用アカウントは必ず対象から外してください。外さずに有効化すると、設定を誤ったときに管理者も締め出されます。境界ではなく接続ごとに検証する考え方はゼロトラストとはで解説しています。

情報共有用ストレージの外部共有｜SharePoint Onlineの期限と共有範囲の確認

サイトごとの外部共有の設定を一覧にし外部ユーザーに有効期限を設けるコマンド

委託先との資料共有にSharePoint OnlineやOneDriveを使っている場合は、SharePoint Online Management Shellで共有の設定を確かめます。Set-SPOTenantの仕様では、外部ユーザーの有効期限は30〜730日の範囲で設定できます。

# SharePoint Online Management Shell で実行する
Connect-SPOService -Url https://contoso-admin.sharepoint.com

# 1. サイトごとの外部共有の設定を一覧にする（読み取りのみ）
Get-SPOSite -Limit All |
  Select-Object Url, Owner, SharingCapability |
  Export-Csv .\spo_sharing.csv -NoTypeInformation -Encoding UTF8

# 2. 外部ユーザーのアクセスに90日の有効期限を設ける（30〜730日）
Set-SPOTenant -ExternalUserExpirationRequired $true -ExternalUserExpireInDays 90

# 3. 委託先と共有するサイトは、登録済みのゲストだけに共有を絞る
Set-SPOSite -Identity https://contoso.sharepoint.com/sites/vendor-project `
  -SharingCapability ExistingExternalUserSharingOnly

2の有効期限は、ポリシーを有効にしたあとにサイトへ参加した外部ユーザーに付きます。すでに参加している外部ユーザーの期限は自動では付かないため、1の一覧で外部共有を許しているサイトを洗い出し、サイトの管理者が参加者を見直す作業が別に要ります。ExistingExternalUserSharingOnlyは、ディレクトリに登録済みのゲストにだけ共有を認める設定です。リンクを知っている人なら誰でも開ける共有を、委託先とのやり取りから外せます。

案件終了後に共有フォルダを残さないと決める条件と個人情報を置かない判断

共有ストレージの設定より先に決めておくべきは、何を置かないかです。顧客の個人情報そのものは、共有ストレージに置かない。調査で必要なときは、件数と期間を絞った抽出を、期限付きの共有で渡す。案件が終わったら共有フォルダを削除し、削除した日を委託先台帳に記録する。この3つは製品に関係なく決められます。

逆に、構成図や作業手順まで共有ストレージから外すのは現実的ではありません。その場合は、パスワードや接続情報だけは別の保管場所に分け、共有ストレージには置かないと決めます。漏えいしたときに被害を「資料の流出」で止めるか、「次の侵入の材料」まで広げるかは、この分け方で決まります。

委託元が再委託先まで監督する範囲｜個人情報保護委員会の指針と契約で確かめる項目

再委託の事前報告と監査を求めるガイドライン通則編3-4-4の記述

個人情報保護委員会のガイドライン（通則編）の3-4-4は、法第25条の委託先の監督を扱っています。委託先が再委託をするときは、再委託の相手方、業務内容、個人データの取扱方法について委託先から事前報告を受けるか承認し、委託先を通じて、または必要に応じて自ら定期的に監査することが望ましいとしています。

同じ項の注記は、委託元が委託先を適切に監督していない場合に再委託先が不適切な取扱いをすると、元の委託元の法違反と判断され得ると書いています。再委託先で起きた漏えいでも、委託元が説明を求められる構造です。漏えいのおそれがあるときの報告の期限と類型は個人情報保護委員会への報告義務で、2026年10月施行の新しい報告の仕組みはサイバー対処能力強化法とはで解説しています。

再委託先に顧客環境への直接ログインを認める条件と認めない場面

本件の教訓を判断基準に落とすと、次のようになります。再委託先の担当者に自社環境への直接ログインを認めるのは、アカウントを個人単位で発行し、委託元が管理する端末か準拠を確かめた端末からしか使えず、ログを委託元が見られる場合に限ります。三つのうち一つでも欠けるなら認めません。

反対に、再委託先の作業が開発だけで、本番環境に触れる必要がないなら、本番へのアカウントは発行しないと決めるべきです。共有アカウントを再委託先と使い回す運用は、どの条件でも採用しません。AWSで委託先に権限を渡す場合の具体的な設定はAWS運用代行の受け入れ設定で示しています。

ここまでの点検を終えても、委託先のアカウントや外部からの入口がどこにあるかを自社だけで説明できない場合は、第三者の点検を入れる時期です。脆弱性診断・セキュリティ診断では、公開しているWebシステムやVPN機器から社内のサーバーに至る経路を含めて確かめられます。保守の委託先を見直すときの確認点はシステム運用保守の会社はどう選ぶにまとめました。

よくある質問

NECの委託先への不正アクセスについて、委託元の担当者と大学関係者から出やすい質問をまとめました。

NECのパソコンやサービスを使っていますが、パスワードを変える必要はありますか？

NECの2026年10月20日の公表文は、システム開発・保守の委託先を起点に、NECの顧客のシステム環境で被害が出た事案を説明したものです。NEC製パソコンや一般向けサービスの利用者にパスワード変更などを求める記載はありません。影響のあった顧客にはNECが個別に連絡済みとしています。NECを名乗る不審なメールや電話が届いた場合は、リンクを開かず、NECの公式サイトを自分で開いて確かめてください。

大阪公立大学のシステム障害とNECの事案はどう関係していますか？

大学は10月21日の第5報で、10月2日からのシステム障害の原因が本件だったと公表しました。保守・運用を委託しているNECの再委託先が9月下旬に攻撃を受け、再委託先の正規アカウントで大学のシステムに不正アクセスされたと、NECから報告を受けています。NECが利用していたクラウドストレージからは、大学に関連する個人情報とシステム関連情報も漏えいしました。

漏えいした個人情報の件数や内容は分かっていますか？

2026年10月21日時点では公表されていません。NECは漏えいした個人情報の詳細を判明しだい顧客に報告するとし、大学も内容と件数をNECに確認中としています。大学が10月5日の会見で示した約13万件は大学の仮想化基盤内の情報で、NECのストレージから漏えいした情報とは別だと第5報で明記されました。

攻撃を受けた委託先の会社名や、ほかの被害顧客は公表されていますか？

NECの公表文には、委託先の社名も顧客名も書かれていません。影響を受けた顧客は「複数」とだけ記載されています。日本経済新聞などの報道では顧客3社とされていますが、NECの公表文では確認できない数字です。顧客の側から公表したのは、10月21日時点で確認できる範囲では大阪公立大学です。

システムの保守を外部に委託している企業はまず何を確認すべきですか？

最初に、委託先に発行しているアカウントの一覧と、それぞれの最終利用日を出してください。契約が終わった会社のアカウントや、長く使われていないアカウントが残っていれば、利用を停止する対象です。次に、そのアカウントがどの端末からでも使える状態か、委託先と共有しているストレージに外部共有が残っていないかを確かめます。再委託の有無と、再委託先が自社の環境にログインできるかも、委託先に書面で尋ねておきます。

関連記事

• 大阪公立大学のランサムウェア被害：原因・復旧状況と臨時サイト、仮想化基盤のバックアップを守る設定：本件で被害を受けた顧客側の事案
• 両毛システムズのランサムウェア被害：VPNアカウント悪用と委託元に残ったファイルの点検：委託先を起点にアカウントが悪用された事案
• 旭化成ファーマのサイバー攻撃：Pharma DIGITAL会員51.4万人の漏えいと委託先DBの監視設計：委託先のデータベースから漏えいした事案
• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効：盗まれた認証情報を失効させる実装
• サプライチェーン攻撃とは？起点別3類型と最新事例・対策の優先順位：委託先を経由する攻撃の類型