世間で増加する不正アクセスに対する
renueの基本方針と取り組み

規模

トレンドマイクロの集計では、国内の企業と自治体が公表した不正アクセスなどの被害は2024年に644件、2025年に593件でした。2026年は1月から9月で600件に達し、9月だけで86件が公表されています。7月と比べて約4割、8月と比べて約2割の増加です。

世界では、日経の集計で9月以降に少なくとも約3.2億人分の個人情報が漏えいしました。Check Point Researchの集計では、2026年9月の1組織あたりの週間攻撃数は2,803件で、前年同月から48%増えています。

警察庁の「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」では、センサーが検知した不審なアクセスが1日・1IPアドレスあたり13,687件で、前年同期から50.7%増えました。ランサムウェアの被害報告は123件で、半期として最多です。

国内で公表された事例には、外食チェーンの運営会社、旅行予約サイト、証券会社、生命保険会社、鉄道事業者、物流事業者、地方銀行、データセンター事業者、行政のシステムなどが含まれ、業種も規模もさまざまです。

侵入の起点と原因として公表されているもの

IPAは10月9日の注意喚起で、特定の製品の脆弱性を狙った攻撃とは断定していません。公表事例の傾向から整理した起点は、外部に公開しているアプリやサービスの侵害と、アカウントの侵害の2つです。

JPCERT/CCは10月8日の注意喚起（10月9日更新）で、確認した攻撃をケースAからDの4つに分けて説明しており、手口の種類としては3つに整理できます。既知の脆弱性のスキャンと悪用（ケースA）には、設定ファイルやバックアップの窃取など管理の不備を突くものも含まれます。API経由の不正操作（ケースB）では、アプリを解析してエンドポイントとキーを特定し、内部APIで権限の変更や不正なアカウントの作成を行う手口や、他のシステムから窃取したAPIキーの流用が見られました。公開Webサーバー経由でのWebシェルの設置（ケースD）も確認されています。ケースCは脆弱性悪用の具体例で、BIツールMetabaseのSQLインジェクション脆弱性（CVE-2026-72898、2026年8月公表）が公表前から悪用されていました。

個人情報保護委員会は、APIの設計と設定の不備により、パラメータを書き換えるだけで他の利用者の情報を取得できた事例を公表しました。

専門家の共同資料では、必要以上の情報を返すAPI、過剰な権限を持つAPI、会員機能への匿名アクセス、管理画面の弱いパスワード、既知の脆弱性の悪用が繰り返し指摘されています。

被害は一般向けのアプリに限らず、BIツールや従業員向けの管理システムのように、不特定多数のアクセスを想定していないシステムにも及びました。

公的機関と専門家は、AIが使われたと断定できるログや痕跡は確認されていないとしています。ゼロデイ脆弱性がAIで発見され悪用された事例も、現時点では確認されていません。以下は、その前提を踏まえたうえで、renueが公開情報と自社の経験から導いた見方です。

renueが注目しているのは、攻撃にかかるコストの変化です。サイバーキルチェーンの7工程は、従来は工程ごとに人が調べ、スクリプトを組み、結果を見て次の手を考える必要がありました。人手と時間が制約になるため、攻撃者は狙う企業を選ばざるを得ませんでした。AIとエージェントはこの工程のほぼ全部を自動で回し、複数の企業に対して同時並行で、安く、偵察から目的の実行までを進めます。

今回の事案で公表された手口を7工程に当てはめると、次のようになります。偵察では、公開アプリ、API、管理画面の洗い出しと、アプリ解析によるエンドポイントの特定が行われました。武器化では、既知の脆弱性から攻撃コードを作ります。Anthropicの報告では、小型モデルでも既知の脆弱性2件から約8時間、約20ドルで攻撃チェーンを構築できました。配送と攻撃では、SQLやNoSQLのインジェクションの探索、Metabaseの脆弱性へのAPIリクエスト、応答を見て手を変える適応的な試行が観測されています。サイバーセキュリティクラウドは、約40分間で326のIPアドレスを使い分け、1,200件を超えるアクセスを行う攻撃を複数回確認しました。インストールと遠隔操作では、Webシェルの設置や事前に作ったアカウントでのログインが使われます。目的の実行は、個人情報の窃取、ポイントの不正交換、脅迫や売買といった二次被害です。

