ความปลอดภัยของข้อมูล

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

ผู้ใช้เห็นเฉพาะงานของตนและงานที่ถูกแชร์ให้ โดยบังคับสองชั้น:

• ตัวกรองเจ้าของในโค้ด — คิวรีที่ดึงงานของผู้ใช้กรองด้วยรหัสเจ้าของ (owner_id) นี่คือรั้วรายบุคคลที่ทำงานจริงในทุกวันนี้ เราตรวจทุกเราเตอร์ของ API เมื่อ 15 สิงหาคม 2569 และไม่พบจุดที่ขาดตัวกรองนี้ — ขอให้อ่านว่าเป็นผลการตรวจ ณ เวลานั้น ไม่ใช่กฎที่เครื่องบังคับอัตโนมัติกับโค้ดที่เขียนเพิ่มภายหลัง
• Row-level security ในฐานข้อมูล — ตารางงานเปิดและบังคับ (FORCE) row-level security ไว้ใต้ชั้นนั้นอีกชั้น
• แอปต่อฐานข้อมูลด้วยบัญชีที่ไม่ใช่ superuser — บทบาท app_rls ซึ่งไม่สามารถข้าม row-level security ได้ ถ้าเซิร์ฟเวอร์ถูกตั้งค่าให้ต่อด้วยบทบาทที่ข้ามได้ ระบบจะปฏิเสธการบูตทันที ในโหมด production ไม่ใช่แค่เตือน

Per-user separation is enforced twice: an explicit owner filter in the queries that read your work — audited across every API router on 15 August 2026 with no gap found, which is an audit result at a point in time and not a rule the toolchain enforces on code written since — with row-level security enabled and FORCEd underneath it. The application connects as the non-superuser app_rls role, which cannot bypass RLS — and a production boot with a bypassing role aborts rather than warning.

รายละเอียดของสิ่งที่เก็บและไม่เก็บอยู่ที่ นโยบายความเป็นส่วนตัว และรายการข้ออ้างพร้อมหลักฐานของแต่ละข้ออยู่ที่ สิ่งที่เรารับปาก

• รหัสผ่านเก็บเป็น bcrypt hash เท่านั้น ไม่มีที่ใดในระบบเก็บรหัสผ่านจริง และเราอ่านรหัสผ่านของคุณไม่ได้
• การเข้าสู่ระบบใช้โทเคนแบบมีอายุ และผูกกับตัวนับรุ่นของโทเคน บนบัญชี — เมื่อคุณเปลี่ยนรหัสผ่านหรือกดออกจากระบบ ตัวนับจะถูกเลื่อน และโทเคนทุกใบที่ออกไปก่อนหน้านั้น (ทุกอุปกรณ์) ใช้ไม่ได้อีก ตรวจซ้ำทุกคำขอ ไม่ต้องรอหมดอายุ
• การเข้าสู่ระบบและการสมัครมีการจำกัดอัตราคำขอ และบัญชีที่ถูกล็อกตอบกลับด้วยข้อความเดียวกับรหัสผ่านผิด — ไม่บอกผู้โจมตีว่าบัญชีนั้นมีอยู่จริง

Passwords are stored only as bcrypt hashes — the plaintext is never kept and cannot be read back. Sessions carry a per-account token-version claim checked on every request: changing a password or signing out increments it, which invalidates every outstanding token on every device immediately rather than waiting for expiry. Login and registration are rate-limited, and a locked account returns the same generic response as a wrong password.

กลไกที่ทำงานอยู่จริง:

• สแนปช็อตเข้ารหัสทุกคืน — ฐานข้อมูลทั้งก้อน ไฟล์ที่ผู้ใช้อัปโหลด และไฟล์แนบของเอกสาร ถูกเก็บในสแนปช็อตเดียว เพื่อให้การกู้คืนได้จุดเวลาที่สอดคล้องกันทั้งระบบ
• สำเนานอกเครื่อง — สแนปช็อตถูกคัดลอกต่อไปยังที่เก็บอ็อบเจ็กต์นอกเครื่อง ไฟไหม้หรือดิสก์เสียที่เครื่องเดียวจึงไม่ทำให้สำเนาสำรองหายไปพร้อมกัน
• มีสคริปต์ทดสอบการกู้คืน และผ่านการทดสอบแล้ว — สคริปต์กู้สแนปช็อตลงฐานข้อมูลชั่วคราวแยกต่างหาก (ไม่แตะระบบจริง) แล้วตรวจว่าจำนวนตาราง จำนวนนโยบาย row-level security จำนวนไมเกรชันที่ลงแล้ว และไฟล์ที่ดัมป์ฐานข้อมูลอย่างเดียวกู้ไม่ได้ ครบถ้วนตรงกับระบบจริง

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

Nightly encrypted snapshots capture the database, uploads and document attachments as a single consistent point, and are copied onward to off-box object storage. A restore-test script exists and has passed: it restores a snapshot into a throwaway database and asserts the table count, RLS policy count, applied-migration count and the files a database dump alone cannot restore. Stated plainly: that script is run manually — no schedule triggers it — and DekEn publishes no recovery-time or recovery-point target, because none has been committed to. A number nobody has agreed to does not belong on this page.

ข้อเท็จจริงด้านปฏิบัติการ — ตรวจสอบจากภายนอกไม่ได้

เมื่อแอปเกิดข้อผิดพลาด รายละเอียดของข้อผิดพลาด (stack trace) ถูกส่งไปยังระบบติดตามข้อผิดพลาดที่ DekEn ติดตั้งและดูแลเอง บนเครื่องเดียวกับที่รันบริการ — ไม่ได้ส่งไปยังบริการของบริษัทภายนอก การรับส่งเกิดขึ้นภายในระบบท่อภายในของเครื่องนั้น ไม่มี stack trace ออกจากเครื่อง

Application errors are reported to a self-hosted error tracker running on the same box as the service, over its internal network — not to a third-party SaaS. No stack trace leaves the machine.

ข้อเท็จจริงด้านปฏิบัติการ — ตรวจสอบจากภายนอกไม่ได้

พบช่องโหว่ กรุณาแจ้งมาที่ [email protected] หรือเปิดเรื่องที่ หน้าติดต่อทีมงาน พร้อมขั้นตอนการทำซ้ำ URL ที่เกี่ยวข้อง และเวลาโดยประมาณที่ทดสอบ เราตอบกลับปกติภายใน 1-2 วันทำการ เท่ากับช่องทางสนับสนุนอื่น ๆ — เราไม่มีทีมเฝ้าระวังตลอด 24 ชั่วโมง และไม่รับปากเวลาตอบกลับที่เร็วกว่านั้น

เราไม่มีโครงการให้เงินรางวัล (bug bounty) และการทดสอบความปลอดภัยกับระบบจริงโดยไม่ได้รับอนุญาตเป็นลายลักษณ์อักษรขัดกับ ข้อกำหนดการใช้บริการ ข้อ 3 — เขียนมาขออนุญาตก่อนได้เสมอ

Report vulnerabilities to [email protected] or through the support page, with reproduction steps, the URL, and roughly when you tested. Replies come on the same expectation as any other support request; there is no 24/7 security desk and no faster turnaround is promised. There is no bug bounty, and unauthorised security testing against production is a breach of §3 of the Terms — ask first, in writing.