1. はじめに
Cisco Identity Services Engine(ISE)は、Network Access Control(NAC)を提供する中核的な製品であり、ユーザー、デバイス、接続元、接続方法といったコンテキストに基づいてネットワークアクセスを制御するための基盤として広く利用されています。
近年、ISE はオンプレミス環境だけでなく、Azure をはじめとするクラウド環境へのデプロイも公式にサポートされるようになりました。これにより、クラウド上に配置したネットワークや、ハイブリッド構成の認証基盤として ISE を利用する選択肢が現実的になっています。
一方で、Azure Marketplace 上には、Azure Application、Virtual Machine、SaaS など、名称や提供形態の異なる複数の ISE 関連オプションが並んでおり、初めて ISE を Azure にデプロイする場合、どれを選択すればよいのか、また何を確認すれば「正しく立ち上がった」と言えるのかが分かりにくい状況があります。
本記事では、これらの選択肢のうちAzure 上に ISE ノードを構築・運用するケースに焦点を当て、特に Azure Application 版を用いたデプロイを前提として内容を整理します。
具体的には、
- Azure Marketplace における ISE の選択肢の整理
- Azure Application 版と Virtual Machine 版の違い
- Azure Application 版デプロイ時の UI 上の確認ポイント
- デプロイ完了後に、ISE が正常に起動しているかを判断するための確認手順
を、実際の操作内容と出力例に基づいて説明します。
なお、本記事では ISE の設計方針やポリシー設定、RADIUS / TACACS+ の具体的な構成には踏み込まず、「Azure 上で ISE を正しくデプロイし、次の設計・構成フェーズに進める状態を作ること」に限定しています。
2. Azure Marketplace における Cisco ISE の選択肢
Azure Marketplace で ISE をキーワードにして検索すると、名称が似ている複数の選択肢が表示されます。初見では違いが分かりにくいですが、これらは提供形態・役割・用途がそれぞれ異なります。本セクションでは、まず Marketplace 上に表示される選択肢を整理します。
2.1. Marketplace に表示される選択肢一覧
ISE に関連する主な選択肢は、以下の 4 つです。
- Cisco Identity Services Engine (ISE) Azure Application
- Cisco Identity Services Engine (ISE) Virtual Machine
- Cisco Identity Services Engine (ISE) SaaS
- Cisco ISE Azure Application
いずれも名称に ISE や Azure Application を含んでいるため、役割を理解せずに選択すると意図しないものをデプロイしてしまう可能性があります。
2.2. 共通事項(ISE 本体としての機能)
後述する Azure Application 版、Virtual Machine 版、SaaS 版は、いずれも ISE 本体を提供する選択肢です。これらについて、公式概要で説明されている主な機能は共通しています。
- Network Access Control(NAC)プラットフォームとしての機能
- エンドポイントやユーザーのコンテキストに基づくアクセス制御
- ポリシーの集中管理
- API を前提とした自動化・外部連携
提供形態による機能差は、公式情報上は明示されていません。以降の違いは、「何ができるか」ではなく、「どのように提供され、どのようにデプロイ・管理するか」にあります。
2.3. Cisco Identity Services Engine (ISE) Azure Application
この選択肢は、ISE 本体を Azure Application(Managed Application)として提供するものです。
- Azure Marketplace 上の Azure Application として提供
- Azure 上で ISE ノードをデプロイ・管理することを前提とした構成
- デプロイ時に必要な項目が UI 上で整理されている
ISE 自体は Virtual Machine として起動されますが、デプロイ手順は Marketplace テンプレートによって制御されます。本記事では、この Azure Application 版を前提に進めます。
2.4. Cisco Identity Services Engine (ISE) Virtual Machine
この選択肢は、ISE 本体を Virtual Machine イメージとして直接提供するものです。
- Virtual Machine 形式で提供される ISE
- 機能説明は Azure Application 版と同一
- デプロイ時に user-data を用いた初期設定が必要
Azure Application 版とは異なり、デプロイ手順や初期構成を利用者側で直接制御する形になります。
2.5. Cisco Identity Services Engine (ISE) SaaS
この選択肢は、ISE を SaaS 形態で提供するものです。
- ISE 本体を SaaS として利用
- 機能説明は他の ISE 本体と同一
- インフラ管理の多くがサービス側に委ねられる
一方で、RADIUS / TACACS+ の配置や内部ネットワーク前提の設計を考慮すると、用途によっては制約が生じる可能性があります。本記事では、この SaaS 版は考慮対象外としています。
2.6. Cisco ISE Azure Application(Sentinel 連携)
この選択肢は、ISE 本体ではありません。Cisco ISE の NAC ログを Microsoft Sentinel(SIEM)に連携するための Azure Applicationです。
- ISE のログを Sentinel に取り込み、可視化や分析を行う用途
- ISE のデプロイや起動とは直接関係しない
そのため、本記事のスコープからは除外します。
2.7. 補足:名称が紛らわしい点について
特に注意が必要なのが、
- Cisco Identity Services Engine (ISE) Azure Application
- Cisco ISE Azure Application
という 2 つの選択肢です。
前者は ISE 本体のデプロイ手段であり、後者は ISE のログを Sentinel に連携するためのソリューションです。名称は似ていますが、目的も役割もまったく異なるため、選択時には注意が必要です。
3. Azure Application 版と Virtual Machine 版の違い
前述の内容から、Azure Marketplace では、Cisco Identity Services Engine(ISE)を Azure Application 版または Virtual Machine 版でデプロイすることが現実的です。両者は名称や提供形態は異なりますが、結論から述べると、デプロイ後に稼働する ISE ノード自体に本質的な違いはありません。
本セクションでは、両者の違いを 実体・デプロイ・運用の 3 つの観点から整理します。
3.1. 実体の違い(Azure リソース観点)
Azure Application 版、Virtual Machine 版のいずれを選択した場合でも、最終的に Azure 上に作成されるのは Microsoft.Compute/virtualMachines リソースです。
どちらの方式でも、
- Azure 上では Virtual Machine として起動される
- プライベート IP を付与できる
- Cisco ISE に対して SSH で直接接続できる
という点は共通しています。
そのため、稼働後の ISE ノードとしての実体や扱いに差分はありません。Azure Application 版だから PaaS になる、あるいは OS や ISE の機能が制限される、といったことはありません。
3.2. デプロイ時の違い
両者の違いが現れるのは、デプロイ時の手順と初期設定方法です。
Virtual Machine 版
Virtual Machine 版では、デプロイ時にuser-data を用いて初期設定をテキストとして記述します。
- 初期構成を user-data に直接記述する
- 依存リソースの準備も含め、利用者側で制御する
- デプロイ工程そのものを細かく設計できる
一方で、記述ミスや差分による失敗が起きやすく、再試行のコストが高くなりがちです。
Azure Application 版
Azure Application 版では、Marketplace が提供するテンプレートを通じて必要な設定項目が 構造化された UI として提示されます。
- user-data を直接記述する必要がない
- 必須項目が明確
- 設定漏れが起きにくい
- 失敗時の再デプロイが比較的容易
その結果、初期デプロイの再現性が高い構成になります。
3.3. Virtual Machine 版を選択するメリット
Azure Application 版が提供されている以上、Virtual Machine 版を選択するメリットがあるのかは整理しておく必要があります。
推測を含みますが、Virtual Machine 版のメリットとして考えられる点は、初期状態として ISE に渡せる設定の自由度が高いことです。つまり、Marketplace テンプレートで定義された入力項目に依存せず、user-data によってより多くの設定を初期状態で投入できる可能性があります。
特に、以下のような要件がある場合には、Virtual Machine 版の方が柔軟に対応できると考えられます。
- 初期構成を user-data で厳密に制御したい場合
- 構築工程そのものを IaC として完全に管理したい場合
- 最小構成から段階的に検証・構築したい場合
一方で、これらの前提がない場合、実運用上は Azure Application 版を選択する方が合理的です。
3.4. 運用上の違い
デプロイ完了後の運用フェーズにおいては、両方式の違いはほぼ存在しません。
- ネットワーク構成
- 管理 GUI および CLI の利用
- SSH による直接アクセス
- 停止・起動、バックアップなどの運用操作
いずれも同一です。
そのため、Azure Application 版と Virtual Machine 版の違いは、「どのように作るか」だけに集約されると言えます。
4. Azure Application 版のデプロイ
本セクションでは、Azure Marketplace から Cisco Identity Services Engine (ISE) BYOL 3.5(Azure Application 版)をデプロイする際の UI 上のポイントを整理します。ここで扱うのは デプロイ操作のみであり、ISE の設計や機能設定については扱いません。
4.1. デプロイ概要
Azure Marketplace で「Cisco Identity Services Engine (ISE) Azure Application」を選択し、通常の Azure Application と同様にデプロイを進めます。
Azure Application 版では、必要な設定項目が Marketplace テンプレートとして整理されており、Virtual Machine 版のように user-data を直接記述する必要はありません。
4.2. 基本設定(Basic)
| 項目 | 内容 | ポイント |
|---|---|---|
| サブスクリプション | デプロイ先の Azure サブスクリプション | 通常の VM と同様 |
| リソースグループ | ISE を配置するリソースグループ | 専用 RG を作成すると管理しやすい |
| リージョン | 配置リージョン | ネットワーク到達性を考慮 |
| Host Name | ISE ノードのホスト名 | 証明書・ノード識別に影響 |
| Time Zone | タイムゾーン | デフォルトは UTC |
| VM Size | 仮想マシンサイズ | Cisco ISE の公式要件に従う |
| Disk Storage Type | ディスク種別 | Premium SSD を選択可能 |
| Volume Size | データボリュームサイズ | ISE 要件に応じて指定 |
4.3. ネットワーク設定(Network Settings)
| 項目 | 内容 | ポイント |
|---|---|---|
| Virtual Network | 接続する VNet | |
| Subnet | 配置するサブネット | |
| Network Security Group | NSG の指定 | 未指定でも後から設定可能 |
| SSH 公開キーのソース | SSH 鍵の指定 | 公開鍵認証のみ |
| SSH Key Type | RSA / Ed25519 | 運用方針に合わせて選択 |
| キーの組名(SSH) | SSH キー名 | |
| Private IP Address | プライベート IP | 固定指定を推奨 |
| Public IP Address | パブリック IP | 外部アクセスが必要な場合のみ |
| DNS domain name | DNS ドメイン | ISE の FQDN に影響 |
| Primary Name Server | DNS サーバー | デプロイ時はパブリック DNS でも可 |
| Secondary / Tertiary Name Server | DNS サーバー | 冗長化する場合に指定 |
| Primary NTP Server | NTP サーバー | パブリック NTP でも可 |
| Secondary / Tertiary NTP Server | NTP サーバー | 冗長化する場合に指定 |
4.4. サービス設定(Services)
| 項目 | 内容 | ポイント |
|---|---|---|
| ERS | External RESTful Services | デプロイ後に変更可能 |
| pxGrid | pxGrid 機能 | デプロイ後に変更可能 |
- ERS:ISE を外部システムから API 経由で操作するための機能です。
- pxGrid:ISE と他のセキュリティ製品間で、コンテキスト情報をリアルタイムに共有するための仕組みです。
いずれも 初期デプロイ時点で必須ではなく、後から有効化できます。
4.5. ユーザー設定(User Details)
| 項目 | 内容 | ポイント |
|---|---|---|
| iseadmin password | 管理者パスワード | 初回ログイン時に変更が必要 |
SSH および GUI 管理に使用する iseadmin ユーザーのパスワードを指定します。
4.6 レビューと送信
入力内容を確認し、デプロイを開始します。ISE のデプロイおよび初回起動には 比較的長時間かかるため、送信前に以下を確認しておくと安全です。
- ネットワーク設定(VNet / Subnet / IP)
- DNS / NTP の到達性
- SSH 鍵の指定
5. デプロイ完了後の確認と操作
Azure 上でデプロイが完了しても、その時点で Cisco Identity Services Engine(ISE) がすぐに利用可能になるとは限りません。
ISE は初回起動時に内部で多数のサービスを初期化するため、完全な起動にはかなりの時間を要します。Azure Portal 上で Virtual Machine が「実行中」と表示されていても、ISE のアプリケーションとしては起動途中であることがほとんどです。
そのため、SSH で接続し、CLI から状態を確認できることが重要になります。
5.1. SSH 接続
ISE ノードに対して SSH 接続を行います。ISE ではパスワード認証は使用できないため、公開鍵認証のみとなります。
ssh -i ise-ssh-key iseadmin@192.168.0.100- ユーザー名は iseadmin
- デプロイ時に指定した SSH 鍵の秘密鍵を使用
SSH 接続できること自体が、OS レベルでは起動していることの確認になります。
5.2. ISE アプリケーション状態の確認
SSH 接続後、最も重要なコマンドが以下です。
show application status iseこのコマンドで、ISE を構成する各サービスの状態を確認できます。初回起動時は、すべてのサービスがすぐに running になるわけではなく、しばらく starting や disabled の状態が混在します。
5.3. application start ise について
ISE には、アプリケーションを明示的に起動する以下のコマンドが用意されています。
application start ise今回の構築では、起動に非常に時間がかかっているように見えたため実行しましたが、必須ではないと考えられます。
基本的には、ISE が自動的に起動処理を行うため、CLI で状態を確認しながら待機する運用が無難です。長時間まったく変化が見られない場合の確認手段として理解しておくのが適切でしょう。
5.4. 起動完了の判断基準
十分に時間を置いた後、再度状態を確認します。
show application status ise以下は、起動完了後の出力例です。
ISE PROCESS NAME STATE PROCESS ID
--------------------------------------------------------------------
Database Listener running 124918
Database Server running 134 PROCESSES
ISE Data Grid Service running 196125
Application Server running 139932
Profiler Database running 140612
ISE Elasticsearch running 180475
AD Connector running 206187
M&T Session Database running 131975
M&T Log Processor running 208095
Certificate Authority Service running 184412
EST Service running 221824
SXP Engine Service disabled
TC-NAC Service disabled
PassiveID WMI Service disabled
PassiveID Syslog Service disabled
PassiveID API Service disabled
PassiveID Agent Service disabled
PassiveID Endpoint Service disabled
PassiveID SPAN Service disabled
DHCP Server (dhcpd) disabled
DNS Server (named) disabled
ISE Messaging Service running 142651
ISE API Gateway Database Service running 142329
ISE API Gateway Service running 175993
ISE pxGrid Direct Service running 183515
ISE pxGrid Direct Pusher running 187215
Segmentation Policy Service disabled
REST Auth Service running 198664
SSE Connector disabled
Hermes (pxGrid Cloud Agent) disabled
MFA (Duo Sync Service) disabled
McTrust (Meraki Sync Service) disabled
aciconn (ACI Connection Service) disabled
Workload Connector Service disabled
ISE Prometheus Service disabled
ISE Prometheus Exporter disabled
ISE Grafana Service disabled
ISE MNT LogAnalytics Elasticsearch running 204823
ISE Kibana Service disabled
ISE Native IPSec Service running 141904
Remote Support Authorization Service disabled
MFC Profiler running 203243
ISE Prometheus Alertmanager Service disabled
Protocols Engine running 224189 5.5. 管理 UI へのアクセス
主要なサービスが running となっていれば、Web 管理 UI へアクセス可能になります。
https://192.168.0.100- 管理ユーザーは iseadmin
- 初回アクセス時はパスワード変更が必要
GUI にアクセスできることを確認できれば、ISE は正常に起動している状態と判断できます。
6. まとめ
本記事では、Cisco Identity Services Engine(ISE)を Azure 上にデプロイする際に、どの選択肢を選び、どこまでを確認すれば「正しく立ち上がった」と判断できるのかを整理しました。
Azure Marketplace には、ISE に関連する複数の選択肢が表示されますが、ISE 本体を Azure 上に構築・運用するという観点では、
- Azure Application 版
- Virtual Machine 版
が対象となります。
この 2 つは提供形態やデプロイ手順が異なるものの、デプロイ完了後に稼働する ISE ノードの実体は同一であり、いずれも Azure Virtual Machine として起動します。
そのため、SSH 接続、管理 GUI、日常的な運用や管理方法に差分はありません。両者の違いは、あくまでデプロイ時の手順と初期設定方法に集約されます。
Azure Application 版では、Marketplace テンプレートによって入力項目が整理されており、user-data を直接記述する必要がありません。その結果、初期デプロイの再現性が高く、失敗時の切り戻しもしやすい構成になります。
一方、Virtual Machine 版は、user-data を用いて初期状態を細かく制御したい場合や、構築工程そのものを IaC として厳密に管理したい場合に選択肢となります(本記事では Virtual Machine 版の詳細な構築検証は行っていません)。
また、デプロイ完了後の確認において重要なのは、Azure Portal 上の状態ではなく、ISE 側のアプリケーション状態を CLI から確認することです。
- SSH で接続できること
show application status iseにより主要サービスが running であること
これらが確認できていれば、ISE は正常に起動しており、次のフェーズに進める状態と判断できます。
本記事で扱った内容は、ISE の設計やポリシー設定の前段となる 基盤構築フェーズに限定しています。
ここまでの確認が完了していれば、証明書設計、認証基盤連携、RADIUS / TACACS+ 設定、必要に応じた ERS や pxGrid の有効化といった構成・設計フェーズに進む準備が整った状態と言えます。