どの工程でも、人が張り付いて判断する必要がなくなりました。工程が多いほど従来の攻撃コストは高く、AIで下がった幅も大きいということです。

この変化を決定的にしたのが、オープンウェイトモデルの登場、特にZhipu AIが2026年9月に公開したGLM-5.3です。Anthropicの9月29日の評価では、Chrome V8の既知脆弱性を悪用する成功率が同社の最上位級モデルとほぼ同等でした。NIST傘下のCAISIの評価も、公開済みのオープンウェイトモデルの中で最もサイバー能力が高いというものでした。モデル本体が公開されているため、約4,400ドル相当の計算で追加学習をかければ、危険な依頼を断る安全対策を外すこともできます。

実際の攻撃でも、サイバーセキュリティクラウドが、約40分間で326のIPアドレスを使い分けて1,200件を超えるアクセスを行う攻撃を複数回観測しました。同社は、AIの利用を直接示す痕跡は確認していないとしたうえで、AIエージェントまたはそれに近い仕組みによる攻撃の可能性を指摘しています。韓国の銀行侵害では、CrowdStrikeが中国製オープンソースのAI侵入ツールとLLMの利用を報告しました。Gambit Securityの報告では、3つのオープンソースAIエージェントが27社に侵入し、スキャン費用は1件あたり約25ドルでした。日経は、AIで多数の企業を同時に、既知の脆弱性を総当たりで突く手口を想定し、大手銀行で見つかる脆弱性が倍増したと伝えました。

侵入口が設定の不備、脆弱性、弱い認証の3つだという見方は、公表された事実でおおむね裏付けられています。IPAは「設定ミス」という語を使っていませんが、JPCERT/CCの「管理不備」と個人情報保護委員会の「API設計・設定の不備」がこれに当たります。専門家の共通見解も、攻撃の手口が劇的に変わったのではなく、基本対策を急ぐべきだというものです。renueはこの見解に同意した上で、変わったのは攻撃者側のコスト構造だと考えています。

従来の守り方は境界防御でした。会社のネットワークを城壁で囲い、門にあたるファイアウォールやVPNで出入りを見張り、いったん城壁の中に入った人と端末は信頼する、という考え方です。本編3-3の「経路を絞る」はこの門の管理に当たり、今も有効な基本ですが、それだけでは足りなくなりました。

足りなくなった理由は3つあります。リモートワークとクラウド、SaaSの普及で、守るべきデータも働く人も城壁の外に出ました。会社のネットワークを囲っても、守る対象の多くはもう囲いの中にありません。次に、門であるVPN機器そのものが侵入経路になっています。警察庁の2026年上半期の報告では、ランサムウェアの侵入経路のうち有効回答36件中18件がVPN機器でした。そして、社内の端末が1台乗っ取られれば、攻撃者は城壁の中に立ったことになり、中にいる人を信頼する前提が崩れます。IP制限が効かなくなるのはこのためです。

ゼロトラストは「城壁の中にいるから信頼する」をやめ、アクセスのたびに「誰が、どの端末で、何に」を確認する考え方です（NIST SP 800-207、2020年）。この考え方は「Never Trust, Always Verify（決して信頼せず、常に検証する）」という標語で知られています。城壁をなくすのではなく、城壁を含めた複数の層で守る点が特徴です。米国CISAの成熟度モデルは、守る対象をID、端末、ネットワーク、アプリケーションとワークロード、データの5つの柱に分け、どの柱でも検証を求めています。具体的には、利用者とAIエージェントのIDを確かめ、その端末が管理された安全な状態かを確かめ、ネットワークは細かく区切って必要な経路だけを通し、アプリやAPIの手前で権限を確かめ、データの手前でもう一度確かめます。この5つの柱を横断して支えるのが、全体を可視化して分析する仕組み、検証と対処を自動化する仕組み、ルールを決めて守らせるガバナンスの3つです。信頼の起点がネットワークの内外ではなくID、つまり「誰か」に移ることから、IDセントリックと呼ばれます。

