CCIE EI/Secure LAN - ISE

ISE Deep Dive

Optimus Joo 2026. 3. 23. 16:46
Cisco ISE Deep Dive — Expert Level 완전 정복
🛡 Expert-Level Technical Series

Cisco ISE Deep Dive
완전 정복 가읎드

Architecture · 802.1X · Profiling · Posture · Guest · BYOD · TrustSec · pxGrid · TACACS+ · Troubleshooting

📅 2026.03.23 ⏱ 앜 45분 읜Ʞ 🏷 ISE 3.x / CCIE Security

01 ISE 개요 및 Zero Trust에서의 역할

Cisco Identity Services Engine(ISE)은 엔터프띌읎슈 넀튞워크에서 정책 결정 포읞튞(Policy Decision Point, PDP)로 Ʞ능하는 찚섞대 NAC(Network Access Control) 플랫폌읎닀. 닚순한 AAA 서버륌 넘얎, 사용자·디바읎슀·애플늬쌀읎션 컚텍슀튞륌 수집하고, 읎륌 Ʞ반윌로 ì ‘ê·Œ 정책을 동적윌로 적용하며, 위협을 싀시간윌로 격늬하는 Zero Trust Architecture의 핵심 엔진읎닀.

ISE가 핎결하는 핵심 묞제

  • Visibility Gap: 넀튞워크에 연결된 몚든 엔드포읞튞(사용자, IoT, OT 장비)의 정첎륌 파악하지 못하멎 정책을 섞욞 수 없닀.
  • Policy Fragmentation: Wired, Wireless, VPN, DC, Cloud 각 도메읞마닀 별도 정책 컚튞례러가 졎재하여 음ꎀ된 볎안읎 얎렵닀.
  • Static ACL 한계: IP êž°ë°˜ ACL은 사용자 로밍, DHCP 환겜에서 묎력하며, 수천 쀄의 ACE ꎀ늬는 욎영 악몜읎닀.
  • Compliance Enforcement: 엔드포읞튞의 볎안 상태(팚치, AV, 암혞화) 믞확읞 시 넀튞워크 접귌을 허용하는 것은 Zero Trust 위반읎닀.

💡 ISE의 3대 축 (Three Pillars)

① Visibility — 프로파음링 + AI Endpoint Analytics로 "Who/What is on the network" 확볎
② Control — 802.1X, MAB, WebAuth, Posture륌 통한 읞슝·읞가·컎플띌읎얞슀 강제
③ Segmentation — TrustSec SGT êž°ë°˜ 마읎크로섞귞멘테읎션윌로 lateral movement 찚닚

ISE는 RADIUS/TACACS+ 프로토윜을 처늬하는 동시에, DHCP, CDP, LLDP, NetFlow, HTTP, SNMP 등 닀양한 프로토윜의 컚텍슀튞 데읎터륌 수집한닀. 수집된 컚텍슀튞는 Security Group Tag(SGT)띌는 레읎랔로 추상화되얎, 넀튞워크·볎안 도메읞 전첎에 음ꎀ된 정책 식별자로 배포된닀.

02 Architecture Deep Dive — Persona · Node · Deployment

2.1 ISE Persona (역할 분늬)

ISE 아킀텍처의 핵심은 Persona êž°ë°˜ 역할 분늬읎닀. 각 ISE 녾드는 하나 읎상의 Persona륌 싀행할 수 있윌며, 소규몚 환겜에서는 몚든 Persona륌 닚음 녞드에 통합(Standalone), 대규몚 환겜에서는 전용 녞드로 분산(Distributed) 배포한닀.

Persona 앜칭 핵심 Ʞ능 HA 구성
Administration PAN 정책 구성, 띌읎선슀 ꎀ늬, DB Replication Master, GUI 제공 Active/Standby (최대 2녾드)
Policy Service PSN RADIUS/TACACS+ 처늬, Profiling Probe, Posture, Guest, BYOD Active/Active (LB VIP 사용), 최대 50 PSN
Monitoring MnT 로귞 수집·상ꎀ분석, 늬포튞, 알람 Active/Standby (최대 2녾드)
pxGrid PXG 컚텍슀튞 공유 허뾌 (WebSocket/STOMP) Active/Active (최대 4녾드)

2.2 Distributed Deployment 아킀텍처

┌─────────────────────────────────────────────────────────────┐ │ DATA CENTER 1 │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Primary │ │ Primary │ │ PSN-1 │ │ PXG-1 │ │ │ │ PAN │◄─►│ MnT │ │(RADIUS) │ │ (pxGrid) │ │ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ │ ▲ ▲ ▲ │ │ │ DB Repl │ Syslog │ RADIUS │ │========│==============│==============│=======================│ │ â–Œ â–Œ â–Œ │ │ WAN / MPLS / SD-WAN │ │========│==============│==============│=======================│ │ â–Œ â–Œ â–Œ │ │ DATA CENTER 2 │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │Secondary │ │Secondary │ │ PSN-2 │ │ PXG-2 │ │ │ │ PAN │◄─►│ MnT │ │(RADIUS) │ │ (pxGrid) │ │ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ └─────────────────────────────────────────────────────────────┘ PSN은 지역별 AD와 co-locate | PAN↔PSN 간 latency ≀ 300ms RTT

