Cisco Network Configuration Compliance & Security Audit

Networking / Cisco / Network Security

การกำหนดค่าที่ปลอดภัยไม่ได้จบลงเมื่อเปิดใช้งานอุปกรณ์ แต่ต้องมีหลักฐานว่า Configuration ปัจจุบันยังตรงตามมาตรฐานองค์กร บทความนี้อธิบายกระบวนการ Golden Configuration → Read-Only Audit → Risk Scoring → Remediation → Verification สำหรับ Cisco IOS และ IOS XE โดยเน้นการทำงานที่ตรวจสอบย้อนหลังได้

1. Cisco Network Configuration Compliance คืออะไร

Configuration Compliance คือการตรวจสอบการตั้งค่าอุปกรณ์เครือข่ายเทียบกับข้อกำหนดที่องค์กรอนุมัติ เช่น การใช้ SSH แทน Telnet, การกำหนด AAA, การส่ง Syslog, การจำกัด Management Access และการปิดบริการที่ไม่จำเป็น

การตรวจสอบแบ่งเป็นสามมิติ: Security (ลดพื้นผิวโจมตี), Operations (ทำงานตามมาตรฐานและกู้คืนได้) และ Evidence (พิสูจน์ได้ว่าใครตรวจอะไร เมื่อใด และพบอะไร)

Compliance ไม่เท่ากับ Security ทั้งหมด

การผ่าน Checklist ไม่ได้ยืนยันว่าอุปกรณ์ปลอดภัยจากช่องโหว่ทุกชนิด ต้องใช้ร่วมกับการจัดการ Firmware, Vulnerability Assessment, Monitoring, Access Review และ Incident Response

Baseline ต้องแยกตามประเภทอุปกรณ์

Access Switch, Distribution Switch, Router, Firewall และอุปกรณ์ที่รองรับ IOS/IOS XE ต่างรุ่น อาจใช้คำสั่งและคุณสมบัติต่างกัน ห้ามนำ Baseline ชุดเดียวไปใช้โดยไม่ตรวจสอบ Platform และ Business Requirement

2. สถาปัตยกรรมการตรวจสอบ Configuration

                  Management Network
                       192.168.99.0/24
                             |
                   Audit Workstation
                  (Python / SSH / Git)
                             |
                 +-----------+-----------+
                 |           |           |
              SW-ACC01    SW-ACC02     R-HQ01
             .99.11       .99.12       .99.1
                 |           |           |
             Running Config / Show Commands
                             |
                    Read-Only Collection
                             |
              Golden Baseline + Rule Engine
                             |
                 Findings / Risk / Evidence
                             |
               Review → Change → Re-Audit

ตัวอย่างนี้ใช้ IP สมมติสำหรับ Lab เท่านั้น เครื่อง Audit ต้องเข้าถึง Management Interface ผ่านเครือข่ายที่ได้รับอนุญาต และใช้บัญชีที่มีสิทธิ์เพียงพอสำหรับอ่านข้อมูล โดยไม่ให้สิทธิ์เปลี่ยน Configuration หากไม่จำเป็น

สิ่งที่ต้องเตรียม

Device Inventory ที่ระบุ Hostname, IP, รุ่น, IOS Version, Owner และ Criticality
Golden Baseline ที่ได้รับอนุมัติและมี Version
ช่องทาง SSH และการยืนยัน Host Key
พื้นที่เก็บหลักฐานที่เข้ารหัส จำกัดสิทธิ์ และกำหนดระยะเวลาเก็บ
Change Ticket และผู้อนุมัติสำหรับการแก้ไข Production

3. Golden Configuration: มาตรฐานอ้างอิงที่ตรวจสอบได้

Golden Configuration ไม่จำเป็นต้องเป็นไฟล์ Running Configuration ทั้งชุดเสมอไป ควรกำหนดเป็น Control Objectives และ Expected State ที่ปรับตามรุ่นและบทบาทของอุปกรณ์ได้

