RDP เปลี่ยนไคลเอนต์: ทำไมฐานข้อมูลจึงเห็นโฮสต์อื่น

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

คำขอที่สองมีที่อยู่ไคลเอนต์ของตัวเอง

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

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

whoami
ipconfig /all
Test-NetConnection db01.corp.internal -Port 5432

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

ตัวตนเปลี่ยนไปพร้อมกับการกำหนดที่อยู่

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

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

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

whoami /groups
klist
query session

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

ทำไมเส้นทางตรงจึงยังถูกปิดกั้นอย่างถูกต้อง

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

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

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

Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess
net use
Get-ChildItem Env: | Where-Object Name -match 'PROXY|DATABASE|API'

เลือกขอบเขตอย่างตั้งใจ

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

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

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

ตรวจสอบการอนุมัติทั้งสองและเส้นทางการถอนสิทธิ์

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

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

query session
query user
qwinsta /server:rdsh01.corp.internal

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