สถาปัตยกรรมความปลอดภัยของ Remio อธิบายตรง ๆ

§01 · บทสรุปผู้บริหาร

Remio เป็นแอปรีโมทเดสก์ท็อปที่สร้างบนสถาปัตยกรรมแบบ zero-knowledge และเพียร์ทูเพียร์ เนื้อหาหน้าจอ ข้อมูลอินพุต และสตรีมเสียงเข้ารหัสต้นทางถึงปลายทางระหว่างอุปกรณ์ด้วย DTLS-SRTP มาตรฐานอุตสาหกรรม ซึ่งเป็นโมเดลความปลอดภัยเดียวกับที่ผลิตภัณฑ์บน WebRTC ทุกตัวใช้ ต่างจากโซลูชันแบบรวมศูนย์ เซิร์ฟเวอร์ signaling ของ Remio ช่วยเพียงการสร้างการเชื่อมต่อเริ่มต้น ไม่เคยเห็น ประมวลผล หรือเก็บข้อมูลเซสชัน

ไม่ต้องมีบัญชี ไม่มีรหัสผ่านให้เจาะ ไม่มีฐานข้อมูลข้อมูลรับรองส่วนกลาง การจับคู่อุปกรณ์ใช้คิวอาร์โค้ดหรือ Device ID และ PIN ที่อ่านจากหน้าจอของโฮสต์เอง และคีย์เซสชันทั้งหมดเป็นคีย์ชั่วคราวพร้อม Perfect Forward Secrecy แม้คีย์หนึ่งถูกเจาะ เซสชันในอดีตและอนาคตก็ยังปลอดภัยทางการเข้ารหัส สถาปัตยกรรมนี้ขจัดการโจมตีทั้งหมวดที่รบกวนคู่แข่ง เพราะไม่มีอะไรให้ขโมย

§02 · โมเดลภัยคุกคาม

สถาปัตยกรรมความปลอดภัยของ Remio ออกแบบมาเพื่อรับมือกับสถานการณ์ภัยคุกคามที่เกี่ยวข้องกับการใช้รีโมทเดสก์ท็อปทั้งในองค์กรและส่วนบุคคล เราระบุชัดเจนว่าปกป้องจากอะไรและขอบเขตความเชื่อถืออยู่ที่ใด

ภัยคุกคามที่เราปกป้อง

• การดักฟัง สื่อทั้งหมด (วิดีโอ เสียง) และช่องข้อมูล (อินพุต แป้นพิมพ์ เคอร์เซอร์) เข้ารหัสด้วย SRTP และ DTLS ตามลำดับ ผู้สังเกตเครือข่ายเห็นเพียงแพ็กเก็ตที่เข้ารหัสและสร้างเนื้อหาเซสชันกลับมาไม่ได้
• การโจมตีแบบ man-in-the-middle (MITM) การแฮนด์เชก DTLS พร้อมการตรวจลายนิ้วมือใบรับรองป้องกันการดักกลางทาง ช่อง signaling ใช้ TLS 1.3 พร้อม Perfect Forward Secrecy
• เซิร์ฟเวอร์ถูกเจาะ แม้เซิร์ฟเวอร์ signaling ของเราถูกเจาะทั้งหมด ผู้โจมตีได้เพียงเมตาดาตาการเชื่อมต่อ (ที่อยู่ IP เวลา) เนื้อหาเซสชันไม่เคยส่งผ่านหรือเก็บบนเซิร์ฟเวอร์ของเรา
• การเข้าถึงโดยไม่ได้รับอนุญาต การจับคู่ต้องสแกนคิวอาร์โค้ดของโฮสต์ พิมพ์ Device ID และ PIN ที่โฮสต์แสดง หรือลงชื่อเข้าบัญชี Remio เดียวกันทั้งสองเครื่อง ไม่มีฐานข้อมูลข้อมูลรับรองที่เข้าถึงจากระยะไกลให้โจมตี
• การขโมยข้อมูลรับรอง ไม่มีรหัสผ่าน ไม่มีบัญชี ไม่มีที่เก็บข้อมูลรับรองส่วนกลาง ความเชื่อถืออุปกรณ์สร้างผ่านการจับคู่ด้วย PIN โทเค็นเซสชัน (JWT) มีอายุสั้นและผูกกับอุปกรณ์
• การเล่นซ้ำเซสชัน การป้องกันการเล่นซ้ำในตัวของ SRTP และหมายเลขลำดับของ DTLS ป้องกันไม่ให้แพ็กเก็ตที่ดักได้ถูกนำมาเล่นซ้ำ
• การโจมตีห่วงโซ่อุปทาน ไบนารีของ Remio ทั้งหมดลงนามรหัส บิลด์ macOS ผ่านการรับรองโดย Apple บิลด์ iOS เผยแพร่ผ่าน App Store เท่านั้น

