homula

サイバー攻撃の基礎とAI — 第4回

入口を塞ぐ

棚卸し・認証・パッチ・公開面を、手順と9枚の図で。

20〜25分対象: IT・情報システム担当（専門知識は前提にしません）最終更新: 2026年10月

この回の結論：まず台帳を作り、外から見える入口を把握する。そのうえで、不要な公開を止め、残した入口にはフィッシングに強い多要素認証と、期限を決めたパッチ適用を当てる。例外は一覧化し、期限を付ける。

第1〜3回で見たとおり、侵入の多くはインターネットに公開された機器から、既知の脆弱性や盗まれた認証情報を使って起きています。この回からは、それに対する具体的な対策を扱います。最初は、入口そのものを減らし、残した入口を固める対策です。

各節は「目的」「なぜ必要か」「やること」「確認方法」の順で書いています。節の順番は、おおむね着手すべき順です。導入の期間の目安は第7回のロードマップで扱います。

数値の基準日：2026年10月27日

統計は基準日時点の最新版です。事実・数値には [ ] で出典番号を付け、記事末尾に原文へのリンクを載せています。原文で裏付けられない推奨は「本ガイドの提案」と明記しています。

82.1%

侵入経路に占めるVPN機器＋リモートデスクトップ（2021〜25年計）

59.0%

未適用パッチがあった被害組織（2022〜25年計）

15文字

単独で使うパスワードの最低長（NIST）

6つ

最初に作る台帳

1.基本対策を組む4つの前提

第4〜6回の対策は、次の4つの前提に沿って組み立てています（本ガイドの提案）。

1知らないものは守れない最初に棚卸しをする第4回2入口を減らし、残った入口を固める公開面・認証・パッチ第4回3入られる前提で、被害を限定し戻れるように権限・ログ・バックアップ第5回4例外が穴になる — 1〜3のすべてに共通例外は一覧化し、代替策と期限を付ける。アスクルの事例では、MFAを「例外的に」適用していなかった1アカウントが入口になった。
図1基本対策を組む4つの前提。4つ目の「例外」は、アスクルの事例で、MFAを例外的に適用していなかった業務委託先向けの管理者アカウントが入口になったことによる[J17]。

2.棚卸し — 資産・公開面・アカウント・データ・委託先

目的：守る対象と、攻撃者から見える入口を把握する。以後のすべての対策は、この台帳を前提にします。

なぜ必要か

  • 侵入の多くはインターネットに公開された機器から起きています[J1]。管理されていない公開機器（忘れられたサーバー、更新されていないVPN装置）には、パッチも監視も届きません。
  • 個人情報保護委員会は、APIが悪用された事例で「管理対象から漏れているAPIが存在した」ことを挙げ、定期的なAPIの棚卸しを求めています[J11b]。
  • 国家サイバー統括室は、保有する情報資産の所在・管理者の把握、分類、利用目的・保存期間の設定、棚卸しを求めています[J8]。

やること：6つの台帳を作る

台帳以後のすべての対策の前提① ハードウェア機器・版・サポート期限・公開の有無→ パッチ・EOLの置き換え② ソフトウェア・クラウド製品・版・利用中のSaaSと管理者→ パッチ・SaaSの設定（第5回）③ 外部公開面IP・ドメイン・URL・ポート・管理画面→ 公開面の削減④ アカウント利用者・管理者・委託先・APIキー・MFA→ ID・認証⑤ データ種類・保存場所・件数・保存期間→ データ保護（第5回）⑥ 委託先業務・渡す情報・付与した権限→ 委託先の管理（第6回）
図2棚卸しで作る6つの台帳と、それぞれを使う対策。記録する項目は本ガイドの提案。
台帳記録する項目（本ガイドの提案）情報源
① ハードウェア機器名、種別（PC・サーバー・ネットワーク機器・VPN装置・複合機等）、設置場所、管理者、OS／ファームウェアの版、サポート期限、インターネットに公開しているか資産管理ツール、ネットワーク機器の管理画面、購入記録
② ソフトウェア・クラウド製品名、版、用途、管理者、サポート期限、利用中のSaaSとその管理者アカウント端末管理ツール、経理の支払記録（SaaSの契約の洗い出しに有効）
③ 外部公開面公開しているIPアドレス・ドメイン・URL・ポート、そこで動いている製品と版、管理画面の有無DNSの登録内容、ファイアウォールの設定、外部からのポート確認
④ アカウント利用者、管理者、委託先、共有アカウント、サービス用アカウント、APIキー。MFAの有無、最終ログイン日IDaaS（Microsoft Entra ID、Google Workspace等）の管理画面
⑤ データ個人情報・機密情報の種類、保存場所、件数の目安、保存期間、削除方法業務部門へのヒアリング
⑥ 委託先委託先、委託している業務、渡している情報、付与しているアカウント・権限、契約上の報告義務契約書、アカウント台帳

