さくらインターネット創業日記

先日、「Web屋のネタ帳」というブログから、「さくらインターネットの会員メニュー画面のセッション情報はログアウトしても1年たっても消えない件」という旨のトラックバックがありました。
それによると、「クッキーを保存しておくと、１年後でもログインできる」といった内容で、クッキーを保存する人なんておるんかいなと思いつつも、実際に保存していた人が居たことに、少し興味が惹かれました。
ただ、指摘されている内容については、実際と異なることも多く、当該ブログの管理者様にはコメントだけお送りしたのですが、特に返事の無いまま、飛び火をして憶測だけが流れ続けていることに少し憂慮しており、ここで解説させて頂くことにしました。

ちなみに、「考え」の部分は、私個人の考えですので、その点はお含みおきください。

まず初めに、当該ブログにおいて指摘されている点を以下の２点に要約します。

• セッション管理をする際にはログアウト時にセッション破棄を行わなければならない


• ログインからしばらくたった後（１年後）もそのまま利用できるのは、良くない

１点目は技術的な指摘であり、会員メニューがセッション管理を行っていたならば、当然ログアウト時にセッション破棄を行わなければならないというのは、書いているとおりです。この部分のみを切り取ってみれば、間違いありません。
しかし、会員メニューに当てはめてみると、これには重大な間違いがあります。
それは何かというと、会員メニューではセッション管理をしていないということです。なので、セッションを破棄するという動作がそもそもありません。
つまり、問題点その１と、問題点その２は、会員メニューには当てはまりませんので、ご安心ください。

２点目はポリシー的な指摘であり、考えが分かれるところです。
ただ、管理者の方が指摘されている、「ログインしてから１年以上もたった後に解約できるのは問題」という部分は間違っており、実際にはログイン後に一定時間が過ぎると、パスワードの再確認がなされます。また、住所変更や、クレジットカードの表示・変更の場合にも、同様の処理が行われます。
すなわち、問題点その３についても、会員メニューには当てはまりません。
（後ほど、管理者によって修正されています。ありがとうございます）
もちろん、サーバ設定については一定期間経過後にできないようにすればとの意見もあると思いますが、逆に不便になる点もあり「考えが分かれる」と表記させて頂きました。

ところで、セッション管理というキーワードが出てきましたので、ユーザ認証が必要なサイトに関して、すこし解説をさせていただく事にします。
まず、ユーザ認証が必要なサイトに関して、以下に代表的な３種類をあげさせていただきました。

1. セッションで管理する

ユーザ名とパスワードはログインを行う場合のみデータベースへ確認し、その後はサーバとブラウザがセッションＩＤと呼ばれるランダムに生成された文字列を共有して、認証行います。
比較的多く利用されている手法で、今回ご指摘頂いた管理者の方の意見も、これをベースとされています。
たとえるならば、カード表面にランダムに振られた番号の書かれた印鑑登録カードと同じようなものです。最初に免許書等で本人確認を行い、それ以降はカード番号の記された印鑑登録カードを持っていくだけで印鑑登録証明書が発行されるのに似てるでしょう。
2. その都度ユーザ名とパスワードを送る

その都度、ユーザ名とパスワードをサーバに送付し、毎回データベースに確認します。これは古典的な方法で、ブラウザのダイアログボックスにユーザ名とパスワードを入力する手法が多く見られます。
たとえるならば、キャッシュカードのようなもので、毎回暗証番号を入れることに似ています。
3. ハッシュを利用する

ユーザ名とパスワードをログイン時のみに行うのはセッション管理に良く似ていますが、サーバに何らかのＩＤを残すことはしません。手法としては、サーバ側でサーバ暗号とユーザ名をハッシュ化しクライアントに知らせ、アクセスする際にはハッシュとユーザ名をサーバに通知します。サーバ側はサーバ暗号とユーザ名を再度ハッシュ化し、通知されたハッシュ値と比較して認証を行います。
その都度ユーザ名とパスワードを送る仕組みと異なり、パスワードは最初のみに限定して安全性を高めると共に、毎回データベースに確認する手間を省けます。

以上が、それぞれの解説です。
他にも、さまざまな方法がありますが、今回は３つだけの紹介とさせていただきます。
以下が、それぞれの特徴などをまとめた表です。

