そのCMS、たまたま被害が出ていないだけでは? 改ざん・乗っ取りから企業サイトを守る、今どきのCMSセキュリティ対策

Webサイトの改ざん・乗っ取りを防ぐために。取材協力:株式会社ディーゼロ

Webサイトの運用や更新に欠かせないCMSですが、その利便性は「安全に使えること」が前提です。コンテンツをインターネット上に公開する以上、常にセキュリティリスクと隣り合わせにあります。対策を怠れば、Webサイトは「改ざん」や「不正ログイン」などの被害にさらされる可能性もあるでしょう。

第3回では、CMS導入時に押さえておきたい「セキュリティ対策」にフォーカスします。セキュリティを意識したとき、CMSの選び方はどう変わるのか。万が一インシデントが発生した場合、どのように対応すべきなのか。現場の制作者だけでなく、企業のWeb担当者など非エンジニア層も理解しておきたい実務的なポイントを整理します。

今回は、九州を代表するWeb制作会社として知られる福岡市の株式会社ディーゼロに取材。長年CMS導入支援に携わってきた熊澤正さんに、現場で求められるセキュリティ対策の考え方をうかがいました。

目次

CMSのセキュリティ対策を怠るとどうなる?  改ざん被害のリアル

──まず率直にうかがいます。自社サイトのCMSにセキュリティ対策をしていなかった場合、どんなことが起きるのでしょうか?

