CouchDB: SSLクライアント認証は必須なのか

クライアント認証は必須ではない

以前書いた「 CouchDBのSecurity Featuresについて」では、"database readers"(Readers)権限設定にUserやRolesを何か設定しないと、誰でもReaders権限を持つことになると書きました。

このReaders権限は通常のDocumentを操作することが可能で、閲覧する他に作成、編集ができます(削除は不可)。 Anonymousに文書を編集されても困るので、この点で(主にBasic認証での)UserかRolesの設定は必須といえるでしょう。

さらに別の記事ではSSLのクライアント認証を行なう事で、証明書を持つユーザだけのアクセスが可能になるとも書きました。しかしクライアント認証だけではUserやRoleは設定されません。

SSLを利用するもう一つの理由は、通信経路が暗号化されないために、Basic認証などに使うID/Password情報がネットワークに平文で流れることを避けることにあります。

デスクトップ環境の中でも、特定の個人だけがログインできると保証されている場合を除けば、何らかの認証は必須といえるでしょう。 また、外部サーバ、ユーザとの連携があれば、SSLによる経路の暗号化が必要になります。

結論としては、SSLを使う主な理由は経路の暗号化で、クライアント認証は実験的な要素が強く、必須とはいえません。

ただSSLクライアント認証は、もう少し使われても良いとは思います。 ネックになるのはCA局の運営コストや外部委託した場合のコストがかなり大きそうだというところでしょうか。

クライアント認証を使うポイントを無理やり考える

ネットワークを移動する相手を信用したい場合には、クライアント認証は有効です。 また外部から観察した情報だけで破られるID,Passwordとは違い、デジタルとはいえファイルに関連付けられた認証情報が必要な点も利点の一つでしょう。

サーバ間認証

ところで最初に試したProxy認証(のような外部認証サーバ)と組み合せたサーバ間認証に使う場合はどうでしょう。

Proxy認証ではMAC周りが弱点で、経路の盗聴に対しては脆弱です。 外部認証サーバ自体はProxy認証よりはましな仕組みでユーザとのやりとりをするでしょうから、外部認証サーバとCouchDBとの間にSSLクライアント認証をいれれば、経路の暗号化しながら望む相手とだけ通信をする事が可能です。

もっとも経路を暗号化すれば、クライアント認証にこだわる必要はなくて、外部認証サーバのIPアドレスでアクセス制御をしても同じ程度の要件は満しそうです。

レプリケーション

YouTubeなどをみているとCouchDBのプレゼンテーションの中では、Offline DBとしての使い方が想定されています。

この場合は、Stunnelのクライアント機能を使ってポートを開けば、アプリケーションレベルでは変更なしに透過的にネットワークを隔てた相手方に接続することができます。 ただし、同一サーバのユーザは誰でもその経路に接続できることになります。

これが許容できれば別ですが、レプリケーション機能自体が認証の仕組みを持たないと、なかなかセキュリティを高めることはできなさそうです。

ここについてはSSLクライアント認証を含めた認証機構は有望そうです。

何が必要なのか

レプリケーションのところはちょっと手がでないので、一般ユーザがCouchDBに接続する場合を考えます。

そもそものSSLクライアント認証を使おうとした動機は、CouchDBの組み込みの仕組みが既にあるLDAPやらのID, Passwordの仕組みと一緒に使えない事に起因するものでした。

パスワードをいく通りも覚えるのは無理ですから、普通はLDAPに統合するでしょう。 現実世界がなかなかこうなっていないのは理解していますが、そうするべきです。

LDAPでも何でも生のパスワード情報にアクセスするのは容易ではありません。 バッチ的な手法を使っても、CouchDB上にユーザ毎のページを生成するのは難しい側面があります。

解説記事を盲信することなかれ

CouchDB Wikiや解説記事の中にはApacheによる認証を行う方法を紹介しているものがあります。 authentication_handlerにnull_authentication_handlerを指定するよう指示がありますが、全てのユーザに"admin" Roleを付与することに注意してください。

とはいえCouchDB附属のBasic認証では、LDAP認証も組み込まれていないですし、いろいろな要件に合わないのは前節のとおりです。

企業での利用にはProxy認証の機能を参考に、Apache + null_authentication_handlerよりはましな仕組みの構築を検討してみるべきだろうと思います。

Proxy認証に代わる仕組みとは…!?

いわゆるCGIでいうところのREMOTE_USER変数を利用して、/_users/org.couchdb.user:$REMOTE_USERからRoleを自動的に設定する仕組みがあれば、ApacheやNginxをSSL、認証のプロキシーとして使えそうな気がします。

実際にはAuthorizationヘッダ行をどうにかするんでしょうけど、試してみる価値はありそうです。

erlangでプログラミングしたことはないけど、自分にできるものか試してみることにしましょう。