2.3 섀계 핵심 원칙

  • PAN-PSN 간 지연: Round-trip 300ms 읎낎. DB Replication곌 정책 Push가 읎 링크륌 사용한닀.
  • PSN-MnT 간 대역폭: Audit Log가 대량 전송되므로 충분한 bandwidth 확볎 필수.
  • PSN-AD Co-location: RADIUS 읞슝 시 AD Lookup읎 발생하므로, PSN곌 AD DC륌 같은 사읎튞에 배치한닀.
  • Load Balancer: Calling-Station-ID(MAC) êž°ë°˜ Sticky Session윌로 PSN 분산. URL Redirect 서비슀(Guest, Posture) 사용 시 PSN Node Group 구성 필수.
  • N+1 또는 N+2 Redundancy: PSN 귞룹 낮 예비 녞드륌 확볎하여, 닚음 PSN 장애 시에도 읞슝 처늬량 유지.
💡 Expert Tip
ISE 3.3부터 Very Small Deployment Node(8 vCPU)가 지원된닀. 원격지 임시 배포나 Lab 환겜에서 늬소슀륌 절앜할 수 있닀. 당, Production 환겜에서는 SNS 3615/3655/3795 ꞉ 하드웚얎륌 권장한닀.

03 Authentication 메컀니슘

3.1 802.1X (EAP êž°ë°˜ 읞슝)

802.1X는 ISE에서 가장 강력한 읞슝 방식읎닀. Supplicant ↔ Authenticator(Switch/WLC) ↔ Authentication Server(ISE) 3자 구조로 동작하며, EAPoL(EAP over LAN)로 캡슐화된 읞슝 프레임읎 교환된닀.

죌요 EAP 방식 비교

EAP 방식읞슝 요소Inner Method특징
EAP-TLS읞슝서 (Mutual TLS)없음최고 볎안, 읞슝서 읞프띌(PKI) 필수
PEAP-MSCHAPv2서버 읞슝서 + 사용자 ID/PWMSCHAPv2가장 음반적, AD 통합 용읎
EAP-FASTPAC 또는 읞슝서MSCHAPv2/GTCCisco 독자, EAP Chaining 지원
TEAP읞슝서 + ID/PWEAP-TLS + MSCHAPv2RFC 7170 표쀀, Machine+User Chaining
ℹ EAP Chaining읎란?
닚음 EAP 섞션 낎에서 Machine Authentication + User Authentication을 순찚 수행하는 Ʞ법읎닀. TEAP 또는 EAP-FAST에서 지원하며, "읎 장비가 회사 소유읎고 + 읎 사용자가 읞슝된 직원"임을 동시에 검슝한닀. ISE Authorization Policy에서 Network Access:EAPChainingResult = User and Machine Both Succeeded 조걎윌로 정밀 정책을 구성할 수 있닀.

3.2 MAB (MAC Authentication Bypass)

802.1X Supplicant가 없는 디바읎슀(프며터, IP Phone, IoT, OT 장비)에 대핮 MAC 죌소륌 ID로 사용하는 Fallback 읞슝읎닀.

! Switch Configuration — 802.1X + MAB Fallback
interface GigabitEthernet1/0/1
 switchport mode access
 switchport access vlan 100
 authentication port-control auto
 authentication order dot1x mab
 authentication priority dot1x mab
 mab
 dot1x pae authenticator
 dot1x timeout tx-period 10
 authentication timer reauthenticate 3600
 authentication event fail action next-method
 authentication event server dead action authorize vlan 999
 authentication event server alive action reinitialize
IOS-XE 802.1X + MAB
⚠ MAB 볎안 한계
MAC 죌소는 슀푞핑읎 가능하므로, MAB 닚독윌로는 볎안성읎 낮닀. 반드시 Profiling곌 결합하여 디바읎슀 종류륌 확읞하고, 최소 권한 원칙에 따띌 제한된 DACL/SGT륌 부여핎알 한닀.

3.3 Web Authentication (CWA / LWA)

  • CWA (Central Web Authentication): ISE가 직접 Web Portal을 혞슀팅. Switch/WLC가 HTTP Redirect ACL을 적용하여 튞래픜을 ISE로 늬닀읎렉튞. Guest, BYOD 옚볎딩에 사용.
  • LWA (Local Web Authentication): Switch/WLC 자첎 Portal. ISE는 뒷닚 RADIUS 서버 역할만 수행. Ʞ능읎 제한적읎띌 CWA 권장.

3.4 Authentication Flow (802.1X Ʞ쀀)

Endpoint Switch (NAD) ISE (PSN) AD/LDAP │ │ │ │ │──EAPoL-Start──────►│ │ │ │◄─EAP-Request/ID───│ │ │ │──EAP-Response/ID──►│ │ │ │ │──RADIUS Access-Req─►│ │ │ │ │──LDAP/Kerberos───►│ │ │ │◄─Auth Result──────│ │ │ │ │ │◄──────────── EAP Challenge/Response (TLS Tunnel) ──────────►│ │ │ │ │ │ │◄─RADIUS Accept──────│ │ │ │ (VLAN, DACL, SGT) │ │ │◄─EAPoL-Success────│ │ │ │ │ │ │ │ ═══ DATA FLOW (Authorized) ════════════════════════════════│

04 Authorization Policy & Policy Sets 섀계

4.1 Policy Set 계잵 구조

ISE의 정책 엔진은 계잵적 Policy Set 구조로 동작한닀. 최상위에 Policy Set 맀칭 조걎읎 있고, 각 Set 낎부에 Authentication Policy → Authorization Policy → Exception Policy가 순서대로 평가된닀.

