真正性をつつく8（最終回） - 今までのおさらいと総括

　この記事は、真正性をつつく7の続きです。前回は、セキュリティテストについて解説しました。今回は、今まで解説してきた事をおさらいします。
　7回にわたり認証について解説してきました。しかしながら、セキュリティを考慮したシステムを作った経験がある人しかピンとこないかもしれません。そこで、自称・営業部長山田太郎（もちろん仮名）の例を元におさらいする事にしました。

【会社のホールにて】
謎の男「済みません。ちょっとよろしいですか？」
掃除婦「はい。」
謎の男「研究開発室に用があるのですが、ご案内頂けますか？」
掃除婦「申し訳ございません。当社では案内は受付係を必ず通す事になっております。
　　　　受付ならば案内する事が出来ますが、如何でしょうか？」
謎の男「いえ、結構です。受付の場所ならば知っています。」
掃除婦「分かりました。」

【会社の裏口】
裏口を勝手に通過しようとする謎の男
警備員「お待ちください。」
謎の男「何ですか？私は社長の許可を得ているのですが・・・」
警備員「お手数をおかけしますが、当社はセキュリティ上の都合で、
　　　　　たとえ社長であろうと裏口は通れない事になっております。」
謎の男「なんだと！では、何のために裏口があるのですか？」
警備員「裏口は火災・地震時等の緊急避難のための通路です。
　　　　　誠に申し訳ございませんが、受付で正規の手順を踏んで下さい。」
謎の男「そんな事はきいていない。今度からそうするが、
　　　　　今回は緊急の用事なのでこちらを通過させてもらうよ。」
警備員「連絡に不備があった事はお詫びいたします。
　　　　　ですが、お客様や関係者の皆様からお預かりしている貴重な情報があります。
　　　　　皆さまにご迷惑をおかけしないために、
　　　　　当方はセキュリティ対策をしなくてはなりません。」
謎の男「そう、堅い事はいうな。社長とは長い付き合いがある。」
警備員「常日頃お世話になっております。関係者の方ならば、
　　　　　当社がセキュリティ対策の実施を、
　　　　　半年前から何度も通知しておりますので、よくご存知だと思います。」
謎の男「そういえば、そんなこと言っていましたね。
　　　　　これは失礼しました。既に実施しているとは知らなかったもので・・・」
警備員「お気になさらないでください。ご不便をおかけします。」
謎の男「分かりました。受付に行きます。」

むむ、怪しい人が会社にやってきました。色々な事を言っていますね。でも、認証対象となるオブジェクトが、どんな事を言ってもルートを一本化するために、必ず規定の場所に誘導せねばなりません。その為には、あらゆる人に徹底してセキュリティ教育をせねばなりません。ただし、極力相手に不快感を与えないように努力する必要があります。その辺の教育も必ずしましょう。セキュリティ対策は教育が命です。

　引き続き、謎の男の動向を見てみましょう。

【受付にて】
謎の男「ちょっと、済みません。研究開発室に行きたいのですが・・・」
受付嬢「はい、研究開発室への入室ですね。お名前を伺ってもよろしいでしょうか？」
謎の男「別にかまいませんが、何故名前を聞くのですか？」
受付嬢「入室には許可が必要となっておりますので、
      お名前を教えて頂かない事にはお通し出来ません。」
謎の男「分かりました。山田です。」
受付嬢「どちらの山田様でしょうか？」
謎の男「○○商事の営業部長山田太郎です。」
受付嬢「有難うございます。只今、アポを確認いたしますので、5分ほどお待ち下さい。」
山田太郎「緊急の用件なのでアポはとっていません。」
受付嬢「ご安心ください。
　　　　　当社のシステムは全ての取引および関係者が記録されていますので、
　　　　　お名前でチェックできます。5分ほどお待ちください。」

セキュリティ対策にはストレスがつきものです。ですから、ただ闇雲に拒否をするのではなく、相手の便宜を図るシステムの機能も作らねばなりません。この場合訪問者に、セキュリティ対策をしない時と比べて、アポ無しでも何とかなるという利点があります。訪問者を全て追い返す会社には誰も来なくなります。セキュリティ対策が会社の利益を損なわないように十分に注意しましょう。

　今度はセキュリティ実施側の視点を書きます。

