2026年10月、明らかにサイバー攻撃のニュースが増えている。 一定の対策を行っているはずの規模の企業ですら毎日のように情報流出が報じられている。 攻撃内容の詳細は聞こえていないが、よくある特定のフレームワークやライブラリの脆弱性が集中して狙われているという話ではないようだ。 おそらくだけど攻撃者側がもつ制限を解除した高性能AIにより攻撃コストが下がり、Bot/AIエージェントで攻撃が自動化され、絨毯爆撃的に攻撃が行われているのだと想像する。
今ニュースになっている企業は氷山の一角のはず。 ニュースで報じられている企業はある程度備えが出来ていた企業といえる。 なぜなら攻撃に気づける能力と事後対応（被害規模を把握し外部に案内できる）の能力を備えていたということ。 一方、備えができていない企業は侵入されたり、情報が窃取されていることにすら気づけていないし、警察などから連絡がいってもてんやわんやで調査すらおぼつかない状況になっているのかもしれない。
このような状況では以前は割に合わず優先度が低かった個人環境も無差別に絨毯爆撃されていると考えている。 そうなると自分のこのブログサイトや自宅内のPCやIoT機器、メールやストレージやその他のクラウドサービスもいつ侵害されてもおかしくはない状況。 攻撃者からすれば情報の窃取という点では価値は低いが、攻撃の中継地点やBot Netとして利用したり、クラウドのテナント上でマイニングを行ったり、成り済ましたアカウントでフィッシングなどに利用できる。 私の名前や属性情報をうまく使って他者にフィッシングする可能性もある。 自分が攻撃者として疑われる状況や莫大なクラウドの請求費用を求められる状況になるかもしれない。
もう一つ気にしているのは技術ブログとして自分のこのブログサイトのシステム構成やその他メール環境（Google WorkspaceやMicrosoft 365）などをインターネットに公開していること。 攻撃側の人間が意識して私の環境を狙うということは行動のコストの観点で気にする必要はなかった。 AIがあらゆる情報を収集して攻撃を編み上げていくと考えるとブログの中で弱点や攻撃のとっかかりを私は沢山残している。 Alibaba Cloud 上にシステムがあり、DNSもAlibaba Cloudにあり、Wordpressを使っており、ApacheとUbuntuも使っている。 情報はGoogle WorkspaceやMicrosoft 365 にあることも暗に公開している。 攻撃の糸口、ヒントはかなり与えられている状況。
ということで急ぎサーバの強靭化を進めることにする。
なお、Wordpress サーバの強靭化といっていますが、Wordpress そのものではなく実行環境（Linuxサーバやそれを提供するクラウド）の強靭化が中心の話です。 自分への作業メモも兼ねてブログに書いています。 記事を公開したのは11月14日ですが作業は一か月前くらいの週末に実施しています。
目次
強靭化の方針
強靭化の方針は以下。 仕事であればリスク評価から始めますが、個人の環境なのでスピードを優先し、時間とコスト面で現実性があり効果的な対策を以下の方針で進めることにします。ここでいうスピードとは一回の週末（土日の二日間で対策を終える感じ。
| # | 方針 | 実現方式 |
|---|---|---|
| 1 | ソフトウェアについてEOS/EOLや脆弱性の有無と影響度を簡単に確認できる状態にする | Alibaba Cloud Security Center で脆弱性管理（使っているソフトウェアとその脆弱性、EOS/EOLが一目瞭然の状態） |
| 2 | 可能な範囲で攻撃を防ぐ（個人の環境を超えてのコストは考えていない） | Alibaba Cloud Security Center でOSレイヤで防御（EPP/EDRで防御だけではなく、侵入を気づける状態) |
| 3 | 防御は出来る限り複数のレイヤーで行う | Alibaba Cloud CDN でネットワークレイヤで防御（サーバを直接インターネットにさらさず多層防御する状態） |
| 4 | 攻撃やその兆候、侵入を気づける状態にする | EPP/EDRのログをSEIM（Alibaba Cloud Simple Log Service とMicorosoft SEIM)で監視と通知 |
| 5 | 情報を盗まれた場合の被害を最小化するためできる限り暗号化する | OS上のデータやMySQL（Alibaba Cloud RDS)のデータの暗号化 |
| 6 | バックアップからシステムをリストアできる状態とし、また、バックアップは破壊されないようにする | Alibaba Cloud のスナップショットバックアップとランサムウェア対策 |
| 7 | OSやWordpress、クラウドのテナントなどすべてのアカウントの認証と権限を見直しする・強化する | クラウドなどインターネット経由の認証はハードウェアキーを原則化し、他のアカウントはこのタイミングで不要アカウントと権限をすべて棚卸 |
| 8 | できる限り手動での作業など人間（私）の時間と都合に左右されないように仕組みで対応する | 1-7をシステム化・仕組化し、脆弱性や不正アクセス検知を自分に通報できる状態 |
方針と対策は見ての通り何か特殊なことはなく、基本的なセキュリティ対策です。 一番やりたいことは8番目の私の都合で発見が遅れたり、対策が遅れたりすることがない環境を仕組みで実現することです。 仕事が忙しくてパッチ適用できていなかった、ちゃんと見ていれば見つけられた攻撃を見逃してしまう、という事態を避けられるようにしたいと考えています。
実現イメージ
実現化の方針を Gemini に絵にしてもらいました。 言葉よりも図の方がわかりやすいですよね。
Alibaba Cloud Security Center で脆弱性管理（使っているソフトウェアとその脆弱性、EOS/EOLが一目瞭然の状態）
Ubuntu や Apache や PHP 、Wordpress それらが利用しているライブラリのSBOM、EOS/EOLと脆弱性の管理を人間による手動実行から Alibaba Cloud Security Center でできる限り自動化します。 Security Center が定期的にサーバをスキャンし、稼働しているソフトウェアに脆弱性がないか、EOS/EOLを迎えていないか私に自動的に教えてくれる状態を作ります。
なお、Alibaba Cloud Security Center は複数のEditionがあります。 また、各機能をバラバラにオプションとして追加していくことも可能だったりします。 今回は脆弱性管理のために Advanced Edition を導入することにしました。 Enterprise Edition にしても EDR は別オプションになるのと Enterprise で利用できる機能はデータベースを外だしにしている私の環境では使いどころがなかったということもあり。
| エディション / 課金方式 | 概要と主な機能 | 個人環境での適正 |
|---|---|---|
| Free Edition（無料） | 基本的なDDoS検知、ブルートフォース攻撃検知、ごく基本的な脆弱性アラート。 | 必須で有効化。無料枠として常に動作。 |
| Anti-virus Edition | ウイルス・マルウェアの検出および自動検疫・削除。 | マルウェア駆除まで自動で任せたい場合。 |
| Advanced Edition | ウイルス駆除＋Linux/Wordpressのシステム脆弱性検出・自動修復。 | 個人ブログに一番おすすめ（コスパ良）。 |
| Enterprise / Ultimate Edition | 改ざん防止（Web Tamper Proofing）、ランサムウェア対策、コンテナ保護、詳細な監査等。 | 個人ブログにはややオーバースペック。 |
| Pay-as-you-go（従量課金） | 月額固定を払わず、「脆弱性修正機能」や「ログ保存」などを必要な機能だけ従量で追加。 | コストを限界まで下げたい場合の選択肢。 |
脆弱性についてUbuntuやApache、PHP、Wordpressを対象に、そしてCSPMとしてAlibaba Cloud の設定不備が一元的に管理・可視化されます。 ダッシュボードから簡単に詳細を確認することも可能ですし、メールやその他手段で私に通知を構成します。
以下がトップ画面ですが、この Security Score が 100 点を維持すればまずまず安心です。 まずまずといったのはゼロデイもあるし、人間なのでミスもあるので完全に防ぐことはあきらめています。
Alibaba Cloud Security Center を購入し有効化する手順の話は↓↓↓
Alibaba Cloud Security Center でOSレイヤで防御（EPP/EDRで防御だけではなく、侵入を気づける状態)
可能な範囲で攻撃を防ぐためのツールとしてこちらも Alibaba Cloud Security Center の Advanced Edition と Agentic EDR を利用します。 いわゆる EPP と EDR の機能が提供されます。
ツールとして Alibaba Cloud Security Center を利用するか、Microsoft Defender for Server を利用するか迷ったのですが、Alibaba Cloud 上にある仮想マシンとの親和性と私が慣れ親しんでいるツールということで Alibaba Cloud Security Center の有償プランとなる Advanced Edition と Agentic EDR を導入しました。 Defender でもほぼ同じことできるのと、自宅PCは Defeder for Endpoint Plan2 とSentinelを構成するので Defender で一本化するメリットもあり、将来そうする可能性もあります。
参考情報として Alibaba Cloud Security Center / Agentic EDR と Microsoft Defender の比較です。
| 比較項目 | Alibaba Cloud Security Center (Advanced / Agentic EDR) | Microsoft Defender (Defender for Cloud / Endpoint) |
|---|---|---|
| 主な対象領域 | マルチクラウド・ハイブリッド環境 （Alibaba Cloudメイン、AWS/Azure等も管理可） | マルチクラウド・ハイブリッド環境 （Azure/M365メイン、AWS/GCP等も管理可） |
| 強み・得意分野 | ・中国/アジア圏の基盤に強い ・Qwen（大規模言語モデル）を活用した自律型調査・復旧 ・Web-CMS（WordPress等）の脆弱性検知に強み | ・M365 / Active Directory との強力な連携 ・グローバルな脅威インテリジェンス（Security Copilot） ・エンタープライズ規模の統合セキュリティ |
| EDR / 挙動検知 | Agentic EDR (Agentic SOC) AI Agentがプロセスや通信をリアルタイム追跡し、自動隔離・復旧 | Defender for Endpoint (P1/P2) 行動分析、メモリ保護、自動調査・インシデント応答（AIR） |
| AIアシスタント機能 | 自社LLM Qwen（通義千問） 統合 アラートの自動解析や対処手順の即時提示 | Microsoft Copilot for Security 統合 自然言語での脅威調査、要約、スクリプト分析 |
| WordPress / CMS保護 | 非常に強い Web-CMSのプラグイン脆弱性検知、Webshell検出、ワンクリックパッチ適用 | 一般的 OS/ミドルウェア層の脆弱性検知は可能だが、CMS固有の防御はWAF/プラグイン依存 |
| コスト構造 | インスタンス単位のライセンス（Advanced/Enterprise） ＋機能アドオン（Pay-as-you-go対応） | サーバー（ノード）単位の月額サブスクリプション （Plan 1 / Plan 2） |
| 個人〜中小規模での適性 | Advanced版なら月額数千円〜で導入しやすく、クラウドコンソールから直感的に操作可能 | Defender for Cloudは手軽だが、Defender for Endpointのフル機能は企業向け構成になりがち |
Alibaba Cloud Security Center を購入し有効化する手順の話は↓↓↓
Alibaba Cloud CDN でネットワークレイヤで防御（サーバを直接インターネットにさらさず多層防御する状態）
AIによる攻撃自動化・無差別攻撃の脅威に対して、ネットワーク層とインスタンス層で多層防御を行います。
以前は Alibaba Cloud の Load Balancer を利用しそこで TLS 通信を終端＝ECSの仮想マシンは直接インターネットにさらさない構成でした。 その構成は1年前くらいにやめて今は仮想マシンが直接インターネットにさらされています。 理由はコスト削減でした。 今回、セキュリティ強化を目的に CDN/WAAP を利用し、ECSの仮想マシンは CDN/WAAP 経由でのみアクセスできるように通信も制限します。 特にBotからの攻撃をできる限りCDN/WAAPで遮断したいと考えました。
この時、どこのCDN/WAAPを使うかは少し考えました。 Alibaba Cloud CDN を使うかどうかです。 結論として 「Cloudflare」と「Alibaba Cloud CDN 」を比較すると、セキュリティ機能の無償枠の充実度で Cloudflare が圧倒的です。
そして、当初は Cloudflare のFreeプランで進めようと思ったのですが、DNSドメインを権威サーバを Cloudflare に変更する必要があることがわかりました。 Cloudflare の有償プランであればDNSドメインは今のAlibaba Cloud DNS のままで進められるのですがCloudflareの有償プランは結構な費用(200USD～）が発生します。
今回はいったんAlibaba Cloud CDN で進めることにしました。
| 機能項目 | Cloudflare（Freeプラン） | Alibaba Cloud CDN |
|---|---|---|
| DDoS防御（L3/L4/L7） | 無制限（Unmetered） で自動防御 | 無料機能枠内での基礎防御のみ |
| カスタムWAFルール | 5ルールまで無料作成可能（特定の国拒否、URI制限など） | Free枠では利用不可（Proプラン：$15/月〜が必要） |
| ボット対策 | 基本的なボットチャレンジ（JS / Turnstile） | 基本的なボットトラフィック管理 |
| マネージドルール（OWASP等） | 自動適用（悪質IPや既知攻撃の遮断） | Free枠非対応（Pro以上） |
| WordPress専用保護 | 管理画面（/wp-admin/）への制限などをWAFルールで容易に実現 | 別途WAF契約または上位プランが必要 |
ただ、Alibaba Cloud CDN で設定を始めていくと Alibaba Cloud にも WAAP が Edge Security Accelerator （ESA)として提供されされていることがわかります。 カタログスペックとしては Cloudflare と同等な感じですし、Cloudflare でいうworkers相当のサービスもあります。
最終的には以下の構成となりました。 www.bigriver.jp宛の通信をまずは全世界にある ESA のEdgeが受け付けます。 そこで悪意ある通信は遮断しつつ、キャッシュもしつつ、最終的にOriginとなる Alibaba Cloud ECS 上の Ubuntu / Apache / WordPress が処理をさばきます。 Origin側では ESA からの接続しか受け付けないように制限も行います。 これで直接サーバをインターネットにさらさない状態にできました。
ESAの導入に関する話は以下。
バックアップからシステムをリストアできる状態とし、また、バックアップは破壊されないようにする
バックアップについては Alibaba Cloud ECS のスナップショットを利用しています。 Alibaba Cloud 側でもつバックアップなので、仮に ECS 上の Ubuntu に侵入されてもスナップショットに攻撃者は直接アクセスすることは出来ないため基本的には破壊される可能性は低いです。 もし、バックアップが破壊されるとしたら Alibaba Cloud のテナントのアカウントが乗っ取られたときとなります。
あと WordPress のデータの実体がはいる MySQL は Alibaba Cloud RDS を利用しており、バックアップも RDS 側で取得しています。 こちらも Alibaba Cloud 側で管理するバックアップなのでUbuntuに侵入され、MySQLに SQL をなげてすべてのテーブルやデータを削除されてもリストアは可能です。
バックアップについてはさらに Alibaba Cloud File Backup の機能も利用し、ファイル単位のバックアップとリストアを行える状態にしています。
なお、バックアップはこれだけでは実は不十分です。 Alibaba Cloud に限らずほぼすべての Public Cloud はバックアップの機能やバックアップ先のストレージを提供はしていますが、そのデータは保証しません。 何らかの問題が発生し、バックアップデータがロストすることはありえるし、その際の責任はサービス提供側は負わずに利用者側が負うという考え方です。
これは全く珍しくもなく当たり前なものです。 我々利用者がやるべきことはクラウドのバックアップ機能に不具合があったり、保存したバックアップデータが消失する事態も想定しバックアップのバックアップを行う必要があるということです。 もちろん、あとは確率論的な話ではあるのでバックアップのバックアップを毎日、毎時間取得しましょうということはなく、重要性に応じて手元にダウンロードしたり、他のクラウドサービスのオブジェクトストレージにコピーしておく、などをお香のが現実的です。 オンプレミスでいうと、サーバ室内での1次バックアップ、月1回のオフラインバックアップ取得と金庫保管での2次バックアップのこの2次バックアップにあたる部分です。
認証の強化
認証の強化ですが、1つは物理の Security Key の導入を進めました。 Alibaba Cloud 以外にもAzureやAWS、Google Cloud、Microsoft 365、Google Workspace など万が一乗っ取られてマイニングされたり、他者の攻撃に使われてしまないように原則物理のSecurity Key だけの認証にしました。
しかし、この Alibaba Cloud だけはどうやっても Security Key の設定が成功せずでした。 その話はこちら。
あとは Alibaba Cloud ECS 上の Ubuntu サーバの SSH ログインも物理の Security Key に限定しました。IPアドレスのアクセス制限も行っていますが、万が一自宅NWに侵入されてPCを乗っ取られても即座にはログインできない状態にしました。
あと、Wordpress の管理者ログインも物理のSecurity Key を必須化しました。 以前は ID /Password とアクセス元IP制限でしたがこちらもなりすましはかなり難しくなったと思います。
まとめ
紹介を省ているものもありますがほぼ予定した強靭化をおえることが出来ました。
Alibaba Cloud のテナントはCSPMで設定不備リスクを減らし、ECSのUbuntuはAgentベースの脆弱性スキャナーとEDRで防御力を高め、インターネットへのWordpress公開をWAAP経由に限定しました。 合わせて認証を物理の Security Key 限定になるように強化し、バックアップもこのタイミングで確実に実行できる状態に確認しています。
あとはまだチューニング中ですがログ監視と自動通知や自動のActionです。 ここはまたこなれてきたら紹介していきます。
まあ、本当は個人のブログサイトでここまでやる必要はありません。 毎月のランニングコストも結構かかっています。 安くしようと思えばWordpressやめてオブジェクトストレージに静的コンテンツでおいてしまえば安全でかつ安いです。
どうしてやるのか、それは自分の知識向上のためにやっている感じです。 インターネットにサーバを公開するという緊張感によって自分事として情報収集したり対処を行います。 それが自分の知識や経験につながっていくと。
今は生成AIに聞けばなんでも答えてくれるし自分もよく使っていてすごく助かっているのですが、AIが言うことが正しいかどうかを見極める責任は自分にあるし、AIが言ったとおり設定して運用したら侵入されて情報盗まれたり、友人・知人にフィッシング攻撃をしかけたり、マイニングされて莫大な費用請求が発生してもAIの責任にはならず自分で負うしかありません。 自分が主体で、責任をもつためには結局は自分がある程度わかっていないといけないということなんだと考えています。
以上
