Athena SASE Quick Start: ตั้งค่า ZTNA, SWG และ Data Loss Analysis ตั้งแต่เริ่มต้นจนใช้งานได้ (พร้อมวิดีโอ)

บทความนี้พาตั้งค่า Sangfor Athena SASE ตั้งแต่เริ่มต้นจนใช้งานได้จริงในบทความเดียว ครอบคลุม 3 โมดูลหลัก ได้แก่ ZTNA ให้ผู้ใช้เข้าถึง Application ภายในได้โดยไม่ต้องใช้ VPN, SWG ควบคุมการใช้เว็บ ป้องกันภัยจากอินเทอร์เน็ต และมองเห็นการใช้งาน GenAI และ Data Loss Analysis ควบคุมการส่งข้อมูลสำคัญออกจากเครื่องผู้ใช้ในระดับพื้นฐาน ทั้งหมดใช้ Omnipoint Secure Client ตัวเดียวบนเครื่องผู้ใช้ และจัดการจาก Console เดียว เหมาะสำหรับผู้ดูแลระบบที่เริ่มใช้งาน Athena SASE หรือต้องการเห็นลำดับการตั้งค่าทั้งระบบก่อนลงรายละเอียดในบทความของแต่ละหัวข้อ

วิดีโอ Quick Start

ขั้นตอนทั้งหมดในบทความนี้มีวิดีโอสาธิตการตั้งค่าตั้งแต่ต้นจนจบให้ดูประกอบ

• หากวิดีโอไม่แสดง ดูได้ที่ YouTube: https://youtu.be/HBYGqTl75Sw
• ต้องการเรียนรู้แต่ละโมดูลอย่างละเอียด ดู Playlist Athena SASE แบบเต็ม: https://youtube.com/playlist?list=PLDaKNfTVAFfY

ภาพรวมการทำงาน

Athena SASE ย้ายจุดตรวจความปลอดภัยไปไว้บน Cloud เครื่องที่ติดตั้ง Client ทุกเครื่องจึงใช้ Policy ชุดเดียวกัน ไม่ว่าผู้ใช้จะทำงานจากสำนักงาน สาขา หรือนอกสถานที่

• ZTNA ให้ผู้ใช้เข้าถึงเฉพาะ Application ภายในที่ได้รับสิทธิ์ แทนการเปิดให้เข้าถึงทั้ง Network แบบ VPN
• SWG ตรวจและควบคุมการใช้อินเทอร์เน็ตของทุกเครื่อง พร้อม Threat Protection เช่น Antivirus และ IPS
• Data Loss Analysis กำหนดว่าไฟล์และข้อความแบบใดส่งออกจากเครื่องได้ และส่งผ่านช่องทางใดได้

เส้นทางของ Traffic เป็นดังนี้

• Client เชื่อมต่อกับ PoP (Point of Presence) ซึ่งเป็นจุดให้บริการบน Cloud ของ Sangfor หลังผู้ใช้ Login ระบบจะส่งรายชื่อ PoP ที่เปิดใช้งานให้กับองค์กรลงมาที่ Client จากนั้น Client วัด Latency และ Packet Loss ไปยังแต่ละ PoP แล้วเชื่อมต่อกับ PoP ที่ดีที่สุดให้อัตโนมัติ
• Athena SASE มี PoP ในประเทศไทย ซึ่งใช้งานได้เมื่อเปิดใช้งานให้กับองค์กรแล้ว
• สำหรับ ZTNA นั้น PoP จะตรวจสิทธิ์และความปลอดภัยของเครื่อง (Zero Trust Policy Check) ก่อน แล้วจึงส่งต่อไปยัง App Connector ใน Data Center
• App Connector เป็นฝ่ายสร้าง Encrypted Tunnel ออกไปหา PoP เอง จึงไม่ต้องเปิด Port หรือทำ Port Mapping จากอินเทอร์เน็ตเข้ามายัง Network ภายใน

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

รายการ	รายละเอียด
Account ของ Platform-X	Account ขององค์กรที่ Activate Subscription ของ Athena SASE แล้ว
เครื่อง Linux ใน Data Center	สำหรับติดตั้ง Identity Connector และ App Connector (ติดตั้งทั้งสองตัวบนเครื่องเดียวกันได้) • Identity Connector: หน้าติดตั้งแนะนำ 4 Core / RAM 8 GB (ขั้นต่ำ 2 Core / 4 GB) CentOS 7 หรือ Ubuntu 16 ขึ้นไป แบบ x86_64 • App Connector: 4 Core / RAM 8 GB ขึ้นไป บนเครื่องที่ติดตั้ง OS ใหม่ ไม่มีโปรแกรมอื่นที่อาจรบกวน Network • ออกอินเทอร์เน็ตได้ และเข้าถึง Domain Controller กับ Server ภายในได้ • ตั้ง DNS ของเครื่องให้ชี้ไปที่ DNS Server ภายใน เพื่อให้ Connector Resolve ชื่อ Server ภายในได้
ข้อมูล Active Directory	IP ของ Domain Controller, Base DN และ Service Account สำหรับอ่านข้อมูล (แนะนำให้สร้าง Service Account แยกไว้สำหรับงานนี้โดยเฉพาะ)
เครื่องผู้ใช้	Windows 7 SP1, Windows 10, Windows 11 หรือ macOS 10.15 ขึ้นไป และ Account ที่มีสิทธิ์ Administrator สำหรับติดตั้ง Client
Firewall ขาออก	ถ้า Firewall ขององค์กรควบคุม Outbound ด้วย Policy ต้องอนุญาตปลายทางตาม Service Address List (ดูหัวข้อ เข้า Console และเตรียม Network)

ตัวอย่างในบทความนี้: เครื่องผู้ใช้อยู่นอกองค์กร ออกได้เฉพาะอินเทอร์เน็ตและไม่มี Route เข้า Data Center ส่วน Data Center มี Domain Controller เครื่อง Connector และ Web Server ภายในที่จะ Publish ส่วนใน AD มีผู้ใช้ 2 Group คือ Group พนักงาน และ Group ทีม IT ซึ่งได้รับสิทธิ์ต่างกัน

เข้า Console และเตรียม Network

เข้า Console

1. Login เข้า Platform-X ที่ https://x.sangfor.com แล้วกรอกรหัสยืนยันที่ได้รับทางอีเมลหรือ SMS
2. ที่หน้า Security Products หาการ์ด Athena SASE แล้วคลิก Visit Console จะเปิดที่หน้า Dashboard › Home (ชื่อ Sangfor Access Secure ด้านบนคือ Console ของ Athena SASE)

เมนูด้านซ้าย	ใช้ทำอะไร
Dashboard, Logs	ดูสถานะ ผู้ใช้ที่ออนไลน์ และผลการทำงานของ Policy
Core Features › Zero Trust Security	ZTNA
Core Features › Data Loss Analysis	Data Loss Analysis (DLP) และ AI App Analysis
Core Features › Secure Web Gateway	SWG รวมถึง Threat Protection เช่น Antivirus และ IPS
Core Features › Global Acceleration	เร่งการเชื่อมต่อข้ามประเทศ (Subscription แยก ไม่ได้ใช้ในบทความนี้)
Platform Management	Identity Management, Endpoints, Objects และ System

ตรวจ Subscription

