Cisco ASDM ユーザ ガイド Version 6.0(3)

認証の概要

セキュリティ アプライアンスを使用すると、AAA サーバを使用してネットワーク アクセス認証を設定できます。ここでは、次の項目について説明します。

• 「ワンタイム認証」

• 「認証チャレンジの受信に必要なアプリケーション」

• 「セキュリティ アプライアンス認証プロンプト」

• 「スタティック PAT と HTTP」

• 「Web クライアントのセキュアな認証」

ワンタイム認証

所定の IP アドレスのユーザは、認証セッションが期限切れになるまで、すべてのルールおよびタイプに対して一度だけ認証を受ける必要があります（タイムアウト値については、「グローバル タイムアウトの設定」を参照）。たとえば、Telnet および FTP を認証するようにセキュリティ アプライアンスが設定されていて、ユーザが正常に Telnet 認証を受けた場合、認証セッションが継続している限り、ユーザは FTP 認証を受ける必要はありません。

認証チャレンジの受信に必要なアプリケーション

プロトコルまたはサービスへのネットワーク アクセス認証を要求するようにセキュリティ アプライアンスを設定することは、すべてのプロトコルまたはサービスについて可能ですが、ユーザが直接認証を受けることができるのは、HTTP、HTTPS、Telnet、または FTP だけです。ユーザがこれらのサービスのいずれかの認証を受けないと、セキュリティ アプライアンスは認証が必要な他のトラフィックを許可しません。

セキュリティ アプライアンスが AAA についてサポートする認証ポートは、次のように固定されています。

• ポート 21 は FTP 用

• ポート 23 は Telnet 用

• ポート 80 は HTTP 用

• ポート 443 は HTTPS 用

セキュリティ アプライアンス認証プロンプト

Telnet および FTP の場合、セキュリティ アプライアンスは認証プロンプトを生成します。

HTTP の場合、セキュリティ アプライアンスはデフォルトで基本 HTTP 認証を使用し、認証プロンプトを提供します。 オプションで、ユーザがユーザ名とパスワードを入力できる内部 Web ページにユーザをリダイレクトするようにセキュリティ アプライアンスを設定できます（「高度な AAA 機能の設定」を参照）。

HTTPS の場合、セキュリティ アプライアンスはカスタム ログイン画面を生成します。 オプションで、ユーザがユーザ名とパスワードを入力できる内部 Web ページにユーザをリダイレクトするようにセキュリティ アプライアンスを設定できます（「高度な AAA 機能の設定」を参照）。

リダイレクションは、基本方式を強化したものです。これは、認証時に向上したユーザ エクスペリエンスが提供されると同時に、Easy VPN でもファイアウォール モードでも、HTTP および HTTPS と同じユーザ エクスペリエンスが提供されるためです。また、セキュリティ アプライアンスでの直接認証もサポートしています。

基本 HTTP 認証を引き続き使用するのは、セキュリティ アプライアンスに受信ポートを開かせない場合、ルータで NAT を使用し、セキュリティ アプライアンスが提供する Web ページの変換ルールを作成しない場合、および使用ネットワークで基本 HTTP 認証が動作に適している場合です。たとえば、URL が埋め込まれている電子メールなどブラウザ以外のアプリケーションは、基本認証との互換性が高くなっています。

正常に認証されると、セキュリティ アプライアンスにより元の宛先にリダイレクトされます。宛先サーバにも独自の認証がある場合、ユーザは別のユーザ名とパスワードを入力します。 基本 HTTP 認証を使用し、宛先サーバに別のユーザ名とパスワードを入力する必要がある場合、仮想 HTTP を設定する必要があります（ 「仮想アクセスの設定」 を参照）。

（注） HTTP 認証を使用する場合、デフォルトでユーザ名とパスワードはクリア テキストでクライアントからセキュリティ アプライアンスに送信されます。さらにこのユーザ名とパスワードは宛先 Web サーバにも送信されます。 クレデンシャルのセキュリティ確保の詳細については、「Web クライアントのセキュアな認証」を参照してください。

FTP の場合、セキュリティ アプライアンス ユーザ名、アット マーク（@）、FTP ユーザ名（name1@name2）を入力するオプションがあります。パスワードには、セキュリティ アプライアンス パスワード、アット マーク（@）、FTP パスワード（password1@password2）を入力します。たとえば、次のテキストを入力します。

この機能は、複数のログインを必要とするファイアウォールをカスケード接続している場合に有用です。複数の名前およびパスワードは、複数のアット マーク（@）で区切ることができます。

スタティック PAT と HTTP

HTTP 認証では、スタティック PAT が設定されている場合、セキュリティ アプライアンスは実際のポートをチェックします。セキュリティ アプライアンスは、マッピングされているポートにかかわらず、実際のポート 80 を宛先とするトラフィックを検出した場合、HTTP 接続を代行受信し、認証を実行します。

たとえば、外部 TCP ポート 889 はポート 80（www）に変換され、すべての関連アクセス ルールはトラフィックを許可するものとします。