┌─────────────────────────────────────────────────┐ │ POLICY SET: "Wired_Access" │ │ Condition: RADIUS:NAS-Port-Type = Ethernet │ │ Allowed Protocols: Default Network Access │ ├────────────────────────────────────────────────── │ ┌─── AUTHENTICATION POLICY ───────────────┐ │ │ │ Rule 1: Dot1X → AD (Primary) │ │ │ │ Rule 2: MAB → Internal Endpoints │ │ │ │ Default: Deny Access │ │ │ └─────────────────────────────────────────┘ │ │ │ │ ┌─── AUTHORIZATION POLICY ────────────────┐ │ │ │ Rule 1: AD:Group=IT_Admin │ │ │ │ → Full_Access + SGT:IT(10) │ │ │ │ Rule 2: AD:Group=HR │ │ │ │ → HR_DACL + SGT:HR(20) │ │ │ │ Rule 3: EndpointProfile=Cisco-IP-Phone │ │ │ │ → Voice_VLAN + SGT:Voice(30) │ │ │ │ Rule 4: EAPChaining=Both_Succeeded │ │ │ │ → Employee_Full + SGT:Emp(40) │ │ │ │ Default: Guest_Redirect │ │ │ └─────────────────────────────────────────┘ │ │ │ │ ┌─── EXCEPTION POLICY ───────────────────┐ │ │ │ Quarantine Rule: Threat Detected │ │ │ │ → Quarantine_VLAN │ │ │ └─────────────────────────────────────────┘ │ └─────────────────────────────────────────────────┘

4.2 Authorization Profile 핵심 요소

  • VLAN Assignment: Tunnel-Private-Group-ID RADIUS 속성윌로 동적 VLAN 할당
  • Downloadable ACL (DACL): ISE에서 Switch로 ACL을 Push. Per-session granularity 제공
  • Security Group Tag (SGT): cisco-av-pair: cts:security-group-tag=XXXX로 SGT 할당
  • URL Redirect: Guest Portal, BYOD Portal, Posture Portal로의 CWA 늬닀읎렉튞
  • Reauthentication Timer: Session Timeout + CoA륌 통한 죌Ʞ적 재읞슝
  • Voice Domain Permission: device-traffic-class=voice VSA로 IP Phone 음성 VLAN 읞가

4.3 Condition Dictionary 활용

ISE는 수십 개의 Dictionary륌 제공하며, Authorization 조걎에서 닀양한 속성 조합읎 가능하닀:

/* Expert-Level Authorization Condition 예시 */

Condition:
  IdentityGroup:Name EQUALS "Employee"
  AND
  Network Access:EAPChainingResult EQUALS "User and machine both succeeded"
  AND
  Session:PostureStatus EQUALS "Compliant"
  AND
  DEVICE:Location EQUALS "Seoul_HQ"

Result:
  Profile: Full_Network_Access
  SGT: Employee_Trusted (0010)
ISE Policy Condition
💡 섀계 원칙: Deny by Default
Authorization Policy의 Default Rule은 반드시 Deny 또는 최소 ì ‘ê·Œ(Guest Redirect)윌로 섀정한닀. "Permit Access"가 Default읞 환겜은 볎안 구멍읎닀. 명시적윌로 맀칭되지 않는 몚든 섞션은 찚닚하는 것읎 Zero Trust 원칙읎닀.

05 Profiling — 엔드포읞튞 식별곌 분류

5.1 프로파음링읎 필요한 읎유

"누가 넀튞워크에 연결되얎 있는가?"는 절반의 질묞읎닀. "묎엇읎 연결되얎 있는가?"가 더 쀑요하닀. 프며터, IP Phone, IoT 섌서, CCTV, 의료 장비 등 802.1X륌 지원하지 않는 디바읎슀가 êž°ì—… 넀튞워크의 상당 부분을 찚지한닀. ISE Profiler는 닀양한 소슀의 시귞널을 수집하여 엔드포읞튞륌 정밀하게 분류한닀.

5.2 Profiling Probes

Probe수집 데읎터정밀도비고
RADIUSCalling-Station-ID, NAS-Port, Framed-IP낮음Ʞ볞 활성화
DHCPhostname, class-identifier, vendor-class쀑간ip helper-address 또는 SPAN
Device SensorCDP/LLDP/DHCP attributes (Switch에서 수집)높음IOS 15.x+, RADIUS accounting윌로 전송
SNMPsysObjectID, sysDescr, cdpCacheDeviceId맀우 높음ISE 3.5부터 SNMPv3 지원
HTTPUser-Agent string쀑간SPAN 또는 WLC
NetFlowTraffic pattern낮음행위 êž°ë°˜ 분류 볎조
pxGrid / MDMMDM compliance, device model, OS맀우 높음Jamf, Intune, WS1 연동
Wi-Fi Edge AnalyticsApple/Intel/Samsung 디바읎슀 속성높음Catalyst 9800 WLC → RADIUS

5.3 Certainty Factor (CF) 맀칭 로직

ISE Profiler는 Certainty Factor 가쀑치 시슀템을 사용한닀. 각 Profiling Rule읎 맀칭되멎 정핎진 CF 값읎 누적되고, Minimum Certainty Factor(MCF) 임계값을 쎈곌하멎 핎당 프로파음로 분류된닀.

/* Custom Profiling Policy 예시 — Axis IP Camera */

Profile: Custom_Axis_Camera
MCF: 30

Rule 1: DHCP:vendor-class CONTAINS "AXIS"          → CF +20
Rule 2: SNMP:sysObjectID EQUALS "1.3.6.1.4.1.368"  → CF +30
Rule 3: HTTP:User-Agent CONTAINS "AXIS"           → CF +10
Rule 4: OUI EQUALS "00:40:8C" (AXIS OUI)          → CF +10

/* Rule 2만 맀칭되얎도 CF=30 ≥ MCF=30 → 분류 확정 */
/* Rule 1+4만 맀칭되얎도 CF=30 ≥ MCF=30 → 분류 확정 */
ISE Profiling Policy

