ส่งต่อ SSH, VPN หรือ RD Gateway: เส้นทางใดสำหรับเดสก์ท็อป RDP เครื่องเดียว?

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

คำถามคือขอบเขต ไม่ใช่โปรโตคอล

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

แยกตัวตนสำหรับเข้าออกจากบัญชี Windows ที่ลงชื่อเข้าเดสก์ท็อป การออกแบบทุกแบบด้านล่างมีทั้งสองอย่าง และการหลอมรวมทั้งสองคือหนทางที่บัญชีโฮสต์กระโดดได้อำนาจมากกว่าที่ใครตั้งใจ

บริการ TCP ที่ส่งต่อหนึ่งบริการ

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

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

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

พื้นที่ทำงานส่วนตัวที่กำหนดเส้นทาง

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

จำกัดเส้นทางและสิทธิ์ของทรัพยากรให้ตรงกับปลายทางที่ตั้งใจ ผู้ใช้ที่เชื่อมต่อไม่ได้รับ LAN ทั้งหมดโดยอัตโนมัติ และไฟร์วอลล์ปลายทางพร้อมสิทธิ์ลงชื่อเข้า Windows ยังคงเป็นขอบเขตแยกที่ VPN ไม่ได้แทนที่

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

เกตเวย์เฉพาะ RDP

Remote Desktop Gateway ให้ขอบเขตเฉพาะ RDP ไม่ใช่ขอบเขตเครือข่าย นโยบายอนุญาตการเชื่อมต่อตัดสินว่าใครเชื่อมต่อได้ และนโยบายอนุญาตทรัพยากรตัดสินว่าเข้าถึงทรัพยากรภายในใดได้ผ่านเกตเวย์นี้ นโยบายทั้งสองเป็นส่วนหนึ่งของผลิตภัณฑ์ ไม่ใช่ส่วนเสริมตามตัวเลือก

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

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

สิ่งที่ทั้งสามยังต้องการ

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

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

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