パフォーマンスの最適化は「より速く」に対処するものだが、ウェブサイトにとって本当に重要なことは2つある:

  • 確実性トラブルに巻き込まれないように(ハッキングされないように、ハングアップしないように、クラッシュしないように、インターフェイスを盗まれないように、改ざんされないように)。
  • バックアップ何か問題が発生した場合(誤削除、アップグレード・ロールオーバー、サーバー障害、身代金要求/侵入後のロールバック)でも、迅速に復旧できます。

次の2つは互いに補い合うものだ:

  • セキュリティーだけを行い、バックアップを行わない場合でも、コントロールできない問題が発生した場合は、一晩でゼロにすることができる。“
  • バックアップだけやってセキュリティはやらないというのでは、「毎日やられて毎日復旧する」というサイクルに陥ってしまい、時間もコストもどうにもならなくなってしまう!

読めばできるようになるはずだ:

  • バックアップとセキュリティー」でカバーすべきものを正確に把握する(間違ったものを購入し、間違ったものをインストールし、それが確実だと思い込まないようにするため)。
  • サイトのタイプ(コンテンツサイト/ビジネスサイト/eコマース/会員制サイト)に応じて適切なソリューションを選択する能力
  • ロードマップに沿って段階的に本番稼動が可能(弾力的、次に制御可能、次に体系的)
  • 自己診断チェックリストで確認可能:バックアップ本当に回復可能なんだ。セキュリティディフェンスは本当にある。
  • 問題発生時(バックアップの失敗、リカバリーの失敗、ハッキングの疑いなど)、まずどこを見るべきかを知る。

1.目標:「プラグイン」ではなく「復旧可能なシステム」が必要。“

バックアップとは、“バックアップファイルを持つこと ”ではない。”

その代わりだ:必要なときに必要な状態にサイトを戻すことができるか?

つまり、バックアップの重要な指標は、「バックアップ・プラグインがインストールされているかどうか」ではなく、この2つなのだ:

  • 許容データ損失ウィンドウ(RPO)最悪の場合、データを失うことをいつまで許容できますか?
    例:コンテンツサイトが24時間分の記事を失うのは許容範囲かもしれないが、eコマースサイトが30分分の注文を失うのは深刻だ。
  • 許容復旧時間(RTO)事故後、どのくらいでオンラインに復帰できる見込みですか?
    例:企業サイトは1時間以内に、eコマース・サイトは10~30分以内に復旧したいかもしれない。

これらの指標を計算式に書き込む必要はないが、判断材料にしてほしい:バックアップ頻度、保持時間、リアルタイム/増分バックアップの必要性、ワンクリック・リカバリ/オフサイト・リカバリの必要性

2.サイトタイプ別の迅速な戦略策定(オリエンテーション、次にツールの選択)

戦略のアドバイス

A. コンテンツサイト/ブログ

  • 変更の頻度:通常は「毎日/毎週“
  • 推奨バックアップ頻度日常データベースのバックアップ + wp-コンテンツ(アップロード/テーマ/プラグイン)
  • 回復目標:昨日/今日のバージョンで十分(記事とメディア・ライブラリーを失わないことに重点を置く)。

B. ビジネスサイト/マーケティングサイト(フォームリードが重要)

  • 変更の頻度:必ずしも高くないが、フォーム/リードが重要
  • 推奨バックアップ頻度:データベース最低日常フォームデータとEメール/CRMは “一か所 ”には存在しない。”
  • リカバリーの目標:更新/改訂/追加追跡スクリプトで問題が発生した場合の迅速なロールバック

C. Eコマースサイト(WooCommerce)

  • 変更頻度:注文/在庫/ユーザーの行動 継続的
  • 推奨バックアップ頻度:優先高周波(1時間ごと、あるいはリアルタイム/ほぼリアルタイムで)、少なくともデータベースの保護を強固にする。
  • 復旧目標:注文データの損失を最小限に抑える。

D. 会員制サイト/コースサイト/コミュニティ

  • 変更頻度:ユーザーの進捗状況、パーミッション、コンテンツのロック解除、インタラクションデータ
  • 推奨バックアップ頻度:データベースはより高い頻度で。
  • リカバリーの目標:ユーザーデータは混乱せず、パーミッションは失われず、コンテンツは改ざんされない。

3.バックアップ・ロードマップ(この3つのフェーズで進めることを推奨する)

ハイライトまずは “可能なリカバリー ”を行い、それから “自動化とシステム化 ”の話をしよう。