5.4 ISE 3.x: AI Endpoint Analytics

ISE 3.0부터 도입된 AI Endpoint Analytics는 뚞신러닝 Ʞ반윌로 엔드포읞튞륌 자동 분류한닀. Ʞ졎 Rule êž°ë°˜ 프로파음링을 볎완하여, 알렀지지 않은(Unknown) 디바읎슀도 행위 팚턎곌 속성 유사도륌 분석핎 귞룹핑한닀. ISE 3.5에서는 Authoritative Source Ʞ능읎 추가되얎, MDM(Jamf 등)읎 특정 속성에 대핮 ISE 자첎 프로파음링볎닀 우선시되도록 섀정할 수 있닀.

🚚 Randomized MAC Address 대응
iOS 14+, Android 10+, Windows 10+에서 Private(Randomized) MAC읎 Ʞ볞 활성화되었닀. MAC êž°ë°˜ 프로파음링곌 MAB 읞슝에 심각한 영향을 쀀닀. 대응 방안: DHCP hostname, HTTP User-Agent, Device Sensor 데읎터륌 적극 활용하고, 가능하멎 802.1X 읞슝서 Ʞ반윌로 전환한닀.

06 Posture Assessment — Compliance 엔진

6.1 Posture 개념

Posture(자섞 평가)는 엔드포읞튞가 넀튞워크에 접귌하Ʞ 전에 볎안 컎플띌읎얞슀 상태륌 검슝하는 메컀니슘읎닀. AV 섀치 여부, OS 팚치 수쀀, 디슀크 암혞화, 방화벜 상태, 레지슀튞늬 í‚€ 졎재 등을 점검한닀.

6.2 Posture Agent vs Agentless

방식Agent지원 OS점검 범위
Cisco Secure Client (구 AnyConnect)Agent 섀치Windows, macOS, Linux전첎 (AV, Patch, Firewall, 암혞화, 레지슀튞늬 등)
Agentless Posture에읎전튞 없음Windows, macOS제한적 (ꎀ늬자 권한윌로 WMI/SSH 원격 조회)
Temporal Agent임시 싀행Windows, macOS쀑간 (싀행 후 자동 삭제)

6.3 Posture Flow

1
쎈Ʞ 읞슝: 802.1X/MAB 읞슝 성공 → ISE Authorization에서 Posture Status = Unknown 조걎 맀칭 → Redirect to Client Provisioning Portal 프로파음 적용
2
Agent Provisioning: 엔드포읞튞가 Portal에 ì ‘ê·Œ → Cisco Secure Client + Compliance Module 닀욎로드/섀치
3
Posture Check: Agent가 ISE에 등록된 Posture Policy Ʞ반윌로 엔드포읞튞 상태 점검
4
Compliant: 몚든 필수 요걎 충족 → ISE가 CoA (Change of Authorization) 발행 → Switch/WLC가 섞션 재읞가 → Full Access 프로파음 적용
5
Non-Compliant: 요걎 믞충족 → Remediation 시간 부여 → 싀팚 시 Quarantine VLAN윌로 읎동 또는 ì ‘ê·Œ 찚닚
/* Posture Condition 예시 */
Condition: AV_Definition_Check
  Type: Anti-Virus Definition
  Vendor: CrowdStrike Falcon
  Check: Definition Date within 3 days

Condition: OS_Patch_Check
  Type: Patch Management
  OS: Windows All
  Severity: Critical patches installed

Condition: Disk_Encryption_Check
  Type: Disk Encryption
  Vendor: BitLocker
  Status: Encrypted

Requirement: Corporate_Compliance
  Conditions: AV_Definition_Check AND OS_Patch_Check AND Disk_Encryption_Check
  Remediation: Message + Auto-Remediation (Force Windows Update)
ISE Posture Policy
💡 ISE 3.3+: ARM64 Posture 지원
ISE 3.3부터 ARM64 아킀텍처(Apple Silicon M1/M2/M3, Qualcomm Snapdragon) 엔드포읞튞에 대한 Posture 정책읎 지원된닀. Windows ARM64와 macOS ARM64 몚두 별도 팚킀지륌 업로드하여 배포 가능하닀.

07 Guest Access — Hotspot · Self-Reg · Sponsored

7.1 Guest Access 유형

  • Hotspot: 별도 계정 없읎 앜ꎀ 동의만윌로 접속. 공공 WiFi, 섞믞나싀에 적합.
  • Self-Registration: 방묞자가 직접 정볎(읎늄, 읎메음, 전화번혞) 입력 후 임시 계정 생성. SMS/Email 읞슝 가능.
  • Sponsored Guest: 사낎 Sponsor(직원)가 Guest 계정을 생성하여 방묞자에게 제공. 승읞 워크플로우 포핚.

7.2 CWA êž°ë°˜ Guest Flow

Guest Device ──(Connect WiFi/Wired)──► Switch/WLC │ │ MAB 읞슝 → ISE Authorization │ 결곌: Guest_Redirect (ACL + URL Redirect) │ â–Œ ┌──────────────┐ │ ISE Guest │ ← HTTP 요청읎 ISE Portal로 Redirect │ Portal │ │ (Self-Reg) │ └──────┬───────┘ │ 계정 생성 + 읞슝 성공 â–Œ ISE → CoA (RADIUS Change of Authorization) → Switch/WLC │ â–Œ 새로욎 Authorization Profile 적용 (Guest VLAN + Internet-Only DACL + SGT:Guest)

7.3 Guest Portal 컀슀터마읎징

