【 2020 年版】 CMS 利用時に必須のセキュリティ対策
CMS を使ってウェブサイトを構築・運用するときに必須のセキュリティ対策について説明します。
「 CMS 」といえば圧倒的なシェアを持つ「 WordPress 」ですが、今回のお話は WordPress だけにかぎったお話ではありません。 どの CMS でも必ず行うべき共通のセキュリティ対策について述べたいと思います。
尚 CMS には大きく「インストール型」と「クラウドサービス型」の 2 種類がありますが、今回は「インストール型」の CMS を主にイメージしています。 また、今回は CMS をビジネスで利用する場合のみを想定しており、勉強や趣味の一環で CMS を利用する場合は想定していません。
では本題です。
目次:
-
全体
- CMS を正しく使う
- 怪しい CMS の使用を避ける
-
準備フェーズ
- セキュリティ方針を決める
-
構築フェーズ
- 信頼できるプラグインだけを使う
- ロールと権限の設定を正しく行う
- ファイルの公開設定を正しく行う
- スパム対策を行う
- HTTPS 化を行う
- SFTP や SCP でコードをアップロードする
- 公式の API を使う
-
運用フェーズ
- 最新バージョンを使う
- 利用するアカウントだけを有効化する
- 利用する機能だけを有効化する
- 複雑なパスワードを設定する
まずは全体的なところからです。
全体
CMS を正しく使う
まず重要なのは、正しいセキュリティ知識を身に着け CMS の正しい使い方を学んだ上で CMS を正しく使うことです。
具体的には、ウェブサイトの構築と運用におけるセキュリティの基礎知識を学ぶこと、 CMS 公式のマニュアルや書籍で使い方を学ぶこと、 CMS の正しい用法を守って使うことです。 これはできている人にとっては改めて言うまでもない基本中の基本ですが、現実にはできていない人が大半です。 ウェブ制作に携わっている人でもできていない人がたくさんいるので、 CMS 関連のセキュリティインシデントの大多数は利用者の知識不足・間違った使い方に原因があると私は考えています。
まずは正しい知識を身に着けて正しく使うこと。 それが難しいのであれば、適切な技術を持った専門家に外注することが一番のセキュリティ対策です。
怪しい CMS の使用を避ける
もうひとつ重要なのは、安全性が疑わしい怪しい CMS の使用を避けることです。
世の中のすべての CMS が健全に開発されているわけではなく、セキュリティへの配慮が不十分な CMS や適切なメンテナンスが行われていない CMS も中には存在します。 特に注意が必要なのは、一見問題無さそうに見えて開発体制やメンテナンスの持続性に問題がある CMS です。
CMS というのは Windows 等の OS といっしょで「脆弱性が見つかったら修正されて、また見つかっては修正されて」が繰り返されるソフトウェアなので、ある時点でいくら高品質の CMS でもメンテナンスが行われなくなってしまえばその使用には高いリスクが伴います。
すべての CMS のメンテナンスはいつか終わるため、そのこと自体は問題ではありません。 重要なのはそれが来年なのか 5 年先なのか 10 年先なのかということです。 サイトのライフサイクルの途中でメンテナンスが終わってしまう可能性の高い CMS は極力避けるべきです。
準備フェーズ
セキュリティ方針を決める
全体的なセキュリティ対策の方向性を決めることです。
考え方は、事業やプロジェクトの運営におけるリスクマネジメントと同じです。 まず、どのようなリスクが想定されるのかを洗い出しそれぞれ評価します。 その上で何を行い何を行わないのか、どのように行うのかを決めます。
人間がいくら健康に気を付けても絶対に風邪をひかないことが不可能なのと同じく、ウェブサイトのセキュリティに完璧はありえません。 また、コストをかければそれだけやれることは増えますが、その分だけセキュリティレベルが上がるかというと必ずしもそうではありません。
そのため、 80:20 の法則を念頭にリソースを注ぐべきポイントを見極め、費用対効果が高くなる形で対策を行うことが重要です。
構築フェーズ
信頼できるプラグインだけを使う
本当に信頼できるプラグインだけを使うことです。
いま主流のオープンソース CMS の場合、有償・無償のサードパーティプラグインが利用できることが一般的です。 無償または安価で高機能なプラグインが利用できるのは魅力的ですが、それらプラグインがすべて安全かというとそういうわけではありません。
一般にプラグインのセキュリティ品質は CMS 本体よりも劣ります。 また、中には悪意のある開発者にハッキングされてしまったプラグインや最初から悪意を持って作られたプラグインなんかも存在します。 そのため有名な CMS のプラグインだからといって油断してはいけません。
オープンソースのプラグインであれば実際のコードを見て確かめるのが理想ですが、技術力や時間的な制約のためにそれは必ずしも現実的ではないでしょう。 多くの場合は代わりに、プラグインのメンテナンス状況や利用統計、口コミ、開発者のプロフィール等を見て信頼できるプラグインかどうかを判断します。
ロールと権限の設定を正しく行う
サイト利用者のロールと権限を明確に定義し CMS 上で適切に設定することです。
まず企画・要件定義の一環として「そのサイトにはどんなユーザーがいて、各タイプのユーザーはどんなことができるのか」を定義しなくてはいけません。 続いて、それを実装フェーズでヌケモレなく適切に実装します。
ここで、「ロール」というのは「権限」という切り口で分けたときのユーザーのグループのことで、「権限」はページ閲覧やデータ操作の可否のことです。 例えば、「匿名ユーザー」「投稿者」「管理者」というロールと、「ファイルをダウンロードできる」「トップページを編集できる」という権限があるイメージです。
このロールと権限の設定を適切に行わないと、たとえ悪意のあるユーザーからの攻撃を受けなくても、思わぬ機密情報の漏洩やデータのロスが起こりえます。 企画と構築の担当が分かれている場合は特に、伝達のモレやミスがないように、ドキュメントに落とし込んで伝えることが重要です。
スパム対策を行う
コメントフォームやコンタクトフォームのようにサイトの訪問者がデータを投稿できる機能を設ける場合は、スパム対策を行うことです。
近年は AI 技術を用いた高精度な検知能力を持つスパム対策ツールが無償または安価で提供されているので、導入のハードルは非常に低くなっています。 メジャーな CMS の場合はそれこそ、ただプラグインをインストールして利用キーを取得するだけで利用できるようなプラグインもあったりするので、プログラミングの知識が無くてもかんたんに導入できます。
ログインフォームを不特定多数の人がアクセスできる状態で公開する場合は、認証処理の前にスパム判定処理を追加することで悪意のあるボットによるログインチャレンジの回数を大幅に減らすことができるので、ログインページのセキュリティ強化にも有効です。
ファイルの公開設定を正しく行う
ウェブサーバー上で公開するファイルのアクセス権限を正しく設定することです。
一般に CMS を構成するファイルにはウェブ上で公開してもよいファイルとそうでないファイルがあります。 まずは、公開してもよいファイルとそうでないファイルとを明確に分類します。 その上で、公開してはいけないファイルにはアクセスができないように適切にウェブサーバーの設定を行います。
メジャーな CMS ではよく PHP が使われていて 、それらの多くは CMS のファイル一式をまるごとウェブサーバーの公開ディレクトリ以下に設置する形で利用するようになっています。 これは初学者にはかんたんでわかりやすいよい特徴ですが、設定を少しでも間違うと公開すべきでない情報を全世界に公開してしまう危険な方法でもあります。
例えば、 CMS 利用として最も多いパターンである WordPress + Apache の場合、設定ファイル
.htaccess
を設置し忘れたら NG です。
.htaccess
は先頭に
.
が付いている隠しファイルで、 FTP クライアントやファイラの設定によっては画面上に表示されません。
中の設定の記述が間違っている場合でも、わかりやすくエラーで教えてくれるとはかぎらないので、作業者がきちんと確認する必要があります。
HTTPS 化を行う
ウェブサーバーと利用者との間の通信を暗号化する HTTPS 化です。
HTTPS 化というのは TLS/SSL と呼ばれる技術を用いてブラウザが通常利用する
http
に代わりに
https
というルールを使う形に設定することです。
これでできることはかんたんに言えば「通信の安全化」です。
HTTPS 化を行えばウェブサーバー・利用者間の通信経路上での盗聴が実質できなくなります。
逆に HTTPS 化を行わないと、経路上でデータが丸見えの状態で通信が行われます。 その場合、いくら複雑なパスワードを設定したとしても外から丸見えな形でやりとりされてしまうため、悪意のある人たちにパスワードが知られるのは時間の問題です。
一昔前は一部のページだけ HTTPS 化すればよいという考え方もありましたが、近年はプライバシーの意識が高まっていることもあって全ページ HTTPS 化する考え方が主流です。
SFTP や SCP でコードをアップロードする
本番環境のウェブサーバーに CMS のファイル一式をアップロードするときに、 SFTP や SCP 等の通信が暗号化された方法を使うことです。
逆に、 FTP 等通信が暗号化されない方法を使ってはいけません。 なぜか一昔前は FTP がよく使われていたようですが、 FTP は本来使うべきではありません。
データベースを使っていてログイン機能を持つ CMS の場合、データベースのパスワードや認証キーを設定ファイルで管理することが一般的です。 その設定ファイルを FTP で送るということは、クレジットカードの暗証番号をはがきに書いてそのままポストに投函するようなものです。 そのようなはがきを送っても悪用されず無事に済む可能性もありますが、悪用される可能性はいくらでもあるので、悪用されても文句は言えません。
公式の API を使う
CMS のカスタマイズの一環で独自のプラグインやテーマを自作する場合は、 CMS 本体やプログラミング言語が提供する公式の API を適切に利用することです。
逆に言うと、それが正しいという強い確信がないかぎり公式に推奨された方法以外は使ってはいけません。 少なくとも「アクセス制御」「ユーザーからのデータの受け取り」「データベースとファイルの取り扱い」「コマンドの実行」「画面への出力」、これらの処理を行うときは適切な API を使うことが大切です。 メジャーな CMS であれば、 CMS ベースのサイトで一般によく行う処理であれば必ずセキュリティを考慮した API が用意されています。
運用フェーズ
最新バージョンを使う
CMS やプラグインの最新バージョンがリリースされたら速やかに更新することです。
CMS は Windows や Android 等の OS と同じように、一度完成したらそれで終わりではなく次々と新しい脆弱性が見つかっては対応されていくタイプのソフトウェアです。 そのため CMS は原則、導入後に継続的に更新し続けることが大前提です。
CMS は一般に不特定多数の人がアクセスできるウェブサイトで使われるということもあって、脆弱性公開後に攻撃が行われる「ゼロデイ攻撃」の格好の標的です。 そのため、 CMS は新しいバージョンがリリースされたらできるだけ速やかにアップデートを行うことが重要です。
ちなみに、レンタルサーバーを利用する場合はあまり気にする必要はありませんが、プログラミング言語やミドルウェア、 OS にも同様のセキュリティ関連アップデートがあるためそれらも適宜更新していく必要があります。
ただし、サードパーティプラグインの場合は、最新バージョンにバグが含まれていたりアップデート処理がうまく行かなかったりする可能性が CMS 本体よりも高いので、最新バージョンを素早く適用することが必ずしもベストとはかぎらないため注意が必要です。
利用するアカウントだけを有効化する
運用時に本当に利用するユーザーアカウントだけを登録・有効化することです。
使う予定の無いアカウントを予備で登録しておいたり、テスト用に作ったアカウントを放置するべきではありません。 一時期使ったけれど使わなくなったアカウントは削除するか、少なくともログインができないように無効化しておくべきです。
強い権限を持つ管理者アカウントを放置しておくことは CMS を丸ごと乗っ取られたりデータを破壊されたりといった深刻な被害につながることがあるため、管理者アカウントの管理には細心の注意を払う必要があります。
利用する機能だけを有効化する
運用時に本当に利用する機能だけを有効化することです。
CMS 本体にデフォルトで備わった機能のうち使わないものは極力無効化します。 ただしそれを正しく行うには、 CMS 本体にどのような機能が備わっているのかを正しく理解しておく必要があります。
プラグインは実際に利用するもの以外はすべて無効化します。 例えば、開発でのみ使用するものや一度使った後に使わなくなったものは本番環境では必ず無効化します。
無効化したプラグインはファイル丸ごと削除してしまうのが理想です。 利用しないプラグインには目が行き届かないため、セキュリティ関連のアップデートがリリースされた場合でもすぐに気づかずに対応が遅れてしまいがちです。 将来的にまた利用する可能性があるプラグインでもしばらくの間使用しないものはいったんファイルごと削除しておくとより安全です。
複雑なパスワードを設定する
ログインにパスワードを使用する一般的な CMS の場合は、パスワードをかんたんに推測できない複雑なものに設定します。
よく言われる複雑なパスワードの基準は、「○文字以上」「大文字小文字入り」「数字記号入り」で、「ユーザー名や誕生日を含まない」「パスワードの使い回しをしない」です。 具体的に何文字以上がよいかという線引きに絶対的な正解はありませんが、 2020 年時点では 12 〜 20 文字が推奨されている場合をよく見かけます。 これは技術の発展にあわせてどんどん長くなっていきます。
人間が複雑なパスワードを覚えておくことは難しいですしあまりに複雑なものを毎回入力するのは作業効率が悪いので、サイトには複雑なパスワードを設定しておいてパスワードの手元での管理にはパスワードマネジャーを使うのがよいでしょう。
最後に
以上です。 最後におさらいとして一覧をもう一度掲載します:
-
全体
- CMS を正しく使う
- 怪しい CMS の使用を避ける
-
準備フェーズ
- セキュリティ方針を決める
-
構築フェーズ
- 信頼できるプラグインだけを使う
- ロールと権限の設定を正しく行う
- ファイルのアクセス制御設定を正しく行う
- スパム対策を行う
- HTTPS 化を行う
- SFTP や SCP でコードをアップロードする
- 公式の API を使う
-
運用フェーズ
- 最新バージョンを使う
- 利用するアカウントだけを有効化する
- 利用する機能だけを有効化する
- 複雑なパスワードを設定する
一般的なリスク管理の考え方と同じで、 CMS のセキュリティ対策というのは「想定されるリスク × かけられる予算」のバランスで決めるものです。 また、セキュリティ対策には「ここまでやれば OK 」という絶対のゴールはありません。
そのため、今回ご紹介したものをすべて行えば絶対に大丈夫かというとそんなわけではありませんし、逆にこれらをやらなければ必ずセキュリティ攻撃を受けて被害を受けるともかぎりません。 結局は、セキュリティ対策として何をやって何をやらないかというのは、サイトのビジネス上の位置づけや特性を考慮して個別に決めるしかありません。
その意味で、これらはあくまでも私が 2020 年時点で考える「必須の対策」に過ぎませんが、 CMS 利用時のセキュリティ対策をどうすべきか迷っている方にはご参考にになるのではないかと思います。 お役に立てば幸いです :D
ちなみに、非常に効果が高いけれど「必須というほどでもない」と考える対策として今回ボツにした対策は以下のとおりです。 何年か後にはこれらをやって当然の世界になっているかもしれません。
-
構築フェーズ
- セキュリティ強化プラグインを使う
- ２要素認証を追加する
-
運用フェーズ
- ファイヤウォールを追加する
参考
ボツ
（オプション）セキュリティ強化プラグインを使う
CMS 本体に無い機能を追加したり補完したりしてセキュリティを強化してくれるプラグインを使うことです。
メジャーなオープンソースの CMS の場合、セキュリティ強化のための定番プラグインが提供されていることがよくあります。
例えば、「パスワードポリシーのカスタマイズ」「ログインフォームの試行回数制限」「スパムブロック」「 IP 制限」等の、適切に使えば CMS のセキュリティを大幅に強化できる機能を提供するものもあるので、そのようなプラグインがある場合は積極的に活用します。
（オプション）２要素認証を追加する
パスワードに加えて、プラスアルファの方法で本人確認を行うこと 英語で 2FA と呼ばれる 主流なのは、ユーザーがパスワードでログインした後に、 SMS やメール、 Authenticator を使ってパスコードを送りその入力を求める方法 記事執筆時点では必須というほどではなくて、個人情報等重要な情報を扱うサイトやクレジットカードが利用できるサイトでの利用にとどまっているけれど、年々広まってきている。数年以内にスタンダードになることもありえると思う。
（オプション）ファイヤウォールを追加する
WordPress よりももっと下のレイヤーでのアクセス制御 よくあるのは、海外からのアクセスを拒否する等 CMS を使ったサイトに対するセキュリティ攻撃のほとんどは海外からのもの。一部の国に集中することも多い。だから、海外からのアクセスをそもそも遮断したらリスクは大幅に減る。セキュリティ攻撃が盛んな一部の国を遮断するだけでも大きい。