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

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

วิดีโอ Quick Start

หากวิดีโอไม่แสดง ดูได้ที่ YouTube

ค่า IP ชื่อโดเมน ชื่อผู้ใช้ และเลขบัตรประชาชนในภาพประกอบเป็นค่าตัวอย่างจากห้องทดลอง (เช่น lab.local, alice, ชื่อที่ขึ้นต้นด้วย LAB-) ให้เปลี่ยนเป็นค่าขององค์กรเมื่อตั้งค่าจริง

Athena SASE ทำงานอย่างไร

▶ ดูขั้นตอนนี้ในวิดีโอ (00:52)

Athena SASE รวม ZTNA, SWG และ DLP ไว้บน Cloud Platform เดียว

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

• Client เชื่อมต่อกับ PoP ซึ่งเป็นจุดให้บริการบน Cloud ของ Sangfor โดย Client วัดความเร็วไปยัง PoP ที่เปิดใช้ให้ Tenant แล้วเชื่อมต่อกับ PoP ที่ดีที่สุดให้อัตโนมัติ
• สำหรับผู้ใช้ในไทย Athena SASE มี PoP ในประเทศไทย เมื่อเปิดใช้ให้ Tenant แล้ว Traffic จะถูกตรวจใกล้ผู้ใช้
• PoP ตรวจ Policy ของ Zero Trust ก่อน แล้วจึงส่งต่อไปยัง App Connector ใน Data Center
• App Connector เป็นฝ่ายสร้าง Encrypted Tunnel ออกไปหา PoP เอง จึงไม่ต้องเปิด Port ของ Network ภายในสู่อินเทอร์เน็ต

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

▶ ดูขั้นตอนนี้ในวิดีโอ (02:05)

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

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

ส่วนที่ 1 · Setup: Console, Subscription และ Service Address List

เข้า Console

▶ ดูขั้นตอนนี้ในวิดีโอ (03:16)

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

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

ตรวจ Subscription

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

   

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

การ์ดอื่นเป็นบริการเสริมตามที่องค์กรสั่งซื้อ

เตรียม Network ตาม Service Address List

▶ ดูขั้นตอนนี้ในวิดีโอ (04:59)

1. ไปที่ System › General Settings › Service Address List

2. ถ้าไม่มี Firewall หรือ Firewall ไม่ได้ควบคุม Application ขาออก หน้านี้แจ้งว่าไม่ต้องทำอะไรเพิ่ม

   

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

ส่วนที่ 2 · Identity: เชื่อม Active Directory

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

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

ติดตั้ง Identity Connector

▶ ดูขั้นตอนนี้ในวิดีโอ (05:54)

1. ไปที่ Platform Management › Identity Management › User Management กด Manage User Sources แล้วเลือก Manage Identity Connectors หน้านี้มีขั้นตอนติดตั้งและ Spec ของเครื่องที่ต้องเตรียม เครื่อง Connector ต้องออกไปยังปลายทางและ Port ที่หน้านี้ระบุไว้ได้

   

2. กด Add ตั้งชื่อ Connector แล้วกด OK ระบบจะดาวน์โหลดไฟล์ติดตั้งให้ทันที และการ์ดของ Connector ใหม่จะขึ้นมารอการติดตั้ง

3. คัดลอกไฟล์ไปไว้บนเครื่อง Linux (เช่นผ่าน SCP) แตกไฟล์ แล้วรันตัวติดตั้งด้วยสิทธิ์ 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 ของเครื่อง พร้อมจุดสถานะสีเขียว

   

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

▶ ดูขั้นตอนนี้ในวิดีโอ (07:32)

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 (ระบบเปลี่ยน Port เป็น 636 ให้)
   Bind Method	Admin แล้วกรอก Service Account ในรูปแบบ Domain\Username พร้อมรหัสผ่าน
   Base DN	OU ที่เก็บผู้ใช้ที่จะใช้งาน 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

▶ ดูขั้นตอนนี้ในวิดีโอ (09:43)

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

   

ส่วนที่ 3 · Client: ติดตั้ง Omnipoint Secure Client