ISE Guest Portal은 CSS/HTML 수쀀에서 람랜딩읎 가능하닀. 로고, 색상, 앜ꎀ 묞구, ì–žì–Ž 팩을 컀슀터마읎슈하여 êž°ì—… CI에 맞춘 Portal을 제공할 수 있닀. Portal에서 수집된 Guest 정볎는 ISE의 Guest Endpoints DB에 저장되며, 만료 시간, 접속 시간 제한, 접속 횟수 제한을 섀정할 수 있닀.

⚠ Guest 50만 계정 죌의
Guest 계정읎 50만 개륌 쎈곌하멎 읞슝 지연읎 발생할 수 있닀. 정Ʞ적읞 Guest Endpoint Purge륌 슀쌀쀄링하여 불필요한 데읎터륌 정늬핎알 한닀.

08 BYOD Onboarding Pipeline

8.1 BYOD 흐멄 개요

BYOD(Bring Your Own Device) 옚볎딩은 직원의 개읞 디바읎슀륌 êž°ì—… 넀튞워크에 안전하게 등록하는 프로섞슀읎닀. ISE는 읞슝서 êž°ë°˜ BYOD륌 지원하며, 낎장 CA(Certificate Authority)륌 통핎 디바읎슀별 고유 읞슝서륌 발꞉한닀.

1
Single SSID 방식: 직원읎 Corporate SSID에 ID/PW로 최쎈 접속 → ISE가 "등록되지 않은 디바읎슀" 감지
2
BYOD Portal Redirect: ISE가 BYOD Portal로 늬닀읎렉튞 → 디바읎슀 등록 동의
3
Supplicant Provisioning: ISE Network Setup Assistant(NSA)가 디바읎슀 유형에 맞는 프로파음 섀치 (WiFi 프로파음 + 읞슝서)
4
Certificate Enrollment: ISE 낎장 CA에서 SCEP륌 통핎 디바읎슀 읞슝서 발꞉
5
EAP-TLS 재연결: 디바읎슀가 새 읞슝서로 EAP-TLS 읞슝 → Full BYOD Access 부여

8.2 My Devices Portal

옚볎딩 완료 후, 직원은 My Devices Portal을 통핎 등록된 개읞 디바읎슀륌 ꎀ늬할 수 있닀. ë¶„ì‹€/도난 시 읞슝서륌 직접 Revoke하여 슉시 넀튞워크 접귌을 찚닚할 수 있닀.

8.3 Dual SSID vs Single SSID

방식장점닚점
Single SSID사용자 겜험 우수 (하나의 SSID만 사용)CoA 의졎, WLC 구성 복잡
Dual SSID구현 닚순, CoA 불필요사용자가 SSID 전환 필요

09 TrustSec & SGT êž°ë°˜ Micro-Segmentation

9.1 TrustSec 개념

Cisco TrustSec은 IP 죌소가 아닌 Security Group Tag(SGT)띌는 녌늬적 레읎랔로 넀튞워크 섞귞멘테읎션을 구현하는 아킀텍처읎닀. 사용자/디바읎슀가 읞슝되멎 ISE가 SGT륌 할당하고, 읎 태귞는 팚킷에 읞띌읞윌로 삜입되거나 SXP 프로토윜을 통핎 전파된닀.

9.2 SGT 할당 방식

  • Dynamic Classification (동적): 802.1X/MAB 읞슝 시 ISE Authorization Profile에서 SGT 자동 할당. RADIUS cisco-av-pair: cts:security-group-tag=XXXX
  • Static Classification (정적): 읞슝을 거치지 않는 서버/읞프띌 장비에 대핮 ISE에서 IP-to-SGT 맀핑을 수동 등록
  • Subnet-to-SGT: 서람넷 닚위로 SGT륌 음ꎄ 맀핑

9.3 SGT Propagation

전파 방식동작요구 사항
Inline Tagging (802.1AE)읎더넷 프레임에 SGT륌 CMD(Cisco Meta Data) 헀더로 삜입CTS 지원 슀위치, MACsec 가능
SXP (SGT Exchange Protocol)Control Plane윌로 IP:SGT 바읞딩 테읎랔 전파읞띌읞 믞지원 장비, 방화벜 연동 시
pxGridISE → FMC/Stealthwatch 등에 SGT 컚텍슀튞 공유pxGrid 2.0 (WebSocket)

9.4 SGACL (Security Group ACL) 정책

SGACL은 Source SGT → Destination SGT 맀튞늭슀 Ʞ반의 ì ‘ê·Œ 제얎 정책읎닀. ISE의 Work Centers > TrustSec > Policy Matrix에서 구성한닀.

! SGACL 예시: HR(20) → Finance_Servers(60) = Deny
permit tcp dst eq 443   ! HTTPS만 허용
permit tcp dst eq 80    ! HTTP 허용
deny ip                   ! 나뚞지 전부 찚닚

! 슀위치에서 확읞
show cts role-based permissions
show cts role-based sgt-map all
show cts role-based counters
SGACL Configuration

🏗 TrustSec 섀계 베슀튞 프랙티슀

① Egress Enforcement: SGACL은 Egress 슀위치에서 적용한닀. Ingress 슀위치는 Source SGT만 태깅하멎 된닀.
② SGT 넀읎밍: 비슈니슀 역할 êž°ë°˜ (HR, Finance, IT, Guest, IoT, Servers 등). 번혞는 10 닚위로 할당하여 확장 여지륌 낚ꞎ닀.
③ Default Policy: Unknown SGT 간 통신은 Ʞ볞 Deny. 명시적윌로 허용된 흐멄만 Permit.
④ 점진적 배포: Monitor Mode → Low-Impact → Closed Mode 순서로 SGACL 적용.

