1. ホーム
  2. のらマネージャーのブログ
  3. セキュリティよしなし

セキュリティよしなし

プライベートとシークレット

2004年4月15日 12:00

前から、書こう書こうと思っていて、結局書きそびれているトピックを。
プライベートとシークレットの違いについてだ。
案外日本語で理解しようとすると、個人に関する秘密(シークレット)がプライベートで、シークレットの一形態なような感じで理解しがちである。で、かく言う私もそう思っていたクチである。
なので、情報セキュリティ業界で言うところの「プライベートキー」を何の疑いもなく「秘密カギ」と翻訳していた。じつは、ここに大きな間違いがあったりするのである。
シークレットキーだってプライベートキーだって他人には分からないようにするんだし、おんなじ「秘密」で良いじゃんと、言いたいところですが、ISO/IEC 11770-3によると、実は全く違うものなんですね。
原文は英語なのですが、私がいんちき意訳してキーの定義のところだけ紹介します。

プライベートキー:非対称キーの対のうち「対象者のみが利用できる」キーのこと
シークレットキー:「特定された対象の集合が利用できる」キーのこと

となっているんですね。言いかえると、情報セキュリティの世界に限って言えば、「プライベートとは全く他者に公開されないもの」であり「シークレットとは特定されている相手には公開されるもの」ということなんですね。
でも、そうすると、本当の意味でのプライベート情報って何なんでしょうね。いわゆる住民基本台帳ネットワークに記載されるような情報も、シークレットな情報であっても、プライベートとは言い難いですよね。だって、名前だって住所だって電話番号だって、最低限、親や友達など特定されている人は少なくとも知っているんですし。
借金の履歴だって病歴だって、受け答えした社員は知っているし、受け持った医者も知っている。秘密の度合いは高くして欲しいけど、純粋なプライベート情報とは言い難いですよね。
情報セキュリティのセンスを磨くのに、自分の持っている情報をこういう視点で一度整理してみると良いかもしれませんね。

量子暗号を正しく理解しよう

2004年3月15日 12:00

実は量子暗号ってほとんど関心が無かったのですが、知っているライターさんが某雑誌にて、量子暗号の原理を紹介する時に「観測する時に系が変化するという不確定性原理」を使った手法であると書いていたんで、すごく気になってしまって思わず調べてしまいました。

それ自体はすごく面白い手法で、量子力学の業界では古くから論じられた「EPRのパラドックス」とか「ベル不等式」といったものが想定した系の状態を活用して、耐タンパー性を高くするという方法です。

何か、良く分からない複雑な計算をして、機密性を高めていると思ったのですが、基本的には盗聴の早期検出にそのポイントがあるんですね。

なんで、それ程気になったかというと、科哲の部屋のほうで解説している通り、不確定性原理は観測における系の攪拌とか系の変化とは無縁な原理なんですね。こんな嘘を雑誌が書いちゃいかんぞと思ったわけですが、なんと、日本の有名大企業がこぞってそういう嘘を書いてあるのでまたビックリ。

実際のところ、観測における系の変化とかに関しては、むしろ解釈上の問題の色合いが強く、ボルンルールとか射影公準といったものを付加することで処理をすることになります。

ちなみに、もとに記事の内容は量子暗号で長距離の実験に日本の企業が成功しましたって話しで非常に喜ばしいのですが、結局、量子暗号を自分で生み出したわけではなくて、ただのキャッチアップに過ぎないんだなぁということを、こういう基本の無知ぶりで証明していたりするわけです。SFチックな量子情報学の専門用語に躍らされているようじゃ意味なしですね。(用語自体はきちんと定義されていることですので、定義にさかのぼれば問題はないのですが)

今の暗号技術でも、既に欧米に支配されているのに、また量子暗号の時代にも、これまた欧米に支配されちゃうこと請け合いですね。科学技術立国で産学連携とかいっているけど、こういう基礎的な知見をおろそかにしているようでは駄目ですね。

