BYOD และการเข้าถึงของผู้รับจ้าง: การรักษาความปลอดภัยของอุปกรณ์ที่ไม่ได้รับการจัดการผ่านเบราว์เซอร์

บริษัทที่ปรึกษาต้องการผู้รับจ้าง 200 คนเพื่อเข้าถึงระบบ SharePoint และ Salesforce ภายในองค์กร สำหรับโครงการที่มีระยะเวลา 6 เดือน คอมพิวเตอร์พกพาส่วนตัวของพวกเขาไม่สามารถติดตั้งเอเจนต์ปลายทางได้ การลงทะเบียน MDM เป็นทางเลือกที่ไม่เหมาะสมสำหรับอุปกรณ์ที่ผู้รับจ้างยังใช้สำหรับการทำธุรกรรมธนาคารส่วนตัวและเก็บรูปภาพครอบครัวด้วย นอกจากนี้ การตั้งระบบ VDI สำหรับกลุ่มผู้ใช้ชั่วคราวจะทำให้งบประมาณโครงการเกินตัว เบราว์เซอร์ — แอปพลิเคชันที่เปิดอยู่แล้วบนทุกเครื่องแล็ปท็อป — เป็นจุดควบคุมที่เหมาะสมที่สุดที่คุณมี คู่มือนี้จะนำผู้นำด้านความปลอดภัยผ่านแนวทางแบบเป็นขั้นตอนในการรักษาความปลอดภัยการเข้าถึงของ BYOD และผู้รับจ้างผ่านกลไกควบคุมที่อิงกับเบราว์เซอร์ ตั้งแต่ข้อกำหนดเบื้องต้นไปจนถึงเกณฑ์ความสำเร็จที่วัดได้

เงื่อนไขเบื้องต้น: สิ่งที่คุณต้องเตรียมไว้ก่อนเริ่ม

ก่อนที่จะกำหนดการควบคุมการเข้าถึงผ่านเบราว์เซอร์สำหรับผู้ใช้ BYOD และผู้รับจ้าง ให้แน่ใจว่าพื้นฐานเหล่านี้ได้จัดเตรียมไว้เรียบร้อยแล้ว การข้ามขั้นตอนเหล่านี้เป็นสาเหตุหลักที่ทำให้การนำระบบไปใช้เกิดการล่าช้า

โครงสร้างพื้นฐานด้านอัตลักษณ์ต้องรองรับผู้ใช้จากภายนอก IdP ของคุณต้องจัดการอัตลักษณ์แบบเฟเดอเรตสำหรับผู้รับจ้าง ไม่ใช่เพียงพนักงานเท่านั้น ลองนึกถึงสถานการณ์ของบริษัทที่ปรึกษา: ผู้จัดการโครงการส่งคำแนะนำการลงทะเบียนให้กับผู้รับจ้าง 200 คนในวันจันทร์ หาก IdP ของคุณไม่สามารถออกอัตลักษณ์ที่มีขอบเขตและจำกัดเวลา ซึ่งผูกกับโดเมนภายนอกได้ คุณจะต้องใช้เวลาทั้งสัปดาห์นั้นในการจัดตั้งบัญชีแบบมือ—และอาจลืมยกเลิกการจัดตั้งบัญชีเมื่อสัญญาสิ้นสุดลง NIST SP 800-46 Rev. 2 ระบุข้อกำหนดด้านความปลอดภัยสำหรับ BYOD และอุปกรณ์ลูกค้าที่ควบคุมโดยผู้รับจ้าง พันธมิตรทางธุรกิจ และผู้จำหน่ายอย่างชัดเจน โดยเน้นย้ำถึงความสำคัญของการรักษาความปลอดภัยข้อมูลที่ละเอียดอ่อนที่เก็บไว้และส่งผ่านอุปกรณ์เหล่านี้

รายชื่อแอปพลิเคชันตามวิธีการเข้าถึง จัดทำแคตตาล็อกแอปพลิเคชันที่ผู้รับจ้างจำเป็นต้องใช้ ไม่ว่าจะเป็นSaaS(เข้าถึงได้ผ่านพร็อกซีแบบไปข้างหน้าหรือแบบย้อนกลับ), แอปพลิเคชันเว็บภายในองค์กร (เข้าถึงได้ผ่าน ZTNA) หรือแอปพลิเคชันแบบ thick client แบบเก่า (ซึ่งอาจยังต้องการ VDI) ส่วนใหญ่ของงานของผู้รับจ้างนั้นเน้นไปที่ SaaS — เช่น SharePoint, Salesforce, ServiceNow — ซึ่งทำให้การบังคับใช้ผ่านเบราว์เซอร์เป็นไปได้สำหรับเซสชันส่วนใหญ่