ขอบเขตความเชื่อถือ

โมเดลภัยคุกคามของเรากำหนดขอบเขตความเชื่อถือไว้สามส่วนอย่างชัดเจน

1. ขอบเขตอุปกรณ์ แต่ละอุปกรณ์ได้รับความเชื่อถือหลังยืนยัน PIN เท่านั้น การป้องกันระดับระบบปฏิบัติการ (แซนด์บ็อกซ์และที่เก็บข้อมูลที่ได้รับการป้องกันของแต่ละระบบ เช่น Keychain) ปกป้องข้อมูลบนอุปกรณ์
2. ขอบเขตเครือข่าย ข้อมูลทั้งหมดที่เดินทางถูกเข้ารหัส เราสมมติว่าเครือข่ายเป็นปรปักษ์
3. ขอบเขตเซิร์ฟเวอร์ เซิร์ฟเวอร์ของเราเองถือเป็นรีเลย์ที่ไม่น่าเชื่อถือ ช่วยให้เชื่อมต่อได้แต่ตรวจดูเนื้อหาไม่ได้

§03 · ภาพรวมสถาปัตยกรรม

Remio แยกระนาบ signaling (การตั้งค่าการเชื่อมต่อ) ออกจากระนาบข้อมูล (การสตรีม) การแยกนี้เป็นหัวใจของการออกแบบ zero-knowledge เซิร์ฟเวอร์ที่ช่วยให้คุณเชื่อมต่อไม่เคยแตะข้อมูลที่คุณแลกเปลี่ยน

Signaling เทียบกับระนาบข้อมูล

หน้าที่เดียวของเซิร์ฟเวอร์ signaling คือส่งต่อ SDP offer/answer และ ICE candidate ระหว่างอุปกรณ์ขณะตั้งค่าการเชื่อมต่อ เมื่อสร้างการเชื่อมต่อ P2P แล้ว เซิร์ฟเวอร์ signaling ไม่เกี่ยวข้องอีก

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

§04 · ชั้นการเข้ารหัส

Remio ใช้กลยุทธ์การเข้ารหัสหลายชั้น โดยแต่ละช่องสื่อสารใช้โปรโตคอลเข้ารหัสที่เหมาะกับความต้องการของมันที่สุด

Perfect forward secrecy

ทุกเซสชันของ Remio สร้างชุดคีย์เข้ารหัสชั่วคราวที่ไม่ซ้ำกันผ่านการแลกเปลี่ยนคีย์ ECDHE

• การเจาะคีย์เซสชันปัจจุบันไม่เปิดเผยเซสชันในอดีต
• การเจาะคีย์เซสชันปัจจุบันไม่เปิดเผยเซสชันในอนาคต
• คู่คีย์แต่ละคู่มีอยู่เฉพาะตลอดเซสชันเดียว
• ไม่เคยเขียนคีย์ลงดิสก์ มีอยู่เฉพาะในหน่วยความจำ

ชุดรหัส (cipher suite)

# Signaling — TLS 1.3 cipher suites (in order of preference)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

# Media — SRTP protection profile (WebRTC industry default)
SRTP_AES128_CM_SHA1_80   # AES-128 counter mode, HMAC-SHA1-80 auth

# DTLS certificates
Self-signed ECDSA (P-256), verified out-of-band via SDP fingerprints

การหมุนเวียนคีย์

คีย์ถูกหมุนเวียนโดยอัตโนมัติที่ขอบเขตต่อไปนี้

