หากผู้ใช้ที่เข้าสู่ระบบสามารถอ่านแถวของผู้ใช้รายอื่นได้ แสดงว่าฐานข้อมูลของคุณเชื่อถือแอปให้ทำงานได้ ฉันย้ายกฎเข้าไปใน PostgreSQL เองด้วยนโยบายและบทบาทความปลอดภัยระดับแถว จากนั้นพิสูจน์ด้วยการทดสอบว่าผู้ใช้รายหนึ่งไม่สามารถเข้าถึงข้อมูลของผู้ใช้รายอื่นได้
ฉันจะตั้งค่าความปลอดภัยระดับแถวของ PostgreSQL เพื่อให้ผู้ใช้แต่ละคนเห็นเฉพาะข้อมูลของตนเอง รวมถึง Supabase ด้วย
การตรวจสอบความปลอดภัยระดับแถวสูงสุด 5 ตาราง โดยแสดงช่องว่างแต่ละช่องด้วยการสอบถาม
- ตรวจสอบสูงสุด 5 ตาราง
- รายงานที่เป็นลายลักษณ์อักษร
- ตัวอย่างการสอบถาม
นโยบายและบทบาทบนสูงสุด 10 ตาราง พร้อมการทดสอบที่พิสูจน์ว่ากฎยังคงอยู่
- นโยบายบนสูงสุด 10 ตาราง
- รายงานที่เป็นลายลักษณ์อักษร
- ตัวอย่างการสอบถาม
สูงสุด 25 ตาราง, ข้อจำกัดแผนในฐานข้อมูล, การย้ายข้อมูลและการทดสอบใน CI
- สูงสุด 25 ตาราง, ข้อจำกัดแผน, CI
- รายงานที่เป็นลายลักษณ์อักษร
- ตัวอย่างการสอบถาม
ขอข้อเสนอที่กำหนดเอง
เข้าสู่ระบบเพื่อขอข้อเสนอที่กำหนดเอง
สร้างบัญชีฟรีหรือเข้าสู่ระบบเพื่อขอข้อเสนอส่วนบุคคลจาก Zinner นี้
เข้าสู่ระบบ / ลงทะเบียนถามคำถามก่อนการขาย
เข้าสู่ระบบเพื่อถามคำถาม
เพื่อลดสแปมบนแพลตฟอร์ม ข้อความก่อนการขายสามารถส่งได้โดยผู้ใช้ที่เข้าสู่ระบบเท่านั้น
สร้างบัญชีฟรีหรือเข้าสู่ระบบเพื่อส่งข้อความถึง Zinner นี้โดยตรง
เข้าสู่ระบบ / ลงทะเบียนโดยสรุป
รายละเอียดสำคัญเกี่ยวกับบริการนี้เพื่อช่วยคุณตัดสินใจ สร้างโดย Zinn Hub ไม่ใช่ผู้ขาย
ตำแหน่งคุณค่า
ชั้นบังคับใช้
แพลตฟอร์มที่รองรับ
Proof of Work
รูปแบบการจัดส่ง
สิ่งที่คุณจะได้รับ
คำอธิบายฉบับเต็ม
แอปใด ๆ ที่มีบัญชีผู้ใช้, แผนชำระเงิน หรือหลายทีมในฐานข้อมูลเดียวจะต้องตัดสินใจว่าใครสามารถเห็นแถวใดได้บ้าง หากกฎนั้นมีอยู่ในโค้ดของแอปเท่านั้น มันจะล้มเหลวในครั้งแรกที่มีคนเข้าถึงข้อมูลด้วยวิธีอื่น: ปลายทางใหม่ที่ใครบางคนลืมป้องกัน, แอปที่สองบนฐานข้อมูลเดียวกัน, หรือ API ที่ Supabase สร้างขึ้นสำหรับตารางของคุณ ความปลอดภัยระดับแถวจะวางกฎไว้ที่ข้อมูล
ฉันได้ทำสิ่งนี้กับผลิตภัณฑ์สมัครสมาชิกภายใต้ NDA: นโยบายความปลอดภัยระดับแถวบนตารางและบทบาทฐานข้อมูลแยกต่างหากสำหรับแต่ละระดับการสมัครสมาชิก ดังนั้นสิ่งที่แผนรวมอยู่จะถูกบังคับใช้โดย PostgreSQL ไม่ใช่โดยการตรวจสอบที่ใครบางคนอาจลืม
ใน Starter ฉันจะตรวจสอบนโยบายที่ตารางสูงสุดห้าตารางมีหรือขาดไป และส่งรายการช่องว่างที่เป็นลายลักษณ์อักษร พร้อมกับตัวอย่างการสอบถามที่แสดงแต่ละช่อง Standard จะเขียนหรือแก้ไขนโยบายบนตารางสูงสุดสิบตาราง ตั้งค่าบทบาทที่แอปของคุณต้องการ ส่งมอบเป็นไฟล์การย้ายข้อมูล และเพิ่มการทดสอบที่ผู้ใช้ A พยายามอ่านและเปลี่ยนแปลงแถวของผู้ใช้ B และล้มเหลว Advanced ครอบคลุมตารางสูงสุดยี่สิบห้าตาราง เพิ่มข้อจำกัดแผนหรือระดับที่บังคับใช้ในฐานข้อมูล และเรียกใช้การทดสอบใน CI
บน Supabase คุณสมบัติ PostgreSQL เดียวกันนี้ใช้ได้กับ auth.uid() และ JWT claims ที่ใช้ภายในนโยบาย บน PostgreSQL ธรรมดา นโยบายจะอ่านผู้ใช้ปัจจุบันจากการตั้งค่าเซสชันที่แบ็กเอนด์ของคุณตั้งค่าสำหรับการร้องขอแต่ละครั้ง
ไม่มีการโทร ทุกแพ็คเกจจะจบลงด้วยบันทึกภาษาธรรมดาว่าใครสามารถเห็นอะไรได้บ้าง ใน Standard และ Advanced นโยบายจะมาในรูปแบบการย้ายข้อมูลในที่เก็บของคุณพร้อมกับการทดสอบ สำหรับ 14 วันหลังจากการส่งมอบ ฉันจะแก้ไขสิ่งที่ไม่ทำงานตามที่เราตกลงกันโดยไม่มีค่าใช้จ่าย
ขั้นตอนในการทำโปรเจกต์ของคุณให้เสร็จสมบูรณ์
1. จัดทำแผนที่ข้อมูล - ฉันจะแสดงรายการตาราง ผู้ที่เป็นเจ้าของแต่ละแถว และผู้ที่ควรอ่านหรือเปลี่ยนแปลงข้อมูลนั้น: เจ้าของ สมาชิกในทีม ผู้ดูแลระบบ แต่ละแผน
2. ตรวจสอบสิ่งที่มีอยู่ - นโยบาย สิทธิ์ และบทบาทปัจจุบันจะถูกตรวจสอบเทียบกับแผนที่นั้น และช่องว่างทุกช่องจะถูกบันทึกพร้อมกับคำสั่งที่แสดงช่องว่างนั้น
3. นโยบายและบทบาท - นโยบายจะถูกเขียนขึ้นสำหรับแต่ละตารางและแต่ละการดำเนินการ โดยมีบทบาทสำหรับแผนหรือทีม เป็นไฟล์การย้ายข้อมูลที่คุณสามารถตรวจสอบได้
4. พิสูจน์ - การทดสอบจะเข้าสู่ระบบในฐานะผู้ใช้ที่แตกต่างกัน และพยายามอ่านและเปลี่ยนแปลงข้อมูลของกันและกัน การดำเนินการที่ต้องห้ามทุกอย่างจะต้องล้มเหลว และการดำเนินการที่ได้รับอนุญาตทุกอย่างจะต้องทำงาน
5. ส่งมอบ - บันทึกสั้นๆ ด้วยคำพูดธรรมดาๆ เกี่ยวกับผู้ที่สามารถเห็นอะไร การย้ายข้อมูล และวิธีการเพิ่มนโยบายเมื่อมีตารางใหม่ปรากฏขึ้น
การรับประกันคุณภาพ Zinner
Zinner ทุกคนจะได้รับการตรวจสอบและอนุมัติก่อนเข้าร่วมแพลตฟอร์ม
บริการทั้งหมดได้รับการสนับสนุนจากความมุ่งมั่นในการประกันคุณภาพของเรา
การชำระเงินของคุณจะได้รับการคุ้มครองจนกว่าคุณจะอนุมัติงานที่ส่งมอบ
เปรียบเทียบแพ็คเกจ
| ฟังก์ชัน | เริ่มต้น | มาตรฐาน | ขั้นสูง |
|---|---|---|---|
| เวลาจัดส่ง | 2 วัน | 5 วัน | 10 วัน |
| การแก้ไข | 1 | 2 | 3 |
| ขอบเขต | ตรวจสอบตารางสูงสุด 5 ตาราง | นโยบายเกี่ยวกับตารางสูงสุด 10 ตาราง | สูงสุด 25 ตาราง, ขีดจำกัดแผน, CI |
| รายงานที่เป็นลายลักษณ์อักษร | ✓ | ✓ | ✓ |
| ตัวอย่างคำสั่ง | ✓ | ✓ | ✓ |
รายละเอียดบริการ
คำถามที่พบบ่อย
การตรวจสอบแอปจะปกป้องเส้นทางที่คุณจำได้ การรักษาความปลอดภัยระดับแถวครอบคลุมทุกคำสั่งที่ทำงานภายใต้บทบาทฐานข้อมูลของแอปของคุณ รวมถึงปลายทางที่เพิ่มเข้ามาในภายหลังและการเรียก API ของ Supabase โดยตรง ผู้ใช้ระดับสูง เจ้าของตาราง และคีย์บริการของ Supabase จะข้ามการตรวจสอบนี้โดยการออกแบบ ซึ่งเป็นเหตุผลว่าทำไมข้อมูลประจำตัวเหล่านั้นจึงยังคงอยู่บนเซิร์ฟเวอร์ ทีมส่วนใหญ่ยังคงใช้การตรวจสอบทั้งสองประเภท
อาจเป็นไปได้ หากนโยบายเรียกใช้ฟังก์ชันที่ช้าหรือไม่มีดัชนี ฉันเขียนนโยบายโดยคำนึงถึงสิ่งนั้น และการตรวจสอบจะแสดงรายการนโยบายใดๆ ที่ต้องการดัชนี
ไม่ แผนผังที่ไม่มีข้อมูลก็เพียงพอที่จะเขียนและทดสอบนโยบายได้ การทดสอบจะทำงานบนข้อมูลเริ่มต้นที่ฉันสร้างขึ้น
ไม่ การรักษาความปลอดภัยระดับแถวในรูปแบบนี้เป็นคุณสมบัติของ PostgreSQL และบริการนี้สร้างขึ้นโดยใช้ PostgreSQL
รีวิวจากลูกค้า
ดูว่าลูกค้าของเราพูดถึง Zinn นี้ว่าอย่างไร