1. ไปที่ Platform Management › System › Licensing › Subscriptions แท็บ My Subscriptions แต่ละการ์ดแสดงจำนวน User License ที่ใช้ไปเทียบกับทั้งหมด และวันหมดอายุ

   

2. ตรวจว่ามี Subscription ครบตามโมดูลที่จะใช้ และจำนวน License พอสำหรับผู้ใช้ที่วางแผนไว้

Subscription	ใช้กับ
Zero Trust Guard	ZTNA
Secure Web Gateway	SWG
Zero Trust Data Protection	Data Loss Analysis

การ์ดอื่นเป็นบริการเสริมตามที่องค์กรสั่งซื้อ ควรตรวจหน้านี้ก่อนดาวน์โหลด Client เพราะ Standard Package ของ Client จะรวม Component ตาม Subscription ที่องค์กรมี

เตรียม Firewall ขาออกตาม Service Address List

1. ไปที่ Platform Management › System › General Settings › Service Address List ถ้าองค์กรไม่มี Firewall หรือ Firewall ไม่ได้ควบคุมการเข้าถึง Application ขาออกด้วย Policy หน้านี้แจ้งว่าไม่ต้องดำเนินการเพิ่ม

   

2. ถ้า Firewall ขององค์กรควบคุม Outbound ด้วย Policy ให้คลิก View Addresses ระบบจะขอรหัสยืนยันทาง SMS ที่ส่งไปยังหมายเลขโทรศัพท์ของผู้ดูแลระบบก่อน รายการที่แสดงมี Domain, IP และ Port แยกตามประเภทของ Cloud Service และ Export ออกไปได้
3. อนุญาตปลายทางเหล่านี้ที่ Firewall ทั้งสำหรับเครื่องผู้ใช้และเครื่อง Connector

เชื่อมผู้ใช้จาก Active Directory

ใช้ผู้ใช้จาก Active Directory (AD) ขององค์กรโดยตรง ผู้ใช้ Login ด้วย Account เดิม และผู้ดูแลระบบไม่ต้องสร้างผู้ใช้ซ้ำอีกชุด Athena SASE เชื่อมกับ AD ภายในองค์กรผ่าน Identity Connector ซึ่งติดตั้งบนเครื่อง Linux ที่เข้าถึง AD ได้ การเชื่อม AD ต้องตั้งค่าทั้ง 2 ส่วน

ส่วนประกอบ	หน้าที่
User Source	ดึงผู้ใช้ OU และ Group จาก AD มาใช้กำหนด Policy
Auth Source	ตรวจรหัสผ่านตอนผู้ใช้ Login

ติดตั้ง Identity Connector

1. ไปที่ Platform Management › Identity Management › User Management คลิก Manage User Sources แล้วเลือก Manage Identity Connectors หน้านี้แสดงขั้นตอนติดตั้งและ Spec ของเครื่องที่ต้องเตรียม เครื่อง Connector ต้องเชื่อมต่อขาออกไปยังปลายทางที่หน้านี้ระบุได้
2. คลิก Add ตั้งชื่อ Connector แล้วคลิก OK ระบบจะดาวน์โหลดไฟล์ติดตั้งให้ทันที และการ์ดของ Connector ใหม่จะขึ้นมารอการติดตั้ง

3. คัดลอกไฟล์ติดตั้งไปไว้บนเครื่อง Linux (เช่น ผ่าน SCP หรือ SFTP) แตกไฟล์ แล้วรันตัวติดตั้งด้วยสิทธิ์ sudo

   tar -zxvf <ชื่อไฟล์ Package>.tar.gz
   cd agent
   sudo ./install.sh install

   บน Ubuntu การรันครั้งแรกจะตรวจ Environment และเปลี่ยน /bin/sh เป็น bash แล้วแจ้งให้รันคำสั่งเดิมอีกครั้ง ให้รัน sudo ./install.sh install ซ้ำจนขึ้นข้อความ install agent success. จากนั้น Connector จะลงทะเบียนกับ Platform ให้อัตโนมัติ

4. ตรวจสถานะของ Service ต้องเห็น active (running)

   systemctl status idaas-agent

5. กลับมาที่ Console คลิก Refresh การ์ดจะแสดง IP ของเครื่อง พร้อมจุดสถานะสีเขียว

   

High Availability: ติดตั้งไฟล์เดียวกันบนเครื่องที่สอง ระบบจะรวมเป็น Cluster ให้อัตโนมัติ รองรับได้สูงสุด 5 Instance

Sync ผู้ใช้จาก AD (User Source)

1. กลับไปที่ Manage User Sources คลิก Add User Source แล้วเลือก Microsoft AD (เลือกได้หลังจากมี Identity Connector แล้ว) ถ้าองค์กรใช้ Microsoft Entra ID ให้เลือก Azure Active Directory เพื่อ Sync ผู้ใช้จาก Cloud แทน

2. กรอกค่าตามตารางนี้

   ช่อง	ค่าที่กรอก
   Name	ชื่อ User Source ที่จำง่าย
   Connector	Identity Connector ที่เพิ่งติดตั้ง
   Server Address	IP ของ Domain Controller
   Encryption Method	SSL (ระบบเปลี่ยน Server Port เป็น 636 ให้)
   Bind Method	Admin แล้วกรอก Service Account ในรูปแบบ Domain\Username พร้อมรหัสผ่าน
   Base DN	OU ที่เก็บผู้ใช้ที่จะใช้งาน Athena SASE เช่น OU=Staff,DC=lab,DC=local
   User Group	Enable เพื่อดึง Security Group จาก AD มาด้วย (ใช้กำหนดสิทธิ์ในส่วน ZTNA)
   Account Mapping	จับคู่ sAMAccountName ของ AD เป็น Username บน Athena SASE
   Sync to Department	Department ที่จะรับผู้ใช้
   Sync Schedule	ในฟอร์มตั้งไว้ทุก 1 ชั่วโมง ปรับได้ตั้งแต่ 10 นาทีถึง 7 วัน

   

3. คลิก Test เพื่อตรวจการเชื่อมต่อกับ AD ก่อนบันทึก
4. คลิก OK ระบบจะเปิดใช้ User Source และถามว่าจะ Sync ทันทีหรือไม่ คลิก OK เพื่อดึงข้อมูลครั้งแรก

5. เมื่อ Sync เสร็จ โครงสร้าง OU และผู้ใช้จาก AD จะขึ้นใต้ Department ที่เลือกไว้ และแท็บ User Group จะแสดง Security Group ที่ดึงมาจาก AD

   

ตั้ง Auth Source และ Authentication Policy

1. ไปที่ Identity Management › Authentication Policies แท็บ Mobile Users เลือก PC (Client Access) ซึ่งเป็น Policy ของ Client บนคอมพิวเตอร์ และมีได้ชุดเดียว
2. คลิก Manage Auth Sources › Add Auth Source เลือก Microsoft AD แล้วตั้งชื่อ (ถ้าองค์กรใช้ Identity Provider อื่น เพิ่ม Auth Source แบบ SAML หรือ OIDC ได้จากหน้านี้)
3. เลือก Connector และกรอกข้อมูล Server ชุดเดียวกับ User Source พร้อม Service Account ตรวจว่า Username Attribute เป็น sAMAccountName ซึ่งฟอร์มกรอกไว้ให้แล้ว ผู้ใช้จึง Login ด้วย Username เดียวกับที่ใช้เข้า Windows
4. คลิก Test แล้วกรอก Username และรหัสผ่านของผู้ใช้ใน AD เพื่อทดสอบการ Login จากนั้นคลิก OK และคลิก OK อีกครั้งเมื่อระบบถามว่าจะเปิดใช้งาน (Enable) หรือไม่