การจัดประเภทข้อมูลเพื่อกำหนดนโยบายDLPหากยังไม่ได้กำหนดว่าข้อมูลใดถือเป็นข้อมูลที่ละเอียดอ่อนในแอปพลิเคชันที่ผู้รับจ้างจะเข้าถึง นโยบาย DLP จะอาจบล็อกข้อมูลมากเกินไป หรือไม่บล็อกข้อมูลใดเลย อย่างน้อยที่สุด ให้กำหนดเงื่อนไขการทริกเกอร์นโยบายสำหรับข้อมูลส่วนบุคคล (PII) ข้อมูลทางการเงิน และทรัพย์สินทางปัญญา

การตัดสินใจเกี่ยวกับสถาปัตยกรรมเครือข่าย NIST SP 800 46 แนะนำให้องค์กรพิจารณาใช้โซลูชันควบคุมการเข้าถึงเครือข่ายที่ตรวจสอบสถานะความปลอดภัยของอุปกรณ์ไคลเอนต์ก่อนอนุญาตให้อุปกรณ์ดังกล่าวใช้เครือข่ายภายใน และพิจารณาใช้เครือข่ายแยกต่างหากสำหรับอุปกรณ์ไคลเอนต์จากภายนอกทั้งหมด รวมถึงอุปกรณ์ BYOD และอุปกรณ์ที่ควบคุมโดยฝ่ายที่สาม สำหรับการเข้าถึงผ่านเบราว์เซอร์ สิ่งนี้หมายถึงการส่งทราฟฟิกของอุปกรณ์ที่ไม่ได้รับการจัดการทั้งหมดผ่านแพลตฟอร์มSSEของคุณ แทนที่จะให้สิทธิ์การเข้าถึงเครือข่ายโดยตรง

ขั้นตอนที่ 1: สร้างความโปร่งใสและกำหนดนโยบายพื้นฐานด้วย CASB และ SWG

เริ่มด้วยการตอบคำถามพื้นฐานที่สุด: อุปกรณ์ที่ไม่ได้รับการจัดการกำลังทำอะไรในแอปพลิเคชัน SaaS ของคุณในปัจจุบัน?

ติดตั้ง CASB ในโหมด reverse proxy เพื่อดักจับเซสชันจากอุปกรณ์ที่ไม่ได้รับการจัดการ ซึ่งกำลังเข้าถึงแอปพลิเคชัน SaaS ที่ได้รับอนุญาต โพรซีรีเวิร์สไม่ต้องการเอเจนต์—ผู้รับจ้างเพียงยืนยันตัวตนผ่าน IdP ของคุณ และถูกส่งผ่านจุดบังคับใช้ CASB อย่างโปร่งใส ในกรณีของบริษัทที่ปรึกษา เมื่อผู้รับจ้างเข้าสู่ระบบ Salesforce จาก MacBook ส่วนตัว CASB จะตรวจพบเซสชันดังกล่าว จัดประเภทอุปกรณ์ว่าเป็นอุปกรณ์ที่ไม่ได้รับการจัดการ เนื่องจากไม่มีใบรับรองลูกค้า และนำนโยบายสำหรับอุปกรณ์ที่ไม่ได้รับการจัดการของคุณมาใช้: การเข้าถึงแบบอ่านอย่างเดียวต่อบันทึกโอกาส ไม่สามารถส่งออกข้อมูลแบบกลุ่มได้ และมีการใส่ลายน้ำบนหน้าจอที่แสดงผล

พร้อมกันนั้น ให้ส่งการจราจรบนเว็บจากผู้ใช้เหล่านี้ผ่าน SWG ของคุณ เพื่อบังคับใช้นโยบายการใช้งานที่ยอมรับได้ บล็อกการเข้าถึงหมวดหมู่ที่มีความเสี่ยงสูง และสแกนไฟล์ที่ดาวน์โหลดเพื่อตรวจหาโปรแกรมมัลแวร์ SWG เป็นแนวป้องกันแรกของคุณต่อกรณีที่ผู้รับจ้างคลิกที่ลิงก์ฟิชชิ่งในแท็บอีเมลส่วนตัว ขณะที่กำลังเข้าสู่ระบบ SharePoint ของบริษัทอยู่

สิ่งที่ควรวัดในขั้นตอนนี้:

จำนวนเซสชันของอุปกรณ์ที่ไม่ได้จัดการที่ตรวจพบต่อวัน

แอปพลิเคชัน SaaS ที่ถูกเข้าถึงโดยอุปกรณ์ที่ไม่ได้รับการจัดการ (การค้นพบ SaaS แบบเงา)

