อะไรที่ปกป้องผู้เช่าหนึ่งราย พูดกันตรง ๆ
ไม่มีใบรับรองที่เราไม่ได้ถือ ไม่มีคำคุณศัพท์มาแทนกลไกควบคุม นี่คือสิ่งที่ถูกบังคับใช้ บังคับใช้ที่ไหน และอะไรที่ยังขาด
การแยกเป็นเรื่องโครงสร้าง ไม่ใช่การคอยตรวจตรา
ทุกคำสั่งค้นข้อมูลที่เป็นของพื้นที่ทำงานจะมีรหัสพื้นที่ทำงานอยู่ในเงื่อนไข ไม่มีเส้นทางเข้าถึงแบบไม่จำกัดขอบเขตให้ใครลืมใช้
ความพังที่การออกแบบนี้ตัดออกคือแบบธรรมดาที่สุด: ระบบที่ถูกต้องดี แต่มีเอนด์พอยต์ใหม่หนึ่งตัวที่เขียนรีบ ๆ แล้วลืมเงื่อนไข WHERE ถ้าชั้นข้อมูลไม่ยอมตอบคำถามที่ไม่ระบุพื้นที่ทำงาน เอนด์พอยต์นั้นก็ไม่ได้คอมไพล์ออกมาเป็นรูรั่ว — มันคอมไพล์ไม่ผ่านเลย
ชุดทดสอบการรั่วแบบมุ่งโจมตีตรึงคุณสมบัตินี้ไว้ แทนที่จะเชื่อธรรมเนียมปฏิบัติ เพราะธรรมเนียมดีได้เท่ากับคนสุดท้ายที่อ่านไฟล์นั้นเท่านั้น
internal/tenancy · migrations/0002
บันทึกตรวจสอบเพิ่มได้อย่างเดียวที่ฐานข้อมูล ไม่ใช่ที่แอปพลิเคชัน
ทริกเกอร์จะโยนข้อผิดพลาดทันทีที่มีการแก้ไขหรือลบ แอปที่ตัดสินใจไม่เขียนประวัติศาสตร์ใหม่คือนโยบาย ส่วนฐานข้อมูลที่ปฏิเสธการเขียนใหม่คือกลไกควบคุม
นี่คือความต่างที่ผู้ตรวจสอบถามและผู้ขายมักตอบไม่ได้ ถ้าสิ่งเดียวที่กันการแก้ย้อนหลังคือ “ไม่มีโค้ดเส้นทางไหนทำแบบนั้น” สคริปต์ซัพพอร์ตหนึ่งตัว ไมเกรชันหนึ่งครั้ง หรือผู้ดูแลที่มีคอนโซลอยู่ในมือ ก็ทำได้ และบันทึกจะไม่มีทางรู้
internal/tenancy · migrations/0002 audit_log_immutable()
กุญแจหมุนได้โดยไม่ต้องหยุดระบบ การเข้าสู่ระบบทนต่อฟิชชิง
การหมุนกุญแจที่ต้องมีช่วงปิดปรับปรุง คือการหมุนที่ไม่เคยเกิดขึ้นจริง
- 01
รหัสกุญแจที่อายุใช้งานคาบเกี่ยวกัน
กุญแจ API และกุญแจลงลายเซ็นเว็บฮุกของแต่ละพื้นที่ทำงานมีรหัสกุญแจกำกับ ระหว่างการหมุน ทั้งสองใช้ได้ คุณจึงย้ายตามตารางของคุณเองแล้วค่อยเพิกถอนของเก่าinternal/tenancy · internal/outbox/sign.go
- 02
พาสคีย์สำหรับทั้งสมาชิกและผู้ดูแล
WebAuthn ที่บังคับการยืนยันตัวผู้ใช้และข้อมูลรับรองแบบค้นพบได้ — ไม่ใช่ทางเลือก เพราะโทเคนพวกนี้ยืนอยู่หน้ากระแสเงิน การเข้าสู่ระบบแบบค้นพบได้จะหาบัญชีจากตัวข้อมูลรับรองเอง จึงไม่มีอะไรต้องพิมพ์ และไม่มีอะไรให้ฟิชinternal/passkey
- 03
สองชั้นด้วยแอปยืนยัน เก็บอย่างถูกวิธี
ความลับ TOTP แฮชไม่ได้ — เพราะการตรวจต้องคำนวณรหัสจากมันใหม่ — ความลับของสมาชิกจึงถูกผนึกด้วย AES-256-GCM ภายใต้กุญแจย่อยเฉพาะบริบท แทนที่จะเก็บเป็นข้อความธรรมดา ตัวนับของรหัสที่ผ่านแล้วจะถูกเขียนกลับ รหัสเดิมจึงใช้ซ้ำภายในช่วงเวลาเดียวกันไม่ได้internal/membertotp · internal/secretbox
- 04
แฮชเมื่อทำได้ ผนึกเมื่อทำไม่ได้
รหัสผ่านหรือรหัสกู้คืนจะถูกแฮช เพราะแพลตฟอร์มต้องตอบแค่ว่า “ใช่อันนี้หรือเปล่า” ส่วนความลับที่แพลตฟอร์มต้องอ่านกลับได้จะถูกผนึกแทน และที่เก็บซึ่งมีมาก่อนโครงสร้างนี้กำลังถูกย้ายมา ไม่ใช่ปล่อยไว้อย่างเดิมinternal/secretbox
ไม่มีอะไรรั่วออกไปทาง URL ที่คุณตั้งไว้
ปลายทางเว็บฮุกคืออินพุตที่ผู้โจมตีมีอิทธิพลได้โดยธรรมชาติ — มันคือ URL ที่ผู้เช่าพิมพ์เข้ามา แล้วแพลตฟอร์มจะยิงไปหามันจากในเครือข่ายของตัวเอง
ตัวส่งจะรันด่านขาออกก่อนยิงคำขอ แทนที่จะเชื่อชื่อโฮสต์ ซึ่งเป็นลำดับเดียวที่ช่วยได้จริง: การตรวจหลังแปลงชื่อ หรือการตรวจที่ตัวสตริงแทนที่จะตรวจที่หมายเลขจริง คือด่านที่ DNS rebinding ถูกออกแบบมาให้เดินผ่านพอดี ปลายทางแบบลูปแบ็กและเครือข่ายภายในอนุญาตเฉพาะในแซนด์บ็อกซ์และการทดสอบแบบครบวงจร และการผ่อนนี้เป็นแฟล็กที่ระบุชัด ไม่ใช่การเดาสภาพแวดล้อม
internal/outbox/ssrf.go · internal/outbox/dispatcher.go
เราไม่ใช่ผู้รับฝากทรัพย์สิน และโค้ดก็ปฏิเสธที่จะกลายเป็นแบบนั้น
ไม่ถือเงินสมาชิก ไม่ถือกุญแจส่วนตัว ไม่มีข้อมูลรับรองของแพลตฟอร์มอยู่ในช่องทางรับเงินของผู้เช่า
สมาชิกจ่ายให้คุณ
internal/rails
การตั้งค่าปฏิเสธของเรา
internal/rails
การถอนสั่งการ ไม่ได้ย้ายเงิน
internal/claims
ยืนยันตัวตนโดยไม่เก็บเอกสาร
เซสชันของผู้ให้บริการรันบนบัญชีของคุณเอง สิ่งที่ส่งกลับมาคือผลตัดสินและตัวอ้างอิงที่ย้อนกลับไม่ได้
ตัวอ้างอิงนั้นพอสำหรับบังคับกติกา “หนึ่งคน หนึ่งตำแหน่ง” และไม่มากกว่านั้น มันไม่พอจะประกอบตัวตนกลับขึ้นมา ซึ่งนั่นแหละคือประเด็น: วิธีเก็บสำเนาพาสปอร์ตที่ปลอดภัยที่สุดคือไม่เก็บ และการรั่วไหลก็เปิดเผยข้อมูลที่ไม่เคยถูกเก็บไม่ได้
internal/verification
สิ่งที่เราไม่อ้างว่ามี
ถ้าคุณกำลังกรอกแบบประเมินผู้ให้บริการ นี่คือแถวที่เราจะไม่ผ่าน รู้ตรงนี้ดีกว่ารู้ตอนเดือนที่สี่
See /contact#security
ส่งแบบประเมินมา หรือหยิบแซนด์บ็อกซ์ไปดูเอง
ทั้งสองทางก็ดี แต่ทางหนึ่งเร็วกว่า