• เริ่มเซสชัน การแฮนด์เชก DTLS ใหม่สร้างคีย์ใหม่สำหรับทุกการเชื่อมต่อ
• การสร้างคีย์ SRTP คีย์สื่อได้มาจากการแฮนด์เชก DTLS และไม่ซ้ำกันในแต่ละแทร็กสื่อ
• การเชื่อมต่อใหม่ หากเซสชันถูกขัดจังหวะแล้วเชื่อมต่อใหม่ จะมีการแลกเปลี่ยนคีย์ใหม่ทั้งหมด

§05 · การพิสูจน์ตัวตนและการจับคู่

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

การจับคู่ด้วย PIN

เมื่อไคลเอนต์ต้องการเชื่อมต่อกับโฮสต์เป็นครั้งแรก กระบวนการเป็นดังนี้

1. โฮสต์แสดง PIN ตัวเลขสั้น ๆ บนหน้าจอ (หรือเป็นคิวอาร์โค้ด)
2. ไคลเอนต์ป้อน PIN ซึ่งส่งผ่านช่อง signaling ไปยังโฮสต์
3. โฮสต์ตรวจสอบ PIN แล้วยืนยันหรือปฏิเสธการจับคู่
4. เมื่อสำเร็จ จะเกิดความสัมพันธ์ความเชื่อถืออุปกรณ์
5. การเชื่อมต่อครั้งต่อไปจากอุปกรณ์เดิมไม่ต้องจับคู่ใหม่

โมเดลความเชื่อถืออุปกรณ์

เมื่อจับคู่แล้ว แต่ละอุปกรณ์ถูกระบุด้วย device ID ที่ไม่ซ้ำกัน โฮสต์เก็บรายการอุปกรณ์ที่เชื่อถือไว้ในเครื่อง ความสัมพันธ์ความเชื่อถือนี้

• เก็บในเครื่องเฉพาะบนอุปกรณ์โฮสต์ ในที่เก็บข้อมูลที่ได้รับการป้องกันซึ่งระบบของมันมีให้ ได้แก่ Keychain บน Mac ที่เก็บข้อมูลระบบแบบเข้ารหัสบน Windows ไฟล์ส่วนตัวบน Linux
• ไม่เคยส่งออก เซิร์ฟเวอร์ไม่รู้ว่าอุปกรณ์ไหนได้รับความเชื่อถือ
• เพิกถอนได้ โฮสต์ลบอุปกรณ์ที่เชื่อถือได้ทุกเมื่อ

โทเค็นเซสชัน (JWT)

หลังจับคู่ ใช้โทเค็นที่ลงนามอายุสั้น (หมดอายุใน 24 ชั่วโมง) เพื่อพิสูจน์ตัวตนกับเซิร์ฟเวอร์ signaling

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

การเข้าถึงของ AI เอเจนต์ (Remio MCP Server)

Remio กำลังขยายโมเดลความเชื่อถือเดียวกันนี้ไปยัง AI เอเจนต์ เครื่องมืออย่าง Claude Code, Codex หรือแอป Claude ควบคุมเครื่องของคุณจากระยะไกลได้ผ่าน Remio MCP Server และขอบเขตความปลอดภัยเหมือนกับที่ไคลเอนต์ที่เป็นมนุษย์ผ่าน

• ทุกอย่างถูกควบคุมด้วยการลงชื่อเข้าของคุณ เอเจนต์เข้าถึงได้เฉพาะโฮสต์ที่ออนไลน์และจับคู่กับบัญชีที่คุณยืนยันตัวตน (ลงชื่อเข้าด้วย Google หรือ Apple ผ่าน OAuth) ไม่มีบัญชีที่ยืนยันตัวตน ก็ไม่มีเครื่องมือ
• Remio เป็นตัวกลาง ไม่ใช่ผู้ปฏิบัติการ หน้าที่เดียวของ MCP server คือเปิดเผยชุดเครื่องมือที่จำกัดอยู่ในบัญชีที่ยืนยันตัวตนของคุณ และส่งให้เครื่องมือ AI ที่คุณเลือกเชื่อมต่อ Remio เริ่มเซสชันกับเครื่องของคุณเองไม่ได้ โฮสต์รับเฉพาะการเชื่อมต่อที่แสดงหลักฐานการอนุญาตของบัญชีคุณ เหมือนโมเดลความเชื่อถืออุปกรณ์ข้างต้น
• ช่องส่งที่เข้ารหัสเดียวกัน เซสชันของเอเจนต์ใช้ช่องเข้ารหัสต้นทางถึงปลายทางเดียวกับที่อธิบายใน §04 เซิร์ฟเวอร์ของเรายังเห็นเพียงบล็อบที่เข้ารหัส คุณสมบัติ zero-knowledge ใน §06 ใช้ได้เหมือนเดิม
• มองเห็นได้ หยุดได้ ตรวจสอบได้ เซสชันของเอเจนต์แสดงบนโฮสต์ขณะทำงาน ยุติได้ทันทีด้วยสวิตช์หยุดฉุกเฉิน และบันทึกในบันทึกตรวจสอบในเครื่อง