การละเมิดนโยบายถูกบล็อก (การดาวน์โหลดจำนวนมาก, การเข้าถึงแอปโดยไม่ได้รับอนุญาต)

เวลาเฉลี่ยตั้งแต่การขอรับผู้รับจ้างเข้าทำงานจนถึงการได้รับสิทธิ์เข้าถึงระบบเพื่อเริ่มทำงาน

ขั้นตอนนี้จะให้ข้อมูลการวัดผลเพื่อสนับสนุนการลงทุนในขั้นตอนต่อไป หากระบบ CASB ของคุณตรวจพบว่าผู้รับจ้างกำลังดาวน์โหลดรายชื่อลูกค้าไปยังอุปกรณ์ส่วนตัวทุกสัปดาห์ ข้อเสนอทางธุรกิจสำหรับขั้นตอนที่ 2 ก็จะชัดเจนขึ้นโดยอัตโนมัติ

ขั้นตอนที่ 2: เพิ่มRemote Browser Isolation เซสชันที่มีความสำคัญสูง

เมื่อสามารถตรวจสอบสถานะได้แล้ว ขั้นตอนต่อไปคือการกำจัดจุดปลายทาง (endpoint) ให้หมดสิ้นในฐานะช่องทางคุกคามสำหรับแอปพลิเคชันที่มีความสำคัญสูงสุดของคุณ นี่คือจุดที่ remote browser isolation กลายเป็นมาตรการควบคุมที่แข็งแกร่งที่สุดสำหรับอุปกรณ์ที่ไม่ได้รับการจัดการ

ลองพิจารณาสถานการณ์จริง: ผู้รับจ้างในบริษัทที่ปรึกษาจำเป็นต้องตรวจสอบข้อมูลลูกค้าใน Salesforce ซึ่งรวมถึงข้อมูลส่วนบุคคล (PII) — ชื่อ ที่อยู่ และมูลค่าธุรกรรม ด้วย RBI เซสชัน Salesforce จะทำงานในคอนเทนเนอร์บนคลาวด์ ผู้รับจ้างสามารถดูและโต้ตอบกับแอปพลิเคชันได้ตามปกติผ่านเบราว์เซอร์ Chrome หรือ Safari ของตนเอง แต่ข้อมูลแอปพลิเคชัน โทเค็นเซสชัน หรือเนื้อหาหน้าเว็บจะไม่ถูกส่งไปยังอุปกรณ์ท้องถิ่นเลย หากแล็ปท็อปส่วนตัวของผู้รับจ้างถูกบุกรุกด้วยโปรแกรมบันทึกการกดคีย์ (keylogger) หรือโปรแกรมขโมยข้อมูล (info stealer) มัลแวร์ดังกล่าวจะไม่มีข้อมูลที่มีประโยชน์ใด ๆ ที่จะจับได้ เนื่องจากเซสชันไม่เคยถูกดำเนินการบนอุปกรณ์ท้องถิ่น

RBI ยังช่วยให้สามารถควบคุมข้อมูลอย่างละเอียดภายในเซสชันที่ถูกแยกออกมาได้ คุณสามารถปิดการใช้งานการคัดลอกและวาง ป้องกันการพิมพ์ ป้องกันการดาวน์โหลดไฟล์ และใช้ลายน้ำแบบไดนามิกที่ฝังข้อมูลระบุตัวตนของผู้ใช้ลงในภาพหน้าจอ เมื่อเซสชันสิ้นสุดลง คอนเทนเนอร์จะถูกทำลาย ทำให้ไม่เหลือข้อมูลใดๆ บนอุปกรณ์ที่ไม่ได้อยู่ภายใต้การจัดการ

วิธีการนี้สอดคล้องโดยตรงกับหลักการZero TrustNIST SP 800 207 ระบุอย่างชัดเจนว่าอุปกรณ์ในเครือข่ายอาจไม่ได้เป็นขององค์กรหรือองค์กรอาจไม่สามารถกำหนดค่าได้ และบริการที่จ้างมาอาจรวมถึงสินทรัพย์ที่ไม่ได้เป็นขององค์กร ซึ่งจำเป็นต้องเข้าถึงเครือข่ายเพื่อปฏิบัติหน้าที่ RBI คือการนำไปใช้ในทางปฏิบัติของหลักการนี้: คุณให้สิทธิ์การเข้าถึงแอปพลิเคชันโดยไม่ไว้วางใจอุปกรณ์

เมื่อใดควรใช้ RBI แทน proxy CASB แบบมาตรฐาน:

เมื่อใดควรใช้ RBI หรือ Standard CASB Proxy

ขั้นตอนที่ 3: ขยายการใช้งาน ZTNA สำหรับแอปพลิเคชันส่วนตัว

