ＷＥＢ／ＤＢ 関連 => CMSサイト制作環境の構築 > ４．CMSに共通する導入プロセス ～ WordPress を例に
引き続き、クライアント側の視点で、サーバーに CMS を導入する手順についてみていきます。WordPress に限らず PHP や CGI 等で書かれた SQLデータベースと連携して動作する CMS の導入手順は概ね共通しています。
本稿ではLAN内の開発環境を想定していますが、ホスティングサービス等においても作業手順は全く同じです。ただし公共のネットワークを経由して設置する場合は、通信経路が暗号化されている必要があります。
コンテンツを作成する作業の度にCMSにログインする必要があります。その度にCMS管理者の認証情報は平文で公共のネットワークを流れます。FTP や Webサーバーが SSLで通信経路が保護できないホスティングサービスにおいては、そもそも CMS によるサイト運用を行うべきではありません。
ユーザー自身がCMSをサーバーにインストールする手順は以下の通りです。WordPress に限った話しではありません。
このプロセスで特に重要なのが ３の工程です。
.公共のネットワークを使用してサーバーに接続するケースでは、DBアカウント情報の扱いには特に注意する必要があります。
WordPress に限らず SQLデータベースと連携して動作するCMSは、初回セットアップ時に、DBサーバーのホスト名（場所）とデータベースのアカウントの入力を求められます。
この時、https:// で始まるSSLで保護されたURLでなかった場合、DBアカウント情報がインターネットを平文で流れる事になります。
万が一、DBアカウントが第三者に渡った場合、それはCMSで管理するサイト内の全ての情報が外部に流出する危険性が高くなります。先程、説明した以下の構成を思い出して下さい。
Internet（公共のネットワークから接続するユーザー）
↓port80＆443
Apache（Web Server）← PHP → MySQL（DB）
前のページで説明したように、データベースサーバーは通常、直接外部から接続できるようにはなっていません。SSH や Webサーバーといったサーバーがフロントエンドの役割を果たしています。
ご存知のようにホスティングサービスでは、複数のユーザーがWebサーバーを利用しているため、そこで運用されている CMS の穴が放置されたり、パーミッションの設定があまかったりして任意のコードが実行されてしまう恐れがあります。
いくら自分が細心の注意を払って、CMS を最新の状態にアップデートしていても、自分以外の契約者の誰かが、PHPやCGI 等で書かれたプログラムのバグを放置していれば、そこを足がかりに漏えいした自分のDBアカウントを使ってデータベースに接続されてしまいます。
これまでの解説で、PHPを個々のユーザー権限で動作させる手順を説明してきましたが、いくら PHP が個々のユーザー権限で動作していたとしても、MySQL等のデータベース側から見れば localhost からの正しいDBアカウントからの接続となるため、このようなリスクは回避できません。
このことは「自分のデータベースのアカウント情報は、絶対に第三者に漏れてはいけない」ことを意味しています。
Internet（公共のネットワークから接続するユーザー）
↓×
Apache（Web Server）← PHP → MySQL（DB）
↑○
Intranet（LAN内のクライアント＝制作スタッフ）
本稿ではLANの制作スタッフのためのサーバーを想定しているので、直接的に関係する問題ではありませんが、CMS によるサイトが完成し、それを納品する段階では、クライアントが契約しているサーバーに設置する必要があるので、制作スタッフにも、これらの認識は必要です。
DBのアカウントがネットワークを流れるのは、このサーバーにCMSを設置するときに入力を求められるこの 1回のみです。
正確には CMS を設置する度に発生しますが、これらのデータベースのアカウント情報（IDとパスワード）は、CMSの動作に必要なので、CMSのセットアップスクリプト実行時に生成されるPHPファイルに平文で直接記述されています。
これらファイルは初回、書き込み権限が付与されているので、設定が終われば、書き込みを禁止にして、第三者が読めないように所有者だけ読み込みだけを許可するようにパーミッションを変更する必要があります。
この際、４００に設定できるか、４０４に設定出来るかは、ホスティングサービスにおいては大変重要なことであることはこれまで説明したとおりです。
後はWebサーバーとデータベースの位置関係は大抵の場合、先に示したように localhost の位置関係にあるので、同一のホスト内でWebサーバーとDBサーバーの接続は完了します。
よってネットワークをデータベースのアカウント情報が流れるのは、初回の設置のみ、ということになります。
CMS のセットアップ時には、必ず CMS の管理者パスワードの設定を求められます。こちらは、CMS でコンテンツを作成する度に必要となるCMS内のユーザーアカウントの事であり、これらの情報はデータベース内に格納されます。
当然、サイトを更新する度にログインする必要があるので、サイト更新の度にネットワークを ID と パスワードが流れる事になります。
良くCookie などでパスワード入力を省略するものがありますが、実際には Cookie に記録された ID と パスワードを使ってログイン作業を自動化しているだけであり、実際には ID とパスワードがその都度ネットワークを流れています。
CMS のユーザーアカウントが、第三者に渡るとどういうことになるかは、説明するまでもありません。CMS によるサイト運用を考えた場合、通信経路が暗号化できるかどうか、という点は重要なポイントになります。
本稿では、LAN内の開発環境の構築を想定しているので、このような通信経路に関する暗号化保護の対策は必要がない前提で書いています。ホスティングサービスでの設置を考えている方は、本稿の内容をそのまま当てはめて解釈するのは注意が必要です。
CMSによるサイト運用を考えた場合、初回セットアップや、CMS管理画面にログインする場合は、その通信経路がSSLで暗号化されている必要があり、それが可能かどうかを最初に確認する必要があります。
サーバーをレンタルする場合、単にCMSが動作します、と言うことだけで善し悪しを判断する事は出来ません。また、改竄されても自己責任で済む個人の匿名日記と、個人情報を扱うショッピングサイト、ビジネスを想定した企業のサイトでは扱う情報によっても求められる対策は一様に同じではありません。その後の運用や、保守管理の面で、安全な手段が提供されているか、CMSの導入には、メリットとデメリットをサイトの目的と照らし天秤に掛ける、慎重な判断が求められます。既にサイトを運用している方が、これから CMSによるサイト運用を考えた場合、「単に目的のCMSが動くから、」と安心するのではなく、サーバーを選定するところからも考え直さないといけない、という認識は必要です。
CMSのメリットとデメリットのページでも紹介しましたが、サーバーとCMSの保守管理をアウトソーシングする感覚で、コンテンツ制作に専念できる CMS も存在します。
無料で提供されている個人ブログの広告なし、企業ＨＰやショッピングサイト版のような位置づけのサービスです。
技術敵に目新しい物ではありませんが、CMSのサイト運用を考えている方は、サーバー管理、CMSの保守管理の必要のないクラウド型のCMSも検討対象に入ります。
引き続き、これらの留意点を認識した上で、WordPress を例にCMSをサーバーに設置する手順について説明します。
目次 １１ / １６ 
最大2台のドライブまで取り付け可能。デュアルコアプロセッサを備え、マルチメディア向けやデータ共有に最適なNASサーバー