受付嬢（　こんな時は、訪問者管理ソフトでチェックするのよね？
　　　　　　えっと、山田太郎で検索・・・あれ？超～ビックリ、山田太郎氏が何人もいるわ。
　　　　　　こんな時は絞らないと・・・うーん、○○商事で絞り込んでも2人居るわ。
　　　　　　2人の顔を知っている人を呼ぶ必要があるわね。
　　　　　　連絡先は、研究開発室の真田さんね。電話しないと・・・）
受付嬢「もしもし、真田さん。今ロビーに○○商事の営業部長太郎さんが来ています。　　　
      アポなしですし、開発部にも同姓同名の人がいますので、認証お願いできますか？」
真田「分かりました。でも、ちょっとおかしいな。
　　　今のところ、山田部長が来る要件なんてないな。
　　　ロビーに警備員も呼んでもらえるかな。」
受付嬢「分かりました。警備員を呼びますので、今から2分後にロビーに来て下さい。」
真田「了解しました。ところで要件は？」
受付嬢「済みません。要件は緊急としか仰っていません。」
真田「緊急？？？分かりました。その件も含めてチェックします。」

セキュリティでは色々な事を考えなくてはなりません。この場合、山田太郎氏は本当に本人なのでしょうか？なり済ましの恐れがあります。また、たとえ本人でも怨恨による犯行も考えられますので、用心に越した事はありません。そうした連絡体制を取るのもセキュリティ対策の一環です。

　では、その結果を見てみましょう。

【警備員が見廻りをするロビーにて】
真田「山田部長。お待たせしました。」
山田太郎「おお、お久し振り真田君。」
真田「お世話になっています。あれ？営業部長の方だと伺っておりましたが・・・」
開発部長山田「済まん。嘘だ。」
真田「なぜ、その様な事を・・・」
開発部長山田「うちが作ったシステムが上手く動作しているか気になってな。」
真田「お気づかい有難うございます。
　　　　セキュリティ対策についてどう思われましたか？」
開発部長山田「まだ、たどたどしいな。それと、全般的に甘いな。」
真田「と、いいますと？」
開発部長山田「今この場で君を刺しても、この距離では警備員は間に合わないだろう。
　　　　　　　　　自分で言うのもなんだが、こんな怪しい男、もっと警戒してもいいと思うぞ。」
真田「そこまでは考えていませんでした。面目ないです。」
開発部長山田「うむ。それと、君は本当に真田なのか？」
真田「御冗談を。本物ですよ。」
開発部長山田「今さっき、ロビーに入る時、何のセキュリティチェックもしていなかったな。」
真田「ええ。出勤時に認証チェックをしていますから。」
開発部長山田「内部セキュリティが甘いな。それだと、一回突破されたらおしまいだ。
　　　　　　　　　認証は多重チェックが基本だと前にも言っただろ。」
真田「ええ、仰るとおりです。」
開発部長山田「それに、そもそも○○商事というのも嘘だった場合どうするつもりだ。」
真田「そこまでは考えておりませんでした。どうしたよいものやら・・・」
開発部長山田「まだまだだな。当社が最近開発した認証セットがあれば解決するぞ。」
真田「相変わらず商売上手ですね。」

この基本的な例（面白くなるように味付けてしています）を見れば分かって頂けると思いますが、セキュリティ対策は考えるべき事が沢山あります。また、絶対に完璧な状態になる事はありません。それに加えて、真正性は情報セキュリティの一部でしかありません。真正性単独ではセキュリティホールがあり過ぎます。他の性質と共に考えねばなりません。
　他にも色々解説するべき事がありますが、あまり長すぎると退屈だと思いますので一旦終わりにします。また近いうちに解説しますのでちょっとだけご期待下さい。

真正性をつつく7 - クラッキング方法を考えよう