なお、詳しく書くことはできませんが、会員メニューの認証は３番目の「ハッシュを利用する」に近いものを採用しています。その為、セッション管理が無く、当該ブログで指摘しているようなセッション削除に関する問題は理論上発生しないということは、上記のとおりです。
この仕組みを採用した背景としては、会員メニューのページ毎に有効期限を指定したいということと、実際のサーバは複数に分かれておりセッションの管理が煩雑になることとの２点からです。このおかげで、クレジットカードは高頻度に、サービス一覧は低頻度にパスワードを再確認する仕組みを構築できています。さらに、会員メニュー、コントロールパネル、オンラインサインアップ、ＤＮＳゾーン編集、ドメインコンパネ等、さまざまなシステムへシングルサインオン可能な環境が構築できました。

ちなみに、この仕組みの危険な点として記した暗号の漏洩や詐称を防ぐべく、公開鍵暗号を利用した暗号化での実装を行っており、認証サーバ以外、会員メニューやレンタルサーバコントロールパネルを含めて、全てのサーバにおいて秘密鍵が含まれておらず、それらのサーバでクッキーの偽造はできません。
さらに、クッキーの中には会員ＩＤと発行日時、キーのインデックス以外の情報はほとんど入っておらず、当然のことながらパスワードなどの機密情報は全くありません。

ところで、高木浩光氏の指摘はとても的を射ており感心する限りですが、キーの有効性についてはキーのインデックス情報により対処ができるようになっており、古いキーの失効をさせることも可能です。
すなわち、時間情報とキーインデックスを公開鍵暗号によって詐称できない裏づけの元にクッキーを生成し、失効したキーインデックスのシリアル番号を登録しておくことにより、古いクッキーの無力化が図れるようになっています。

なお、唯一当社で考えなければならないこととしては、ページ毎の有効期限を再考することかと思っています。
例えば、レンタルサーバのコントロールパネルには、かなりの長時間にわたってクッキーの失効を抑制していますが、１ヶ月毎にパスワード再確認の必要性があるのかもしれません。
このあたりについては、皆様のお知恵をお借りしつつ、ポリシーの再検討をさせて頂きたく思っております。

まとめ

1. 認証にセッション管理は利用しておらず、セッションを破棄する仕組みはそもそも存在しない


2. クッキー(SID)の有効期間はコントロールできる仕組みであり、ページ毎に個別の期限を設けている


3. クッキー(SID)を選択的に無効化できる仕組みがサーバ側に備わっている（失効情報）


4. クッキー(SID)には会員ＩＤとキーインデックス（シリアル）、発行時間などが含まれており、詐称防止のために公開鍵暗号を用いている


5. 現在の有効期限を今より短くしないといけないページがあるのかもしれない（コンパネ等）


6. ログアウトを押しつつクッキーを保存する人は通常はおらず、居たとしても前述のように有効期限管理で代用可能（クッキーを破棄するログアウト方法は一般的）

以上、長文を最後までごらん頂き、ありがとうございました。
また、当該ブログの管理者様には深く感謝いたします。

今後とも、さくらインターネットのサービスをよろしくお願いします。

追記1 4/28
当該ブログの管理者様によって記事が追加されていました。
http://neta.ywcafe.net/000731.html
大変丁寧にご対応いただき、ありがとうございます。
ちなみに、「公開してくださってもかまいません」については、特に他意はなく(笑)、ほかの方にメールを送った際に『ブログで公開しても言いか』と返信されることがたまにあるので、書いただけでした。私的には、「セッションではないらしい」ということと「パスワード確認があるらしい」ということが、ほかのかたがたに伝われば、特に問題は無く、結局このエントリーもあるので、見解の発表はすでに達成できたと思っています。
なお、新しい記事で書かれていた有効期限は、たいへん有用かと思うので、実現できればいいなと思います。SIDに含まれるキー自体は１日で失効させて、利用者の方があらかじめ設定した期間に限ってパスワードなしでキーを更新していくなどの方法も取れるかもしれません。

私が担当したインターネットウィークでのチュートリアルも、無事終了しました。
少し消化不良気味でしたが、たくさんの方にお越し頂き、大変嬉しく思います。
関係する方々には大変ご協力を頂き、ありがとうござました。

家には、MAC MINIとiBookあわせて2台のMACがあります。
そのMACの間でデータのやり取りを考えていたのですが、今回はLAN経由より高速なIEEE1394(FireWire)経由での接続を試してみました。

