การออกแบบการค้นหาแบบรวมที่คำนึงถึงสิทธิ์โดยไม่ให้ข้อมูลรั่วไหล

ทำไมการค้นหาแบบรวมอาจทำให้ข้อมูลรั่วไหล\n\nการค้นหาแบบรวมมักหมายถึงกล่องค้นหาเดียวที่สแกนทั้งแอป: ลูกค้า ตั๋ว ใบแจ้งหนี้ เอกสาร ผู้ใช้ และสิ่งอื่น ๆ ที่คนทำงานด้วย มันมักขับเคลื่อนการเติมข้อความอัตโนมัติและหน้าผลลัพธ์ด่วนเพื่อให้ผู้ใช้ไปยังระเบียนได้ทันที.\n\nการรั่วไหลเกิดขึ้นเมื่อการค้นหาคืนค่าบางอย่างที่ผู้ใช้ไม่มีสิทธิ์จะรู้ว่ามีอยู่ แม้พวกเขาจะเปิดระเบียนไม่ได้ แต่บรรทัดเดียวเช่นชื่อเรื่อง ชื่อบุคคล แท็ก หรือส่วนที่เน้นก็สามารถเปิดเผยข้อมูลที่ละเอียดอ่อนได้.\n\nการค้นหาดูเหมือนเป็น "อ่านอย่างเดียว" ทีมมักประเมินค่าต่ำกว่าความเสี่ยง แต่การค้นหาสามารถเปิดเผยข้อมูลผ่านชื่อผลลัพธ์และตัวอย่าง ออโต้คอมพลีท ยอดรวมของผลลัพธ์ แฟคเซ็ตอย่าง "ลูกค้า (5)" และแม้แต่ความแตกต่างด้านเวลา (เช่น คำค้นบางคำเร็ว บางคำช้า).\n\nปัญหานี้มักปรากฏชัดทีหลัง ไม่ใช่ตั้งแต่วันแรก ตอนแรกทีมส่งมอบการค้นหาเมื่อมีเพียงบทบาทเดียว หรือเมื่อทุกคนเห็นทุกอย่างในฐานข้อมูลทดสอบ เมื่อผลิตภัณฑ์โตขึ้น คุณเพิ่มบทบาท (ซัพพอร์ต vs เซลส์, ผู้จัดการ vs เจ้าหน้าที่) และฟีเจอร์อย่างกล่องจดหมายร่วม โน้ตส่วนตัว ลูกค้าที่จำกัด และ "บัญชีของฉันเท่านั้น" หากการค้นหายังคงอาศัยสมมติฐานเก่า มันจะเริ่มแสดงเบาะแสข้ามทีมหรือข้ามลูกค้าได้\n\nโหมดความล้มเหลวที่พบบ่อยคือการจัดทำดัชนี "ทุกอย่าง" เพื่อความเร็ว แล้วพยายามกรองผลลัพธ์ในแอปหลังการค้นหา — นั่นมักสายเกินไป เครื่องมือค้นหาตัดสินใจแล้วว่าอะไรตรงกัน และอาจเปิดเผยระเบียนที่ถูกจำกัดผ่านคำแนะนำ ยอดรวม หรือฟิลด์บางส่วน\n\nลองนึกภาพเจ้าหน้าที่ซัพพอร์ตที่ควรเห็นแค่ตั๋วของลูกค้าที่มอบหมายให้เขา พวกเขาพิมพ์ "Acme" และออโต้คอมพลีทแสดง "Acme - Legal escalation" หรือ "Acme breach notification" แม้การคลิกจะขึ้น "access denied" แต่แค่ชื่อเรื่องก็เป็นการรั่วไหลของข้อมูล\n\nเป้าหมายของการค้นหาแบบรวมที่คำนึงถึงสิทธิ์พูดง่ายแต่ทำยาก: คืนค่าผลลัพธ์ที่เร็วและตรงตามบริบท ขณะเดียวกันบังคับใช้กฎการเข้าถึงเดียวกับที่คุณใช้เมื่อเปิดแต่ละระเบียน ทุกคำค้นต้องทำงานราวกับว่าผู้ใช้เห็นได้เพียงส่วนข้อมูลของตนเท่านั้น และ UI ต้องหลีกเลี่ยงการให้เบาะแสเพิ่มเติม (เช่น ยอดรวม) นอกส่วนข้อมูลนั้น\n\n## สิ่งที่คุณกำลังจัดทำดัชนีและสิ่งที่ต้องปกป้อง\n\nการค้นหาแบบรวมดูเรียบง่ายเพราะผู้ใช้พิมพ์คำแล้วคาดหวังคำตอบ แต่เบื้องหลังคุณกำลังสร้างพื้นผิวใหม่สำหรับการเปิดเผยข้อมูล ก่อนจะเลือกดัชนีหรือฟีเจอร์ฐานข้อมูล ให้ชัดเจนสองเรื่อง: วัตถุที่คุณค้นหา (entities) และส่วนใดของวัตถุเหล่านั้นที่ละเอียดอ่อน\n\nentity คือระเบียนใด ๆ ที่ใครบางคนอาจต้องการค้นหาอย่างรวดเร็ว ในแอปธุรกิจโดยทั่วไปรวมถึง ลูกค้า ตั๋ว ใบแจ้งหนี้ คำสั่งซื้อ และไฟล์ (หรือเมตาดาต้าของไฟล์) นอกจากนี้อาจรวมระเบียนบุคคล (ผู้ใช้ เจ้าหน้าที่) โน้ตภายใน และวัตถุระบบอย่างการเชื่อมต่อหรือคีย์ API หากมีชื่อ รหัส หรือสถานะที่ใครอาจพิมพ์ มักจะลงท้ายด้วยการถูกใส่ในการค้นหาแบบรวม\n\n### กฎต่อระเบียน vs กฎต่อเทเบิล\n\nกฎต่อเทเบิลเป็นแบบหยาบ: คุณเข้าถึงทั้งตารางหรือไม่เข้าถึง ตัวอย่าง: เฉพาะฝ่ายการเงินสามารถเปิดหน้าบิลได้ นี่ง่ายแต่พังเมื่อคนต่างกันควรเห็นแถวต่างกันในตารางเดียวกัน\n\nกฎต่อระเบียนตัดสินการมองเห็นเป็นแถว ๆ ตัวอย่าง: เจ้าหน้าที่ซัพพอร์ตเห็นตั๋วที่มอบหมายให้ทีมของตน ในขณะที่ผู้จัดการเห็นตั๋วทั้งหมดในภูมิภาคของตน อีกกฎทั่วไปคือความเป็นเจ้าของของผู้เช่า: ในแอปหลายผู้เช่า ผู้ใช้เห็นแค่ระเบียนที่มี customer_id = their_customer_id.\n\nกฎต่อระเบียนมักเป็นจุดที่การค้นหารั่วไหล หากดัชนีคืนการจับคู่ก่อนที่คุณจะตรวจสิทธิ์แถว คุณก็เปิดเผยแล้วว่ามีบางอย่างอยู่\n\n### "ได้รับอนุญาตให้ดู" หมายถึงอะไรในทางปฏิบัติ\n\n"ได้รับอนุญาต" ไม่ใช่แค่ใช่/ไม่ใช่ มันมักผสมผสานความเป็นเจ้าของ (สร้างโดยฉัน มอบหมายให้ฉัน) การเป็นสมาชิก (ทีมของฉัน แผนกของฉัน บทบาทของฉัน) ขอบเขต (ภูมิภาค หน่วยธุรกิจ โครงการ) สถานะระเบียน (เผยแพร่ ไม่ถูกเก็บถาวร) และกรณีพิเศษ (ลูกค้า VIP บันทึกทางกฎหมาย แท็กรจำกัด)\n\nเขียนกฎเหล่านี้เป็นภาษาธรรมดาก่อน จากนั้นค่อยแปลงเป็นโมเดลข้อมูลพร้อมการตรวจสอบฝั่งเซิร์ฟเวอร์\n\n### ตัดสินใจว่าส่วนใดปลอดภัยที่จะโชว์ในตัวอย่างผลลัพธ์\n\nผลการค้นหามักมีตัวอย่างสั้น ๆ และตัวอย่างสามารถรั่วไหลข้อมูลได้แม้ผู้ใช้จะเปิดระเบียนไม่ได้\n\nค่าเริ่มต้นที่ปลอดภัยคือแสดงเฉพาะฟิลด์ขั้นต่ำที่ไม่ละเอียดอ่อนจนกว่าจะยืนยันสิทธิ์: ชื่อแสดงหรือชื่อเรื่อง (บางครั้งมาสก์), ตัวระบุสั้น ๆ (เช่น หมายเลขคำสั่งซื้อ), สถานะระดับสูง (Open, Paid, Shipped), วันที่ (สร้าง/อัปเดต) และป้ายประเภทวัตถุทั่วไป (Ticket, Invoice)\n\nตัวอย่างชัดเจน: ถ้ามีคนค้นหา "Acme merger" และมีตั๋วที่ถูกจำกัด การคืนค่า "Ticket: Acme merger draft - Legal" ก็เป็นการรั่วไหลแล้ว ผลลัพธ์ที่ปลอดภัยกว่าอาจเป็น "Ticket: Restricted" โดยไม่มีตัวอย่าง หรือไม่มีผลลัพธ์เลย ขึ้นกับนโยบายของคุณ\n\nการนิยามสิ่งเหล่านี้ให้ถูกต้องตั้งแต่แรกจะทำให้การตัดสินใจในภายหลังง่ายขึ้น: จะจัดทำดัชนีอะไร จะกรองอย่างไร และยินดีเปิดเผยอะไรบ้าง\n\n## ข้อกำหนดพื้นฐานสำหรับการค้นหาที่ปลอดภัยและรวดเร็ว\n\nคนใช้การค้นหาแบบรวมเมื่อรีบ หากช้ากว่าหนึ่งวินาที ผู้ใช้จะเริ่มไม่เชื่อถือและกลับไปกรองด้วยมือ แต่ความเร็วเป็นเพียงครึ่งงาน การค้นหาที่เร็วแต่รั่วไหลแม้ระเบียนเดียวก็แย่กว่าการไม่มีการค้นหาเลย\n\nกฎหลักไม่ต่อรอง: บังคับใช้สิทธิ์ในเวลาค้นหา ไม่ใช่แค่ใน UI การซ่อนแถวหลังจากดึงมาแล้วสายเกินไปเพราะระบบแตะข้อมูลที่ไม่ควรถูกส่งกลับแล้ว\n\nสิ่งนี้ใช้กับทุกอย่างรอบการค้นหา ไม่ใช่แค่รายการผลสุดท้าย คำแนะนำ ผลลัพธ์ยอดนิยม ยอดรวม และแม้แต่การตอบว่า "ไม่มีผลลัพธ์" ก็รั่วไหลได้ ออโต้คอมพลีทที่แสดง "Acme Renewal Contract" ให้คนที่เปิดไม่ได้คือการรั่วไหล แฟคเซ็ตที่บอกว่า "12 ใบแจ้งหนี้ที่ตรงกัน" เป็นการรั่วไหลหากผู้ใช้อนุญาตให้เห็นแค่ 3 แม้แต่เวลาตอบช้าสำหรับการจับคู่ที่จำกัดก็สามารถให้เบาะแสได้\n\nการค้นหาแบบรวมที่ปลอดภัยต้องมีสี่อย่าง:\n\n- ความถูกต้อง: ทุกไอเท็มที่คืนค่าต้องอนุญาตสำหรับผู้ใช้นี้ สำหรับผู้เช่านี้ และสำหรับเวลานี้\n- ความเร็ว: ผลลัพธ์ คำแนะนำ และยอดรวมต้องรวดเร็วอย่างสม่ำเสมอ แม้ที่สเกลใหญ่\n- ความสอดคล้อง: เมื่อการเข้าถึงเปลี่ยน (อัปเดตบทบาท ตั๋วถูกย้าย) การค้นหาต้องเปลี่ยนอย่างรวดเร็วและคาดเดาได้\n- ความตรวจสอบได้: คุณต้องอธิบายได้ว่าทำไมไอเท็มถึงถูกส่งกลับ และบันทึกกิจกรรมการค้นหาเพื่อตรวจสอบ\n\nเปลี่ยนมุมมอง: ถือว่าการค้นหาเป็น API ข้อมูล ไม่ใช่ฟีเจอร์ UI นั่นหมายถึงกฎการเข้าถึงเดียวกับหน้ารายการต้องใช้กับการสร้างดัชนี การประมวลผลคำค้น และทุกเอ็นด์พอยต์ที่เกี่ยวข้อง (autocomplete, recent searches, popular queries)\n\n## รูปแบบการออกแบบสามแบบที่ใช้บ่อย (และเมื่อต้องใช้แต่ละแบบ)\n\nกล่องค้นหาสร้างง่าย แต่การค้นหาแบบรวมที่คำนึงถึงสิทธิ์ยาก เพราะดัชนีต้องการคืนผลทันที ในขณะที่แอปของคุณต้องไม่ให้ข้อมูลที่ผู้ใช้ไม่มีสิทธิ์เห็นโดยอ้อม\n\nด้านล่างคือสามรูปแบบที่ทีมมักใช้ บทสรุปจะช่วยให้คุณเลือกตามความซับซ้อนของกฎการเข้าถึงและความเสี่ยงที่ยอมรับได้\n\nApproach A: จัดทำดัชนีเฉพาะฟิลด์ที่ "ปลอดภัย" แล้วค่อยดึงข้อมูลเต็มหลังตรวจสิทธิ์.\nเก็บเอกสารมินิมัลในดัชนี เช่น ID และป้ายที่ไม่ละเอียดอ่อนซึ่งปลอดภัยที่จะแสดงให้ใครก็ตามที่เข้าถึง UI ได้ เมื่อผู้ใช้คลิกผลลัพธ์ แอปของคุณโหลดระเบียนเต็มจากฐานข้อมูลหลักและใช้กฎสิทธิ์จริงที่นั่น\n\nวิธีนี้ลดความเสี่ยงการรั่วไหล แต่ทำให้ผลลัพธ์ให้ข้อมูลน้อยและต้องระมัดระวังข้อความใน UI เพื่อไม่ให้ป้าย "ปลอดภัย" เปิดเผยข้อมูลลับโดยไม่ตั้งใจ\n\nApproach B: เก็บแอตทริบิวต์สิทธิ์ในดัชนีแล้วกรองที่นั่น.\nรวมฟิลด์อย่าง tenant_id, team_id, owner_id, ธงบทบาท หรือ project_id ในเอกสารที่จัดทำดัชนี ทุกคำค้นเพิ่มตัวกรองที่ตรงกับขอบเขตของผู้ใช้ปัจจุบัน\n\nวิธีนี้ให้ผลลัพธ์ที่เร็วและมีบริบทดี รวมทั้งออโต้คอมพลีทที่ดี แต่ทำได้เมื่อกฎการเข้าถึงสามารถแสดงเป็นตัวกรองเท่านั้น หากสิทธิ์ขึ้นกับตรรกะซับซ้อน (เช่น "มอบหมาย หรือ อยู่ในสแตนด์บายสัปดาห์นี้ หรือ เป็นส่วนหนึ่งของ incident") มันจะยากที่จะทำให้ถูกต้อง\n\nApproach C: ไฮบริด. กรองหยาบในดัชนี แล้วตรวจสิทธิ์สุดท้ายในฐานข้อมูล.\nกรองในดัชนีด้วยแอตทริบิวต์ที่เสถียรและกว้าง (tenant, workspace, customer) แล้วรีเช็คสิทธิ์บนชุดไอดีผู้สมัครที่เล็กในฐานข้อมูลหลักก่อนส่งคืนอะไร\n\nวิธีนี้มักปลอดภัยที่สุดสำหรับแอปจริง: ดัชนียังเร็ว และฐานข้อมูลยังเป็นแหล่งความจริง\n\n### การเลือกแบบ\n\nเลือก A เมื่อคุณต้องการตั้งค่าที่ง่ายที่สุดและยอมรับผลลัพธ์ที่มีบริบทน้อยได้ เลือก B เมื่อคุณมีขอบเขตชัดเจนและค่อนข้างคงที่ (multi-tenant, team-based) และต้องการออโต้คอมพลีทที่เร็วมาก เลือก C เมื่อมีบทบาทมาก ข้อยกเว้น หรือกฎต่อระเบียนที่เปลี่ยนบ่อย สำหรับข้อมูลที่มีความเสี่ยงสูง (ทรัพยากรบุคคล การเงิน การแพทย์) ควรเลือก C เพราะ "เกือบถูก" ไม่พอสำหรับกรณีเหล่านี้\n\n## ขั้นตอนทีละขั้น: ออกแบบดัชนีที่เคารพกฎการเข้าถึง\n\nเริ่มด้วยการเขียนกฎการเข้าถึงเหมือนกำลังอธิบายให้เพื่อนร่วมทีมคนใหม่ฟัง หลีกเลี่ยงคำว่า "แอดมินเห็นทุกอย่าง" เว้นแต่ว่าจริง ๆ เป็นเช่นนั้น ระบุเหตุผลแทน: "เจ้าหน้าที่ซัพพอร์ตเห็นตั๋วจากผู้เช่าของตน ผู้นำทีมเห็นตั๋วจากหน่วยงานของตนเท่านั้น โน้ตส่วนตัวเห็นได้เฉพาะเจ้าของและเจ้าหน้าที่ที่มอบหมาย" หากคุณอธิบายไม่ได้ว่าทำไมคนถึงเห็นระเบียน จะยากในการเข้ารหัสอย่างปลอดภัย\n\nต่อไป เลือกตัวระบุที่เสถียรและกำหนดเอกสารค้นหาขั้นพื้นฐาน ดัชนีไม่ควรเป็นสำเนาเต็มของแถวฐานข้อมูล เก็บเฉพาะสิ่งที่ต้องใช้ค้นหาและแสดงในรายชื่อผล เช่น ชื่อ เรื่อง สถานะ และอาจมีตัวอย่างสั้นที่ไม่ละเอียดอ่อน เก็บฟิลด์ที่ละเอียดอ่อนไว้หลังการดึงข้อมูลครั้งที่สองพร้อมการตรวจสิทธิ์\n\nจากนั้นตัดสินใจว่าสัญญาณสิทธิ์ใดที่กรองได้เร็ว นี่คือแอตทริบิวต์ที่กำหนดการเข้าถึงและเก็บในเอกสารทุกชิ้น เช่น tenant_id, org_unit_id, และธงขอบเขตจำนวนน้อย เป้าหมายคือให้ทุกคำค้นสามารถใช้ตัวกรองก่อนคืนผลได้ รวมทั้งออโต้คอมพลีท\n\nเวิร์กโฟลว์ที่ใช้งานได้จริงมีดังนี้:\n\n1. กำหนดกฎการมองเห็นสำหรับแต่ละ entity (ตั๋ว ลูกค้า ใบแจ้งหนี้) เป็นภาษาธรรมดา\n2. สร้างสคีม่าเอกสารค้นหาที่มี record_id และฟิลด์ค้นหา/แสดงที่ปลอดภัยเท่านั้น\n3. เพิ่มฟิลด์สิทธิ์ที่กรองได้ (tenant_id, org_unit_id, visibility_level) ในทุกเอกสาร\n4. จัดการข้อยกเว้นด้วยการมอบสิทธิ์แบบชัดเจน: เก็บ allowlist (ไอดีผู้ใช้) หรือไอดีกลุ่มสำหรับรายการที่แชร์\n\nรายการที่แชร์และข้อยกเว้นคือจุดที่การออกแบบล้มเหลว หากตั๋วแชร์ข้ามทีม อย่าแค่เพิ่ม boolean ใช้การมอบสิทธิ์แบบชัดเจนที่ตรวจสอบได้ด้วยตัวกรอง หาก allowlist ใหญ่ ให้ใช้การมอบสิทธิ์แบบกลุ่มแทนผู้ใช้รายบุคคล\n\n## การรักษาความสอดคล้องของดัชนีโดยไม่เกิดความประหลาดใจ\n\nประสบการณ์การค้นหาที่ปลอดภัยขึ้นอยู่กับสิ่งน่าเบื่ออย่างหนึ่งที่ทำให้ดี: ดัชนีต้องสะท้อนความจริง หากระเบียนถูกสร้าง เปลี่ยน แก้ไข หรือลบ ผลการค้นหาต้องตามทันอย่างรวดเร็วและคาดเดาได้\n\n### ติดตามการสร้าง อัปเดต ลบ\n\nปฏิบัติกับการจัดทำดัชนีเป็นส่วนหนึ่งของวงจรชีวิตข้อมูล แบบจำลองที่มีประโยชน์คือ: ทุกครั้งที่แหล่งความจริงเปลี่ยน คุณส่งเหตุการณ์และตัวจัดทำดัชนีตอบสนอง\n\nวิธีที่ใช้กันทั่วไปได้แก่ ทริกเกอร์ฐานข้อมูล เหตุการณ์จากแอป หรือคิวงาน สิ่งสำคัญคืออย่าให้เหตุการณ์หายไป หากแอปบันทึกระเบียนแต่ดัชนีล้มเหลว จะเกิดพฤติกรรมสับสนเช่น "ฉันรู้ว่ามันมี แต่การค้นหาไม่เจอ"\n\n### การเปลี่ยนแปลงสิทธิ์คือการเปลี่ยนแปลงดัชนี\n\nการรั่วไหลหลายครั้งเกิดเมื่อเนื้อหาอัปเดตถูกต้อง แต่เมตาดาต้าสิทธิ์ไม่อัปเดต การเปลี่ยนสิทธิ์มาจากการอัปเดตบทบาท การย้ายทีม การโอนความเป็นเจ้าของ การย้ายลูกค้า หรือการรวมตั๋ว\n\nให้การเปลี่ยนแปลงสิทธิ์เป็นเหตุการณ์สำคัญ หากการค้นหาของคุณพึ่งพาตัวกรอง tenant หรือ team ให้แน่ใจว่าเอกสารที่จัดทำดัชนีรวมฟิลด์ที่ต้องใช้ในการบังคับนั้น (tenant_id, team_id, owner_id, allowed_role_ids) เมื่อตัวเหล่านี้เปลี่ยน ให้รีอินเด็กซ์\n\nส่วนยากคือขอบเขตผลกระทบ การเปลี่ยนบทบาทอาจกระทบหมื่น ๆ ระเบียน วางแผนเส้นทางรีอินเด็กซ์แบบกลุ่มที่มีการติดตามความคืบหน้า การลองใหม่ และวิธีหยุดชั่วคราว\n\n### วางแผนสำหรับ eventual consistency\n\nแม้มีเหตุการณ์ดี ก็จะมีช่วงเวลาที่ดัชนียังตามไม่ทัน ตัดสินใจว่าผู้ใช้ควรเห็นอะไรในวินาทีแรกหลังการเปลี่ยน\n\nสองกฎช่วยได้:\n\n- ทำให้ความล่าช้าเป็นเรื่องสม่ำเสมอ หากการจัดทำดัชนีปกติใช้ 2–5 วินาที ให้ตั้งความคาดหวังนั้นเมื่อจำเป็น\n- เลือกให้หายไปดีกว่ารั่วไหล ปลอดภัยกว่าที่ระเบียนที่เพิ่งได้รับสิทธิ์จะปรากฏช้ากว่าให้ระเบียนที่เพิ่งถูกถอนสิทธิ์ยังปรากฏอยู่\n\n### เพิ่มทางเลือกที่ปลอดภัยเมื่อดัชนีค้าง\n\nการค้นหาเพื่อค้นพบ แต่การดูรายละเอียดคือที่ที่การรั่วไหลทำร้ายจริง ทำการตรวจสิทธิ์อีกครั้งเมื่ออ่านรายละเอียดก่อนแสดงฟิลด์ละเอียดอ่อน หากผลลัพธ์เล็ดรอดเพราะดัชนีค้าง หน้ารายละเอียดยังต้องบล็อกการเข้าถึง\n\nรูปแบบที่ดีคือ: แสดงตัวอย่างขั้นต่ำในการค้นหา แล้วตรวจสิทธิ์อีกครั้งเมื่อผู้ใช้เปิดระเบียน (หรือขยายตัวอย่าง) หากการตรวจล้มเหลว ให้แสดงข้อความชัดเจนและลบรายการออกจากผลลัพธ์เมื่อรีเฟรชครั้งถัดไป\n\n## ความผิดพลาดทั่วไปที่ทำให้ข้อมูลรั่วไหล\n\nการค้นหาสามารถรั่วไหลได้แม้หน้า "เปิดระเบียน" ของคุณล็อกแน่น ผู้ใช้อาจไม่เคยคลิกผลลัพธ์แต่ยังรู้ชื่อ รหัสลูกค้า หรือขนาดของโปรเจกต์ที่ซ่อนอยู่ การค้นหาแบบรวมที่คำนึงถึงสิทธิ์ต้องปกป้องไม่เพียงเอกสาร แต่รวมถึงเบาะแสเกี่ยวกับเอกสารด้วย\n\nออโต้คอมพลีทเป็นแหล่งรั่วไหลบ่อย ๆ คำแนะนำมักขับเคลื่อนโดยการค้นหา prefix ที่เร็วซึ่งข้ามการตรวจสิทธิ์เต็มรูปแบบ UI ดูปลอดภัย แต่ตัวอักษรเดียวอาจเปิดเผยชื่อลูกค้าหรืออีเมล ออโต้คอมพลีทต้องรันตัวกรองการเข้าถึงเดียวกับการค้นหาเต็ม หรือสร้างจากชุดคำแนะนำที่กรองล่วงหน้า (เช่น แยกตามผู้เช่าและบทบาท)\n\nยอดรวมแฟคเซ็ตและป้าย "ประมาณ 1,243 ผลลัพธ์" เป็นการรั่วไหลเงียบ ยอดรวมยืนยันการมีอยู่แม้คุณจะซ่อนรายการ หากคำนวณยอดรวมตามกฎการเข้าถึงไม่ได้อย่างปลอดภัย ให้แสดงข้อมูลน้อยลงหรือไม่แสดงยอดรวม\n\nแคชเป็นอีกสาเหตุทั่วไป แคชที่แชร์ระหว่างผู้ใช้ บทบาท หรือผู้เช่าอาจสร้าง "ผีผลลัพธ์" ที่ผู้ใช้หนึ่งเห็นผลลัพธ์ที่สร้างให้คนอื่น เกิดขึ้นได้กับ edge cache แคชระดับแอป และแคชในหน่วยความจำของบริการค้นหา\n\nเช็คลิสต์ช่องโหว่ที่ควรตรวจเร็ว:\n\n- ออโต้คอมพลีทและการค้นหาล่าสุดถูกกรองด้วยกฎเดียวกับการค้นหาเต็ม\n- ยอดรวมแฟคเซ็ตและตัวเลขถูกคำนวณหลังการตรวจสิทธิ์\n- คีย์แคชรวม tenant ID และลายเซ็นสิทธิ์ (บทบาท ทีม ไอดีผู้ใช้)\n- โลกและการวิเคราะห์ไม่เก็บคำค้นหรือตัวอย่างที่ละเอียดอ่อนแบบดิบ\n\nสุดท้าย ระวังตัวกรองกว้างเกินไป "กรองตาม tenant เท่านั้น" เป็นข้อผิดพลาดคลาสสิกของ multi-tenant แต่เกิดขึ้นภายในผู้เช่าเดียวได้เช่นกัน: กรองตาม "แผนก" เมื่อการเข้าถึงเป็นแบบแถวต่อแถว ตัวอย่าง: เจ้าหน้าที่ซัพพอร์ตค้นหา "refund" แล้วได้ผลลัพธ์ข้ามลูกค้าทั้งผู้เช่า รวมทั้งบัญชี VIP ที่ควรเห็นได้แค่ทีมเล็กกว่า การแก้โดยหลักการคือ: บังคับใช้กฎระดับแถวในทุกเส้นทางคำค้น (search, autocomplete, facets, exports) ไม่ใช่แค่หน้าเปิดระเบียน\n\n## รายละเอียดความเป็นส่วนตัวและความปลอดภัยที่คนมักลืม\n\nการออกแบบหลายแบบเน้นว่า "ใครเห็นอะไร" แต่การรั่วไหลเกิดจากขอบเขต: สถานะว่าง เวลา และเบาะแสเล็ก ๆ การค้นหาที่คำนึงถึงสิทธิ์ต้องปลอดภัยแม้จะคืนค่าเป็นศูนย์\n\nการยืนยันด้วยการไม่มีผลลัพธ์เป็นช่องโหว่ง่าย หากผู้ใช้ไม่มีสิทธิ์ค้นหาชื่อลูกค้าหรืออีเมลแล้วได้ข้อความเฉพาะเช่น "No access" หรือ "You don't have permission" คุณได้ยืนยันการมีอยู่ของระเบียนแล้ว ปฏิบัติต่อ "ไม่มีผลลัพธ์" เป็นผลลัพธ์ดีฟอลต์สำหรับทั้ง "ไม่มีอยู่" และ "มีอยู่แต่ไม่อนุญาต" รักษาเวลาในการตอบและถ้อยคำให้สม่ำเสมอเพื่อไม่ให้คนเดาจากความเร็ว\n\n### การจับคู่บางส่วนที่ละเอียดอ่อน\n\nออโต้คอมพลีทและการค้นหาแบบพิมพ์ตามเวลาเป็นพื้นที่ที่ข้อมูลส่วนบุคคลเล็ดรอด การจับคู่บางส่วนของอีเมล เบอร์โทร หรือหมายเลขประจำตัวสามารถเปิดเผยเกินความตั้งใจ ตัดสินใจตั้งแต่แรกว่าฟิลด์เหล่านี้จะทำงานอย่างไร\n\nชุดกฎปฏิบัติได้:\n\n- ต้องเป็นการจับคู่ตรงสำหรับฟิลด์ความเสี่ยงสูง (อีเมล เบอร์โทร รหัส)\n- หลีกเลี่ยงการแสดงสแนปชอตที่เน้นข้อความที่ซ่อนอยู่\n- พิจารณาปิดออโต้คอมพลีทสำหรับฟิลด์ละเอียดอ่อนทั้งหมด\n\nถ้าการโชว์แม้แต่ตัวอักษรเดียวช่วยให้ใครบางคนเดาข้อมูล ให้ถือว่าฟิลด์นั้นละเอียดอ่อน\n\n### การควบคุมการใช้งานที่ไม่สร้างความเสี่ยงใหม่\n\nเอ็นด์พอยต์การค้นหาเป็นเป้าสำหรับการโจมตีแบบสำรวจ: ลองคำค้นจำนวนมากเพื่อแมปสิ่งที่มี เพิ่มอัตราจำกัดและการตรวจจับพฤติกรรมผิดปกติ แต่ระวังสิ่งที่เก็บเก็บบันทึก โลกที่รวมคำค้นดิบอาจเป็นแหล่งรั่วไหลที่สอง\n\nทำให้เรียบง่าย: จำกัดอัตราต่อผู้ใช้ ต่อไอพี และต่อผู้เช่า; เก็บบันทึกเป็นจำนวน เวลา และรูปแบบหยาบ (ไม่ใช่ข้อความคำค้นเต็ม); แจ้งเตือนเมื่อมีคำค้นที่เกือบพลาดซ้ำ ๆ (เช่น ไอดีเรียงกัน); และบล็อกหรือยกระดับการยืนยันหลังความล้มเหลวซ้ำ\n\nทำให้ข้อผิดพลาดน่าเบื่อ ใช้ข้อความและสถานะว่างเดียวกันสำหรับ "ไม่มีผลลัพธ์" "ไม่อนุญาต" และ "ตัวกรองไม่ถูกต้อง" ยิ่ง UI พูดน้อย ยิ่งเปิดเผยน้อย\n\n## ตัวอย่าง: ทีมซัพพอร์ตค้นหาตั๋วข้ามลูกค้า\n\nเจ้าหน้าที่ซัพพอร์ตชื่อ Maya ทำงานในทีมที่ดูแลบัญชีลูกค้า 3 ราย เธอมีช่องค้นหาเดียวในส่วนหัวแอป ผลิตภัณฑ์มีดัชนีรวมสำหรับตั๋ว รายชื่อติดต่อ และบริษัท แต่ทุกผลลัพธ์ต้องปฏิบัติตามกฎการเข้าถึง\n\nMaya พิมพ์ "Alic" เพราะคนโทรบอกชื่อ Alice ออโต้คอมพลีทแสดงคำแนะนำไม่กี่รายการ เธอคลิก "Alice Nguyen - Ticket: Password reset" ก่อนเปิดแอปตรวจสอบสิทธิ์สำหรับระเบียนนั้นอีกครั้ง หากตั๋วยังมอบหมายให้ทีมของเธอและบทบาทของเธออนุญาต เธอจะเข้าไปยังตั๋วนั้นได้\n\nสิ่งที่ Maya เห็นในแต่ละขั้นตอน:\n\n- กล่องค้นหา: คำแนะนำปรากฏเร็ว แต่มีเฉพาะรายการที่เธอเข้าถึงได้ตอนนี้\n- รายการผลลัพธ์: หัวเรื่องตั๋ว ชื่อลูกค้า เวลาอัปเดตล่าสุด ไม่มีตัวแทนข้อความว่า "คุณไม่มีสิทธิ์"\n- รายละเอียดตั๋ว: มุมมองเต็มโหลดหลังการตรวจสิทธิ์ฝั่งเซิร์ฟเวอร์อีกครั้ง หากการตรวจล้มเหลว แอปจะแสดงว่า "Ticket not found" (ไม่ใช่ "forbidden")\n\nเปรียบเทียบกับ Leo เจ้าหน้าที่ใหม่ที่ฝึกงาน บทบาทของเขาเห็นเฉพาะตั๋วที่ระบุว่า "Public to Support" และสำหรับลูกค้าหนึ่งรายเท่านั้น Leo พิมพ์ "Alic" เขาเห็นคำแนะนำจำนวนน้อยกว่า และไม่มีรายการที่หายไปเป็นเบาะแส ไม่แสดงยอดรวมว่า "มี 5 ผลลัพธ์" ที่บอกว่ามีการจับคู่อื่นอยู่ UI แสดงเฉพาะสิ่งที่เขาเปิดได้\n\nต่อมา ผู้จัดการย้าย "Alice Nguyen - Password reset" จากทีมของ Maya ไปยังทีมขึ้นศูนย์เฉพาะ ในช่วงเวลาอันสั้น (มักเป็นวินาทีถึงไม่กี่นาที ขึ้นกับแนวทางซิงค์ของคุณ) การค้นหาของ Maya จะหยุดคืนค่านั้น หากเธอมีหน้ารายละเอียดเปิดและรีเฟรช แอปจะตรวจสิทธิ์อีกครั้งและตั๋วจะหายไป\n\nนั่นคือพฤติกรรมที่ต้องการ: พิมพ์เร็ว ผลลัพธ์เร็ว โดยไม่มีเบาะแสการรั่วไหลผ่านยอดรวม ตัวอย่าง หรือรายการค้างในดัชนี\n\n## เช็คลิสต์และขั้นตอนถัดไปสำหรับการนำไปใช้อย่างปลอดภัย\n\nการค้นหาแบบรวมที่คำนึงถึงสิทธิ์จะ "เสร็จ" เมื่อขอบเขตน่าเบื่อปลอดภัยแล้ว รั่วไหลหลายกรณีเกิดในจุดที่ดูเหมือนไม่เป็นอันตราย: ออโต้คอมพลีท ยอดรวม และการส่งออก\n\n### การตรวจสอบความปลอดภัยด่วน\n\nก่อนปล่อย ให้เดินผ่านการตรวจเหล่านี้ด้วยข้อมูลจริง ไม่ใช่ตัวอย่าง:\n\n- ออโต้คอมพลีท: ห้ามแนะนำชื่อเรื่อง ชื่อ หรือไอดีที่ผู้ใช้เปิดไม่ได้\n- ยอดรวมและแฟคเซ็ต: หากแสดงยอดรวม ให้คำนวณหลังการตรวจสิทธิ์ (หรือไม่แสดงยอดรวม)\n- การส่งออกและการกระทำเป็นกลุ่ม: การส่งออก "การค้นหาปัจจุบัน" ต้องตรวจสิทธิ์ต่อแถวเมื่อส่งออก\n- การเรียงลำดับและการเน้น: อย่าเรียงหรือเน้นโดยใช้ฟิลด์ที่ผู้ใช้ไม่มีสิทธิ์เห็น\n- "ไม่พบ" vs "ห้าม": สำหรับเอนทิตีละเอียดอ่อน ให้พิจารณารูปแบบการตอบเหมือนกันเพื่อผู้ใช้จะไม่ยืนยันการมีอยู่\n\n### แผนทดสอบที่ทำได้\n\nสร้างเมทริกซ์บทบาทเล็ก ๆ (บทบาท x เอนทิตี) และชุดข้อมูลที่ตั้งใจให้เป็นกรณียาก: ระเบียนที่แชร์ ระเบียนที่เพิ่งถูกยกเลิกการเข้าถึง และคู่ที่เหมือนกันข้ามผู้เช่า\n\nทดสอบสามรอบ: (1) ทดสอบเมทริกซ์บทบาท ยืนยันว่าระเบียนที่ถูกปฏิเสธไม่ปรากฏในผลลัพธ์ คำแนะนำ ยอดรวม หรือการส่งออก; (2) "ลองทำลาย" ทดสอบ วางไอดี วางอีเมลหรือเบอร์โทร และลองการจับคู่บางส่วนที่ต้องไม่คืนค่าอะไร; (3) ทดสอบเวลาและแคช เปลี่ยนสิทธิ์และยืนยันว่าผลลัพธ์อัปเดตเร็วโดยไม่มีคำแนะนำหรือรายการค้าง\n\nในเชิงปฏิบัติ ให้วางแผนสำหรับวันที่ผลการค้นหา "ดูผิด" บันทึกบริบทคำค้น (ผู้ใช้ บทบาท ผู้เช่า) และตัวกรองสิทธิ์ที่ใช้ แต่หลีกเลี่ยงการเก็บสตริงคำค้นหรือตัวอย่างละเอียดอ่อนแบบดิบ สำหรับการดีบักที่ปลอดภัย สร้างเครื่องมือสำหรับผู้ดูแลระบบที่อธิบายได้ว่าทำไมระเบียนถึงตรงและทำไมถึงได้รับอนุญาต\n\nถ้าคุณกำลังสร้างบน AppMaster (appmaster.io) แนวทางปฏิบัติที่เป็นประโยชน์คือเก็บการค้นหาเป็นโฟลว์ฝั่งเซิร์ฟเวอร์: โมเดลเอนทิตีและความสัมพันธ์ใน Data Designer บังคับกฎการเข้าถึงใน Business Processes เดียวกัน และนำการตรวจสิทธิ์นั้นกลับมาใช้กับออโต้คอมพลีท รายการผล และการส่งออก เพื่อให้มีที่เดียวที่ต้องถูกต้อง\n