徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。スライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃することを防ぎようがない、という前提を置いているからです。逆の言い方をすると、攻撃者がアプリケーションサーバに侵入したとしてもユーザーの認証情報にアクセスできなければ、認証情報を奪われる可能性はないわけです。そのようなシステムを構築するにはどのようにしたらいいでしょうか。一般的なウェブアプリケーションにおける答えは、ストアドプロシージャの利用とデータベースサーバの保護にあります注1。多くのSQLデータベースサーバはストアドプロシージャとストアドファンクションをサポートしており、これはMySQLやPostgreSQLといったオープンソースRDBMSでも例外ではありません。ストアドプロシージャやストアドファンクションには二つの役割があり、ひとつは処理手順をまとめること、もうひとつは、テーブルへのアクセスパターンを限定することです。MySQLの場合、以下のようなDDLを実行することで、一般ユーザー権限(webapp)からは読み書きできない認証情報カラムpasssalt(ソルト値を格納)とpasshash(ハッシュ値を格納)をもつuserテーブルを作ると同時に、パスワードの一致を確認するストアドファンクション(check_pw)を提供することができます。webapp@'webapp-host';実際に、このデータベースに一般ユーザー権限で接続してみると、以下のように、ユーザーの作成はできるものの認証情報は読めない一方で、パスワードの検証は可能、となっていることがわかります。sec)このように、SQLデータベース内にパスワードの検証/更新ロジックを持たせることで、(データベースに一般ユーザー権限でアクセスするための情報が保存された)ウェブアプリケーションサーバに攻撃者の侵入を許した場合でも、パスワードの漏洩を防ぐことができます。ストアドプロシージャで監査ログを出力することで、攻撃を検知したり被害範囲を特定したりといったことも可能になるでしょう。このような手法を実践するにあたっては、@isidaiさんの指摘をあわせて参照の上、各自の責任において設計、実装くださいますようお願いいたします)■■データベースサーバの保護SQLデータベースの機能を利用してパスワードを保護する場合に考えなければならないこととして、ウェブアプリケーションサーバが攻撃者の手に落ちた場合に、そこを踏み台としてデータベースサーバに侵入されるリスクを下げるにはどうすれば良いか、という点があります。答えは単純で、データベースサーバをウェブアプリケーションサーバとは別のネットワークセグメントに配置し、両者の間にファイアウォールを設置すれば良い注2、ということになります。ファイアウォールの役割は、ウェブアプリケーションサーバからデータベースサーバへのアクセスを正規のTCPポートを指定するもの以外、全て遮断することです注3。このように設定することで、データベースサーバの権限管理機能にバグがない限り、ウェブアプリケーションサーバを踏み台として認証情報を奪われる可能性はなくなります。言うまでもありませんが、データベースサーバを配置するネットワークセグメントをインターネットと直接接続してはいけません。理想的には、アクセス手段を厳密に規定して管理系セグメントからのみ接続可能とすべきでしょう。■■まとめユーザーのパスワードを適切に暗号化することは重要ですが(そのまとめとして徳丸さんのスライドは優れていると思います)、サーバへの侵入を前提としてアーキテクチャを設計する際には、多層防御の手法が有効になります。本稿では、RDBMSサーバのストアドプロシージャとファイアウォールの使用を通じて、ユーザーの認証情報を多層防御するウェブアプリケーションが簡単に構成できることを説明しました。実は、本稿で取り上げた問題とその解は、Unixにおいてシャドウパスワードが導入された経緯の変奏曲です。Unixのシャドウパスワードとは、誰もが閲覧可能なファイル(/etc/passwd)に一方向暗号化(ハッシュ化)されたパスワードを記載しておくのではなく、攻撃者(一般ユーザー)がアクセスし得ないファイル(/etc/shadow)に認証情報を配置し、認証が必要な場合はAPIを通してルート権限で動作するプロセスに問い合わせ、/etc/shadowの内容と比較した結果を回答してもらう、という仕組みです。いった成功した大規模なソフトウェア製品を思い浮かべることでしょう。実は、ウェブ上でサービスを提供する会社のエンジニアたちは、これらとは別の種類のOSSを使って仕事をしています。このブログエントリでは、そのようなOSSを紹介し、それらがなぜ開発され使われているかを説明したいと思います。記述される大規模ウェブアプリケーションの一般的な構成を示しています注1。このうち、「自社ロジック」と書かれているところ以外は、全てオープンソースとして開発/公開されているモジュール(ソフトウェア部品)です。各社のエンジニアが密接に協力しながら、ミドルウェアをオープンソースとして整備していることがわかるかと思います注2。このような部品開発における会社を超えた協力体制は、Perl以外のプログラミング言語を使っているウェブ企業でも良く見られるものです。そのような協力がなされるのでしょうか。「そのようなエンジニア文化だから」というのもひとつの答えかと思います。彼らが業務の一環として開発したミドルウェアをオープンソースとして公開している以上、文化を裏打ちする経済的合理性を考えないわけにはいきません。ウェブ業界は、主にコンテンツをユーザーに配信する企業群として成長してきました。これらの企業におけるコアコンピタンスとは、コンテンツ(あるいはコンテンツを提供してくれるユーザー)です。このため、ソフトウェア自身を金の卵だと考えるソフトウェア業と異なり、ウェブ業界では、ソフトウェアはコンテンツを配信するための手段だという位置づけをされることが多々あります。ソフトウェアが売上をあげるための手段である以上、その開発/運用コストを削減することが重要になります注3。種々多様なコンテンツにあわせて迅速にソフトウェアインフラを整備し安価に運用するためには、カスタム開発を最小限に抑える必要があります。社外への発注や人材の流動、ビジネス規模の変化を考慮した場合、ソフトウェアスタック全体を内製し社内で維持改善を続けるよりも、業界全体のデファクトスタンダードとなる実装が自社の都合にあった形で存在することが望ましいと言うことができます。図で示したソフトウェア構成は、この経済的な要求が反映された結果なのです。Furlを見てみましょう。2010年に開発が開始されたFurlは、LINEに勤務するエンジニアがメンテナンス権をもっている高速かつカスタマイズが容易なHTTPクライアントであり、サーバの必要台数がコストに響くような大規模サービスで好んで使われています。一方で、その開発には、当初からDeNAに所属するエンジニアが参加しており、同社の影響も大きいものがあります。その顕著な例が、DeNAの要件にあわせて追加された、DNSリゾルバの置換機能です。一般的な使用形態において必要ない機能というのは、第三者が、たとえ必要なコードを書いて追加をお願いしたとしても、なかなか受け入れてもらえるものではありません。それは、機能の追加をいったん受け入れてしまうと、以後その機能をメンテナンスしていく責務が主開発者の肩にかかるからです。かかわらず、Furlに同機能が追加されたのは、両社のエンジニアが継続的に共同作業を行っており(Furlが、DeNAのエンジニアがメンテナンスしているHTTPパーサライブラリを使っていることを含みます)既に信頼関係が構築されていたという事情を勘案する必要があるでしょう。このように、継続的にオープンソースのミドルウェア開発に参加することでコストを分担しつつ、自社にとって便利なものにしていく、という営みが実際に行われているのです。■OSS共同開発のリスク評価では、経済的な合理性はあったとして、部品を共同開発することによるリスクはないのでしょうか。ある質問は「ある会社の社員が、ライバル社に害をなすような機能を組み込んだりしないのですか」というものです。ウェブ企業のエンジニアたちによるオープンソース開発では、この点についても抑止力が働く構造になっています。本稿で例に挙げたOSSはいずれも、誰がどの機能を書いたか、コミットログを追うことで全て把握できるようになっています。エンジニアのコミュニティにおけるコードの品質に対する最初の評価基準は、どの会社のエンジニアが書いたか、ではなく、誰が書いたか、という点です注4。この条件下において、悪意のあるコードをOSSに埋め込むことは、エンジニアにとってキャリアの終わりを意味します。そのような行為に手を染めたエンジニアは、以後就職先を見つけることはできないでしょう。終身雇用が期待できる業種なら、それでも悪行を働くインセンティブがあるかもしれませんが、ウェブ業界は転職を前提としたキャリアプランを立てざるをえないところです。このように、職業倫理のみならず経済的側面からも、共同開発によるリスクは抑えられていると言うことができます。実際には、コードが多くの目にさらされることによる品質向上効果の方が大きいと考えるべきでしょう。■まとめ以上、述べてきたように、ウェブ企業におけるオープンソース開発は、サポート収益を期待するソフトウェア企業のオープンソース注5とは大きく異なる原理に基づいて活発な開発が行われている分野です。コンシューマには見えない小粒なソフトウェアが多いがゆえに見落とされがちな分野ですが、オープンソースソフトウェアに関する議論や検討を行う際には、これらの活動とその背景についても理解しておくことが望ましいかと思います。主要なモジュールと本稿に登場するものを中心に抜粋して図示しています。