手順

  1. IPA「中小企業の情報セキュリティ対策ガイドライン」第4.0版の付録「資産管理台帳」のひな形を使うと始めやすくなります[J6]。
  2. ③外部公開面は、社内の記録だけでなく、外から見える状態を確認します。目的は「台帳にないのに公開されているもの」を探すことです。
  3. ①でサポート期限が切れた機器（EOL）を特定します。Windows 10は2025年10月14日にサポートが終了しました。2026年10月13日にはOffice 2021／Office LTSC 2021、Windows 11 24H2（Home／Pro）などのサポートが終了しています[G24]。
  4. 年1回以上、および機器・サービスを追加したときに更新します。
社内の記録（台帳）外から見える状態台帳にあり、公開していない公開の要否を判断済み台帳にないのに公開されている忘れられたサーバー更新されていないVPN装置右端の領域を探すのが目的。パッチも監視も届かないので、見つけたら止める。
図3外部公開面の棚卸しの考え方。社内の記録と、外から見える状態を突き合わせる。

確認方法

  • 外部から確認した公開ポート・URLの一覧が、すべて③の台帳に載っている
  • ④のすべてのアカウントに利用者（責任者）が紐づいている。共有アカウントは一覧化されている
  • EOL機器の一覧と、それぞれの置き換え期限がある

3.ID・認証

目的：盗まれた・推測されたパスワードだけではログインされない状態にする。管理者権限を持つアカウントを最小化し、乗っ取られたときの被害を限定する。

なぜ必要か

  • 半田病院ではVPN装置の管理者資格情報がダークウェブで公開されていました[J16]。アスクルではMFAのない管理者アカウントが不正利用されました[J17]。
  • 国家サイバー統括室は、多要素認証の導入、管理者アカウントの最小化、不要なアカウントの無効化を求めています[J8]。個人情報保護委員会は、安全管理措置の手法例に「フィッシングに強い多要素認証」を加えました[J11b]。
  • 金融庁は証券会社等に対し、ログイン・出金などの重要な操作で、フィッシングに耐性のある多要素認証（パスキーやPKIをベースとした認証など）の実装と、既定での必須化を監督指針に定めました（2025年10月15日適用）[J13b]。SMSのワンタイムコードなどはフィッシングサイトに入力させれば突破できるため、行政はより強い方式を求めています。