ちなみに、FireWire経由で接続するための方法は非常に簡単です。
まず2台のMACを用意し、ＩＥＥＥ1394のケーブルで接続します。この際、機種によって小型の６ピンの際と、大型の９ピンの場合がありますから間違えないように用意してください。
接続ができれば、外付けハードディスクとして認識させる事にします。外付けハードディスクとして認識させるには、キーボードの「T」キーを押しながら電源を入れ、画面にFireWireマークが出れば完了です。（外付けハードディスクとして認識されている間は、そのMACでいっさい作業はできません）
後は、他方のMACにおいてデスクトップ上にFireWireマーク付きのMacintosh HDが出てくるのを待つだけです。

肝心の転送速度ですが、ターミナル上で単純にデータ転送を行った結果、11062839 bytes/secと出ました。100Mbpsフルと同じくらいの速さなので、うちのしょぼい100M-HUBを介した接続とは雲泥の差です。
2台以上のMACをお持ちの方は、ぜひお試しあれ。

最近トラックバックスパムが、以前にもまして迷惑しています。
そのため、トラックバックのスクリプト名を修正していました。

というのも、どこぞのサイトで、URL決めうちでスパムを送信しているらしいとのことで、スクリプト名を修正すれば大丈夫なんじゃないかなということで。

具体的な方法は以下をご覧ください。

オラクルについてのメモ
最近、販売管理システムが遅いので、システム担当の協力を得ながらチューンナップなどしています。

その中で、いくつかをまとめました。

お客様より blogtimes をインストールできないとのことでサポートに問い合わせがきていたらしく、技術が調べていたのですが、そんなに難しいのかなということで、自分でインストールを試みました。

ということで、さくらのレンタルサーバライトで利用するblogtimesです。

1. ダウンロードとインストール

http://nilesh.org/mt/blogtimes/ よりダウンロードします。
私の場合は、ZIP版のアーカイブをダウンロードし、Windows端末にて展開して、FFFTPにてアップロードしました。 アップロード先は、/home/kunihirotanaka/www/mt/plugins でしたが、場合に応じてパスは変更が必要です。 ちなみに、さくらのレンタルサーバでは、標準で必要なモジュール等が入っており、特に変更の必要はありませんでした。
2. テンプレートの編集

Movabletype のテンプレートを編集します。
私は、以下のように書きました。
<MTBlogTimes width="150" height="20">
 <img src="<$MTBlogTimesFileURL$>" width="<$MTBlogTimesWidth$>"
  height="<$MTBlogTimesHeight$>"
  border="0" alt="B L O G T I M E S" title="B L O G T I M E S" />
</MTBlogTimes>

3. 再構築して完成

あとは、再構築をする事により、画像が入ります。
※注意点
• プラグインはCGIじゃないので、先頭行にスクリプトパスを書く必要はありません。
• imgタグにおいて直接blogtimes.plへのパスを書いてはいけません。
  マクロ「$MTBlogTimesFileURL」を利用します。
とりあえず、マニュアルどおりにやれば、さくらのレンタルサーバでは問題なくインストールができるようですので、参考にして下さい。

ゴールデンウィークなのに、することなく家でプログラミング。
会社で使うプログラムの新調に大忙しです。

最近は、社内の開発力もだいぶ上がってきて、以前より信頼できるようになりましたが、
何も無いところからの開発はまだまだ未完。
頑張って引き継いでいかなければなりませんねぇ。

東京出張から帰ってきました。

で、今回はネットワークの話。

うちの会社では、先月からコア部に10Gbpsのイーサーネットを導入しているわけですが、
周辺部に関しても10Gへのアップグレードをすべく検討をしております。

現在利用しているFoundry NetIron400に加えて、先日導入したForce10、
検証中の Procket や HitachiのGR4000 それに NetIron40G等々、
多数の個性をもったルータたち。
今日も、とある代理店が見積もりを持って、アピールしていってくれましたが、
値段が値段だけに、簡単には決断できません。
機器選定も大変なものです。

ちなみに、現在うちの東京第三データセンター（池袋）からKDDI大手町ビルまでは、
キャリア冗長を採った上で、10Gbps×2本の構成になっています。
半年くらいは、このままでもつでしょうかね・・・。