この場合、ユーザはポート 889 で 10.48.66.155 にアクセスを試み、セキュリティ アプライアンスはそのトラフィックを代行受信し、HTTP 認証を実行します。セキュリティ アプライアンスが HTTP 接続の完了を許可する前に、ユーザの Web ブラウザには HTTP 認証ページが表示されます。

ローカル ポートがポート 80 以外の場合、ユーザには認証ページが表示されません。その代わりに、セキュリティ アプライアンスは、要求したサービスを使用するには認証を受ける必要があることを示すエラーメッセージを Web ブラウザに送信します。

Web クライアントのセキュアな認証

HTTP 認証を使用する場合、デフォルトでユーザ名とパスワードはクリア テキストでクライアントからセキュリティ アプライアンスに送信されます。さらにこのユーザ名とパスワードは宛先 Web サーバにも送信されます。 セキュリティ アプライアンスには、次のような複数の方式で HTTP 認証のセキュリティを確保できます。

• HTTP 用に認証のリダイレクション方式をイネーブルにする：「インタラクティブ認証ルールの追加」を参照してください。 この方式では、認証クレデンシャルが続けて宛先サーバに送信されないようにします。

• 仮想 HTTP をイネーブルにする：「仮想 HTTP の設定」を参照して、セキュリティ アプライアンスの認証と HTTP サーバの認証を個別に行うことができます。 HTTP サーバが 2 次認証を必要としない場合でも、このコマンドにより基本認証クレデンシャルは HTTP GET 要求から除去されます。

• HTTPS を使用して Web クライアントとセキュリティ アプライアンス間でユーザ名とパスワードの交換をイネーブルにする：「HTTPS を使用した HTTP 認証のクレデンシャルの交換」を参照し、HTTPS を使用した Web クライアントとセキュリティ アプライアンス間でのユーザ名とパスワードの交換をイネーブルにします。 これはセキュリティ アプライアンスと宛先サーバの間、およびクライアントとセキュリティ アプライアンスの間のクレデンシャルを保護する唯一の方式です。 この方式だけを使用することも、または他の方式と組み合せて使用してセキュリティを強化することもできます。

ネットワーク アクセス認証のイネーブル化

ネットワーク アクセス認証をイネーブルにするには、次の手順を実行します。

ステップ 1 第 12 章「AAA サーバとユーザ アカウントの設定」 に従って AAA サーバ グループを設定します。

ステップ 2 Configuration > Firewall > AAA Rules ペインから、 Add > Add Authentication Rule を選択します。

Add Authentication Rule ダイアログボックスが表示されます。

ステップ 3 Interface ドロップダウン リストから、ルールの適用対象とするインターフェイスを選択します。

ステップ 4 Authenticate または Do not Authenticate をクリックします。

たとえば、10.1.1.50 を除く 10.1.1.0/24 を認証する場合、2 つのルール（1 つには Authenticate オプションを使用、もう 1 つには Do not Authenticate オプションを使用）を作成します。 ルールは必ず適切な順序に並べてください。 たとえば、上記の Do not Authenticate ルールを Authenticate ルールよりも上に置き、10.1.1.50 からのトラフィックが最初に Do not Authenticate ルールに一致するようにします。

ステップ 5 AAA Server Group ドロップダウン リストから、サーバ グループまたは LOCAL ユーザ データベースを選択します。

ステップ 6 （オプション）AAA サーバをサーバ グループに追加するには、 Add Server をクリックします。 ユーザを LOCAL データベースに追加するには、 Add User をクリックします。

サーバ グループとローカル ユーザ データベースの設定に関する詳細については、 第 12 章「AAA サーバとユーザ アカウントの設定」 を参照してください。

ステップ 7 Source フィールドで、送信元 IP アドレスを入力するか、 ... ボタンをクリックして ASDM にすでに定義されている IP アドレスを選択します。

プレフィックス/長さ表記（10.1.1.0/24 など）を使用してアドレスとサブネット マスクを指定します。マスクを使用せずに IP アドレスを入力すると、そのアドレスは最後が 0 であってもホスト アドレスと見なされます。

任意の送信元アドレスを指定するには、 any を入力します。

アドレスが複数ある場合はカンマで区切ります。

ステップ 8 Destination フィールドで、宛先 IP アドレスを入力するか、 ... ボタンをクリックして ASDM にすでに定義されている IP アドレスを選択します。

プレフィックス/長さ表記（10.1.1.0/24 など）を使用してアドレスとサブネット マスクを指定します。マスクを使用せずに IP アドレスを入力すると、そのアドレスは最後が 0 であってもホスト アドレスと見なされます。

任意の宛先アドレスを指定するには、 any を入力します。

アドレスが複数ある場合はカンマで区切ります。

ステップ 9 Service フィールドで、宛先サービスの IP サービス名または番号を入力するか、 ... ボタンをクリックしてサービスを選択します。

TCP または UDP のポート番号、あるいは ICMP サービス番号を指定する場合は、 プロトコル / ポート を入力します。 たとえば、TCP/8080 と入力します。

デフォルトでは、サービスは TCP です。

サービスが複数ある場合はカンマで区切ります。

