Gumiki::Official Site
大小さまざまな規模のWebサイトをブラウザ上から容易に構築できるCMSシステム"Gumiki"の公式サイトです

セキュリティガイド

 Gumikiサイトでのデータの管理・保護について記述したものです。

Article written:2006/10/09 16:11:07


1.認証について

 Gumikiサイトを運営する場合、殆どの場合は意図しないユーザに編集されないように何らかの認証機構を用意することになります。2006/10現在、.htaccessによるBasic認証と、ver1.10から導入された、Cookieを用いたGumiki認証の2つの手段が提供されています。それぞれの基本的な導入の仕方については、Basic認証は認証設定ガイド、Gumiki認証はリリースノートのver1.10の項を参照ください。

2.ファイルの保護/隠蔽について

 上記のいずれかの認証方式により、とりあえずGumikiの操作については、意図しないユーザがアクセスできないようになりました。しかし、Gumikiで読み書きするデータを保管するファイルまでガードできているかというと、必ずしもそうではありませんし、また、Gumikiページの編集権限を持っている人が全員物理ファイルも見て差し支えないとは限りません。サイト管理者はこの問題を適切なレベルにおいて対処する必要があります。

適切なファイルパーミッション

 殆どの方はFTPソフトでファイルをアップロードして使うことになると思いますが、そのファイルに付与するパーミッション情報はどうあるべきか。
r[閲覧] 4 : このファイルをhttp:などから閲覧するための権限
w[書込] 2 : このファイルに対して編集や書き込みを許可するための権限
x[実行] 1 : このファイルをプログラムとして実行するための権限
 それぞれの権限には数値を持っており、この加算によって組み合わせを表現しています。つまり、0〜7までの数値の組み合わせがありえるわけですが、
 これをユーザ、グループ、第3者という3つの括りに対して設定します。その結果、1つのファイルには、000〜777で表現されるパーミッション値というのを持ちます。常にもっともふさわしい値が簡単に設定できれば良いのですがこれが案外面倒なものです。Webサーバによって、若干パーミッションの制約や動作の違いがあったりもします。ここでは、Unix-Apacheサーバを念頭において、適切なパーミッションの例を紹介していきます。

パーミッション値用途Gumikiで適用すると良いファイル
666読み書きされるデータファイルに対して設定します。database/内の設定ファイルおよびtext/内のページデータ
660読み書きされるデータファイルに対して設定します。第3者(other)からの直接のアクセスを禁止します。database/内の設定ファイルおよびtext/内のページデータ

 設定対象は同じですが、666ではなく660とした場合、Gumikiシステムを経由しないで直接httpでファイルを取得することができなくなります。Basic認証の場合はフォルダ単位で認証がかけられるため、666を使っておいても安心できるのですが、Gumiki認証はあくまでシステムへの認証ですから、666ではファイルに直接アクセスされて読み取られてしまう可能性があるわけです。660にしておけば直接読まれる心配は無くなります。
 どちらかというと、読み書きできるファイルは常時660のほうが安心と言えます。ただし、httpでの直接のファイル取得が禁止されてしまうわけですから、たとえばGumikiバックヤードでのログファイルの直へのアクセスができなくなってしまいます(ログ解析は、システムがデータを読み取るので問題はありません)。この違いを理解した上で適切なパーミッションを選んでください。

パーミッション値用途Gumikiで適用すると良いファイル
755直接実行されるプログラムに対して設定します。gumiki.cgi / edgumiki.cgi
440読み取り専用、あるいは間接的に実行されるライブラリ的プログラムに対して設定します。common.cgi / sql-engine.pl / auth.cgi
666読まれても特に問題ない普通のファイルに指定します。デフォルトのようなものだと思ってください。通常、FTPで転送した後パーミッションを設定しなくても自動的に666になっています色々
777 or 770特別ガードする必要のないフォルダやロックファイル用-

 直接実行するプログラム(cgi)には755、直接は実行しないプログラム(pl/cgi)には440というのを徹底しておくと色々間違いが無くて良いです。まあ、どうしても面倒というのなら全て755にしておいても動作そのものには問題はないのですが、セキュリティ上の観点でよろしくない事が起きえます。
 Gumikiでも実はやってしまったのですが、ver1.0までの common.pl に 755 とか 666 なんて指定した結果、httpで指定するとそのファイルを直接DLできちゃうわけなのですよね。それが何を意味しているのかは敢えて書きません。ごめんなさい。

 余談ですがApacheサーバの場合、実行cgiに550を付与しておいても、直アクセス成功したりします。私もよく分かっていないのですが、cgiスクリプトはPerlプログラムから結局呼ばれる関係で、常にuserの権限で実行されてる、ということなんじゃないでしょうかね。実は500でも動きますが、group権限について説明していくと面倒なので、今回はgroupの値はuserの値とあわせています。

書き込むファイルの種類とプライバシーデータの隠蔽

 Gumikiでは3種類のファイルを読み書きしています。
 一つはページの実体であるコンテンツファイル
 もう一つはレルム&ページ間の構成やその名前を保存している構成管理データ(メタデータ)、
 後一つは各種ログデータです。厳密にはログではありませんが、掲示板やCoolFeedデータなどもGumikiではログデータとして扱われます。
 コンテンツデータは /text ディレクトリに、残りの二つは /database ディレクトリに書き込まれます。

 さて、これらのファイルについての保護の重要度について考えてみます。
 コンテンツファイルはそもそもページとして公開する目的で設置しているものですから、ファイルを直では取られたくないとはいえ、基本的には見られて構わないものです。なので、普段はパーミッションは666で良いでしょう。ファイル名を推測されて直に叩かれたくない場合は、.htaccessを用いて/text ディレクトリにBasic認証をかますなり、各ファイルのパーミッションを666から660にすれば良いものと思われます。
 構成管理データは、第3者に見られたところで面白みのある内容ではありませんが、ページの在り処が一覧できてしまうため、できれば見られたくはないデータに属します。
 ログデータについては、閲覧者のIPアドレスなどをはじめとして、若干個人情報保護を検討すべきデータが含まれています。そのサイトの特色次第でもありますが、必要なら直では見られないように.htaccessを指定したり、660のパーミッションを当てておくのが良いものと思われます。.htaccessは特定のディレクトリを保護するような書き方ではなく、サイト全体に特定の拡張子以外のファイルは直に叩けないような指定をするのが一番スマートかと思われます。

 これである程度の隠蔽はできました。しかしこれでも不十分と思う人はさらにもう一段セキュリティを堅固にすることができます。 Gumikiでは /database ディレクトリの名前を変えるように推奨していますが、その部分を独立して設定項目にしておいたのはもう一つの意味がありまして、可能ならば public_htmlの外に/database を配置することができます。Webサーバの制約上、public_html の外にあるリソースにはどう頑張っても直にアクセスすることはできないため、非常に安全なものになります。但し、public_html外のディレクトリにはフォルダやファイルを作成できないとか、public_html(あるいはwww)というフォルダを持たないプロバイダもあり、どの環境でも導入可能というわけでもありません。


トピックガイド