　この記事は、真正性をつつく6の続きです。前回は、認証オブジェクトについて解説しました。今回は、次の段階であるセキュリティテストについて解説します。
　今回までいくつかの段階を踏んできましたが、それでもまだ不十分です。仕上げとして、セキュリティテストを行う必要があります。その一環として有効なのは、クラッカーとして考える事です。人は自身が行った対策について甘く評価する性質があります。そこで、クラッカーになったつもりで考えなくてはならないのです。
　クラッキング技法としては、システムに対する攻撃はもちろんの事、人間の盲点を突くソーシャルエンジニアリングの手法も視野に入れます。実際のところ、セキュリティホールとなる確率は、コンピューターよりも人間の方が高いです。人間は錯覚する生き物であり、騙されやすい精神構造をしています。セキュリティテストと呼ぶと、プログラミングの方を思い浮かべがちですが、人間は騙されやすいという重大なセキュリティホールを見逃しては真の意味でセキュリティ対策にはなりません。
　何故人間は騙されやすいのかと言いますと、人間は五感から送られてくる情報を脳の処理で補完しているからです。従って、マジックの様な視覚的トリックや、詐欺師たちが使う言葉による誤認識が可能となってしまいます。一説によると特に日本人は騙されやすい精神構造をしているそうです。それは、馬鹿という訳ではなく、人が良いのが原因です。人が良い事は生存に於いて有効に働きます。親切さが求められるビジネスの世界では特にそうです。しかしながら、クラッカーたちはその親切心を利用します。親切に振舞う事によりクラッカーは、クラッキングする為の情報を取得し、クラック行為を成功させてしまいます。
　では、全てを疑えば良いのかというと、そうではありません。ビジネスをしている以上、全ての人間を疑い人でなしになるという手段はあり得ません。セキュリティと言うと、「全てを拒否すればいい」、「そもそもネットワークに接続するな」、「全ての人を追い返せ」などと極論を言う人がいますが、それではビジネスが成り立ちません。また、疑えば疑うほど、詐欺師は騙しやすいそうです。全てを拒否するのはただの暴論であり、セキュリティとは呼べません。セキュリティ対策とは、如何にしてシステムを安全に利用するかを考える技術体系であり、使わないというのは前提から間違っています。
　セキュリティテストは、プログラミング方面とソーシャルエンジニアリングの手法を使って、予告せず不規則に実施するのがベストです。良くある間違いは、セキュリティテストの日程を教えてしまって、普段とは違う行動を社員にさせてしまう事です。普段は面倒だと思ってしていないセキュリティ対策も、その日だけ正しく行うという可能性があります。これでは意味がありません。
　クラック方法を考え、実際にテストしてみる事により、セキュリティホールを発見と修正が出来ます。セキュリティ対策は考えておしまいとなるケースが多いのですが、実際の役に立たなければ意味がありません。考えて安心するのではなく、常に危険意識を持ってバージョンアップしていきましょう。ただし、セキュリティと利便性のバランス感覚を忘れないようにして下さい。セキュリティは強固にすればするほど、不親切で利便性が下がります。ビジネスをしているのですから、お客様や従業員といった人の事を忘れてはなりません。セキュリティ以前に、使えないシステムは意味がありません。その点を決して忘れてはなりません。

真正性をつつく6 - 認証オブジェクトを考えよう