5. กลับมาที่หน้า Policy คลิก Edit (มุมซ้ายล่าง) ที่ Auth Method ติ๊ก Microsoft AD ที่เพิ่งสร้าง แล้วคลิก Save วิธีอื่นที่เลือกไว้แล้วยังคงใช้ได้ ผู้ใช้เลือกวิธีที่ต้องการได้ที่หน้า Login

   

• ถ้าต้องการให้ผู้ใช้เปลี่ยนรหัสผ่าน AD ผ่านระบบ ต้องใช้ Encryption Method แบบ SSL หรือ TLS และเปิด Password Permissions ใน Auth Source ด้วย
• เพิ่ม Multi-Factor Authentication ได้ที่ Identity Management › Authentication Settings แท็บ Multi-Factor Authentication รองรับ TOTP, FIDO2, Email Address และ SMS

อ่านรายละเอียดเพิ่มเติม: การ Sync ผู้ใช้จาก Microsoft AD ภายในองค์กร · การตั้งค่า Auth Source แบบ Microsoft AD · การตั้งค่า Multi-Factor Authentication (MFA)

ติดตั้ง Omnipoint Secure Client

ติดตั้ง Omnipoint Secure Client เพียงตัวเดียวก็ใช้งานได้ครบทั้ง ZTNA, SWG และ Data Loss Analysis

ดาวน์โหลด Package

1. ไปที่ Platform Management › Endpoints › Client Deployment แท็บ Deployment Guide เลือก First Installation สำหรับเครื่องที่ยังไม่มี Client ของ Sangfor

   

   วิธีติดตั้ง	เหมาะกับ
   Webpage	ส่งลิงก์ให้ผู้ใช้ดาวน์โหลดและติดตั้งเอง
   Installation Package	แจกไฟล์ติดตั้งให้ผู้ใช้ เช่น ผ่าน Shared Folder
   Silent Installation โดยผู้ดูแลระบบ	เครื่องจำนวนมาก ติดตั้งผ่าน Microsoft AD หรือซอฟต์แวร์ Desktop Management

2. ไปที่แท็บ Download Center Standard Package สร้างจาก Subscription ขององค์กร ในตัวอย่างมี Component ครบ 3 ตัว คือ Secure Web Gateway, Zero Trust Network Access และ Extended Data Loss Analysis
3. Package Type มี 2 แบบ
   • Full-Featured รวมทุก Component ไว้ในไฟล์เดียว เหมาะกับการติดตั้งแบบ Offline หรือติดตั้งจำนวนมาก
   • Lightweight ไฟล์ขนาดเล็ก แล้วดึง Component จาก Cloud ภายหลัง เหมาะกับองค์กรที่มีหลายสาขาหรือหลายประเทศ

4. ที่ Method เลือก Package เลือกระบบปฏิบัติการ (Windows หรือ macOS) แล้วคลิก Download Package

   

ติดตั้งและ Login

1. ที่เครื่องผู้ใช้ ดับเบิลคลิกไฟล์ติดตั้ง ยืนยันสิทธิ์ Administrator ติ๊กยอมรับ EULA แล้วคลิก Install Now
2. เมื่อติดตั้งเสร็จ คลิก Close หน้าต่าง Client จะเปิดขึ้นมา คลิก Log In แล้ว Client จะเปิดหน้า Login ใน Browser (ถ้า Policy เปิดไว้หลายวิธี ผู้ใช้เลือกวิธีที่ต้องการได้จาก More Login Options)
3. กรอก Username และรหัสผ่านของ AD ติ๊กยอมรับ Terms of Use แล้วคลิก Log In

4. หน้าต่าง Client จะแสดง Office Network Connected และ Internet Access Protected ส่วนไอคอนผู้ใช้แสดง Account ที่ Login อยู่

   

ตรวจสอบฝั่ง Console

• Dashboard › User Status แท็บ Desktop App Users แสดงผู้ใช้ที่ออนไลน์ ผู้ดูแลระบบดูรายละเอียด หรือสั่ง Log out user ได้จากหน้านี้

• Platform Management › Endpoints › Endpoint Assets เครื่องที่เพิ่ง Login มีสถานะ Online และ Authenticated คอลัมน์ Client Component Status แสดง ZTNA, SWG และ XDLA (Data Loss Analysis) ที่ติดตั้งบนเครื่อง

  

อ่านรายละเอียดเพิ่มเติม: Deployment Guide: เลือกวิธีติดตั้ง Omnipoint Secure Client · การติดตั้ง Client ผ่าน Group Policy ของ AD · ข้อกำหนดระบบและการตรวจสอบสภาพแวดล้อมก่อนติดตั้ง Client

ZTNA: เข้าถึง App ภายในโดยไม่ต้องใช้ VPN

VPN แบบเดิมเปิดให้เข้าถึงได้ทั้ง Network แต่ ZTNA ให้ผู้ใช้เข้าได้เฉพาะ App ที่ได้รับสิทธิ์เท่านั้น

ติดตั้ง App Connector

1. ไปที่ Core Features › Zero Trust Security › Policies › Connectors แผนภาพด้านบนสรุปการทำงาน: Traffic จากเครื่องผู้ใช้วิ่งเข้า PoP ซึ่งตรวจสิทธิ์และความปลอดภัยของเครื่อง แล้วจึงส่งต่อให้ App Connector ใน Data Center
2. แท็บ Connector Apps คลิก Add Connector กรอกชื่อ Connector แล้วคลิก Add ด้านล่างเพื่อสร้าง

3. ที่ Select Environment เลือก Linux ซึ่งระบบแนะนำ (ควรติดตั้งบนเครื่องที่ติดตั้ง OS ใหม่ ไม่มีโปรแกรมอื่นที่อาจรบกวน Network ของ Connector) แล้วคลิก Download Package หน้านี้มีคำสั่งติดตั้งครบทุกขั้น

   

4. คลิก Finish Connector จะมีสถานะ Down และรอการติดตั้ง

5. ที่เครื่อง Linux แตกไฟล์โดยไม่เปลี่ยนชื่อไฟล์ Package แล้วติดตั้งและตรวจสถานะ ต้องเห็น active (running)

   tar -xf <ชื่อไฟล์ Package>
   cd target
   sudo ./install.sh
   systemctl status connector

6. กลับมาที่ Console คลิก Refresh สถานะจะเปลี่ยนเป็น Up แถวของ Instance แสดง OS, DNS ที่เครื่องใช้ และเวลา Heartbeat ล่าสุด

   

• ช่อง DNS ของ Instance ต้องเป็น DNS Server ภายใน เพราะ Connector ใช้ DNS นี้ Resolve ชื่อ Server ให้ผู้ใช้ บน Ubuntu ถ้าช่องนี้แสดง 127.0.0.53 ให้ชี้ไฟล์ /etc/resolv.conf ไปที่ /run/systemd/resolve/resolv.conf แล้ว Restart Service ของ Connector
• สำหรับระบบใช้งานจริง ให้ติดตั้ง Package เดียวกันบนอีกเครื่อง Connector จะทำงานแบบ Active-Active
• แท็บ Connector Groups ใช้ทำ Active-Standby ข้าม Data Center ถ้า Connector หลักมีปัญหา ตัวสำรองจะรับงานแทน หนึ่ง Group รวมได้สูงสุด 8 Connector และเลือกตัวที่ใช้งานตามลำดับ Priority

