[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[dennou-ruby:002632] Re: Ruby で 作った小物置き場



odakker@xxxxxxxxxxxxxx wrote:
> Hiki とか Wiki って便利だなあ, とはかねがね思ってはいたのですが, 
> セキュリティが気になって dennou サーバ等への導入には躊躇していました. 
> 
> 導入に際しどのような点に気をつければよいのか, ご存知でしたら教えて下さい. 
> 特に書き込みに際してのアクセス制御をどのように行っているのかが気になって
> います.

プロダクトによって違うので、Hiki のばあい。

昔からのやり方は、気にしないというものです。
ただし、セキュリティとしては通常のレベル、すなわちデータを
HTTPでアクセスできないところにおくということはやっておきます。
しかし Hiki はすっかり有名になったのでロボットによるスパムが
あります。これに対する対処は3つ。

ひとつは書き込みは完全に制限するというもの。これは簡単です。
たとえば、
http://www.nesugi.net/hiki/?hiki%A4%D8%A4%CE%BD%F1%A4%AD%B9%FE%A4%DF%A4%F2%B6%D8%BB%DF%A4%B9%A4%EB

ふたつ目は、とりあえず書かせておいて馬鹿野郎のパターンを
見切ったら Apache の設定でアドレスなりAgentなりでフィルターして
ブロックするというものです。

最後のひとつは、これが本命で、先週かずひこさんに教えてもらうまで
気づいてなかったのですが(駄目じゃん)、標準の認証プラグインを
使うというものです。
http://hikiwiki.org/ja/edit_user.rb.html
http://hikiwiki.org/ja/auth_typekey.rb.html

なおふたつ目の場合は、svn か cvs と連動させて、いたずらを
見つけたら昔に戻すということは必要になると思います。
http://hikiwiki.org/ja/history.rb.html
はやくみつけるには RSS を監視しておくとよいです。

実はもう一個あって、これはうちの会社で使っている方法ですが、
Apache で認証できないとそもそも読めないという方法です。
IE が Referer を投げるチャンスを減らすために HTTPS にするとか
HTTPで認証するならダイジェスト認証にするとか。パスワード漏洩が
気になる場合は、SSL のクライアント認証という手もありますが、
クライアントのマシンが安全に運用されていることが要求されるので、
わりと特殊かもしれません。

先週の RubyKaigi2006 で、えんたーぷらいずな運用で各種のアプリでの
認証に関するニーズが、あたりまえですが、あることが分かったので、
なんとなくフレームワークのアイデアを練っています。
Active Directory 対応とか、他のアプリに対して認証だけ貸すとか
逆に借りるとかいった枠組みを作ってパッチなりプラグインを
書いたらいいかなあとか思っています。Apache に任せる mod_auth_form
あたりも参考になりそうです。


ごとけん