はじめて作った顧客管理システム
わたしがはじめて、顧客管理のシステムを構築したのは１９９９年です。間近に迫るＹ２Ｋ問題（西暦２０００年に世界中のシステムが障害を起こし、パニックになるかもしれない問題）を抱えた緊張のときでした。
きっかけは、当時、在籍していた会社が、ある香水会社の販売代理店の契約を締結したことです。わたしは、顧客からのネット注文に応えるため、簡単なWebサイトと、注文フォームを作りました。注文情報は、sendmailコマンドにより、受注担当者が電子メールとして受付します。担当者がメールで確認した注文内容をアクセスで作った受注画面に登録します。アクセスDBには、商品、顧客などのマスタテーブルと、受注、出荷のトランザクションテーブルを関連付け、出荷情報は経理がエクセルで確認できるよう、ODBC接続をしました。
これは、突貫工事で作った仕組みです。このとき、情報セキュリティを意識したアプリケーションとはなっていませんでした。
複数の担当者が使うことから、IDとパスワードによる認証機能を用意しました。ただ、パスワードは平文でユーザーテーブルに記録していました。DBへのアクセス権さえあれば、誰でもパスワードが分かってしまいます。
後回しのセキュリティ対策
当時、多くの会社が顧客情報を管理するシステムを作りました。ただ、総じてシステムを構築する際の情報セキュリティに配慮する意識は低かったはずです。
JPCERTコーディネーションセンター（JPCERT/CC）という組織があります。ここは、インターネットを介して発生する侵入やサービス妨害等のセキュリティインシデントについて、国内のインシデント等の報告を受け付け、対応の支援、発生状況の把握、手口の分析、再発防止のための対策の検討や助言を、技術的な立場から行なっている組織です。
JPCERT/CCのホームページを見ると「国内でホームページからの顧客情報漏えいが頻発するインシデント」が２０００年にはじまったことが記録されています。１９９０年代に粗製乱造された顧客管理システムの脆弱性が攻撃されたと考えられます。
会社がインターネットビジネスをスタートさせるとき、第一にビジネスができるアプリケーションを作ることに注力します。その次に利用者の使い勝手を向上させるような仕組みを作ります。情報セキュリティ対策の検討は、後回しにされがちです。攻撃者にとってはそこがねらい目なのです。
パスワードはハッシュ化する
パスワードは平文で保管するのではなく、ハッシュ化するべきです。
ハッシュ化とは、任意の長さのメッセージやファイルなどの入力値を固定長の出力値に変換することです。
たとえば、123456という数字６桁の単純なパスワードと、SG7DY4wDというやや複雑な英数小文字混在の８桁パスワードをSHA1という１６０ビットでハッシュ化すると次のようになります。
- （パスワード）123456：（SHA1）E10ADC3949BA59ABBE56E057F20F883E
- （パスワード）SG7DY4wD：（SHA1）A214294F8C715113890EFD3211D31174264834F4
元のメッセージが単純でも、ちょっと複雑でも、ハッシュ値は固定の長さです。かつ、ハッシュ化された値から元のメッセージを求めることは困難です。これがハッシュ関数の特性のひとつ「一方向性」です。
- パスワード123456から、E10ADC3949BA59ABBE56E057F20F883Eは、簡単に求められる（SHA1によるハッシュ化）。
- E10ADC3949BA59ABBE56E057F20F883Eからパスワード123456を求めるのは困難。
ハッシュ関数には、一方向性の性質があるので、ハッシュ化されたパスワードをテーブルに格納することは、セキュリティ対策上、有効に作用します。
なお、暗号技術の適切な実装法・運用法を調査・検討するCTYPTRECでは、SHA1によるハッシュ化は安全性が低下していることから、よく使われるMD5と共に非推奨しています。CTYPTRECは次のハッシュ関数を推奨しています。
- SHA-256（256ビット）
- SHA-384（384ビット）
- SHA-512（512ビット）
安全なハッシュ関数を求める考え方として、誕生日攻撃による探索が使われます。誕生日攻撃（ブルートフォース攻撃の一種）は、メッセージの総数が２N のとき、２N/2個のメッセージを集めると同じメッセージが存在する確率が高いという考え方に基づいています。SHA1は１６０ビットですので、誕生日攻撃によるメッセージ総数は、２80です。SHA256であれば２128となります。