Publish เว็บภายใน

เพิ่ม App ได้ทั้งด้วย IP และ Domain และควรเปิดเฉพาะ Port ที่จำเป็น เพื่อลดช่องทางการโจมตี

1. ไปที่ Zero Trust Security › Policies › Apps แท็บ App List สร้าง App Group ก่อน โดยคลิกเครื่องหมาย + ที่ App Groups ตั้งชื่อ แล้วคลิก OK (ตัวอย่างสร้าง 2 Group คือ App ของพนักงาน และ App ของทีม IT) App Group จะเป็นหมวดหมู่ของ App ใน Workspace ของผู้ใช้ และใช้ให้สิทธิ์ทั้ง Group ได้ในครั้งเดียว

2. คลิก Add ระบบเปิดฟอร์ม Add Internal App ซึ่งใช้ได้กับทุก Protocol โดยผู้ใช้เข้าใช้งานผ่าน Client กรอกค่าตามตารางนี้

   ช่อง	ค่าที่กรอก
   App Name / App Category	ชื่อ App และ App Group ที่สร้างไว้
   App Address › Protocol	TCP, UDP, ICMP หรือ ALL (เว็บเลือก TCP)
   App Address › Server Address	TCP: IP, ช่วง IP, Subnet, Domain หรือ Wildcard Domain (*.domain.com) UDP, ICMP และ ALL: IP, ช่วง IP หรือ Subnet
   App Address › Port	Port เดียว หลาย Port หรือเป็นช่วง (เว็บในตัวอย่างใช้ 80) App หนึ่งตัวกรอก Address ได้สูงสุด 32 รายการ
   Exclude specified addresses	เปิดใช้เมื่อกรอกเป็นช่วง IP หรือ Subnet แล้วมีบางเครื่องที่ไม่ต้องการเปิดให้เข้าถึง
   Region	เลือก Default ซึ่งเป็น Region ที่ Console สร้างไว้ ระบบจะใช้ PoP ใน Region ที่เลือกก่อนเมื่อสร้าง Tunnel ไปยัง App
   Connection Method	Connector แล้วเลือกตัวที่ติดตั้งไว้ (ถ้าทำ High Availability แบบ Group ให้เลือก Connector Group)

   

3. แท็บ Personalized: Display Apps to Users เปิดอยู่ App จึงขึ้นใน Workspace ของผู้ใช้ เลือก App Icon ให้จำได้ง่าย ที่ App Launch Method ติ๊ก Windows แล้วเลือก Browser สำหรับ App ที่เปิดบนเว็บ และกรอก Redirected Address เป็น URL ของเว็บภายใน เมื่อผู้ใช้คลิก App ระบบจะเปิด Browser ไปที่ URL นี้ให้

4. ที่หัวข้อ Warning Message for Unauthorized Users ติ๊ก Allow ที่ App Access Request ผู้ใช้ที่ยังไม่มีสิทธิ์จะส่งคำขอใช้ App นี้จาก Client ได้ และผู้ดูแลระบบอนุมัติที่แท็บ App Approval

   

5. คลิก OK App จะขึ้นในรายการ พร้อม Address, Group และ Connector ที่ใช้

กรอกเฉพาะ Protocol และ Port ที่ App ใช้จริง ผู้ใช้จะเข้าถึงได้เฉพาะส่วนนั้น ต่างจาก VPN ที่มักเปิดให้เข้าถึงทั้ง Network

Publish Remote Desktop และ File Share

RDP (เสี่ยงต่อการเดารหัสผ่าน) และ File Share แบบ SMB (เสี่ยงต่อการแพร่กระจายของ Malware) ไม่ควรเปิดสู่อินเทอร์เน็ต ให้ Publish ผ่าน ZTNA แล้วให้สิทธิ์เฉพาะ Group ที่จำเป็น

• Remote Desktop: เลือก App Group ของทีม IT กรอก IP ของ Server และ Port 3389 แล้วเลือก Connector ตัวเดิม ที่ App Launch Method เลือก System Application › Remote Desktop Connection เมื่อผู้ใช้คลิก App ระบบจะเปิด Remote Desktop Connection ให้ แล้วผู้ใช้กรอก IP ของ Server (App แบบ Client/Server ทั่วไปใช้ Specified Program โดยระบุชื่อหรือ Path ของโปรแกรม)

  

• File Share: กรอก Server Address เป็นชื่อ Domain (เช่น files.lab.local) Port 445 และ App Launch Method เลือก System Application › File Explorer

• เมื่อ Publish ด้วย Domain ระบบจะเปิด Enable fake IP ในแท็บ Proxy Settings ให้อัตโนมัติ (ล็อกไว้) Client จะได้ Fake IP แทน IP จริงของ Server จึงไม่เปิดเผย IP ภายใน และรองรับกรณีที่หลาย Domain ใช้ IP เดียวกัน รวมถึงการ Publish แบบ Wildcard Domain

  

ที่ App List คลิกปุ่มเลือกคอลัมน์ แล้วเปิด App Health Status เพื่อดูสถานะของแต่ละ App ตัวนับด้านบนแยกจำนวน App ตามสถานะ Normal, Unhealthy, Down, Probing และ Unknown

ให้สิทธิ์ตาม AD Group

1. App ที่ Publish แล้วจะยังไม่มีผู้ใช้เข้าได้จนกว่าจะได้รับสิทธิ์ ไปที่แท็บ App Authorization
2. ฝั่งซ้ายเลือกแท็บ App Groups เลือก Group ของ App แล้วคลิก Permissions

3. แท็บ User Group คลิก Select ค้นหา Security Group ที่ Sync มาจาก AD เลือกแล้วคลิก OK สิทธิ์นี้ครอบคลุมทุก App ใน Group

   

4. ทำแบบเดียวกันกับ App Group อื่น เช่น App ของทีม IT ให้สิทธิ์กับ Security Group ของทีม IT

เมื่อใช้ Group จาก AD การเพิ่มหรือย้ายพนักงานทำที่ AD ที่เดียว สิทธิ์จะปรับตามหลังการ Sync รอบถัดไป

ให้ผู้ใช้เรียก Server ภายในด้วยชื่อ (User Policy)

1. ไปที่ Zero Trust Security › Policies › Advanced Settings แท็บ User Policies (Policy ที่ผูกกับผู้ใช้จะมีผลก่อน Policy ของ Department ที่อยู่เหนือขึ้นไป ถ้าไม่มีเลยระบบจะใช้ Default policy)
2. คลิก Add ตั้งชื่อ ช่อง Objects เลือกได้ทั้งผู้ใช้และ Department (ตัวอย่างเลือก Department ที่ผู้ใช้อยู่โดยตรง)
3. แท็บ Account Settings กำหนดเวลา Logout อัตโนมัติเมื่อไม่มีการใช้งาน App ตามนโยบายความปลอดภัยขององค์กร
4. แท็บ Access Settings เปิด Internal DNS Resolution กรอก Domain ภายในแบบ Wildcard (เช่น *.lab.local) แล้วเลือก Connector ตัวเดียวกับที่ใช้ Publish App ระบบจะแสดง DNS Server ที่ตั้งไว้บนเครื่อง Connector