IDを中心に置くと、守りの要点は認証と認可の2つになります。認証は本当にその人かを確かめる仕組みで、認可はその人が何を触れてよいかを決める仕組みです。

認証では、複数人で使い回すアカウントをなくし、MFAを最低限の条件にします。Microsoftの研究では、MFAを有効にするだけでアカウント侵害のリスクが99%以上下がりました。さらにフィッシングに強いパスキーへ移行し、パスワードログインやSMSといった弱い入口を残さないようにします。2026年10月にSBI証券が注意喚起した「パスキーを設定していても不正ログインされた疑い」の事案は、パスキーが破られたのではなく、パスキーを守る鍵が弱かった事例です。詳細はAppendix Dにまとめました。

認可では、アプリ、API、データベースといった守る対象ごとに、誰が触れてよいかを決めます。全てを一度に決めるのは難しいため、まず漏えいや侵害が起きたときの影響度でデータとシステムを分類し、影響の大きいものから順に、触れる人、API、エージェントを必要最小限に絞ります。分類の基準と進め方はAppendix Eにまとめました。

一般消費者向けのアプリに完全なゼロトラストを求めるのは難しいのが実情です。それでも、管理画面、API、BIツール、従業員向けシステムといった「不特定多数が触らないはずの入口」を誰が触れるかを定義するだけで、今回の事案の多くは防げました。IPAが示す点検項目（外部公開アプリの把握、アカウント権限とAPI連携の見直し、アカウントの棚卸し）も、この作業に帰着します。

参考にした標準と公的文書

NIST SP 800-207 Zero Trust Architecture（2020年8月）は、防御の焦点をネットワーク境界からユーザー、資産、リソースへ移し、所在地や所有形態で暗黙に信頼しないという考え方を7つの基本原則にまとめた文書です。全てのデータソースと計算サービスをリソースと見なす、所在地によらず通信を保護する、アクセスはセッション単位で付与する、動的なポリシーで判断する、資産の完全性とセキュリティ態勢を監視する、認証と認可を動的かつ厳格に実施する、状態情報を収集して態勢の改善に使う、の7つです。分冊のSP 800-207Aと計画ガイドのCSWP 20があります。

CISA Zero Trust Maturity Model v2.0（2023年4月）は、アイデンティティ、デバイス、ネットワーク、アプリケーションとワークロード、データの5つの柱と、可視化と分析、自動化とオーケストレーション、ガバナンスの横断3機能を、4つの成熟度（原文ではTraditional、Initial、Advanced、Optimal）で定義したモデルです。米国の連邦機関向けですが、全ての組織で使えると明記されています。アプリケーションとワークロードの柱では、第2段階でソフトウェア資産管理、パッチ適用、SBOMなどによる依存関係の追跡の自動化を始めると定めており、本編3-2の4段階はこの定義を要約したものです。

デジタル庁 DS-210「ゼロトラストアーキテクチャ適用方針」（2022年6月30日）は、国内の政府情報システム向けにゼロトラストの適用方針を示した文書で、SP 800-207とCSWP 20を参照しています。適用方針として、リソースを識別して特定できる状態にする、主体の身元確認と当人認証を実施する、ネットワークを保護する、リソースの状態を確認する、アクセス制御ポリシーで評価してアクセスを管理する、リソースとアクセスを観測する、の6つを挙げています。適用プロセスの最初に置かれているのがリソースと業務フローの識別と特定で、機密性、完全性、可用性の特性も分析対象にすると後続で活用しやすいと書かれており、本編3-5で分類を先に行う順序と同じです。関連文書として、DS-212 属性ベースアクセス制御、DS-211 常時リスク診断・対処、DS-201 セキュリティリスク分析、DS-221 脆弱性診断導入、DS-222 ログ取得・分析導入ガイドブックがあります。

