実際のモデルケースにおける 802.1X に対する機能要件

実際に 802.1X と PKI を用いた認証システムを運用する際に、どのような点に注意すべ

きか考察してみる。まず、このようなシステムを導入する場合には、通常の無線LAN環境 に加えて、RADIUSサーバと、更にPKIを利用するための認証局やリポジトリが必要とな る。このため導入にあたっては、これらの追加コンポーネントをどう扱うかがポイントで ある。

認証局ベンダ X社

subject以外の 情報はほぼ同一

ユーザ企業 C社 ユーザ企業 B社

ユーザ企業 A社

イーサネット 認証サーバ

アクセス ポイント 他社クライアントからの アクセスを制御する必

要がある。

リポジトリ 失効情報等 認証局 X の提供

失効情報の問い合わせ ホスティングなど

のアウトソーシン グも可能。

図 8-2 認証局ベンダから証明書を取得

開発部 営業部

管理部 イーサネット 認証サーバ

アクセス ポイント リポジトリ 失効情報等 認証局

の提供

失効 情報 の問い合

わせ

部署によってアクセス 制御をする必要がある。

図 8-3 自前でPKI環境を構築

8.1.4.1 RADIUSサーバ

RADIUSサーバは、アクセスポイントとRADIUSプロトコルを用いて通信を行うので、

必ずしもアクセスポイントと物理的に近接している必要はない。また、(無線 LAN)クライ アントの認証には公開鍵証明書を用いるので、RADIUS サーバにユーザの秘密情報を格納 する必要がない。このため、外部データセンタのホスティングサービスを利用するなど、

アウトソーシングすることも可能である。

ただし、認証頻度やトラフィックを十分考慮しないと、クライアントにとって十分なパ フォーマンスを得られない可能性があるので注意が必要である。また、EAP-TTLSやPEAP などクライアント認証に公開鍵暗号を用いないケースでは、RADIUS サーバに各ユーザの 秘密情報を格納することになるので、セキュリティ面での配慮が重要となる。

8.1.4.2 認証局とリポジトリ

EAP-TTLSやPEAPのサーバ認証で必要となるサーバ証明書や、EAP-TLSのクライア

ント認証で必要となるクライアント証明書は、認証局から発行してもらうことになる。加 えて、認証の際に証明書の失効検証を行うためには、リポジトリなどから失効情報を取得 する必要がある。これらを実現する方法として、第三者的な認証局ベンダなどからサーバ 証明書やクライアント証明書を取得する場合と、自社で認証局やリポジトリなど必要なシ ステムを構築する場合が考えられる。以下、両者の違いについて考察する。

(ア) 認証局ベンダから証明書を取得する場合

認証局ベンダから証明書を取得するメリットは、より安全な証明書を発行してもらえる 点にある。一般に認証局ベンダは、認証局を運用するにあたり、認証局運用規定(CPS)を定 め公開している場合が多い。CPS の内容は認証局ベンダによって様々であるが、認証局を 如何に厳密に運用しているかを示すものである。例えば電子署名法で認定された特定認証 業務の認定認証局などは、認証局運用にツーマンルール(常に二人で行動することによって 不正を防ぐ)を要求するなど、きわめて厳密である。このような運用ノウハウを持つ認証局 ベンダから証明書を取得することで、容易に本人以外の第三者が不正に証明書を利用して しまう事態を防ぐことができる。

また、厳密な証明書であることにより、第三者からの信頼を得やすい。このため電子署 名や暗号データを交換する対象が広がるというメリットもある。例えば、社外に電子署名 したデータを送る際に、自社認証局から発行された証明書を用いて署名するよりも、信頼 ある認証局ベンダから発行された証明書を用いて署名した方が信頼されやすい。

一方で、注意すべき点もいくつかある。TLS 認証では、信頼する側(Relying-Party)が信 頼している認証局(Trust Anchor)から、信頼される側(Subscriber)の証明書までの証明書チ ェーンをたどることができれば、基本的に信頼関係が成立する。図 8-2で言えば、RADIUS サーバ(Relying-Party)が認証局Xを信頼している(Trust Anchor)場合、このRADIUSサー バは認証局Xが発行する全ての証明書を信頼できてしまう、ということである。

認証局ベンダは、勿論様々なユーザに証明書を発行しているため、このように意図して いない認証が成立してしまう可能性がある。そこで、認証局ベンダからクライアント認証 に用いる証明書を取得するような場合には、何らかの形で「特定の証明書だけに認証を許 可する」仕組みが必要と考えられる。ここで認証を許可したい証明書と、許可したくない 証明書の違いは認証局ベンダに依存するが、確実に利用可能な識別子として、subjectDN が挙げられる。このため本実験においても、IEEEやIETFで明確に要件として挙げられて はいないものの、このようなsubjectDN を用いたアクセス制御が実装されているかどうか 検証してみた（表 7-16、表 7-17参照）。

結果として、このsubjectDNによるアクセス制御を実装・機能しているRADIUSサーバ はごく一部だけであった。これは IEEE やIETF で明確に要件として定義されていないた

めと考えられるが、実運用にあたっては、各標準で定義されるような単に認証に必要な機 能だけでなく、このような付加機能が選定のポイントになると思われる。

(イ) 自前で認証局やリポジトリを構築する場合

証明書発行に必要な認証局やリポジトリなどの環境を自前で用意するにあたって、上述 の認証局ベンダから発行される証明書と同等の厳密さを要求することは、現実的でない。

同等の厳密さを確保するには、認証局ベンダと同等の運用が必要であり、電子署名法の例 に挙げたように、相当な運用コストが発生するからである。

逆に証明書の厳密さを求めないのであれば、自前で PKI環境を構築することには、それ なりのメリットがある。一つには証明書の管理が挙げられる。例えば認証局ベンダから証 明書を取得していた場合、証明書に対応する鍵ペアを紛失したりした場合、再発行や失効 には認証局ベンダとのやりとりが必要となる。場合によっては、再発行や失効に数日かか る可能性もある。しかし、これらの証明書発行環境を自前で運用していれば、再発行や失 効なども容易に行うことができる。勿論これらの運用にはコストが発生してしまうが、運 用に厳密さを要求しなければ、ある程度は低減させることが可能と考えられる。

もっとも、クライアント証明書に厳密さを求めないようであれば、EAP-TLS よりも

EAP-TTLSやPEAPのように、そもそもクライアント証明書を用いない認証手順を採用し

た方が適切である。その場合には、必要となるのはサーバ証明書だけとなるので、少数で あれば認証局ベンダなどから取得してしまう方が現実的であるかも知れない。

[島岡]