参考までに
科学哲学の部屋
EPRのパラドックス
ベル不等式
不確定性関係

セキュリティー実戦~プレゼントサイト3~

2004年2月15日 12:00

前回からえらい間が開いてしまいましたが、検証と運用です。

8.運用手順を考える

検証なのになぜ運用といわれそうですが、運用作業も検証対象なので 運用手順を決めなきゃならない。
今回は小さい話しなので、運用といってもそんな豪勢な話しじゃなくて、次の事を決めます。
a.サイトからメールが来て、プレゼントを発送するまでの一連の作業
b.トラブル発生時のサイトの対応
c.ごめんなさいメールを書く時の基準
d.上記を実践するための日常的なチェック項目とチェックサイクル

これは、簡単で
a.メールが来る→プリントアウト→伝票に転記→プレゼント準備→宅急便を呼ぶ→配送→メール破棄、紙は保管
b.トラブルを定義。公にダメージがあるもの
 荒らしとシステムダウン
  プレゼント目当ての荒らし→一時停止→一行掲示板で告知(別サーバーに用意)
  システムダウン→関連システム内に告知→一行掲示板に告知
c.基準を定義。私的に迷惑をかけたもの
 個人情報の漏洩、配送取り違い、配送忘れ
  メールテンプレートを事前作製
d.チェック項目
  bに対して。
  プレゼント数のチェック、投票数のチェック
  cに対して。
  アクセスのログ、配送履歴、プレゼント在庫数チェック
  ここで、注意する必要があるのは6の個人情報の取り扱い範囲を逸脱しないチェック内容であることが重要です。基本的に運用ははじめのポリシー段階に依存すべきだからです。各種個人情報もチェックするのであれば、ポリシーにさかのぼりそこから検討する必要が出てきます。

9.実施前に検証しよう

検証手順はいたってシンプル。実行前の検証と実行後の検証に別れます。
実行前の検証のポイントは、起こりうることを可能な限り想像する。という事になります。

さて、それぞれの場合でこの実装で大丈夫かを考えましょう

可用性が破られる。
・システムがダウンする。→運用でカバー。8.b.をチェック。
・DDOS攻撃を食らう=システムダウンと考える→運用でカバー。8.b.をチェック。
・コードのバグ=システムダウンと考える→運用でカバー。8.b.をチェック。
一応大丈夫そう。

機密性が破られる。
・ハッキングによる個人情報の取得→サーバー内には残らない。5をチェック。
・ハッキングによるメールアドレスの取得→運用でカバー。8.c.をチェック。
こんなもんぐらいでしょう。おそらく大丈夫。

完全性が破られる。
・個人情報の入力間違え→対策なし
・プレゼントの配送間違え→運用でカバー。8.c.をチェック。
・プレゼント在庫不足→運用でカバー。8.c.をチェック。8.d.で事前防止。
これもこんなものでしょう。入力間違えは防ぎようなしですね。

一応、ポリシーにそってはほぼ完璧そう。 これでいったん実施しましょう。
と、その前に。

10.チェックしよう

運用の中に、チェックする項目をきちんと加えましょう。

メールが来る→プリントアウト→伝票に転記→プレゼント準備→宅急便を呼ぶ→配送→メール破棄、紙は保管

となってましたが、サイトの運用と合わせて

a.メールが来る→プリントアウト→伝票に転記→プレゼント準備→宅急便を呼ぶ→配送→メール破棄、紙は保管→サイトを更新→チェック→はじめに戻る

というサイクルをしていきましょう。でも、何をチェックする必要があるでしょう?
各ステップで、必要な情報を保護していることをチェックすれば良いのです。

1.メールのチェック。
基本情報がちゃんと入っているかを確かめる。

2.プリントアウト
基本情報がきちんと入っているかを確認する。
メールのプリントミスがないかを確認する。

3.転記作業
書き間違えがないかを確認する。

4.プレゼント準備
在庫を確認する。送り先とプレゼントが一致していることを確認する。