§06 · การออกแบบ zero-knowledge

ที่ Remio zero-knowledge ไม่ใช่คำการตลาด แต่เป็นข้อจำกัดทางสถาปัตยกรรม ระบบของเราออกแบบให้เนื้อหาเซสชันเข้าถึงไม่ได้โดยโครงสร้างสำหรับ Remio พนักงาน หรือบุคคลที่สาม

สิ่งที่เซิร์ฟเวอร์ของเรามองเห็น

• ที่อยู่ IP ของอุปกรณ์ที่เชื่อมต่อ (จำเป็นสำหรับระบบเครือข่าย)
• เวลาของการเชื่อมต่อ
• Device ID (ตัวระบุที่ไม่เปิดเผยความหมาย ไม่ผูกกับข้อมูลส่วนบุคคล)
• เมตาดาตา signaling: การแลกเปลี่ยน SDP offer/answer, ICE candidate

สิ่งที่เซิร์ฟเวอร์ของเรามองไม่เห็น

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

นโยบายการเก็บรักษาข้อมูล

เพราะสถาปัตยกรรม P2P ของเรา แทบไม่มีอะไรให้เก็บรักษา

• เนื้อหาเซสชัน ไม่เก็บเลย เป็นสตรีมแบบเรียลไทม์เท่านั้น
• บันทึก signaling เมตาดาตาการเชื่อมต่อเก็บไว้ได้นานสุด 30 วันเพื่อดีบัก แล้วลบ ไม่มีเนื้อหาเซสชัน
• บัญชีผู้ใช้ ไม่ต้องมีบัญชี ข้อมูล Firebase Auth ที่เป็นทางเลือกจัดการโดยโครงสร้างพื้นฐานของ Google และผู้ใช้ลบได้
• ข้อมูลอุปกรณ์ เก็บในเครื่องบนแต่ละอุปกรณ์ หากคุณเลือกลงชื่อเข้า รายการอุปกรณ์ของคุณจะซิงก์กับบัญชี (ดูนโยบายความเป็นส่วนตัว)

การไหลของข้อมูลแบบ P2P เป็นหลัก

ในการเชื่อมต่อส่วนใหญ่ (เมื่อ NAT traversal สำเร็จ) ข้อมูลไหลตรงระหว่างอุปกรณ์โดยไม่แตะเซิร์ฟเวอร์ใด ๆ

# Best case: direct P2P
Client <—— DTLS-SRTP (encrypted) ——> Host
              ↑ No server involvement

# Fallback: TURN relay
Client <— DTLS-SRTP —> TURN server <— DTLS-SRTP —> Host
                            ↑ Still E2E encrypted
                            ↑ Server sees only encrypted blobs

แม้ในกรณีสำรองที่ใช้รีเลย์ TURN เซิร์ฟเวอร์รีเลย์จัดการเฉพาะแพ็กเก็ตที่เข้ารหัส ทำหน้าที่เป็นท่อเปล่า ถอดรหัส ตรวจดู หรือแก้ไขข้อมูลไม่ได้

§07 · ความปลอดภัยของเครือข่าย

การสร้างการเชื่อมต่อ P2P

Remio ใช้โปรโตคอล ICE (Interactive Connectivity Establishment) เพื่อหาเส้นทางเชื่อมต่อที่ดีที่สุดระหว่างอุปกรณ์

