企業に認証サーバが必要な理由：RADIUSを使おう（1）

本連載ではRADIUSの概要をお話ししてみたい。初めにお断りしておくが、筆者はRADIUSのプログラムを提供する側の人間ではない。どちらかといえばプログラムを利用する側の人間である。それもあり、RADIUSそのものだけを深く掘り下げることはせず、認証を軸にお話できればと思う。

» 2004年12月04日 00時00分公開

[小林聡，ノーテル・ネットワークス]

個人認証の必要性と現実

　本連載では認証を軸にRADIUSを簡単に解説するのが目的だ。その前に個人認証が必要な理由と、そもそも認証とは何かといった少し哲学的な部分について掘り下げてみたい。なお、個人情報を含む情報管理（いわゆる情報セキュリティ）の分野は認証だけにとどまるのではない。当然、認証だけを強化したからといってセキュリティを完全に高めたことにはならないが、今回はこの辺りの詳細は割愛する。なお、以下の文章では個人認証を単に認証と省略する。

フレームワークとしてのAAA≫

　認証を語るうえで外せない概念としてAAAがある。Authentication Authorization Accountingのそれぞれの頭文字を取っている（最後のAはAccountingを含む形でのAdministrationとして扱う場合もある）。日本語では一般的に、下記の訳が当てられている。

Authentication−認証

Authorization−認可

Accounting−課金管理

　認証と認可の違いが日本語だと極めてあいまいなので、簡単に説明したい。

認証……資源にアクセスしようとしている人間が名乗っているとおりの人間かどうかを確認する（I&Aで後述）
認可……認証がパスしたとして、その人間に適切なアクセス権が与えられているかを確認する（アクセス権の限定で後述）となる
課金管理……いまの時代にそぐわない気もする単語であるが、古くからこの訳が当てられており、いまだにこの訳が使用されているようである。あえて現代風にアレンジすれば、「アクセスログ管理」とでもなるだろうか（アクセスログサンプルを参照）

　誰がいつ・どのくらいの時間アクセスしていたかのログは、インシデントが発生した（何か事件が起こった）際の事後確認のために必須である。

　また、そうではなくてもキャパシティプランニングは日常業務として必要であり、そのための指標にもなる。

Identification & Authentication

　認証で重要な概念をI&Aと称することが多い。これはIdentification & Authenticationの略である。Identificationは「名前を名乗ること」、Authenticationは「名乗った本人であることを証明すること」になる。よくよく考えてみるとこれと似た局面は現実世界でも随所にある。

　例えば、身分証明書の提示である。一般的に運転免許証が使用されるが、これは「氏名」および「顔写真」が一緒になっているので、個人認証手段としては強固な部類に属する。

　一方で、電話のような声だけの情報では個人識別があいまいになる。それもあり、いわゆる「オレオレ詐欺」がはびこることになる。これはAuthenticationを行っていないわけである。そういう意味ではIdentificationも不完全ではあるが……。

　この対処法として「自分の名前を名乗らせる」というのがあるが、Authenticationの観点からだけいえばいまひとつ心もとない。

　個人名はもとより、生年月日や住所などを調べられることは、いまのご時世そんなに難しいことではない。ましてやそれが流出した個人情報ならなおさらである。

　確実に本人しか知り得ないことを尋ねてみるしかない。Authenticationの本筋はここにある。誰でもが容易に知り得る公知の情報を持って（知って）いるからといって、それが本人であることの証拠にはなり得ないからである。

　コンピュータの世界では名前（ユーザー名）だけで個人認証することはない。必ず「ユーザー名」とペアになった「パスワード」（もしくはそれに相当するもの）が使用される（そのほかにも本人しか持っていない何か「具体的なモノ」を使用するケース、これらを組み合わせるケースなどがある）。

　この場合、「パスワード」とは本人しか知り得ない何か。である。これはユーザー名ごとにユニーク（一意）であり、これを他人に教えないという大前提でこのシステムが成り立っている。

I&Aが完全でないと何が起きるか？

　ここまで読んできた方で、I&Aを守ることがそれほど重要だろうかと疑問に思う方がいらっしゃるかもしれない。

　これが守られない場合に何が起きるかをお話ししよう。まだ記憶に新しいと思われるが、今年は個人情報の漏えい事件が頻発していた。その1つ、日本最大級の事件として記憶されている某社では捜査機関にアクセスログの提出を要求された。そこで明らかになったことはユーザー名・パスワードペアの共有であった。アクセスログは記録されていたものの、このログは本来の役に立つことはなかった。流出させた（であろう）特定の個人を特定できなかったのである。

　ここで気を付けなければいけないのは、「流出のきっかけとなった個人を特定できたからといって流出した個人情報が戻ってくるわけではない」という厳然たる事実である。

　だが、その「特定の個人を特定することができる」ということ自体が効果を持つことがあり得る。恐らく、その「特定の個人」はユーザー名・パスワードのペアを共有していることの事実を知ったうえで（つまり、自分に捜査の手が及ばないことを承知のうえで）犯行に及んだものと思われる。個人を特定できる仕組みがあり、それが突破不可能であったならば、この個人は容易に犯行に及ぶことはなかったであろうことは想像に難くない。

　この辺りの話を厳密化しないと認証を含むセキュリティというフレームワークは意図どおりに動いてくれないが、本稿の目的ではないので今回は割愛する。

アクセス権の限定