　この記事は、真正性をつつく5の続きです。前回は、アクセスポイントの決定について解説しました。今回は、認証オブジェクトについて解説します。
　アクセスポイントには、必ず認証オブジェクトが必要となります。例えば、受付には受付嬢が必要ですし、研究室の扉には認証端末が必要です。セキュリティ対策を行う際には、それら認証オブジェクトを熟考しなくてはなりません。具体的には、認証内容、認証行動、認証に必要なデータの3点を考えます。つまり、誰が何をどの様に何をもって認証するのかよく考えます。
　認証内容、認証行動、認証に必要なデータは関連しています。認証する内容に基づき、どの様に認証するべきなのかが決まりますし、認証を行う際に必要なデータもそれで決まります。真正性の場合、何がどれだけ保障されているのかが認証内容に該当します。これから原則を述べます。
　原則其の一、認証に必要なデータは認証側から絶対に漏らさない。認証に必要なデータが漏れると、それだけなりすましが容易になります。これはオレオレ詐欺を思い浮かべると良く分かると思います。犯人「オレオレ」、被害者「健二かい？」、犯人「そうそうオレ健二だよ」。この様に認証に必要なデータを漏らすと、不適切なオブジェクトが認証をパスしてしまいます。これは意外と忘れがちなので十分に注意しましょう。
　原則其の二、認証に必要なデータは最小限にする。認証するオブジェクトに対して、不必要にデータを開示してしまうと、そこからクラックされる可能性が高くなります。権限に応じたデータを持たせましょう。
　原則其の三、アクセス経路を集約化します。この原則は他の原則と密接に関係しています。認証オブジェクトに最低限のデータしか渡さないと、自ずと十分な認証が出来なくなります。そこで、より権限の高い認証オブジェクトを知らせておき、認証対象となるオブジェクトがそこに集まるようにします。そうすれば、権限と責任が明確化し、人間の意識も集中できます。その結果、効果的なセキュリティ対策が行えるようになります。アクセスパターンが複雑化すると、それだけセキュリティ上の弱点が多くなりますのでこれは非常に重要です。
　原則其の四、情報資産の価値に比例させる。保護対象となる情報資産の価値が高ければ、それだけ厳重に保護しなくてはなりません。価値が低い情報を厳重に補語してもコストが高くつくだけです。情報セキュリティに割り当てられる予算と労力は有限です。重要な情報に予算と労力を割り当てられる様に注意しましょう。
　原則其の五、定期的に確認しましょう。どれだけ厳重にセキュリティ対策を行っても必ず穴がありますし、時間とともにクラッキング技術も向上します。セキュリティ対策は一度考えたらお終いではありません。あくまでもスタート地点に過ぎません。また、安全だと人は安心し、セキュリティ意識が低くなっていきますので、定期的にセキュリティ対策を見直し、セキュリティ教育も行う必要があります。
　細かい事を言えばきりがありませんが、ひとまずこの5つの原則をおさえましょう。そうすれば、ある程度有効なセキュリティシステムになります。情報資産の重要性は高まっています。今後、情報資産の重要性は減らないでしょうから、これからの時代これぐらいは押えておく必要があります。続く...

真正性をつつく5 - アクセスポイントを決定しよう

　この記事は、真正性をつつく4の続きです。前回は、アクセス経路の特定について解説しました。今回は、アクセスポイントの決定について解説します。
　アクセス経路を考えると、非常に多くの組み合わせがある事に気付くと思います。ですが、真正性は経路の組み合わせで判定しません。この点に注意が必要です。分かり難いと思いますので例を挙げます。
　自称・営業部長山田太郎氏が受付で「俺は社長の許可を得てここにきている。早く通せ！」と言いだしたとします。この場合、受付嬢はそのまま通すべきなのでしょうか？答えは否です。たとえそれが本当であったとしても、誰かが認証しているのだから大丈夫だと考えるのは早計です。何故ならば、嘘の場合は真正性をチェックしていない状態になってしまうからです。この場合、受付嬢は理由に関わらず真正性をチェックするべきです。
　では、どこで真正性をチェックするのでしょうか？それを考えるのが、今回解説するアクセスポイントの決定作業です。アクセス経路には複数の組み合わせが考えられますが、認証をするオブジェクトは自ずと決まります。例えば、ガードマン、受付嬢、指紋認証端末などです。これらの認証オブジェクトを、どの様なアクセス経路を通ろうとも真正性をチェックできるように配置します。この配置した場所がアクセスポイントとなります。アクセスポイントは多ければ多いほど真正性が高くなりますが、それに比例して真正性をチェックされる側のストレスが増加します。また、アクセスポイントの増加に伴いコストも増加します。従って、保護対象となる情報資産の価値に見合ったアクセスポイントを設定するべきです。
　アクセスポイントを設定したら、アクセス経路と照らし合わして、真正性のチェック漏れがないか慎重に確認しましょう。クラッカーは一番弱い場所を選びます。真正性を逃れるルートがあるのならば、絶対にそこからクラック（情報資産の破壊／窃盗などの犯罪行為）されると考えましょう。クラッカーは自分よりも賢いと考えて、セキュリティ対策を練りましょう。

真正性をつつく4 - アクセス経路の特定をしよう

