アクセスコントロールと認証システム

認証システム

 認証のプロセスは識別、認証、権限管理に分けられる。
 これらをアクセスコントロールと総称する。

 どのユーザーがアクセスしているか見るのが識別。
 そのユーザーが本人かどうかを確認するのが認証。
 認証されたユーザーに何を許可し何を許可しないか決めるのが権限管理。

パスワード認証

クリアテキスト

 パスワードを平分でやり取りする。盗聴されたら終わり。
 当初ローカルでの認証のために設計されているのでネットワーク上で利用するにはあまりセキュアではない。
 POP3などに実装されている。

チャレンジレスポンス

 クリアテキストの脆弱性を解消したモデル。
 まず、クライアントがユーザーIDをサーバーに送信。
 つづいてサーバーからチャレンジコードが返信される。
 クライアントはパスワードとチャレンジコードからハッシュ値を生成。これを送信する。
 実装技術としてはCHAPがある。

ワンタイムパスワード

 ログインごとにパスワードを変更する方式。
 仮にパスワードが漏洩してもそれは使い捨てゆえに不正利用されない。

S/KEY

 チャレンジレスポンス方式の応用。UNIXにて実装されている。
 前出の要素に加えてシーケンス番号を利用しており、その回数だけシード(チャレンジコード)とパスフレーズからハッシュ処理をしてワンタイムパスワードを作る。
 通信ごとにシーケンス番号が減るため、ゼロになるたびにパスフレーズの変更が要求され、よりセキュアなシステムとなっている。
 とはいえパスフレーズが漏洩すれば当分危険にさらされるので注意が必要。

時刻同期方式

 チャレンジコードではなく時刻をトリガーとする。
 クライアントはトークンにより時刻からパスワードを生成する。トークンはUSBキーなどのハードウェアやノードにインストールされたソフトウェアが利用される。
 パスワードが生成されたら、個人番号(PIN)とともにサーバーに送信して認証が行われる。情報は時刻とPINのみを材料とするため盗聴された場合もリスクが最小限に抑えられるのが特徴。ただし、時刻の同期が取れていないと機能しないのが弱点。

 さらに安全性を高めるため、PINもトリガーとしてパスワードに組み込む場合がある。
 もちろんこれもトークンが盗まれれば全て終わりだが、そんな状況では何をしても無駄であり、そういうあほな状況を避けることこそセキュリティ対策なのではないかと思う。
 (鍵をかけた。鍵を取られた。盗みに入られた。やばい鍵だけでは危険だ。・・・なんてね)

パスワードの運用

 パスワード認証ではどんな形であれ、システムのどこかしらに漏れてはまずい認証情報が存在することになる。
 ゆえにパスワードの管理は保安上きわめて重要となる。

認証が突破される例

 ・ユーザーの不注意でパスワード漏洩。
 ・推測されやすいパスワードがブルートフォースなどで破られる。
 ・ソーシャルハックによりパスワードが盗用される。

パスワード作成・管理要件

 まず第一に重要なのはパスワードが十分に複雑で第三者に類推されないことである。
 銀行の暗証番号を誕生日にするなという奴と同じ論理で、より高度なルールを設定する必要がある。
 また、一度作っておしまいではなくそれを各自が適切に管理する事も重要。

作成・管理要件の具体例

 自身の個人情報そのままはダメ
 十分に長く、辞書にある単語をそのまま使わない
 定期的に変更する
 他人に漏らさない
 紙に書いてモニタに張るなど容易に漏洩するような行為をしない
 
ただし、これらをあまり厳格に規定しすぎると利便性を欠くため注意が必要。
また、管理規定も各組織の特性に合わせる必要がある。
従来悪とされてきたパスワードのメモも、(それを厳重に管理するのであれば)長く複雑なパスワードを使うことを促進できるのでナイス!というような見方だってある。

ユーザーIDの管理

 パスワードほど厳重な管理はなされないが、ユーザーIDも適切な管理が必要な項目である。
 特に、既に組織からいなくなったユーザーのIDを放置することは危険。
 リストラリーマンが自分のアカウント使って云々といえば想像できるであろう。
 
 また、ユーザーIDもある程度特定されにくいものにするとよりセキュアになる。
 もっとも例によって利便性との相談ではあるが。
 (ただ少なくとも管理者のIDはなるべく予想されにくいものが望ましい。rootとかは良くないね。)