やること（1）多要素認証（MFA）を、人がログインする全アカウントに

  1. 対象は、人がインターネットから利用するすべてのログイン（VPN、リモートデスクトップ、メール、クラウドサービス、管理画面）です。社員だけでなく、委託先・一時利用者のアカウントも含めます。
  2. サービス用アカウントやAPIキーのように、プログラムが使う認証情報はMFAを使えません。台帳（④）で責任者を決め、権限を必要な範囲に絞り、使われていないものを定期的に無効化します（本ガイドの提案。クラウドのAPIキーやOAuth連携の棚卸しは第5回で扱います）。
  3. 方式は、下の図の順に強い方式を目標にします。
  4. 例外を作らない。どうしても必要な例外（MFAに対応しない古いシステム等）は、一覧化し、接続元の制限などの代替策と、解消の期限を付けます。
  5. クラウドの管理者はすでに必須化が進んでいます。Microsoftは、Azureポータル・Entra管理センター等へのサインインでMFAを必須化し（2024年10月〜）、2025年10月1日からはAzure CLI・PowerShell・IaCツール等での作成・更新・削除操作にも適用しました[G18]。Google Workspaceは全管理者アカウントに2段階認証を段階的に強制しています[G19]。
  6. Microsoft 365で条件付きアクセスのライセンス（Entra ID P1/P2）がない場合は、「セキュリティの既定値」を有効にします。全ユーザーのMFA登録、管理者の毎回のMFA、レガシー認証（MFAを使えない古い認証方式）のブロックが一括で設定されます[G18b]。
強い弱いパスキー・FIDO2セキュリティキーフィッシング耐性あり（偽サイトでは使えない）目標認証アプリのプッシュ（番号照合付き）・ワンタイムコードフィッシング耐性はない当面の標準SMSのワンタイムコード偽サイトに入力させれば突破される移行までの暫定パスワードだけ盗まれた・買われたパスワードでログインされる使わない優先順位は本ガイドの提案。パスキーを目標とする位置づけは、金融庁の監督指針（フィッシングに耐性のあるMFAの必須化）と整合する。
図4多要素認証の方式と、フィッシングへの強さ。優先順位は本ガイドの提案で、パスキーを目標とする位置づけは金融庁の監督指針[J13b]と整合する。

やること（2）パスワード方針を現行の基準に合わせる

米国立標準技術研究所（NIST）のSP 800-63B-4（2025年7月31日確定）は、次のように定めています[G15]。IPAの中小企業向けガイドラインにある「情報セキュリティ6か条」も、パスワードの強化（長く・複雑に・使い回さない）を挙げています[J6]。

やることやめること（してはならない）✓ 単独で使うなら15文字以上MFAの一要素なら8文字以上✓ 漏えい済み・頻出のパスワードと照合該当するものは使わせない✓ パスワードマネージャーと自動入力を許可長いパスワードを無理なく使える✓ 侵害の証拠があるときに変更させる変更のきっかけは「時間」ではなく「事実」✕ 文字種の混在ルール大文字・数字・記号を必ず含める、など✕ 定期的な変更の強制「90日ごとに変更」など社内規程に「90日ごとの変更」「記号を含める」が残っていたら、見直しの対象。出典: NIST SP 800-63B-4（2025-07-31確定）。「やること」はSHALL、「やめること」はSHALL NOTの事項。
図5パスワード方針でやること・やめること（NIST SP 800-63B-4[G15]）。単一要素として使うパスワードは最低15文字、MFAの一要素として使う場合は8文字以上。

やること（3）管理者権限を分ける

  1. 管理者作業用のアカウントを、日常業務（メール・Web閲覧）用のアカウントと分けます（本ガイドの提案。CIS Controls Safeguard 5.4と整合[G13]）。
  2. 管理者アカウントの数を最小にし、誰が持っているかを台帳（④）で管理します[J8]。
  3. PCの利用者には、ローカル管理者権限を与えません（第5回）。

やること（4）アカウントのライフサイクル

作る台帳に登録し、責任者を紐づける使う全員にMFA。管理者は管理作業専用のアカウント終わる退職・異動・委託終了の当日に無効化する定期的な洗い出し一定期間（例: 45日）ログインのない有効アカウントを洗い出し、無効化する。理由があるものは記録する。侵入の痕跡として確認する（IPAの注意喚起）作ったはずのないアカウントはないか。削除・無効化したはずのアカウントが、有効に戻っていないか。
図6アカウントのライフサイクルと管理の要点。45日はCIS Controls Safeguard 5.3の目安[G13]、侵入の痕跡としての確認はIPAの注意喚起（2026年10月）による[J26]。

