- はじめに
- ACS 5.2 の導入
- ACS 4.x から ACS 5.2 への移行
- ACS 5.x ポリシー モデル
- ACS を使用した一般的なシナリオ
- [My Workspace] の概要
- インストール後の設定タスク
- ネットワーク リソースの管理
- ユーザおよび ID ストアの管理
- ポリシー要素の管理
- アクセス ポリシーの管理
- ACS での監視とレポート
- アラームの管理
- レポートの管理
- Monitoring & Report Viewer を使用した ACS のトラブルシューティング
- Monitoring & Report Viewer でのシステム の動作と設定の管理
- システム管理者の管理
- システムの動作の設定
- システム管理設定の管理
- ロギングの概要
- AAA プロトコル
- ACS 5.2 での認証
- 用語集
- 索引
Cisco Secure Access Control System 5.2 ユーザ ガイド
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月6日
章のタイトル： AAA プロトコル
AAA プロトコル
一般的な使用例
•
「ネットワーク アクセス（EAP 使用および未使用の RADIUS）」
デバイス管理（TACACS+）
図 A-1 に、デバイス管理に関するフローを示します。次の 2 つの主要なトリガーがあります。
• 「セッション アクセス要求（デバイス管理 [TACACS+]）」
セッション アクセス要求（デバイス管理 [TACACS+]）
（注） 番号は、図 A-1に対応しています。
2. ネットワーク デバイスによって、TACACS+ アクセス要求が ACS に送信されます。
3. ACS は、ID ストアを使用してユーザのクレデンシャルを確認します。
4. ACS は、決定を適用するネットワーク デバイスに、TACACS+ 応答を送信します。応答には、セッション中の管理者アクセスのレベルを決定する特権レベルなどのパラメータが含まれています。
コマンド認可要求
（注） 番号は、図 A-1に対応しています。
1. 管理者が、ネットワーク デバイスでコマンドを発行します。
2. ネットワーク デバイスによって、TACACS+ アクセス要求が ACS に送信されます。
ネットワーク アクセス（EAP 使用および未使用の RADIUS）
ネットワーク アクセスでは、ホストはネットワーク デバイスに接続し、ネットワーク リソースの使用を要求します。ネットワーク デバイスは、新しく接続されたホストを識別し、転送方式として RADIUS プロトコルを使用して、ユーザの認証および認可を ACS に要求します。
ACS 5.2 では、RADIUS プロトコルを使用して転送されるプロトコルに応じて、次のカテゴリのネットワーク アクセス フローがサポートされます。
EAP を含まない RADIUS ベースのプロトコルの詳細については、「EAP 認証を使用しない RADIUS ベースのフロー」を参照してください。
• RADIUS を使用して転送される EAP プロトコル ファミリ。さらに次のように分類できます。
– TLS ハンドシェイクを含み、クライアントが ACS サーバ証明書を使用してサーバ認証を実行する EAP プロトコル。
PEAP。内部方式 PEAP/EAP-MSCHAPv2 および PEAP/EAP-GTC のいずれかを使用します。
EAP-FAST。内部方式 EAP-FAST/EAP-MSCHAPv2 および EAP-FAST/EAP-GTC のいずれかを使用します。
– 完全に証明書ベースの EAP プロトコル。このプロトコルでは、TLS ハンドシェイクによってサーバ認証とクライアント認証の両方に証明書が使用されます。
EAP 認証を使用する RADIUS ベースのフローの詳細については、「EAP 認証を使用する RADIUS ベースのフロー」を参照してください。
EAP 認証を使用しない RADIUS ベースのフロー
この項では、EAP 認証を使用しない RADIUS ベースのワークフローについて説明します。
PAP 認証を使用する RADIUS の処理手順は、次のとおりです。
2. ネットワーク デバイスは、RADIUS Access-Request を ACS に送信します。使用されている特定のプロトコル（PAP、CHAP、MSCHAPv1、または MSCHAPv2）に適した RADIUS アトリビュートが含まれています。
3. ACS は、ID ストアを使用してユーザのクレデンシャルを確認します。
4. RADIUS 応答（Access-Accept または Access-Reject）が、決定を適用するネットワーク デバイスに送信されます。
図 A-2 に、EAP を使用しない RADIUS ベースの認証を示します。
図 A-2 EAP 認証を使用しない RADIUS ベースのフロー
EAP 認証を使用する RADIUS ベースのフロー
EAP には、さまざまな認証タイプをサポートする拡張フレームワークがあります。これらのフレーワークの中で、ACS によってサポートされている具体的な EAP 方式は次のとおりです。
• クライアントが ACS サーバ証明書を使用してサーバ認証を実行する EAP 方式
• サーバ認証とクライアント認証の両方に証明書を使用する EAP 方式
認証プロセスで EAP が使用される場合は常に、具体的にどの EAP 方式（および該当する場合は内部方式）を使用する必要があるかを決定するネゴシエーション フェーズが先行します。
2. ネットワーク デバイスが EAP 要求をホストに送信します。
3. ホストは、EAP 応答によって、ネットワーク デバイスに応答します。
4. ネットワーク デバイスは、ホストから受信した EAP 応答を RADIUS Access-Request 内に（EAP-Message RADIUS アトリビュートを使用して）カプセル化し、RADIUS Access-Request を ACS に送信します。
5. ACS は、RADIUS パケットから EAP 応答を抽出して新しい EAP 要求を作成し、この EAP 要求を RADIUS Access-Challenge 内に（この場合も EAP-Message RADIUS アトリビュートを使用して）カプセル化し、ネットワーク デバイスに送信します。
6. ネットワーク デバイスは、EAP 要求を抽出し、ホストへ送信します。
この方法で、ホストと ACS は間接的に EAP メッセージを交換します（EAP メッセージは、RADIUS を使用して転送され、ネットワーク デバイスを介して渡されます）。この方法で交換される EAP メッセージの最初のセットによって、特定の EAP 方式がネゴシエートされます。その後、認証を実行する場合に、この EAP 方式が使用されます。
その後交換される EAP メッセージは、実際の認証の実行に必要なデータを伝送するために使用されます。ネゴシエートされた特定の EAP 認証方式で必要な場合、ACS では ID ストアを使用してユーザのクレデンシャルを確認します。
ACS では、認証が成功か失敗かを決定したあと、EAP-Success または EAP-Failure メッセージを、RADIUS Access-Accept または Access-Reject メッセージ内にカプセル化された状態で、ネットワーク デバイスに（最終的にはホストにも）送信します。
図 A-3 に、EAP を使用する RADIUS ベースの認証を示します。
ACS 5.2 エクスペリエンスに影響する可能性があるサプリカントの既知の問題のリストについては、次の URL を参照してください。 http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.2/release/notes/acs_52_rn.html#wp123862
アクセス プロトコル：TACACS+ および RADIUS
ACS 5.2 は、TACACS+ アクセス プロトコルと RADIUS アクセス プロトコルを使用できます。 表 A-1 に、この 2 つのプロトコルの比較を示します。
|
|
|
|
|---|---|---|
UDP：コネクションレス型トランスポート層プロトコル、確認応答も配送保証もないデータグラム交換。UDP は、IP を使用してデータ ユニット（データグラムと呼ばれる）をコンピュータ間で移動します。 |
||
TACACS+ の概要
ネットワーク デバイスがシスコ デバイス管理アプリケーション、アクセス サーバ、ルータ、またはファイアウォールである場合は、TACACS+ を使用する必要があります。ACS 5.2 では、管理アプリケーションを使用して管理対象ネットワーク デバイスを設定するネットワーク ユーザに対してコマンド認可を提供することにより、シスコ デバイス管理アプリケーションをサポートします。
認可に ACS を使用するように設定されている各管理アプリケーション対して、固有のコマンド セットを使用することによって、管理アプリケーションのユーザに対するコマンド認可のサポートを実現できます。
ACS 5.2 は、管理アプリケーションとの通信に TACACS+ を使用します。管理アプリケーションが ACS と通信できるようにするには、その管理アプリケーションを、ACS 5.2 に TACACS+ を使用する AAA クライアントとして設定する必要があります。
また、デバイス管理アプリケーションに有効な管理者名とパスワードを与える必要があります。管理アプリケーションが最初に ACS と通信するとき、これらの要件が通信の正当性を保証します。
パケットのヘッダーを除き、クライアントと TACACS+ サーバが通信するすべての情報（パケット本体に含まれている）は、共有秘密情報を使用することによって暗号化されます。共有秘密情報自体は、ネットワークで直接的には送信されません。
RADIUS の概要
• 「ACS 5.2 での RADIUS アトリビュート サポート」
RADIUS は、クライアント/サーバ プロトコルです。リモート アクセス サーバは、このプロトコルを使用して中央サーバと通信してダイヤルイン ユーザを認証し、要求されたシステムまたはサービスへのアクセスを認可します。RADIUS を使用すると、企業は、すべてのリモート サーバが共有できる中央データベースにユーザ プロファイルを保持できます。
このプロトコルはセキュリティを向上させます。企業はこのプロトコルを使用して、単一の管理ネットワーク ポイントで適用されるポリシーを設定できます。
新旧の RFC をサポートするために、ACS 5.2 では認証の要求をポート 1645 およびポート 1812 で受け入れます。アカウンティングについては、ACS ではアカウンティング パケットをポート 1646 および 1813 で受け入れます。
RADIUS VSA
ACS 5.2 には、標準 IETF RADIUS アトリビュートのセットがあります。現在は使用されていない RADIUS IETF アトリビュートは、その名前で識別できます。使用されていないアトリビュートには、 attribute-nnn という形式の名前が付けられています。 attribute はアトリビュートの名前であり、 nnn はアトリビュートの ID です。
また、ACS 5.2 では RADIUS VSA がサポートされています。ACS 5.2 のインストール後、次の事前定義済みの RADIUS VSA のセットを使用できます。
• Cisco Business Service Management（BSM）
これらの事前定義済みの RADIUS VSA を変更するか、または新しい RADIUS VSA を定義できます。RADIUS VSA は、作成、編集、および複製できます。詳細については、「RADIUS ベンダー固有アトリビュートの作成、複製、および編集」を参照してください。
AAA サーバとしての ACS 5.2
AAA サーバは、コンピュータ リソースへのユーザのアクセス要求を処理するサーバ プログラムであり、企業に対して AAA サービスを提供します。一般的に、AAA サーバは、ネットワーク アクセス サーバおよびゲートウェイ サーバ、ユーザ情報を格納するデータベースおよびディレクトリと連携動作します。現在、デバイスまたはアプリケーションと AAA サーバとの通信に使用されている標準は、RADIUS です。
ACS 5.2 は、1 台以上の Network Access Device（NAD; ネットワーク アクセス デバイス）の AAA サーバとして機能します。NAD は、ACS サーバのクライアントです。各クライアント NAD で ACS の IP アドレスを指定し、RADIUS プロトコルを使用してユーザ アクセス要求を ACS に送信する必要があります。
RADIUS は、エンドユーザからネットワーク リソースへのアクセスを保護するために、広く一般に使用されています。RADIUS サーバは、他の RADIUS サーバまたは他の種類の認証サーバへのプロキシとして動作できます。
NAD は、ネットワークのゲートキーパーとして機能し、ユーザの代理として Access-Request を ACS に送信します。ACS は、内部 ID ストアを使用するか、外部で設定された LDAP または Windows Active Directory ID ストアを使用して、ユーザ名、パスワード、および必要に応じてその他のデータを確認します。
ACS は、最終的に NAD に対して、Access-Reject メッセージまたは一連の認可アトリビュートを含む Access-Accept メッセージによって応答します。
ACS 5.2 を使用すると、UDP を使用したネットワーク転送を実行できます。ACS 5.2 には、RADIUS パケット解析および構成、必要なデータの確認、重複要求のトラッキングを含む RADIUS プロトコルが実装されています。
• クライアントおよびサーバの再起動またはオフライン化に特別な処理を必要としない。
• UDP は簡単にマルチスレッド サーバを実装して複数のクライアント要求を処理する。
RADIUS に対して UDP が割り当てるポート番号は、次のとおりです。
ACS 5.2 は認証システムへの入り口です。ACS は、特定の設定可能な UDP ポートで受信します。ネットワークからデータが着信した場合は、次の処理が実行されます。
1. ACS は、データを RADIUS クライアント要求またはプロキシ応答パケットとして処理しようとします。
2. ACS は、設定に登録されている NAD からパケットが着信したことを確認し、重複したパケット処理を防止します。
3. ACS は、RADIUS パケットを解析し、その内容について必要な確認を実行します。
4. 次に、ACS は処理のためにデータを適切なフローに渡します。
ACS 5.2 での RADIUS アトリビュート サポート
ACS 5.2 では、RFC 2865 に記述されているように RADIUS プロトコルがサポートされています。
ACS 5.2 では、次のタイプの RADIUS アトリビュートがサポートされています。
ACS 5.2 では、RADIUS に対する次の拡張で定義されているアトリビュートもサポートされています。
• アカウンティング関連のアトリビュート。RFC 2866 で定義されています。
• トンネル プロトコルのサポート。RFC 2867 および 2868 で定義されています。
• EAP のサポート（EAP-Message アトリビュートを使用）。RFC 2869 および 3579 で定義されています。
（注） RADIUS パラメータの参照には、表記法 [attribute-number] [attribute name] が使用されます。たとえば、[1]User-Name です。数字と名前は、仕様でパラメータに対して割り当てられている数字と名前に対応します。
RADIUS では、任意の RADIUS アトリビュートの受信、送信、およびディクショナリベースの解析および構築がサポートされています。RADIUS アトリビュートが通常のアトリビュート、VSA、または Cisco Attribute-Value（AV; アトリビュート値）のペアのいずれであるかは関係ありません。ACS の RADIUS インターフェイスでは、RFC 2865 で定義されている次のアトリビュート データ型がサポートされています。
データ型 integer、string、および text の許可される値の列挙（ENUM）指定がサポートされています。アトリビュート値は、パケットの解析および構築が実行されるとき、これらに対してチェックされます。
ACS は、RADIUS State アトリビュート（24）を使用して特定のカンバセーションを識別します。各カンバセーションには、固有の ID があります。すべてのカンバセーションは、特定の設定バージョン（カンバセーションが開始された時点で使用可能な最新バージョン）で処理されます。
（注） RADIUS State アトリビュート（24）は、PAP 認証には使用されません。
クライアントと RADIUS サーバ間のすべてのトランザクションでは、各 RADIUS パケット内の Request/Response Authenticator フィールドを使用してメッセージの整合性が保護されます。このフィールドでは共有秘密情報が使用されます。共有秘密情報自体は、ネットワークで直接的には送信されません。
また、カプセル化された EAP-Message アトリビュートが含まれるすべてのパケットを含む、一部の形式の RADIUS パケットでは、さらに、Message-Authenticator RADIUS アトリビュート（これにも、共有秘密情報が使用されます）を使用して、すべての RADIUS アトリビュートの整合性が保護されます。
さらに、クライアントと RADIUS サーバ間で送信される RADIUS パケット内のユーザ パスワードは常に暗号化され、セキュアでないネットワーク上の権限のないユーザがパスワードを簡単に判別できないように保護します。
ACS では、RADIUS を使用して転送されるさまざまな認証プロトコルがサポートされています。EAP を使用しないサポート対象プロトコルは、次のとおりです。
また、さまざまな EAP ベースのプロトコルを、RADIUS EAP-Message アトリビュート内にカプセル化することによって、RADIUS を使用して転送できます。これらのプロトコルは、証明書を使用するかどうか、およびどの程度使用するかに応じて、より詳細に分類できます。これらの機能は、次のとおりです。
• クライアントが ACS サーバ証明書を使用してサーバ認証を実行する EAP 方式
• サーバ認証とクライアント認証の両方に証明書を使用する EAP 方式。
認可は、設定されているアクセス ポリシーに従って許可されます。
RADIUS の認証機能または認可機能とは別に、RADIUS プロトコルのアカウンティング機能を使用できます。RADIUS アカウンティング機能の一部を使用して、セッションの開始時および終了時にデータを送信でき、セッション中に使用したリソースの量（時間、パケット、バイトなど）を示すことができます。
ISP では、特別なセキュリティおよび課金の必要性に対応するために、RADIUS アクセス コントロールおよびアカウンティング ソフトウェアを使用する場合があります。
RADIUS アクセス要求
ユーザ ログインでは、ネットワーク アクセス デバイスから RADIUS サーバへのクエリー（Access-Request）と、それに対応するサーバからの応答（Access-Accept または Access-Reject）が行われます。Access-Request パケットには、ユーザ名、パスワード、NAD IP アドレス、および NAD ポートと、その他の関連アトリビュートが含まれています。
RADIUS サーバでは、NAD からアクセス要求を受信すると、データベースでユーザ名を検索します。データベース クエリーの結果に応じて、受け入れまたは拒否が送信されます。アクセス拒否メッセージには、拒否の理由を示すテキスト メッセージが付加される場合があります。
RADIUS では、認証と認可は対になっています。RADIUS サーバは、ユーザ名およびパスワードが正しいことを確認すると、Access-Accept 応答を返します。この応答には、このセッションで使用するパラメータを示すアトリビュート値のペアのリストが含まれています。このパラメータのリストによって、ユーザの認可権限が設定されます。
• ユーザに割り当てる IP アドレス（スタティックまたはダイナミック）
フィードバック