แอปพลิเคชัน SaaS เป็นเพียงส่วนหนึ่งของภาพรวมเท่านั้น การทำงานร่วมกับผู้รับจ้างหลายแห่งจำเป็นต้องเข้าถึงแอปพลิเคชันเว็บภายในองค์กร — เช่น พอร์ทัลที่ปรับแต่งเอง วิกิภายในองค์กร และสภาพแวดล้อมการพัฒนา — ซึ่งไม่ได้เปิดให้เข้าถึงจากอินเทอร์เน็ต

VPN แบบดั้งเดิมให้ผู้รับจ้างสร้างช่องทางเชื่อมต่อระดับเครือข่ายเข้าสู่ระบบของคุณ ซึ่งขัดกับหลักการทุกข้อในคู่มือ Zero Trust หากผู้รับจ้างคนใดในจำนวน 200 คนนั้นมีมัลแวร์ในแล็ปท็อปส่วนตัว และคุณได้ให้สิทธิ์เข้าถึง VPN แก่เขา มัลแวร์นั้นสามารถสแกนเครือข่ายภายในของคุณ พยายามเคลื่อนที่ตามแนวนอน และเข้าถึงระบบที่อยู่ไกลเกินขอบเขตที่ผู้รับจ้างนั้นตั้งใจจะเข้าถึง

ZTNA /Private Access VPN ด้วยการเข้าถึงระดับแอปพลิเคชัน ผู้รับจ้างจะผ่านกระบวนการยืนยันตัวตน ระบบนโยบายจะประเมินตัวตน ข้อมูลบริบทของอุปกรณ์ และสัญญาณความเสี่ยง ก่อนที่จะอนุญาตให้เข้าถึงเฉพาะแอปพลิเคชันภายในที่ได้รับการอนุมัติตามบทบาทของพวกเขาเท่านั้น — ไม่มีสิ่งอื่นใด ผู้รับจ้างจะไม่เห็นหรือเข้าถึงเครือข่ายพื้นฐานเลย

ขั้นความพร้อมของโมเดลความพร้อม Zero Trust ของ CISA ช่วยให้องค์กรสามารถประเมิน วางแผน และรักษาการลงทุนที่จำเป็นเพื่อก้าวสู่ระบบ Zero Trust ผ่านห้าเสาหลัก ได้แก่: ความเป็นบุคคล (Identity), อุปกรณ์ (Devices), เครือข่าย (Networks), แอปพลิเคชันและเวิร์กโหลด (Applications and Workloads), และข้อมูล (Data) การเปลี่ยนจาก VPN ไปสู่ ZTNA สำหรับการเข้าถึงของผู้รับจ้าง เป็นขั้นตอนที่วัดผลได้ในการก้าวจากระดับความพร้อม "แบบดั้งเดิม" (Traditional) ไปสู่ระดับ "ขั้นต้น" (Initial) ในทั้งเสาหลักด้านอุปกรณ์และเครือข่าย

สำหรับกรณีของบริษัทที่ปรึกษา ZTNA หมายความว่า ผู้รับจ้าง Jane สามารถเข้าถึงพอร์ทัลติดตามโครงการภายในจากแล็ปท็อปส่วนตัวที่บ้านได้ แต่เธอไม่สามารถสแกนเครือข่าย เข้าถึงโดเมนคอนโทรลเลอร์ หรือเปลี่ยนไปยังแอปพลิเคชันการเงินได้ หากสัญญาของเธอสิ้นสุดลงในวันศุกร์ สิทธิ์การเข้าถึงของเธอจะถูกยกเลิกที่ชั้นแอปพลิเคชัน — ไม่จำเป็นต้องติดตามใบรับรอง VPN หรือปรับกฎไฟร์วอลล์ให้เรียบร้อย

ทำไม VDI และ MDM จึงไม่เพียงพอสำหรับการใช้งาน BYOD และการเข้าถึงของผู้รับจ้าง

ผู้นำด้านความปลอดภัยมักประเมิน VDI และ MDM ก่อนที่จะพิจารณาใช้ระบบควบคุมผ่านเบราว์เซอร์ ทั้งสองระบบมีกรณีการใช้งานที่เหมาะสม แต่ไม่มีระบบใดที่เหมาะสำหรับกลุ่มอุปกรณ์ที่ไม่ได้รับการจัดการ ซึ่งมีจำนวนมากและใช้ชั่วคราว