5. เปิด Append DNS suffix กรอก Domain (เช่น lab.local) ผู้ใช้พิมพ์แค่ชื่อสั้นใน Browser ก็เข้าได้ แล้วคลิก Save

   

ผู้ใช้ที่ Login แล้วจะ Resolve ชื่อภายในผ่าน Connector ด้วย DNS Server ตัวนี้ DNS ภายในจึงไม่ต้องเปิดออกสู่อินเทอร์เน็ต

ทดสอบที่เครื่องผู้ใช้

• ก่อน Login Client: เปิดเว็บภายในด้วยชื่อจะ Resolve ชื่อไม่ได้ และเรียกด้วย IP ก็เชื่อมต่อไม่ได้ เพราะเครื่องอยู่นอกองค์กรและไม่มี Route เข้า Data Center

• Login ด้วยผู้ใช้ใน Group พนักงาน: แท็บ Work (Workspace) แสดงหมวดของพนักงาน มีทั้งเว็บภายในและ File Share แต่ไม่มี Remote Desktop

  

• คลิก App ของเว็บภายใน Browser จะเปิดหน้าเว็บทันที Server ภายในเห็น Request มาจาก IP ของ Connector ไม่ได้เชื่อมต่อกับเครื่องผู้ใช้โดยตรง และพิมพ์แค่ชื่อสั้นก็เข้าได้เพราะเปิด Append DNS suffix ไว้
• คลิก File Share ระบบเปิด File Explorer ให้พิมพ์ชื่อ Share บน Server ภายในได้เลย (เครื่องที่ไม่ได้ Join Domain จะถาม Username และรหัสผ่าน AD ในครั้งแรก)
• ผู้ใช้ Group พนักงานเชื่อมต่อ Remote Desktop ไปที่ Server ไม่ได้ เพราะไม่ได้รับสิทธิ์ App นี้ (หลัก Least Privilege: ผู้ใช้เห็นเฉพาะ App ที่จำเป็นต่องาน) ส่วนผู้ใช้ Group ทีม IT จะเห็นครบทุก App รวมถึง Remote Desktop

ขอสิทธิ์ผ่าน App Access Request

ผู้ใช้ที่ยังไม่อยู่ใน Group ที่ได้รับสิทธิ์จะยังไม่มี App ใน Workspace แต่ขอสิทธิ์เองได้

1. ที่ Client คลิกเมนูมุมซ้ายล่าง เลือก App Access Request เลือก App ที่ต้องการ กำหนดระยะเวลา เลือกเหตุผล และกรอกรายละเอียดสั้น ๆ แล้วคลิก OK

   

2. ฝั่งผู้ดูแลระบบ ไปที่แท็บ App Approval ที่ Pending จะเห็นคำขอพร้อม App และเหตุผล เลือกคำขอแล้วคลิก Approve

   

3. ที่เครื่องผู้ใช้ คลิก Refresh ใน Workspace ก็เห็น App ที่ได้รับอนุมัติทันทีโดยไม่ต้อง Login ใหม่ และใช้ได้ตามช่วงเวลาที่อนุมัติเท่านั้น

ตรวจสภาพเครื่อง (App Protection Policy)

นอกจากตัวตนของผู้ใช้ ZTNA ยังตรวจสภาพของเครื่องตลอดการใช้งานได้ด้วย

1. ไปที่ Zero Trust Security › Policies › Security Policies แท็บ Access Policies ใช้ควบคุมการ Login ของผู้ใช้ ส่วนแท็บ App Protection Policies ใช้ควบคุมการเข้าแต่ละ App คลิก Add แล้วตั้งชื่อ Policy
2. ที่ Applicable Scope เลือกผู้ใช้ และเลือก App ที่ต้องการป้องกัน

3. ที่ Conditions ฟอร์มติ๊ก Windows ไว้ให้ เพิ่มเงื่อนไข Enable system firewall เท่ากับ True แล้วเลือก Response Method เป็น Allow หมายถึงให้เข้าได้เมื่อผ่านเงื่อนไข และทำตาม Action เมื่อไม่ผ่าน

   

4. ที่ Action เลือก Block Access Only แล้วกรอกข้อความแจ้งผู้ใช้เป็นภาษาไทยที่ช่อง Endpoint Prompt จากนั้นคลิก OK

• OS ที่ไม่ได้ติ๊กในฟอร์ม ระบบจะให้เข้าใช้งานได้ทันที จึงควรติ๊กให้ครบทุก OS ที่ผู้ใช้ใช้งาน
• Policy ใหม่มีผลเมื่อผู้ใช้ Login ครั้งถัดไป ให้ผู้ใช้ Logout แล้ว Login ใหม่ก่อนทดสอบ

ผลลัพธ์: เมื่อปิด Windows Firewall แล้วเปิดเว็บภายใน ระบบ Block การเข้าถึงและแสดงข้อความที่ตั้งไว้ ผู้ใช้จึงรู้ว่าต้องแก้ไขที่ใด เมื่อเปิด Firewall กลับมาก็เข้าใช้งานได้ตามปกติ

Log และ Dashboard ของ ZTNA

• Logs › Critical Feature Logs › ZTNA Logs แท็บ Access Logs แสดงว่าใครเข้า App ใด จากเครื่องใด เมื่อใด และผลเป็นอย่างไร

  

• แท็บ User Logs แสดงการให้สิทธิ์ App และแท็บ User Security Logs แสดงประวัติการ Login ถ้า Login ไม่สำเร็จ Log จะแสดงสาเหตุไว้ด้วย
• ภาพรวมดูได้ที่ Dashboard › Home ทั้งจำนวน App และ Connector ที่ Down
• ระบบเก็บ Log ไว้บน Platform ให้ หากต้องการเก็บระยะยาว ให้ส่งต่อด้วย Syslog Forwarding

อ่านรายละเอียดเพิ่มเติม: การติดตั้ง App Connector บน Linux · การ Publish Internal App · App Protection Policies

SWG: ควบคุมการใช้เว็บ ป้องกันภัย และดูการใช้งาน GenAI

ไม่ว่าผู้ใช้จะอยู่ที่ใด การใช้เว็บและ AI ควรผ่าน Policy เดียวกัน พร้อม Log ที่ตรวจสอบย้อนหลังได้

Traffic Forwarding

• Client ส่ง Traffic ผ่าน Tunnel ไปที่ PoP เพื่อระบุ Application ตรวจ Policy และบันทึก Log
• ใน Mode Intelligent Traffic Forwarding Client จะส่งเฉพาะ Packet แรก ๆ ของการเชื่อมต่อไปตรวจที่ PoP
• ผู้ใช้ที่อยู่ใน SSL Decryption Policy จะส่ง Traffic ทั้งหมดผ่าน PoP และการ Decrypt ทำที่ PoP ไม่ได้ทำบนเครื่องผู้ใช้

1. ไปที่ Platform Management › System › Connections › Traffic Forwarding Policies แท็บ Client Traffic หน้านี้กำหนดว่า Traffic ใดส่งไปตรวจที่ PoP และ Traffic ใดออกอินเทอร์เน็ตโดยตรง

2. คำอธิบายบนหน้านี้ระบุว่ามี Traffic Exclusion Policy สำหรับ App ภายใน (เช่น Printer) ในวง Private IP ได้แก่ 10.0.0.0/8, 172.16.0.0/12 และ 192.168.0.0/16 อยู่แล้ว ถ้า Network ภายในใช้วง IP อื่นด้วย ให้เพิ่มวงนั้นตามที่หน้านี้แนะนำ

   

