โครงสร้างพื้นฐาน OFFSHORE ส่วนตัว
การดำเนินงานวันที่สองใช้งานจริง · 6 นาทีในการอ่าน

การดูแลระบบ Windows RDP อย่างปลอดภัยโดยไม่สูญเสียการเข้าถึง

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

โดย SwissOctet Editorial
คำตอบตรงประเด็น

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

01

ถือว่าเดสก์ท็อปเป็นขอบเขตการดูแลระบบ

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

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

02

จำกัดการเข้าถึงได้ก่อนพึ่งพาการป้องกันด้วยการเข้าสู่ระบบ

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

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

03

ทำให้การยืนยันตัวตนและความเชื่อถือชัดเจน

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

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

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

ลดสิ่งที่เซสชันสามารถนำพาไปได้

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

สำหรับสภาพแวดล้อมที่ใช้โดเมนที่เหมาะสม Microsoft มี Remote Credential Guard เพื่อลดการเปิดเผยข้อมูลรับรองระหว่างการเชื่อมต่อ RDP โดยต้องใช้ไคลเอนต์ที่เข้ากันได้และการรับรองความถูกต้องด้วย Kerberos และรองรับการเชื่อมต่อโดยตรงกับเครื่องเป้าหมาย การเชื่อมต่อผ่าน Remote Desktop Gateway หรือ Connection Broker ไม่ได้รับการรองรับ ตรวจสอบข้อกำหนดสำหรับเส้นทางการเข้าถึงจริงของคุณ แทนที่จะถือว่าเป็นการป้องกันสากลสำหรับเครื่อง Windows แบบโฮสต์เดี่ยว

05

บำรุงรักษาเครื่องและหลักฐานที่คุณต้องการ

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

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

06

ลำดับเซสชันแรกที่ปลอดภัย

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

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

เปลี่ยนเป็น行動

รายการตรวจสอบปฏิบัติของคุณ

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

รายละเอียดที่สำคัญ

NLA ทำให้โฮสต์ RDP ที่เปิดเผยปลอดภัยอย่างสมบูรณ์หรือไม่+

ไม่ NLA เป็นเพียงการควบคุมการรับรองความถูกต้องอย่างหนึ่ง การเข้าถึงได้ ข้อมูลรับรอง การอัปเดต และสิทธิ์ยังคงต้องได้รับการดูแล

ฉันสามารถใช้ Remote Credential Guard บนเซิร์ฟเวอร์ Windows ทุกเครื่องได้หรือไม่+

ไม่ ไคลเอนต์ โฮสต์ และสภาพแวดล้อมการรับรองความถูกต้องต้องเป็นไปตามข้อกำหนดของ Microsoft รวมถึงการจัดวาง Kerberos ที่เกี่ยวข้อง

ฉันควรทำอะไรก่อนที่จะเข้มงวดไฟร์วอลล์+

ยืนยันเส้นทางการกู้คืน รักษาเซสชันที่ใช้งานได้ และทดสอบเส้นทางที่อนุญาตใหม่ผ่านการเชื่อมต่อครั้งที่สอง

แหล่งอ้างอิงหลัก

ไปที่ต้นทาง

แหล่งอ้างอิงเหล่านี้สนับสนุนแนวคิดทางเทคนิคในคู่มือนี้ ปฏิบัติตามเอกสารปัจจุบันก่อนเปลี่ยนระบบโปรดักชัน

  1. Microsoft: เปิดใช้งาน Remote Desktop และ Network Level Authentication learn.microsoft.com
  2. Microsoft: การเข้าถึง Remote Desktop Gateway learn.microsoft.com
  3. Microsoft: Remote Credential Guard learn.microsoft.com

คำแนะนำด้านบรรณาธิการโดย SwissOctet ตัวอย่างมีไว้เพื่อประกอบ ข้อมูลจำเพาะของบริการ ตัวเลือกที่มี และเงื่อนไขตามสัญญาต้องได้รับการตรวจสอบแยกต่างหาก

เชื่อมโยงความรู้

โครงสร้างพื้นฐานที่เกี่ยวข้อง

รักษาสายไว้

บันทึกภาคสนามถัดไปของคุณ

สำรวจทุกคู่มือ
บันทึกภาคสนาม / 01
การดำเนินงานวันที่สองประยุกต์

สร้างการสำรองข้อมูลที่คุณกู้คืนได้จริง

เลือกเป้าหมายการกู้คืน ปกป้องสำเนาอิสระ และฝึกการกู้คืนก่อนที่เหตุการณ์จะบังคับให้ต้องทำ

อ่าน 4 นาทีอ่านคู่มือ
บันทึกภาคสนาม / 02
การดำเนินงานวันที่สองประยุกต์

แบบจำลองภัยคุกคามเชิงปฏิบัติสำหรับโครงการโฮสติ้งของคุณ

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

อ่าน 6 นาทีอ่านคู่มือ
บันทึกภาคสนาม / 03
การดำเนินงานวันที่สองประยุกต์

เกณฑ์พื้นฐานการเสริมความปลอดภัย Linux VPS ที่คุณดูแลรักษาได้

ดูแลระบบอย่างปลอดภัย เปิดเผยเฉพาะบริการที่จำเป็น และกำหนดการอัปเดตและการกู้คืนโดยไม่ล็อกตัวเองออก

อ่าน 6 นาทีอ่านคู่มือ