ความปลอดภัย

การยืนยันตัวตน

บัญชีถูกจัดการโดย Supabase Auth ด้วยอีเมลและรหัสผ่าน Google OAuth หรือ GitHub OAuth หลังจากเข้าสู่ระบบ เบราว์เซอร์ของคุณจะเก็บ session token (JWT หนึ่งตัว) ที่จะถูกรีเฟรชโดยอัตโนมัติโดย middleware ของแพลตฟอร์ม ดังนั้นเซสชันที่ใช้งานอยู่จึงไม่หมดอายุอย่างเงียบ ๆ ระหว่างที่คุณกำลังทำงาน

API ยอมรับ session token นั้นในสองรูปแบบ: ไม่ว่าจะเป็นคุกกี้เซสชันที่แดชบอร์ดส่งอยู่แล้ว หรือเป็นส่วนหัว Authorization Bearer การเข้าถึงแบบโปรแกรมโดยไม่ต้องเข้าสู่ระบบเบราว์เซอร์ใช้ API key แทน ซึ่งอธิบายไว้ด้านล่าง endpoint จะปฏิเสธคำขอที่ไม่มีข้อมูลยืนยันตัวตนที่ถูกต้อง มีเพียง route สาธารณะที่ระบุไว้อย่างชัดเจนเท่านั้น เช่น การตรวจสอบสุขภาพและแบบฟอร์มติดต่อ ที่ทำงานได้โดยไม่ต้องยืนยันตัวตน

บทบาทและสิทธิ์

ทุกบัญชีมีบทบาทเดียวเท่านั้น: CLIENT, OPERATOR หรือ ADMIN ลูกค้าเป็นเจ้าของหุ่นยนต์และจ่ายเงินสำหรับเซสชัน ผู้ควบคุมควบคุมหุ่นยนต์และได้รับเงินจากเซสชัน และผู้ดูแลระบบดำเนินการแพลตฟอร์ม คุณเลือกระหว่างลูกค้าและผู้ควบคุมระหว่าง onboarding บทบาทผู้ดูแลระบบถูกกำหนดโดยผู้ดูแลแพลตฟอร์มและไม่สามารถเลือกได้ด้วยตนเอง

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

API Key

API key ให้สคริปต์และเซิร์ฟเวอร์เข้าถึงได้โดยไม่ต้องเข้าสู่ระบบเบราว์เซอร์ คุณสร้างและเพิกถอนมันได้ที่ /dashboard/settings คีย์มีคำนำหน้า ayr_live_ และถูกส่งเป็นส่วนหัว Authorization Bearer คีย์หนึ่งทำงานด้วยบทบาทและสิทธิ์ของบัญชีที่สร้างมัน ดังนั้นคีย์ที่รั่วไหลจึงร้ายแรงพอ ๆ กับรหัสผ่านที่รั่วไหล

• เก็บคีย์ไว้ฝั่งเซิร์ฟเวอร์ มันไม่ควรอยู่ใน JavaScript ฝั่ง client แอปมือถือ หรือ repository สาธารณะ
• ใช้หนึ่งคีย์ต่อหนึ่งการเชื่อมต่อ เมื่อมีอะไรรั่วไหล คุณจะได้เพิกถอนแค่ผู้ใช้รายเดียว ไม่ใช่ทั้งหมด
• หมุนเวียนโดยไม่มีการหยุดชะงัก: สร้างคีย์ทดแทนก่อน นำไปใช้งาน แล้วจึงเพิกถอนคีย์เก่าที่ /dashboard/settings
• เพิกถอนทันทีเมื่อมีข้อสงสัย การสร้างคีย์ใหม่ใช้เวลาเพียงไม่กี่วินาที ผู้โจมตีที่มีคีย์ที่ถูกต้องสามารถทำทุกอย่างที่บัญชีของคุณทำได้

กลไกป้องกันระหว่างการควบคุมแบบสด

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

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

บันทึกการตรวจสอบ

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

นอกเหนือจากเซสชัน การกระทำสำคัญของแพลตฟอร์มจะถูกบันทึกไว้ใน audit log พร้อม id ของผู้ใช้ที่กระทำการ การกระทำนั้น ทรัพยากรที่ได้รับผลกระทบ และ metadata การเปลี่ยนแปลงโปรไฟล์ ธุรกรรมที่เกี่ยวข้องกับการชำระเงิน และการกระทำของผู้ดูแลระบบทั้งหมดล้วนทิ้งบันทึกไว้ บันทึกการตรวจสอบถูกเขียนโดยแพลตฟอร์มและไม่สามารถแก้ไขได้ผ่านอินเทอร์เฟซใด ๆ ที่ผู้ใช้เข้าถึงได้

การเข้ารหัสและการปกป้องข้อมูล

ปริมาณข้อมูลทั้งหมดที่เข้าและออกจากแพลตฟอร์มถูกเข้ารหัสระหว่างการส่งด้วย TLS รวมถึงสตรีมวิดีโอและสัญญาณควบคุม ในระดับข้อมูล นโยบาย row-level security จำกัดการเข้าถึงฐานข้อมูลตามบัญชี ข้อมูลการชำระเงินคือขอบเขตที่ชัดเจนที่สุดของทั้งหมด บัตรและข้อมูลธนาคารถูกจัดการโดย Stripe เท่านั้นและไม่เคยแตะต้องเซิร์ฟเวอร์ของ AY-Robots เลย

การรายงานช่องโหว่

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

คำถามที่พบบ่อย