サイバー攻撃への備え｜企業が進めたい7つの対策と初動対応

サイバー攻撃への備えは、侵入を防ぐ対策、異常を見つけて被害を抑える体制、業務を復旧する準備を組み合わせて進めます。ソフトウェアの更新や認証の強化に加え、バックアップ、連絡先、復旧手順を日頃から確認することが大切です。

Webサイト、メール、クラウド、取引先とのデータ共有が止まると、問い合わせ対応や受発注にも影響が及びます。この記事では、中小企業やWebサイト運営者に向けて、サイバー攻撃対策の優先順位、被害が疑われたときの初動、AIを利用する際の備えまで解説します。

情報確認日：2026年10月29日。IPA、CISA、WordPress、OWASPの公式資料を参照して構成しています。一般的な備えを解説する記事であり、特定のサイトの安全性を診断したものではありません。対応は、自社の体制・設備・契約に合わせて具体化してください。

サイバー攻撃への備えが必要な理由

サイバー攻撃では、情報を盗まれるだけでなく、システムの停止、Webサイトの改ざん、アカウントの乗っ取り、取引先へのなりすましなどが問題になります。顧客情報を大量に持っていない会社でも、メールや共有ファイルが使えなくなれば、業務の継続に支障が出る可能性があります。

2026年10月9日のIPAの注意喚起では、外部公開アプリケーション、利用する外部サービス、保有するデータの点検が挙げられています。自社で作ったシステムだけでなく、クラウドや外部連携も含めて把握する視点が重要です。出典：不正アクセスによる漏えい等を踏まえたIPAの注意喚起。

すべての攻撃を一つの製品で防ぐことはできません。「どの被害を減らしたいか」「異常を誰が判断するか」「止まったときに何から戻すか」を決め、技術と運用をつなぐことが備えの中心になります。

想定しておきたい攻撃と影響

攻撃の名前を覚えるだけでなく、自社のどの入口から、どの業務へ影響が出るかを考えます。次の表は、点検のために整理した代表例です。

スマートフォンでは表を横にスクロールできます。複数の手口が組み合わされる場合もあります。

たとえば、認証情報の流出がメールの不正利用につながり、取引先へ偽の案内が送られることも考えられます。パスワードだけ、端末だけという分け方にせず、利用するサービスと業務の流れを合わせて点検しましょう。参考：IPA「中小企業の情報セキュリティ対策ガイドライン」。

企業が進めたい7つの対策

1．守る情報とシステムを洗い出す

パソコン、スマートフォン、ルーター、Webサイト、メール、クラウド、外部委託先、AIとの連携を一覧にします。それぞれの管理者、契約先、使っているアカウント、保存するデータ、停止したときの影響を確認してください。

最初から完璧な台帳を目指すより、受発注、顧客対応、経理など重要な業務から整理する方法があります。不要な個人情報を持ち続けていないか、使っていないサービスや外部連携が残っていないかも確認します。

2．ソフトウェアと機器を更新する

OSやブラウザーだけでなく、VPN機器、ルーター、サーバー、CMS、プラグインなども対象です。利用製品の公式情報を受け取り、サポートが終了した製品は更新・移行の計画を立てます。

更新前のバックアップや動作確認も必要ですが、確認待ちのまま重要な修正を放置しない運用が大切です。担当者、優先順位、実施日、確認結果を残します。脆弱性対策と公開範囲の点検の参考：IPAの点検・対策項目。

3．認証を強化し、パスワードを使い回さない

メール、クラウド、管理画面、リモート接続など、影響が大きいアカウントから多要素認証を設定します。対応する環境では、FIDO/WebAuthnに基づくパスキーやセキュリティキーなど、フィッシングへの耐性がある認証方式を検討します。

多要素認証にも方式の違いがあります。身に覚えのない承認通知を許可しないこと、回復用の情報を保護することも含めて運用します。CISAはフィッシング耐性のある認証の導入を推奨しています。出典：CISA「Implementing Phishing-Resistant MFA」（PDF）。

4．必要な人に、必要な権限だけを渡す

日常の作業すべてを管理者権限で行わず、閲覧、編集、設定変更などの役割を分けます。退職・異動・契約終了時には、アカウントだけでなく、共有リンク、APIキー、外部委託先の接続も確認します。

共有アカウントを減らして誰が操作したかを追える状態にすると、誤操作や不正利用の調査にも役立ちます。例外的に広い権限を使う場合は、利用目的、担当者、期間を明確にします。