HTTP、HTTPS、Telnet、FTP のいずれかの宛先ポートを必ず含めるようにします。これは、ユーザがこれらのサービスのいずれかで認証を受けておかないと、他のサービスがセキュリティ アプライアンスで通過を許可されないためです。

ステップ 10 （オプション）Description フィールドに説明を入力します。

ステップ 11 （オプション）TCP または UDP の送信元サービスを指定するには、 More Options 領域をクリックして開き、Source Service フィールドに TCP サービスまたは UDP サービスを入力します。

宛先サービスと送信元サービスは同じである必要があります。 Destination Service フィールドをコピーし、Source Service フィールドに貼り付けます。

ステップ 12 （オプション）ルールを非アクティブにするには、 More Options 領域をクリックして開き、 Enable Rule をオフにします。

この設定は、ルールを削除せずに無効にしたい場合に便利です。

ステップ 13 （オプション）ルールの時間範囲を指定するには、 More Options 領域をクリックして開き、Time Range ドロップダウン リストから時間範囲を選択します。

新しい時間範囲を追加するには、 ... ボタンをクリックします。詳細については、「時間範囲の設定」を参照してください。

この設定は、事前に設定した時間にだけルールをアクティブにする場合に便利です。

ステップ 14 OK をクリックします。

TACACS+ 認可の設定

TACACS+ でネットワーク アクセス認可を実行するように、セキュリティ アプライアンスを設定できます。

認証ルールと認可ルールは互いに依存しませんが、認可ルールで一致した未認証トラフィックはすべて拒否されます。認可が成功するためには、ユーザは最初にセキュリティ アプライアンスで認証を受ける必要があります。所定の IP アドレスのユーザは、すべてのルールおよびタイプに対して一度だけ認証を受ければよいため、認証セッションが期限切れになっていなければ、トラフィックが認証文で一致した場合でも、認可が発生することがあります。

ユーザの認証が完了すると、セキュリティ アプライアンスは、一致するトラフィックの認可ルールをチェックします。トラフィックが認可ルールに一致した場合、セキュリティ アプライアンスはユーザ名を TACACS+ サーバに送信します。TACACS+ サーバはセキュリティ アプライアンスに応答し、ユーザ プロファイルに基づいてそのトラフィックの許可または拒否を示します。セキュリティ アプライアンスは、その応答内の認可ルールを実施します。

ユーザに対するネットワーク アクセス認可の設定については、ご使用の TACACS+ サーバのマニュアルを参照してください。

TACACS+ 認可を設定するには、次の手順を実行します。

ステップ 1 認可するトラフィックの認証をイネーブルにします。詳細については、「ネットワーク アクセス認証の設定」を参照してください。 すでに認証をイネーブルにしている場合は、次の手順に進んでください。

ステップ 2 Configuration > Firewall > AAA Rules ペインから、 Add > Add Authorization Rule を選択します。

Add Authorization Rule ダイアログボックスが表示されます。

ステップ 3 Interface ドロップダウン リストから、ルールの適用対象とするインターフェイスを選択します。

ステップ 4 Authorize または Do not Authorize をクリックします。

たとえば、10.1.1.50 を除く 10.1.1.0/24 を認可する場合、2 つのルール（1 つには Authorize オプションを使用、もう 1 つには Do not Authorize オプションを使用）を作成します。 ルールは必ず適切な順序に並べてください。 たとえば、上記の Do not Authorize ルールを Authorize ルールよりも上に置き、10.1.1.50 からのトラフィックが最初に Do not Authorize ルールに一致するようにします。

ステップ 5 AAA Server Group ドロップダウン リストから、サーバ グループまたは LOCAL ユーザ データベースを選択します。

ステップ 6 （オプション）AAA サーバをサーバ グループに追加するには、 Add Server をクリックします。 ユーザを LOCAL データベースに追加するには、 Add User をクリックします。

サーバ グループとローカル ユーザ データベースの設定に関する詳細については、 第 12 章「AAA サーバとユーザ アカウントの設定」 を参照してください。

ステップ 7 Source フィールドで、送信元 IP アドレスを入力するか、 ... ボタンをクリックして ASDM にすでに定義されている IP アドレスを選択します。

プレフィックス/長さ表記（10.1.1.0/24 など）を使用してアドレスとサブネット マスクを指定します。マスクを使用せずに IP アドレスを入力すると、そのアドレスは最後が 0 であってもホスト アドレスと見なされます。

任意の送信元アドレスを指定するには、 any を入力します。

アドレスが複数ある場合はカンマで区切ります。

ステップ 8 Destination フィールドで、宛先 IP アドレスを入力するか、 ... ボタンをクリックして ASDM にすでに定義されている IP アドレスを選択します。

プレフィックス/長さ表記（10.1.1.0/24 など）を使用してアドレスとサブネット マスクを指定します。マスクを使用せずに IP アドレスを入力すると、そのアドレスは最後が 0 であってもホスト アドレスと見なされます。

任意の宛先アドレスを指定するには、 any を入力します。

アドレスが複数ある場合はカンマで区切ります。