ติดตั้ง Omnipoint Secure Client ตัวเดียว ได้ครบทั้ง ZTNA, SWG และ DLP

ดาวน์โหลด Package

▶ ดูขั้นตอนนี้ในวิดีโอ (11:22)

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

   

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

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

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

   

ติดตั้งและ Login

▶ ดูขั้นตอนนี้ในวิดีโอ (12:52)

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 จะเห็นผู้ใช้ออนไลน์ Admin ดูรายละเอียด หรือสั่ง Log out user ได้จากหน้านี้

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

  

ส่วนที่ 4 · ZTNA: เข้า App ภายในโดยไม่ต้องใช้ VPN

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

ติดตั้ง App Connector

▶ ดูขั้นตอนนี้ในวิดีโอ (14:13)

1. ไปที่ Core Features › Zero Trust Security › Policies › Connectors แผนภาพด้านบนสรุปการทำงาน: Traffic จากเครื่องผู้ใช้วิ่งเข้า PoP ซึ่งตรวจสิทธิ์และ Security Compliance ของเครื่อง แล้วจึงส่งต่อให้ 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 (ในตัวอย่างใช้เครื่องเดียวกับ Identity Connector) แตกไฟล์โดยไม่เปลี่ยนชื่อไฟล์ Package แล้วติดตั้งและตรวจสถานะ ต้องเห็น active (running)

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

   

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

   

Publish เว็บภายใน (Tunnel App)

▶ ดูขั้นตอนนี้ในวิดีโอ (16:17)

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

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

2. กด Add ระบบเปิดฟอร์มของ Tunnel 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 UDP, ICMP และ ALL: IP, ช่วง IP หรือ Subnet
   App Address › Port	Port เดียว หลาย Port หรือเป็นช่วง (เว็บในตัวอย่างใช้ 80) App หนึ่งตัวกรอก Address ได้สูงสุด 32 รายการ
   Exclude specified addresses	เปิดเมื่อกรอกเป็นช่วง IP หรือ Subnet แล้วมีบางเครื่องที่ไม่ต้องการเปิด
   Region	Default ระบบจะใช้ PoP ใน Region นี้ก่อนเมื่อสร้าง Tunnel ไปยัง App
   Connection Method	Connector แล้วเลือกตัวที่ติดตั้งไว้ (ถ้าทำ HA แบบ Group ให้เลือก Connector Group)

   

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

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

   

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

Publish Remote Desktop และ File Share

▶ ดูขั้นตอนนี้ในวิดีโอ (18:49)

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