5．端末の保護と、怪しい依頼の確認を習慣にする

組織で管理する端末では、マルウェア対策、画面ロック、更新、紛失時の対応を整えます。検知製品を導入する場合も、通知を誰が見て判断するかまで決めなければ、対応にはつながりません。

メールやチャットで請求先変更、ログイン、ファイルの実行などを求められたら、送信者の表示名だけで判断しないようにします。普段と違う依頼は、以前から知っている電話番号や正式な窓口など、別の経路で確認する手順を用意しましょう。

6．バックアップを守り、復元を試す

元のデータと同じ権限で変更・削除できる場所だけに保存すると、バックアップも同時に被害を受けるおそれがあります。オフラインのコピーや、改変・削除を制限できる保存先などを組み合わせ、複数の時点へ戻せるようにします。

自動処理が成功したという通知だけでは、業務を戻せるかまではわかりません。復元手順、必要な認証情報、復元したデータの確認方法をそろえ、隔離した検証環境で試します。バックアップと復旧計画の参考：CISAのランサムウェア対策・対応資料（PDF）。

7．異常の通知と連絡先を整える

見覚えのないログイン、新規管理者の作成、不自然な大量送信、Webページの改ざん、バックアップの失敗など、確認する通知やログを決めます。通知先が担当者一人だけにならないよう、代理担当と不在時の連絡方法も用意します。

ログは取得して終わりではありません。保存期間、調べられる担当者、必要な権限、相談先へ安全に渡す方法を確認します。パスワードやAPIキーなどの秘密を、調査メモやチャットへそのまま貼らない配慮も必要です。

WordPress・Webサイト運営での備え

Webサイトでは、WordPressだけでなく、サーバー、ドメイン管理、管理者のメール、ファイル転送用の認証情報までがつながっています。一つのプラグインを追加しただけで、これらすべてが保護されるわけではありません。

• WordPress本体、テーマ、プラグインを、提供元の情報に基づいて更新する。
• 不要なプラグイン・テーマ・アカウントを整理し、信頼できる配布元を使う。
• 記事の編集者に、ユーザー管理やサイト設定まで変更できる権限が必要か見直す。
• 管理画面やサーバーの認証を強化し、対応するアクセス制限やWAFなどを補助として使う。
• 更新や設定変更の前後で、表示、フォーム、ログインなど重要な機能を確認する。

WordPressの公式資料も、更新、アクセス範囲の制限、信頼できる配布元、バックアップなどを組み合わせる考え方を示しています。WAFやログイン制限は補助策であり、脆弱なソフトウェアの更新や権限管理を置き換えるものではありません。出典：WordPress公式「Hardening WordPress」。

PHPやCMSの更新については、関連記事の「PHPの脆弱性について」でも解説しています。

異常に気づいたときの初動

まず、疑いの段階で報告する

画面に不審な要求が出た、勝手にメールが送られた、知らない管理者が増えた、といった段階でも、決めておいた担当者へ連絡します。攻撃と断定できるまで一人で調べ続けるより、発見時刻、対象、症状、直前に行った操作を共有することが重要です。

安全を確かめ、被害が広がる経路を抑える

感染が疑われる業務端末では、手順や担当者の指示に従い、ネットワークからの隔離などを行います。工場設備など、停止が安全や現場の稼働に影響する対象は、一律に切断せず、現場責任者と専門家が判断します。

クラウドの不正利用なら、正常な端末や連絡手段を使い、担当者が対象アカウント、セッション、外部連携の制限を検討します。パスワードを変更しただけで、すべての接続やセッションが無効になるとは限らない点にも注意します。

証拠を残し、相談しながら復旧を進める

時刻、表示されたメッセージ、関係するメール、通知、ログなどを、組織の手順に従って保全します。不審なファイルを開き直したり、別のパソコンへ無造作にコピーしたりしないようにします。秘密情報を含む記録は、アクセスを制限して扱ってください。

自己判断で初期化・ファイル削除・再起動を急ぐと、調査に必要な情報を失う場合があります。CISAのランサムウェア対応資料も、ネットワーク隔離を優先し、電源断は隔離ができない場合など必要な条件で判断すると説明しています。出典：CISAのランサムウェアによる情報漏えいへの対応資料（PDF）。