5.宅急便を呼ぶ
配送手渡しを確実に行い、配送履歴をとる。

6.メールの破棄、紙は保管
配送履歴、プレゼント在庫を照らし合わせミスの無いことを確認してから破棄する。
つづりに正しく、紙をつづる。できれば鍵付きの棚にしまう。

7.チェック
日々、サイト上の必要な情報を取得する。
ログ、プレゼント数、投票数。グラフ化等を行い解析しやすく保管する。
1~6のステップに作業チェックに抜けが無いかを確認する。

日々の運用の中で、こうしたチェック作業を行っていきます。
対処不能な事態が発生した時点で、はじめに立ち返り、再度検討していきます。
こういう地味な運用のチェック作業は何よりも重要な記録になっていきます。

ぜひ、個人情報等を取り扱われるサイトを運営されているのであれば 最低限このぐらいの検討を行われてはいかがでしょうか?

セキュリティー実戦~プレゼントサイト2~

2004年1月15日 12:00

前回は具体的な情報の区分けを行いました。
その区分けに応じて具体的にキャンペーンサイトに反映しなければなりません。
そうしないと、個人情報が特定URLをたたくだけで丸見えというサイトが出来上がることになります。

お金が無いんで、知恵と工夫でその辺を乗り切っていきましょう。

5.情報提供の段階を設ける。

暗号化だの特殊な認証だのということより、そもそも不要な情報は取らない という姿勢がもっとも重要です。
情報の段階を設けて、それを具体的に投票の段階としました。

step1. メールアドレス+マガジン購読希望+投票ストーリー

まず、第一段階でもっとも可用性が重要なメールアドレスを取りWeb上の データベースに登録します。本来は、購読希望や投票情報も分離すべきですが、ここは、投票作業の利便性を敢えてとり一緒に登録作業をさせます。

step2. 名前+住所+郵便番号+電話番号

次にプレゼントを表示し、それが「欲しい人のみ」これらの情報を入力してもらいます。入力すると、後はスルーでメールCGIにより私にメールがきます。Webサーバーには情報を残しません。
SSL等は入ってませんが成りすましがし難いように、メール送信CGIにも工夫をして第3者に情報を取られ難いようにしてはいます。
ただ、実は、ちょっと失敗と思っていることがあります。
宅配で贈るプレゼントでは「電話番号」が必要で、そうでないプレゼントには必要が無いんですよね。プレゼントのデータを作る時にそういう工夫をしておけば良かったと思っています。

6.情報を誠実に取り扱う。

各種の情報の取り扱い方について、それぞれわかりやすく記載することもまた重要です。

通り一辺倒な個人情報の保護についての記載では、ユーザーは信用しません。
そして、こちらが頑張っても怒りうるリスクについては、事前に記載して 理解してもらう必要があります。

後は、ちゃんと情報を入力する場面で「入力する理由」と「そのリスク」を明記すること、情報をその約束に従って適切に取り扱うことです。
ですので、
・メールマガジン購読希望の方のメールアドレスに対してのみ、 メールマガジン登録作業を行う。
・住所名前を送ってくれた方には、プレゼントの送付をきちんと行う。
そして、きちんと情報の破棄を約束通り行うことが重要です。

7.まとめ

ちなみに、取った情報は
A:メールアドレス、マガジンの希望、投票ストーリーID
B:名前、住所、電話番号、郵便番号、感想
です。
AとBでは、可用性と機密性に差があります。
本当は、完全性についても差をつけたいのですがそれを行うコストと それのためのメリットが少ないので、あまり手を加えていません。
Aは機密性(中)、可用性(中)、完全性(小)
Bは機密性(大)、可用性(小)、完全性(小)
と考えています。

当然、機密性から来るデメリット、可用性から来るデメリットとそれぞれのメリットを自分なりに数値化し判断することが、個人情報を取り扱うサイトを作る上で最も重要でしょう。
どこにでもあるアンケートCGIを単純に使うのではなく、これからはこういう考え方でアンケートサイトを作る必要が生まれてきています。イッショクタに個人情報と考えるのではなく、一つ一つの情報を預かるということを真摯に考えることが原点ともいえます。