ตัวอย่าง Golden Baseline

Control ID	วัตถุประสงค์	Expected State	หลักฐาน
NET-001	Remote Management	อนุญาต SSH และไม่อนุญาต Telnet บน VTY	show running-config \| section line vty
NET-002	Access Restriction	Management Access จำกัดตาม ACL ที่อนุมัติ	VTY access-class / Management Plane Policy
NET-003	Logging	ส่ง Log ไปยัง Syslog Server ที่กำหนด	show logging
NET-004	Time Sync	มี NTP Source ที่อนุมัติและ Sync ได้	show ntp associations / status
NET-005	Authentication	ใช้ AAA ตามนโยบายและมี Fallback ที่ทดสอบแล้ว	show running-config \| section aaa
NET-006	SNMP	ใช้ SNMPv3 เมื่อรองรับและปิด Community ที่ไม่จำเป็น	show snmp user / config
NET-007	Layer 2 Edge	พอร์ตผู้ใช้ใช้ PortFast/BPDU Guard ตาม Design	show spanning-tree summary / interface
NET-008	Backup	สำรอง Config และทดสอบ Restore ตามรอบ	Backup Log / Restore Test

ตัวอย่าง Configuration เฉพาะสำหรับ Lab

! ตัวอย่างเท่านั้น: ต้องตรวจสอบนโยบายและ IOS รุ่นที่ใช้
ip ssh version 2
service timestamps log datetime msec
logging host 192.168.99.50
ntp server 192.168.99.60
!
line vty 0 4
 transport input ssh
 login authentication default

ข้อควรระวัง: ตัวอย่าง VTY อ้างอิง AAA Method List ชื่อ default ซึ่งต้องกำหนดและทดสอบให้พร้อมก่อนใช้งาน มิฉะนั้นอาจล็อกผู้ดูแลออกจากอุปกรณ์ อย่าคัดลอกคำสั่งนี้ไปใช้บน Production โดยตรง

Version Control สำหรับ Baseline

กำหนด Baseline ID, Version, Effective Date, Approver, Applicable Platforms, Exceptions และเหตุผลที่เปลี่ยนแปลง ตัวอย่าง CISCO-IOS-ACCESS-SWITCH-v1.0 พร้อมบันทึกใน Git Repository ที่จำกัดสิทธิ์ โดยไม่เก็บ Password หรือ Secret ในรูป Plaintext

4. Cisco CLI สำหรับเก็บ Audit Evidence

เริ่มจากคำสั่งอ่านข้อมูลก่อนทุกครั้ง บางคำสั่งอาจแตกต่างตาม IOS/IOS XE และสิทธิ์ของบัญชี

show version
show inventory
show running-config
show ip ssh
show users
show logging
show ntp status
show ntp associations
show snmp user
show access-lists
show interfaces status
show interfaces trunk
show spanning-tree summary
show ip interface brief

ตรวจสอบ VTY และ SSH

show running-config | section line vty
show ip ssh

ตรวจว่า VTY ที่ใช้งานทั้งหมดจำกัด transport input ssh และมี Access Restriction ตามนโยบาย หากพบ VTY หลายช่วง เช่น line vty 0 4 และ line vty 5 15 ต้องตรวจทุกช่วง ไม่ใช่เฉพาะช่วงแรก

ตรวจสอบ Logging และ NTP

show logging
show ntp status
show ntp associations

การมีบรรทัด logging host หรือ ntp server ใน Config ไม่ยืนยันว่าระบบปลายทางรับข้อมูลได้ ต้องตรวจสอบจาก Syslog Collector และสถานะ Synchronization จริงด้วย

ปกป้องข้อมูลจาก Running Configuration

show running-config อาจมีข้อมูลอ่อนไหว เช่น Shared Secret, Community String, IP Management และ Topology ต้องจัดเก็บอย่างจำกัดสิทธิ์ หลีกเลี่ยงการส่งไฟล์ดิบผ่านอีเมลหรือแนบใน Ticket ที่เปิดให้คนทั่วไปเข้าถึง