ステップ 9 Service フィールドで、宛先サービスの IP サービス名または番号を入力するか、 ... ボタンをクリックしてサービスを選択します。

TCP または UDP のポート番号、あるいは ICMP サービス番号を指定する場合は、 プロトコル / ポート を入力します。 たとえば、TCP/8080 と入力します。

デフォルトでは、サービスは TCP です。

サービスが複数ある場合はカンマで区切ります。

ステップ 10 （オプション）Description フィールドに説明を入力します。

ステップ 11 （オプション）TCP または UDP の送信元サービスを指定するには、 More Options 領域をクリックして開き、Source Service フィールドに TCP サービスまたは UDP サービスを入力します。

宛先サービスと送信元サービスは同じである必要があります。 Destination Service フィールドをコピーし、Source Service フィールドに貼り付けます。

ステップ 12 （オプション）ルールを非アクティブにするには、 More Options 領域をクリックして開き、 Enable Rule をオフにします。

この設定は、ルールを削除せずに無効にしたい場合に便利です。

ステップ 13 （オプション）ルールの時間範囲を指定するには、 More Options 領域をクリックして開き、Time Range ドロップダウン リストから時間範囲を選択します。

新しい時間範囲を追加するには、 ... ボタンをクリックします。詳細については、「時間範囲の設定」を参照してください。

この設定は、事前に設定した時間にだけルールをアクティブにする場合に便利です。

ステップ 14 OK をクリックします。

RADIUS 認可の設定

認証が成功すると、RADIUS プロトコルは RADIUS サーバによって送信される access-accept メッセージでユーザ認可を返します。認証の設定の詳細については、「ネットワーク アクセス認証の設定」を参照してください。

ネットワーク アクセスについてユーザを認証するようにセキュリティ アプライアンスを設定すると、RADIUS 認可も暗黙的にイネーブルになっています。したがって、この項では、セキュリティ アプライアンス上の RADIUS 認可の設定については取り上げません。ここでは、セキュリティ アプライアンスが RADIUS サーバから受信したアクセスリスト情報をどのように処理するかについて説明します。

アクセスリストをセキュリティ アプライアンスにダウンロードするように RADIUS サーバを設定できます。ユーザは、ユーザ固有のアクセスリストで許可された操作だけを認可されます。

（注） アクセス ルールをすでに設定している場合、ユーザごとの上書き設定が、ユーザ固有のアクセスリストによる認可に対して次のような影響を与えることに注意してください（「Advanced Access Rule Configuration」を参照）。

• ユーザごとの上書き設定を使用しない場合、ユーザ セッションのトラフィックは、インターフェイス アクセスリストとユーザ固有のアクセスリストの両方によって許可される必要があります。

• ユーザごとの上書き設定を使用した場合、ユーザ固有のアクセスリストによって許可される内容が決定されます。

この項では、Cisco Secure ACS およびサードパーティ RADIUS サーバを設定する方法について説明します。次の項目を取り上げます。

• 「ダウンロード可能なアクセスリストの機能と Cisco Secure ACS について」

• 「ダウンロード可能なアクセスリストに関する Cisco Secure ACS の設定」

• 「ダウンロード可能なアクセスリストに関する任意の RADIUS サーバの設定」

• 「ダウンロード可能なアクセスリスト内のワイルドカード ネットマスク表現の変換」

ダウンロード可能なアクセスリストの機能と Cisco Secure ACS について

ダウンロード可能なアクセスリストは、Cisco Secure ACS を使用して各サーバに適切なアクセスリストを提供する場合に最もスケーラブルな方法です。次の機能があります。

• 無制限のアクセスリスト サイズ：ダウンロード可能なアクセスリストは、完全なアクセスリストを Cisco Secure ACS からセキュリティ アプライアンスに転送するために必要な数の RADIUS パケットを使用して送信されます。

• アクセスリスト管理の簡素化および集中化：ダウンロード可能なアクセスリストにより、一度記述したアクセスリスト セットを多数のユーザ プロファイルまたはグループ プロファイルに適用することや、多数のセキュリティ アプライアンスに配布することができます。

この方法は、複数の Cisco Secure ACS ユーザまたはグループに適用する非常に大きいアクセスリスト セットがある場合に最適ですが、Cisco Secure ACS ユーザおよびグループの管理を簡素化できることから、アクセスリストのサイズを問わず有用です。

セキュリティ アプライアンスは、ダウンロード可能なアクセスリストを Cisco Secure ACS から次のプロセスで受信します。

1. セキュリティ アプライアンスがユーザ セッションのための RADIUS 認証要求パケットを送信します。

2. Cisco Secure ACS がそのユーザを正常に認証した場合、Cisco Secure ACS は、該当するダウンロード可能なアクセスリストの内部名が含まれた RADIUS access-accept メッセージを返します。Cisco IOS cisco-av-pair RADIUS VSA（ベンダー 9、アトリビュート 1）には、ダウンロード可能なアクセスリスト セットを特定する次の AV のペアが含まれています。

acl-set-name はダウンロード可能なアクセスリストの内部名です。この名前は、Cisco Secure ACS 管理者がアクセスリストに割り当てた名前とアクセスリストが最後に変更された日時の組み合せです。