熊澤正(以下、熊澤 私たちへのご相談で一番多いのは、自社サイトの「改ざん」です。毎年、必ず数件は相談がありますね。「気づいたらサイトがおかしくなっている」「どう対応していいかわからない」といったご連絡です。

株式会社ディーゼロ テクニカルデザイン部 熊澤正さんの近影
株式会社ディーゼロでテクニカルデザイン部に所属する熊澤正さん

──その場合、どのように対応するのですか?

熊澤  まずはすぐに調査します。すると、例えばこんなケースがあります。

外部パートナーがインストール型のWordPressでサイトを制作したものの、保守契約までは結んでおらず、CMSのアップデートが行われないまま放置されていた。その結果、サイトが改ざんされていたケースです。

あるいは、他社からの指摘で初めて自社サイトの改ざんに気づいたケースもあります。そのときは、CMSのバージョン管理や自動更新が有効になっておらず、長期間アップデートされていない状態でした。

──サイトをつくりっぱなしで日常的に更新していないと、社内でもサイトを見る機会が少なく、自社では異変に気づきにくい、と。

熊澤  はい。こうしたケースは、日頃の対策が十分でない場合、実際によく起こりえます。

ほかにも、リニューアル案件のご相談でサイトの状態を調査したところ、セキュリティ対策がほとんど行われていなかったというケースもありました。担当者としては「特に問題なく運用できている」と認識されているものの、実際には必要な対策がなされていない状態だった、ということもあります。

もし社内でリニューアルの話が出ていなければ、その状態のまま運用され続けていた可能性も高いでしょう。つまり「たまたま被害が出ていなかっただけ」という状態です。

──つまり、相談している企業側は「問題がある」と認識しているわけではない。

熊澤  そうなんです。だから「保守が必要です」と説明しても、なかなか理解してもらえないこともあります。

実際にセキュリティ対策を万全にしようとすると、サーバの状態確認やOSのアップデート、PHPのバージョン更新など、さまざまな対応が必要になります。古いコードが動かなくなる部分があれば修正も必要ですし、そのうえでCMS自体のバージョンアップも行う。結果として、かなりのコストがかかってしまうことも少なくありません。

──日頃から対策していないと、かなり厳しい現実が待っているわけですね。

熊澤  すでに何かしらの被害が出ている場合は、保守だけでは済まないこともあります。バックアップがあっても、データ自体が汚染されていれば使えません。「ゼロからつくり直しましょう」となると、調査から復旧までに多額のコストがかかる可能性があります。

──一方で「改ざん」の深刻さについて、あまり実感されていないケースも多そうです。

熊澤  “サイトの見た目が少し変になった”程度の問題だと侮ってはいけません。改ざんは、自社サイトにとって非常に深刻な被害につながる可能性があります。

例えば、サイトを訪れたユーザーにマルウェアを感染させる仕組みを仕込まれたり、フィッシング詐欺の拠点として悪用されたりすることがあります。さらに、検索エンジンから危険なサイトと判断されれば、検索結果から除外されてしまうこともあります。

そうなれば、自社の取引先やお客様をはじめ、社会に対する信頼を一瞬で失いかねません。

CMS導入は「入れて終わり」ではない。制作会社が伝えるべき運用とリスク

──セキュリティの問題は、最初にCMSの導入を支援した制作会社側(開発側)にも責任がある、という言い方もできるかもしれません。その点はいかがでしょうか?

熊澤  CMSの導入とは「Webサイトにシステム(Content Management “System”)を入れる」ということです。何もないところに別の仕組みを組み込むわけですから、それ相応のリスクも生じます。そのことを相手に説明しないまま導入する制作者がいるとしたら、とても残念ですね。

制作側は、導入と同時に運用コストが発生することを必ず伝えるべきだと思います。相手は専門家ではありませんから、知らなくて当然。弊社の場合は、初期の見積もり段階で必ずランニングコスト(運用費)も明示しています。

あと「一度CMSを導入すれば、そのままずっと使える」と思っている方も多いです。実際には、導入後もCMSの定期的なバージョンアップが必要ですし、旧バージョンのままだとサポート対象外になることもあります。そうした説明も欠かせません。

──CMSは、決してメンテナンス不要のシステムではない、ということですね。

熊澤  予算が限られていて、どうしてもセキュリティコストが気になるなら、「CMSを導入しない」という選択もあり得ます。定期的にコンテンツを更新する予定がないのであれば、CMSを導入せず、HTMLファイルをアップロードする従来型の運用も選択肢になります。この場合、CMSの実装費用やシステム保守などの運用コストを抑えることができます。

それにセキュリティに関しては「脆弱性診断を一度受けたから安心」とするケースもありますが、新しい脆弱性があとから見つかることもあります。診断結果は「その時点で脆弱性が見つからなかった」という意味に過ぎず、完全な安全を保証するものではありません。

──費用面を考えると、診断の頻度や範囲も悩みどころですね。

熊澤  そこは予算とのバランスになります。特にサイト規模が大きい場合は、リスク回避のためにも定期的な診断を検討する必要があります。

CMS導入の初期費用と運用費用の2種類を示した図。初期費用の内訳:Web制作、CMS導入&初期設定、コンテンツ移行(乗り換えの場合)etc. 運用費用の内訳:保守(アップデート対応など)、インフラ(サーバOSやPHPのバージョン管理など)、セキュリティ(脆弱性診断、WAF運用、ログ監視など)、バックアップ(データ取得、復旧テストなど)、緊急対応(インシデントへの事態収拾)etc.
CMSの導入に必要なのは、導入のための費用を払うこと“だけ”ではありません

CMSのセキュリティは“攻撃の種類”より「リスク評価」から考える

──ここから、もう少し具体的にうかがいます。CMSに関連したリスクとしては、「アカウントの乗っ取り」、Webサイトの「改ざん」、あるいは「踏み台化」(自社サイトが乗っ取られ、他社へのサイバー攻撃の発信源にされること)、さらに脆弱性攻撃などが挙げられます。それぞれには、どのように対処すべきでしょうか。

熊澤  おっしゃる通り、そうしたリスクがあります。ただ、CMSを導入している企業のWeb担当者の方で、セキュリティに詳しくない場合には、個々の攻撃手法を知ることよりも先に「自社サイトを公開することのリスク」を評価してほしいと思います。

──CMS導入前に考えるべきことがある、ということでしょうか。

熊澤  はい。自社サイトを公開する以上、必ず何らかのリスクが伴います。そこでまず、「何を載せて、何を載せないのか」を判断する必要があります。

例えば、掲載している内容が消えてしまったらどんな被害が出るのか。改ざんされた場合はどうなるのか。社内向けや会員向けのクローズドなサイトであれば、情報が抜き取られた場合にどんな損害が考えられるのか。こうした観点で、自社のリスクを整理することが大切です。

──リスク評価があってこそ、本当に必要なセキュリティ対策が見えてくるわけですね。

熊澤  その通りです。リスクの大きさがわかれば、どこまで対策すべきか、費用の目安も見えてきます。

仮に情報が流出したとしても「流出しても問題がない」と言い切れる内容であれば、「極端な話、放置でも構わない」という判断になります。もちろん、実際には何かしら対策はしたほうがいいですが。

個々の攻撃は、あくまで対策しなかった結果として起きる現象です。企業の担当者の立場で言えば、改ざんや脆弱性攻撃の具体的な仕組みを深く理解するよりも、その前段階として「どう備えるか」という考え方を押さえるほうが実務的です。

──お話を聞いていると、セキュリティはCMS単体で考えるものではなさそうですね。

熊澤  はい。Webサイト全体を守るという視点で考えるべきです。そのうえで、リスクの深刻度や重要度に応じて、どこまで予算をかけるのかを判断していくことになります。

──現実的には、信頼できる外部パートナーと協力しながら進めることが重要ですね。

「CMSのリスクに対応するには?」というタイトルのフローチャート。ステップ1:サイト公開前にリスク評価 NG:個々の攻撃手法を調べる。推奨:「何を、どこまで守るか?」。ステップ2:リスクへの対策案を整理 NG:「とりあえずWAF?」場当たりの対応。推奨:「解決最優先」or「許容範囲の損害」の判断。ステップ3:要件に適ったCMSを選定 NG:不要な多機能化で予算がふくらむ。推奨:上記を踏まえたCMSで最終調整へ。
個々の攻撃の中身を知ることは大事ですが、その前に、サイト公開で「何を、どこまで守るか」というリスク評価を優先して取り組みましょう

CMSは自社管理かSaaSか? セキュリティと体制で考える選び方

──CMSのタイプについてもうかがいます。オンプレミスで自社管理する方法、SaaSとしてサービス事業者に任せる方法、あるいはAWSなどのクラウドを使ったPaaS・IaaSなどがあります。セキュリティの観点からは、どのように選ぶべきでしょうか。

熊澤  目的や置かれている状況によって判断は変わるので、「これが正解」という決め方はありません。例えば、Webサイトをどれくらいの期間運用する予定なのか。そうした前提によっても選択は変わってきます。

実務上、最初にお話しすることが多いのは、「サービスの仕様に沿った形で実現できるサイトであれば、SaaSはかなり現実的な選択肢」ということですね。

──「自社ですべて管理」となると、コスト面も気になります。

熊澤  オンプレミスの場合、コストだけでなくリスク管理も基本的に自社の責任になります。社内に知見のある人材がおらず、管理体制を組めない場合は、オンプレミス運用はかなり難しいでしょう。

もちろん、既存サービスの枠に収まらない独自機能を実装したい場合は、SaaS以外の選択肢になります。ただし、フルスクラッチで構築する場合は、開発費用も高くなりますし、どこに依頼できるかという問題も出てきます。

──初期費用や保守を考えると、SaaSは現実的な選択肢ですよね。企業担当者が選びやすいSaaSについて、もう少し詳しく教えてください。

熊澤  月額費用はもちろんですが、メンテナンスの周期や仕様変更の頻度も確認しておくべきです。

また、よくあるのは「最初はSaaSで十分だったが、ビジネスの拡大とともに機能が足りなくなった」というケースです。さらに、サービス終了の可能性も考えて、データをエクスポートできるか、つまり将来的に移行できるかも確認しておくと安心です。

──社内にセキュリティやインフラの知識を持つ人がいない場合は、SaaSが無難ということですね。

熊澤  そうですね。「まずはWebサイトを用意したい」「限られた予算で運用したい」といったケースでは、SaaSは非常に現実的です。

逆にSaaS以外を選ぶ目安としては、信頼できる外部パートナーがいて、ある程度の予算も確保できる場合でしょう。その場合は、パートナーと保守契約を結びながらオンプレミスで構築する、という選択肢も十分に考えられます。

CMSのセキュリティ事故にどう備える? インシデント対応の基本

──では実際に、アカウントの乗っ取りやWebサイトの改ざん、踏み台化といったインシデントが起きた場合について教えてください。

熊澤  まず大切なのは、「インシデントが起きたこと」に気づける仕組みを用意しておくことです。

──具体的には、どのような対策でしょうか。

熊澤  例えば、Webサイトの改ざんなどを未然に防ぐためには、サーバや操作用端末の異変を監視・検知する仕組みを導入しておくことが重要です。具体的には、パソコンやサーバ内の挙動を監視するEDR(Endpoint Detection and Response)や、サイトの稼働状況を確認する「死活監視」、不審なアクセスを監視する「ログ監視」などが挙げられます。

さらに、Webサイト全体の防御としてはWAF(Web Application Firewall)の導入も重要です。WAFは、WebサイトやWebアプリケーションに対するさまざまなサイバー攻撃を遮断する仕組みです。ただし、WAFでは攻撃が発生した際の通知の頻度にも注意が必要です。通知が多すぎると対応が追いつかなくなるため、適切な通知設定の調整も必要になります。

──「気づく仕組み」を用意することが重要なのですね。他にもありますか?

熊澤  もうひとつは復旧の準備です。改ざんされた場合でも正常な状態に戻せるよう、バックアップを取得しておくことは基本です。そのうえで、ぜひ用意しておいてほしいのが「対応フロー」です。

──対応フロー、ですか。

熊澤  「インシデントが発生したとき、最初に誰へ相談するのか」を決めておくことです。社内の担当者なのか、外部パートナーなのか。最初の連絡先と、その次の連絡先も決めておくと安心です。

また、個人情報の流出があった場合には、個人情報保護委員会への報告義務が発生する可能性がありますし、攻撃状況についてIPA(情報処理推進機構)へ届け出るケースもあります。そうした対応を誰が担当するのかまで含めて、あらかじめ整理しておくことが大切です。

「インシデント対応フロー」の7段階。①準備 インシデントに備えた仕組みづくり ②検知 インシデント発生・改ざん発覚 ③社内通報 サイト担当者→上長・経営層への報告 ④外部通報 専門家に連絡(メイン担当:Aさんに連絡) ※Aさんが不在の場合、Bさんに連絡 ⑤対処 応急処置・被害の封じ込めと原因調査開始 ⑥復旧 バックアップの活用 ⑦報告 個人情報流出→個人情報保護委員会へ サイバー攻撃→IPAへ ※社内Aさんと社外Xさんが各所に連絡
インシデント発生時に、ただちに迷わず動ける対応フローを事前に必ずつくっておきましょう

機能を増やしすぎないことも、セキュリティ対策の一つ

──最後に、ここまでのお話を通して言い残していることがあれば教えてください。

熊澤  私たちはあえて、CMSの「機能の星取表」をつくらないようにしています。

──星取表、とは?

熊澤  CMSの機能をリスト化して、「この機能はある」「これはない」と◯×で整理する表ですね。実はこれをつくると、「せっかくだから、この機能も入れておこう」と機能を盛り込みすぎてしまうことが多いんです。

──確かに、一覧があると全部そろえたくなりそうです。

熊澤  そうなんです。もちろん、リスト自体は見積もりや確認の際には便利ですし、完全に否定するものではありません。ただ、星取表があることで、本来必要ない機能まで導入してしまうケースも少なくありません。

機能が増えれば、それだけ管理する対象も増えます。結果として、セキュリティのリスクや運用負担が大きくなる可能性もあります。

──必要な機能を見極めることが重要、ということですね。

熊澤  はい。CMSは「何でもできること」が重要なのではなく、「必要なことを安全に運用できること」が大切です。機能を増やしすぎない設計も、結果としてセキュリティや運用の安定につながると思います。

取材・文:遠藤義浩

  • URLをコピーしました!
目次