デジタル庁 DS-500群（行政手続等におけるトラストおよびデジタルアイデンティティに関するガイドライン群、2026年2月改定）は、本人確認と認証を扱う文書群です。DS-511が本人確認におけるデジタルアイデンティティの取扱いを定め、DS-512がその解説書に当たります。

MFAはどれだけ効くか

Microsoft Researchの論文「How effective is multifactor authentication at deterring cyberattacks?」（2023年5月）は、Azure ADの大規模なサンプルを分析し、MFAが侵害リスクを全体で99.22%下げ、認証情報が漏えい済みのアカウントでも98.56%下げたと報告しています。MFAを有効にしたアカウントの99.99%超が調査期間中安全でした。SMSよりも認証アプリの方が効果が高いという結果です。

先行する数値として、Microsoftが2019年に示した「MFAでアカウント侵害は99.9%減る」と、Googleが2019年5月にNYUとUCSDと共同で公表した研究があります。Googleの研究では、端末へのプロンプトが自動ボットを100%、一括フィッシングを99%、標的型攻撃を90%防ぎました。SMSコードはそれぞれ100%、96%、76%でした。

NISTのSP 800-63Bは効果を数値では示さず、AAL（Authenticator Assurance Level）という認証の保証レベルの枠組みを定めています。

パスキーを設定していても不正ログインされた、という事案の見方

SBI証券は2026年10月2日、日本証券業協会からの通知を受けて注意喚起を出しました。フィッシングでGoogleやAppleのアカウント情報が窃取され、クラウドに保存されたパスキーやパスワードのメモが悪用されて、証券口座への不正ログインと不正取引が行われた疑いがあるという内容です。SBI証券は10月8日に、自社口座での被害は確認されておらず、注意喚起は他社の事案によるものだと補足しました。SBI証券のシステムからIDやパスワードが流出した事案とは性質が異なります。

この事案で、パスキーの暗号方式やFIDO/WebAuthnの仕組みが破られたとは公表されておらず、専門家の整理でも、パスキー認証そのものが突破された事例は見つかっていません。突かれたのは、同期型パスキーを預けているプラットフォームアカウント（GoogleやApple）の乗っ取り、残っていたパスワードログイン、パスワードマネージャのメモ、ログイン後のセッションといった、認証の外側です。SBI証券自身の推奨対策も「パスキー認証の利用」と「ログインパスワードの無効化」であり、弱い入口を塞ぐ内容です。

同期の仕組みを狙う攻撃も報告されています。PhishUが2026年5月に公表した「Vaultjacking」は、中間者型のフィッシングでGoogle Password Managerの6桁PINを窃取し、攻撃者の仮想マシンを同期の対象に参加させて保管庫全体を同期させる手法です。Oktaが2026年7月に報告した「パスキー登録ヴィッシング」は、電話で偽の登録画面に足止めしている間に、攻撃者のパスキーを正規のアカウントへ登録する手口です。いずれも、新しい端末を紐付ける関門がPINのみ、口頭確認のみと弱いことを突いています。

renueはこの事案を、パスキーが破られたのではなく、パスキーを守る鍵が弱かった事例だと見ています。パスキーを導入する側が学べることは、パスワードログインやSMS認証のような弱い代替手段を無効化すること、同期先アカウントの2段階認証と復旧用の連絡先を点検すること、そして新しい端末の紐付けをPINや口頭確認だけで通さないことの3つです。

パスキーの2つの種類と、NISTの保証レベル

パスキーは、AppleやGoogleのクラウドに預けて複数の端末で使う同期型と、セキュリティキーなど1つの端末から出ないデバイス固定型の2種類に分かれます。NISTの文書に「パスキー」という語はありません。同期可能認証器（syncable authenticators）とデバイス固定（device-bound）という呼び方で区別しています。

NIST SP 800-63B（Revision 4）と2024年4月の補足文書は、同期可能認証器をAAL2までの選択肢として認めています。AAL3では、同期が鍵の非エクスポート要件に反するため、認めていません。AAL3の要件は、秘密鍵をハードウェアで保護された隔離実行環境に保管し、FIPS 140 Level 1以上の検証を受けた認証器を使うことです。つまり、クラウドに鍵を預ける同期型パスキーはAAL3にはなれません。