3. คลิก Advanced ตรวจว่า Forward DNS Traffic เปิดอยู่ (ใช้สำหรับ Audit เนื้อหาเว็บที่ Decrypt และจำเป็นสำหรับการตรวจจับการติดต่อกับ C2 Server) และ IPv6 DNS Resolution Requests ติ๊ก Enable blocking ไว้ เพื่อให้ Traffic ถูก Audit ได้ครบ

SSL Decryption

เว็บส่วนใหญ่เป็น HTTPS การ Decrypt ช่วยให้ระบบ Audit เนื้อหา ควบคุม App ได้ละเอียดขึ้น และสแกนไวรัสในไฟล์ที่ดาวน์โหลดผ่าน HTTPS ได้

1. ไปที่ Core Features › Secure Web Gateway › Policies › SSL Decryption หน้านี้เป็นรายการ Policy ที่ทำงานตามลำดับ Priority จึงกำหนดการ Decrypt แยกตามกลุ่มผู้ใช้ได้
2. คลิก Add ตั้งชื่อ Policy แล้วเลือก Rank (Rank กำหนดว่าผู้ดูแลระบบระดับใดแก้ไข Policy นี้ได้ และใช้เรียงลำดับ Priority ของ Policy ด้วย)
3. ที่ Content ติ๊ก Apps (ตรวจ Traffic บน Port 443) แล้วเลือก All เพื่อ Decrypt ทุกเว็บ
4. Reject data transmitted over QUIC protocol ถูกติ๊กไว้ในฟอร์ม เมื่อ Reject แล้ว Browser จะกลับไปใช้ TCP ซึ่ง PoP ตรวจเนื้อหาได้

5. ที่ Applicable Scope ฟอร์มเลือก All ไว้ ปรับให้ตรงกับกลุ่มผู้ใช้ที่ต้องการ แล้วคลิก OK

   

6. เว็บที่ไม่ต้องการ Decrypt ให้เพิ่มในแท็บ Decryption Whitelist ซึ่งมีรายการ Predefined ให้ด้วย

Client ติดตั้ง Root Certificate บนเครื่องให้ ผู้ใช้จึงไม่เห็นหน้าเตือน Certificate ตรวจสอบได้โดยคลิกรูปกุญแจใน Browser ของเครื่องผู้ใช้ ช่อง Issued By ของเว็บที่ถูก Decrypt จะเป็น CA ของระบบ ไม่ใช่ CA เดิมของเว็บ

URL & App Audit

1. ไปที่ Secure Web Gateway › Policies › URL & App Audit คลิก Add ตั้งชื่อ Policy ช่อง URL/App ฟอร์มเลือก All ไว้ ครอบคลุมทั้งการเข้าเว็บ Web Email, Netdisk, การส่งไฟล์ผ่าน HTTP และอื่น ๆ

   

2. Action เป็น Audit และ Schedule เป็น All Day เลือก Applicable Scope แล้วคลิก OK

3. ดูผลที่ Logs › Critical Feature Logs › SWG Logs

   • แท็บ Secure Web Gateway แสดงว่าใครใช้ App ใด ใน Category อะไร และ Status เป็น Logged (คลิก Details เพื่อดู Domain Name และ Destination IP)
   • แท็บ Web Browsing แสดงชื่อหน้าเว็บและ URL ที่เปิด
   • แท็บ Search Engine แสดงคำค้นหา (เมื่อเปิด SSL Decryption)

   

URL & App Control

ใช้จำกัด App ที่ใช้ Bandwidth สูงหรือไม่เกี่ยวกับงาน ด้วย Policy เดียวที่ใช้ได้ทุกที่

1. ไปที่ Secure Web Gateway › Policies › URL & App Control คลิก Add แล้วตั้งชื่อ Policy
2. คลิกช่อง URL/App หน้าต่างนี้ควบคุมได้ 3 แบบ คือ Apps, Web File และ Emails ติ๊ก Apps แล้วคลิก Select ที่ช่อง App

3. ระบบจัด App ไว้เป็น Tag เช่น SaaS, Security Risk และ High Bandwidth Consumption การคลิก Tag เป็นการกรองรายการ ต้องติ๊กเลือก App หรือทั้งโฟลเดอร์ ส่วน URL Category เช่น Online Shopping อยู่ใต้ Visit Web Site ตัวอย่างนี้ค้นหา YouTube แล้วเลือก YouTube Video จากนั้นคลิก OK

   

4. Action เป็น Reject (ฟอร์มเลือกไว้ให้) และ Schedule เป็น All Day เลือก Applicable Scope แล้วคลิก OK
5. Policy ในรายการเรียงตาม Priority และ Policy ใหม่จะอยู่ลำดับบนสุด เหนือแถว Default Policy ที่ Console แสดงไว้

ผลลัพธ์: ผู้ใช้เปิด YouTube จะขึ้น Block Page แจ้งว่าการเข้าถึงถูกปฏิเสธตาม Policy และใน SWG Logs รายการนี้มี Status เป็น Blocked

• Secure Web Gateway › Analytics › Blocked Activities แสดงผู้ใช้ App ที่ถูก Block และ Policy ที่ Match
• ปรับหัวข้อ ข้อความ และข้อมูลที่แสดงบน Block Page (เช่น Username หรือ URL) ได้ที่ System › General Settings › Page Redirection

ดูการใช้งาน GenAI

พนักงานใช้ AI เพื่อทำงานได้เร็วขึ้น เป้าหมายคือให้ใช้ได้อย่างมั่นใจ โดยเริ่มจากรู้ว่าใครใช้ AI ตัวใด

1. ไปที่ Core Features › Data Loss Analysis › Analytics › Outbound Data แล้วเปิดแท็บ AI App Analysis
2. หน้านี้ใช้ข้อมูลจาก URL & App Audit, Audit Policy ของ Data Loss Analysis และ SSL Decryption จึงต้องเปิดทั้งสามส่วน (ตั้งค่าตามหัวข้อด้านบนและหัวข้อ Data Loss Analysis)

3. เลือก Department จะเห็นจำนวน AI App ที่ใช้ จำนวนครั้งที่เข้าใช้ และประเภทของ AI App แท็บ GenAI Apps แสดง AI แต่ละตัว จำนวนครั้งที่เข้าใช้ ที่ถูก Block และที่อนุญาต ส่วนแท็บ GenAI App Users แสดงว่าผู้ใช้แต่ละคนใช้ AI ตัวใดบ้าง

   

Threat Protection

ไปที่ Secure Web Gateway › Policies › Threat Management แท็บ Threat Protection มี 4 Engine หลัก ตรวจว่า Engine ที่ต้องการเปิดอยู่ (สวิตช์ของแต่ละ Engine มีผลกับทั้งองค์กร)

Engine	หน้าที่
Command and Control (C2) Activity Detection	Block Mode จะ Block การติดต่อกับ C2 Server ตามระดับความรุนแรง ส่วน Monitor Mode บันทึก Log อย่างเดียว
URL Filtering	กำหนด Action ตาม Category ของเว็บ เช่น Block เว็บ Phishing และเว็บอันตราย
Antivirus	ตรวจไฟล์ที่ดาวน์โหลดผ่าน HTTP และ HTTPS (การตรวจไฟล์ใน HTTPS ต้องเปิด SSL Decryption สำหรับเว็บนั้น)
IPS	ตรวจจับการโจมตีช่องโหว่ของระบบ