　この記事は、真正性をつつく3の続きです。前回は、デジタルの認証技術について解説しました。今回は、次の手順であるアクセス経路の特定について解説します。
　おさらいします。真正性を保証するシステムを設計するには、対象となるオブジェクトを明確化し、認証技術の決定を行います。次にするべき手順は、アクセス経路の特定です。真正性を保証するオブジェクトを定め、対象に使用する認証技術を決定しても、アクセス経路を特定しない内には役に立ちません。何故ならば、人の認証とデジタルなオブジェクトの認証は違うように、対象となるオブジェクトによって認証方法が異なるからです。ちょっと分かり難いので、毎度おなじみの例を使用して解説します。
　営業部長山田太郎（仮名）が、直接会社を訪問する事もあれば、会社のシステムへアクセスしてくる場合もあります。この2つの状況を考えると、受付嬢などの人間が対応する場合と、サーバーが対処する場合がある事が分かります。人間と機械の対応は自ずと違いますので、アクセス経路ごとに対象（プロセスなど）と認証手段を考える必要があります。また、会社訪問の場合も、掃除婦の方が話しかけられる場合もあります。さらには、受付嬢の場合も契約状況（派遣、正社員、アルバイト、パート）により権限と責任が違いますので、取りうる認証手段が異なります。こうした状況も考えなくては、真正性を保証するシステムを提供できません。
　ここで一つの疑問が浮かぶ人がいるかと思います。「何故、アクセス経路の特定を先に考えないのか」。その疑問については、セキュリティレベルをあげるためです。認証技術は日々進歩しています。過去につくったシステムの認証技術をそのまま使うのではなく、現在の認証技術を検討しなくてはなりません。先にアクセス経路を決めてしまうと、先入観により「前に採用した認証技術をそのまま使用しよう」という流れが起きてしまいます。システムを作る人の中にも保守的な人が多く、既存の知識の範囲だけで物事を判断してしまう人が沢山います。そうした人達がシステムの選択肢を減らしてしまうと、既存の技術の弱点を知り尽くしたクラッカーの餌食になります。セキュリティを考慮したシステム開発とは、ただ単にセキュリティ技術を採用する事ではなく、開発工程で起こる人間の盲点にも対処するという事なのです。
　アクセス経路は、物理的な物と論理的な物（システムと非システム）の2種類あります。物理的なアクセス経路は、会社の構造に対する経路（情報システム外の経路）です。論理的なアクセス経路は、システムにログインすると言った非物理的な情報システム内の経路の事です。直感的に分かりやすいように、論理的／物理的と表現しましたが、物理的アクセス経路と言っても、建物内だけのルートではなく、電話でアクセスしてくるなどといった経路もあり得るので注意しましょう。また、論理的アクセス（情報システムでのアクセス）内にも、ネットワーク外からアクセスされる場合と、ネットワーク内からアクセスされる場合などといった複数のパターンがありえます。こうした細かな事まで考える事がセキュリティ対策では必要です。
　

真正性をつつく3 - デジタルの認証技術もあるよ