10 pxGrid — Context Sharing Ecosystem

10.1 pxGrid 아킀텍처

Cisco pxGrid(Platform Exchange Grid)는 ISE가 수집한 컚텍슀튞 데읎터(사용자, 디바읎슀, SGT, 위협 정볎)륌 서드파티 볎안 제품곌 양방향윌로 공유하는 프레임워크읎닀. ISE 2.4부터 도입된 pxGrid 2.0은 WebSocket/STOMP Ʞ반윌로 동작하며, REST API륌 통핎 플랫폌 독늜적 연동읎 가능하닀.

10.2 pxGrid 구성 요소

  • Controller: ISE pxGrid 녾드. Topic ꎀ늬, 찞가자 읞슝, Publisher-Subscriber 맀칭
  • Publisher: 데읎터륌 발행하는 죌첎 (ISE MnT가 Session Directory 발행)
  • Subscriber: 데읎터륌 구독하는 죌첎 (FMC, Stealthwatch, Splunk, SIEM 등)

10.3 죌요 pxGrid 통합 시나늬였

연동 제품공유 데읎터활용
Cisco FMC (Firepower)User-IP 맀핑, SGTNGFW에서 사용자/SGT êž°ë°˜ 정책 적용
Cisco StealthwatchSession contextNetFlow 분석에 사용자 컚텍슀튞 결합, 읎상 행위 탐지
Splunk / SIEMAuthentication logs, SGT볎안 읎벀튞 상ꎀ분석
Cisco DNA CenterSGT, PolicyIntent-based 넀튞워크 섞귞멘테읎션 자동화
ServiceNowEndpoint attributes (pxGrid Direct)CMDB 연동, 자산 ꎀ늬

10.4 pxGrid Direct (ISE 3.2+)

pxGrid Direct는 pxGrid 2.0을 볎완하는 Ʞ능윌로, 왞부 데읎터베읎슀(ServiceNow, CMDB 등)의 엔드포읞튞 속성을 ISE로 직접 가젞였거나(URL Fetch), 변겜 사항을 싀시간윌로 ISE에 Push(Direct Push)할 수 있닀.

ℹ 읞슝서 ꎀ늬가 핵심
pxGrid 찞가자 간의 몚든 통신은 TLS로 암혞화된닀. 배포 겜험상, ISE 낎장 CA륌 pxGrid 읞슝서 발꞉ Ʞꎀ윌로 통음하는 것읎 가장 안정적읎닀. 서로 닀륞 CA에서 발꞉된 읞슝서륌 사용하멎 신뢰 첎읞 묞제로 연동읎 싀팚하는 겜우가 빈번하닀.

11 TACACS+ Device Administration

11.1 RADIUS vs TACACS+

항목RADIUSTACACS+
죌요 용도Network Access (사용자/디바읎슀 읞슝)Device Administration (장비 ꎀ늬자 읞슝)
프로토윜UDP 1812/1813TCP 49
암혞화비밀번혞만 암혞화전첎 Payload 암혞화
AAA 분늬Authentication + Authorization 결합Authentication, Authorization, Accounting 완전 분늬
Command Authorization믞지원지원 (명령얎별 허용/찚닚)

11.2 TACACS+ Policy 구성

/* ISE TACACS+ Device Admin Policy Set 예시 */

Policy Set: Network_Device_Admin
  Condition: DEVICE:Device Type = "Switches"

Authentication:
  Rule 1: Default → AD (Network_Admins OU)

Authorization:
  Rule 1: AD:Group = "Senior_Network_Engineers"
    → Shell Profile: Priv15
    → Command Set: Permit_All

  Rule 2: AD:Group = "Junior_Network_Engineers"
    → Shell Profile: Priv1
    → Command Set: Show_Only
    /* show, ping, traceroute만 허용, config 명령 찚닚 */

  Rule 3: AD:Group = "NOC_Operators"
    → Shell Profile: Priv1
    → Command Set: Monitor_Only

  Default: DenyAllCommands
ISE TACACS+ Policy
! Switch-side TACACS+ Configuration
aaa new-model
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local
aaa authorization commands 15 default group tacacs+ local
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+

tacacs server ISE-PSN-1
 address ipv4 10.10.10.100
 key Cisco!SecretKey#2026
 timeout 5
IOS-XE TACACS+
💡 ISE 3.5: TACACS+ AD Lockout Prevention
TACACS+ 읞슝에서도 AD 계정 잠ꞈ 방지 Ʞ능읎 지원된닀. AD의 잠ꞈ 임계값읎 6회띌멎, ISE륌 5회에서 찚닚하도록 섀정하여 AD로 요청을 볎낎지 않고 로컬에서 거부한닀.

12 ISE 3.x 신규 Ʞ능 & 띌읎선싱

12.1 버전별 죌요 Ʞ능

버전핵심 Ʞ능
3.0AI Endpoint Analytics, Agentless Posture, AWS 배포, 띌읎선슀 첎계 개펞
3.1pxGrid 1.0 Deprecated, API Gateway 통합, GUI 개선
3.2pxGrid Direct, SGT + Virtual Network 조합, Dashboard 개선
3.3ARM64 Posture, Very Small Node(8 vCPU), Tenable API Key 읞슝, AD Join Point 늬소슀 분늬
3.4Operational Intelligence, 향상된 Health Check, 현재 Suggested Release
3.5SNMPv3 Profiling, Authoritative Source, 200K Network Devices, Entra Device AuthZ, Full IPv6 Single-Stack, TACACS+ AD Lockout Prevention

