บทความโดย: ดร. วิรินทร์ เมฆประดิษฐสิน
ในอดีต ระบบความปลอดภัยเครือข่ายถูกออกแบบมาเหมือน “ปราสาทที่มีคูน้ำล้อมรอบ” (Castle and Moat) ใครก็ตามที่ข้ามคูน้ำและผ่านประตูเมืองเข้ามาได้ จะถูกถือว่าเป็น “คนภายใน” ที่ไว้ใจได้ แต่ในโลกยุค Hybrid Work ที่พนักงานทำงานจากคาเฟ่ จากบ้าน หรือจากต่างประเทศ แนวคิดนี้ใช้ไม่ได้อีกต่อไปครับ
วันนี้เราต้องเปลี่ยนแนวคิดใหม่เป็น “Never Trust, Always Verify” (ไม่เคยไว้ใจ และต้องตรวจสอบเสมอ) นี่คือหัวใจของบทความนี้ครับ เราจะมาดูวิธีการทำให้ FortiGate รู้จัก “ตัวตน” (Identity) ของผู้ใช้ และการใช้ ZTNA เพื่อสร้างอุโมงค์ความปลอดภัยรายแอปพลิเคชันที่เหนือชั้นกว่า VPN ทั่วไป
1. User Authentication: พื้นฐานของการระบุตัวตน (The Gatekeeper)
เราสามารถบอกได้ว่า “IP Address ไม่ใช่ตัวตน” เพราะเครื่องหนึ่งเครื่องอาจมีคนสลับกันใช้หลายคน หรือหนึ่งคนอาจใช้หลายอุปกรณ์ ดังนั้นการทำ Identity-based Access จึงเป็นก้าวแรกที่สำคัญ
1.1 Local Users vs. Remote Authentication
- Local Users: การสร้าง User ภายในเครื่อง FortiGate เอง เหมาะสำหรับองค์กรขนาดเล็ก หรือ Guest ที่เข้ามาใช้งานชั่วคราว
- Remote Authentication (Enterprise Integration): การเชื่อมต่อกับฐานข้อมูลกลางขององค์กร:
- LDAP / Active Directory (AD): หัวใจหลักขององค์กรส่วนใหญ่ ช่วยให้พนักงานใช้ Username/Password ชุดเดียวกับที่ใช้ Login คอมพิวเตอร์
- RADIUS: มาตรฐานสำหรับการยืนยันตัวตนผ่าน Wi-Fi หรืออุปกรณ์ Network อื่นๆ
1.2 Captive Portal: หน้าด่านสำหรับการยืนยันตัวตน
เมื่อ User พยายามออกอินเทอร์เน็ต FortiGate จะทำการ “กัก” (Interception) และเด้งหน้าจอ Login ขึ้นมา
- Authenticated Mode: ต้องใส่รหัสผ่านจึงจะใช้งานได้
- Disclaimer Mode: ให้กดยอมรับเงื่อนไขการใช้งานก่อน (เหมาะสำหรับ Guest หรือ Wi-Fi สาธารณะ)
2. 2FA/MFA: การเพิ่มเกราะชั้นที่สอง (Two-Factor Authentication)
ในยุคที่รหัสผ่านหลุดได้ง่ายเพียงแค่การคลิก Link Phishing การมีแค่ Password อย่างเดียวคือความประมาทครับ ผม แนะนำให้ใช้ FortiToken หรือ Google Authenticator ร่วมกับ FortiGate เพื่อทำ MFA (Multi-Factor Authentication) ซึ่งช่วยป้องกันการสวมรอยได้เกือบ 100%
3. Zero Trust Network Access (ZTNA): อนาคตของการเข้าถึงเครือข่าย
นี่คือหัวใจของ FortiOS 7.6 ZTNA ไม่ใช่แค่ VPN ที่ดีขึ้น แต่มันคือการเปลี่ยนวิธีคิด (Paradigm Shift) จากการให้สิทธิ์เข้า “วงเครือข่าย” มาเป็นการให้สิทธิ์เข้า “แอปพลิเคชัน”
3.1 ความต่างระหว่าง VPN และ ZTNA
- VPN: เหมือนการให้กุญแจหน้าบ้าน เมื่อไขเข้ามาได้ User จะเห็นอุปกรณ์ทุกอย่างในบ้าน (Full Network Access)
- ZTNA: เหมือนระบบคีย์การ์ดในโรงแรม User จะเข้าได้เฉพาะ “ห้อง” (App) ที่ระบุไว้ในบัตรเท่านั้น และระบบจะตรวจสอบ “บัตร” ตลอดเวลาที่ใช้งาน (Continuous Verification)
3.2 ZTNA Tags & Posture Check: การตรวจสอบสุขภาพอุปกรณ์
ผมชอบฟีเจอร์นี้มากครับ คือการที่ FortiGate ร่วมมือกับ FortiClient EMS ตรวจสอบ “ท่าทาง” (Posture) ของเครื่องก่อนให้เข้า
- เครื่องติดไวรัสไหม? (ถ้าติด ตัดการเชื่อมต่อทันที)
- เปิด Antivirus หรือยัง?
- เป็นเครื่องของบริษัทจริงไหม? (Check Certificate/Domain Join)
- เครื่องอยู่ที่ไหน? (Geo-location)
4. ZTNA Architecture: เบื้องหลังการทำงาน (The Reverse Proxy)
การทำ ZTNA บน FortiGate ใช้หลักการของ Access Proxy (Reverse Proxy)
- User Request: ผู้ใช้เรียกหาแอป (เช่น internal-hr.company.com)
- Identity Verification: FortiGate ตรวจสอบตัวตนผ่าน SAML (Azure AD, Okta)
- Posture Check: ตรวจสอบ Tag จาก FortiClient ว่าเครื่องปลอดภัยไหม
- Encrypted Tunnel: หากผ่านเงื่อนไข ระบบจะสร้างอุโมงค์ HTTPS/TCP เฉพาะแอปนั้นๆ ให้ทันที
5. การเปลี่ยนผ่าน (Transitioning): จาก VPN สู่ ZTNA
การเปลี่ยนผ่านไม่จำเป็นต้องทำในวันเดียว เราสามารถทำแบบ Hybrid ได้
- Legacy Apps: ยังใช้ VPN แบบเดิมสำหรับแอปเก่าๆ ที่ซับซ้อน
- Web/Cloud Apps: เริ่มใช้ ZTNA เพื่อความคล่องตัวและปลอดภัยกว่า
- Seamless Experience: User ไม่รู้สึกถึงความต่าง เพราะ FortiClient จะเป็นคนจัดการการเชื่อมต่อเบื้องหลังให้เองแบบอัตโนมัติ
6. Advanced Monitoring: การติดตามระดับบุคคลและระดับ Session
วิศวกรยุค ZTNA ต้องดู Log ให้เป็น:
- ZTNA Monitor: ดูว่าตอนนี้มีใครกำลังใช้แอปไหนบ้าง และเครื่องที่ต่อเข้ามามี Posture อย่างไร (สีเขียวคือปลอดภัย สีแดงคือมีความเสี่ยง)
- Posture Change Logs: หากพนักงานแอบปิด Firewall ในเครื่อง ระบบ ZTNA จะบันทึก Log และตัด Session ทันที ซึ่งเราสามารถนำมาใช้ทำ Report ด้าน Compliance ได้
7. บทสรุป: เมื่อความปลอดภัยเริ่มต้นที่ “ความไม่ไว้วางใจ”
การตั้งค่า Identity และ ZTNA คือการยกระดับองค์กรเข้าสู่มาตรฐานความปลอดภัยระดับสากลครับ ธุรกิจยุคใหม่ที่ต้องการความคล่องตัว (Agility) แต่ยังคงความปลอดภัยสูงสุด ต้องมองข้ามเรื่องการ Block IP ไปสู่การจัดการ “สิทธิ์รายบุคคลและรายแอปพลิเคชัน”
ในบทความถัดไป (บทที่ 8) เราจะกลับไปทบทวนและเจาะลึกเรื่อง Virtual Private Networks (VPN) ในระดับ Advance กันครับ เพื่อดูว่าในวันที่ ZTNA กำลังเติบโต VPN ยังมีความจำเป็นอย่างไร และการเซ็ต IPsec/SSL VPN ให้มีความปลอดภัยสูงสุดตามมาตรฐาน NIST ทำได้อย่างไรบ้างครับ
💡 เกร็ดความรู้
- SAML Integration: การเชื่อมต่อ FortiGate กับ Cloud Identity อย่าง Azure AD จะช่วยให้พนักงานทำ Single Sign-On (SSO) ได้ คือ Login ครั้งเดียวเข้าได้ทุกอย่างทั้งในและนอกบริษัท
- Zero Trust Tagging: เราสามารถสร้างกฎได้ว่า “พนักงานฝ่ายการเงินที่ใช้ Windows 7 ห้ามเข้าถึงระบบโอนเงิน” เพื่อลดความเสี่ยงจากระบบปฏิบัติการที่ล้าสมัยครับ
สำหรับบทความที่ 8 นี้ เราจะกลับมาเจาะลึกเทคโนโลยีที่เป็น “กระดูกสันหลัง” ของการเชื่อมต่อระหว่างสาขาและการทำงานจากภายนอกมาอย่างยาวนาน นั่นคือ Virtual Private Networks (VPN) แม้ว่าในบทก่อนเราจะพูดถึง ZTNA ที่เป็นอนาคต แต่ในโลกความเป็นจริงของวิศวกรเครือข่าย IPsec และ SSL VPN ยังคงเป็นเครื่องมือมาตรฐานที่ขาดไม่ได้ โดยเฉพาะในการเชื่อมต่อระดับโครงสร้างพื้นฐาน (Infrastructure-to-Infrastructure)