確認方法

  • IDaaSの管理画面で、MFA未登録のアカウントが0件（または例外一覧と一致）
  • レガシー認証によるサインインが0件（Microsoft 365ではサインインログで確認できる）
  • 管理者ロールを持つアカウントの一覧が台帳と一致し、すべてが管理作業専用である
  • 45日以上ログインのない有効アカウントが0件、または理由が記録されている
  • パスワード方針に定期変更の強制・文字種ルールがなく、漏えいパスワードとの照合がある

4.脆弱性・パッチ管理

目的：修正プログラムを、決めた期限内に、決めた優先順位で適用し続ける仕組みを作る。

なぜ必要か

  • 被害組織の59.0%（2022〜2025年の4年計）に未適用のパッチがありました[J1]。悪用はパッチ公開の平均7日前に始まり（推定）[G2]、KEV掲載脆弱性の修正完了には中央値43日かかっています[G1]。
  • 政府の業務基盤GSSは、公表済みの脆弱性を適用前に突かれました。当初の深刻度評価はCVSS Mediumでした[J15]。CVSSが低いから後回し、という判断は危険です。
受け取るベンダーの配信JPCERT/CC・IPA・KEV照合する台帳に該当製品があるか期限内に当てる優先度ごとの期限自動更新・定例枠当てられないなら止める公開の停止・回避策EOLは置き換え✕海外の事例：BIツールの修正版公開から4日後に侵入されたその組織は、既存の脆弱性通知の仕組みがその勧告を特定できず、対応に回せなかったと公表した。問題はパッチの有無ではなく、情報を受け取って対応に回す仕組みだった。
図7パッチ管理の4つの仕組み。下段の事例はMathspaceの公表による[G25]。

やること（1）情報を受け取る

  1. 台帳にある製品について、ベンダーのセキュリティ情報を受け取る手段（メール配信、RSS）を登録します。
  2. 公的な情報源を毎日確認します。JPCERT/CCの注意喚起[J9]、IPAの緊急対策情報、CISA KEV[G4]です。
  3. 受け取った情報を「自社の台帳に該当製品があるか」で照合する担当と手順を決めます。

やること（2）優先順位と期限を決める

インターネットに公開された機器・サービスかKEV掲載、またはJPCERT/CCが悪用を確認KEV掲載か（社内の機器）はいいいえ緊急即日〜72時間無理なら公開停止か回避策高14日以内通常月次の定例適用はいいいえはいいいえ期限の数値は本ガイドの提案。自組織の体制に合わせて決める。CVSSの数値だけで後回しにしない（第2回）。
図8パッチの優先度と期限の決め方。期限の数値は本ガイドの提案。KEVは実際の悪用が確認された一覧なので、CVSSより優先度の判断に直結する[G4]。EPSS（悪用される確率の推定）は補助的に使える[G5]。
優先度条件適用期限の例（本ガイドの提案）
緊急インターネットに公開された機器・サービスで、KEV掲載またはJPCERT/CCが悪用を確認したもの即日〜72時間。適用できない場合は公開を止めるか、ベンダーの回避策を当てる
高公開された機器・サービスのその他の重要な修正、社内の機器でKEV掲載のもの14日以内
通常上記以外月次の定例適用

米国の連邦機関は、KEV掲載脆弱性への対応期限を課されています[G4]。民間に義務はありませんが、期限の考え方の参考になります。

やること（3）当てる仕組みを自動化する

  1. PCのOS・ブラウザ・Office製品は自動更新を有効にします。IPAの6か条の1番目は「OS・ソフトウェアは常に最新の状態に」です[J6]。
  2. サーバー・ネットワーク機器は、月次の定例メンテナンス枠を決めます。緊急時は枠を待ちません。
  3. 自社で更新を管理しきれない機器（VPN装置など）は、自動で更新されるクラウドサービスへの移行を検討します（次節）。