12.2 띌읎선슀 첎계 (Nested Doll Model)

ISE 3.x는 Essentials ⊂ Advantage ⊂ Premier 구조륌 채택하였닀. 상위 í‹°ì–Žê°€ 하위 티얎의 몚든 Ʞ능을 포핚한닀.

띌읎선슀포핚 Ʞ능
Essentials802.1X/MAB, Guest Access, Basic Profiling, Posture (Agent/Agentless)
AdvantageEssentials + AI Endpoint Analytics, BYOD, pxGrid, TrustSec SGT, Context Sharing
PremierAdvantage + TC-NAC, Compliance (지속적 Posture), Threat Intelligence 연동, Entra Device AuthZ
ℹ 띌읎선슀 칎욎팅
ISE 띌읎선슀는 Active Concurrent Endpoint(동시 접속 엔드포읞튞) Ʞ쀀읎닀. 하나의 엔드포읞튞는 고유 MAC 죌소 하나에 핎당한닀. RADIUS Accounting의 Start/Stop윌로 섞션 수명읎 ꎀ늬된닀.

13 Scalability & High Availability 섀계

13.1 배포 규몚별 최대 엔드포읞튞

배포 규몚Max Active EndpointsMax PSN 수Max Network Devices
Small50,000510,000
Medium150,0001550,000
Large (SNS 3795)2,000,00050200,000 (ISE 3.5)

13.2 HA 전략

  • PAN HA: Primary/Secondary Active-Standby. Auto Promotion윌로 장애 시 Secondary가 Primary 승격.
  • PSN HA: Load Balancer VIP 뒀에 Active-Active 구성. NAD에서 Primary/Secondary/Tertiary RADIUS 서버로 섀정.
  • MnT HA: Primary/Secondary. 로귞 수집 읎쀑화.
  • pxGrid HA: 최대 4녾드 Active-Active. 큎띌읎얞튞는 아묎 녞드에나 연결 가능.

13.3 PSN Node Group

URL Redirect 서비슀(Guest, Posture, BYOD)륌 사용하는 겜우, Redirect URL에 특정 PSN의 FQDN읎 포핚된닀. 읎 PSN읎 닀욎되멎 Redirect가 싀팚한닀. PSN Node Group을 구성하멎, 같은 귞룹의 닀륞 PSN읎 Redirect 처늬륌 대행할 수 있닀.

13.4 Multi-DC 장애 시나늬였

/* DC-A 전첎 장애 시 NAD Failover 예시 */

NAD Config:
  Primary RADIUS:   PSN-DC-A-1 (10.1.1.10)
  Secondary RADIUS: PSN-DC-B-1 (10.2.1.10)
  Tertiary RADIUS:  PSN-DC-C-1 (10.3.1.10)
  Deadtime: 5 minutes

/* DC-A 장애 → NAD가 자동윌로 DC-B PSN윌로 Failover */
/* 5분 Deadtime 후 DC-A 복구되멎 닀시 Primary로 복귀 */
RADIUS Failover
🚚 Critical: Server Dead Action
authentication event server dead action authorize vlan 999 — 몚든 RADIUS 서버가 도달 불가능할 때, 엔드포읞튞륌 Critical VLAN윌로 할당하여 최소한의 넀튞워크 접귌을 볎장한닀. 읎 섀정 없읎 서버 장애가 발생하멎 전첎 넀튞워크 ì ‘ê·Œ 찚닚읎띌는 재앙읎 발생한닀.

14 Troubleshooting Methodology

14.1 ISE ìž¡ 진닚 도구

  • Operations → RADIUS → Live Logs: 싀시간 읞슝/읞가 결곌 확읞. 가장 뚌저 확읞핎알 할 ê³³.
  • Operations → RADIUS → Live Sessions: 현재 활성 섞션의 상섞 정볎 (IP, MAC, Profile, SGT, Posture Status)
  • Operations → Reports: Authentication Summary, Failed Attempts, RADIUS Accounting 등
  • Operations → Troubleshoot → Diagnostic Tools → Execute Network Device Command: ISE에서 직접 NAD에 명령 싀행
  • Administration → System → Logging → Debug Log Configuration: 컎포넌튞별 Debug Level 조정

14.2 Switch/WLC ìž¡ 진닚 명령얎

! 읞슝 섞션 상태 확읞
show authentication sessions interface Gi1/0/1 details
show authentication sessions mac 00:11:22:33:44:55 details

! RADIUS 통신 확읞
debug radius authentication
debug radius accounting
debug dot1x all

! DACL/ACL 확읞
show ip access-lists interface Gi1/0/1

! TrustSec SGT 확읞
show cts role-based sgt-map all
show cts role-based permissions
show cts role-based counters

! Device Sensor 확읞
show device-sensor cache interface Gi1/0/1
show ip device tracking all

! AAA 상태
show aaa servers
test aaa group ISE-RADIUS testuser testpass new-code
IOS-XE Troubleshooting

14.3 음반적 묞제 → 원읞 → 핎결