• Remote Desktop: เลือก App Group ของทีม IT กรอก IP ของ Server และ Port 3389 แล้วเลือก Connector ตัวเดิม App Launch Method เลือก System Application › Remote Desktop Connection (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

▶ ดูขั้นตอนนี้ในวิดีโอ (20:38)

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

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

▶ ดูขั้นตอนนี้ในวิดีโอ (21:18)

1. ไปที่ Zero Trust Security › Policies › Advanced Settings แท็บ User Policies (Policy ที่ผูกกับผู้ใช้จะมาก่อน Policy ของ OU ที่อยู่เหนือขึ้นไป ถ้าไม่มีเลยระบบจะใช้ Default policy)
2. กด Add ตั้งชื่อ ช่อง Objects เลือกได้ทั้ง User และ Department (ตัวอย่างเลือก Department ที่ผู้ใช้อยู่โดยตรง)
3. แท็บ Account Settings กำหนดให้ Log Out อัตโนมัติเมื่อไม่มีการใช้ App ตามเวลาที่ตั้งไว้ (ตัวอย่างตั้ง 8 ชั่วโมง ในการใช้งานจริงให้ตั้งตามนโยบายความปลอดภัยขององค์กร)
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

   

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

▶ ดูขั้นตอนนี้ในวิดีโอ (22:36)

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

• Login ด้วยผู้ใช้ที่อยู่ใน Security Group ของพนักงาน (alice): Workspace แสดง Category ของพนักงาน ทั้ง Intranet และ File Share แต่ไม่มี Remote Desktop

  

• คลิก Intranet แล้ว Browser จะเปิดหน้าเว็บภายในทันที หน้าเว็บแสดงว่า Request มาจาก IP ของ Connector ส่วน Server ภายในไม่ได้คุยกับเครื่องของผู้ใช้โดยตรง และพิมพ์แค่ชื่อสั้น (intranet) ก็เข้าได้เพราะเปิด Append DNS suffix ไว้

  

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

• ผู้ใช้ในกลุ่มทีม IT (itadmin) จะเห็นครบทุก App รวมถึง Remote Desktop คลิกแล้วระบบเปิด Remote Desktop Connection ให้เชื่อมต่อได้

  

ขอสิทธิ์ผ่าน App Access Request (ผู้ใช้ bob ที่ยังไม่อยู่ใน Group ที่ได้รับสิทธิ์ จึงยังไม่มี App ใน Workspace)

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

   

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

   

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

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

▶ ดูขั้นตอนนี้ในวิดีโอ (25:06)

นอกจากตัวตนแล้ว Zero Trust ยังตรวจสภาพของเครื่องตลอดการใช้งานด้วย

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 แล้วเขียนข้อความแจ้งผู้ใช้เป็นภาษาไทย จากนั้นกด OK

   

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

Log และ Dashboard ของ ZTNA

▶ ดูขั้นตอนนี้ในวิดีโอ (26:24)

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

  

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

ส่วนที่ 5 · SWG: ควบคุมการใช้เว็บและ AI

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

Traffic Forwarding

▶ ดูขั้นตอนนี้ในวิดีโอ (27:21)

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

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

2. หน้านี้มี Policy ยกเว้น Traffic สำหรับ App ภายในในวง Private IP 3 วงหลัก (10.0.0.0/8, 172.16.0.0/12 และ 192.168.0.0/16) อยู่แล้ว คือแถว Default Non-Traffic Forwarding Policy ถ้าองค์กรใช้ IP วงอื่นด้วย ให้เพิ่มเข้าไปใน Policy นี้

   

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

SSL Decryption

▶ ดูขั้นตอนนี้ในวิดีโอ (28:47)

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

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

5. Applicable Scope ฟอร์มเลือก All ไว้ ปรับได้ตามต้องการ (ตัวอย่างเลือก Department ของห้องทดลอง) แล้วกด OK

   

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

URL & App Audit

▶ ดูขั้นตอนนี้ในวิดีโอ (30:13)

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

▶ ดูขั้นตอนนี้ในวิดีโอ (31:40)

ใช้จำกัด 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 แล้วเลือก All ส่วน URL Category เช่น Online Shopping อยู่ใต้ Visit Web Site ตัวอย่างค้นหา YouTube แล้วเลือก YouTube Video จากนั้นกด OK

   

4. Action เป็น Reject (ฟอร์มเลือกไว้ให้) และ Schedule เป็น All Day แล้วกด OK เลือก Applicable Scope แล้วกด OK

• Policy ในรายการเรียงตาม Priority และ Policy ใหม่จะอยู่ลำดับบนสุด เหนือ Default Policy ที่อนุญาตแบบกว้าง

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

  

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

ดูการใช้งาน Generative AI

▶ ดูขั้นตอนนี้ในวิดีโอ (33:14)

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

1. ไปที่ Data Loss Analysis › Analytics › Outbound Data แล้วเปิดแท็บ AI App Analysis
2. หน้านี้ต้องเปิด URL & App Audit และ SSL Decryption (ตั้งไว้แล้วด้านบน) และ Audit Policy ของ DLP (ตั้งในส่วนที่ 6)

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

   

Threat Protection

▶ ดูขั้นตอนนี้ในวิดีโอ (34:10)

ไปที่ Secure Web Gateway › Policies › Threat Management มี 4 Engine หลัก ตรวจว่า Engine ที่ต้องการเปิดอยู่

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

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

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

  

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

  

ส่วนที่ 6 · DLP: ควบคุมการส่งข้อมูลสำคัญออกนอกองค์กร

DLP พื้นฐานที่มาพร้อมกับ Client และ Console เดียวกัน ใช้กำหนดว่า Sensitive Data ส่งออกทางไหนได้บ้าง DLP ทำงานบนเครื่องผู้ใช้ผ่านโมดูล XDLA ใน Client ตัวเดิม ตรวจไฟล์และข้อความที่ส่งออกจากเครื่อง ทั้งผ่าน Browser, App, USB และ Clipboard ตัวอย่างในส่วนนี้ใช้เลขบัตรประชาชนไทยเป็นข้อมูลสำคัญ

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

▶ ดูขั้นตอนนี้ในวิดีโอ (35:49)

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

   

ตอนนี้ระบบรู้แล้วว่าไฟล์ที่มีเลขบัตรประชาชนคือ Sensitive Data ระดับ L4

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

▶ ดูขั้นตอนนี้ในวิดีโอ (37:53)

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

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

   

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

▶ ดูขั้นตอนนี้ในวิดีโอ (38:32)

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 และฟอร์มกำหนดให้ตรวจข้อความที่ยาวเกิน 50 ตัวอักษร)
5. Action เลือกเป็น Block ไว้แล้ว ติ๊ก Send alert เพื่อแจ้งผู้ใช้ว่าทำไมถูกบล็อก (กด Configure Alert เพื่อดูและแก้ข้อความได้) และติ๊ก Log outbound files เพื่อเก็บสำเนาไฟล์ที่ถูกบล็อกไว้เป็นหลักฐาน

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

   

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