VDI (Virtual Desktop Infrastructure): VDI สร้างสภาพแวดล้อมเดสก์ท็อปแบบรวมศูนย์บนเซิร์ฟเวอร์ โดยส่งสตรีมเซสชันภาพไปยังอุปกรณ์ของผู้ใช้ ซึ่งเหมาะอย่างยิ่งสำหรับสภาพแวดล้อมที่มีกฎระเบียบเข้มงวดและต้องการแอปพลิเคชันแบบ thick client แต่สำหรับผู้รับจ้าง 200 คนที่เข้าถึงแอปพลิเคชัน SaaS เป็นระยะเวลา 6 เดือน VDI ถือเป็นโซลูชันที่เกินความจำเป็น โซลูชัน VDI ที่โฮสต์บนคลาวด์มักมีค่าใช้จ่ายหลายสิบดอลลาร์ต่อผู้ใช้ต่อเดือน ส่วน VDI ที่ติดตั้งในสถานที่เอง (on-premise) ต้องการทุนลงทุนจำนวนมากสำหรับเซิร์ฟเวอร์ เครือข่าย และซอฟต์แวร์การเสมือน สำหรับโครงการที่มีผู้รับจ้าง 200 คน ค่าใช้จ่ายการสมัครสมาชิก VDI รวมทั้งหมดอาจสูงถึงหลายหมื่นดอลลาร์ภายในหกเดือน — ยังไม่รวมค่าใช้จ่ายด้านโครงสร้างพื้นฐาน ใบอนุญาต และค่าใช้จ่ายสนับสนุน VDI ยังก่อให้เกิดความล่าช้า การหยุดชะงักของเซสชัน และเวลาการตั้งค่าเริ่มต้นที่ยาวนาน ซึ่งทำให้ผู้ใช้รู้สึกหงุดหงิดและลดประสิทธิภาพการทำงาน

MDM (การจัดการอุปกรณ์มือถือ): MDM จำเป็นต้องติดตั้งโปรไฟล์การจัดการบนอุปกรณ์ส่วนตัวของผู้รับจ้าง เพื่อให้องค์กรสามารถควบคุมการตั้งค่าอุปกรณ์ ลบข้อมูลจากระยะไกล และตรวจสอบแอปพลิเคชันที่ติดตั้งไว้ได้ ผู้รับจ้างส่วนใหญ่จะปฏิเสธ เนื่องจากอุปกรณ์ของพวกเขาเป็นทรัพย์สินส่วนตัว และพวกเขาใช้อุปกรณ์ดังกล่าวเพื่อทำธุรกรรมธนาคาร ส่งอีเมลส่วนตัว และเก็บภาพถ่ายครอบครัว การขอให้ผู้รับจ้างลงทะเบียนในระบบ MDM จะก่อให้เกิดปัญหาทางกฎหมาย ความกังวลเกี่ยวกับความเป็นส่วนตัว และความล่าช้าในการเริ่มงานเป็นเวลาหลายวันหรือหลายสัปดาห์

ระบบควบคุมผ่านเบราว์เซอร์ (CASB + RBI + SWG + ZTNA): ไม่ต้องการเอเจนต์ ไม่จำเป็นต้องลงทะเบียนอุปกรณ์ และไม่จำเป็นต้องขยายโครงสร้างพื้นฐาน ผู้รับจ้างเพียงเปิดเบราว์เซอร์ ทำการยืนยันตัวตนผ่าน IdP ของคุณ และนโยบายความปลอดภัยจะถูกบังคับใช้ที่ชั้นเซสชัน เวลาในการลงทะเบียนลดลงจากหลายวันเหลือเพียงไม่กี่นาที ตลาดความปลอดภัย BYOD สะท้อนถึงการเปลี่ยนแปลงนี้: มูลค่าตลาดอยู่ที่ 60.64 พันล้านดอลลาร์ในปี 2025 และคาดว่าจะเพิ่มขึ้นถึง 120.36 พันล้านดอลลาร์ภายในปี 2032 ด้วยอัตราการเติบโตเฉลี่ยต่อปี (CAGR) 10.28% (GII Research, 2026)

ตาราง 2: VDI เทียบกับ MDM เทียบกับระบบควบคุมผ่านเบราว์เซอร์

จุดบูรณาการ: การทำให้ระบบความปลอดภัยของเบราว์เซอร์ทำงานร่วมกับระบบที่มีอยู่ของคุณ

ระบบควบคุม BYOD ที่ทำงานผ่านเบราว์เซอร์ไม่ทำงานแบบแยกตัว แต่คุณค่าของมันจะเพิ่มขึ้นหลายเท่าเมื่อผสานรวมกับโครงสร้างพื้นฐานด้านความปลอดภัยที่มีอยู่ของคุณ