5. Security Audit Checklist และผลตรวจ

หัวข้อ	วิธีตรวจ	สถานะตัวอย่าง	แนวทางดำเนินการ
SSH Only	VTY transport input	Pass	ตรวจทุก VTY Range
Management ACL	access-class / Control Plane	Fail	กำหนด ACL ตาม Approved Management Subnet
Syslog	Config และ Collector	Pass	ทดสอบการรับ Log
NTP	Config และ Sync Status	Warning	ตรวจ Reachability และ NTP Peer
SNMP	Version / User / ACL	Review	ตรวจสิทธิ์และ Migration Plan
Config Backup	Backup Job / Restore Test	Pass	ตรวจความสมบูรณ์และการกู้คืน

Pass = ตรง Baseline, Fail = ไม่ตรง, Warning = ต้องตรวจเพิ่ม, Not Applicable = ไม่ใช้กับอุปกรณ์นี้โดยมีเหตุผลอนุมัติ และ Unknown = หลักฐานไม่เพียงพอ ห้ามนับ Unknown เป็น Pass

6. Automated Configuration Audit ด้วย Python และ Netmiko

Lab นี้เป็น Read-Only Audit โดยดึงเฉพาะบรรทัด VTY จาก Cisco IOS/IOS XE และตรวจว่าทุก VTY Block ที่พบกำหนดให้รับเฉพาะ SSH หรือไม่ ตัวอย่างนี้ยังไม่ใช่ Compliance Engine ครบทุก Control

ติดตั้ง Dependencies

python -m venv .venv
# Windows PowerShell
.venv\Scripts\Activate.ps1
# Linux / macOS: source .venv/bin/activate
python -m pip install netmiko

Python Audit Script

import getpass
import re
from datetime import datetime, timezone
from netmiko import ConnectHandler

HOST = "192.168.99.11"  # Lab device only
USERNAME = input("SSH username: ")
PASSWORD = getpass.getpass("SSH password: ")

connection = {
    "device_type": "cisco_ios",
    "host": HOST,
    "username": USERNAME,
    "password": PASSWORD,
    "conn_timeout": 10,
}

try:
    with ConnectHandler(**connection) as ssh:
        output = ssh.send_command(
            "show running-config | section ^line vty"
        )

    blocks = re.split(r"(?=^line vty )", output, flags=re.MULTILINE)
    blocks = [b.strip() for b in blocks if b.strip().startswith("line vty ")]

    findings = []
    for block in blocks:
        lines = [line.strip() for line in block.splitlines()]
        transport = [line for line in lines if line.startswith("transport input ")]
        passed = transport == ["transport input ssh"]
        findings.append({"vty": lines[0], "pass": passed})

    overall_pass = bool(findings) and all(item["pass"] for item in findings)
    timestamp = datetime.now(timezone.utc).isoformat()

    print(f"Audit UTC: {timestamp}")
    print(f"Device: {HOST}")
    for item in findings:
        status = "PASS" if item["pass"] else "REVIEW"
        print(f"{item['vty']}: {status}")
    print("Overall:", "PASS" if overall_pass else "REVIEW")

except Exception as exc:
    # Avoid dumping credentials or full sensitive device output.
    print(f"Audit failed: {type(exc).__name__}")

ข้อจำกัดของ Script

การตรวจนี้อาศัยรูปแบบผลลัพธ์ CLI และอาจไม่ครอบคลุมค่า Default, Template, Parser Variations หรือ VTY ที่ถูกควบคุมด้วยนโยบายอื่น การไม่พบ transport input ssh จึงให้สถานะ REVIEW ไม่สรุปว่าอุปกรณ์เปิด Telnet เสมอไป ก่อนใช้งานจริงควรทดสอบกับรุ่นอุปกรณ์และใช้ Structured Parser หรือ Ansible Resource Modules ที่เหมาะสม

