Excel ไปยัง SQL Server ของพาร์ทเนอร์โดยไม่ใช้ความเชื่อใจของโดเมน

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

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

สามการตัดสินใจที่คำถามซ่อนไว้

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

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

ข้อมูลระบุตัวตนโดยไม่ใช้ความเชื่อใจระดับฟอเรสต์

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

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

เข้ารหัสใช่ แต่จะเชื่อใบรับรองหรือ

ด้วย ODBC Driver 18 นั้น Encrypt=Yes;TrustServerCertificate=No ขอเซสชันที่เข้ารหัสซึ่งมีการตรวจสอบใบรับรองจริง ๆ สตริงการเชื่อมต่อจะต้องระบุชื่อเซิร์ฟเวอร์ที่ใบรับรองครอบคลุม และไคลเอนต์ต้องเชื่อถือห่วงโซ่ของมัน Driver 18 ยังเข้ารหัสเป็นค่าเริ่มต้น ต่างจากเวอร์ชันก่อนหน้า ดังนั้นสตริงการเชื่อมต่อเก่าอาจต่อรอง TLS ได้โดยไม่บอก การตั้งค่าที่ชัดเจนทำให้แนวนโยบายที่ตั้งใจมองเห็นได้ทุกเครื่อง ซึ่งสำคัญเมื่อหลายคนดูแลเวิร์กบุ๊กเดียวกัน

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

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

เส้นทางเครือข่ายไม่ใช่การป้องกัน

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

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

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