メインコンテンツへスキップ
見出し画像

サイバー攻撃への備え、何から手をつけるか|技術対策と組織対応

    「多要素認証は入れました」「バックアップも取っています」。
    そう答えられる会社は増えました。

    けれど、その多要素認証はどの方式でしょうか。
    そのバックアップは、実際に復元したことがあるでしょうか。
    2026年時点で問われているのは、導入したかどうかではなく、その中身が本当に効くのかというところです。

    この記事では、個人・企業がすぐに着手できる技術的対策と、技術だけでは埋まらない組織としての備えを整理します。
    攻撃側の手口については別の記事にまとめています。

    https://note.com/yunta_fukurou/n/n888367434664

    この記事は、警察庁・金融庁などの一次資料をもとに、2026年9月時点の内容にしています。


    今すぐできる技術的対策

    多要素認証(MFA):「設定した」だけでは不十分

    パスワードの使い回しを突く攻撃は、依然として深刻です。
    その深刻さを示したのが、2025年春に社会問題化した証券口座の乗っ取りでした。

    この事態を受け、日本証券業協会(JSDA)は2025年10月15日、「インターネット取引における不正アクセス等防止に向けたガイドライン」を改正・施行しました。
    ログイン時、出金時、出金先銀行口座の変更時など、重要な操作時にフィッシング耐性のある多要素認証を必須とする内容で、具体的な方式としてパスキーによる認証とPKI(公開鍵基盤)をベースとした認証が挙げられています。

    ここで注目すべきは、従来のワンタイムパスワード(OTP)が「フィッシング耐性のある認証方式」として位置づけられていない点です。
    代替的な多要素認証という扱いにとどまりました。

    実際の対応も進んでいます。
    野村證券は2025年11月29日からパスキー認証を必須化し、さらに2026年6月27日には、ログイン・取引・出金時のパスキー認証必須化へと対象を広げています。

    つまり、多要素認証には強さの差があるということです。
    フィッシング耐性の低いものから順に並べると、こうなります。

    • SMSによるワンタイムパスワード:手軽だが、SIMスワップ(携帯電話番号の乗っ取り)のリスクがあり、フィッシング耐性は低め

    • 認証アプリ(Google Authenticator、Microsoft Authenticatorなど):SMSより安全だが、偽サイトに誘導されて認証コードごと盗まれるリスクは残る

    • パスキー/FIDO2、セキュリティキー(YubiKeyなど):秘密鍵が端末やキーの中に保持され、フィッシングサイトでは原理的に認証が成立しないため、現時点でもっとも強固

    「多要素認証を設定しているから安心」ではなく、「どの方式の多要素認証か」まで意識することが、2026年時点では重要になっています。
    行政分野でもデジタル庁のDS-511ガイドラインが公開鍵方式(パスキー等)による本人確認の重要性を示しており、官民を挙げてパスワードレスへ移行しつつある状況です。

    脆弱性管理:「知らなかった」を無くす仕組み

    ランサムウェアの主要な侵入経路はVPN機器です。
    警察庁が2026年3月に公表した令和7年(2025年)の資料では、被害組織へのアンケート結果として、侵入経路の6割以上をVPN機器が占めています。

    Fortinet、Ivanti、Citrixなど、自社が使っている機器のメーカーが脆弱性情報を公開したら、可能な限り早く確認・適用する体制が必要です。
    具体的には、次のような運用ルールを決めておくことをおすすめします。

    • 自社で使用している主要機器・ソフトウェアのメーカー名、製品名、バージョンを一覧化しておく

    • 各メーカーのセキュリティ情報配信(メールマガジンやRSS等)に登録し、担当者が定期的に確認する

    • 緊急度の高い脆弱性(すでに悪用が確認されているもの)が公表された場合は、通常のパッチ適用サイクルを待たず、優先的に対応する

    地味な作業ですが、機器の一覧すらない状態では「自社が対象かどうか」の判断すらできません。
    まずは一覧を作るところからです。

    バックアップ:「取得」ではなく「復元できるか」

    警察庁の過去の調査(令和4年時点)では、バックアップを取得していた組織は83%にのぼった一方、実際に復元を試みたもののうち、被害直前の水準まで戻せなかったケースが81%にのぼりました。

    重要なのは、次の3点です。

    • 3-2-1ルール:3つのコピーを、2種類の異なるメディアに保存し、うち1つはネットワークから切り離した場所(オフライン媒体や書き換え不可のクラウドストレージ)に保管する

    • 年に一度は実際に復元テストを行い、「本当に元に戻るか」を確認する

    • バックアップ自体が暗号化されないよう、バックアップシステムへのアクセス権限も最小限に絞る

    3つ目は見落とされがちですが、攻撃者は侵入後にバックアップを探して真っ先に潰しにきます。
    バックアップサーバーに管理者権限で誰でも入れる状態では、意味がありません。

    EDR:侵入されたことに気づく仕組み

    ウイルス対策ソフト(アンチウイルス)は既知のウイルスパターンを検知する仕組みですが、近年の攻撃は未知の手口やファイルを使わない侵入も多く、これだけでは防ぎきれません。

    そこで有効なのが、端末の不審な挙動そのものを検知するEDR(Endpoint Detection and Response)です。
    Microsoft Defender for Endpoint、CrowdStrike Falcon、トレンドマイクロ Apex Oneなど、複数のベンダーから製品が提供されています。

    導入していない場合は、まず自社の重要端末(サーバーや経営層の端末など)から優先的に検討するのが現実的です。
    全社一斉導入を目指して予算が付かず何年も止まるより、狙われやすいところから入れるほうが早く効きます。

    PR

    PR


    組織としての備え

    ゼロトラストという考え方

    従来のセキュリティ対策は「社内ネットワークの中は安全、外は危険」という前提で、境界線(ファイアウォールなど)を守る発想が中心でした。
    しかし、テレワークの普及やクラウドサービスの利用拡大により、この「境界線」という考え方自体が崩れてきています。

    そこで近年主流になっているのが「ゼロトラスト」という考え方です。
    社内・社外を問わず「何も信頼せず、都度確認する」という発想で、米国立標準技術研究所(NIST)が「NIST SP 800-207」としてその枠組みを整理しています。
    日本国内でも、デジタル庁や国家サイバー統括室が政府情報システムのゼロトラスト移行方針を示しています。

    難しく聞こえますが、要は「社内からのアクセスだから安全」と思い込まず、社内であっても毎回きちんと本人確認(多要素認証など)を行う、という前半で解説した技術的対策の延長線上にある考え方です。

    CSIRT:インシデント対応の司令塔

    CSIRT(Computer Security Incident Response Team)とは、セキュリティ上のインシデントが発生した際に対応する専門チームのことです。

    やや古い数字になりますが、IPAが2017年に行った調査では、CSIRTなどのインシデント対応組織の設置状況は、日本が66.8%だったのに対し、欧州は78.0%、米国は90.1%でした。

    CSIRTは必ずしも専任の独立部署である必要はありません。
    脅威の大きさや保有する情報資産の価値、予算に応じて、既存の情報システム部門内に役割として位置づける形でも構いません。
    重要なのは「インシデントが起きたときに誰が指揮を取り、どこに報告し、どう動くか」があらかじめ決まっていることです。
    自社での構築が難しい場合は、外部のインシデントレスポンスプロバイダーを活用する選択肢もあります。

    標的型メール訓練:責めるのではなく、通報しやすくする

    日本シーサート協議会(NCA)が実施したアンケートによると、標的型攻撃メールを模した訓練を実施済み、または実施予定の企業は8割以上にのぼるとされています。

    訓練は、対象者全員に一斉送信する方法のほか、役職ごとに引っかかりやすい文面を変える方法もあります。
    役員層には「セミナー講師依頼」、一般職層には「メールボックス容量超過」といった具合に出し分け、開封率・通報率を層別に評価します。

    ただし、重要なのは「開封してしまった人を責める」ことではなく、「通報しやすい雰囲気を作る」ことです。
    訓練で開封してしまっても、すぐに情報システム部門へ通報できれば被害は最小限に抑えられます。
    逆に、怒られるのが怖くて黙っていた数時間が、被害を決定的にします。

    ここで挙げた備えのうち、実際に被害が出た朝の手順を、別の記事で配っています。
    時間帯ごとの動きと、報告書式6種をまとめています。


    2026年8月時点の最新状況

    ここからは、2026年に入ってから動いた点をまとめます。

    パスキー移行の効果が、実際の数字に出てきた

    前半で触れた証券口座の乗っ取りは、対策の効果が数字で確認できる珍しいケースになりました。

    金融庁は、証券会社のインターネット取引サービスにおける不正アクセス・不正取引の被害状況を毎月集計・公表しています。
    2026年8月10日更新の資料を見ると、被害は2025年3月から8月にかけて集中し、その後大きく減少しています。
    2026年に入ってからは月あたりの不正アクセスが数百件規模まで下がり、直近では二桁台まで落ち着きました。

    この間に起きたことが、日本証券業協会のガイドライン改正(2025年10月15日)と、各社のパスキー必須化です。
    「フィッシング耐性のある方式に切り替えれば、被害は実際に減る」ということが、業界規模の実例として示されたわけです。

    最新値は毎月更新されるため、金融庁のページで確認してください。

    中小企業ほど狙われ、そのほとんどが計画を持っていない

    2026年3月公表の警察庁資料からは、被害の分布が読み取れます。

    • ランサムウェア被害を受けた組織のうち、中小企業が約6割

    • 業種別では製造業が約4割

    • 一方で、BCP(事業継続計画)を策定済みの組織は約18%

    つまり、報告している組織の8割強は、事業継続計画を持たないまま被害に遭っています。
    復旧に総額1,000万円以上を要した組織は全体の5割を超え、1か月未満で復旧できたのは5割強にとどまりました。

    CSIRTの整備やBCPの策定は「大企業の話」ではありません。
    むしろ、専任担当者がいない中小企業ほど、事前に「誰が何をするか」を紙に書いておく価値が大きくなります。


    まとめ

    技術的対策と組織的な備え、両方を見てきました。

    • 多要素認証は「入れたか」ではなく「どの方式か」。パスキー/FIDO2がもっとも強い

    • 脆弱性管理は、まず機器の一覧を作るところから

    • バックアップは「取得」ではなく「復元テストをしたか」。バックアップ自体の権限管理も忘れない

    • EDRは全社一斉を待たず、重要端末から

    • ゼロトラストは、技術的対策の延長線上にある考え方

    • CSIRTは専任部署でなくてよい。誰が指揮を取るかが決まっていることが本質

    • メール訓練は、開封率より通報しやすさを作るための仕掛け

    証券業界のパスキー移行が示したのは、正しい方式に切り替えれば被害は実際に減るという事実です。
    抽象的な「セキュリティ意識の向上」ではなく、方式を変える、テストする、担当を決める。
    効くのは、そういう具体的な行動のほうです。

    皆さんの会社では、バックアップの復元テスト、最後にいつやりましたか。


    参考・引用元


    実務で使う書式について

    この連載の内容を、社内でそのまま使える書式にまとめたものを、別のマガジンで公開しています。
    規程のひな形、対応フロー、チェックシート、報告書式などです。

    実務で使う書式・キット
    https://note.com/yunta_fukurou/m/mfc25857fab40


    関連する記事

    NASを使っている場合の具体的な守り方は、別の記事で扱っています。
    メーカーが公式に挙げている設定と、3-2-1ルールをまとめています。
    https://note.com/yunta_fukurou/n/n3da1f48b059c

    認証情報の使い回しをどう断つかについては、こちらで扱っています。
    パスワードマネージャーとパスキーの現在地をまとめています。
    https://note.com/yunta_fukurou/n/n235bb2e43f79

    社外からの接続経路としてVPNを使っている場合の論点は、別の記事で扱っています。
    VPN機器が狙われている実態と、ゼロトラストという考え方をまとめています。
    https://note.com/yunta_fukurou/n/nfab4459cedb4

    境界に置く機器そのものの選び方と確かめ方は、別の記事で扱っています。
    「入口・内部・出口」という分け方が公的資料でどう使われているかを確かめ、機器を足す前に見る3点をまとめています。
    https://note.com/yunta_fukurou/n/n8483037cfd1d

    通信の暗号化を支えるサーバ証明書には、有効期限があります。
    その上限が短くなっていく話と、期限の数え方は、別の記事で扱っています。
    https://note.com/yunta_fukurou/n/n30db220f551f

     
     
    Digital Workplace Architect|社内外のIT・AIの導入と運用 IT・AI・セキュリティと周辺機器の「今さら聞けない」を一次情報で解説。書式・キットも。 Amazonのアソシエイトとして、梟 〜GLEANINGS〜は適格販売により収入を得ています。

    あなたへのおすすめ