เพื่อความปลอดภัยของข้อมูลรับรอง ให้ตรวจสอบ SSH Host Key ก่อนใช้งานจริง และเลือกใช้ Secret Manager หรือ Vault แทนการฝังรหัสผ่านใน Source Code

การขยายสู่หลายอุปกรณ์

แยก Inventory เป็น CSV/YAML, เพิ่ม Device Role, Baseline Version, Control ID, Severity และ Evidence Reference จากนั้นส่งออก JSON/CSV โดยไม่บันทึก Secrets หากต้องการตรวจหลายร้อยอุปกรณ์ ควรเพิ่ม Concurrency Limit, Retry Policy และ Rate Limiting เพื่อไม่ให้ระบบ Management รับภาระเกินจำเป็น

7. Risk Scoring: จัดลำดับการแก้ไขตามผลกระทบ

การพบ Configuration ที่ไม่ตรง Baseline ไม่ได้หมายความว่าทุกข้อมีความเร่งด่วนเท่ากัน ตัวอย่างโมเดลคะแนนภายในองค์กรสามารถคำนวณจาก Likelihood × Impact โดยให้แต่ละตัวแปรมีคะแนน 1–5

Risk Score = Likelihood (1–5) × Impact (1–5)

1–4    = Low
5–9    = Medium
10–16  = High
17–25  = Critical

ช่วงคะแนนนี้เป็น ตัวอย่างเกณฑ์ภายใน ไม่ใช่มาตรฐานสากลตายตัว ต้องปรับตาม Risk Appetite ขององค์กร

Finding	Likelihood	Impact	Score	Priority
Telnet เปิดรับจากเครือข่ายที่เข้าถึงได้	5	5	25	Critical
Management ACL ไม่ตรงนโยบาย	4	4	16	High
ไม่มี Syslog Collector สำรอง	3	3	9	Medium
Hostname ไม่ตรง Naming Standard	2	1	2	Low

คะแนนตัวอย่างขึ้นกับสมมติฐาน ไม่ใช่การประเมินความเสี่ยงของอุปกรณ์จริง ต้องพิจารณา Exposure, Asset Criticality, Existing Controls และ Business Impact ร่วมด้วย

8. Configuration Drift Detection และ Change Control

Configuration Drift คือการเปลี่ยนแปลงจาก Baseline ที่ได้รับอนุมัติ เช่น มีการเปิดบริการ Management เพิ่ม, เปลี่ยน ACL, เปลี่ยน NTP Server หรือปรับ Port Configuration โดยไม่มี Change Record ที่สอดคล้อง

Workflow ตรวจ Drift

เก็บ Running Configuration ด้วยบัญชี Read-Only ตามรอบที่กำหนด
Normalize ข้อมูลที่เปลี่ยนโดยธรรมชาติ เช่น Timestamp หรือบรรทัดที่ไม่เกี่ยวกับ Control
เปรียบเทียบกับ Approved Baseline และ Last Known Good
จัดประเภท Authorized Change, Unauthorized Change, Expected Exception
เปิด Finding และผูก Change Ticket สำหรับรายการที่ต้องแก้ไข
Re-Audit หลังแก้ไขและเก็บหลักฐานก่อน/หลัง

ทำไมไม่ควรใช้ Text Diff อย่างเดียว

การสลับลำดับบรรทัด การแสดงค่า Default และความแตกต่างของ IOS Version อาจทำให้เกิด False Positive จึงควรใช้การเปรียบเทียบเชิงความหมาย (Semantic Comparison) หรือ Control-Based Checks สำหรับการตัดสิน Compliance

9. Remediation Workflow: แก้ไขโดยไม่เพิ่มความเสี่ยง

ห้ามนำผล Audit ไปสั่งแก้ Configuration อัตโนมัติบน Production ทันที ควรแยก Detect และ Remediate ออกจากกัน

