▼ダイレクトメニュー 　もくじ 　はじめに 　802.1xの概要 　802.1xベースソリューションのアーキテクチャ上の利点 　一般的なアーキテクチャ 　Juniper Networks社のどのRADIUSサーバを選択すべきか？ 　パフォーマンス 　信頼性 　802.1xクライアントについて 　RADIUSサーバに関する条件 　まとめ

一般的なアーキテクチャ シナリオ #1　―　シングルサイト環境 シナリオ #2　―　独立したサイト郡による分散処理 シナリオ #3　―　サイトは分散させ、認証とセキュリティに関する処理は中央で行う シナリオ #4　―　サイトとセキュリティ処理を分散させ、認証処理は中央で行う 次に、一般的な4つの802.1xアーキテクチャについて概要を説明します。この4つのアーキテクチャを参考にしながら、RADIUSサーバの役割を説明し、それぞれのアーキテクチャが適するネットワークのタイプを示し、ネットワークアドミニストレータが一般的に配慮すべき要素であるコスト、性能、信頼性について説明します。 シナリオ #1 　シングルサイト環境 最も単純なシナリオであり、次のように特徴付けられます。 (1) すべてのWLANユーザが1つのサイトに割り当てられています。 (2) 中央の認証データベースですべてのユーザ認証処理を行います。 (3) 1つまたは複数のRADIUSサーバでWLANやリモート・アクセスによる利用を管理し、ユーザを認証し、安全なWLAN接続を確立します。 (図1) すべてのWLANユーザが1つのネットワークに割り当てられています。 このアーキテクチャには以下の利点があります。 (1) RADIUSサーバがサポートする任意のバックエンド認証データベースに対してWLANユーザを認証することができます（後述のように認証方式によってアーキテクチャの適性が異なります）。 (2) 規模の変化に対応する場合でも、アクセスポイントおよび中央の認証データベースに対してユーザを認証するRADIUS/AAAサーバを追加するだけで済みます。 シナリオ #2 　独立したサイト群による分散処理 このシナリオは、次のように特徴付けられます。 (1) 独立した複数のサイトやネットワークによる分散処理。 (2) 認証データベースは、中央のサイトから、独立した下位の各サイトやネットワークにコピーされ、すべてのユーザ認証処理がローカルで行われます。 (3) 独立したそれぞれのサイトやネットワークごとに、WLANやリモート・アクセスの利用を管理する1つまたは複数のRADIUSサーバが配備されています。各RADIUSサーバは次の処理を実行します。 　1. ユーザ認証をローカルで処理 　2. 安全なWLAN接続を確立 　3. 必要に応じアカウント・データを記録 (4) 中央サイトのネットワークやオペレーティングハブの可用性には左右されません。 (図2) 独立したネットワークがすべてのWLAN/リモート・アクセスの認証処理やセキュリティ処理をローカルに行うように設定されています。 このアーキテクチャには以下の利点があります。 (1) ネットワークへのアクセスがローカルに制御され、中央認証ストアに戻るリンクの信頼性による影響を受けません。 (2) 安全なWLAN接続を確立するための処理負荷はすべて、分散したRADIUSサーバが負担します。新しいWLANユーザの追加による性能低下の問題が発生した場合でも、RADIUSサーバを増設することで容易に対処できます。 WindowsやLDAPのように高い信頼性で容易にコピーできる認証データベースが配備されたネットワークには、このアーキテクチャが適します。一部のトークン・システムやSQLデータベースのように容易にコピーできない認証システムには、このアーキテクチャは適しません。 シナリオ #3 　サイトは分散させ、認証とセキュリティに関する処理は中央で行う このシナリオは、次のように特徴付けられます。 (1) サイト、ネットワーク、アクセスポイントのクラスタは分散しています。 (2) 各サイトや各ネットワーク上のWLANアクセスポイントが、中央のサイトやオペレーティングハブに配備されている認証データベースに対してユーザを認証します。 (3) すべてのWLAN/リモート・アクセスの利用の管理は、中央のサイトに配備されている1つまたは複数のRADIUSサーバが行います。中央のサイトのRADIUSサーバは次の処理を行います。 　1. ユーザ認証処理をローカルにて実行 　2. ユーザの安全な接続を確立 　3. 必要に応じアカウント・データを記録 (4) 中央サイトのネットワークやオペレーティングハブの可用性に左右されます。 (5) リンクの帯域幅の使用状況に左右されます。 (図3) 分散配備されたサイトのポイントから認証処理とセキュリティ処理を行う中央のRADIUSサーバに情報を送信します。 このシナリオは、各サテライト・サイト、ネットワーク、APクラスタにRADIUS/AAAサーバが不要なため、コスト面ではある程度有利ですが、次の2つの点に注意が必要です。 (1) 第一に、WLANユーザがネットワークに接続できるかいなかが、分散ネットワークと中央サイトまたはオペレーティングハブとの間のリンクの状態に左右されます。このリンクが故障した場合、ユーザはネットワークに接続できません。すでに接続しているユーザも遮断されます。セキュリティ確保のためキーの再発行が必要になります。 (2) 第二に、中央サイトのRADIUS/AAAサーバはユーザの認証処理を行うだけでなく、安全なWLAN接続を確立するのに必要な暗号処理計算も行わなければなりません。膨大な数のWLANユーザを管理する（またはその予定がある）場合には、この処理がボトルネックとなって性能を低下させる恐れがあります。WLANユーザの増加に合わせてRADIUSサーバを増設することで、この問題に対処することができます。 WLANユーザの認証に必要なトークンのタイプによっては分散した各ネットワークに認証データベースをコピーするのが実際的でない（またはコピーしたくない）ような環境では、この方式が適しています。また、非常に高速で信頼性の高いリンクでネットワークが接続されている場合にも、この方法が適します。 シナリオ #4 　サイトとセキュリティ処理を分散させ、認証処理は中央で行う このシナリオは、次のように特徴付けられます。 (1) サイト、ネットワーク、アクセスポイントのクラスタは分散しています。 (2) 認証データベースは中央サイトまたはネットワーク・ハブに配備されています。 (3) それぞれのサイト、ネットワーク、アクセスポイントのクラスタには、WLAN/リモート・アクセスの利用を管理するRADIUSサーバが配備されています。分散配備されたRADIUSサーバは次の処理を行います。 　1. ユーザ認証に関する中央サイトへの問い合わせ 　2. 安全な接続そのものを確立する処理 　3. 必要に応じアカウント・データをローカルで記録、または中央サイトにデータを転送 (4) 中央サイトのネットワークの可用性に左右されます。 (図4) ユーザ認証処理は中央サイトに任せ、セキュリティの確立処理はそれぞれのネットワークで行います。 このシナリオには、シナリオ#3と同様に分散ネットワークと中央サイトまたはオペレーティングハブとの間のリンクの信頼性に左右されるという問題点がありますが、別の利点があります。この方式では、安全なWLAN接続を確立する処理に関わる負荷を、分散したネットワーク上に配備されたRADIUSサーバに分散させることができます。これにより性能が向上し、分散サイトと中央サイトの間のリンクで使用される帯域幅が少なくて済みます。 したがって、WLANユーザの認証に必要なトークンのタイプによってはそれぞれのサテライト・ネットワークに認証データベースをコピーするのが実際的でない（またはコピーしたくない）ような環境には、おそらくこの方式が最も適しています。また、非常に高速で信頼性の高いリンクによりネットワークが接続されている場合にも、この方法が適します。 アーキテクチャを組み合わせて 802.1xの利点の一つは、その柔軟性にあります。注目すべきは、次の例のように、自分のネットワークに合わせて上記のシナリオのアーキテクチャを組み合わせることができるという点です。 (1) WLAN環境の展開に際して分散化の程度が比較的大きい方法（シナリオ#2、#4）を採用した場合に、分散ネットワークのいくつかがきわめて小さく、数人のWLANユーザだけから構成される場合があります。これらのネットワークが高い信頼性で中央サイトにリンクされている場合は、そのネットワークにRADIUSサーバをインストールせず、認証処理とセキュリティ処理を中央サイトのRADIUSサーバに任せることもできます。 (2) 比較的に中央集権型の認証/セキュリティ方式（シナリオ#3）を採用した場合に、一部のリモート・オフィスと中央ネットワークとの間のリンクの信頼性が低い場合があります。このような場合、所属するWLANユーザがたとえ数人しか居なくても、これらのユーザが高い信頼性で接続できるようにするためにはこれらのネットワークにRADIUSサーバを分散配備することが必要になる場合もあります。 << 前へ [ 戻る ] 次へ >>