ทุก Engine ทำงานบน PoP ผู้ใช้จึงได้รับการป้องกันด้วย Policy เดียวกันไม่ว่าจะเชื่อมต่อจากที่ใด

1. ทดสอบ: ดาวน์โหลดไฟล์ทดสอบ EICAR ซึ่งเป็นไฟล์มาตรฐานสำหรับทดสอบ Antivirus การดาวน์โหลดจะถูก Block และ Browser แสดงหน้าแจ้งว่าไฟล์นี้อาจติดไวรัส

   

2. ดู Log ที่ Logs › Critical Feature Logs › Threat Protection Logs แท็บ Security Logs เลือก Log Type เป็น Antivirus แล้วเปิด Details จะเห็นผู้ใช้ ชื่อไฟล์ ชื่อไวรัส และ Action เป็น Reject

   

อ่านรายละเอียดเพิ่มเติม: SSL Decryption · URL & App Control Policy · Threat Protection: Antivirus และ IPS Policy

Data Loss Analysis: ควบคุมการส่งข้อมูลสำคัญ

Data Loss Analysis เป็นการควบคุมการรั่วไหลของข้อมูลขั้นพื้นฐานที่มาพร้อมกับ Client และ Console เดียวกัน ทำงานบนเครื่องผู้ใช้ผ่าน Component XDLA ใน Client ตัวเดิม ใช้กำหนดว่าไฟล์และข้อความที่มี Sensitive Data ส่งออกผ่านช่องทางใดได้ เช่น Browser และ Application ตัวอย่างในหัวข้อนี้ใช้เลขบัตรประชาชนไทยเป็นข้อมูลสำคัญ

กำหนดข้อมูลสำคัญ: เลขบัตรประชาชนไทย

1. ไปที่ Data Loss Analysis › Policies › Sensitive Object Definition แล้วคลิก DLA Dictionaries ซึ่งเก็บรูปแบบของข้อมูลด้วย Keyword หรือ Regular Expression ระบบมี Predefined Dictionary ของหลายประเทศ ส่วนเลขบัตรประชาชนไทยสร้างเองได้ด้วย Regular Expression
2. คลิกเครื่องหมาย + ที่ Groups เพื่อสร้าง Group แล้วคลิก Add

3. ตั้งชื่อ เลือก Sensitivity Level เป็น L4 (Top Secret) Matching Method เลือก Regular Expression แล้วกรอกรูปแบบเลขบัตรประชาชน 13 หลัก ซึ่งรองรับทั้งแบบมีขีด มีช่องว่าง และตัวเลขที่เขียนติดกัน

   \b\d[- ]?\d{4}[- ]?\d{5}[- ]?\d{2}[- ]?\d\b

4. ที่ Validity Check กรอกเลขตัวอย่าง (เช่น 1-0000-00001-01-3) แล้วคลิก Test เพื่อตรวจว่ารูปแบบถูกต้อง

   

5. Hit Count มี 2 ช่อง คือต้องพบอย่างน้อยกี่ Regular Expression และต้องพบขั้นต่ำกี่ครั้งในไฟล์ ตัวอย่างกรอก 1 ทั้งสองช่อง (ถ้าต้องการจับเฉพาะไฟล์ที่มีข้อมูลจำนวนมาก ให้เพิ่มค่าช่องที่สอง) แล้วคลิก OK
6. กลับมาที่แท็บ Sensitive Data คลิก Add ตั้งชื่อ เลือก Group เป็น General และ Sensitivity Level เป็น L4 ให้ตรงกับ Dictionary

7. ที่ Rule Configuration (เงื่อนไขทำงานแบบ AND ถ้าติ๊กหลายข้อ ไฟล์ต้อง Match ทุกข้อ) ติ๊ก File Content เลือก DLA Dictionaries แล้วเลือก Dictionary ที่เพิ่งสร้าง คลิก OK

   

Audit Policy: เก็บ Log การส่งไฟล์ออก

1. ไปที่ Data Loss Analysis › Policies › Audit Policies คลิก Add แล้วตั้งชื่อ
2. ติ๊ก Apps เลือกกลุ่ม Network Application และ Chat AI แล้วที่ File Extensions เลือกเฉพาะชนิดไฟล์ที่ต้องการ เช่น Microsoft Office และ Text
3. ติ๊ก Browsers ที่ Audited Objects เลือก All และ Exclusion Options เลือก Audit all addresses

4. เปิด Attachment Audit ระบบจะเก็บสำเนาไฟล์ที่ส่งออกไว้ตรวจสอบย้อนหลัง เลือก Applicable Scope แล้วคลิก OK

   

Data Loss Control: Block การส่งข้อมูลสำคัญ

1. ไปที่ Data Loss Analysis › Policies › Data Loss Control คลิก Add ตั้งชื่อ และเลือก Rank
2. ที่ Controlled Objects ติ๊ก Browsers เลือก All เพื่อควบคุมการอัปโหลดผ่าน Browser และติ๊ก Apps เลือกกลุ่ม Chat AI และ Google Drive Web
3. ที่ Sensitive Files ติ๊ก Enable identification แล้วเลือก Sensitive Data ที่เพิ่งสร้าง
4. ที่ Transfer Method มี File เลือกไว้แล้ว ให้ติ๊ก Clipboard text เพิ่มเพื่อควบคุมการวางข้อความด้วย (Clipboard text ใช้กับเครื่อง Windows และในฟอร์มตั้ง Text Length ไว้ที่มากกว่า 50 ตัวอักษร)
5. ที่ Action เลือก Block ติ๊ก Send alert เพื่อแจ้งผู้ใช้ว่าถูก Block เพราะอะไร (คลิก Configure Alert เพื่อดูและแก้ข้อความ) และติ๊ก Log outbound files หากต้องการเก็บสำเนาไฟล์ที่ถูก Block ไว้เป็นหลักฐาน

6. เลือก Applicable Scope แล้วคลิก OK ระบบจะส่ง Policy ไปที่เครื่องผู้ใช้ภายใน 2–5 นาที

   

ทดสอบการ Block และดู Log

• อัปโหลดไฟล์ทดสอบที่มีเลขบัตรประชาชนสมมติขึ้น Google Drive ระบบ Block ทันทีและแสดงข้อความแจ้งเตือนบนเครื่อง ส่วนไฟล์ที่ไม่มี Sensitive Data อัปโหลดได้ตามปกติ

  

• คัดลอกรายชื่อทดสอบที่มีเลขบัตรประชาชนไปวางในช่อง Prompt ของ ChatGPT ระบบ Block การวางข้อความและแจ้งเตือนบนเครื่อง การแนบไฟล์เดียวกันก็ถูก Block เช่นกัน ส่วน Prompt ทั่วไปและไฟล์ที่ไม่มี Sensitive Data ยังใช้ได้ตามปกติ

• ดู Log ที่ Logs › Critical Feature Logs › File Audit แท็บ File Transfers จะเห็นไฟล์ที่ถูก Block พร้อม Sensitive Data, Transfer Channel และ Policy ที่ Match ส่วนไฟล์ที่ส่งได้ก็ถูกบันทึกไว้ด้วยโดย Action เป็น Audit คลิก Details เพื่อดูรายละเอียด ในไฟล์ทดสอบจะเห็นเลขบัตรประชาชนที่ Match ถูกไฮไลต์ไว้

  

