Cisco ISE アップグレードの概要
Cisco ISE アップグレードの概要
このマニュアルは、Cisco ISE アプライアンスおよび仮想マシンで Cisco Identity Services Engine（ISE）ソフトウェアをリリース 2.3 にアップグレードする方法について説明します。
Cisco ISE 展開のアップグレードは複数段階のプロセスであり、このマニュアルで指定されている順序で実行する必要があります。最小限のダウンタイムでのアップグレードを計画するには、このマニュアルで示されている推定所要時間を使用します。PSN グループに複数の PSN を含む展開では、ダウンタイムはありません。アップグレード対象の PSN で認証されるエンドポイントがあった場合は、要求はノード グループ内の別の PSN で処理されます。エンドポイントは、認証の成功後に再認証されて、ネットワーク アクセスが付与されます。
スタンドアロン展開または PSN が単一の展開の場合は、PSN のアップグレード中すべての認証にダウンタイムが発生する可能性があります。
次のリリースはすべて、リリース 2.3 に直接アップグレードできます。
-
Cisco ISE、リリース 2.0
-
Cisco ISE、リリース 2.0.1
-
Cisco ISE、リリース 2.1
-
Cisco ISE、リリース 2.2
 （注） | Cisco ISE リリース 2.3 以降では、すべてのネットワーク アクセス ポリシーとポリシー セットを置き換える、新しい拡張された [ポリシーセット（Policy Sets）] ページが提供されます。以前のリリースからリリース 2.3 以降にアップグレードすると、すべてのネットワーク アクセス ポリシーの設定（認証および承認の条件、ルール、ポリシー、プロファイル、および例外を含む）が ISE GUI の新しい [ポリシーセット（Policy Sets）] 領域に移行されます。変更の詳細については、新規ポリシー モデル を参照してください。 |