1. Host candidate การเชื่อมต่อ LAN ตรงบนเครือข่ายเดียวกัน
2. Server-reflexive candidate (STUN) NAT traversal ผ่านเซิร์ฟเวอร์ STUN เพื่อค้นหา IP สาธารณะ
3. Relay candidate (TURN) รีเลย์ที่เข้ารหัสเมื่อสร้างการเชื่อมต่อตรงไม่ได้

ตัวแทน ICE ทดสอบคู่ candidate ทั้งหมดพร้อมกัน และเลือกเส้นทางที่หน่วงต่ำและเชื่อถือได้ที่สุด ให้ความสำคัญกับ P2P ตรงเสมอ

นโยบายการส่งผ่านที่กำหนดค่าได้

ค่าเริ่มต้นของการเชื่อมต่อคือเลือก P2P ตรงก่อน และสำรองไปยังรีเลย์ที่เข้ารหัสโดยอัตโนมัติ มีนโยบายที่เข้มงวดกว่า คือบังคับให้ทราฟฟิกทั้งหมดผ่านรีเลย์ หรือข้ามการค้นหาใน LAN ทั้งหมด สำหรับสภาพแวดล้อมเครือข่ายที่ล็อกแน่น

การจำกัดอัตรา

เซิร์ฟเวอร์ signaling ใช้การจำกัดอัตราอย่างเข้มงวดเพื่อป้องกันการใช้งานในทางที่ผิด

ตัวจำกัดอัตราที่หมดอายุจะถูกล้างอัตโนมัติทุก 5 นาที โดยมี TTL 10 นาที ป้องกันหน่วยความจำหมดจากการโจมตีแบบกระจาย

การป้องกัน DDoS

โครงสร้างพื้นฐาน signaling ของเราได้รับการปกป้องโดย Cloudflare ซึ่งให้

• Anycast DNS พร้อมเครือข่ายขอบทั่วโลก
• การลดผลกระทบ DDoS ชั้น 3, 4 และ 7
• Web Application Firewall (WAF)
• การจำกัดอัตราที่ขอบก่อนทราฟฟิกถึงต้นทาง
• การตรวจจับบอตและหน้าท้าทาย

§08 · ความปลอดภัยของไคลเอนต์

Remio ใช้ชุดความปลอดภัยเต็มรูปแบบของแต่ละระบบปฏิบัติการเพื่อปกป้องข้อมูลในเครื่องและรับรองความสมบูรณ์ของแอปพลิเคชัน

macOS

• การผสาน Keychain ข้อมูลสำคัญทั้งหมด (โทเค็นความเชื่อถืออุปกรณ์ JWT) เก็บใน macOS Keychain ซึ่งป้องกันด้วยข้อมูลลงชื่อเข้าของผู้ใช้และการเข้ารหัสระดับฮาร์ดแวร์
• App Sandbox Remio ทำงานในสภาพแวดล้อมแซนด์บ็อกซ์ด้วยสิทธิ์ขั้นต่ำ การจับภาพหน้าจอและการช่วยเหลือพิเศษต้องได้รับอนุมัติจากผู้ใช้อย่างชัดเจน
• การลงนามรหัส บิลด์ทั้งหมดลงนามด้วยใบรับรอง Apple Developer
• Notarization บิลด์ macOS ผ่านการรับรองโดย Apple ยืนยันว่าไม่มีมัลแวร์ที่รู้จัก
• Hardened runtime ป้องกันการฉีดโค้ด การแย่งไลบรารี และการดีบักในบิลด์ใช้งานจริง

iOS

• App Transport Security (ATS) การเชื่อมต่อเครือข่ายทั้งหมดต้องใช้ HTTPS/TLS ไม่ตั้งค่าข้อยกเว้น
• การป้องกันข้อมูล รายการ Keychain เข้ารหัสด้วยคีย์ที่อุปกรณ์สร้างจากฮาร์ดแวร์ของตัวเอง และรายการที่ระบุว่าเฉพาะอุปกรณ์นี้จะไม่ออกจากอุปกรณ์ แม้ในข้อมูลสำรอง
• Keychain Services ข้อมูลรับรองอุปกรณ์เก็บใน iOS Keychain ด้วยคลาสการป้องกัน kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
• การตรวจสอบของ App Store บิลด์ iOS ทั้งหมดผ่านกระบวนการตรวจสอบความปลอดภัยของ Apple
• ไม่มีข้อมูลเบื้องหลัง แอปไม่เก็บหรือส่งข้อมูลเมื่ออยู่เบื้องหลัง