ステージ1:“自動バックアップ+オフサイト・ストレージ ”から始める”

これが結論だ。どんなツールを使うにせよ、それを満たせ:

  • 自動:: “手動でクリックするのを忘れないようにする ”に頼ってはいけない。”
  • オフサイトストレージバックアップを同じサーバーに置かない
    サーバーがハングアップしたり、ディスクが壊れたり、ライブラリーを削除するためにアカウントに侵入されたりすると、「ローカル・バックアップ」も一緒に消えてしまうからです。

このツールの代表的な実装には以下のようなものがある:

  • バックアッププラグインは、バックアップをクラウドドライブ/オブジェクトストレージ/FTP (アップドラフトプラス (例えば、Dropbox、Google Drive、Amazon S3、その他多くのターゲットが明示的にサポートされている)。
  • クラウドバックアップサービスは、バックアップをクラウド上に置き、ワンクリックでリカバリできる(Jetpack VaultPressバックアップ (主にクラウドバックアップとワンクリックリカバリーだが、バックアップの有料プランを含める必要がある)

フェーズ2:バックアップを “復旧可能なシステム ”にアップグレードする”

多くのサイトは、バックアップの欠如が原因ではなく、本当に転倒している:

  • 不完全なバックアップ(アップロード/テーマ/プラグインではなくデータベースのみ)
  • バックアップファイルの破損/パーミッションの誤り
  • リカバリーが必要になったとき、“リカバリープロセスがうまくいかない ”ことに気づく。”

したがって、第2段階の目的は以下の通りである:定期的にリカバリー・エクササイズを行う(テスト環境/一時ディレクトリ復旧でも)以下の点を確認してください:

  • データベースは復旧できる。
  • メディアライブラリは復元できます (wp-content/uploads/
  • テーマ/プラグインを復元できる (wp-content/themes/wp-content/plugins/
  • 復旧後、サイトには正常にアクセスでき、バックエンドには正常にログインでき、主要な機能を実行することができます(eコマースでは注文/支払いプロセスをテストし、会員サイトではログイン/特権をテストします)。

多くの商用バックアップ・ソリューションが、「ワンクリック・リカバリー」、「分単位のリカバリー」、「負荷軽減のための増分バックアップ」を強調しているのはこのためだ。例えば ブログボールト プラグインの説明では、**自動的な増分バックアップ(データベース、テーマ、プラグイン、メディアを含む)**とステージング/マイグレーション機能が提供されることが強調されています。マネージWP また、インクリメンタルバックアップ技術による負荷の軽減や、ワンクリックでのリカバリーの提供にも重点を置いている。


フェーズ3:バックアップをアップデート/リリースプロセスに関連付ける(ロールバックポイント)

この段階で、あなたの目標は各大きな変更の前のロールバック・ポイント

典型的なシナリオは以下の通り:

  • ワードプレスコアのメジャーバージョンアップ
  • テーマの変更/テンプレートの一新
  • 主要プラグインのインストールまたは交換(eコマース決済、会員システム、フォームシステム)
  • 一括画像置換/一括コンテンツ移行

ステージ3のポイントは、「変更がOKであることを祈る」必要はなく、変更がうまくいかなかった場合に「変更前の瞬間」に素早くロールバックできることだ。

4.具体的に何をバックアップするか(多くの人がこれらの重要なポイントを見逃している)

必須1:データベース(注文/ユーザー/コンテンツ/設定の保存先)

  • 記事、ページ、コメント
  • ユーザー、パーミッション
  • WooCommerce注文、在庫、クーポン
  • プラグインのコンフィギュレーション(データベースに保存された大量のコンフィギュレーション)

必須2:wp-content(これはWordPressサイトの「見える資産」の大部分です。)

  • uploads写真、添付ファイル、メディアライブラリ(「バックアップを忘れる」最も簡単な場所)
  • themesテーマファイル(カスタムコード/テンプレート)
  • pluginsプラグインファイル(一部のプラグインはカスタムファイルも書き込む)

必要に応じて:構成と動作環境に関する情報

環境の違いを無視してはいけない:

  • PHPのバージョン違いにより、リカバリ後にエラーが報告されることがある
  • 特定の拡張機能/キャッシュ・コンポーネントの違いにより、動作が異なる場合があります。
  • リバースプロキシ/CDN/セキュリティルールがログインとバックエンドインターフェースに影響する可能性があります。

リカバリーは単にファイルを戻すだけでなく、オペレーティング環境とコンフィギュレーションがファイルの実行をサポートできるようにすることでもある。

5.バックアッププログラムの選択

タイプA:プラグインによる時間指定バックアップ(ほとんどのサイトに適した開始ソリューション)

特徴:低コスト、コントロール可能、迅速な展開。ただし、しっかりとした「オフサイト・ストレージ+リカバリー・ドリル」を行う必要がある。

表現ツール:

  • アップドラフトプラス複数のバックアップターゲット(Dropbox、Google Drive、Amazon S3、FTP、Eメールなど)をプラグインページで明示的にサポートしています。
    理想的なサイト:コンテンツサイトやビジネスサイトを立ち上げようとしているサイト、「自分たちで管理するストレージにバックアップしたい」と考えているサイト。
  • WPvividバックアップと移行プラグインのページでは、バックアップ、マイグレーション、ステージング(ステージングは、変更をテストするためにサブディレクトリに作成することができます)をハイライトしています。
    こんな人に最適:頻繁にサイトを移行し、アドホックに変更をテストする必要がよくある人。
  • デュプリケーター: プラグインのページでは、新しいホストや新しいドメインへのサイトのバックアップ/パッケージング/マイグレーション/クローニングを強調しています。
    理想的な用途:サイトの移行、複製、テストサイトの構築、「再配置可能なパッケージ」の作成。

UpdraftPlusは、どちらかというと「バックアップシステムのスターター」です。“

WPvivid/ Duplicatorは “移行/パッケージング/コピー ”に優れているが、バックアップもできる。


タイプB:クラウドバックアップ/ほぼリアルタイムバックアップ(データやリカバリ時間に敏感なサイトに適しています。)

特徴:「変更ごと/高頻度変更保護」と「ワンクリック復旧」に重点を置き、どちらかというと一連のサービスに近い。

表現ツール:

  • Jetpack VaultPress Backup (ジェットパックバックアップ)プラグインのページでは、クラウドバックアップとワンクリックでのリカバリーを強調しています。公式購読ページでは、次のようなことも強調されている。“「すべての変更を保存し、ワンクリックで使用可能な状態に素早く戻す」。
    こんな方に最適:「復旧スピード」に敏感なEコマース/会員制/サイト、または成熟したサービスにバックアップ業務を委託したい方。
  • ブログボールトプラグインの説明には「自動、安全、増分バックアップ(データベース、テーマ、プラグイン、メディア)」とステージングとマイグレーション機能が含まれています。
    理想的な対象:「バックアップ+テスト+移行」が完全なワークフローであるサイト。
  • マネージWPサーバーの負荷を軽減し、ワンクリックでリカバリーが可能なインクリメンタルバックアップ技術に重点を置いています。
    理想的な人:複数のサイトを管理し、バックアップ/更新/監視を一つのパネルで統一的に行いたい人(スタジオ/チーム)。

タイプC:ホスト側スナップショット/自動バックアップ(「第二の保険」として強く推奨)

ホストのバックアップの価値:それは、より広い範囲をカバーする「システムレベルのスナップショット」になる傾向がある(データベースやファイルの状態、さらにはある程度のレベルの環境も含む)。

よくある誤解

  • ホストバックアップ≠移行可能バックアップホスティングのバックアップは、ホストを変更したときや、バックアップを持ち出す必要があるときに不便かもしれません。
  • プラグイン・バックアップはより移行性が高いバックアップはコントロール可能なストレージに保存されるため、環境間のリカバリがより柔軟になる。

したがって、最も安定した組み合わせが一般的だ:

ホスティング・バックアップ(アンダーフード)+プラグイン/クラウド・バックアップ(アプリケーション層の移行可能+きめ細かなリカバリポイント)

6.セキュリティ・ロードマップ(プラグインの束ではなく、最も効果的な基本から始める)

セキュリティとは「プラグインを10個インストールする」ことではなく、レイヤーごとに防御を構築することなのだ:

ステージ1:アカウントと特権(最大かつ最も直接的なメリット)

この段階でやりたいことは、「最も一般的なエントリーポイントを難しくする」ことだ:

  • 管理者アカウントの最小化:必要な人だけが利用できる
  • 強力なパスワード・ポリシー:再利用しない、弱いパスワードを使わない
  • 2FA(2段階認証)これは、「クラッシュ/リーク・パスワード」の時代において、最も効果的な機能強化のひとつである。
    例えば 強固なセキュリティ プラグインページでは、複数の2FA方式(Authy、Google Authenticator、電子メール、代替コードなど)を明示的にサポートしています。
  • ログイン保護: ブルートフォースの試行を制限し、スワイプによるログインを避ける
  • 使用していないアカウントは無効化/削除、使用しなくなったテーマ/プラグインは削除(無効化だけではない)

ステージ2:アップデートとエクスポージャーの管理(旧バージョンにリスクを残さない)

WordPressへの侵入の多くは、「公開されている脆弱性を持つ古いプラグイン/テーマ/コア」から生じている。

したがって、“アップデート ”はセキュリティー戦略の中核のひとつである。
WordPressのドキュメントでは、WordPress 3.7からセキュリティ向上のためにバックグラウンドでの自動アップデートが導入されたことに触れており、自動アップデートはほとんどのサイトでデフォルトで有効になっているとしています。 5.6 新しいサイトの開始が自動的に有効になるメジャーバージョンアップとマイナーバージョンアップなどの戦略。

原則:

  • コア/テーマ/プラグインの明確なアップデート戦略(自動/半自動/手動見直し)
  • メジャーアップデート前のロールバックポイント(セクション3「バックアップステージ3」に戻る)
  • メンテナンスされなくなったプラグインは、できるだけ早く交換すべきである(これが「露出を減らす」最も直接的な方法である)。

第3段階:保護と検知(攻撃を成功させにくくし、異常を早期に検知できるようにする)

この段階でやりたいことは、「より組織的な守備に近い」ことだ:

  • ファイアウォール/WAF(WordPressに到達する前にジャンクトラフィックの一部をブロックする)
  • 悪質コードスキャン、ファイル整合性監視
  • セキュリティログとアラート:異常ログイン、権限の変更、ファイルの変更
  • 監視:ダウンタイムの監視、証明書の有効期限切れ、異常な5xx、異常なトラフィックの急増

表現ツール:

  • ワードフェンスプラグインのページには、ファイアウォール、マルウェアスキャン、ログインセキュリティが明記されており、プレミアムではファイアウォールルールとマルウェアシグネチャのアップデートがリアルタイムで行われるのに対し、無料版では30日間の遅延があることが記載されている。
    推奨:無料版は基本的なセキュリティを大幅に向上させるが、サイトのリスクが高い場合や「最新の脅威インテリジェンス」に依存する場合は、「更新の遅れ」の違いを理解すること。
  • パッチスタック(仮想パッチ/エクスプロイト対策のアイデア)公式サイトでは、仮想パッチによって脆弱なプラグインやテーマからサイトを保護することを強調している。パッチスタック無料版では脆弱性警告、有料版では自動脆弱性保護、その他のアイデアがある。
  • スクリ(クリアランスとセキュリティサービス)そのサービスページでは、マルウェアのクリーンアップと今後の侵入を継続的にスキャン/ブロックする機能を強調しています。

7.リスクアラート

バックアップに関する高頻度の落とし穴

  1. バックアップはサーバーのローカルのみに行われる
    サーバーがおかしくなると、ローカルのバックアップも一緒に消えてしまうことが多い。
  2. wp-contentではなくデータベースのみ
    復元してみると、投稿はあるのに画像が消えていたり、テーマのカスタマイズが消えていたり、プラグインファイルが不整合でエラーになっていたりします。
  3. 決してリカバリーのドリルをしないこと。
    リカバリーに失敗した、バックアップが壊れている、重要なファイルがなくなっている、と気づくのは、肝心なときになってからだ。
  4. バックアップの頻度がビジネスに合っていない
    1日1回バックアップするEコマース/会員制サイトでは、最悪の場合、1日分の注文/ユーザー行動データを失う可能性があり、そのコストはバックアップのコストをはるかに上回る可能性があります。

安全性に関する高周波ピット

  1. セキュリティ・プラグインがインストールされているが、長期間更新されていない
    セキュリティ・プラグインはアップデートの代わりにはならない。古い脆弱性は存在し、リスクはなくならない。
  2. 管理者アカウント/共有アカウントが多すぎる
    パーミッションは制御不能で、ログは追跡しにくく、終了時の引き継ぎは危険だ。
  3. WAF/CDNは安全だ。“
    WAFは多くの一般的な攻撃を阻止できるが、脆弱なパスワードや古い脆弱性、バックドアのプラグインなどを修正することはできない。最も安全なのは「多層防御」である。
  4. 互いに競合する複数のセキュリティ・プラグインを積み重ねると、サイトの速度も低下する。
    セキュリティ・ポリシーは、2FA+ポリシーの更新+ファイアウォール/スキャン+アラートという「より少ないものをより多く」を優先すべきであり、「インストールすればするほど安全」というものではない。

8.バリデーション・チェックリスト

バックアップの確認(この8つをパスしなければ「バックアップがある」とは言わないこと)

  • 自動バックアップが有効かどうか(手動ではない)
  • バックアップにデータベース+wpコンテンツ(アップロード/テーマ/プラグイン)が含まれているかどうか。
  • バックアップのオフサイト保存の有無(クラウドドライブ/オブジェクトストレージ/スタンドアロンサーバー)
  • 明確なリテンション戦略があるか(7/30/90日リテンションなど)
  • 前回のバックアップが成功したかどうか(「スケジュールが存在する」ではない)
  • 最後のリカバリー・エクササイズはいつでしたか?それは成功しましたか?
  • 大型アップデートの前に、追加のロールバックポイントが発生するのですか?
  • 復旧後のクリティカルパスの可用性(ログイン、フォーム、eコマース注文/会員アクセスなど)

セキュリティの検証(まず基本を押さえる)

  • 管理者アカウントは最小化されていますか?終了時のアカウントクリーンアップの仕組みはありますか?
  • 有効または無効 2FA(少なくとも管理者/編集者/店長など、高い権限を持つ役割)
  • 明確なものはあるか?アップデート戦略(コア/テーマ/プラグイン)
  • 使用していないプラグイン/テーマを削除するかどうか(単に無効化するだけではない)
  • ファイアウォール/ログイン保護/不正スキャン(ワードフェンス (等も一部含まれる)
  • 脆弱性警告/仮想パッチのアイディアの利用可能性(パッチスタック など)
  • アラートの可用性(異常ログイン、ファイル変更、ダウンタイム、証明書の有効期限切れ)
  • コンティンジェンシープラン」の有無:ハッキング/改ざんの場合に最初に取るべき措置は何か

一般的な問題

1.ホストのバックアップだけでいいのでしょうか?

通常、1つの情報源だけに頼ることは推奨されない。
ホスティングのバックアップは素晴らしいが、「取り上げて、移行して、細かくロールバックする」ことが必ずしも容易ではない。その方が安定する:基盤となるホスティング・バックアップ + 移行性とリカバリ・ポイントの管理のためのプラグイン/クラウド・バックアップ


2.バックアップの頻度は?

データの変化率」による:

  • コンテンツサイト:通常1日に十分な量
  • 企業サイト:毎日(特にフォームリードがある場合)、リードがサイト上だけでないことを確認する。
  • Eコマース/会員制:注文/ユーザーデータの価値が高いため、より高頻度(1時間ごと、あるいはほぼリアルタイム)が推奨される。

3.バックアップの保存期間は?

内容やコンプライアンスの必要性に応じて、このアイデアを使うことができる:

  • 定期的なロールバックのため、少なくとも7~30日間保管してください。
  • もし「潜在的なバックドア/慢性的な改ざん」を心配するのであれば、以前のクリーンなバージョンに戻ることができるように、サイクルを長く(例えば90日間)保つ方が価値がある。

4.UpdraftPlus/WPvivid/Duplicatorは「同じもの」ですか?

両者ともバックアップするが、強調点は異なる:

  • アップドラフトプラス より典型的なのは、「スケジュールバックアップ+マルチターゲットストレージ+リカバリー」だ。“
  • WPvivid バックアップ+マイグレーション+ステージングを重視 テスト機能
  • デュプリケーター パック/マイグレーション/クローンサイト」に強い“

タイプ」で選択すれば、名前に惑わされることはない。


5.なぜJetpack Backupにお金を払う必要があるのですか?何のためですか?

本質的には「クラウド・バックアップ・サービス」であり、クラウド保存とワンクリック復元に重点を置いているため、プラグインのページには以下の内容を明示する必要がある。 バックアップの支払いプラン公式サブスクリプションページでは、すべての変更を保存し、ワンクリックで素早くリカバリーできることを強調している。
理想的な人:回復速度に敏感で、バックアップのO&Mを成熟したサービスに任せたい人。


6.BlogVault/ManageWPのような「増分バックアップ」のポイントは?

インクリメンタルバックアップがその中核である:変更点のみをバックアップするこれにより、サーバーの負荷が軽減されるとともに、リカバリーポイントを高い頻度で生成できるようになる。

  • BlogVaultプラグインこの説明では、自動的な増分バックアップとデータベース/テーマ/プラグイン/メディアの上書きが強調されており、ステージングとマイグレーションが組み込まれている;
  • マネージWP インクリメンタルバックアップ技術も、負荷を軽減し、ワンクリックでリカバリーを提供するために重視されている。

大規模なサイト、多くのメディア、頻繁な更新、複数のサイトを管理する場合に最適です。


7.セキュリティ・プラグインは1つで十分ですか?

たいていのサイトでは、「主要なセキュリティ・プラグインを1つ用意し、基本ポリシーを正しく設定する」ほうが、「たくさんのプラグインを用意する」よりも効果的なことが多い。
例えば ワードフェンス ファイアウォール、スキャン、ログイン・セキュリティなどの基本的な機能をカバーすることができる。 2FA(ソリッドセキュリティはこのための様々な方法を提供しています)、すでに攻撃のコストを大幅に引き上げることができます。


8.Wordfenceの無料版は使えますか?なぜプレミアムにしようと言う人がいるのですか?

Wordfenceプラグインのページクラリティ:プレミアムでは、ファイアウォールルールと悪意のあるシグネチャの更新がリアルタイムで行われますが、無料版では30日間遅れます。
プレミアムが必要かどうかは、あなたのリスクと許容度による:

  • 低リスクのサイト:無料版+タイムリーなアップデート+2FA、通常はすでに役立っている!
  • 最新の脅威インテリジェンス」への高いリスクと大きな依存:「アップデートの遅れ」が生み出す機会の窓を理解する必要性

9.Patchstackのような「仮想パッチ」は具体的に何を解決するのですか?

このアイデアは、プラグインやテーマの脆弱性が悪用される前に(あるいはパッチが完全に普及する前に)、アプリケーション層で既知の脆弱性の攻撃面をブロックするためにルールを使用するというものだ。パッチスタック公式サイト仮想パッチによる脆弱なプラグイン/テーマの保護に重点を置き、無料/有料によるアラートと自動保護の違いを解説。
これはアップデートに取って代わるものではなく、むしろ「パッチ・ウィンドウ」のリスクを最小限に抑えるための方法である。


10.2FAを有効にすると、ロックアウトされますか?

事前に準備しておくことをお勧めする:

  • 代替コード/リカバリー・メソッド(強固なセキュリティ (backupコードなどのプログラムも挙げられた)
  • 少なくとも1人の「緊急管理者」を維持し、復旧情報を確保する。
  • 重要なのは、情報漏えいが可能な場所に復旧情報を置かないことだ。

11.WordPressの自動アップデートはオンにすべきかどうか?

WordPressドキュメント自動バックグラウンド更新の仕組みは、セキュリティの向上を目的としており、ほとんどのサイトでデフォルトで有効になっていること、さまざまなタイプの更新ポリシーを設定できることを説明する。
推薦する:

  • セキュリティとマイナーバージョンの更新:自動化される傾向がある(既知の脆弱性を公開する時間を短縮できる)
  • メジャーリリース/クリティカルなプラグインのアップデート:前進する前に、バックアップ・ロールバック・ポイントとテスト・プロセスを組み合わせる(少なくともロールバックできるように)。

12.ウェブサイトがハッキングされた疑いがある場合、まずどうすればよいですか?

正しい順序(大きな混乱を避けるため):

  1. まず出血を止める。バックグラウンドでのログインを一時的に制限し、疑わしい機能を停止し、必要に応じてメンテナンスページを開きます。
  2. 証拠保全とリカバリー・ポイント・ファースト(分析用に)現在の状態のバックアップを直ちに作成し、同時にクリーンなロールバックポイントを準備する。
  3. ロールバック/クリーンアップ: 清潔であることが分かっている時点に優先的に復旧させるか、プロのクリーニング・サービスを利用する(スクリ 悪意のあるクリーンアップと継続的な保護に重点を置く)
  4. 穴を補うコア/プラグイン/テーマのアップデート、パスワードとキーのリセット、2FAの有効化、疑わしいアカウントとプラグインの削除。

13.セキュリティもバックアップもやっているのに、なぜモニターが必要なのか?

早期発見」が損失を最小限に抑えるからだ。
ダウンタイム、期限切れの証明書、異常なトラフィック、異常なログイン、異常な注文、これらはすべて「早ければ早いほど良い」問題である。