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

สองเส้นทาง สองที่อยู่ต้นทาง

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

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

ตรวจสอบว่าฐานข้อมูลเห็นอะไรจริง ๆ

ที่อยู่ต้นทางเป็นสิ่งที่ต้องวัด ไม่ใช่คาดเดาจากแผนภาพ อ่านจากฝั่งเซิร์ฟเวอร์ของการเชื่อมต่อที่ใช้งานอยู่

Test-NetConnection sql.example.com -Port 1433
sqlcmd -S tcp:sql.example.com,1433 -N -d appdb -Q "select SUSER_SNAME() as login_name, DB_NAME() as db"

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

เปิดตัวรับฟังและไม่เปิดอย่างอื่น

เปิดเฉพาะบริการที่การติดตั้งต้องการ พอร์ต 1433 ที่คุ้นเคยเป็นพอร์ตของอินสแตนซ์เริ่มต้น ไม่ใช่ค่าคงที่สากล

Get-NetTCPConnection -State Listen -LocalPort 1433

อินสแตนซ์ที่มีชื่อมักรับฟังบนพอร์ตแบบไดนามิก โดย SQL Server Browser ตอบการค้นพบบน UDP 1434 และการพึ่งพานี้เป็นการเปิดเผยแยกที่ต้องให้เหตุผล การตรึงพอร์ตคงที่ให้อินสแตนซ์จะตัดความจำเป็นของ Browser และทำให้กฎไฟร์วอลล์เสถียร รักษาการตรวจสอบการเข้ารหัสและใบรับรองที่ไคลเอนต์ทำอยู่แล้วไว้ แทนที่จะปิดเพื่อให้การทดสอบผ่าน จากนั้นให้บทบาทฐานข้อมูลสำหรับภาระงาน แทนการเพิ่มทั้งกลุ่ม VPN ไปยังบทบาทเซิร์ฟเวอร์

พิสูจน์เส้นทางที่อนุญาตและเส้นทางที่ปฏิเสธ

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

บันทึกว่าไคลเอนต์ทำงานที่ใด ฐานข้อมูลเห็นแหล่งใด และกฎใดอนุญาต นั่นคือหลักฐานที่การทบทวนครั้งถัดไปจะขอ

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