　この記事は、真正性をつつく2の続きです。前回は、識別子と認証方法について解説しました。今回はその続きで、デジタル系の認証技術について解説します。
　前回は主に対人的な認証技術（本人認証）でした。しかしながら、オブジェクトは常に人だとは限りません。PCのプロセスなどと言ったデジタルなものもありえます。例えば、営業部長山田太郎氏が、会社のシステムにログインしてきた場合、デジタル系の認証技術を使用する必要があります。
　デジタル系の認証技術も発想としては同じなのですが、デジタルなオブジェクトが相手なので詳細が違います。具体的には、時間認証・デジタル署名・認証サーバーを用いて同時の認証をする方式などがあります。これらを順に解説していきます。
　時間認証は、その名の通り時間を用いた認証方式です。代表例がワンタイムパスワードです。パスワードをネットワーク越しに送ると、傍聴されてしまう危険性が常にあります。一度盗聴されてしまうと、なりすましが様に行われてしまいますので、これはなんとしても避けなくてはなりません。そこで、パスワードをある一定の時間だけ有効にする方式が考えだされました。
　ワンタイムパスワードの方式は色々ありますが、主な方式は時刻同期方式とチャレンジレスポンス方式の2つです。時刻同期方式は簡単に言うと、クライアントがトークンと呼ばれるワンタイムパスワードを生成する為の装置を使用して、入力された暗号と時刻を元に、その都度パスワードを生成して使用する方式です。そして、チャレンジレスポンス形式は、認証サーバーとクライアントの双方が、ユーザIDとそれに対応した各種情報（シーケンス番号、シード、前回使用したパスワード）をやり取りして認証する方式です。一見両方式とも完璧に見えるでしょうが、クライアントから送る情報が盗聴されると破られる恐れがあるので注意が必要です。
　デジタル認証方式は電子署名を使用して認証する方式です。この方式は、公開鍵暗号方式を利用します。具体的には、送信者は送信データをハッシュ関数で圧縮し、送信者だけが持つ秘密鍵で暗号化し、データと署名されたデータを相手へと送ります。受信者は、受信データをハッシュ関数で圧縮しダイジェストメッセージを作ります。それと同時に、署名入りデータを送信者の公開鍵で複合します。その両者が一致すれば、ある特定の送信者が送った正しいデータだと看做せます。
　デジタル認証方式は、信頼できる第三者の存在が前提となります。何故ならば、公開鍵の所有者が保障されなければ、悪意を持った偽名を名乗る人物かもしれないからです。犯罪者が一定期間の犯罪をもくろみ、鍵を公開しているかもしれません。また、認証を行う機関がクラッキングされたらお終いです。従って、認証局が信頼できなければ意味がなくなってしまうのです。
　それに加えて、鍵をどうやって配送するのかという問題があります。鍵そのものが盗まれれば、容易に他人になり済ます事が出来てしまいます。鍵をどの様にして送るのか、また認証局がどの様にして本人を特定し、その身分を保障するのか、認証局の信頼性をどのように判定するのかといった色々な課題があります。完璧な方式は存在しないのです。
　そういった既存の認証方式の問題を解決するべく、自前で認証サーバーを用意し、独自の認証方式を提供することもあり得ます。ただし、その独自の方式が他の方式に比べて安全だとは必ずしも言い切れません。独自認証だと言っても、クラッカーはインターネットに流れるデータを分析したり、ソーシャルエンジニアリングのテクニックを使用したりして、認証方式を特定する事が可能です。認証方式が分かれば、悪意ある人は必ずクラックする方法を思いつきます。つまり、どの様な認証方式を使用してもいつかクラックされると思った方が賢明です。
　多要素認証を採用し、定期的に認証方法を見直しましょう。

真正性をつつく2 - 識別子と認証方法の決定

　この記事は、真正性をつつく1の続きです。前回は、真正性が保証するオブジェクトとは何かについて解説しました。今回は、識別子と認証方法について解説します。
　真正性を考慮したシステムを作るためには、対象の決定後に識別子と認証方法を考える必要があります。人や情報が本当に正しいのかを判断するには、名乗っているオブジェクトの等価性を判定します。ですが、無闇にその人の等価性を判断する事は出来ません。何らかの識別子が必要となります。毎度おなじみの例を元にその事について考えてみましょう。
　目の前にいる営業部長山田太郎と名乗る人物は、本当に営業部長の山田太郎氏なのでしょうか？言動だけでそれを判定する事は出来ません。それだと余りもいい加減であり、確認する人が口車に乗ってしまえばお終いです。営業部長の山田太郎氏だと確認を持てる動かぬ証拠が必要です。そうした認証に関する問題に対処するため、人類はいくつかの認証方法を考え出しました。
　認証技術は常に進化しているので、その全てを知っているわけではありません。私が知る限り認証方法は、記憶認証、所持認証、属性認証があります。情報システムは、それらの認証方法を用いて真正性を確保します。これから個々の認証方法を解説します。
　最も一般的なのが記憶認証です。そのオブジェクトしか知りえない情報を記憶していたら、そのオブジェクトだとみなします。これを読んでいる人は、殆どの人がOSを立ち上げる時に、パスワードを入力しています。これをパスワード認証と呼びます。パスワード認証は実施に殆どコストがかからないので、多くの場面で採用されていますが、認証方法としては弱い部類に入ります。何故ならば、その人の生年月日や有名な単語などの単純なパスワードならば他人でも容易に推測できますし、パスワードを書いた紙を読めばお終いです。この様に記憶認証は色々な弱点がありますが、何時でも変えられるという長所を持っています。重要なので、記憶認証の長所と短所をぜひ覚えておきましょう。
　所持認証とは、特定の持ち物を所持しているオブジェクトを、そのオブジェクトだとみなす認証方法です。例えば、キャッシュカード、ICカード、スマートカードなどがあげられます。所持認証は色々な工夫が出来るものの、識別子となる物が他人に奪われると破られますし、偽装などの方法で突破する事もありえます。所有物の紛失についてよく注意しましょう。
　属性認証とは、本人の生体情報を照合して認証する方法です。生体情報は虹彩（アイリス）、指紋、DNA、静脈、声紋・・・など色々あります。生体情報は極めて信頼できるデータですが、風邪をひいて声が変わり、本人でも認証されないなどといった本人拒否の問題があります。それに加えて、人工的に指を作って指紋認証を突破するなどの手口も考えだされており、必ずしも完璧だとは言えない状態です。なお、生体情報は漏れてはならないプライベートなデータです。生体情報は厳重に管理しましょう。
　以上のように、全ての認証方法には弱点が存在します。従って、どれか一つだけを採用するのではなく、複数の認証方法を組み合わせる多要素認証が一般的です。実務的なシステムは必ず複数の認証方法を採用しましょう。

