ความปลอดภัยและการปฏิบัติตามข้อกำหนด

การยืนยันตัวตน (Authentication)

วิธีการเข้าสู่ระบบ

Ocriva รองรับการยืนยันตัวตน 4 รูปแบบ เลือกใช้ตามความเหมาะสมกับการทำงานของคุณ

JWT Token

หลังจากเข้าสู่ระบบสำเร็จ Ocriva จะส่งกลับ Token 2 ชนิด:

• Access Token — อายุสั้น ใช้แนบกับทุก API Request
• Refresh Token — อายุยาว ใช้ขอ Access Token ใหม่เมื่อของเดิมหมดอายุ

แนบ Access Token กับทุก Request ดังนี้:

# ใช้ JWT access token
curl -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  https://api.ocriva.com/upload/ORG_ID/file

การขอ Access Token ใหม่:

# Refresh access token
curl -X POST https://api.ocriva.com/auth/refresh \
  -H "Content-Type: application/json" \
  -d '{ "refreshToken": "YOUR_REFRESH_TOKEN" }'

API Token

API Token ออกแบบมาสำหรับการเชื่อมต่อระหว่าง Server ที่ไม่ต้องการ Session ของผู้ใช้ แต่ละ Token มีคุณสมบัติดังนี้:

• สร้างต่อองค์กร — จัดการที่ Organization → API Tokens
• กำหนดขอบเขตถึง Project — Token เข้าถึงได้เฉพาะ Project ที่กำหนดเท่านั้น
• ปรับแต่งได้ ด้วย:
  • สิทธิ์ (Permissions) — อ่าน เขียน ลบ แยกตามประเภท Resource
  • IP Whitelist — จำกัดการใช้งานจาก IP Address ที่กำหนดเท่านั้น
  • วันหมดอายุ — Token จะหยุดทำงานโดยอัตโนมัติเมื่อถึงวันที่กำหนด

# ใช้ API Token (รูปแบบ Authorization header เดียวกับ JWT)
curl -H "Authorization: Bearer YOUR_API_TOKEN" \
  https://api.ocriva.com/upload/ORG_ID/file

การกำหนดสิทธิ์ (Authorization)

Role-Based Access Control (RBAC)

สมาชิกทุกคนในองค์กรจะได้รับบทบาทหนึ่งใน 4 บทบาท บทบาทกำหนดว่าสมาชิกสามารถทำอะไรได้บ้างในองค์กร

นอกจากบทบาทแล้ว Owner และ Admin ยังสามารถกำหนด สิทธิ์แบบละเอียด ให้สมาชิกแต่ละคน:

• canCreateTemplates — สร้างและแก้ไข Template
• canManageMembers — เชิญและลบสมาชิก
• canManageProjects — สร้าง แก้ไข และลบ Project
• canViewAnalytics — ดู Analytics และรายงานการใช้งาน

การแยกข้อมูลต่อองค์กร

ทุก API Request จะถูกตรวจสอบว่าผู้ใช้มีสิทธิ์เข้าถึง Resource ขององค์กรนั้นหรือไม่ ระบบบังคับใช้ผ่าน OrganizationGuard ที่ทำงานในทุก Endpoint:

• ผู้ใช้ต้องเป็นสมาชิกที่ active ขององค์กรนั้น
• บทบาทของผู้ใช้ต้องอนุญาตการกระทำที่ร้องขอ
• ไม่มีทางเข้าถึงข้อมูลข้ามองค์กรได้ แม้จะมี JWT ที่ถูกต้อง

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

การแยกข้อมูล Multi-Tenant

Ocriva เป็นแพลตฟอร์ม Multi-Tenant ข้อมูลของแต่ละองค์กรถูกแยกไว้หลายชั้น:

• Database — ทุก Query มี Filter organizationId เสมอ ข้อมูลขององค์กรหนึ่งจะไม่ปรากฏใน Query ขององค์กรอื่น
• File Storage — แต่ละองค์กรใช้ Path Prefix แยกกันใน Storage Bucket
• Billing และ Credits — ยอด Credit การใช้งาน และใบแจ้งหนี้แยกต่างหากต่อองค์กร
• สมาชิก — การเป็นสมาชิกและสิทธิ์มีผลเฉพาะภายในองค์กรนั้น ไม่มีบทบาทระดับแพลตฟอร์ม