やること（4）更新できないものは止める

  1. サポートが終了した製品には修正が出ません。置き換えの計画を立てます。米CISA・FBI・英NCSCは2026年2月、サポートが終了したエッジ機器（VPN装置・ファイアウォール・ルーター等）が国家支援の攻撃者に悪用されているとして、置き換えを求める文書を出しました[G17b]。
  2. IPAは2026年10月のPHPの脆弱性について、更新が困難な場合の選択肢として、公開の終了・廃止の検討まで挙げています[J27]。更新できないシステムは公開を止める、という判断基準を事前に決めておきます。

確認方法

  • 台帳の全製品に、情報の受け取り手段と担当者がある
  • 過去3か月のKEV追加分（自社に該当するもの）について、適用日が記録され、期限内である
  • 自動更新が無効になっているPCが0台（端末管理ツールで確認）
  • EOL機器ごとに置き換え期限がある

5.外部公開面とネットワーク

目的：インターネットから到達できる入口を最小にし、残す入口を固める。侵入された場合に、社内全体へ広がらないようにする。

なぜ必要か

  • ランサムウェアの侵入経路は、2021〜2025年の5年計でVPN機器とリモートデスクトップが82.1%を占めます[J1]。
  • JPCERT/CCは、業務上必要のないサービスや機能（管理機能など）がインターネットに公開されている場合は公開を停止するよう求めています[J9]。国家サイバー統括室は、インターネットに公開されていない内部のサーバ等も含めて、不要なポートの無効化を求めています[J8]。
見直し前インターネットVPNRDP管理画面BIツールWeb社内ネットワーク（1つにつながっている）サーバー業務PC来客・私物バックアップ1か所入られると、全体に広がる見直し後インターネットZTNA・SSE公開Web✕ RDP✕ 管理画面アプリ単位で接続サーバー業務PC来客・私物管理用バックアップ業務ネットワークから直接届かない場所に公開を減らし、残す入口を固め、入られても広がらないように分ける。
図9外部公開面とネットワークの見直しの前後。ZTNA・SSEへの移行はCISA・FBI等の推奨[G17]、ネットワークの分け方は本ガイドの提案。

やること（1）公開しているものを減らす

  1. ③外部公開面の一覧を見て、公開が必要か一つずつ判断します。不要なものは公開を止めます。
  2. リモートデスクトップ（RDP）をインターネットに直接公開しません。
  3. 管理画面（VPN装置・ルーター・Webシステムの管理機能・BIツール等）は、インターネットから到達できないようにします。どうしても必要なら、接続元のIPアドレスを限定します。JPCERT/CCは、利用地域が限られる場合のアクセス元地域の制限も挙げています[J9]。

やること（2）VPN装置を固める、または置き換える

  1. 残すVPN装置は「緊急」の枠で更新し、管理者アカウントとVPN利用者の全員にMFAを付けます。
  2. 脆弱性が公表されたVPN装置で侵害の可能性がある場合は、更新に加えて認証情報を変更します。半田病院では脆弱性から管理者資格情報が取得され公開されていました[J16]。更新だけでは、盗まれた認証情報は無効になりません。
  3. 置き換えの選択肢として、米CISA・FBI等の共同文書（2024年6月）は、従来型のVPNからゼロトラスト（ZTNA）、SSE、SASEといった方式への移行を推奨しています[G17]。これらは、利用者がアプリケーション単位で接続し、社内ネットワーク全体には入れない設計で、提供者が基盤を更新するクラウドサービスとして提供されることが多い方式です。

やること（3）社内ネットワークを分ける

  1. 少なくとも、サーバー、業務PC、来客・私物端末、管理用ネットワークを分け、必要な通信だけを許可します（本ガイドの提案）。
  2. バックアップの保管先は、業務ネットワークから直接到達できないようにします（第5回）。

確認方法

  • 外部から確認した公開ポートが、すべて台帳上「公開が必要」と判断されたものだけである
  • RDPがインターネットに公開されていない
  • 管理画面にインターネットから到達できない（社外の回線から試す）
  • VPN装置の版が最新で、全利用者にMFAがある

ここまでで、入口の対策は揃う