• ที่ AI App Analysis มุมมอง File Transfer Analysis จะเห็นสรุปการส่งไฟล์ผ่าน AI แต่ละตัว

สรุปคือ SWG บอกว่าใครใช้ AI ตัวใด ส่วน Data Loss Analysis ควบคุมว่าข้อมูลใดส่งออกไปได้ ทั้งหมดทำงานผ่าน Client ตัวเดียว

Analysis Rules และ Risky Users

นอกจากการ Block ทีละเหตุการณ์ ผู้ดูแลระบบควรเห็นพฤติกรรมเสี่ยงในภาพรวมด้วย

1. ไปที่ Data Loss Analysis › Policies › DLA Rules แท็บ Analysis Rules ระบบมี Predefined Rule แบ่งเป็นกลุ่ม เช่น Outbound File Transfer, Decryption และ File Operations
2. วิธีที่สะดวกคือคลิก Copy จาก Predefined Rule (เช่น Rule การอัปโหลดไฟล์ระดับ L3–L4 ไปยัง Netdisk และเว็บไซต์ภายนอก) แล้วปรับให้เหมาะกับองค์กร: ตั้งชื่อใหม่ แก้ช่อง Description เป็นคำอธิบายของ Rule ใหม่ เปลี่ยน Applicable Users และเพิ่ม Sensitive Data ที่สร้างไว้
3. Detection Method แบบ Meet conditions in a leak ตรวจทีละเหตุการณ์ ส่วนแบบ Meet conditions within นับรวมจำนวนไฟล์และขนาดไฟล์ภายในช่วงเวลาที่กำหนด
4. Risk Score คือคะแนนความเสี่ยงของ Rule ตั้งได้ตั้งแต่ 1 ถึง 9 แล้วคลิก OK

• Data Loss Analysis › Dashboard › XDLA แสดงสรุปการส่งไฟล์ ทั้งที่ถูก Block และที่ถูก Audit กราฟ Transfer Analysis แสดงว่า Sensitive Data ระดับ L4 ถูกส่งผ่านช่องทางใด และจาก Department ใด

  

• เมื่อ Rule ที่เปิดใช้งานตรวจพบเหตุการณ์ที่ Match เงื่อนไข Incident จะแสดงที่ Data Loss Analysis › Analytics › Rule-based Analysis พร้อมผู้ใช้และ Rule ที่ Match
• Risky Users แสดงผู้ใช้ที่มีคะแนนความเสี่ยงสูงจาก Incident เหล่านั้น

อ่านรายละเอียดเพิ่มเติม: ภาพรวม Data Loss Analysis · Data Loss Control · การใช้ GenAI อย่างปลอดภัย

เครื่องมือแก้ปัญหาเบื้องต้น

เครื่องมือ	อยู่ที่	ใช้ทำอะไร
Diagnostics	หน้าต่าง Omnipoint Secure Client	ตรวจสถานะของ Client และเส้นทางจากเครื่องไปถึง PoP และ Application ปลายทาง แสดงเวลาของแต่ละช่วง ช่วยแยกว่าอาการอยู่ที่ Network ของผู้ใช้ ที่ PoP หรือที่ Server
Log Collection	หน้าต่าง Omnipoint Secure Client	เก็บ Log ของ Client ในคลิกเดียว เพื่อส่งให้ทีม Technical Support ของ Sangfor วิเคราะห์ต่อ
https://127.0.0.1:30001	Browser บนเครื่องผู้ใช้	แสดงสถานะการเชื่อมต่อ ชื่อผู้ใช้ และ IP ที่เครื่องเชื่อมต่ออยู่ และมีเมนู Temporary Logout สำหรับ Logout ชั่วคราว
Endpoint Logs	System › Troubleshooting	ดึง Log จากเครื่องผู้ใช้จากระยะไกลโดยผู้ใช้ไม่ต้องดำเนินการเอง: New Task › เลือกเครื่อง › OK เมื่อสถานะเป็น Successful ให้คลิก Download เก็บไฟล์ไว้
Client Troubleshooting	System › Troubleshooting	• Bypass traffic forwarding ให้ผู้ใช้ที่เลือกออกอินเทอร์เน็ตแบบ Direct ชั่วคราว เพื่อแยกว่าอาการที่ผู้ใช้พบเกี่ยวข้องกับการส่ง Traffic ผ่าน Cloud หรือไม่ • Bypass client policies ตรวจว่าอาการเกิดจาก Policy ฝั่ง Endpoint เช่น Data Loss Analysis หรือไม่ • Client Debugger ใช้ร่วมกับทีม Technical Support ของ Sangfor
Service Troubleshooting	System › Troubleshooting	เปิด Traffic Log Capture ชั่วคราวเพื่อดูว่า Policy ใดมีผลกับ Traffic ของผู้ใช้

เมื่อเปลี่ยน Policy แล้วผู้ใช้ยังไม่เห็นผล ให้ผู้ใช้ Logout แล้ว Login ใหม่ เพื่อดึง Policy ล่าสุดจาก Cloud

ฝั่ง App Connector ตรวจ Service แล้วรันคำสั่งตรวจการเชื่อมต่อ ผลแต่ละข้อเป็น √ หรือ X ถ้าข้อใดเป็น X ระบบจะแสดง IP และ Port ปลายทางที่ต้องอนุญาตที่ Firewall

systemctl status connector
curl http://localhost:18888/get_detect_network

สำหรับ Identity Connector ใช้คำสั่ง systemctl status idaas-agent

ลำดับการตรวจเบื้องต้น

1. ดูว่าผู้ใช้ออนไลน์อยู่หรือไม่ที่ Dashboard › User Status
2. รัน Diagnostics ที่เครื่องผู้ใช้
3. ตรวจสิทธิ์ Policy และ Log ของโมดูลนั้น (ZTNA Logs, SWG Logs, Threat Protection Logs หรือ File Audit)
4. ถ้ายังไม่พบสาเหตุ ให้เก็บ Endpoint Logs และ Log ของ Connector แล้วติดต่อทีม Technical Support ของ Sangfor

อ่านรายละเอียดเพิ่มเติม: แนวทางแก้ปัญหา Athena SASE · เครื่องมือช่วยตรวจปัญหาบน Client · Client Bypass สำหรับการแก้ไขปัญหา

สรุป

• ตรวจ Subscription และเตรียม Firewall ขาออกตาม Service Address List
• เชื่อม Active Directory ผ่าน Identity Connector ให้ผู้ใช้ Login ด้วย Account เดิม
• ติดตั้ง Omnipoint Secure Client ตัวเดียวที่รวม ZTNA, SWG และ Data Loss Analysis
• ZTNA: Publish App ผ่าน App Connector ผู้ใช้เข้าได้เฉพาะ App ที่ได้รับสิทธิ์ พร้อมตรวจสภาพเครื่อง
• SWG: Decrypt HTTPS ควบคุมการใช้เว็บ มองเห็นการใช้ AI และป้องกันภัยจากเว็บ
• Data Loss Analysis: ระบุเลขบัตรประชาชนไทย Block การส่งออกผ่าน Browser และ AI และบันทึกไฟล์ที่ส่งได้ไว้ตรวจสอบ
• เมื่อพบปัญหา เริ่มจาก Diagnostics ที่เครื่องผู้ใช้ และเครื่องมือ Troubleshooting บน Console