　スパイ映画などで主人公が上司に何かを尋ねると「君は知る必要がない」などとにべもなく断られるシーンを見たことはあるだろう。これは極めて前時代的な場面かもしれないが、情報へのアクセスという面から考えると極めて重要な概念であることが分かる。「知らないものは漏らし（聞き出し）ようがない」という厳然たる事実がそれである。

　また、アクセスできる対象を限定することにより、「出来心」による悪意を未然に防ぐ予防的効果も多少は期待できる。ユーザー名・パスワードのペアは個人に帰属させることが重要である。理由は個人特定だけではない。ユーザー名を確実に個人に帰属させることにより、その特定の個人に対しての情報アクセス権をコントロールできるようになるということである。

　先の某社の事例では、共有ユーザーのアクセス権は最高のものを与えていたらしい。つまり、誰でも全ユーザーの情報を取り放題だったということである。この後、（報道によれば）某社はアクセス権限を徹底的に見直し、どのユーザーに対しても一度にアクセスできる件数を制限したということになっている。

　そもそも、一度に全ユーザーのデータを必要とする局面などそうそうないわけであり、一度に1人分の情報さえ引き出せれば本来のユーザーサポート業務に支障を来すことはないであろう。このように、アクセス可能な対象を限定することにより、万が一ユーザー名・パスワードが推測された（もしくは何らかの理由で漏えいした）場合でも被害を最小限にとどめることが可能となる。

アクセスログの解析

　参考までにアクセスログレポートと基になったアクセスログを掲載する。

Wed Nov 24 15:40:09 2004
Timestamp = 1101278409
User-Name = "tg"
Acct-Status-Type = Start
NAS-IP-Address = 192.168.115.112
Acct-Delay-Time = 10
Acct-Session-Id = "000000FC"
Framed-IP-Address = 192.168.10.15
Acct-Authenticator = Verified
Record-Unique-Key = "2f99057041a42cc9000000FC" 
 
Wed Nov 24 15:43:11 2004
Timestamp = 1101278591
Acct-Status-Type = Start
Acct-Session-Id = "8861465018421051393"
User-Name = "user"
NAS-IP-Address = 192.168.116.125
Acct-Authenticator = Verified
Record-Unique-Key = "2f99067d41a42d7f8861465018421051393"
 
Wed Nov 24 15:52:28 2004
Timestamp = 1101279148
Acct-Status-Type = Stop
Acct-Session-Time = 557
Acct-Input-Octets = 65211
Acct-Output-Octets = 103900
Acct-Input-Packets = 1068
Acct-Output-Packets = 1082
Acct-Session-Id = "8861465018421051393"
Acct-Terminate-Cause = User-Request
User-Name = "user"
NAS-IP-Address = 192.168.116.125
Acct-Authenticator = Verified
Record-Unique-Key = "2f99067d41a42fac8861465018421051393"
 
Wed Nov 24 15:55:24 2004
Timestamp = 1101279324
User-Name = "tg"
Acct-Status-Type = Stop
NAS-IP-Address = 192.168.115.112
Acct-Delay-Time = 9
Acct-Session-Id = "000000FC"
Acct-Session-Time = 917
Acct-Input-Octets = 65611
Acct-Output-Octets = 103600
Acct-Input-Packets = 1018
Acct-Output-Packets = 1002
Framed-IP-Address = 192.168.10.15
Acct-Authenticator = Verified
Record-Unique-Key = "2f99057041a4305c000000FC"
 
Wed Nov 24 15:57:27 2004
Timestamp = 1101279447
User-Name = "koba"
Acct-Status-Type = Start
NAS-IP-Address = 192.168.115.112
Acct-Delay-Time = 5
Acct-Session-Id = "00000100"
Framed-IP-Address = 192.168.10.15
Acct-Authenticator = Verified
Record-Unique-Key = "2f99057041a430d700000100"
 
Wed Nov 24 16:12:57 2004
Timestamp = 1101280377
User-Name = "koba"
Acct-Status-Type = Stop
NAS-IP-Address = 192.168.115.112
Acct-Delay-Time = 13
Acct-Session-Id = "00000100"
Acct-Session-Time = 923
Acct-Input-Octets = 59844
Acct-Output-Octets = 55214
Acct-Input-Packets = 964
Acct-Output-Packets = 922
Framed-IP-Address = 192.168.10.15
Acct-Authenticator = Verified
Record-Unique-Key = "2f99057041a4347900000100"

画面1　アクセスログサンプル

　オリジナルのアクセスログは見ていただければ分かるが、ログが時系列に1ブロックずつ記載されている。これをレポーティングツールで加工したものがアクセスログレポート（クリックで別HTMLが開きます）になる。

　ユーザーごとのアクセス傾向などが容易に把握できるようになっているのがお分かりいただけると思う（当然だが、レポーティングツールに与えるオプションでレポートの項目を増やしたり、減らしたりできる。あくまでも一例とお考えいただきたい）。

認証データは管理者にとって有益な情報となる

　RADIUSの解説をする前に個人認証の必要性についてお話しした。これは認証はあくまでもセキュリティの一部でしかないことを実感していただくためである。加えて、認証は行っただけで終わりになるのではなく、そのログはシステム管理者にとって極めて有益な情報源になることも押さえておいていただければ幸いである。次回からは実際のRADIUSプロトコルがどのように動作するのかを解説する。

「次回」へ

「RADIUSを使おう」バックナンバー