社内共有と備忘録を兼ねて、企業サイト構築時に決めている設計方針・インストールしているプラグイン・セキュリティ対策をそれぞれまとめました。セキュリティ対策の項目を除き、構築時の細かい設定やプログラム実装についての説明は省略しています。
概要
弊社、というか自分が実装する際の方針として、WordPressと紐付ける必要のないファイルは、できるだけWordPressのファイル・フォルダと分けて構築する手法を採択しています。これはサイト全体をWordPress依存にさせたくない、ということが大きな理由です。また、関係ないファイルをWordPress内で管理させることによって、お客様やHTMLに詳しくない編集者が不用意にファイルを更新してしまうことを防ぐ意味もあります。７年以上WordPressと付き合ってきましたが、以下の設計方針が最も最適だと判断し、まとめました。
基本設計方針
- 複雑になる場合を除き、できるだけマルチサイト化ではなく、カスタム投稿で対応できるようにする。
- Wordpressの複数インストールする必要がある場合は、なるべくマルチサイト化で対応できるようにする。
- CMS化の必要の無いページはWordPress管理に含めない。
- WordPressのページ機能を使って静的ページ作成は原則行わない。
- 下書きのプレビュー機能はかなりの確率で導入して欲しいと要望をもらうため、ブロク記事など文書量が多い更新を行う投稿・及びカスタム投稿には原則動作するようにする。
- WordPressに関係ないファイルはThemeフォルダ内に入れない。
- 共通パーツはWordPressでも、静的HTMLでも同じパーツを使う。
- 静的HTML内で、部分的にWordPressの機能が必要な場合は、wp_load.phpを使って実装する。
設定プラグイン一覧
必須
実装時に最低限設定しているプラグインです。どれも管理画面のユーザビリティに配慮するためのものです。記事の順番変更、複製など、導入時にほぼ100％求められる事項に対応できます。
-
Duplicate Post
投稿の複製を投稿一覧から簡単に行えるようにする。 -
Intuitive Custom Post Order
投稿の並び替えをドラッグアンドドロップで簡単に行えるようにする。 -
Media Library Categories
ライブラリにカテゴリ情報を付与。 -
WP Multibyte Patch
日本語のマルチバイト処理の強化するプラグイン。標準インストール済み。 -
Enable Media Replace
メディア画面で画像の差し替えを可能にするプラグイン。 -
WP Admin UI Customize
管理画面メニューのカスタマイズ。権限ごとに表示を出し分けることも可能。 -
User Admin Simplifier
ユーザ権限ではなく、ユーザごとに表示させたいメニュー項目の表示・非表示を設定できる。
オプション
カスタムフィールドの拡張やURLのカスタマイズまで、オプションとは書いていますが、どれも開発上で必須なプラグインです。特にAdvanced Custom Fieldsは非常に強力です。カスタムフィールドを使用して実装するケースでは迷わず導入することを推奨します。
-
Custom Post Type UI
カスタム投稿を簡単に作成する。 -
Advanced Custom Fields
標準のカスタムフィールドよりも、明快で分かりやすい形でカスタムフィールドを操作できるプラグイン。カスタムフィールドを使った実装したいケースではほぼ必須と言っていい。複数画像登録（ギャラリー機能）や、繰り返し入力（リピーターフィールド）など高度なフィールドを作成できる。ただし、全機能を利用できるようにするためにはPro版の購入が必要。 -
Custom Post Type Permalinks
カスタム投稿のパーマリンクを自動設定してくれるプラグイン。例えば http://example.com/post_type/taxonomy/term
といったURLを「パーマリンク設定」画面で簡単に設定できるようになる。
管理画面・ユーザアカウント
管理画面には、簡潔さと扱いやすさを求められます。お客様を混乱させないために、利用を想定しない機能やボタンは極力非表示・無効化することが望ましいです。
- サイドバーメニューに操作をしないであろう項目は表示させない。特に企業サイト構築の場合、コメント機能などはほぼ必要とされないので、非表示、または無効化する。
- 記事の投稿・更新操作に関係のないブロックを残しておくとユーザビリティが低下するので、標準で用意されているタグ・リンク・カスタムフィールド入力などは、理由がなければ非表示にする。
- 純粋な「投稿」だけを使って記事を作成・更新する場合を除き、ダッシュボードから更新させるような機能は殆ど望まれないため、ダッシュボードに表示されている情報は「概要」を除いてすべて非表示、または削除する。
- ユーザアカウントは、「開発用アカウント（管理者）」と、記事を投稿・編集できる「編集用アカウント（編集者）」の2アカウントを作成し、要求される場合を除き、お客様には「編集用アカウント」のみを送付する。
セキュリティ対策
Wordpressはその人気と汎用性故に、脆弱性を狙った攻撃を受ける可能性が非常に高いCMSです。コアアップデートなど基本的な対策をしていれば大きな問題にはならないかと思いますが、油断をしてアップデートもせず、放置をしておくと問題が起きる可能性が大です。 実装・公開時には以下の対応を行う事が望ましいです。
コアアップデートは可能な限り行う
基本の基ですが、WordPress本体のコアアップデートは極力行うべきです。しかしプラグインが動作しない、長いことアップデートしていないので動作確認にコストがかかる...といったアップデートを躊躇してしまう問題もあるため、作業工数とタイミングを見て、適切にアップデートすることを推奨します。
デフォルトユーザーの「admin」は削除
デフォルトで設定されるAdminアカウントを残しておくと、総当り攻撃（ブルートフォースアタック）の成功率を高めてしまいます。初期設定で作成されたadminアカウントは公開時には必ず削除してください。
なお、はてなブックマークからご指摘頂きましたが、最近のバージョンでは初期アカウント名が必ずadminと設定される仕様ではなくなりました。新しいバージョンを新規インストールされる場合は、アカウント名をadminではなく、別の名前に設定しましょう。
パスワードは８文字以上、大文字小文字数字を混ぜたものを使う
難しく考える必要はないです。分かりやすく使い慣れたパスワードを捨てて、少なくとも公開前までには安全なパスワードに変更してください。
生成には以下のようなツールで、ランダム生成されたパスワードを使うことを推奨します。
wp-config.php, wp-comments-post.phpへのアクセス禁止
攻撃を受けやすいファイルへのアクセスを禁止します。
ルートに設置されているwp-config.php及びwp-comments-post.phpへのアクセスを禁止します。.htaccessに以下を記述。
<files wp-config.php>
order allow,deny
deny from all
</files>
<files wp-comments-post.php>
order allow,deny
deny from all
</files>
xmlrpc.phpファイルへのアクセス禁止（または削除）
xmlrpc.phpファイルは、ピンバックや、スマホアプリなどからの更新を行うためのファイルです。しかし、通常の企業サイトでその更新スタイルを望まれたことは殆どありません。アクセス禁止、またはファイル自体の削除を行うことを推奨します。
.htaccessでアクセス禁止にする場合は以下の記述を追加。
<files xmlrpc.php>
order deny,allow
deny from all
</files>
ログイン画面へのアクセス禁止
管理画面への承認されていないIPからのアクセスを禁止します。allow from 00.00.00.00には、任意のグローバルIPを記述して設定してください。管理画面へは、wp-login.phpからのアクセスと/wp-admin/ディレクトリからの二通りのアクセスが行えるため、それぞれに設定が必要です。なお、グローバルIPアドレスはお客様側のIP設定も必要なことを留意してください。
wp-login.phpへのアクセス禁止
ルートに設置されているwp-login.phpへのアクセスを禁止します。.htaccessに以下を記述。
<files wp-login.php>
order deny,allow
deny from all
allow from 00.00.00.00
</files>
/wp-admin/ディレクトリへのアクセス禁止
/wp-admin/ディレクトリへのアクセスを禁止します。/wp-admin/配下に.htaccessを作成し、以下を記述。
order deny,allow
deny from all
allow from 00.00.00.00
不要ファイルの除去
- license.txt
- readme.html
- wp-config-sample.php
上記のようなWordPressの動作に関係ない不要ファイルは設置前に消去することを推奨します。
不要なプラグインは無効化・または削除する
動作に必要のないプラグインはリリース前に無効化、まったく必要のないものは削除することを推奨します。
不要なテーマファイルも削除する
PHPファイルで構成されるテーマファイルは攻撃対象になりえます。デフォルトでインストールされているtwentyシリーズは、そのインストール率の高さからセキュリティ的には危険なファイルです。
使用している場合はともかく、不要であれば極力削除することが望ましいです。
プラグインを使ったセキュリティ対策について
ネットを検索すると必ずと行っていいほどプラグインによるセキュリティ対策が上位にランクインします。導入コストが低く、知識がない人間にも簡単に扱えるのが強みですが、もっとも使われている無料版はソースコードが公開されているため、脆弱性の解析によって攻撃受ける可能性があります。また、無料プラグインの場合はその無料という性質の都合、アップデートも必ず行われるかの確証がありません。どのように運用していくか、導入コストなどを鑑みて導入判断を行う必要があります。
この手のプラグインはいくつもありますが、国産で有名且つ情報が豊富なセキュリティプラグインの代表格として、「SiteGuard WP Plugin」が挙げられます。
セキュリティ対策の参考記事
公式ドキュメントにもブルートフォースアタックへの対策ドキュメントがあります。
なんという良記事。
「コアアップデートは可能な限り行う」という所は自分も悩んでおりまして明確な基準を出せずにおります・・・。
@hose それについては私も最適解が見つけられずで（苦笑
更新費・初期構築費用にセキュリティ対策項目を含んでいるならその中から対応コストを割ければよいかと思っています。一方で、運用でない作りきりの案件やコストが割けない場合は、自動アップデートを導入しておく、アップデート以外の最低限のセキュリティ対策をしておく、という方針をとっています。
素晴らしい記事をありがとうございます。
WPのページ機能を使わない、という方針には何か理由があるのでしょうか？
コメントでの質問失礼します。
こう言う記事は、非常に重宝してます。まとめ共有、ありがとうございます。
なお、WPのセキュリティに関して、一点確認したい事があります。
回答頂けますと幸いです。
自分の場合、最近のWPしか触った事がないのですが、'wp-config.php'とは初期生成時のみサンプルファイルから作って、その後'wp-config'と言うフォルダになっているようなのですがどこかに存在してるんでしょうか？
それともサンプルファイル自体にアクセス制限なりと読み替えですかね？
読んでいただきましてありがとうございます。
@wack746 WPのページ機能を使わないのは、WPに関係ないページをWPで管理したくない・依存させたくないというのが理由です。静的ページを作るのであれば、通常のhtmlやphpファイルで直接管理するほうが、制作サイドからするとずっと楽という事情もあります。
もちろん、動的更新エリアなどがあればその限りではないです。
@jack-low wp-config.phpは通常WordPressインストール時に、インストールディレクトリ配下に生成されます。もちろんwp-config-sample.phpをリネームして、手動設定しても動作します。wp-configディレクトリについてはちょっとわかりませんが、通常そのフォルダは生成されなかったと思います。