การลงนามรหัสและการตรวจสอบ

# Verify Remio macOS binary — verify_signature.sh
$ codesign --verify --deep --strict "Remio Host.app"
# Remio Host.app: valid on disk

$ spctl --assess --verbose "Remio Host.app"
# Remio Host.app: accepted
# source=Notarized Developer ID

§09 · การรับมือเหตุการณ์

ประวัติด้านความปลอดภัย

ณ เดือนกุมภาพันธ์ 2026 Remio ไม่มีประวัติการถูกเจาะหรือเหตุการณ์ด้านความปลอดภัย สถาปัตยกรรม zero-knowledge ของเราลดพื้นผิวการโจมตีลงอย่างมาก ไม่มีฐานข้อมูลข้อมูลรับรองหรือข้อมูลเซสชันส่วนกลางให้เล็งเป้า

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

เราสนับสนุนการเปิดเผยอย่างรับผิดชอบจากนักวิจัยด้านความปลอดภัย หากคุณพบช่องโหว่ที่อาจเกิดขึ้น

1. ส่งอีเมลถึง security@remio.net พร้อมคำอธิบายโดยละเอียด
2. ระบุขั้นตอนการทำซ้ำ หากมี
3. เราตอบรับภายใน 48 ชั่วโมง
4. เราตั้งเป้าแก้ช่องโหว่ที่ยืนยันแล้วภายใน 30 วัน
5. ผู้รายงานได้รับการให้เครดิตใน changelog ด้านความปลอดภัยของเรา เว้นแต่ต้องการปกปิดตัวตน

นโยบายการเปิดเผยอย่างรับผิดชอบ

• เราขอช่วงเวลา 90 วันก่อนเปิดเผยต่อสาธารณะ
• เราไม่ดำเนินคดีกับนักวิจัยที่กระทำโดยสุจริต
• เราจัดลำดับการแก้ไขตามความรุนแรง ได้แก่ วิกฤต สูง กลาง ต่ำ
• โครงการ bug bounty อย่างเป็นทางการอยู่ในแผนงานของเรา

กระบวนการรับมือเหตุการณ์

เมื่อมีปัญหาด้านความปลอดภัยที่ยืนยันแล้ว

1. การควบคุม แยกระบบที่ได้รับผลกระทบภายใน 1 ชั่วโมง
2. การประเมิน กำหนดขอบเขตและผลกระทบภายใน 24 ชั่วโมง
3. การสื่อสาร แจ้งผู้ใช้ที่ได้รับผลกระทบภายใน 72 ชั่วโมง (สอดคล้อง GDPR)
4. การแก้ไข ปล่อยแพตช์ผ่านโครงสร้างพื้นฐานอัปเดตอัตโนมัติ
5. การทบทวนหลังเหตุการณ์ เผยแพร่รายงานความโปร่งใส

§10 · การปฏิบัติตามข้อกำหนด

ความพร้อมด้าน GDPR

สถาปัตยกรรม zero-knowledge ของ Remio เป็นมิตรกับ GDPR โดยธรรมชาติ เพราะเราจำกัดการเก็บข้อมูลให้เหลือน้อยที่สุดเท่าที่จำเป็นทางเทคนิค

• การลดข้อมูลให้น้อยที่สุด เราเก็บเฉพาะสิ่งที่จำเป็นต่อการสร้างการเชื่อมต่อ
• สิทธิ์ในการลบ เนื่องจากเราไม่เก็บเนื้อหาของผู้ใช้ จึงไม่มีอะไรให้ลบ ข้อมูลบัญชีที่เป็นทางเลือกลบได้เมื่อร้องขอ
• การโอนย้ายข้อมูล ข้อมูลความเชื่อถืออุปกรณ์เก็บในเครื่องและผู้ใช้ควบคุมเอง
• ความยินยอม การจับคู่ด้วย PIN เป็นกลไกความยินยอมที่ชัดเจนสำหรับแต่ละอุปกรณ์
• ไม่มีการโอนเนื้อหาข้ามพรมแดน การเชื่อมต่อ P2P เก็บข้อมูลไว้ระหว่างอุปกรณ์ ไม่เข้าสู่โครงสร้างพื้นฐานของเรา