IdP และการเข้าถึงแบบมีเงื่อนไข: IdP ของคุณ (Azure AD, Okta, Ping) ทำหน้าที่เป็นผู้ควบคุมการเข้าถึง ให้กำหนดนโยบายการเข้าถึงแบบมีเงื่อนไขเพื่อตรวจจับอุปกรณ์ที่ไม่ได้จัดการ — โดยทั่วไปจะตรวจพบจากการไม่มีใบรับรองลูกค้าหรือสัญญาณการปฏิบัติตามข้อกำหนด — และส่งเซสชันเหล่านั้นผ่านพร็อกซีแบบย้อนกลับของ CASB หรือ RBI โดยอัตโนมัติ เมื่อผู้รับจ้างเข้าสู่ระบบ SharePoint จากอุปกรณ์ที่ไม่ได้ลงทะเบียน IdP ควรบังคับใช้เส้นทางการเข้าถึงที่เข้มงวดขึ้นโดยอัตโนมัติโดยไม่ต้องมีการแทรกแซงด้วยมือ

การรวมนโยบาย DLP: นโยบาย DLP ที่ใช้เพื่อปกป้องข้อมูลบนอุปกรณ์ปลายทางที่ได้รับการจัดการควรขยายไปครอบคลุมเซสชันเบราว์เซอร์จากอุปกรณ์ที่ไม่ได้รับการจัดการด้วย หากนโยบาย DLP ของคุณห้ามการส่งออกข้อมูลลูกค้าแบบจำนวนมากสำหรับพนักงาน ก็ต้องห้ามการส่งออกดังกล่าวสำหรับผู้รับจ้างที่เข้าถึงผ่าน RBI ด้วย รายงาน "IBM Cost of a Data Breach Report (2024)" ได้วัดความเสี่ยงนี้: ค่าใช้จ่ายเฉลี่ยทั่วโลกจากการรั่วไหลข้อมูลในปี 2024 อยู่ที่ 4.88 ล้านดอลลาร์ — เพิ่มขึ้น 10% เมื่อเทียบกับปีก่อน ซึ่งเป็นการเพิ่มขึ้นสูงสุดนับตั้งแต่การระบาดของโรคโควิด-19 การบังคับใช้นโยบาย DLP อย่างสม่ำเสมอทั้งในการเข้าถึงที่ได้รับการจัดการและที่ไม่ได้จัดการ จะช่วยลดโอกาสที่องค์กรจะกลายเป็นส่วนหนึ่งของสถิติดังกล่าว

การบูรณาการ SIEM และ UEBA: ส่งบันทึกเซสชันจาก CASB, RBI และ ZTNA เข้าสู่ SIEM ของคุณ เพื่อสร้างค่าพื้นฐานด้านพฤติกรรมสำหรับกิจกรรมของผู้รับจ้าง หากผู้รับจ้างที่ปกติเข้าถึงข้อมูล Salesforce 20 รายการต่อวัน แต่忽然ส่งออกข้อมูล 2,000 รายการ ความผิดปกตินี้ควรกระตุ้นให้เกิดการแจ้งเตือน การมองเห็นและวิเคราะห์เป็นหนึ่งในสามความสามารถที่ตัดข้ามในแบบจำลองความพร้อม Zero Trust ของ CISA และข้อมูลเทเลเมทรีระดับเซสชันจากระบบควบคุมเบราว์เซอร์เป็นการนำไปใช้ในทางปฏิบัติของความสามารถดังกล่าว

การอัตโนมัติในการยกเลิกการจ้างงาน: เมื่อสัญญาจ้างผู้รับจ้างสิ้นสุดลง ให้ปิดใช้งานข้อมูลประจำตัว IdP ของผู้รับจ้าง เนื่องจากสิทธิ์การเข้าถึงเป็นแบบเซสชันและถูกบังคับใช้ที่ชั้นพร็อกซีหรือชั้น RBI จึงไม่มีใบรับรอง VPN ที่ต้องเพิกถอน ไม่มีเอเจนต์ที่จุดปลายที่ต้องถอนการติดตั้ง และไม่มีโปรไฟล์อุปกรณ์ที่ต้องลบ สิทธิ์การเข้าถึงจะหยุดทำงานโดยอัตโนมัติ

ตัวชี้วัดและเกณฑ์ความสำเร็จ

วัดสิ่งที่สำคัญ ตัวชี้วัดเหล่านี้แสดงให้เห็นว่าระบบควบคุมการเข้าถึงแบบ BYOD บนเบราว์เซอร์และสำหรับผู้รับจ้างของคุณทำงานได้อย่างมีประสิทธิภาพหรือไม่ และช่วยพิสูจน์ว่าการลงทุนต่อไปนั้นคุ้มค่า

ตัวชี้วัดการดำเนินงาน:

เวลาเฉลี่ยที่ผู้รับจ้างสามารถเข้าถึงระบบได้: ตั้งแต่การจัดเตรียมข้อมูลประจำตัวจนถึงเซสชันการทำงานครั้งแรกที่มีผลผลิต เป้าหมาย: น้อยกว่า 30 นาที หากคุณวัดเวลานี้เป็นวัน กระบวนการนี้จำเป็นต้องปรับปรุง

ปริมาณเซสชันของอุปกรณ์ที่ไม่ได้รับการจัดการ: จำนวนเซสชันรวมต่อสัปดาห์จากอุปกรณ์ที่จัดประเภทเป็นอุปกรณ์ที่ไม่ได้รับการจัดการ คาดว่าจะมีการเพิ่มขึ้นตามการขยายตัวของการใช้งาน; ส่วนการลดลงในขณะที่จำนวนพนักงานผู้รับจ้างยังคงคงที่ อาจบ่งชี้ว่ามีการใช้ระบบแบบบายพาส

อัตราการละเมิดนโยบาย: จำนวนการกระทำที่ถูกบล็อก (การดาวน์โหลด การคัดลอกและวาง การเข้าถึงแอปโดยไม่ได้รับอนุญาต) ต่อ 1,000 เซสชัน อัตราที่สูงอย่างต่อเนื่องอาจบ่งชี้ว่านโยบายมีข้อจำกัดมากเกินไป หรือการสื่อสารกับผู้ใช้ยังไม่เพียงพอ

ตัวชี้วัดด้านความปลอดภัย:

ไม่มีเหตุการณ์ข้อมูลรั่วไหล: จำนวนเหตุการณ์ข้อมูลถูกเปิดเผยที่สามารถติดตามได้ถึงอุปกรณ์ที่ไม่ได้จัดการอย่างเหมาะสม เป้าหมายคือศูนย์สำหรับเซสชันที่ได้รับการปกป้องโดย RBI

อัตราตรวจพบ Shadow SaaS: จำนวนแอปพลิเคชัน SaaS ที่ไม่ได้รับอนุญาต ซึ่งถูกเข้าถึงโดยอุปกรณ์ที่ไม่ได้รับการจัดการ ตามที่ CASB ตรวจพบ ตัวชี้วัดนี้ควรลดลงตามเวลา เมื่อคุณปรับนโยบาย SWG ให้เข้มงวดขึ้น

เหตุการณ์การขโมยข้อมูลรับรองจากอุปกรณ์ที่ไม่ได้รับการจัดการ: การโจมตีที่ใช้ข้อมูลรับรองคิดเป็น 16% ของการละเมิดข้อมูลทั้งหมด และใช้เวลานานที่สุดในการตรวจพบและควบคุมการแพร่กระจาย โดยใช้เวลาเกือบ 292 วัน (IBM, 2024) ระบบแยกเซสชันของ RBI ควรช่วยลดการขโมยข้อมูลรับรองจากการโจมตีผ่านเบราว์เซอร์ให้เหลือเกือบเป็นศูนย์

ตัวชี้วัดค่าใช้จ่าย:

ค่าใช้จ่ายต่อการเข้าถึงของผู้รับจ้าง: เปรียบเทียบค่าใช้จ่ายรวมในการออกใบอนุญาต SSE สำหรับเซสชันของอุปกรณ์ที่ไม่ได้รับการจัดการ กับค่าใช้จ่าย VDI ที่เทียบเท่า ความแตกต่างนี้คือเหตุผลที่สนับสนุนการต่อสัญญา

จำนวนตั๋วสนับสนุนสำหรับสิทธิ์การเข้าถึงของผู้รับจ้าง: ระบบควบคุมผ่านเบราว์เซอร์ควรสร้างตั๋วสนับสนุนน้อยกว่า VDI หรือ MDM เนื่องจากไม่มีซอฟต์แวร์ฝั่งลูกค้าที่ต้องแก้ไขปัญหา

ข้อผิดพลาดที่พบบ่อย

การปฏิบัติต่ออุปกรณ์ที่ไม่ได้รับการจัดการทั้งหมดอย่างเท่าเทียมกัน ผู้รับจ้างที่เข้าถึงเอกสารโครงการที่ไม่มีความละเอียดอ่อน ไม่จำเป็นต้องมีมาตรการควบคุมที่เหมือนกับผู้ที่จัดการข้อมูลส่วนบุคคลของลูกค้า (PII) การใช้ RBI กับทุกเซสชันอย่างไม่เหมาะสมจะเพิ่มค่าใช้จ่ายและเวลาตอบสนอง ใช้การแบ่งระดับตามความเสี่ยง: ใช้ CASB proxy สำหรับแอปพลิเคชันที่มีความละเอียดอ่อนต่ำ และใช้ RBI สำหรับแอปพลิเคชันที่มีความละเอียดอ่อนสูง