ข้อมูลที่จัดเก็บ (Data at Rest)

• เอกสารจัดเก็บใน Supabase Storage หรือ Google Cloud Storage ทั้งสองใช้การเข้ารหัสที่ระดับ Provider
• ฐานข้อมูล (MongoDB) มีการเข้ารหัสที่ระดับ Provider
• Secret, API Key และ Credential ทั้งหมดจัดการผ่าน Doppler — ไม่มีการเขียนลงใน Source Code หรือไฟล์ Configuration

ข้อมูลระหว่างการรับส่ง (Data in Transit)

• ทุก API Communication ใช้ HTTPS/TLS — ไม่รับ Plain HTTP
• WebSocket Connection ใช้ WSS
• Webhook Payload ลงลายเซ็นด้วย HMAC-SHA256 ให้ผู้รับตรวจสอบความถูกต้องได้

การเก็บรักษาไฟล์ (File Retention)

• แต่ละ Project มี นโยบาย File Retention ที่ตั้งค่าได้ — ไฟล์ที่เกินระยะเวลาจะถูกลบอัตโนมัติ
• การลบในแอปพลิเคชันเป็นแบบ Soft Delete — Record ถูกซ่อนจาก Query แต่ข้อมูลยังคงอยู่จนกว่าจะถึงเวลา Retention หรือมีการลบแบบ Hard Delete

ความปลอดภัย Webhook

การตรวจสอบลายเซ็น (Signature Verification)

ทุก Webhook Delivery จาก Ocriva จะมี Header 2 ตัว:

ตรวจสอบ Signature ใน Webhook Handler ก่อนประมวลผล Payload:

const crypto = require('crypto');
 
function verifyWebhookSignature(rawBody, signature, secret) {
  const expected = crypto
    .createHmac('sha256', secret)
    .update(rawBody) // ใช้ raw request body string ไม่ใช่ parsed object
    .digest('hex');
 
  return crypto.timingSafeEqual(
    Buffer.from(signature),
    Buffer.from(expected)
  );
}
 
// ตัวอย่างกับ Express
app.post('/webhook', express.raw({ type: 'application/json' }), (req, res) => {
  const sig = req.headers['x-webhook-signature'];
  const secret = process.env.WEBHOOK_SECRET;
 
  if (!verifyWebhookSignature(req.body.toString(), sig, secret)) {
    return res.status(401).send('Invalid signature');
  }
 
  const event = JSON.parse(req.body);
  // ประมวลผล event...
  res.sendStatus(200);
});

แต่ละ Webhook Endpoint มี Secret เป็นของตัวเอง สร้างขึ้นตอน Endpoint ถูกสร้าง คุณสามารถหมุน Secret ได้ทุกเมื่อที่ Organization → Webhooks

แนวปฏิบัติที่ดีด้านความปลอดภัย API

ปฏิบัติตามแนวทางเหล่านี้เพื่อให้การใช้งานปลอดภัย:

1. ใช้ API Token สำหรับ Server-to-Server และ JWT สำหรับ User Session — อย่านำ JWT ของผู้ใช้ไปใช้ใน Script อัตโนมัติ
2. กำหนดวันหมดอายุ สำหรับ API Token ทุกตัว — หมุนเวียน Token สม่ำเสมอ
3. เปิดใช้ IP Whitelist — จำกัด API Token ให้ใช้ได้เฉพาะจาก IP Address ที่รู้จักของ Server
4. ใช้หลัก Least Privilege — ให้สิทธิ์เฉพาะสิ่งที่ Token นั้นต้องการสำหรับงานเฉพาะ
5. เก็บ Secret ใน Environment Variable — ใช้ Secrets Manager (Doppler, AWS Secrets Manager เป็นต้น) ห้าม Hardcode Token
6. ใช้ HTTPS เท่านั้น — ห้ามส่ง Token ผ่านการเชื่อมต่อ Plain HTTP
7. ตรวจสอบ Log — ติดตาม Webhook Delivery Log และรูปแบบการใช้งาน API เพื่อหาความผิดปกติ
8. ตรวจสอบ Webhook Signature — ยืนยัน Payload ทุกชิ้นที่รับใน Production