では、次回は検証方法と運用の実際を考えていきましょう。

セキュリティー実戦~プレゼントサイト1~

2003年12月15日 12:00

さて、住基ネットなるもののおかげで、セキュリティビジネスがまた大盛り上がり。それのコンサルティングでご飯を食べている私としては嬉しい限りです。とくに、ウィルスブームより技術からセキュリティマネジメントに目が向いてきているんで嬉しい悲鳴です。
でも、具体的に何をどうすればセキュリティを確保できて個人情報を保護できるのかって話しは案外少なかったりします。
小さなプレゼントキャンペーンサイトの事例で、具体的な個人情報の収集と、その取り扱い方を考えていきましょう。具体的には、今自分でやっている投票+プレゼントキャンペーンを参考に紹介しましょう。まずは試しに一票入れてみて下さい。

1.キャンペーンの運用に必要な情報を考えよう。

まずは、キャンペーンの運用に必要な情報を考えましょう。
当然、プレゼントキャンペーンなのですからプレゼントの送付に必要な情報が必要です。
「住所」、「名前」は当然として郵送するためには、その他に「郵便番号」があると望ましいですし、宅配であれば「電話番号」が必要な場合が多いです。
2重投票防止のための情報もあるといいですよね。
あと、当然こちらとしては今後も継続的に情報を提供したいので、それに関する情報も欲しいと思います。で、それはメールアドレスにしましょう。

2.どの情報が何に必要なのかを考える。

「住所」「名前」「郵便番号」「電話番号」
は、基本的にはプレゼントの送付の時のみ必要な情報です。
そして、「メールアドレス」は、2重投票防止と希望者へのメールマガジン配布処理のために必要な情報です。

3.情報の可用性を考える。

基本として、どの情報もユーザーの許可なく第3者に公表しないなんてのは大前提。これが公表されていたら、信用が落ちてしまうのでサイト運営者の私の今後のビジネスに大きな影響が出ます。
すると、この手のサイトの場合、機密性から情報のランクを区切っていくのは難しい。だとすれば、まずは完全性と可用性で考える。
すると、投票したその場で、2重投票であるかをチェックしたいので、「可用性」という点でWeb上で即時必要なのはメールアドレス。それ以外の情報についてはネット上に蓄積する必要は皆無である。
この可用性を維持することは、2重投票を防止して大量のプレゼント配布による損害を防止する効果があります。また、キャンペーンの投票結果の情報の客観性を保持する上でも必要だと判断。
WebDBを構築しその中にメールアドレス情報と購読希望のメールマガジン情報をアップした。その情報は私だけが知っているIDとパスワードで保護。

4.情報の完全性を考える。

情報の完全性というのが要求されるのが、住所、名前、郵便番号、電話番号である。この情報が不完全であると、ユーザーに希望するプレゼントが届かない恐れがあるうえに、こちらも送料が無駄になるという損害がありえる。
この情報については可用性はそれほどではないので、原則としてWeb上に情報を置かないようにし、メールでのみ私のPCに届くようにする。
この完全性を維持したところで、損害は一件、80円から300円程度と判断して機密性が下がる「確認画面」の導入は行わないことにした。
メールで届いた情報はプリントアウトし、PC上から情報を削除する。送付作業完了後、同プリントアウト用紙はシュレッダーで破棄。

これにより、機密性と可用性のみで情報種別分けをすることにした。

まずは、これで個人情報を分解し情報に対する基本的な取り扱いを決めました。
次回は具体的な実装を紹介します。

アイリンクへのお問い合わせ

お問い合わせメールフォームはこちら

2016年12月移転 北海道旭川市神楽1条7丁目4−8 お問合わせはメール・SNSアカウントで mail
  • twitter
  • facebook
  • google
  • noimage
  • noimage
  • noimage