คุณค้นหา Chrome Remote Desktop และพบวลี “ความเสี่ยงด้านความปลอดภัย” แนบมาด้วย นั่นเป็นคำถามที่ยุติธรรมและสมควรได้รับคำตอบที่ชัดเจน แทนที่จะให้ความมั่นใจที่คลุมเครือหรือรายการคำเตือนโดยไม่มีบริบทใดๆ
บทความนี้ครอบคลุมถึงข้อกังวลด้านความปลอดภัยเดสก์ท็อประยะไกลของ Chrome ที่เกิดขึ้นจริง: เครื่องมือใดที่ป้องกันได้ดี ช่องว่างที่แท้จริงอยู่ที่ไหน และขั้นตอนที่เป็นรูปธรรมที่จะปิดช่องว่างเหล่านี้ ไม่ว่าจะเป็นผู้ใช้ตามบ้านหรือผู้เชี่ยวชาญด้านไอที ความเสี่ยงก็เหมือนกัน เงินเดิมพันต่างกัน
Chrome Remote Desktop ปลอดภัยแค่ไหน?
Chrome Remote Desktop ได้รับการดูแลภายใต้มาตรฐานโครงสร้างพื้นฐานของ Google และการป้องกันเริ่มต้นนั้นเป็นของจริงแทนที่จะเป็นเพียงความสวยงาม ข้อบกพร่องด้านความปลอดภัยเดสก์ท็อประยะไกลของ Chrome ที่ผู้ใช้ส่วนใหญ่พบไม่ได้อยู่ในเลเยอร์การเข้ารหัส มันอยู่ในการกำหนดค่าบัญชีและการตั้งค่าเครือข่าย
การเรียกใช้การตรวจสอบความปลอดภัยของเดสก์ท็อประยะไกลของ Chrome หมายถึงการตรวจสอบทั้งสิ่งที่จัดส่งตามค่าเริ่มต้นและสิ่งที่คุณกำหนดค่าในภายหลัง จุดแข็งของเครื่องมือควรได้รับการตรวจสอบอย่างยุติธรรมก่อนที่ช่องว่างจะเข้ามาโฟกัส เนื่องจากการละเลยออกไปทันทีจะนำไปสู่การตัดสินใจที่ไม่ดีในทั้งสองทิศทาง
การเข้ารหัส: TLS/SSL และ AES
การส่ง CRD ทุกครั้งจะทำงานผ่านอุโมงค์ที่เข้ารหัส TLS/SSL โดยมีการเข้ารหัส AES ซ้อนกันอยู่ด้านบน ข้อมูลที่ย้ายระหว่างอุปกรณ์ของคุณและเครื่องระยะไกลไม่สามารถอ่านโดยบุคคลที่สามในระหว่างการขนส่ง รวมถึงผู้ให้บริการเครือข่ายหรือ ISP ของคุณ
PIN และรหัสแบบครั้งเดียวได้รับการยืนยันฝั่งไคลเอ็นต์และไม่เคยส่งไปยังเซิร์ฟเวอร์ของ Google ในรูปแบบที่อ่านได้ เนื้อหาเซสชันเดินทางผ่าน เส้นทางตรง, STUN หรือ TURN/รีเลย์ ขึ้นอยู่กับสภาพเครือข่าย เซสชันเดสก์ท็อประยะไกลทั้งหมดได้รับการเข้ารหัสอย่างสมบูรณ์ ในทั้งสามโหมด ตามเอกสารของ Google
สำหรับการใช้งานส่วนตัวบนเครือข่ายที่เชื่อถือได้ ความปลอดภัยของ Chrome Remote Desktop เป็นไปตามมาตรฐานการเข้ารหัสเดียวกันกับที่ใช้ในธุรกรรมทางการเงินออนไลน์ ผู้ใช้ส่วนใหญ่ประเมินค่าพื้นฐานนี้ต่ำเกินไปก่อนที่ช่องว่างการกำหนดค่าจะเริ่มมีความสำคัญ
การตรวจสอบบัญชี Google และการยืนยันแบบสองปัจจัย
การเข้าถึง CRD จำเป็นต้องมีบัญชี Google ที่ใช้งานอยู่และได้รับการรับรองความถูกต้องซึ่งได้รับการสนับสนุนโดยการป้องกันแบบ brute-force การตรวจจับการเข้าสู่ระบบที่น่าสงสัย และการแจ้งเตือนการครอบครองบัญชีในระดับแพลตฟอร์ม รากฐานการตรวจสอบความถูกต้องนี้มีความแข็งแกร่งอย่างแท้จริง โดยแยก CRD ออกจากเครื่องมือที่ใช้รหัสผ่านแบบสแตนด์อโลนเพียงอย่างเดียว
การเปิดใช้งานการยืนยันแบบ 2 ขั้นตอนช่วยลดความเสี่ยงของการครอบครองบัญชีด้วยรหัสผ่านในการใช้งาน CRD ใดๆ ลงอย่างมาก โดยจะไม่ลบภัยคุกคามหลังการรับรองความถูกต้อง เช่น โทเค็นเซสชันที่ถูกขโมย ดังนั้นจึงทำงานได้ดีที่สุดในฐานะเลเยอร์เดียวในแนวทางการขยายการเข้าถึงที่กว้างขึ้น
ชิ้นของเราบน Chrome Remote Desktop คืออะไร? อธิบายโมเดลการเข้าถึงแบบเต็มและขั้นตอนการตั้งค่าอย่างละเอียด ข้อกังวลด้านความปลอดภัยของเดสก์ท็อประยะไกลของ Chrome จะมีความเฉพาะเจาะจงมากขึ้นเมื่อคุณเข้าใจวิธีการทำงานของชั้นบัญชี และนั่นคือจุดเริ่มต้นของส่วนถัดไป
ความเสี่ยงด้านความปลอดภัยของ Chrome Remote Desktop
ข้อกังวลด้านความปลอดภัยของ Chrome Remote Desktop จะเชื่อมโยงโดยตรงกับรูปแบบการละเมิดที่ได้รับการบันทึกไว้ทั่วทั้งอุตสาหกรรม ตามที่ รายงาน Adversary ที่ใช้งานอยู่ของ Sophos สำหรับครึ่งแรกของปี 2024อาชญากรไซเบอร์ใช้ Remote Desktop Protocol ในทางที่ผิดใน 90% ของการโจมตีที่จัดการโดยการตอบสนองเหตุการณ์ของ Sophos ในปี 2566
บริการระยะไกลภายนอกทำหน้าที่เป็นวิธีการเข้าถึงเบื้องต้นอันดับต้นๆ ใน 65% ของกรณีเหล่านั้น จากการสอบสวนมากกว่า 150 รายการใน 23 ประเทศ ตัวเลขเหล่านี้ครอบคลุมถึงเครื่องมือเดสก์ท็อประยะไกลในวงกว้าง ส่วนด้านล่างระบุว่ารูปแบบเหล่านั้นใช้กับ CRD โดยเฉพาะที่ใด
ข้อกังวลด้านความเป็นส่วนตัว
CRD ถูกฝังอยู่ในระบบนิเวศของบัญชี Google การประทับเวลาการเชื่อมต่อ ตัวระบุอุปกรณ์ และความถี่ในการเข้าถึงล้วนเชื่อมโยงกับบัญชีนั้น ปัญหาด้านความปลอดภัยเดสก์ท็อประยะไกลของ Google Chrome มีโครงสร้างดังนี้ โมเดลข้อมูลประจำตัวทั้งหมดของเครื่องมืออยู่ในบัญชี Google บัญชีเดียว
บัญชีที่ถูกบุกรุกผ่านฟิชชิ่งหรือจี้โทเค็นของเบราว์เซอร์ช่วยให้ผู้โจมตีมองเห็นอุปกรณ์ระยะไกลทั้งหมดที่ลงทะเบียนได้โดยตรง นี่ไม่ใช่การละเมิดการเข้าถึงระยะไกลแบบสแตนด์อโลน เป็นการบุกรุกบัญชี Google โดยสมบูรณ์ ซึ่งหมายความว่าความเสี่ยงจะขยายไปยังบริการ เอกสาร และผู้ติดต่อที่เชื่อมโยงทั้งหมดที่จัดเก็บไว้ในบัญชีนั้น
ช่องโหว่ WiFi สาธารณะ
Chrome Remote Desktop ใช้ WebRTC สำหรับเส้นทางการเชื่อมต่อ โดยมีการเจรจาเบื้องต้นจัดการผ่านบริการของ Google ก่อนที่จะสร้างเซสชัน Direct, STUN หรือ TURN/relay บนเครือข่ายที่ไม่น่าเชื่อถือหรือสาธารณะ การกำหนดเส้นทางการรับส่งข้อมูลและเงื่อนไขการมองเห็นเครือข่ายทำให้เกิดความเสี่ยงที่เครือข่ายส่วนตัวที่ได้รับการควบคุมจะไม่ทำ
เงื่อนไขเหล่านั้นมีความสำคัญเนื่องจากสภาพแวดล้อม WiFi สาธารณะอยู่นอกเหนือการควบคุมของคุณ การใช้ CRD โดยไม่มีข้อควรระวังเพิ่มเติมบนเครือข่ายที่ใช้ร่วมกันจะขยายขอบเขตการเข้าถึงของคุณให้เกินกว่าที่ชั้นการเข้ารหัสเพียงอย่างเดียวจะครอบคลุม
VPN สามารถลดความเสี่ยงในเครือข่ายที่ไม่น่าเชื่อถือได้ แต่เป็นเลเยอร์เพิ่มเติม ไม่ใช่วิธีแก้ปัญหาสำหรับความเสี่ยงที่เกี่ยวข้องกับ CRD ทั้งหมด
ปัญหาไฟร์วอลล์และความเข้ากันได้
เราเตอร์ที่บ้านส่วนใหญ่จะผ่านการรับส่งข้อมูล CRD โดยไม่มีการกำหนดค่าใดๆ เครือข่ายองค์กรที่ใช้ Deep Packet Inspection สามารถตั้งค่าสถานะองค์ประกอบการส่งสัญญาณ WebRTC และปล่อยโดยไม่ต้องแจ้งให้ผู้ใช้ทราบ บนเครือข่ายที่มีข้อจำกัด ผู้ดูแลระบบอาจต้องอนุญาต Chrome Remote Desktop URL บริการพร้อมการรับส่งข้อมูลบน TCP/UDP 443 และ 3478.
จากมุมมองของผู้ใช้ การเชื่อมต่อล้มเหลว โดยไม่มีข้อความแสดงข้อผิดพลาดชี้ไปที่สาเหตุที่แท้จริง ฉันได้ติดตามรูปแบบความล้มเหลวนี้ในสภาพแวดล้อมขององค์กร มีการวินิจฉัยผิดพลาดอย่างต่อเนื่องว่าเป็นข้อบกพร่องของแอปพลิเคชัน CRD แทนที่จะเป็นข้อขัดแย้งของนโยบายไฟร์วอลล์
หากข้อผิดพลาดใบรับรอง SSL ปรากฏขึ้นบนเครือข่ายเดียวกัน วิธีแก้ไขข้อความ HTTPS ไม่ปลอดภัยใน Chrome ครอบคลุมการแก้ไขปัญหาระดับพอร์ตที่เกี่ยวข้องซึ่งใช้ในสภาพแวดล้อมไฟร์วอลล์เดียวกัน และมักจะแก้ไขปัญหาทั้งสองปัญหาได้ในคราวเดียว
ข้อมูลรับรองที่อาจอ่อนแอ
PIN ขั้นต่ำของ CRD คือตัวเลขหกหลัก เกณฑ์ดังกล่าวไม่เพียงพอสำหรับสิ่งใดๆ นอกเหนือจากการใช้งานส่วนตัวทั่วไป ผู้ใช้ส่วนใหญ่เลือกรูปแบบที่คาดเดาได้ ซึ่งจะทำให้พื้นที่การค้นหาในทางปฏิบัติพังทลายลง และทำให้ความพยายามแบบเดรัจฉานมีประสิทธิภาพมากกว่าการนับตัวเลขที่แนะนำ
การใช้รหัสผ่านซ้ำในระดับบัญชี Google จะทำให้เกิดสิ่งนี้ การละเมิดบริการที่ไม่เกี่ยวข้องสามารถมอบข้อมูลรับรองที่ผ่านการทดสอบแก่ผู้โจมตีเพื่อนำไปใช้กับบัญชี Google ที่เกตการเข้าถึงอุปกรณ์ CRD ที่ลงทะเบียนทั้งหมด
ตามที่ IBM ต้นทุนของรายงานการละเมิดข้อมูลปี 2024ข้อมูลประจำตัวที่ถูกขโมยถือเป็นเวกเตอร์การโจมตีครั้งแรกอันดับต้นๆ ในปี 2024 โดยคิดเป็น 16% ของการละเมิดที่ได้รับการวิเคราะห์ทั้งหมดในองค์กร 604 แห่งที่ทำการศึกษาใน 12 แห่ง
การละเมิดข้อมูลประจำตัวเหล่านี้ใช้เวลาเฉลี่ย 292 วันในการตรวจจับและกักกัน ซึ่งเป็นวงจรชีวิตที่ยาวนานที่สุดในบรรดาการโจมตีทุกประเภทในการศึกษานี้ ความเสี่ยงด้านความปลอดภัยบนเดสก์ท็อประยะไกลของ Chrome ที่เกี่ยวข้องกับข้อมูลประจำตัวที่ไม่รัดกุมเป็นไปตามรูปแบบในทางปฏิบัตินี้
ข้อเสียของ Chrome Remote Desktop
ทั้งหมดที่กล่าวมา ข้อกังวลด้านความปลอดภัยเดสก์ท็อประยะไกลของ Google ขยายไปไกลกว่าภัยคุกคามที่ทำงานอยู่ CRD ถูกสร้างขึ้นเพื่อการใช้งานส่วนบุคคลและการสนับสนุนระยะไกลขั้นพื้นฐาน ข้อจำกัดด้านล่างนี้เป็นเพียงตัวเลือกการออกแบบโดยเจตนา และกลายเป็นปัจจัยในการตัดสินใจสำหรับการใช้งานระดับมืออาชีพ
ไม่มีการควบคุมระดับองค์กร
สำหรับการปรับใช้ CRD มาตรฐานบน Windows, Mac หรือ Linux จะไม่มีการบันทึกการเชื่อมต่อและไม่มีการควบคุมการเข้าถึงตามบทบาท สภาพแวดล้อม ChromeOS ที่มีการจัดการมีให้ การเข้าถึงคอนโซลผู้ดูแลระบบและการบันทึกการตรวจสอบระดับเซสชัน ผ่าน Chrome Enterprise แต่ไม่มีการควบคุมเหล่านั้นอยู่นอกบริบทที่ได้รับการจัดการนั้น
เราพบว่านี่คือจุดที่ผู้ประเมินด้านไอทีตัดสิทธิ์ CRD สำหรับการใช้งานในองค์กรอย่างต่อเนื่อง การเชื่อมต่อที่ไม่ได้บันทึกเข้ากับข้อมูลที่ได้รับการควบคุมเพียงครั้งเดียวสามารถแสดงถึงความล้มเหลวในการปฏิบัติตามกฎระเบียบโดยไม่มีเส้นทางการแก้ไข แม้ว่าจะมีขั้นตอนการทำให้แข็งอื่นๆ ทุกขั้นตอนก็ตาม
การพึ่งพาบัญชีและขีดจำกัดประสิทธิภาพ
หากบัญชี Google ที่เชื่อมโยงกับ CRD ไม่สามารถเข้าถึงได้ การเข้าถึงระยะไกลอาจถูกรบกวนได้ ดังนั้นจึงเป็นความคิดที่ไม่ดีที่จะทำให้บัญชีผู้ใช้ทั่วไปหนึ่งบัญชีเป็นเส้นทางเดียวของคุณสู่เครื่องที่สำคัญ การประเมินการพึ่งพานี้ก่อนที่จะปรับใช้เป็นสิ่งที่ต้องรู้สำหรับทีมที่ใช้ CRD บนระบบการผลิตหรือระบบที่มีความสำคัญต่อธุรกิจ
รหัสการเข้าถึงการสนับสนุนเป็นรหัสแบบใช้ครั้งเดียว และในระหว่างเซสชั่นการแชร์สด โฮสต์จะถูกขอให้ยืนยันการแชร์ต่อทุก ๆ 30 นาที การโอนไฟล์ใช้งานได้ในเซสชันระยะไกลของ ChromeOS ที่มีการจัดการ แต่ไม่มีในการปรับใช้ Windows, Mac และ Linux มาตรฐาน
นอกเหนือจากช่องว่างด้านฟีเจอร์แล้ว พื้นที่หน่วยความจำของ Chrome รวมกับการเชื่อมต่อระยะไกลที่ใช้งานได้ยังสร้างภาระที่วัดได้บนฮาร์ดแวร์โฮสต์ ซึ่งทำให้ประสิทธิภาพในเครื่องรุ่นเก่าลดลงในทางปฏิบัติ
สำหรับการพัฒนา การจัดการเซิร์ฟเวอร์ หรือเวิร์กโฟลว์ระดับมืออาชีพโดยเฉพาะ เซิร์ฟเวอร์ RDP ขจัดข้อจำกัดเหล่านี้ ที่ Cloudzy เซิร์ฟเวอร์ของเราทำงานบนโปรเซสเซอร์ AMD Ryzen 9 ที่ความเร็ว 4.2+ GHz พร้อมเครือข่ายสูงสุด 40 Gbps และ SLA ความพร้อมในการทำงาน 99.95%
Chrome Remote Desktop กับเซิร์ฟเวอร์ Cloudzy RDP
| คุณสมบัติ | Chrome เดสก์ท็อประยะไกล | เซิร์ฟเวอร์ Cloudzy RDP |
| ความเร็วเครือข่าย | ตัวแปรการกำหนดเส้นทาง WebRTC | ทุ่มเทสูงสุด 40 Gbps |
| โปรเซสเซอร์ | ขึ้นอยู่กับฮาร์ดแวร์ของโฮสต์ | AMD Ryzen 9, เพิ่มความเร็ว 4.2+ GHz |
| การป้องกัน DDoS | ไม่มี | การป้องกัน FreeDDoS |
| โปรโตคอล | WebRTC ผ่าน HTTPS | RDP บนอินสแตนซ์ที่แยก KVM |
| บันทึกการตรวจสอบ | ไม่สามารถใช้ได้ | การบันทึกเหตุการณ์การเชื่อมต่อระดับระบบปฏิบัติการผ่าน Windows Event Viewer |
| SLA สถานะการออนไลน์ | ไม่มี | 99.95% |
| การถ่ายโอนไฟล์ | จำกัด; ใช้ได้เฉพาะใน ChromeOS ที่มีการจัดการเท่านั้น | รองรับ RDP ดั้งเดิม |
| การพึ่งพาบัญชี | บัญชี Google บัญชีเดียว | ข้อมูลรับรอง Windows อิสระ |
Google Remote Desktop ปลอดภัยหรือไม่
“Google Remote Desktop” และ “Chrome Remote Desktop” เป็นผลิตภัณฑ์เดียวกัน ซึ่งเป็นสาเหตุที่ข้อกังวลด้านความปลอดภัยของ Google Remote Desktop และปัญหาด้านความปลอดภัยของ Google Remote Desktop ปรากฏภายใต้ชื่อทั้งสองในฟอรัมและเอกสารประกอบของผลิตภัณฑ์ สถาปัตยกรรม ความเสี่ยง และขั้นตอนการชุบแข็งจะเหมือนกัน
Google Remote Desktop มีความปลอดภัยสำหรับการใช้งานส่วนตัวเมื่อมีการกำหนดค่าอย่างเหมาะสม การเข้ารหัส TLS/SSL และ AES เป็นไปตามมาตรฐานอุตสาหกรรม เมื่อเปิดใช้งาน 2FA เลเยอร์การรับรองความถูกต้องจะจัดการประเภทภัยคุกคามที่พบบ่อยที่สุดโดยกำหนดเป้าหมายไปที่การใช้งานส่วนบุคคลและทีมขนาดเล็ก
สำหรับทีมที่มีข้อกำหนดด้านการปฏิบัติตามข้อกำหนด แนวทางการตรวจสอบ หรือความต้องการด้านความซ้ำซ้อนในการเข้าถึง CRD ถือเป็นเครื่องมือแบบสแตนด์อโลน ความเสี่ยงด้านความปลอดภัยเดสก์ท็อประยะไกลของ Google จะเพิ่มขึ้นตามความละเอียดอ่อนของระบบที่มีการเข้าถึงและจำนวนผู้ใช้ที่เกี่ยวข้อง
จะทำให้ Chrome Remote Desktop ปลอดภัยยิ่งขึ้นได้อย่างไร
ความเสี่ยงด้านความปลอดภัยบนเดสก์ท็อประยะไกลของ Chrome ที่ระบุข้างต้นมีการแก้ไขโดยตรงตามรายการด้านล่าง ขั้นตอนต่างๆ เรียงลำดับตามการกระแทก ทำงานจากบนลงล่างเพื่อการอัปเกรดการตั้งค่าของคุณที่รวดเร็วและมีความหมายที่สุดโดยไม่มีค่าใช้จ่ายทางเทคนิคที่ไม่จำเป็น
เปิดใช้งานการยืนยันแบบสองขั้นตอนในบัญชี Google ของคุณ
เปิด myaccount.google.com เลือกความปลอดภัย จากนั้นเลือกการยืนยันแบบ 2 ขั้นตอน เลือกแอปตรวจสอบสิทธิ์หรือคีย์ความปลอดภัยของฮาร์ดแวร์เป็นปัจจัยที่สอง การดำเนินการเพียงครั้งเดียวนี้จะปิดประเภทการละเมิดข้อมูลประจำตัวที่ข้อมูล IBM 2024 แสดงโดยตรวจไม่พบโดยเฉลี่ย 292 วัน
คีย์ความปลอดภัยของฮาร์ดแวร์มีการป้องกันฟิชชิ่งที่แข็งแกร่งที่สุด แอปตรวจสอบสิทธิ์เป็นตัวเลือกที่ใช้งานได้จริงที่สุดสำหรับผู้ใช้ส่วนใหญ่ เราพบว่าทีมที่เปิดใช้งานขั้นตอนนี้ลดความเสี่ยงต่อการโจมตีตามข้อมูลประจำตัวได้อย่างมาก แม้ว่าภัยคุกคามหลังการตรวจสอบความถูกต้อง เช่น การขโมยคุกกี้เซสชัน ยังคงเป็นความเสี่ยงในการจัดการแยกต่างหาก
ตั้งค่า PIN ที่ยาวและซับซ้อน
ใช้อักขระอย่างน้อย 8 ตัว คละตัวอักษรและตัวเลข และหลีกเลี่ยงลำดับใดๆ ที่เชื่อมโยงกับข้อมูลส่วนบุคคล หากต้องการอัปเดต PIN ที่มีอยู่ ให้เปิด remotedesktop.google.com/access ค้นหาอุปกรณ์ในแผงอุปกรณ์ระยะไกล และเลือกไอคอนดินสอ
การหมุนเวียน PIN มีความสำคัญเป็นระยะ โดยเฉพาะอย่างยิ่งหลังจากการแชร์การเข้าถึงชั่วคราวหรือหลังจากที่บัญชี Google แสดงกิจกรรมการเข้าสู่ระบบที่น่าสงสัย PIN ที่เป็นตัวเลขสั้นๆ เป็นหนึ่งในจุดอ่อนที่มีการใช้ประโยชน์อย่างต่อเนื่องมากที่สุดในการปรับใช้ CRD ที่เราตรวจสอบ
ใช้ VPN บนเครือข่ายสาธารณะหรือเครือข่ายที่ใช้ร่วมกัน
เชื่อมต่อ VPN ของคุณก่อนเปิด CRD บนเครือข่ายใดๆ ที่คุณไม่ได้ควบคุมเป็นการส่วนตัว เลือกผู้ให้บริการที่มีนโยบายไม่บันทึกข้อมูลการใช้งานที่ได้รับการตรวจสอบแล้วและ Kill Switch ที่จะตัดการเข้าถึงอินเทอร์เน็ตหาก VPN หยุดทำงานโดยไม่คาดคิด และปิดหน้าต่างการเปิดเผยข้อมูลสั้นๆ
ผู้ใช้ส่วนใหญ่ที่ข้าม VPN บนเครือข่ายสาธารณะไม่เคยพบเหตุการณ์ที่มองเห็นได้ ซึ่งสร้างความรู้สึกผิด ๆ ว่าความเสี่ยงในชั้นเครือข่ายนั้นเป็นไปในทางทฤษฎีเท่านั้น ถือว่าขั้นตอน VPN ไม่สามารถต่อรองได้บนเครือข่ายย่อยที่แชร์ใดๆ
เปิดใช้งานโหมดม่านบน Windows
โหมดม่านจะบล็อกหน้าจอทางกายภาพของเครื่องโฮสต์ไม่ให้แสดงกิจกรรมระยะไกลระหว่างการเชื่อมต่อ CRD ที่ใช้งานอยู่ ทุกคนในโฮสต์จะเห็นเฉพาะหน้าจอที่ถูกล็อค ไม่ว่าผู้ใช้ระยะไกลจะทำอะไรก็ตาม ต้องใช้ Windows Professional, Ultimate, Enterprise หรือ Server
การตั้งค่าโหมดม่านแบบเต็มของ Google ต้องใช้คีย์รีจิสทรีสี่คีย์บน Windows ชุด RemoteAccessHostRequireCurtain ถึง 1 อันเดอร์ HKLM\ซอฟต์แวร์\นโยบาย\Google\Chrome, fDenyTSConnections ถึง 0 และ การตรวจสอบสิทธิ์ผู้ใช้ เป็น 0 ภายใต้เส้นทาง Terminal Server และบน Windows 10 ก็ตั้งค่าเช่นกัน SecurityLayer เป็น 1 ภายใต้เส้นทาง RDP-Tcp
Google เตือนว่าขั้นตอนที่พลาดจะทำให้เซสชันยุติทันที เมื่อตั้งค่าคีย์ทั้งหมดแล้ว ให้รีสตาร์ทบริการโฮสต์ CRD เพื่อใช้การเปลี่ยนแปลง
การตั้งค่านี้มีการใช้งานน้อยเกินไปในการปรับใช้สำนักงานที่ใช้ร่วมกัน และทีมไอทีส่วนใหญ่กำหนดค่าได้ภายในไม่ถึงห้านาที
อัปเดต Chrome ตลอดเวลา
CRD ทำงานบนโครงสร้างพื้นฐานของ Chrome ดังนั้นเบราว์เซอร์ที่ไม่ได้รับการติดตั้งจึงหมายถึงโฮสต์ CRD ที่ไม่ได้รับการติดตั้ง ในปี 2568 Chrome บันทึก CVE ที่เผยแพร่แล้ว 205 รายการ ที่คะแนน CVSS เฉลี่ย 7.9; ข้อบกพร่องในการเรียกใช้โค้ดจากระยะไกลหลายประการที่เกี่ยวข้องซึ่งส่งผลโดยตรงต่อโฮสต์ CRD ที่ใช้งานอยู่
เปิด Chrome ไปที่ความช่วยเหลือ จากนั้นเลือกเกี่ยวกับ Google Chrome และยืนยันสถานะเวอร์ชันปัจจุบัน Google แนะนำให้เปิดใช้งานการอัปเดตอัตโนมัติ ดังนั้นแพทช์รักษาความปลอดภัยจึงมีผลทันทีที่พร้อมใช้งาน การล่าช้าหรือการบล็อกการอัปเดต Chrome จะทำให้ช่องโหว่ที่ทราบเปิดอยู่บนโฮสต์ CRD ที่ใช้งานอยู่
บทสรุป
Chrome Remote Desktop มาพร้อมกับการป้องกันที่แท้จริง: การเข้ารหัส TLS/SSL, การเข้าถึงโดยใช้ PIN และโมเดลการตรวจสอบสิทธิ์ที่รองรับ 2FA สำหรับการใช้งานส่วนบุคคลโดยมีขั้นตอนที่เข้มงวดมากขึ้น นี่ถือเป็นตัวเลือกที่ดีสำหรับความต้องการการเข้าถึงระยะไกลทุกวันบนเครือข่ายที่เชื่อถือได้
ขีดจำกัดเชิงโครงสร้างคือโมเดลการเข้าถึงทั้งหมดขึ้นอยู่กับบัญชี Google บัญชีเดียว ไม่ว่าจะเป็นความสม่ำเสมอของประสิทธิภาพ การบันทึกการปฏิบัติตามข้อกำหนด หรือความน่าเชื่อถือของโครงสร้างพื้นฐาน ข้อกังวลด้านความปลอดภัยในการตั้งค่าระดับมืออาชีพมักจะชี้ไปที่โซลูชันเฉพาะเสมอ สำหรับทีมที่มี CRD มากเกินไป เซิร์ฟเวอร์ที่ใช้ KVM ของ Cloudzy มอบรากฐานที่เชื่อถือได้มากกว่า
เครื่องมือที่เหมาะสมขึ้นอยู่กับบริบทของคุณ CRD แก้ปัญหาการเข้าถึงส่วนบุคคลได้ดี เมื่อการปฏิบัติตามข้อกำหนด ความพร้อมใช้งาน หรือการเข้าถึงแบบหลายผู้ใช้เข้ามาในภาพ สถาปัตยกรรมจะต้องตรงกับเดิมพัน