การลืมข้อมูลที่กำลังถูกส่งผ่านระหว่างแอปต่างๆ คุณได้ล็อกการเข้าถึง Salesforce ด้วย RBI แล้ว แต่ผู้รับจ้างยังสามารถคัดลอกชื่อลูกค้าจาก Salesforce วางลงในเครื่องมือ AI สร้างเนื้อหาในแท็บข้างเคียง และได้รับคำตอบที่รวมข้อมูลที่ได้รับการเสริมเติมได้ จับคู่ RBI กับนโยบาย SWG ที่จำกัดการเข้าถึงเครื่องมือ AI สร้างเนื้อหาจากเซสชันอุปกรณ์ที่ไม่ได้รับการจัดการ — หรือกำหนดให้การเข้าถึงเครื่องมือ AI ผ่านการแยกส่วนด้วย Skyhigh ได้ระบุมาตรการควบคุมเพิ่มเติมสำหรับสถานการณ์นี้ในคู่มือเกี่ยวกับการปกป้องแอปคลาวด์จากอุปกรณ์ที่ไม่ได้รับการจัดการ

การข้ามขั้นตอนการออกจากระบบ การจัดสรรสิทธิ์การใช้งานได้รับความสนใจทั้งหมด ส่วนการยกเลิกสิทธิ์การใช้งานได้รับเพียงกระดาษโน้ตติดไว้เท่านั้น ให้ระบบ HR หรือระบบจัดซื้อจัดจ้างของคุณทำงานอัตโนมัติในการทริกเกอร์ขั้นตอนการออกจากระบบที่เชื่อมโยงกับวันที่สิ้นสุดสัญญา ผู้รับจ้างที่ยังคงมีสิทธิ์เข้าถึงระบบสามเดือนหลังจากโครงการสิ้นสุดลง ถือเป็นภัยคุกคามจากภายใน ไม่ว่าเขาจะมีเจตนาหรือไม่ก็ตาม

การเพิกเฉยต่อการสื่อสารกับผู้ใช้ ผู้รับจ้างที่ใช้งาน RBI เป็นครั้งแรกอาจรายงานว่า “แอปพลิเคชันนี้รู้สึกแตกต่าง” หรือว่าการคัดลอกและวางไม่ทำงาน หากไม่มีการสื่อสารเชิงรุกเพื่ออธิบายว่าทำไมจึงมีมาตรการควบคุมเหล่านี้ และพฤติกรรมใดที่ถูกจำกัด คุณจะพบวิธีการหลีกเลี่ยงอย่างลับๆ — เช่น ผู้รับจ้างส่งข้อมูลผ่านอีเมลไปยังบัญชีส่วนตัวเพื่อหลีกเลี่ยงข้อจำกัดในการดาวน์โหลด

การติดตั้งระบบควบคุมเบราว์เซอร์โดยไม่ใช้ DLP การแยกเบราว์เซอร์data loss prevention ประตูที่ล็อกไว้แต่หน้าต่างยังเปิดอยู่ RBI ป้องกันไม่ให้ข้อมูลเข้าถึงอุปกรณ์ แต่ DLP รับประกันว่าข้อมูลภายในเซสชันไม่สามารถถูกนำออกผ่านช่องทางที่ได้รับอนุญาตได้ — เช่น การอัปโหลดไปยังบัญชีเก็บข้อมูลบนคลาวด์ส่วนตัว การส่งอีเมลไปยังที่อยู่อีเมลที่ไม่ใช่ของบริษัท หรือการพิมพ์เป็นไฟล์ PDF ในเครื่อง IBM พบว่า 35% ของการละเมิดข้อมูลเกี่ยวข้องกับข้อมูลเงา (shadow data) — ข้อมูลที่เก็บไว้ในแหล่งข้อมูลที่ไม่ได้จัดการ (IBM, 2024) — ซึ่งเน้นย้ำว่าการเคลื่อนย้ายข้อมูลที่ไม่ได้ควบคุมก่อให้เกิดค่าใช้จ่ายและความเสี่ยง

สมมติว่าโมเดลการปรับใช้แบบเดียวสามารถใช้ได้กับทุกกรณี บางกลุ่มผู้ใช้อาจได้รับประโยชน์จากส่วนขยายเบราว์เซอร์แบบเบาบนอุปกรณ์ที่ได้รับการจัดการ ในขณะที่ผู้รับจ้างอาจใช้ RBI แบบไม่มีเอเจนต์ ควรปรับการควบคุมให้สอดคล้องกับสถานะของอุปกรณ์และประเภทผู้ใช้ แทนที่จะบังคับใช้วิธีการเดียวสำหรับพนักงานทั้งหมด