AAA とローカル データベースについて
ここでは、AAA とローカル データベースについて説明します。
認証
認証はユーザを特定する方法です。アクセスが許可されるには、ユーザは通常、有効なユーザ名と有効なパスワードが必要です。AAA サーバは、データベースに保存されている他のユーザ クレデンシャルとユーザの認証資格情報を比較します。クレデンシャルが一致する場合、ユーザはネットワークへのアクセスが許可されます。クレデンシャルが一致しない場合、認証は失敗し、ネットワーク アクセスは拒否されます。
次の項目を認証するように、Cisco ASA を設定できます。
-
ASA へのすべての管理接続(この接続には、次のセッションが含まれます)
-
Telnet
-
SSH
-
シリアル コンソール
-
ASDM(HTTPS を使用)
-
VPN 管理アクセス
-
-
enable コマンド
-
ネットワーク アクセス層
-
VPN アクセス
認証
認可はポリシーを使用するプロセスです。どのようなアクティビティ、リソース、サービスに対するアクセス許可をユーザが持っているのかを判断します。ユーザが認証されると、そのユーザはさまざまなタイプのアクセスやアクティビティを認可される可能性があります。
次の項目を認可するように、ASA を設定できます。
-
管理コマンド
-
ネットワーク アクセス層
-
VPN アクセス
Accounting
アカウンティングは、アクセス時にユーザが消費したリソースを測定します。これには、システム時間またはセッション中にユーザが送受信したデータ量などが含まれます。アカウンティングは、許可制御、課金、トレンド分析、リソース使用率、キャパシティ プランニングのアクティビティに使用されるセッションの統計情報と使用状況情報のログを通じて行われます。
認証、認可、アカウンティング間の相互作用
認証だけで使用することも、認可およびアカウンティングとともに使用することもできます。認可では必ず、ユーザの認証が最初に済んでいる必要があります。アカウンティングだけで使用することも、認証および認可とともに使用することもできます。
AAA Servers
AAA サーバは、アクセス制御に使用されるネットワーク サーバです。認証は、ユーザを識別します。認可は、認証されたユーザがアクセスする可能性があるリソースとサービスを決定するポリシーを実行します。アカウンティングは、課金と分析に使用される時間とデータのリソースを追跡します。
AAA Server Groups
認証、許可、またはアカウンティングに外部 AAA サーバを使用する場合は、まず AAA プロトコルあたり少なくとも 1 つの AAA サーバ グループを作成して、各グループに 1 つ以上のサーバを追加する必要があります。AAA サーバ グループは名前で識別されます。各サーバ グループは、あるサーバまたはサービスに固有です。
次の項を参照してください。
Kerberos、SDI および HTTP フォーム用のサーバ グループも設定できます。これらのグループは VPN 設定で使用されます。これらのグループのタイプについては、『VPN 構成ガイド』を参照してください。
ローカル データベースについて
ASA は、ユーザ プロファイルを取り込むことができるローカル データベースを管理します。AAA サーバの代わりにローカル データベースを使用して、ユーザ認証、認可、アカウンティングを提供することもできます。
次の機能にローカル データベースを使用できます。
-
ASDM ユーザごとのアクセス
-
コンソール認証
-
Telnet 認証および SSH 認証
-
enable コマンド認証
この設定は、CLI アクセスにだけ使用され、Cisco ASDM ログインには影響しません。
-
コマンド許可
ローカル データベースを使用するコマンド許可を有効にすると、Cisco ASA では、ユーザ特権レベルを参照して、どのコマンドが使用できるかが特定されます。コマンド許可がディセーブルの場合は通常、特権レベルは参照されません。デフォルトでは、コマンドの特権レベルはすべて、0 または 15 のどちらかです。
-
ネットワーク アクセス認証
-
VPN クライアント認証
マルチ コンテキスト モードの場合、システム実行スペースでユーザ名を設定し、login コマンドを使用して CLI で個々にログインできます。ただし、システム実行スペースではローカル データベースを参照する AAA ルールは設定できません。
(注) |
ローカル データベースはネットワーク アクセス認可には使用できません。 |
フォールバック サポート
ローカル データベースは、複数の機能のフォールバック方式として動作できます。この動作は、ASA から誤ってロックアウトされないように設計されています。
ログインすると、コンフィギュレーション内で指定されている最初のサーバから、応答があるまでグループ内のサーバが順に 1 つずつアクセスされます。グループ内のすべてのサーバが使用できない場合、ローカル データベースがフォールバック方式(管理認証および許可限定)として設定されていると、ASA はローカル データベースに接続しようとします。フォールバック方式として設定されていない場合、ASA は引き続き AAA サーバにアクセスしようとします。
フォールバック サポートを必要とするユーザについては、ローカル データベース内のユーザ名およびパスワードと、AAA サーバ上のユーザ名およびパスワードとを一致させることを推奨します。これにより、透過フォールバックがサポートされます。ユーザは、AAA サーバとローカル データベースのどちらがサービスを提供しているかが判別できないので、ローカル データベースのユーザ名およびパスワードとは異なるユーザ名およびパスワードを AAA サーバで使用することは、指定するべきユーザ名とパスワードをユーザが確信できないことを意味します。
ローカル データベースでサポートされているフォールバック機能は次のとおりです。
-
コンソールおよびイネーブル パスワード認証:グループ内のサーバがすべて使用できない場合、ASA ではローカル データベースを使用して管理アクセスを認証します。これには、イネーブル パスワード認証が含まれる場合があります。
-
コマンド許可:グループ内の TACACS+ サーバがすべて使用できない場合、特権レベルに基づいてコマンドを認可するためにローカル データベースが使用されます。
-
VPN 認証および認可:VPN 認証および認可は、通常この VPN サービスをサポートしている AAA サーバが使用できない場合、ASA へのリモート アクセスをイネーブルにするためにサポートされます。管理者である VPN クライアントが、ローカル データベースへのフォールバックを設定されたトンネル グループを指定する場合、AAA サーバ グループが使用できない場合でも、ローカル データベースが必要な属性で設定されていれば、VPN トンネルが確立できます。
グループ内の複数のサーバを使用したフォールバックの仕組み
サーバ グループ内に複数のサーバを設定し、サーバ グループのローカル データベースへのフォールバックをイネーブルにしている場合、ASA からの認証要求に対してグループ内のどのサーバからも応答がないと、フォールバックが発生します。次のシナリオで例証します。
サーバ 1、サーバ 2 の順で、LDAP サーバ グループに 2 台の Active Directory サーバを設定します。リモート ユーザがログインすると、ASA によってサーバ 1 に対する認証が試みられます。
サーバ 1 から認証エラー(「user not found」など)が返されると、ASA によるサーバ 2 に対する認証は試みられません。
タイムアウト期間内にサーバ 1 から応答がないと(または認証回数が、設定されている最大数を超えている場合)、ASA によってサーバ 2 に対する認証が試みられます。
グループ内のどちらのサーバからも応答がなく、ASA にローカル データベースへのフォールバックが設定されている場合、ASA によってローカル データベースに対する認証が試みられます。