การปฏิบัติตามข้อกำหนด (Compliance)

Ocriva มีฟีเจอร์ที่ช่วยให้คุณสามารถปฏิบัติตามข้อกำหนดด้านกฎระเบียบและการจัดการข้อมูล ทั้งนี้ภาระหน้าที่ด้านการปฏิบัติตามขึ้นอยู่กับวิธีที่คุณใช้แพลตฟอร์มและกฎระเบียบที่บังคับใช้กับองค์กรของคุณ

พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล (PDPA)

พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) เป็นกฎหมายคุ้มครองข้อมูลหลักของประเทศไทย มีผลบังคับใช้กับองค์กรที่เก็บรวบรวม ใช้ หรือเปิดเผยข้อมูลส่วนบุคคลของบุคคลในประเทศไทย

สิทธิ์ของเจ้าของข้อมูลภายใต้ PDPA ที่เกี่ยวข้อง:

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

ฟีเจอร์ของ Ocriva ที่เกี่ยวข้องกับ PDPA:

• การจัดการความยินยอม (Consent Management) — โมดูลในตัวสำหรับบันทึกความยินยอมของผู้ใช้ก่อนเก็บข้อมูลส่วนบุคคล รองรับการบันทึกวันเวลาและเวอร์ชันของนโยบาย
• นโยบาย Data Retention — ตั้งค่าได้ต่อ Project เพื่อจำกัดระยะเวลาที่ข้อมูลส่วนบุคคลถูกเก็บ
• สิทธิ์การลบข้อมูล — รองรับทั้ง Soft Delete และ Hard Delete เพื่อตอบสนองคำร้องขอลบข้อมูล
• การควบคุมการเข้าถึง — RBAC จำกัดว่าใครสามารถดูและส่งออกข้อมูลได้
• Log การดำเนินการ — บันทึกว่าใครเข้าถึงข้อมูลใด เมื่อไหร่

แนวปฏิบัติสำหรับ PDPA:

1. ใช้โมดูล Consent เพื่อขอความยินยอมก่อนประมวลผลข้อมูลส่วนบุคคล
2. กำหนด Retention Policy ให้สั้นที่สุดเท่าที่จำเป็นสำหรับวัตถุประสงค์ทางธุรกิจ
3. จำกัดสิทธิ์ทีม — ให้เข้าถึงข้อมูลส่วนบุคคลเฉพาะผู้ที่จำเป็นต้องใช้
4. มีขั้นตอนสำหรับตอบสนองคำร้องขอของเจ้าของข้อมูลภายใน 30 วันตามที่กฎหมายกำหนด
5. จัดทำบันทึกกิจกรรมการประมวลผลข้อมูล (Records of Processing Activities)

ปรึกษานักกฎหมายเพื่อประเมินภาระหน้าที่ด้าน PDPA โดยเฉพาะของคุณ

การประมวลผลผ่าน AI Provider

เอกสารที่อัปโหลดไป Ocriva จะถูกส่งต่อไปยัง AI Provider เพื่อประมวลผล แต่ละ Provider มีนโยบายด้าน Data ของตัวเอง:

• OpenAI — อยู่ภายใต้นโยบายการใช้งานข้อมูล API ของ OpenAI
• Google Gemini — อยู่ภายใต้ข้อกำหนดการประมวลผลข้อมูลของ Google Cloud
• Anthropic Claude — อยู่ภายใต้นโยบายการใช้งาน API ของ Anthropic

ข้อแนะนำทั่วไป

• ใช้ Project-level Retention Policy เพื่อลบเอกสารอัตโนมัติหลังประมวลผลเสร็จ
• กำหนด Role ด้วย สิทธิ์น้อยที่สุดที่จำเป็น สำหรับสมาชิกแต่ละคน
• ตรวจสอบ API Token สม่ำเสมอ — ยกเลิก Token ที่ไม่ใช้และตรวจสอบ Scope
• เปิดใช้ Webhook Signature Verification สำหรับทุก Endpoint ใน Production