3. セキュリティ アプライアンスはダウンロード可能なアクセスリストの名前を検査し、以前にその名前のダウンロード可能なアクセスリストを受信したことがあるかどうかを判別します。

–セキュリティ アプライアンスが以前にその名前のダウンロード可能アクセスリストを受信したことがある場合は、Cisco Secure ACS との通信は完了し、セキュリティ アプライアンスはアクセスリストをユーザ セッションに適用します。ダウンロード可能なアクセスリストの名前には最後に変更された日時が含まれているため、Cisco Secure ACS から送信された名前と、以前にダウンロードしたアクセスリストの名前が一致するということは、セキュリティ アプライアンスはダウンロード可能なアクセスリストの最新バージョンを持っていることになります。

–セキュリティ アプライアンスが以前にその名前のダウンロード可能なアクセスリストを受信したことがない場合は、そのアクセスリストの古いバージョンを持っているか、そのアクセスリストのどのバージョンもダウンロードしたことがないことになります。いずれの場合でも、セキュリティ アプライアンスは、ダウンロード可能なアクセスリスト名を RADIUS 要求内のユーザ名として使用し、ヌル パスワード アトリビュートとともに RADIUS 認証要求を発行します。cisco-av-pair RADIUS VSA では、この要求に次の AV のペアも含まれます。

これに加えて、セキュリティ アプライアンスは Message-Authenticator アトリビュート（IETF RADIUS アトリビュート 80）で要求に署名します。

4. ダウンロード可能なアクセスリストの名前が含まれているユーザ名アトリビュートを持つ RADIUS 認証要求を受信すると、Cisco Secure ACS は Message-Authenticator アトリビュートをチェックして要求を認証します。Message-Authenticator アトリビュートがない場合、または正しくない場合、Cisco Secure ACS はその要求を無視します。Message-Authenticator アトリビュートの存在により、ダウンロード可能なアクセスリスト名がネットワーク アクセスの不正取得に悪用されることが防止されます。Message-Authenticator アトリビュートとその使用方法は、RFC 2869「RADIUS Extensions」で定義されています。この文書は、 http://www.ietf.org で入手できます。

5. 要求されたアクセスリストの長さが約 4 KB 未満の場合、Cisco Secure ACS はそのアクセスリストを含めた access-accept メッセージで応答します。メッセージには他の必須アトリビュートを含める必要があるので、1 つの access-accept メッセージに収まるアクセスリストの最大サイズは 4 KB よりわずかに小さくなります。

Cisco Secure ACS はダウンロード可能なアクセスリストを cisco-av-pair RADIUS VSA で送信します。アクセスリストは、一連の AV のペアという形式をとります。各ペアには ACE が 1 つ含まれ、シリアル番号が付けられます。

AV のペアの例を次に示します。

6. 要求されたアクセスリストの長さが約 4 KB を超える場合、Cisco Secure ACS は、上記の形式のアクセスリストの一部が含まれた access-challenge メッセージで応答します。メッセージには、State アトリビュート（IETF RADIUS アトリビュート 24）も含まれています。State アトリビュートには、Cisco Secure ACS がダウンロードの進捗を追跡するために使用する制御データが含まれています。Cisco Secure ACS は、RADIUS メッセージの最大サイズ以内で可能な限り多数の完全な AV のペアを cisco-av-pair RADIUS VSA に含めます。

セキュリティ アプライアンスはアクセスリストの一部を受信すると、それを保存し、新しい access-request メッセージで応答します。これには、ダウンロード可能なアクセスリストを求める最初の要求と同じアトリビュートと、access-challenge メッセージで受信した State アトリビュートのコピーが含まれています。

これは、Cisco Secure ACS がアクセスリストの最後の部分を access-accept メッセージで送信するまで続行されます。

ダウンロード可能なアクセスリストに関する Cisco Secure ACS の設定

Cisco Secure ACS 上のダウンロード可能なアクセスリストを共有プロファイル コンポーネントとして設定し、そのアクセスリストをグループまたは個々のユーザに割り当てることができます。

アクセスリスト定義は、次のプレフィックスがない点を除いて拡張 access-list コマンドに類似する、1 つまたは複数のセキュリティ アプライアンス コマンドで構成されます。

Cisco Secure ACS バージョン 3.3 上のダウンロード可能なアクセスリスト定義の例を次に示します。

ダウンロード可能なアクセスリストを作成する方法、およびそれらをユーザと関連付ける方法の詳細については、ご使用のバージョンの Cisco Secure ACS のマニュアルを参照してください。

セキュリティ アプライアンス上では、ダウンロードされたアクセスリストの名前は次のようになります。

acl_name 引数は Cisco Secure ACS で定義された名前（上記の例では acs_ten_acl）、 number は Cisco Secure ACS が生成した一意のバージョン ID です。

セキュリティ アプライアンス上にダウンロードされたアクセスリストは、次の行で構成されます。

ダウンロード可能なアクセスリストに関する任意の RADIUS サーバの設定