真正性をつつく1 - 真正性の対象を見極めよう

　この記事は、真正性をつつく0の続きです。前回は、真正性を保証することのむずかしさを書きました。今回は、真正性が保証するオブジェクトとは何かについて解説します。
　前回、真正性とは「情報を要求するオブジェクトが本当に主張通りのオブジェクトなのかを保証する特性」だと書きました。オブジェクトだと書いてある点に注目して下さい。オブジェクトと考える事が重要です。何故ならば、真正性と言うと多くの人は人間を思い浮かべますが、保証するべき対象は人だけに限らないからです。人が発する言葉の内容も対象となります。その他にも、プロセスなどといったプログラム的なものも対象となります。
　前回提示した、営業部長の山田太郎（仮名）が緊急の用件で来ているケースを元に考えてみましょう。真正性の対象となるオブジェクトを大別すると、営業部長の山田太郎と、要求している内容である緊急の用件です。この人は本当に営業部長の山田太郎なのでしょうか？緊急の用件とは何なのでしょうか？順を追って考えていきましょう。
　先ず問題となるのは、山田太郎という人物が存在するか否かです。犯行をもくろむ人物が、適当な偽名を使っている可能性があります。山田太郎氏が存在するのか否かをどうやって知るのでしょうか？オブジェクトの存在を確認する方法を考えなくてはなりません。
　次に考えるべき事は、営業部長としての山田太郎氏が存在するか否かです。情報部長の山田太郎氏が存在するものの、営業部では存在しないかもしれません。また、営業部に山田太郎氏が存在しても、部長でないかもしれません。他にも、同姓同名の人物が存在する場合もあります。こうした色々な可能性を視野に入れなければなりません。
　最後の「緊急の要件」と言うオブジェクトについては、より慎重に考える必要があります。何故ならば、これは複合オブジェクトだからです。要件そのものと、緊急の用件に対する行動を伴っています。緊急の要件というオブジェクトと、それに伴い求めている行動というオブジェクトを見極める必要があるのです。さらに要件の内容によっては、さらなるオブジェクトがそこに含まれています。
　以上のように、真正性は対象を見極める事が大切です。対象をはっきりさせないと、保障されていないオブジェクトを許可してしまうかもしれません。クラッキングもしくは詐欺の手口は、その多くが対象そのものを誤魔化す事から始まっています。おれおれ詐欺が格好の例でしょう。息子が存在するにしても、電話越しに存在する彼が本当に息子なのかという事をはっきりさせずに、彼の言う言葉を信じてしまうと大変な目に遭います。
　今回は、真正性の第1段階である「対象の識別」について解説しました。次回は次の段階を解説します。

真正性をつつく0 - 真正性を保証するのは意外と難しい