Cisco ISE リリース 2.0 より前のバージョンの場合は、はじめに上記のリリースのいずれかにアップグレードしてから、リリース 2.3 にアップグレードする必要があります。
アップグレード バンドルは Cisco.com からダウンロードすることができます。リリース 2.3 では、次のアップグレード バンドルを使用できます。
-
ise-upgradebundle-2.0.x-to-2.3.0.x.SPA.x86_64.tar.gz：リリース 2.0 または 2.0.1 から 2.3 にアップグレードするには、このバンドルを使用します。
-
ise-upgradebundle-2.3.0.x.SPA.x86_64.tar.gz：リリース 2.1 または 2.2 から 2.3 にアップグレードするには、このバンドルを使用します。
Cisco ISE のこのリリースでは、GUI ベースおよび CLI ベース両方のアップグレードをサポートします。
管理者用ポータルからの GUI ベースのアップグレードは、現在リリース 2.0 以降で、リリース 2.3 にアップグレードする場合にのみサポートされます。詳細については、GUI からの Cisco ISE 展開のアップグレードを参照してください。
Cisco ISE の CLI からは、リリース 2.0、2.0.1、2.1、または 2.2 からリリース 2.3 に直接アップグレードできます。詳細については、CLI からの Cisco ISE 展開のアップグレードを参照してください。
新規ポリシー モデル
認証、許可、例外を含むすべてのネットワーク アクセス ポリシーとポリシー セットが、[ポリシー（Policy）] > [ポリシー セット（Policy Sets）] からアクセスできる改良された [ポリシーセット（Policy Sets）] 領域で統合されました。各ポリシー セットは、ポリシー階層の最上位レベルで定義されたコンテナであり、その下にそのセットのすべての関連する認証および許可ポリシーおよびポリシー例外ルールが設定されます。
すべて条件に基づいて、認証と許可の両方に複数のルールを定義できます。また、条件とその他の関連設定に簡単にアクセスして、新しいポリシー セット インターフェイスから直接再利用できるようになりました。ポリシー セットが照合される順序は、新しいインターフェイスに表示される順序によって決定され、[ポリシー セット（Policy Set）] テーブルの最初の行から開始され、一致が見つかるまでチェックが続行されます。一致するものが見つからない場合は、システムのデフォルト ポリシー セットが使用されます。同じ論理を使用して正しい認証ルールの照合と選択が行われ、次に正しい許可ルールの照合と選択が行われます。各テーブルの先頭から開始し一致が見つかるまで各ルールがチェックされます。一致する他のルールがない場合は、デフォルト ルールが使用されます。
新しいポリシー モデルは、古いユーザ インターフェイスを使用して以前のバージョンで追加された可能性のあるすべてのポリシーを表しますが、ネットワーク アクセスを論理的に管理できる大幅に簡素化された改良済みのインターフェイスが提供されます。
スタンドアロンの認証および許可ポリシーの変更
スタンドアロンの認証ルールを使用する場合、ISE 2.2 以下のバージョンからのルールは新しいポリシー モデルに変換されます。認証ルールに割り当てられている許可されたプロトコルに基づいて、2 つの個別のシナリオがあります。
-
システム内のすべての「外部パート」に、デフォルト パートを含む同じ許可されたプロトコルが割り当てられている場合、すべての元の認証ルールは次のように ISE 2.3 以降に変換されます。
すべての「外部パート」は、新しいポリシー モデルの単一のポリシー セットに変換されます。新しいポリシー セットはデフォルトと呼ばれ、ポリシー セット レベルでは条件が定義されず、統一された許可プロトコルが割り当てられます。すべての内部パートは、新しいデフォルト ポリシー セット内の認証ポリシーの一部としてルールに変換されます。
次の表に、同じ許可されたプロトコルを使用する古いスタンドアロン認証ルールのセットの変換を示します（シナリオ 1）。この表では、各行の形式は次のとおりです。
名前（条件/結果）
たとえば認証外部パート 1（外部条件/許可されるプロトコル A）の場合：
-
名前：認証外部パート 1
-
条件：外部条件
-
結果：許可されるプロトコル A
-
-
システム内の「外部パート」の少なくとも 1 つに、デフォルト パートなどの他の部分とは異なる許可されたプロトコルが割り当てられている場合、すべての元の認証ルールは次のように 2.3 以降に変換されます。
各「外部パート」は、新しいポリシー モデルの個別のポリシー セットに変換されます。新しいポリシー セットは、その特定の新しいセットの元の外部パートの名前に基づいて名前が付けられます。各ポリシー セットのポリシー セット レベルでは、元の外部パートの条件と許可されたプロトコルが割り当てられます。各外部パートのすべての内部パートは、新しいポリシー セット内の認証ポリシーの一部として 1 対 1 で認証ルールに変換されます。
次の表に、異なる許可されたプロトコルを使用する古いスタンドアロン認証ルールのセットの変換を示します（シナリオ 2）。この表では、各行の形式は次のとおりです。
名前（条件/結果）
たとえば認証外部パート 1（外部条件/許可されるプロトコル A）の場合：
-
名前：認証外部パート 1
-
条件：外部条件
-
結果：許可されるプロトコル A
-
ポリシー セットの変更
以前のバージョンから ISE 2.3 以降にアップグレードする場合、表示される新しいポリシー セットはここで説明する古い ISE バージョンの場合とは異なりますが、動作はまったく同じままです。
次の図は、Cisco ISE 2.3 へのアップグレード後のポリシー セットの変更を示しています。
ISE 2.2 以下のバージョンからのポリシーは、新しいポリシー モデルに変換されます。認証ルールに割り当てられている許可されたプロトコルに基づいて、2 つの個別のシナリオがあります。
-
単一のポリシー セット内のすべての「外部パート」に同じ許可されたプロトコルが割り当てられている場合、元のポリシー セットはすべて次のように ISE 2.3 以降に変換されます。
-
すべての「外部パート」は、新しいポリシー モデルの単一のポリシー セットに変換されます。新しいポリシー セットは、元のポリシー セットと同じ名前になります。たとえば、古いモデルでポリシー セットの名前が「全従業員」になっている場合、新しいモデルでも「全従業員」と呼ばれます。
次の表に、同じ許可されたプロトコルを使用する認証ルールを含む古いポリシー セットの変換を示します（シナリオ 1）。この表では、各行の形式は次のとおりです。
名前（条件/結果）
たとえば認証外部パート 1（外部条件/許可されるプロトコル A）の場合：
-
名前：認証外部パート 1
-
条件：外部条件
-
結果：許可されるプロトコル A
-
-
新しくアップグレードされたポリシー セットには、元のポリシー セットからの外部条件と内部条件を組み合わせて変換される認証ルールのリストが含まれています。変換中に作成されるそれぞれの新しい認証ルールは、内部パートの名前を含むサフィックス付きの古い外部パートの名前に基づいて名前が付けられます。たとえば、上記の表のように、古いポリシー セットが「ポリシー セット A」と呼ばれ、その認証の「外部パート」の 1 つが外部パート 1 と呼ばれ、認証の「内部パート」の 1 つが内部パート 1 と呼ばれている場合、新しく作成された認証ルールは、ポリシー セット A 内で「外部パート 1：内部パート 1」と呼ばれます。同様に、古いポリシー セットが「全従業員」ポリシー セットと呼ばれ、その認証の「外部パート」の 1 つがロンドンと呼ばれ、認証の「内部パート」の 1 つが「有線 MAB」と呼ばれている場合、新しく作成された認証ルールは「全従業員」ポリシー セット内で「ロンドン：有線 MAB」と呼ばれます。認証ポリシーのデフォルトの外部パートは、デフォルトの認証ルールとして変換されます。システムのデフォルト ポリシー ルールは、作成または変換された他のルールに関係なく、認証テーブル全体の最後のルールとして表示され、このルールは移動または削除できません。
-
外部パートに定義された条件（それに基づいて認証ルールが照合されます）は、内部パートの条件（認証に使用される ID ストアを示す）と組み合わされます。新しい結合条件は、新しいモデルのポリシー セット内の単一の認証ルールで設定されます。ポリシー セット内の新しい個別ルールは、古いポリシー セットの個別の外部パートごとに作成されます。
-
-
ポリシー セット内の「外部パート」に対して 2 つ以上の許可されたプロトコルが選択されている場合、元のポリシー セットはすべて次のように ISE 2.3 以降に変換されます。
-
古いポリシー セット内の各認証ルールの各「外部パート」は、新しいモデルで新しい個別のポリシー セットに変換されます。この新しいポリシー セットは、新しいポリシー モデルの [認証ポリシー（Authentication Policy）] セクションの下にある同じ元の「外部パート」から「条件」を配置します。
次の表に、ISE 2.2 以前のバージョンから ISE 2.3 以降への古いポリシー セットの変換を示します（シナリオ 2）。
-
変換時に作成される新しいポリシー セットは、外部パート名を含むサフィックスを使用して抽出された古いポリシー セットの名前に基づいて名前が付けられます。たとえば、上記の表のように、古いポリシー セットが「ポリシー セット A」と呼ばれ、その認証の「外部パート」の 1 つが外部パート 1 と呼ばれている場合、新しく作成されたポリシー セットは「ポリシー セット A：外部パート 1」と呼ばれます。同じように、古いポリシー セットが「ロンドン」と呼ばれ、その認証の「外部パート」の 1 つが有線 MAB と呼ばれている場合、新しく作成されたポリシー セットは「ロンドン：有線 MAB」と呼ばれます。
古い各ポリシー セットのデフォルトの外部パートも、「ロンドン：デフォルト」などのように、他のすべての外部パートと同様に新しいポリシー セットに変換されます。システム デフォルト ポリシー セットは、作成または変換された他のポリシー セットに関係なく、テーブル全体の最後のポリシー セットとして表示され、移動または削除できません。
-
古いポリシー セットの最上位レベルで定義された条件は、許可された正しいプロトコルを選択するように設計された外部認証パート条件と組み合わされます。新しい結合条件は、新しいモデルの新しいポリシー セットごとに最上位レベルのルールで構成されます。古い各ポリシー セットの各外部パートごとに新しい個別のポリシー セットが作成されます。
-
許可ルール/例外の変更
グローバル例外とローカル例外だけでなく、許可ルールもポリシー セット内から維持されるようになりました。古いポリシー セット内のすべての許可ルールおよび例外は、認証ポリシー ルールの変換の結果として生じるすべての新しいポリシー セットにも適用されます。許可ポリシーの変更は、外部パートに設定されている許可されたプロトコルに関係なく、アップグレードされるすべてのポリシー セットに適用されます。
ポリシー セットの評価
新しいインターフェイスでポリシー セットは、[ポリシー セット（Policy Set）] テーブルに表示される順序に従って一致の有無がチェックされます。たとえば、古い「ロンドン」ポリシー セットに、変換前にステータスが異なる 3 つの外部パートがあり、古い「ニューヨーク」セットにデフォルトの外部パートのみが含まれている場合、新しいポリシー セット インターフェイスのテーブルには新しいポリシー セットとシステムのデフォルト ポリシー セットが次の順序で表示されます。
|
ポリシー セット名 |
|---|
|
ロンドン：有線 MAB |
|
ロンドン：ワイヤレス MAB |
|
ロンドン：デフォルト |
|
ニューヨーク：デフォルト |
|
デフォルト |
最初の 2 つのセットが一致しない場合、システムは「ロンドン：デフォルト」をチェックします。「ロンドン：デフォルト」が一致しない場合、システムは次に「ニューヨーク：デフォルト」をチェックします。「ニューヨーク：デフォルト」も一致しない場合、システムはポリシーとして「デフォルト」のみを使用します。
同じ論理を使用して正しい認証ルールの照合と選択が行われ、次に正しい許可ルールの照合と選択が行われます。各テーブルの先頭から開始し一致が見つかるまで各ルールがチェックされます。一致する他のルールがない場合は、デフォルト ルールが使用されます。
新しく変換されたポリシー セットのステータス
認証ルールに異なる許可されたプロトコルを使用するポリシー セットを変換する際に、新しく変換されたポリシー セットのステータスは、古いポリシー セットのステータスと古いポリシー セットの「外部パート」のステータスに基づいて次のように決定されます。
|
古いポリシー セットのステータス |
古いポリシー セットの「外部パート」のステータス |
新しいポリシー セットのステータス |
|---|---|---|
|
無効（Disable） |
無効（Disable） |
無効（Disable） |
|
無効（Disable） |
モニタ（Monitor） |
無効（Disable） |
|
無効（Disable） |
有効（Enable） |
無効（Disable） |
|
モニタ（Monitor） |
無効（Disable） |
無効（Disable） |
|
モニタ（Monitor） |
モニタ（Monitor） |
モニタ（Monitor） |
|
モニタ（Monitor） |
有効（Enable） |
モニタ（Monitor） |
|
有効（Enable） |
無効（Disable） |
無効（Disable） |
|
有効（Enable） |
モニタ（Monitor） |
モニタ（Monitor） |
|
有効（Enable） |
有効（Enable） |
有効（Enable） |
新しく変換された認証ルールのステータス
認証ルールに同じ許可されたプロトコルを使用するポリシー セットを変換する際に、新しく変換された認証ルールのステータスは、古い認証ルールの「外部パート」のステータスと対応する古い認証ルールの「内部パート」のステータスに基づいて次のように決定されます。
|
古い認証ルールの「外部パート」のステータス |
対応する古い認証ルールの「内部パート」のステータス |
変換された認証ルールのステータス |
|---|---|---|
|
無効（Disable） |
無効（Disable） |
無効（Disable） |
|
無効（Disable） |
モニタ（Monitor） |
無効（Disable） |
|
無効（Disable） |
有効（Enable） |
無効（Disable） |
|
モニタ（Monitor） |
無効（Disable） |
無効（Disable） |
|
モニタ（Monitor） |
モニタ（Monitor） |
モニタ（Monitor） |
|
モニタ（Monitor） |
有効（Enable） |
モニタ（Monitor） |
|
有効（Enable） |
無効（Disable） |
無効（Disable） |
|
有効（Enable） |
モニタ（Monitor） |
モニタ（Monitor） |
|
有効（Enable） |
有効（Enable） |
有効（Enable） |
仮想マシンでサポートされるオペレーティング システム
リリース 2.3 は、Red Hat Enterprise Linux（RHEL）7.0 をサポートしています。
VMware 仮想マシンの Cisco ISE ノードをアップグレードする場合は、アップグレードの完了後に、Red Hat Enterprise Linux（RHEL）7 にゲスト オペレーティング システムを変更します。これを行うには、VM の電源をオフにし、RHEL 7 にゲスト オペレーティング システムを変更し、変更後に VM の電源をオンにする必要があります。
アップグレードにかかる時間
アップグレード時間の計算
次の表に、Cisco ISE ノードのアップグレードの推定所要時間を示します。アップグレードにかかる実際の時間は、いくつかの要因によって異なります。ノード グループに複数の PSN があれば、実稼働ネットワークはアップグレード プロセス中に停止することなく動作し続けます。
|
展開のタイプ |
ノード ペルソナ |
アップグレードにかかる時間 |
|---|---|---|
|
スタンドアロン（Standalone） |
管理、ポリシー サービス、モニタリング |
15 GB のデータごとに 240 分 + 60 分 |
|
分散型
|
セカンダリ管理ノード |
240 分 |
|
ポリシー サービス ノード |
180 分 |
|
|
モニタリング（Monitoring） |
15 GB のデータごとに 240 分 + 60 分 |
リリース 2.3 へのアップグレードでは、仮想マシンのゲスト オペレーティング システムをアップグレードして、ネットワーク アダプタのタイプを変更する必要があります。ゲスト OS の変更では、システムの電源をオフにし、RHEL バージョンを変更し、電源を再度オンにする必要があります。前述の表にある推定所要時間のほかに、アップグレード前のタスクにかかる時間を考慮する必要があります。複数 PSN の分散展開では、システムのアップグレード準備に約 2 時間必要です。
アップグレードにかかる時間に影響する要因
（注） | 仮想マシン上の Cisco ISE ノードのアップグレードは、物理アプライアンスのアップグレードよりも長い時間がかかる場合があります。 |
フィードバック