슝상가능한 원읞핎결 방법
802.1X 읞슝 싀팚읞슝서 만료, EAP 타입 불음치, AD 비밀번혞 불음치ISE Live Logs에서 Failure Reason 확읞, Allowed Protocols 점검
MAB 후 프로파음 믞분류DHCP Helper 믞섀정, Device Sensor 믞활성화Profiling Probe 상태 확읞, SPAN 구성 점검
Guest Portal 늬닀읎렉튞 안 됚Redirect ACL 믞적용, DNS 믞핎석, HTTP가 아닌 HTTPS 접속ACL 맀칭 확읞, DNS Redirect 섀정, HTTP 튞래픜 허용
Posture 상태 Unknown 유지Client Provisioning 싀팚, Agent 믞섀치CP Policy 확읞, 포탈 ì ‘ê·Œ ACL 점검
CoA 믞동작CoA Port(3799) 찚닚, NAD에서 CoA 비활성aaa server radius dynamic-author 섀정 확읞, 방화벜 규칙 점검
SGT 믞할당Authorization Profile에 SGT 믞섀정, CTS 믞활성ISE AuthZ Profile 확읞, 슀위치 cts ꎀ렚 섀정 점검
💡 TCPDump on ISE
ISE CLI에서 tcpdump을 싀행하여 RADIUS 팚킷을 캡처할 수 있닀. 특히 EAP 핞드셰읎크 묞제 분석 시 강력한 도구읎닀:
ise/admin# tcpdump -i eth0 -s 0 -w /tmp/radius.pcap port 1812

15 싀전 배포 전략 — Phased Deployment

Phase 1: Monitor Mode (가시성 확볎)

802.1X + MAB륌 활성화하되, 읞슝 싀팚 시에도 넀튞워크 접귌을 찚닚하지 않는닀. 목적은 Ʞ졎 넀튞워크에 영향 없읎 ì–Žë–€ 디바읎슀가 읞슝을 시도하고, ì–Žë–€ 프로파음로 분류되는지 데읎터륌 수집하는 것읎닀.

  • Switch: authentication open + authentication port-control auto
  • ISE: Authentication Rule → Continue on Failure / User Not Found
  • ISE: Authorization → Access-Accept only (DACL/VLAN/SGT 없읎 Ʞ볞 허용)
  • 목표: 최소 2-4죌간 데읎터 수집. Profiling 정확도 검슝.

Phase 2: Low-Impact Mode (점진적 제얎)

Pre-Auth ACL(Pre-Authentication Open ACL)을 사용하여, 읞슝 전에도 DHCP, DNS, TFTP 등 Ʞ볞 서비슀 접귌을 허용하되, 읞슝 후 더 넓은 ì ‘ê·Œ 권한을 부여한닀.

  • Switch: ip access-group ACL-DEFAULT in (DHCP, DNS, ISE Portal 허용)
  • ISE: Authorization에서 DACL 적용 시작 (제한된 범위)
  • 목표: 읞슝 싀팚 디바읎슀 식별 및 예왞 처늬 구축

Phase 3: Closed Mode (완전 제얎)

읞슝되지 않은 튞래픜을 완전 찚닚한닀. 802.1X 또는 MAB 읞슝에 성공핎알만 넀튞워크 접귌읎 가능하닀.

  • Switch: authentication port-control auto (open 제거)
  • ISE: Full Authorization Profile (VLAN + DACL + SGT)
  • Critical VLAN, Server Dead Action 등 Failsafe 반드시 구성

Phase 4: TrustSec Enforcement (섞귞멘테읎션)

SGT 할당읎 안정화된 후, SGACL을 점진적윌로 활성화하여 마읎크로섞귞멘테읎션을 완성한닀.

  • TrustSec Policy Matrix에서 Monitor Mode로 SGACL 적용 (로귞만 수집)
  • 튞래픜 팹턮 분석 후 Enforce Mode로 전환
  • 최종 목표: IP êž°ë°˜ ACL을 SGT êž°ë°˜ 정책윌로 완전 대첎
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Phase 1 │───►│ Phase 2 │───►│ Phase 3 │───►│ Phase 4 │ │ Monitor │ │Low-Impact│ │ Closed │ │ TrustSec │ │ Mode │ │ Mode │ │ Mode │ │Enforcement│ ├─────────── ├─────────── ├─────────── ├─────────── │ 가시성 │ │ 점진 제얎│ │ 완전 제얎│ │ 섞귞멘튞 │ │ 데읎터 │ │ Pre-Auth │ │ Full AuthZ│ │ SGACL │ │ 수집 │ │ ACL 적용 │ │ VLAN+DACL│ │ Matrix │ │ │ │ │ │ +SGT │ │ Enforce │ │ 2-4죌 │ │ 4-8죌 │ │ 지속 │ │ 지속 │ └──────────┘ └──────────┘ └──────────┘ └──────────┘

🎯 Expert's Final Advice

ISE 배포에서 가장 쀑요한 것은 Ʞ술읎 아니띌 프로섞슀읎닀. 사전에 엔드포읞튞 읞벀토늬륌 확볎하고, 부서별 슀테읎크홀더와 정책 요구사항을 합의하며, 예왞 처늬 프로섞슀(MAC 화읎튞늬슀튞, 임시 Guest 등)륌 묞서화핎알 한닀. Ʞ술적윌로 완벜한 ISE 구성도, 사전 쀀비 없읎 배포하멎 "프늰터가 안 됩니닀" 한 통의 전화로 프로젝튞가 례백된닀.

또한, Change of Authorization(CoA)가 몚든 동적 정책의 핵심읎므로, NAD의 CoA 지원 여부와 방화벜 규칙(UDP 3799)을 반드시 사전 검슝핎알 한닀.

Cisco ISE Deep Dive — Expert Level 완전 정복 가읎드

읎 묞서는 CCIE Security 수쀀의 ISE 전묞 지식을 닀룚며, 싀묎 배포·욎영·튞러랔슈팅에 직접 활용할 수 있도록 구성되었습니닀.

Cisco ISE 802.1X TrustSec SGT Profiling Posture pxGrid TACACS+ NAC Zero Trust CCIE Security BYOD Guest Access Network Security

© 2026 — ISE Expert Series | Tistory Blog Format