Trac: Trac利用ユーザーへのアクセス制限をする方法 | A Day In The Boy's Life

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

Tracはバグ管理だけでなく、システム運用管理での情報管理・共有に適したツールですが、その特性の一つには情報の可視化があげられます。(参考: Tracの使い方 - バグ管理システム以外のTracの用途 -


ですので、ここで書くことはそれに少しそむく事ではあるのですが、社内でTracを利用する場合に、プロジェクトメンバー以外に情報を見せたくない、部外に知られてはまずい情報を共有する事ができないなどもあるため、Trac上の情報にアクセス制限するための対策が必要になる場合もあります。


ここでは、Tracを使う上でその中にある情報を保護するための手段を書いてみたいと思います。



Tracの権限を使って情報を保護する


最も簡単な方法です。

Trac上には様々な権限が用意 されており、それらを使えばチケットやWikiの情報をプロジェクトメンバー以外に知られないようにする事ができます。

具体的に言えば、「TICKET_VIEW」権限や「WIKI_VIEW」権限をanonymousから取り払えば、ログインしていないユーザーにチケットやWikiの情報を見せない事が可能です。


ただ、anonymousからWIKI_VIEW権限を取ってしまうと、Tracにアクセスした際にTOPに何も表示されず、何のシステムかよく分からない状態にもなりますし、メールでチケットのURLを送ったらログインしなくとも見ることができた方が利用しやすいですので、毎回ログインしないといけないという状況は利用者にとって苦になるかもしれません。


また、Tracの権限付与はTRAC_ADMIN権限(またはサーバーへのログイン権限)があれば出来てしまいますので、管理者が勝手に権限を書き換えるという事も出来てしまいます。

Tracにはアカウント管理の機構を用意していません(Basic認証用のユーザーID/パスワードがそれになる)ので、利用者は自分のパスワードをTrac上から変更する事もできないので、アカウントを共有されたりするとプロジェクトメンバー以外に情報が漏れる可能性があります。


この方法を使う場合、ユーザーをグループ化するなど管理しやすいようにしておいた方がよいでしょう。

参考: Tracの使い方 - 利用者の権限をグループ化する -



Tracの管理ディレクトリごとBasic認証をかけてしまう


Tarcには元々ログインする際に、Basic認証によりユーザー認証を行いますが、Tracへログインする時だけでなく、システムへアクセスする際にいきなりBasic認証を行うように設定してしまおうと言う方法です。

設定方法は、TracのインストールディレクトリにてBasic認証が作用するように、Apacheの設定ファイルを編集します。


設定例)

<LocationMatch "/home/trac">
AuthType Basic
AuthName "Trac"
AuthUserFile /home/trac/.htpasswd
Require valid-user
</LocationMatch>

Tracログイン時に参照される.htpasswdファイルと同様のものを参照させれば、システムにアクセスする際に求められるBasic認証をクリアすると、そのままTracへもログインできます。

ただし、この問題は1.で書いたようにパスワードが漏れてしまえば、想定外のメンバーからアクセスされることになります。


また、この方法をうまく使えばプロジェクト単位でTrac利用者を設定する事も可能です。


参考: バグトラッキングシステム「Trac」インストール (※ 5. Apache環境設定)


設定例)

<LocationMatch "/home/trac/project1">
AuthType Basic
AuthName "Trac"
AuthUserFile /home/trac/project1/.htpasswd
Require valid-user
</LocationMatch>

<LocationMatch "/home/trac/project2">
AuthType Basic
AuthName "Trac"
AuthUserFile /home/trac/project2/.htpasswd
Require valid-user
</LocationMatch>

Tracのプロジェクトディレクトリ(project1及びproject2)で参照する.htpasswdファイルを異なるものに指定します。

ただし、プロジェクトが増えてくると管理が煩雑になるデメリットがあります。



mod_rewriteを使ってネットワークセグメントごとにアクセス制御を行う


Tracとはかけ離れるのですが、mod_rewriteを使えばネットワークセグメントごとにApacheへのアクセス制御が行えますので、それを使って特定のネットワークからのみTracへのアクセスを許可すると言う事が実装できます。


設定例)

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !^/error_page\.html$ [NC]
RewriteCond %{REMOTE_ADDR} !^192\.168\.[0-9]*\.[0-9]*$
RewriteRule ^(.*)$ http://192.168.0.100/error_page.html

上記の設定では、アクセスもとのアドレスをApache側でチェックして、「192.168.x.x」のIPアドレスであればアクセスを許可し、それ以外の場合は「error_page.html」(このシステムへはアクセスできませんの様なエラーページ)を出力するように設定しています。

そのままでは、error_page.htmlへのアクセスも当然許可していないセグメントからはアクセスできないので、そのHTMLファイルだけは例外的にアクセスできるように設定しています。


mod_rewriteは設定がややこしいので、もしうまく行かない場合は


RewriteLog logs/rewrite_log
RewriteLogLevel 9

などして、ログファイルの中身を確認してみるとよいでしょう。(大量のログファイルが出るので注意)


この方法を使えば、例えば情報システム部門のネットワークセグメントからのみTracを参照させると言う事が可能になります。

また、アクセスできる人が想定のメンバーである事が分かっているのであれば、ある程度anonymousにも権限を持たせることができると思います。


ただし、そのようなネットワーク構成になっていないならこの方法は使えません・・・。

特定のIP限定でアクセスを設定すると言う事も可能ですが、あまりに狭い範囲で設定してしまうと情報共有ツールとしてTracを使ううまみがなくなってしまいます。



Tracはプロジェクト管理に向いているツールなので、そこで溜め込まれた情報と言うのはある意味財産です。

その財産は広く使われてこそ意味のあるものですが、システム保守・運用の観点からあまり誰しもが知ってよい情報ばかりでは無いかと思いますので、このような方法で情報を保護する対策を講じてみてはいかがでしょうか。