Confirm: ยืนยัน Finding ด้วยคำสั่งที่เหมาะสมและตรวจสอบผลกระทบ
Assess: ระบุอุปกรณ์ที่ได้รับผลกระทบ ความเสี่ยง และ Dependency
Approve: เปิด Change Ticket ระบุผู้อนุมัติและ Maintenance Window
Backup: สำรอง Running/Startup Configuration และตรวจสอบไฟล์
Prepare: สร้าง Implementation Plan, Verification Plan และ Rollback Plan
Implement: ทดสอบกับ Lab หรือ Pilot Device ก่อนขยายผล
Verify: ตรวจ Management Reachability, AAA, Logging และบริการที่เกี่ยวข้อง
Close: Re-Audit, แนบ Evidence และปิด Change Ticket

ตัวอย่าง Change Plan สำหรับ Management Access

กรณีตรวจพบ VTY อนุญาต Telnet ให้ทดสอบ SSH และ AAA ให้ทำงานก่อน วาง Out-of-Band Console Access และกำหนด Rollback Method ที่ทดสอบได้ จากนั้นจึงพิจารณาปรับ VTY ตาม Change Window โดยไม่ใช้คำสั่งเปลี่ยนระบบจากบทความนี้โดยตรง

Rollback ต้องยืนยันได้

เก็บค่าเดิมที่ได้รับอนุมัติและทดสอบวิธี Restore ใน Lab โดยเฉพาะการเปลี่ยน AAA, VTY, ACL และ Routing ซึ่งอาจทำให้ผู้ดูแลสูญเสียการเชื่อมต่อ การมีไฟล์ Backup อย่างเดียวไม่เพียงพอหากไม่มีช่องทางเข้าถึงอุปกรณ์เมื่อเกิดปัญหา

10. Hands-on Lab: ตรวจสอบ Cisco Switch แบบ Read-Only

Lab Objective

ตรวจสอบ Access Switch ในเครือข่ายทดสอบว่าใช้ SSH Only, มี Syslog Server และมี NTP Synchronization หรือไม่ โดยไม่เปลี่ยน Configuration

Step 1 — เตรียมข้อมูล

Device: SW-ACC01
Management IP: 192.168.99.11
Baseline: CISCO-IOS-ACCESS-SWITCH-v1.0
Scope: SSH, Logging, NTP

Step 2 — รวบรวมหลักฐาน

show version
show ip ssh
show running-config | section line vty
show logging
show ntp status

Step 3 — ประเมินผล

Control	Expected	Observed (สมมติ)	Result
NET-001	VTY ใช้ SSH Only	ทุก VTY ระบุ SSH	Pass
NET-003	Syslog ส่งถึง Collector	มี Config แต่ยังไม่ยืนยัน Collector	Warning
NET-004	NTP Synchronized	สถานะ Unsynchronized	Fail

Step 4 — สร้าง Finding

Finding ID: AUD-2026-001
Device: SW-ACC01
Control: NET-004
Observation: NTP ยังไม่ Synchronize
Potential Impact: Timestamp ของ Log อาจคลาดเคลื่อน ทำให้ Correlation เหตุการณ์ยากขึ้น
Recommendation: ตรวจ NTP Reachability, Source Interface, ACL และ Server Status ก่อนเสนอ Change
Verification: ตรวจสถานะ NTP อีกครั้งและเปรียบเทียบเวลากับแหล่งอ้างอิง

Step 5 — Re-Audit

หลังการแก้ไขที่ได้รับอนุมัติ ให้ตรวจผลอีกครั้งและแนบหลักฐานที่มี Timestamp โดยบันทึกทั้งผลก่อนและหลัง ไม่แก้ไข Evidence เดิมทับ

11. Audit Report, Evidence และ KPI

โครงสร้างรายงานที่ควรมี