棚卸しで入口を把握し、不要な公開を止め、残した入口にMFAと期限付きのパッチ適用を当てる。それでも入られることを前提に、被害を限定し、戻れるようにする対策を第5回で扱います。

Summary

この記事の要点

  1. 1知らないものは守れない。ハードウェア・ソフトウェア・外部公開面・アカウント・データ・委託先の6つの台帳を最初に作る。
  2. 2外部公開面は外から見える状態で確認し、「台帳にないのに公開されているもの」を探して止める。
  3. 3MFAは、人がログインする全アカウント（委託先・一時利用者を含む）に。サービス用アカウントやAPIキーは、責任者・最小権限・定期的な棚卸しで管理する。パスキーなどフィッシングに強い方式を目標にし、例外は一覧化して期限を付ける。
  4. 4パスワードは単独なら15文字以上。文字種ルールと定期変更の強制はやめ、漏えいパスワードとの照合とパスワードマネージャーを使う。
  5. 5パッチは「受け取る・照合する・期限内に当てる・当てられないなら止める」の仕組みで回す。公開機器でKEV掲載のものが最優先。
  6. 6RDPと管理画面はインターネットに出さない。VPN装置は更新とMFA、侵害の可能性があれば認証情報も変える。社内は分ける。

Sources

出典

本文の事実・数値は、以下の官公庁・公的機関・標準化団体・ベンダー公式の原文に基づいています。数値は各出典の公開時点、または2026年10月27日の集計時点のものです。

FAQ

よくある質問

棚卸しから始めることを勧めます。知らないものは守れないためです。ハードウェア、ソフトウェア・クラウドサービス、外部公開面、アカウント、データ、委託先の6つの台帳を作ります。外部公開面は社内の記録だけでなく外から見える状態を確認し、「台帳にないのに公開されているもの」を探して止めます。IPAの中小企業向けガイドラインの資産管理台帳のひな形を使うと始めやすくなります。

パスキーやFIDO2セキュリティキーなど、フィッシングに耐性のある方式を目標にします。SMSのワンタイムコードは、偽サイトに入力させれば突破できるため、移行までの暫定と位置づけます。金融庁は証券会社等に、ログイン・出金などの重要な操作でフィッシングに耐性のある多要素認証の実装と必須化を求めています。

米国立標準技術研究所（NIST）のSP 800-63B-4は、定期的な変更を要求してはならないとしています。侵害の証拠がある場合に変更させます。あわせて、単独で使うパスワードは15文字以上、文字種の混在ルールは課さない、漏えい済み・頻出のパスワードと照合する、パスワードマネージャーと自動入力を許可する、としています。社内規程に「90日ごとの変更」が残っている場合は見直しの対象です。

インターネットに公開された機器・サービスで、KEV（実際に悪用が確認された脆弱性の一覧）に載っているものやJPCERT/CCが悪用を確認したものを最優先にします。本ガイドでは、これを即日〜72時間、公開機器のその他の重要な修正と社内機器のKEV掲載分を14日以内、それ以外を月次の定例適用とする目安を提案しています。CVSSの数値だけで後回しにしないことが重要です。

残す場合は、最優先の枠で更新し、管理者とVPN利用者の全員に多要素認証を付けます。脆弱性が公表されて侵害の可能性がある場合は、更新に加えて認証情報も変更します。置き換えの選択肢としては、米CISA・FBI等が、従来型のVPNからゼロトラスト（ZTNA）、SSE、SASEといった方式への移行を推奨しています。

Next

シリーズの前後

第3回

AIが変えたこと・変えていないこと

第5回 — 準備中

入られる前提で守る — 端末・メール・SaaS・データ・バックアップ・ログ

AIの導入とセキュリティを、あわせて相談したい方へ

homulaは、AIエージェントを業務に導入する企業に向けて、統制ポリシー・権限・監査ログの設計から運用までを支援しています。AIを載せる前提となる基盤の点検も含めてご相談ください。

AIガバナンス設計支援を見る無料で相談する
資料DLデモ・相談を依頼