ユーザ固有のアクセスリストを Cisco IOS RADIUS cisco-av-pair VSA（ベンダー 9、アトリビュート 1）でセキュリティ アプライアンスに送信するように、Cisco IOS RADIUS VSA をサポートする任意の RADIUS サーバを設定できます。

cisco-av-pair VSA で、 access-list extended コマンドと類似する 1 つまたは複数の ACE を設定します。ただし、次のコマンド プレフィックスを置き換える必要があります。

次のテキストに置き換えます。

nnn 引数は、0 ～ 999999999 の番号で、セキュリティ アプライアンス上に設定するコマンド文の順序を指定します。このパラメータを省略すると、順番は 0 となり、cisco-av-pair RADIUS VSA 内部の ACE の順序が使用されます。

RADIUS サーバ上の cisco-av-pair VSA に対して設定されている必要のあるアクセスリスト定義の例を次に示します。

cisco-av-pair アトリビュートで送信されるアクセスリストをユーザごとに一意にする方法については、ご使用の RADIUS サーバのマニュアルを参照してください。

セキュリティ アプライアンス上では、ダウンロードされたアクセスリストの名前は次の形式になります。

username 引数は、認証を受けるユーザの名前です。

セキュリティ アプライアンス上にダウンロードされたアクセスリストは、次の行で構成されます。RADIUS サーバ上で指定された番号に基づいた順序になっています。

ダウンロードされたアクセスリストの「access-list」という単語と名前の間には、2 個のスペースがあります。これらのスペースにより、ダウンロードされたアクセスリストとローカルのアクセスリストが区別されます。この例では、「79AD4A08」はセキュリティ アプライアンスが作成したハッシュ値で、RADIUS サーバ上でアクセスリスト定義がいつ変更されたかを判別するために役立ちます。

ダウンロード可能なアクセスリスト内のワイルドカード ネットマスク表現の変換

RADIUS サーバを使用して、ダウンロード可能なアクセスリストを Cisco VPN 3000 Series Concentrator およびセキュリティ アプライアンスに提供する場合は、ワイルドカード ネットマスク表現を標準のネットマスク表現に変換するようにセキュリティ アプライアンスを設定しなければならない場合があります。これは、Cisco VPN 3000 Series Concentrator はワイルドカード ネットマスク表現をサポートしますが、セキュリティ アプライアンスは標準のネットマスク表現しかサポートしないためです。これらの違いは、RADIUS サーバ上のダウンロード可能なアクセスリストを設定する方法に影響しますが、ワイルドカード ネットマスク表現を変換するようにセキュリティ アプライアンスを設定することで、その影響を最小限に抑えることができます。ワイルドカード ネットマスク表現の変換により、RADIUS サーバ上のダウンロード可能なアクセスリストのコンフィギュレーションを変更することなく、Cisco VPN 3000 Series Concentrator 用に記述されたダウンロード可能なアクセスリストをセキュリティ アプライアンスで使用できます。

アクセスリスト ネットマスク変換は、ACL Netmask Convert オプションを使用してサーバごとに設定できます。このオプションは Configuration > Device Management > Users/AAA > AAA Server Groups > Add/Edit AAA Server ダイアログボックスにあります。RADIUS サーバの設定方法の詳細については、 第 12 章「AAA サーバとユーザ アカウントの設定」 を参照してください。

HTTPS を使用した HTTP 認証のクレデンシャルの交換

セキュリティ アプライアンスは、HTTP 認証のセキュリティを確保する方式を提供します。HTTP 認証を保護しないと、クライアントからセキュリティ アプライアンスに送信されるユーザ名およびパスワードは、クリア テキストとして渡されます。Secure HTTP 機能を使用することで、Web クライアントとセキュリティ アプライアンスとの間で HTTPS を使用したユーザ名とパスワードの交換がイネーブルになります。

この機能をイネーブルにした後、ユーザが HTTP を使用しているときに認証を必要とした場合は、セキュリティ アプライアンスが HTTP ユーザを HTTPS プロンプトにリダイレクトします。正常に認証されると、セキュリティ アプライアンスにより元の HTTP URL にリダイレクトされます。

セキュアな Web クライアント認証には次の制約事項があります。

• 許容される最大同時 HTTPS 認証セッション数は 16 です。 16 の HTTPS 認証プロセスがすべて実行中の場合、認証を必要とする新しい接続は失敗します。

• 認証の絶対タイムアウト値を 0 に設定すると（「グローバル タイムアウトの設定」の Authentication absolute オプションを参照）、HTTPS 認証が機能しない場合があります。 HTTPS 認証後に、ブラウザが複数の TCP 接続を開始して Web ページをロードすると、最初の接続は通過しますが、その後の接続では認証が起動されます。 その結果、ユーザが毎回正しいユーザ名とパスワードを入力しても、繰り返し認証ページが表示されます。 この状態を回避するには、認証の絶対タイムアウト値を 1 秒に設定します。 ただし、この回避策を使用すると、認証されていないユーザが同じ送信元 IP アドレスからアクセスすれば 1 秒間だけファイアウォールを通過できるおそれがあります。