Field	ตัวอย่าง
Audit ID	NET-AUD-2026-010
Scope	Access Switch 10 อุปกรณ์
Baseline	CISCO-IOS-ACCESS-SWITCH-v1.0
Execution Time	UTC Timestamp
Auditor / Approver	ผู้ตรวจ / ผู้อนุมัติ
Finding ID / Control ID	AUD-2026-001 / NET-004
Risk / Status	Medium / Open
Evidence Reference	Encrypted Evidence Store Path
Change Ticket	CHG-2026-021
Re-Audit Result	Pending / Pass / Fail

ตัวอย่าง KPI สำหรับ Network Compliance

Compliance Rate: Controls ที่ผ่าน / Controls ที่ประเมินได้ × 100 (ไม่นับ N/A แต่รายงาน Unknown แยก)
Critical Finding Count: จำนวนข้อค้นพบความเสี่ยงสูงสุดที่ยังเปิดอยู่
Mean Time to Remediate: ระยะเวลาเฉลี่ยจากยืนยัน Finding จนแก้ไขและ Re-Audit ผ่าน
Audit Coverage: จำนวนอุปกรณ์ที่ตรวจสำเร็จ / จำนวนอุปกรณ์ใน Scope × 100
Unauthorized Drift Count: จำนวนการเปลี่ยน Configuration ที่ไม่สัมพันธ์กับ Change Record ที่อนุมัติ

Security ของ Evidence

จัดเก็บผล Audit ด้วย Access Control, Encryption, Retention Policy และ Integrity Check เช่น SHA-256 Hash พร้อมแยกสิทธิ์ผู้ตรวจและผู้อนุมัติ หากรายงานต้องเผยแพร่ ให้ Redact Password, Secret, Community String, Management IP และรายละเอียดที่ไม่จำเป็นตามนโยบายองค์กร

12. คำถามที่พบบ่อย (FAQ)

ใช้ Cisco Configuration Backup แทน Compliance Audit ได้หรือไม่

ไม่ได้ทั้งหมด Backup บอกว่าระบบตั้งค่าอะไรอยู่ แต่ Compliance Audit ต้องเทียบกับมาตรฐานที่ได้รับอนุมัติ ตรวจความถูกต้อง และสร้างหลักฐานผลการประเมิน

ควรตรวจ Configuration บ่อยเพียงใด

ขึ้นอยู่กับความสำคัญของอุปกรณ์และความเสี่ยง ตัวอย่างแนวทางคือหลังทุก Change, ตามรอบรายสัปดาห์หรือรายเดือน และเมื่อเกิด Incident โดยกำหนดตามนโยบายขององค์กร

ใช้ Ansible แทน Python ได้หรือไม่

ได้ Ansible เหมาะกับ Inventory, Playbook และการจัดการหลายอุปกรณ์ ส่วน Python เหมาะกับการเขียน Logic ตรวจสอบหรือประมวลผลข้อมูลเฉพาะทาง ทั้งสองสามารถทำงานร่วมกันได้

Compliance Audit เกี่ยวข้องกับ ISO/IEC 27001 อย่างไร

รายงาน Configuration Audit สามารถเป็นหลักฐานประกอบการดำเนินงานด้าน Configuration Management, Access Control, Logging และ Monitoring ตามขอบเขตของระบบบริหารความมั่นคงปลอดภัยสารสนเทศ แต่การตรวจ Config เพียงอย่างเดียวไม่ได้ทำให้องค์กรได้รับการรับรอง ISO/IEC 27001

สรุป

Cisco Network Configuration Compliance & Security Audit ที่ดีต้องเริ่มจาก Baseline ที่ได้รับอนุมัติ ตรวจด้วยวิธี Read-Only เท่าที่ทำได้ จัดเก็บ Evidence อย่างปลอดภัย ประเมินความเสี่ยงตามบริบทองค์กร และแก้ไขผ่าน Change Control พร้อม Rollback และ Re-Audit เพื่อรักษามาตรฐานเครือข่ายอย่างต่อเนื่อง