SOC 2

ยังไม่มี

• การตรวจสอบความปลอดภัยอิสระ ยังไม่มีการทดสอบเจาะระบบหรือตรวจสอบโค้ดโดยบุคคลที่สาม
• SOC 2 Type I ยังไม่มีรายงาน
• SOC 2 Type II ยังไม่มีรายงาน
• โครงการ bug bounty รางวัลสำหรับการเปิดเผยอย่างรับผิดชอบอย่างเป็นทางการ

ที่ตั้งของข้อมูล

เพราะ Remio เป็น P2P เป็นหลัก ข้อมูลเซสชันอยู่ที่ใดก็ตามที่อุปกรณ์ของคุณอยู่ ข้อมูลของคุณไม่เคยออกจากการเชื่อมต่อตรงระหว่างอุปกรณ์ เซิร์ฟเวอร์ signaling (โฮสต์ที่ Cloudflare และ DigitalOcean) ประมวลผลเฉพาะเมตาดาตาการเชื่อมต่อ และเมตาดาตานี้ไม่ผูกกับข้อมูลส่วนบุคคลใด ๆ

§11 · เปรียบเทียบกับทางเลือกอื่น

อุตสาหกรรมรีโมทเดสก์ท็อปเผชิญเหตุถูกเจาะที่เป็นข่าวใหญ่หลายครั้ง นี่คือความแตกต่างพื้นฐานของสถาปัตยกรรม Remio จากทางเลือกแบบรวมศูนย์

ทำไมสถาปัตยกรรมแบบรวมศูนย์จึงล้มเหลว

ปัญหาพื้นฐานของบริการรีโมทเดสก์ท็อปแบบรวมศูนย์คือการถูกเจาะเพียงครั้งเดียวกระทบผู้ใช้ทั้งหมด เมื่อเซิร์ฟเวอร์ใช้งานจริงของ AnyDesk ถูกเจาะในเดือนกุมภาพันธ์ 2024 ผู้โจมตีขโมยใบรับรองการลงนามรหัส ซึ่งอาจใช้เผยแพร่มัลแวร์ที่ปลอมเป็นซอฟต์แวร์ AnyDesk ที่ถูกต้อง รหัสผ่านผู้ใช้ทั้งหมดต้องรีเซ็ต

เมื่อ APT29 (กลุ่มที่รัฐรัสเซียหนุนหลัง) เจาะเครือข่ายองค์กรของ TeamViewer ในเดือนมิถุนายน 2024 ก็เกิดคำถามเรื่องความสมบูรณ์ของตัวผลิตภัณฑ์ เพราะสถาปัตยกรรมแบบรวมศูนย์หมายความว่าผู้ให้บริการมีความสามารถทางเทคนิคที่จะเข้าถึงเซสชัน

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

§12 · บทสรุป

ความปลอดภัยของ Remio ไม่ใช่ชุดฟีเจอร์ที่เสริมเข้าไปในผลิตภัณฑ์ แต่เป็นผลของการตัดสินใจทางสถาปัตยกรรมตั้งแต่วันแรก ด้วยการเลือก P2P แทนรวมศูนย์ การจับคู่ด้วย PIN แทนรหัสผ่าน และ zero-knowledge แทนการเก็บข้อมูล เราจึงสร้างรีโมทเดสก์ท็อปที่ความปลอดภัยเป็นสถานะเริ่มต้น ไม่ใช่การอัปเกรดทางเลือก

เราเชื่อว่าความเป็นส่วนตัวไม่ใช่ทางเลือก และความไว้วางใจควรได้มาจากความโปร่งใส ไม่ใช่เรียกร้องผ่านข้อกำหนดการให้บริการ ไวต์เปเปอร์ฉบับนี้เป็นส่วนหนึ่งของคำมั่นนั้น

สำหรับคำถาม การตรวจสอบความปลอดภัยระดับองค์กร หรือการรายงานช่องโหว่

• สอบถามด้านความปลอดภัย: security@remio.net
• ฝ่ายขายองค์กร: enterprise@remio.net
• ทั่วไป: hello@remio.net