連絡先は、社内責任者、保守会社、クラウド提供元、契約するセキュリティ支援先などを事前に整理します。状況に応じて警察などの関係機関へ相談し、IPAのサイバーセキュリティ相談・届出窓口一覧や不正アクセス対策特設サイトも参照してください。顧客・取引先への連絡や必要な報告は、担当者と専門家が確認して進めます。

バックアップと事業継続の準備

何を、どの時点まで、どれくらいの時間で戻すか

バックアップの頻度は、データが変わる頻度と、どれだけの情報を失うと困るかで決めます。更新が少ない案内ページと、注文が入る販売システムでは、必要な準備が違います。「毎日保存しているから十分」と一律には判断できません。

復旧の優先順位も決めます。受注、顧客への連絡、会計、Webサイトなどのうち、先に動かす業務は何か。担当者が不在でも、復旧先、認証情報の保管先、確認手順へたどり着けるかを点検しましょう。

同期・保存・復元を区別する

クラウドへの同期は便利ですが、削除や暗号化などの変更が同期先へ反映される場合があります。履歴の保持期間、復元できる対象、管理者による削除の制限を確認し、必要なら別の保存先も用意します。

また、バックアップを戻すだけでは侵入経路が残る可能性があります。原因への対処、利用するデータや環境の健全性の確認、再接続の判断、再発を監視する体制まで含めて復旧を進めます。

AIを使う業務で増やしたい確認

AIが文書を読んだり、ブラウザーや外部ツールを操作したりする場合は、人に渡すアカウントと同じように、アクセスできる情報と実行できる操作を管理します。便利さに合わせて管理者権限をまとめて渡すと、誤操作や外部の不正な指示の影響が大きくなります。

読む情報と、実行する操作を分ける

外部のWebページや文書に書かれた指示を、社内の承認と同じ扱いにしない設計が必要です。プロンプトインジェクションでは、AIが読む情報に紛れた指示によって、意図しない操作へ誘導されることがあります。

AIに渡すデータを業務に必要な範囲へ絞り、参照だけの作業と、公開・送信・削除・設定変更を分けます。重要な操作は対象と変更内容を人が確認し、問題があれば連携を止められるようにします。

AIの連携先と秘密情報の扱いを管理する

パスワードやAPIキーを会話へ貼り付ける運用を避け、承認された管理方法を使います。接続先ごとに、利用目的、権限、担当者、停止方法を残してください。出力ログやAIへ渡すファイルに秘密が混ざっていないかも確認します。

OWASPは、AIエージェントに最小権限、外部入力への対策、人による重要操作の確認、監視などを組み合わせることを推奨しています。出典：OWASP「AI Agent Security Cheat Sheet」。

今後、複数のAIや業務サービスが連携するほど、どのAIが何へアクセスしたかを追い、不要な接続を止められる運用が重要になると考えられます。これは本記事の展望であり、AIの導入だけで防御や復旧が自動的に完成するという意味ではありません。

認証情報とAI連携については、関連記事の「1Password CLIとは？使い方・料金・AI連携と安全な運用を解説」もご覧ください。

今日から始める実行計画

やることが多いときは、事業への影響と、外部から利用される範囲を基準に順序を付けます。次は本記事の実行計画の例です。すでに攻撃が疑われる場合は、この予定を待たずに初動対応へ進んでください。

訓練では「会社のメールが使えない」「担当者が不在」「バックアップから戻せない」といった条件を一つずつ試します。チェック表の記入だけで終えず、連絡先がつながるか、必要な操作ができるかを確かめましょう。

専任担当者を置きにくい場合は、保守会社や外部のセキュリティ支援を検討します。対応範囲、夜間・休日、ログの調査、復旧支援、連絡方法、費用を確認し、自社で担う部分も明確にしてください。対策の段階的な進め方は、IPAの中小企業向けガイドラインも参考になります。

サイバー攻撃への備えについてよくある質問

防御・初動・復旧を、日々の運用につなげる

サイバー攻撃への備えは、守る対象を把握し、更新・認証・権限・端末の保護を続けることが土台になります。そこへ、異常の通知、報告しやすい連絡体制、保護されたバックアップ、復旧の確認を組み合わせます。

「対策を入れたか」に加え、「異常に気づき、連絡でき、必要な業務を戻せるか」まで確かめましょう。AIや外部サービスが増えたときも、その都度アクセス範囲と停止方法を見直し、備えを業務の中へ組み込むことが大切です。