• HTTPS 認証は SSL ポート 443 で行われるため、ポート 443 上の HTTP クライアントから HTTP サーバへのトラフィックをブロックするルールを設定してはいけません。さらに、ポート 80 の Web トラフィックにスタティック PAT が設定されている場合、SSL ポートにも同じ設定を行う必要があります。

Web クライアントのセキュアな認証をイネーブルにするには、次の手順を実行します。

ステップ 1 Configuration > Firewall > AAA Rules ペインから、ペインの下部にある Advanced ボタンをクリックします。

AAA Rules Advanced Options ダイアログボックスが表示されます。

ステップ 2 Enable Secure HTTP をオンにします。

ステップ 3 OK をクリックします。

インタラクティブ認証ルールの追加

HTTP のデフォルトでは、セキュリティ アプライアンスは基本 HTTP 認証を使用します。HTTPS の場合、セキュリティ アプライアンスは同様のカスタム ログイン画面を生成します。Configuration > Security Policy > AAA Rules > Advanced AAA Configuration > Add Interactive Authentication ダイアログボックスを使用すれば、ユーザがユーザ名とパスワードを入力できる内部 Web ページにセキュリティ アプライアンスがユーザをリダイレクトするように設定できます。

HTTP および HTTPS 認証のリダイレクト方式をイネーブルにした場合、セキュリティ アプライアンスでの直接認証も自動的にイネーブルになります。HTTP、HTTPS、Telnet、または FTP によるセキュリティ アプライアンスの通過は許可しないが他のタイプのトラフィックは認証する場合、直接認証は役に立ちます。他のトラフィックが許可される前に、ユーザは HTTP または HTTPS を使用するセキュリティ アプライアンスを直接認証できます。通過トラフィックに基本 HTTP 認証を引き続き使用する場合、直接認証は独立して設定できます。直接認証のログイン ページにアクセスするには、次の URL のいずれかを入力します。

リダイレクションは、基本方式を強化したものです。これは、認証時に向上したユーザ エクスペリエンスが提供されると同時に、Easy VPN でもファイアウォール モードでも、HTTP および HTTPS と同じユーザ エクスペリエンスが提供されるためです。また、セキュリティ アプライアンスでの直接認証もサポートしています。

基本 HTTP 認証を引き続き使用するのは、セキュリティ アプライアンスに受信ポートを開かせない場合、ルータで NAT を使用し、セキュリティ アプライアンスが提供する Web ページの変換ルールを作成しない場合、および使用ネットワークで基本 HTTP 認証が動作に適している場合です。たとえば、URL が埋め込まれている電子メールなどブラウザ以外のアプリケーションは、基本認証との互換性が高くなっています。

インタラクティブ認証ルールを設定するには、次の手順を実行します。

ステップ 1 Configuration > Firewall > AAA Rules ペインから、ペインの下部にある Advanced ボタンをクリックします。

AAA Rules Advanced Options ダイアログボックスが表示されます。

ステップ 2 Interactive Authentication 領域で、 Add をクリックします。

ステップ 3 Protocol メニューから、 HTTP または HTTPS を選択します。

HTTP と HTTPS の両方のリスナをイネーブルにするには、2 つの別のルールを作成する必要があります。

ステップ 4 Interface メニューから、リスナをイネーブルにするインターフェイス名を選択します。

ステップ 5 Port メニューから共通ポートを選択するか、リスンするポート番号を入力します。

HTTP のデフォルトは 80、HTTPS のデフォルトは 443 です。

ステップ 6 通過トラフィックを認証用の受信ポートにリダイレクトするには、 Redirect network users for authentication requests チェックボックスをオンにします。

このチェックボックスをオンにしない場合、直接認証だけがイネーブルになります。

ステップ 7 OK をクリックします。

Telnet を使用した直接認証のイネーブル化

すべてのプロトコルまたはサービスについてネットワーク アクセス認証を設定できますが（ aaa authentication match コマンドまたは aaa authentication include コマンドを参照）、ユーザが直接認証を受けることができるのは、HTTP、Telnet、または FTP だけです。ユーザがまずこれらのサービスのいずれかで認証を受けておかないと、他のサービスは通過を許可されません。 セキュリティ アプライアンスで HTTP、Telnet、FTP は許可しないが、他のタイプのトラフィックは認証する場合、仮想 Telnet を設定できます。仮想 Telnet では、セキュリティ アプライアンス上に設定された所定の IP アドレスにユーザが Telnet 接続すると、セキュリティ アプライアンスは Telnet プロンプトを表示します。

仮想 Telnet アドレスへの Telnet アクセスの認証を、AAA 認証ルールを使用して認証するその他のサービスに対する認証と同様に設定する必要があります（「ネットワーク アクセス認証の設定」を参照）。

認証が済んでいないユーザが仮想 Telnet IP アドレスに接続すると、ユーザはユーザ名とパスワードを尋ねられ、その後 AAA サーバにより認証されます。いったん認証されると、ユーザには
「Authentication Successful.」メッセージが表示されます。その後ユーザは認証を必要とする他のサービスに正常にアクセスできます。

