- はじめに
- 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日
章のタイトル： ACS 5.x ポリシー モデル
ACS 5.x ポリシー モデル
ACS 5.x は、ポリシーベースのアクセス コントロール システムです。ACS 5.x での ポリシー モデル という用語は、ポリシー管理者のポリシー要素、ポリシー オブジェクト、およびポリシー規則を表しています。ACS 5.x では、4.x バージョンで使用されていたグループベースのモデルの代わりに、規則ベース ポリシー モデルが使用されています。
（注） ACS 4.x および ACS 5.2 での概念の対応については、「ACS 4.x から ACS 5.2 への機能マッピング」を参照してください。
ACS 5.x ポリシー モデルの概要
ACS 5.x の規則ベース ポリシー モデルを使用すると、以前のグループベースの手法よりも強力で柔軟なアクセス コントロールを実現できます。
以前のグループベース モデルでは、 グループ を使用してポリシーを定義していました。これは、グループに次の 3 つのタイプの情報が結合されていたためです。
•
識別情報：この情報は、AD グループまたは LDAP グループでのメンバーシップ、または ACS 内部ユーザの静的割り当てに基づいています。
• その他の制約事項または条件：時間の制限、デバイスの制限など。
• 権限：VLAN または Cisco IOS の特権レベル。
ACS 5.x ポリシー モデルは、次の形式の 規則 に基づいています。
たとえば、グループベース モデルに関して記述されている次の情報を使用します。
If identity-condition, restriction-condition then authorization-profile
ACS 5.2 では、条件および結果をグローバルな共有オブジェクトとして定義します。これらを定義しておくと、規則を作成するときに参照できます。ACS 5.2 では、これらの共有オブジェクトに対して ポリシー要素 という用語を使用しています。ポリシー要素は、規則を作成するための構築ブロックとなります。
表 3-1 に、以前のグループに含まれていたすべての情報をさまざまなポリシー要素によって定義する方法を示します。
|
|
|
|---|---|
ポリシー は、アクセス要求を評価して決定を返すために ACS 5.x で使用される規則セットです。規則セットの例は次のとおりです。
• 認可ポリシー の規則セットでは、任意のアクセス要求に関する認可の決定が返されます。
• ID ポリシー では、任意のアクセス要求の ID アトリビュートの認証方法および取得方法が決定されます。
ACS 5.x では、独立したポリシーの順序（ポリシー ワークフロー）が アクセス サービス に編成され、アクセス要求を処理するために使用されます。複数のアクセス サービスを作成して、異なる種類のアクセス要求を処理できます。たとえば、デバイス管理アクセスやネットワーク アクセスなどです。詳細については、「アクセス サービス」を参照してください。
単純なポリシーおよび規則ベース ポリシーを定義できます。規則ベース ポリシーは、さまざまな条件をテストする複雑なポリシーです。単純なポリシーでは、条件なしですべての要求に対して単一の結果を適用します。
さまざまなタイプのポリシーの詳細については、「ポリシーのタイプ」を参照してください。
ポリシー モデルの用語の詳細については、「ポリシーの用語」を参照してください。
ポリシーの用語
表 3-2 に、規則ベース ポリシーの用語を示します。
単純なポリシー
すべての ACS ポリシーを規則ベース ポリシーとして設定できます。ただし、場合によっては、条件なしですべての要求に適用する単一の結果を選択する単純なポリシーを設定することもできます。
たとえば、さまざまな条件の規則セットを含む規則ベースの認証ポリシーを定義できます。または、内部データベースをすべての認証に使用する場合は、単純なポリシーを定義できます。
表 3-3 は、各ポリシー タイプが単純なポリシーとして設定できるかどうかを判断する場合に役立ちます。
• 単純なポリシーを作成および保存してから規則ベースのポリシーに変更すると、単純なポリシーは規則ベースのポリシーのデフォルト規則になります。
• 規則ベース ポリシーを保存してから単純なポリシーに変更した場合、ACS ではデフォルト規則が単純なポリシーとして自動的に使用されます。
規則ベース ポリシー
規則ベース ポリシーは、ID ベース ポリシーでの課題を克服するために導入されました。以前のバージョンの ACS では、ユーザ グループのメンバーシップによってメンバーにアクセス権が付与されていましたが、特定の制限も課されていました。
ユーザがアクセスを要求すると、ID ストアを使用してそのユーザのクレデンシャルが認証され、そのユーザは適切なユーザ グループに関連付けられます。認可はユーザ グループと関連付けられているため、ユーザ グループのすべてのメンバーは常に同じアクセス制限と権限を持ちます。
このタイプのポリシー（単純なポリシー）では、権限は特定のユーザ グループとのユーザの関連付けに基づいて付与されます。これは、ユーザの ID だけが主要な条件である場合に役立ちます。ただし、さまざまな条件下で異なる権限が必要なユーザの場合、このポリシーは機能しません。
ACS 5.x では、ID に関係なくさまざまな条件に基づく規則を作成できます。ユーザ グループにすべての情報が含まれるわけではありません。
たとえば、従業員がキャンパスで勤務しているときにはフル アクセスを許可し、リモートで勤務しているときにはアクセスを制限する場合は、ACS 5.2 で規則ベース ポリシーを使用してこれを実現できます。
ID 以外のさまざまな条件に基づいて権限を設定することができ、権限はユーザ グループに関連付けられなくなりました。セッション アトリビュートおよび環境アトリビュート（アクセス場所、アクセス タイプ、端末の健全性、日付、時刻など）を使用して、許可するアクセスのタイプを決定できます。
If conditions then apply the respective permissions
規則ベース ポリシーでは、条件は使用可能なセッション アトリビュートの任意の組み合せで構成可能であり、権限は認可プロファイルで定義されます。VLAN、ダウンロード可能 ACL、QoS 設定、および RADIUS アトリビュートを含めるように認可プロファイルを定義します。
ポリシーのタイプ
表 3-3 に、ACS で設定可能なポリシーのタイプを示します。
ポリシーは評価順に示されています。あるポリシーで取得されたアトリビュートは、そのポリシー以降のすべてのポリシーで使用できます。唯一の例外は、ID ストアからのアトリビュートだけを使用する ID グループ マッピング ポリシーです。
|
|
|
|
|
|
|
|---|---|---|---|---|---|
|
|
|||||
|
|
|||||
|
|
|||||
|
|
|||||
|
|
| 1.単純なポリシーでは、ACS がすべての要求に適用する単一の結果セットを指定します。つまり、実際には単一規則ポリシーです。 |
アクセス サービス
アクセス サービスは、ACS 5.x での不可欠な構成要素です。アクセス サービスを使用すると、ネットワークに接続するユーザとデバイス、およびネットワーク デバイスを管理する管理者用のアクセス ポリシーを設定できます。
ACS 5.x では、認証要求および認可要求はアクセス サービスによって処理されます。アクセス サービスは、次の要素で構成されています。
• ID ポリシー：ユーザの認証方法を指定します。パスワードの確認に使用される、許可された認証プロトコルおよびユーザ リポジトリが含まれています。
• グループ マッピング ポリシー：ユーザの ACS ID グループが、外部 ID ストアのユーザ アトリビュートまたはグループ メンバーシップに基づいてダイナミックに設定されるかどうかを指定します。ユーザの ID グループをユーザの認可の一部として使用できます。
アクセス サービスは、アクセス要求の処理に使用される、独立したポリシー セットです。
ACS 管理者は、さまざまな種類のアクセス要求の処理を明確に区別および分離するために、複数のアクセス サービスを作成できます。ACS では、次の 2 つのデフォルト アクセス サービスが提供されています。
• Default Device Admin：デバイス CLI への TACACS+ ベースのアクセスに使用
• Default Network Access：ネットワーク接続への RADIUS ベースのアクセスに使用
これらのアクセス サービスをそのまま使用したり、必要に応じて変更または削除したりできます。追加のアクセス サービスを作成することもできます。
TACACS+ プロトコルによって、認証が認可から分離されます。つまり、ACS では、TACACS+ 認証要求と認可要求が個別に処理されます。 表 3-4 に、RADIUS アクセス サービスと TACACS+ アクセス サービスのその他の相違点を示します。
|
|
|
|
|---|---|---|
TACACS+ の場合、すべてのポリシー タイプが任意ですが、1 つのサービスで少なくとも 1 つのポリシー タイプを選択する必要があります。TACACS+ の ID ポリシーを定義していない場合は、ACS によって認証要求に対して認証エラーが返されます。
同様に、認可ポリシーを定義していない場合に、ACS がセッションまたはコマンドの認可要求を受信すると、その要求は失敗します。RADIUS アクセス サービスと TACACS+ アクセス サービスの両方で、サービスの作成後、ポリシーを追加するためにサービスを変更できます。
（注） アクセス サービスにはサービス セレクション ポリシーは含まれていません。サービス セレクション規則は独立して定義されています。
複数のアクセス サービス（さまざまな使用例、ネットワーク、地域、管理ドメイン用のサービスなど）を保持および管理できます。サービス セレクション ポリシーを設定します。サービス セレクション ポリシーとは、各新規アクセス要求を適切なアクセス サービスに送信するサービス セレクション規則セットのことです。
表 3-5 に、アクセス サービス セットの例を示します。
|
（デバイス管理用） |
（802.1X エージェントレス ホストへのアクセス用） |
（802.1X 有線および無線デバイスからのアクセス用） |
|---|---|---|
表 3-6 に、サービス セレクション ポリシーを示します。
|
|
|
|
|---|---|---|
ACS 5.2 は、TACACS+ アクセス要求を受信すると、ID ポリシー A に従って要求を認証するアクセス サービス A を適用します。その後、シェル/コマンド認可ポリシーに従って認可および権限を適用します。このサービスによって、すべての TACACS+ 要求が処理されます。
ACS 5.2 は、ホスト ルックアップであると判断した RADIUS 要求（たとえば、RADIUS の service-type アトリビュートが call-check と同一）を受信すると、ID ポリシー C に従って認証するアクセス サービス C を適用します。その後、セッション認可ポリシー C に従ってセッション認可プロファイルを適用します。このサービスによって、すべてのホスト ルックアップ要求（MAC 認証バイパス要求とも呼ばれる）が処理されます。
アクセス サービス B によって、その他の RADIUS 要求が処理されます。このアクセス サービスでは、ID ポリシー B に従って認証が行われ、セッション認可ポリシー B が適用されます。このサービスによって、上記の規則で処理されるホスト ルックアップを除き、すべての RADIUS 要求が処理されます。
ACS では、新しいサービスを作成するときにテンプレートとして使用できる定義済みのアクセス サービスが提供されています。アクセス サービス テンプレートを選択すると、ACS によって、ポリシー セットが含まれたアクセス サービスが作成され、それぞれのサービスにカスタマイズされた条件セットが設定されます。
サービスにポリシーを追加したり、サービスからポリシーを削除したりすることにより、アクセス サービスの構造を変更できます。また、ポリシー条件セットを変更することにより、ポリシーの構造を変更することもできます。アクセス サービス テンプレートおよび説明のリストについては、「アクセス サービス テンプレートの設定」を参照してください。
ACS 5.2 は、RADIUS および RADIUS プロキシ サーバとして機能します。ACS がプロキシ サーバとして機能する場合、NAS から認証要求およびアカウンティング要求を受信し、これらの要求を外部 RADIUS サーバに転送します。
ACS は要求の結果を受け入れて NAS に返します。ACS で RADIUS サーバに要求が転送されるように、外部 RADIUS サーバを ACS で設定する必要があります。タイムアウト時間および接続試行回数を定義できます。
ACS プロキシのリモート ターゲットは、次のパラメータを含むリモート RADIUS サーバのリストです。
• ユーザ名からのプレフィックス/サフィックスのストリッピング
RADIUS プロキシ サーバは、要求を受信すると、リスト内の最初のリモート RADIUS サーバにその要求を転送します。プロキシ サーバは、指定されたタイムアウト間隔および試行回数内に応答を受信しない場合、その要求をリスト内の次の RADIUS サーバに転送します。
最初の応答をリスト内のいずれかのリモート RADIUS サーバから受信すると、プロキシ サービスによってその応答が処理されます。応答が有効な場合は、ACS によってその応答が NAS に戻されます。
表 3-7 に、ACS 4.2 リリースと 5.2 リリース間での RADIUS プロキシ サービスの相違点を示します。
|
|
|
|
|---|---|---|
ACS は、同時に複数の外部 RADIUS サーバへのプロキシ サーバとして動作できます。ACS がプロキシ サーバとして機能するには、ACS で RADIUS プロキシ サービスを設定する必要があります。RADIUS プロキシ サービスの設定方法については、「アクセス サービスの一般プロパティの設定」を参照してください。
RADIUS 要求のプロキシ処理の詳細については、「RADIUS プロキシ要求」を参照してください。
ID ポリシー
次の 2 つの主要メカニズムによって、要求の認証に使用されるメカニズムとソースが定義されます。
• パスワードベース：ユーザがユーザ名とパスワードを入力したあと、データベースに照らして認証が実行されます。MAC アドレスを指定することにより、ホストでこの認証をバイパスできます。ただし、ID ポリシー認証の場合は、ホスト ルックアップもパスワードベースであると見なされます。
• 証明書ベース：クライアントがセッション認証用の証明書を提示します。ACS 5.2 では、証明書ベースの認証は、EAP-TLS プロトコルを選択すると発生します。
また、要求内のプリンシパルのアトリビュートを取得するためにデータベースを使用できます。
ID ソースは、ID ポリシーの 1 つの結果であり、次のいずれかのタイプになります。
• アクセス拒否：ユーザへのアクセスは拒否され、認証は実行されません。
• ID データベース：単一の ID データベース。ID ポリシーの結果として単一の ID データベースが選択された場合、外部データベース（LDAP や AD）または内部データベース（ユーザやホスト）のいずれかが結果として選択されます。
選択されたデータベースを使用してユーザ/ホストの認証が行われ、そのユーザ/ホストに関してデータベースに格納されている定義済みアトリビュートが取得されます。
• 証明書認証プロファイル：証明書の構造および内容が含まれており、具体的には証明書アトリビュートを内部ユーザ名にマッピングします。証明書ベースの認証の場合は、証明書認証プロファイルを選択する必要があります。
証明書ベースの要求の場合、証明書を使用して自身を特定するエンティティは、証明書に格納されている公開キーに関連付けられている秘密キーを保持します。証明書認証プロファイルでは、次のことを定義することにより、基本的な PKI 処理が拡張されています。
– ユーザ名の定義に使用される証明書アトリビュート。証明書アトリビュートのサブセットを選択して、要求のコンテキストにユーザ名フィールドを読み込むことができます。このユーザ名は、要求の残りのユーザを識別する場合に使用されます。ログで使用される識別情報にも使用されます。
– 証明書の失効ステータスの確認に使用される LDAP または AD データベース。LDAP または AD データベースを選択すると、証明書データが LDAP または AD データベースから取得され、クライアントが入力したデータに照らして比較されて、クライアント証明書の追加確認が行われます。
• ID 順序：ID データベースの順序。この順序は認証に使用されます。追加の順序が指定されている場合は、その追加順序を使用してアトリビュートだけが取得されます。ID ポリシーの結果として複数の ID 方式を選択できます。ID 方式を ID 順序オブジェクトで定義します。ID 順序には任意のタイプの方式を含めることができます。
ID 順序には 2 つのコンポーネントがあります。1 つは認証用であり、もう一つはアトリビュート取得用です。管理者は、証明書および ID データベースのいずれか、またはその両方に基づいて認証を実行できます。
– 証明書に基づいて認証を実行する場合は、ACS によって単一の証明書認証プロファイルが選択されます。
– ID データベースに基づいて認証を実行する場合は、認証が成功するまで順番にアクセスされるデータベースのリストを定義する必要があります。認証が成功すると、データベース内の定義済みアトリビュートが取得されます。
また、任意のデータベース リストを定義して、そこから追加アトリビュートを取得することもできます。これらの追加データベースには、使用された認証がパスワードベースであるか証明書ベースであるかに関係なく、アクセスできます。
証明書ベースの認証が使用された場合、ユーザ名フィールドは、証明書アトリビュートから読み込まれ、アトリビュートの取得に使用されます。リストで定義されているすべてのデータベースにアクセス可能であり、ユーザに一致するレコードが見つかった場合は、対応するアトリビュートが取得されます。
ユーザのパスワードに要変更のマークが付いている場合でも、またはユーザ アカウントがディセーブルになっている場合でも、そのユーザのアトリビュートを取得できます。ユーザのアカウントをディセーブルにした場合でも、そのユーザのアトリビュートはアトリビュート ソースとして引き続き使用できます。ただし、認証には使用できません。
ID ポリシーの処理中にエラーが発生した場合、そのエラーは次の 3 つの主要タイプのいずれかになります。
• Authentication failed：ACS は、認証が失敗したことを示す明示的な応答を受信します。たとえば、正しくないユーザ名やパスワードが入力された場合、またはユーザがディセーブルにされた場合があります。
• User/host not found：指定されたユーザ/ホストが認証データベースで見つかりませんでした。
• Process failed：定義されたデータベースへのアクセス中にエラーが発生しました。
ID データベースから返されたすべてのエラーは、上記のいずれかのタイプになります。各エラー タイプに対して、次のオプションを設定できます。
• Continue：ACS によって、サービスで定義されている次のポリシーに対して処理が続行されます。
認証ステータス システム アトリビュートで、ID ポリシー処理の結果が保持されます。エラーの発生時にポリシー処理の続行を選択した場合は、後続のポリシー処理でこのアトリビュートを条件として参照して、ID ポリシー処理が成功しなかった場合を区別できます。
使用される基本プロトコルでの制限が原因で、[Continue] オプションを選択しても処理を続行できない場合があります。このことは PEAP、LEAP、および EAP-FAST の場合に該当し、[Continue] オプションを選択しても要求は拒否されます。
規則を作成する場合、次のデフォルト値をエラー オプションに使用できます。
• Authentication failed：デフォルトは reject です。
グループ マッピング ポリシー
ID グループ マッピング ポリシーは、標準ポリシーです。条件は、外部アトリビュート ストアだけ、または証明書から取得されるアトリビュートまたはグループに基づきます。結果は ID グループ階層内の ID グループになります。
ID ポリシーが内部ユーザまたはホスト ID ストアにアクセスすると、対応するユーザまたはホスト レコードから ID グループが直接設定されます。この処理は、グループ マッピング ポリシーの暗黙的な処理部分です。
したがって、このデフォルト規則は、グループ マッピング ポリシーの処理の一部として、次の条件が両方とも満たされる場合にだけ適用されます。
• グループ マッピング テーブル内のいずれの規則も一致しない。
• ID グループが内部ユーザまたはホスト レコードから設定されていない。
グループ マッピング ポリシーの結果は、システム ディクショナリ内の IdentityGroup アトリビュートに格納され、[Identity Group] 条件を選択することにより、ポリシーにこのアトリビュートを含めることができます。
デバイス管理用の認可ポリシー
シェル プロファイルによってデバイス CLI へのアクセスが決まります。コマンド セットによってコマンド認可ごとの TACACS+ が決まります。デバイス管理アクセス サービス用の認可ポリシーでは、単一のシェル プロファイルおよび複数のコマンド セットを含めることができます。
複数のコマンド セットを持つ規則の処理
認可ポリシーに複数のコマンド セットを持つ規則が含まれている場合は、ACS によってアクセス要求内のコマンドが処理される方法を理解することが重要です。規則の結果に複数のコマンド セットが含まれており、その規則の条件がアクセス要求に一致した場合、ACS では、その規則内の各コマンド セットに照らしてアクセス要求内のコマンドが処理されます。
1. コマンド セットにコマンドとその引数との一致が含まれる場合、その一致が Deny Always であると、ACS によってそのコマンド セットは Commandset-DenyAlways として指定されます。
2. コマンド セット内のコマンドの一致に Deny Always がない場合は、最初の一致が見つかるまで、コマンド セット内のすべてのコマンドが順番にチェックされます。
– 最初の一致が Permit である場合、そのコマンド セットは Commandset-Permit として指定されます。
– 最初の一致が Deny である場合、そのコマンド セットは Commandset-Deny として指定されます。
3. ACS は、すべてのコマンド セットを分析したあと、コマンドを次のように認可します。
a. コマンド セットが Commandset-DenyAlways として指定された場合、ACS によってそのコマンドは拒否されます。
b. Commandset-DenyAlways がない場合、コマンド セットが Commandset-Permit である場合はそのコマンドが許可されます。そうでない場合、そのコマンドは拒否されます。
認可ポリシーの例外規則
現実世界での一般的な問題は、日々の運用で、ポリシーの免除または例外を許可する必要が頻繁に発生することです。特定のユーザが、特殊なアクセスを短期間必要とする場合があります。または、あるユーザが休暇中の他のユーザの代理を務めるために追加のユーザ権限を必要とする場合があります。
ACS では、認可ポリシーの例外ポリシーを定義できます。例外ポリシーには、ポリシーの例外および免除用の個別のポリシー セットが含まれています。これらは、通常、臨時および一時的なものです。例外規則は、主要規則テーブルの規則よりも優先されます。
例外規則では、主要ポリシーとは異なる条件および結果セットを使用できます。たとえば、主要ポリシーでは ID グループおよび場所を条件として使用するが、関連する例外ポリシーでは異なる条件を使用する場合があります。例外ポリシーでは、デフォルトで複合条件および時刻と日付の条件が使用されます。時刻と日付の条件は、例外規則に明確な開始時刻と終了時刻を設定する必要がある場合は特に重要となります。
例外ポリシーは、主要ポリシーよりも優先されます。例外ポリシーには、例外ポリシー独自のデフォルト規則は必要ありません。例外ポリシーで一致が見つからなかった場合は、独自のデフォルト規則を持つ主要ポリシーが適用されます。
例外を使用すると、標準ポリシーの一時的変更に対処できます。たとえば、あるグループの管理者 John が休暇中で、別のグループの管理者 Bob がその代理を務める場合、 John と同じアクセス権を休暇の間 Bob に付与する例外規則を作成できます。
サービス セレクション ポリシー
ACS では、さまざまなアクセス要求を受信すると、サービス セレクション ポリシーを使用してこれらの要求が処理されます。次の 2 つのモードのサービス セレクションが提供されています。
単純なサービス セレクション
単純なサービス セレクション モードでは、ACS によってすべての AAA 要求が 1 つのアクセス サービスを使用して処理されます。実際にはサービスは選択されません。
規則ベースのサービス セレクション
規則ベースのサービス セレクション モードでは、さまざまな設定可能オプションに基づいて、使用するアクセス サービスが決定されます。オプションの一部を次に示します。
• AAA Protocol：要求に使用されるプロトコル。TACACS+ または RADIUS です。
• Request Attributes：要求内の RADIUS アトリビュートまたは TACACS+ アトリビュート。
• Date and Time：ACS が要求を受信した日付および時刻。
• Network Device Group：AAA クライアントが属しているネットワーク デバイス グループ。
• AAA Client：要求を送信した AAA クライアント。
• Network condition objects：ネットワーク条件の基になるもの。
– Device Port：この条件では、デバイス以外に、端末が関連付けられているポートもチェックされます。
ポリシー条件の詳細については、「ポリシー条件の管理」を参照してください。
ACS は、2 つのデフォルト アクセス サービス（Default Device Admin および Default Network Access）を使用して事前設定されています。規則ベースのサービス セレクション モードは、AAA プロトコルを選択基準として使用するように設定されています。このため、TACACS+ 要求を受信した場合は Default Device Admin サービスが使用され、RADIUS 要求を受信した場合は Default Network Access サービスが使用されます。
アクセス サービスおよびサービス セレクションのシナリオ
ACS を使用すると、組織では、複数のシナリオ（有線、無線、リモート VPN、デバイス管理など）で ID 要件およびアクセス コントロール要件を管理できます。アクセス サービスは、これらのさまざまなシナリオをサポートする場合に主要な役割を果たします。
アクセス サービスを使用すると、独立した個別のネットワーク アクセス ポリシーを作成して、さまざまなネットワーク アクセス シナリオにおける固有のポリシー要件に対処できます。さまざまなシナリオに対して個別のポリシーを使用すると、組織のネットワークをより適切に管理できます。
たとえば、デバイス管理とネットワーク アクセスに使用するデフォルトのアクセス サービスには、ネットワーク デバイスにアクセスするネットワーク管理者と、企業のネットワークにアクセスする組織のスタッフとの典型的な区別がポリシーに反映されています。
ただし、複数のアクセス サービスを作成すると、さまざまな管理ドメインを区別できます。たとえば、アジア太平洋地域での無線アクセスを、ヨーロッパのユーザによる無線アクセスを管理しているチームとは異なるチームが管理できます。この場合、次のアクセス サービスが必要となります。
• APAC ワイヤレス：アジア太平洋地域のワイヤレス ユーザ用のアクセス サービス。
• ヨーロッパ ワイヤレス：ヨーロッパ諸国のワイヤレス ユーザ用のアクセス サービス。
追加のアクセス サービスを作成することにより、単一のアクセス サービス内に複数のポリシーが存在する複雑な状況を軽減できます。このためには、複数のアクセス サービス間で複合ポリシーを作成します。たとえば、大規模な組織で 802.1x ネットワーク アクセスを展開する場合、次のアクセス サービスが可能となります。
• 802.1x：常勤スタッフのマシン、ユーザ パスワード、および証明書ベースの認証用。
• エージェントレス デバイス：電話やプリンタなど、EAP サプリカントを持たないデバイス用。
• ゲスト アクセス：ゲスト無線ネットワークにアクセスするユーザ用。
この例では、802.1x、エージェントレス デバイス、およびゲスト アクセス用のネットワーク アクセス ポリシーを 1 つのアクセス サービスで作成する代わりに、このポリシーを 3 つのアクセス サービスに分割します。
最初の一致規則テーブル
ACS 5.2 では、規則セットを評価するための最初の一致規則テーブルを使用してポリシーを決定できます。規則テーブルには条件および結果が含まれています。条件は、単純または複合のいずれかとなります。単純な条件は、アトリビュート演算子値で構成され、True または False のいずれかとなります。複合条件には、AND または OR 演算子で結合された、より複雑な条件が含まれています。詳細については、「ポリシーの条件」を参照してください。
管理者は、ポリシーに含める単純な条件を選択します。これらの条件は規則テーブルでカラムとして表示されます。規則テーブルでは、カラム見出しは条件の名前になり、通常はアトリビュートの名前です。
規則はカラム見出しの下に表示され、各セルには、条件を形成するためにアトリビュートと結合される演算子および値が表示されます。 ANY の場合、図 3-1に定義済みの条件タイプが含まれているカラムベースの規則テーブルを示します。
デフォルト規則では、他の規則が存在しないか、またはアクセス要求内のアトリビュート値が規則と一致しない場合に ACS で使用されるポリシー結果が指定されています。
ACS は、現在のアクセス要求に関連付けられているアトリビュート値を、規則で表されている条件セットと比較することによって、最初の一致規則テーブル内の規則セットを評価します。
• アトリビュート値が条件に一致しない場合、ACS は規則テーブル内の次の規則に進みます。
• アトリビュート値が条件と一致すると、その規則で指定されている結果が ACS によって適用され、残りの規則はすべて無視されます。
ポリシーの条件
次の条件内のアトリビュートに基づいて、単純な条件を規則テーブルに定義できます。
• Customizable conditions：ACS が認識するプロトコル ディクショナリおよび ID ディクショナリに基づいたカスタム条件を作成できます。ポリシー規則ページでカスタム条件を定義します。個別の条件オブジェクトとして定義することはできません。
• Standard conditions：デバイス IP アドレス、プロトコル、ユーザ名関連のフィールドなど、常に使用可能なアトリビュートに基づいた標準条件を使用できます。
ポリシーの結果
ポリシー規則には、ポリシーのタイプに応じた結果情報が含まれています。独立した共有オブジェクトとしてポリシーの結果を定義します。ポリシーの結果はユーザまたはユーザ グループの定義には関連付けられません。
たとえば、認可ポリシー用の認可結果と権限結果を定義するポリシー要素を次に示します。
• ID ポリシーの結果としての ID ソースおよびエラー オプション。「ネットワーク アクセスの認可プロファイル」を参照してください。
• グループ マッピングの ID グループ。「グループ マッピング ポリシー」を参照してください。
• Cisco TrustSec のセキュリティ グループおよびセキュリティ グループ Access Control List（ACL; アクセス コントロール リスト）。「ACS および Cisco TrustSec」を参照してください。
その他のポリシー結果については、「認可および権限の管理」を参照してください。
ネットワーク アクセスの認可プロファイル
認可プロファイルでは、認可の成功後に ACS によってユーザに返される RADIUS アトリビュート セットを定義します。アクセス認可情報には、認可特権と権限、およびダウンロード可能 ACL などのその他の情報が含まれています。
複数の認可プロファイルをネットワーク アクセス ポリシー結果として定義できます。この方法では、規則の結果として認可プロファイルを組み合せて使用できるため、個々のプロファイルで組み合せ自体をすべて保持するよりも、保持する認可プロファイルの数が少なくなります。
複数の認可プロファイルを含む規則の処理
セッション認可ポリシーには、複数の認可プロファイルを持つ規則を含めることができます。認可プロファイルには、一般情報（名前と説明）および RADIUS アトリビュートだけが含まれています。複数の認可プロファイルを使用した場合は、ACS によってそれらのプロファイルが単一のアトリビュート セットにマージされます。特定のアトリビュートの出現状況によって、次のように処理されます。
• 結果として生成される認可プロファイルの 1 つだけに出現する場合、アトリビュートはその認可結果に含められます。
• 結果プロファイルに複数回出現する場合は、結果セットで最初に出現したプロファイル内のアトリビュート値に基づいて、認可結果のアトリビュート値が決定されます。
たとえば、VLAN が最初のプロファイルに出現する場合、リスト内の 2 番めまたは 3 番めのプロファイルに出現する VLAN よりも優先されます。
（注） 複数の認可プロファイルを使用する場合は、優先順位の高い順に並べる必要があります。
プロトコル ディクショナリ内の RADIUS アトリビュート定義では、アトリビュートが応答で 1 回だけ出現するか、または複数回出現するかを指定します。いずれの場合も、応答でアトリビュート値が何回出現するかにかかわらず、ACS によって、1 つのプロファイルだけから任意のアトリビュートの値が取得されます。唯一の例外は、Cisco Attribute Value（AV）ペアです。このペアは、結果に含まれるすべてのプロファイルから取得されます。
ポリシーおよび ID アトリビュート
ID ストアには、ポリシー条件の一部として、認可結果で使用できる ID アトリビュートが含まれています。ポリシーを作成するときに、ID アトリビュートおよびユーザ アトリビュートを参照できます。
これにより、認可規則内の権限にグループを直接マッピングする際の柔軟性が高まります。ACS がユーザまたはホストの要求を処理するときに、ID アトリビュートが取得され、認可ポリシー条件で使用できるようになります。
たとえば、ACS 内部ユーザの ID ストアを使用する場合、その内部ユーザの ID グループを参照したり、その内部ユーザのアトリビュートを参照したりできます（ACS では、内部 ID ストア レコード用に追加のカスタム アトリビュートを作成できることに注意してください）。
外部 Active Directory（AD）を使用している場合は、AD グループを認可規則で直接参照できます。また、AD ユーザ アトリビュートを認可規則で直接参照できます。ユーザ アトリビュートには、ユーザの部門またはマネージャのアトリビュートが含まれている場合があります。
ポリシーおよびネットワーク デバイス グループ
ネットワーク デバイス グループ（NDG）をポリシー条件として参照できます。ACS では、デバイスの要求を受信すると、そのデバイスと関連付けられている NDG が取得され、ポリシー テーブルの NDG に照らして比較されます。この方法を使用すると、複数のデバイスをグループ化し、同じポリシーを割り当てることができます。たとえば、特定の場所にあるすべてのデバイスをグループ化して、同じポリシーを割り当てることができます。
ネットワーク デバイスからネットワークへのアクセス要求を受信すると、ACS はネットワーク デバイス リポジトリを検索して、IP アドレスが一致するエントリを見つけます。その IP アドレスを使用して ACS が識別したデバイスから要求を受信した場合、ACS はそのデバイスに関連付けられているすべての NDG を取得します。
規則ベース ポリシーの例
次の例に、ポリシー要素を使用してポリシー規則を作成する方法を示します。
ある企業では、ネットワークを 2 つの地域（East および West）に分割しており、各地域にネットワーク操作エンジニアが常駐しています。エンジニアは、次のことを可能にするアクセス ポリシーを作成します。
ACS 5.2 ポリシー モデルを次の目的のために使用できます。
• East および West のネットワーク デバイス グループを定義し、ネットワーク デバイスを該当するグループに割り当てる。
• East および West の ID グループを定義し、ユーザ（ネットワーク エンジニア）を該当するグループにマップする。
• フル アクセスまたは読み取り専用の認可プロファイルを定義する。
• ネットワーク デバイス グループの場所に応じて各 ID グループにフル アクセスまたは読み取り専用アクセスを許可する規則を定義する。
これを行う前に、2 つのユーザ グループ（エンジニアが常駐する場所ごとに 1 つのグループ。それぞれのグループに権限に関する個別の定義などが設定されます）を作成しておく必要があります。この定義では、規則ベース モデルのような柔軟性や細かさは提供されません。
図 3-2 に、ポリシー規則テーブルの例を示します。
最後のデフォルト規則を除き、各規則には 2 つの条件（ID グループと場所）および結果（認可プロファイル）が含まれています。ID グループは ID ベースの分類であり、場所は非 ID 条件です。認可プロファイルには、セッションの権限が含まれています。
サービスおよびポリシーの設定フロー
表 3-8 に、サービスとポリシーを設定する場合の、推奨される基本フローを示します。このフローには、ユーザ定義の条件およびアトリビュートの設定は含まれていません。このフローでは、NDG、ID グループ、および複合条件を規則で使用できます。
サービスおよびポリシーを設定する前に、次のことを実行しておく必要があります。
• ACS へのネットワーク リソースの追加、およびネットワーク デバイス グループの作成。「ネットワーク デバイス グループの作成、複製、および編集」および「ネットワーク デバイスおよび AAA クライアント」を参照してください。
• 内部 ACS ID ストアへのユーザの追加、または外部 ID ストアの追加。「内部ユーザの作成」、「ID アトリビュートの管理」、または「外部 LDAP ID ストアの作成」を参照してください。
|
|
|
|
|---|---|---|
| • • • |
||
（任意）カスタム条件をポリシー規則に定義します。このステップは、ステップ 6 でポリシー規則を定義する前に実行できます。つまり、規則の作成中にカスタム条件を定義できます。「カスタム セッション条件の作成、複製、および編集」を参照してください。 |
||
アクセス サービスを作成します。構造および許可プロトコルだけを定義します。ポリシーについてはまだ定義する必要はありません。「アクセス サービスの作成、複製、および編集」を参照してください。 |
||
要求に使用するアクセス サービスを決定するために、規則をサービス セレクション ポリシーに追加します。次の章を参照してください。 |
||
ID ポリシーを定義します。要求の認証に使用する ID ストアまたは順序を選択し、ID アトリビュートを取得します。 「ユーザおよび ID ストアの管理」 を参照してください。 |
||
フィードバック