　連載（システム開発における情報セキュリティ）の方で細かい事を書くと読み難いと思ったので、個別に情報セキュリティネタを書きます。今回のお題は「真正性」です。真正性を簡潔に言うと、情報を要求するオブジェクトが本当に主張通りのオブジェクトなのかを保証する特性です。真正性を保証する為の行動の例としては、本人確認などがあげられます。文章にすると簡単そうに見えますが、システムを開発する方も運営する方も大変です。
　たとえばその人が営業部長の山田太郎（仮名）を名乗っているとします。この人は本当に営業部長の山田太郎なのでしょうか？多くの人は「車の免許証を見せてもらえばいい」と思うでしょうが、免許証が偽造されたものかどうか見抜けるでしょうか？また、「車の免許証を持っていないが緊急の用件なんだ。ちんたらしないで早く通したまえ。もし、君のせいでなにかあったら責任を取れるのか！」と一喝されればどうしますか？
　こうした簡単な例でもセキュリティ対策は大変です。山田太郎部長が本当に免許証を持っていなければどうやって認証するのでしょうか？認証するにしても本当に緊急かつ重要な要件ならばどうしますか？詳細な手順を作ってもバイトの人が面倒を避けて通してしまうかもしれません。特に他社の部長である場合、どうやって認証しますか？・・・真正性を真面目に考えると、簡単な例でも色々考えなくてはならない事が分かってもらえると思います。
　今度は情報システムらしい例を考えます。社内の端末からアクセスする人が、本当にその人なのかをどうやって認証しますか？社内の端末からアクセスされていても安心できません。その端末を使っている人が、本当にその端末を使うべき人なのかわからないからです。他人が端末の持ち主に罪をかぶせるために、なりすましているかもしれません。
　この2つの事例から分かる事は、人間だけがチェックしても駄目（人間は騙される）、コンピュータだけが判断しても駄目（抽象的な事が苦手）だという事です。人と情報システムの連携でようやく真正性を保証できます。ただし、100％の真正性は不可能だという事を忘れてはなりません。どの様な技術でもそれを破る方法を犯罪者は見つけ出します。また、完璧にしようとするとコストがかかり過ぎますし、厳重すぎる情報セキュリティは仕事に支障を及ぼします。
　以上のように真正性を保証するのは大変な事です。この連載では真正性について書きます。

システム開発における情報セキュリティ14

　この記事は、システム開発における情報セキュリティ13の続きです。前回は、セキュリティポリシーについて解説しました。今回は、セキュリティ技術の学び方について解説します。
　連載を通じてシステム開発で情報セキュリティをどう取り扱うべきなのかを、駆け足で解説してきました。今までの記事を読めば、情報セキュリティは、情報技術全般はもちろんのこと人間心理にまで及ぶ、非常に範囲が広いものである事が分かって頂けると思います。
　この範囲が広い情報セキュリティを、どの様に学ぶのか気になる方が多いと思います。そこで今回は、連載の締めとして情報セキュリティの学習方法について書きます。
　残念ながら、情報セキュリティの学習方法にも銀の弾丸は存在しません。一応情報セキュリティという分野は存在しますが、結局のところOS・コンパイラ・ネットワーク・データベースといった情報技術に関する知識全般と、人間心理と行動を深く広く学ばなければなりません。かくいう私も、情報セキュリティを意識して学んだわけではなく、情報技術全般を学び、仕事を通じ実践と分析を続けているだけです。
　健全な好奇心があれば自ずと情報技術全般を深く学びますし、仕事をしていれば組織や人間心理が分かってきます。技術者として人生経験を積むしかないと言えます。ですから何よりも大切なのは、小手先だけの方法論ではなく、心の持ち方だと言えます。
　この世に当たり前な事や絶対に保障されているものは存在せず、あらゆる知識を学び、それら知識の裏を読む姿勢が大事です。その知識は、所詮人間が使うものであり、人間は不完全な生き物である事実を受け入れれば、自ずとクラッカーの手口が分かり、その対策方法も考えつきます。
　すなわち、あらゆる知識を吸収しつつ、絶対的な真実や完璧なものは存在しないという前提の下、常に知識の裏を読み、人間の弱みを受け入れ、その理論の不完全さと弱みを如何にカバーするのかを日常的に考え続けるのが、情報セキュリティの学び方だという事です。
　この連載はひとまずこれで終わりです。ですが、情報セキュリティは語るべき事が無限にあります。たとえば、セキュリティポリシー１つとっても1冊の本が書けます。また、人が人である限り、あらゆるシステムに虚弱性があります。情報セキュリティは人間にとって永遠の課題なのです。
　機会があれば、セキュリティポリシーなどの1つの題材に特化した記事をかきます。終わり。