セキュリティガイド

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

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

1.認証について

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

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

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

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

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


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


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

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

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

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

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

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

---

→トピックガイド