着信ユーザ（低セキュリティから高セキュリティへ）の場合、送信元インターフェイスに適用されるアクセス ルールに、宛先インターフェイスとして仮想 Telnet アドレスを含める必要もあります。 さらに、NAT が必要でない場合も含め、仮想 Telnet IP アドレスにスタティック NAT ルールを追加する必要があります。 通常、アイデンティティ NAT ルールが使用されます（アドレスを同一アドレスに変換）。

発信ユーザの場合、トラフィックに明示的な許可がありますが、内部インターフェイスにアクセス ルールを適用する場合は、必ず仮想 Telnet アドレスへのアクセスを許可する必要があります。 スタティック NAT ルールは必要ありません。

セキュリティ アプライアンスからログアウトするには、仮想 Telnet IP アドレスに再接続します。ログアウトを尋ねるプロンプトが表示されます。

仮想 Telnet サーバを設定するには、次の手順を実行します。

ステップ 1 Configuration > Firewall > Advanced > Virtual Access ペインから、 Enable Telnet Server をオンにします。

ステップ 2 Virtual Telnet Server フィールドで、Telnet 接続する対象の IP アドレスを入力します。

このアドレスは必ず、セキュリティ アプライアンスにルーティングされる未使用のアドレスにしてください。 たとえば、外部にアクセスするときに内部アドレス用の NAT を実行し、仮想 Telnet サーバへの外部アクセスを提供する場合、仮想 Telnet サーバ アドレスにグローバル NAT アドレスのいずれかを使用できます。

ステップ 3 OK をクリックします。

仮想 HTTP の設定

セキュリティ アプライアンスで HTTP 認証を使用する場合（「ネットワーク アクセス認証の設定」を参照）、セキュリティ アプライアンスはデフォルトで基本 HTTP 認証を使用します。 この認証方式を、セキュリティ アプライアンスが HTTP 接続をセキュリティ アプライアンス自身が生成した Web ページにリダイレクトするように変更できます（「インタラクティブ認証ルールの追加」を参照）。

ただし、引き続き基本 HTTP 認証を使用する場合、HTTP 認証をカスケードするには仮想 HTTP サーバが必要になることがあります。

セキュリティ アプライアンスだけでなく宛先 HTTP サーバにも認証が必要な場合、virtual http コマンドを使用すると、セキュリティ アプライアンス（AAA サーバ経由）の認証と HTTP サーバの認証を個別に行うことができます。 仮想 HTTP を使用しないと、セキュリティ アプライアンスの認証に使用されたユーザ名とパスワードが HTTP サーバに送信され、HTTP サーバのユーザ名とパスワードを入力するプロンプトが別途表示されることはありません。 AAA サーバと HTTP サーバでユーザ名とパスワードが異なると、HTTP 認証は失敗します。

この機能は、AAA 認証を必要とするすべての HTTP 接続をセキュリティ アプライアンス上の仮想 HTTP サーバにリダイレクトします。 セキュリティ アプライアンスは、AAA サーバのユーザ名とパスワードの入力を求めるプロンプトを表示します。 AAA サーバがユーザを認証すると、セキュリティ アプライアンスは HTTP 接続を元のサーバにリダイレクトして戻しますが、AAA サーバのユーザ名とパスワードは含めません。 HTTP パケットにユーザ名とパスワードが含まれていないため、HTTP サーバはユーザにプロンプトを別途表示し、HTTP サーバのユーザ名とパスワードの入力を求めます。

着信ユーザ（低セキュリティから高セキュリティへ）の場合、送信元インターフェイスに適用されるアクセス ルールに、宛先インターフェイスとして仮想 HTTP アドレスを含める必要もあります。 さらに、NAT が必要でない場合も含め、仮想 HTTP IP アドレスにスタティック NAT ルールを追加する必要があります。 通常、アイデンティティ NAT ルールが使用されます（アドレスを同一アドレスに変換）。

発信ユーザの場合、トラフィックに明示的な許可がありますが、内部インターフェイスにアクセス ルールを適用する場合は、必ず仮想 HTTP アドレスへのアクセスを許可する必要があります。 スタティック NAT ルールは必要ありません。

仮想 HTTP サーバを設定するには、次の手順を実行します。

ステップ 1 Configuration > Firewall > Advanced > Virtual Access ペインから、 Enable HTTP Server をオンにします。

ステップ 2 Virtual HTTP Server フィールドで、仮想 HTTP サーバの IP アドレスを入力します。

このアドレスは必ず、セキュリティ アプライアンスにルーティングされる未使用のアドレスにしてください。 たとえば、外部にアクセスするときに内部アドレス用の NAT を実行し、仮想 HTTP サーバへの外部アクセスを提供する場合、仮想 HTTP サーバのアドレスにグローバル NAT アドレスのいずれかを使用できます。

ステップ 3 （オプション）ユーザに HTTP 接続をセキュリティ アプライアンスにリダイレクトする必要があることを通知するには、 Display redirection warning をオンにします。

このオプションは、リダイレクトが自動的に行われないテキストベースのブラウザにだけ適用されます。

ステップ 4 OK をクリックします。