ＷＥＢ／ＤＢ 関連 => CMSサイト制作環境の構築 > ３．Webサーバー Apacheで CMS が動作する仕組み
ここからは LANのサーバーに WordPress0 が動作する環境を構築するために必要な環境、手順について見ていきます。サーバー管理者の視点になります。
「動作」に必要なパッケージと、「運用」に求められるパッケージは異なる点に着目して下さい。本項ではLAN内の開発環境を想定しているので、ぶっちゃけいえば、動作すれば良いことになりますが、サイトの運用を考えた場合、セキュリティに対する考え方は全く異なるため、サーバー側に求められる機能には違いがある点に留意して下さい。
WordPress に限らず PHP と SQLデータベースで動作する CMS （コンテンツマネジメントシステム）の場合も、当該CMS が要求するバージョンや、モジュールなどの個別要件を除いては、セキュリティに対する考え方についても共通します。
本項の内容は 「LAN内のサイト制作に携わるスタッフが使用する Webサーバーが既に構築されている」ことを想定しています。
例えば、具体的には DreamWeaver や HPビルダーのようなツールを使って、従来のホームページを制作するために必要な Webサーバー（Apache）が既に構築されている必要があります。
使用OS は CentOS 6.x、保守管理の面から、標準のパッケージ管理を前提にします。
これらの基本的なイントラ用のWEBサーバーや FTP サーバーの構築については、煩雑になるので割愛します。（十分煩雑ですが）以降、CMS を実行できる環境をLANの制作スタッフに提供する上でキモになる所を中心に説明します。
CentOS をはじめ、多くのLinuxディストリビューションのパッケージで提供される Apache Webサーバーでは、PHP は モジュール形式として動作するようにセットアップされています。
この場合、PHP を実行するユーザーは Apache Webサーバー（httpd）を実行している apache のユーザー権限で実行されることになります。
皆さんが普段なにげに見ているホームページのほとんどが、この様なホスティングサービスによって運用されています。
1台のサーバーを独占して使用出来る専用サーバーの場合は、これで問題ありませんが、複数のユーザーで1台のサーバーを共用するホスティングサービスの場合は大きな問題が生じます。
それは、それぞれが設置したプログラムが同じ実行権限で動作すると、同じサーバーを利用してる全く赤の他人が設置しているプログラムについて、干渉できることになってしまうからです。
CGI の場合、それぞれのユーザー実行権限での動作を実現する suEXEC という仕組みが以前からありますが、独自の CGI の設置を認めているホスティングサービスの多くは、これらの理由から suEXEC 環境を提供しています。
近年では、WordPress に代表される CMS によるサイト運用が主流になりつつあり、PHP で開発されている CMS が多い事もあって、ホスティングサービスにおいても、PHP をそれぞれのユーザー権限で動作する仕組みを提供しているサーバーレンタル業者も増えている、という背景があります。
Apache Webサーバー の PHP がどのように動作しているか調べるには、以下の内容を記述した .php ファイルを公開ディレクトリにアップロードし、ブラウザでアクセスするとわかります。
<?php
phpinfo();
?>
Server API が Apache 2.0 Handlerと表示された場合、モジュール版で動作しています。この場合、Apache WEBサーバーで動作する CMS は全て apache のユーザー権限で動作することになります。
よってユーザーはパーミッションを 400 や600 などの運用が出来るのは、Webサーバーを動作させているユーザーのみ（CentOSの場合は apache）であり、それ以外のユーザーがこのサーバーを利用する場合は、そのユーザーは自分がオーナーのファイルやディレクトリに対して、パーミッションを「その他」に対して必要最小限に緩める必要が出てきます。
CGIモードで動作するWebサーバーの場合は以下のように表示されます。
この場合、CGI や PHPはそれぞれのユーザー権限で動作しますので、CGI が suEXEC に対応している場合は、PHP をパーミッションを 400 や 600 に絞り込んだ運用が出来ることになります。（詳細は後述）
.このページはサーバー管理者を対象にしているので、パーミッションについて一定の理解、知識を持っていることを前提にしていますが、そうでない場合は、先にこちらを参照してください。
ファイルのオーナーは FTPクライアントを使ってサーバーにファイルをアップロードしたユーザーが、そのファイルの所有者（オーナー）になります。
そのシステムにアカウントをもつ、その他のユーザーや、グループにカテゴライズされるユーザーに対して、読み込み、書き込み、実行、これらの度を認めるのか、認めないのか、ファイル、ディレクトリ単位でパーミッションを設定する必要があります。
そのため、Webサーバーを動かしているユーザーが、そのファイルにアクセスするには "その他" のユーザーに対して、そのファイルのオーナーである自分自身が、FTPクライアントを使って、読み込みや、書き込み、実行等の権限を与える必要があります。
一般的には、Webサーバーの公開ディレクトリには FTP クライアントを使ってファイルをアップロードしますが、パーミッションの変更もこのFTPクライアントをつかって行います。
ここでの "その他" のユーザーとは、厳密に言えば Apache Webサーバーを動かしているユーザーのことを指しています。
具体的には、サイトを閲覧しようとしたユーザーのリクエストに答えようと Apache Webサーバーがその html を開こうとしますが、
Apache を実行しているユーザー apache が、そのファイルに対して権限がなければ、要求を実行できませんとエラーを返します。これが俗に言うパーミッションエラーです。
パーミッションエラーはサーバー側の設定でも発生する問題なので、必ずしも、ユーザー自身が行う設定が間違っているから発生するエラーとは限りません。
ユーザー側で問題解決が出来ない場合は、サーバー管理者に問い合せる必要も出てきます。ファイルの所有権は、セキュリティを考える上でいろはの「い」になる部分です。適当に変えたら動いた、という感覚で操作するのは危険で、特に書き込みの扱いには注意が必要です。
その他に対して「書き込み」権限を与える行為は「任意のプログラムを自分以外のその他のユーザーに実行させる手段を提供する行為」と考えるようにして、慎重に行う必要があります。
その他のユーザーに書き込み権限を与える必要が出てくるケースは、特にサーバーを動作させているユーザーとファイルオーナーのユーザーが異なるWebサーバーにおけるCMSによるサイト運用において必要となることがありますが、
その他のユーザーに限らず、書き込み権限に関しては、必要な作業が終われば、切っておく必要があります。
その他にしたら動作する、表示されるというのは、Webサーバー自身、つまり、apache ユーザーに許可するために、その他のユーザーに対して認めるという行為であり、複数のユーザーで共用するホスティングサービスにおいては、セキュリティ上、かなりあまい考え、ということになります。
つまり、CMS利用可能を宣伝しているサーバーレンタル業者が、この様なパーミッション設定を求めている場合は、CMS の利用は避けるべきです。
専用サーバーの場合は、利用者は1人なので、単にオーナーをPHPやCGIが動作するユーザー apache や nobody 等に chown するだけの話しですが、
1台のサーバーを複数のユーザーで利用する共用が目的の場合は、PHP や CGI が生成したファイルのオーナー（所有者）は、Webサーバーでそれを実行しているユーザーがオーナーになります。CentOS の場合はユーザー apache です。
このため、FTP クライアントを使って、それぞれのユーザーがアップロードしたファイルのオーナー（所有者）は、当然、そのユーザーになります。つまり、自分のディレクトリに所有者の異なるファイルが混在し、自分で削除したり、置き換えたりする権限がないファイルが存在する状況が発生します。
逆も同じで、そのCGIやPHPを実行しているユーザーと、FTPでそのPHPやCGIで書かれたプログラムをアップロードしたユーザーが異なると、プログラム側から見れば、ファイルに対する制限になるため、CMS によっては違った挙動を示すものがあります。
本稿で題材にしている WordPress もそれに該当します。これは WordPress に限ったはなしではなく、PHP や CGI などのWebサーバー上で動作するアプリケーションにおいては、構造的な理由に起因する共通の問題です。
例えば hoge というアカウントをサーバ管理者から与えられているとします。この hogeユーザーアカウントを利用して、サーバー利用者は FTP クライアントを使って、WordPress などの CMS をアップロードします。
この CMSを実行させるには、繰り返し説明している通り、Webサーバーで PHP 等を動作させているユーザー（通常はapache や nobody）といったユーザーに対して適切な許可を与えるように「その他」に対して、慎重且つ、適切に必要最小限の権限を与える必要があります。
つまり、ファイルオーナー（ユーザー）と PHP や CGI などを実行しているユーザーが一致しないケースです。
WordPress は、ブラウザからアップデートが行えるインターフェイスを提供していますが、このケースの場合、WordPress は、FTPのユーザーアカウントの入力を求める画面を表示します。
つまり、WordPress のアップデートプログラムを実行している自分は、これらのファイルを更新する（書き換える）権限がないので、FTPのユーザーアカウント（ファイルのユーザー権限）を貸してくれ、と言ってるわけです。
ただ、これはお勧め出来ません。ブラウザを利用してFTPのアカウント情報の入力を求める行為は、通信経路が暗号化されているべきですが、WordPress はその警告、リスクの説明すら出しません。
うんちく：従来、個人のHPでは、サービスプロバイダが提供するサーバースペースを利用することが一般的で、その際も FTPクライアントを使ってサーバーにアップロードしていました。サービスプロバイダが提供するネットワークで完結するケースも多く、通信経路を盗聴から守るという点であまり神経質になる必要がなかったためです。現在は、個人のサイトでもインターネット上に存在するサーバーをレンタルすることが一般的になっており、公共のネットワークを利用する以上は、個人ユーザーにおいても FTPの通信経路は暗号化されている必要があります。古くからＨＰで個人で情報を発信されているベテランの方ほど、そのような扱いに慣れているので、意外にセキュリティに対して無頓着であることも多いのかも知れません。
PHP や CGI等がそれぞれのユーザー権限で実行出来る Webサーバの場合、FTPでアップロードしたファイルやディレクトリのオーナー（ユーザー）と、PHP や CGI等を実行するユーザーが同じ場合です。
この場合、WordPress （PHP）は、全てのファイルに対するオーナーであるため、自身で WordPress 本体を書き換えることが出来ます。
つまり、管理画面では、FTP アカウント入力を求められることなく、アップデート作業が完了します。
このように、ファイルを置き換えるようなケース、例えばこのような本体のアップデート作業や、画像のアップロードなどファイル操作を伴うような機能を提供している CMS においては、PHP や CGI 等の動作が、実行権限によって挙動が異なることが考えられます。
これらの理由から、本稿では CMSサイト制作における開発環境の提供を目的とした場合、ユーザー側の判断で、どちらのケースを想定するか、選定できるように PHP の動作モードを選べる環境を提供出来るようにします。
そもそも Webサーバーを独占して使用するサーバー管理者の場合は、単に PHP や CGI等を動作している apache や nobody といったサーバー側で設定されているユーザーと、プログラムやファイル、ディレクトリのオーナーを同じにすれば良いだけの話しです。
ですので、パーミッションで「その他」に許可しない絞り込んだ運用が出来ます。システムに影響を与えないように、そもそも囲い込みが出来ているので、本稿で説明しているような、suEXEC などの必要性がないわけです。
下手にいじって穴を開けることになりかねないので、第三者にサーバー利用を認めるような、レンタルサーバー事業者的なサーバーの使い方をしない限りは、必要の無い機能と考えて差しさえありません。（正直、踏み台温床をつくる行為はやめてほしい…）
現実は、サイトの数とWebサーバーの数は同じではなく、世の中のほとんどのサイトはホスティングサービスにより運用されています。 また、バーチャルホストで複数のサイトを運用している場合などは、被害が全体に及ばないように、suEXEC などの個々のユーザー権限でWebアプリケーションを実行させる行為は意味があります。
CMS の多くはデータベースと連携して動作し、コンテンツの内容はデータベースに保存されています。CMSのプログラム本体のアップデートは、基本的にデータベースのアカウント情報が記されたファイル以外を差し替える手順で行います。
つまり、FTPを使ってダウンロードした最新のファイルに置き換える、という作業手順を踏みます。この際、データベースの構造に修正が必要になる場合は、自動的に修正プログラムが実行される場合があります。
この時にコンテンツが記録されたデータベースに修正が加えられるため、最悪の場合、サイトのコンテンツの中身を破壊する恐れがあります。これを回避するために、必ずデータベースのバックアップを行いましょうと言うことです。
実際にサイトを運営する側としては、その更新によってどのような変更がデータベース（コンテンツ）に影響するかわからないので、データベースそのもの、つまり、サイトのコンテンツそのものを、万が一に備え元に戻せるように、その都度、データベースをバックアップする必要があります。
これが非常に面倒なわけです。WordPress の場合は、このようなセキュリティ上、迅速に行う必要のある、データベースに修正が及ばない程度のパッチの適用が迅速に行えるインターフェイスに定評がありますが、データベースのバックアップを取る必要性が無くなるわけではありません。
これらは定期的にサーバーでデータベースのバックアップが行われているか、復元できる分かり易い手段が提供されているか、保守管理の事を考えると、共用型のサーバーをレンタルする上で非常に重要なチェック項目になります。
補足：これはデータベースが壊れた場合、データ破損に関する問題に対するためのバックアップですが、ハードウェアの故障に関してはまた、別のハードウェアにバックアップする備えが必要になる視点も忘れないで下さい。また、CMSそのものセキュリティメンテナンスを必要としないクラウド型のサービスも存在します。
このことは先に説明したとおりですが、WordPress に限らず、CMSによるサイト運用は、従来のサイト運用と異なり、これまでは考える必要もなかった保守管理作業が発生します。それらを導入するメリットと天秤に掛ける必要があります。
引き続き、PHP をそれぞれのユーザー権限で動作させるための設定について具体的に見ていきます。
目次 ５ / １６ 
最大2台のドライブまで取り付け可能。デュアルコアプロセッサを備え、マルチメディア向けやデータ共有に最適なNASサーバー