NISTは、同期の仕組みへのアクセスをAAL2相当のMFAで守り、鍵を利用者が管理する秘密で暗号化することを求めています。Vaultjackingが突いたのはまさにこの関門で、各社の実装がNISTの要件をどこまで満たしているかが問われています。

renueの考えは次のとおりです。デバイス固定型パスキーは、端末を盗まれても本人の生体情報やPINなしには使えず、現代の利用体験を前提にした認証方式として最も強い選択肢です。ただし、紛失すると復旧できないため2本以上の事前登録が必須であり、ヘルプデスクの本人確認手順も整える必要があります。同期型パスキーはパスワードより格段に強いものの、守るべき対象がプラットフォームアカウントと復旧経路に移ります。管理者、財務、本番運用といった高リスクの権限はデバイス固定型に限定し、それ以外は同期型でも構いません。どちらの場合も、弱いフォールバックを残さないことが条件です。

重要インフラの範囲

本編3-2で「壊れたら直す」の例外とした、生命や生活に直接影響するシステムを考える目安として、国が重要インフラと定める分野を使います。サイバーセキュリティ戦略本部の「重要インフラのサイバーセキュリティに係る行動計画」は、停止や機能低下が国民生活や社会経済活動に重大な影響を及ぼす分野として、情報通信、金融、航空、空港、鉄道、電力、ガス、政府・行政サービス、医療、水道、物流、化学、クレジット、石油、港湾、郵便の16分野を定めています（郵便は2026年7月31日の改定、10月1日施行で追加）。ただし、これらの分野の事業者が持つシステムの全てが、生命や生活に直結するわけではありません。配達を管理するシステムと社内の経費精算システムでは、止まったときの影響がまったく違います。分野の一覧は該当しそうなシステムの当たりを付けるためのもので、実際に例外として扱うかどうかはシステム単位で、次に述べる影響度の分類で判断します。

なぜ分類から始めるのか

アプリ、API、データベースといった守る対象の一つひとつについて、誰が触れてよいかを決めるのがゼロトラストの到達点です。ただし、最初から全てを決めることはできません。そこでrenueは、漏えいや侵害が起きたときの影響の大きさでデータとシステムを分類することから始めます。

分類があれば、どのシステムの更新を優先するか、どこまで厳しい認証を求めるか、更新で止まるリスクと放置して漏えいするリスクのどちらが大きいか、といった判断に共通の根拠ができます。分類がないまま対策を並べると、全てが同じ優先度になり、結局どれも進みません。

分類の基準

基準は自社で発明する必要がなく、公開されている標準を使えます。米国のFIPS 199は、機密性、完全性、可用性のそれぞれが損なわれたときの組織、資産、個人への影響を、低、中、高の3段階で格付けする枠組みで、情報の種類ごとの目安はSP 800-60に示されています。情報は組み合わせると格が上がり、氏名だけなら低でも、マイナンバーや医療情報と組み合わせれば中以上です。

国内にも同じ発想の基準があります。政府機関の統一基準は情報を機密性、完全性、可用性の3つの観点で格付けし、デジタル庁のDS-201は、標準的な対策の水準と、事業への被害の大きさを組み合わせてリスクを評価します。どちらを使っても、影響の大きいものから順に守るという結論は変わりません。

分類から認可までの進め方

進め方は4段階です。まず影響度でデータとシステムを分類し、次に外部に公開しているものを棚卸しします。その上で、影響の大きいものから順に、触れてよい人、API、AIエージェントを決め、最後に影響度に応じた認証の強さを割り当てます。影響度の高いシステムにはデバイス固定型パスキーを、それ以外にはMFAを必須にする、という使い分けです。

この規律は人だけに適用するものではありません。APIキーを持つ外部システムや、業務を代行するAIエージェントも、人と同じように「誰が、何に、どこまで」を決めて管理します。分類と棚卸しの作業はAIエージェントで進められるため、専任のチームを持たない組織でも現実的に取り組めるとrenueは考えています。