▶ ดูขั้นตอนนี้ในวิดีโอ (39:36)

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

  

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

  

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

  

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

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

Analysis Rules และ Risky Users

▶ ดูขั้นตอนนี้ในวิดีโอ (41:26)

นอกจากบล็อกทีละครั้ง ทีม IT ควรเห็นพฤติกรรมเสี่ยงในภาพรวมด้วย

1. ไปที่ Data Loss Analysis › Policies › DLA Rules แท็บ Analysis Rules ระบบมี Predefined Rule กว่า 20 ข้อ แบ่งเป็นกลุ่ม เช่น การส่งไฟล์ออก และการ Decrypt ไฟล์

   

2. วิธีที่สะดวกคือกด Copy จาก Predefined Rule (เช่น การอัปโหลดไฟล์ระดับ L3–L4 ไปยัง Netdisk และเว็บไซต์ภายนอก) แล้วปรับให้เหมาะกับองค์กร: ตั้งชื่อใหม่ เปลี่ยน 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 แสดงสรุปการส่งไฟล์ ทั้งที่ถูกบล็อกและที่ถูก Audit กราฟ Transfer Analysis แสดงว่า Sensitive Data ระดับ L4 ถูกส่งผ่านช่องทางไหน และจาก Department ใด

  

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

ส่วนที่ 7 · เครื่องมือแก้ปัญหาเบื้องต้น

▶ ดูขั้นตอนนี้ในวิดีโอ (43:07)

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

ฝั่ง 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 แล้วติดต่อทีม Support ของ Sangfor

สรุปและบทความที่เกี่ยวข้อง

▶ ดูขั้นตอนนี้ในวิดีโอ (45:45)

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

บทความที่เกี่ยวข้อง

• ภาพรวม Sangfor Access Secure (SASE) และสถาปัตยกรรม
• การเข้าใช้งาน SaaS SASE บน Platform-X
• วิธี Activate License สำหรับลูกค้า (Platform-X)
• วิธี Activate License แทนลูกค้าสำหรับ Partner (Partner License Center)
• การ Sync ผู้ใช้จาก On-Premises Microsoft AD
• การตั้งค่า Microsoft AD Authentication Source
• การตั้งค่า Multi-Factor Authentication (MFA) แบบละเอียด
• First Installation Deployment Guide สำหรับการติดตั้งครั้งแรกในองค์กร
• การ Deploy Connector บน Linux อย่างละเอียด
• การสร้างและจัดการ Connector Groups
• การเผยแพร่ Tunnel Applications บน Zero Trust Guard
• การกำหนด App Protection Policies
• SSL Decryption Configuration
• การตั้งค่า URL & App Control Policy
• Threat Management - Antivirus และ IPS
• Client Bypass สำหรับการแก้ไขปัญหา
• Sangfor Access Secure (SASE) Deployment Guide สำหรับ Partner / Integrator