บันทึกการตรวจสอบ (Audit Trail)

ภาพรวม

Audit Trail คือบันทึกแบบ append-only ที่ป้องกันการแก้ไขย้อนหลัง ครอบคลุมทุกการกระทำสำคัญที่เกิดขึ้นภายในองค์กรของคุณ ทุกครั้งที่สมาชิกสร้าง Project เชิญเพื่อนร่วมงาน อัปเดต Template หรือหมุนเวียน API Token Ocriva จะบันทึก Entry ที่ระบุว่าใครเป็นผู้ดำเนินการ มีการเปลี่ยนแปลงอะไร เกิดขึ้นเมื่อไหร่ และ Request มาจากที่ไหน

Audit Log ถูกบันทึกโดยอัตโนมัติ — ไม่ต้องเปิดใช้หรือตั้งค่าใดเพิ่มเติม ทุกองค์กรบน Ocriva มีประวัติ Audit ครบถ้วนนับตั้งแต่วันที่องค์กรถูกสร้าง

ประโยชน์หลัก:

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

NOTE

Audit Log มีขอบเขตต่อองค์กร สมาชิกสามารถดูประวัติ Audit ได้เฉพาะองค์กรที่ตนเองเป็นสมาชิกเท่านั้น ไม่มีการเข้าถึงข้อมูลข้ามองค์กรใด ๆ

การกระทำที่ถูกติดตาม

Ocriva ติดตาม 23 การกระทำใน 6 ประเภท Entity ทุกการกระทำใช้รูปแบบ entity.verb (เช่น project.created, member.removed)

Organization

การกระทำ	คำอธิบาย
`organization.created`	มีการสร้างองค์กรใหม่
`organization.updated`	มีการเปลี่ยนแปลงการตั้งค่าหรือชื่อองค์กร
`organization.deleted`	องค์กรถูกลบออก

Member

การกระทำ	คำอธิบาย
`member.invited`	มีการเชิญสมาชิกใหม่เข้าองค์กร
`member.role_updated`	มีการเปลี่ยนบทบาทของสมาชิกที่มีอยู่
`member.removed`	สมาชิกถูกนำออกจากองค์กร
`member.left`	สมาชิกออกจากองค์กรด้วยตนเอง
`invitation.accepted`	ผู้ถูกเชิญตอบรับคำเชิญแล้ว

Project

การกระทำ	คำอธิบาย
`project.created`	มีการสร้าง Project ใหม่
`project.updated`	มีการแก้ไขการตั้งค่า Project
`project.deleted`	Project ถูกลบออก
`project.member.added`	มีการเพิ่มสมาชิกเข้า Project
`project.member.updated`	มีการอัปเดตสิทธิ์ของสมาชิกใน Project
`project.member.removed`	สมาชิกถูกนำออกจาก Project

Template

การกระทำ	คำอธิบาย
`template.created`	มีการสร้าง Template การดึงข้อมูลใหม่
`template.updated`	Template ถูกแก้ไข
`template.deleted`	Template ถูกลบออก

API Token

การกระทำ	คำอธิบาย
`api_token.created`	มีการสร้าง API Token ใหม่
`api_token.updated`	มีการเปลี่ยนแปลงการตั้งค่า API Token
`api_token.deleted`	API Token ถูกยกเลิกและลบออก
`api_token.regenerated`	ค่า Secret ของ API Token ถูกสร้างขึ้นใหม่

Webhook

การกระทำ	คำอธิบาย
`webhook.created`	มีการลงทะเบียน Webhook Endpoint ใหม่
`webhook.updated`	URL, Events หรือการตั้งค่า Webhook ถูกเปลี่ยนแปลง
`webhook.deleted`	Webhook ถูกนำออก

ฟิลด์ใน Audit Log

แต่ละ Entry ใน Audit Log ประกอบด้วยฟิลด์ต่อไปนี้:

ฟิลด์	ประเภท	จำเป็น	คำอธิบาย
`id`	string	ใช่	Identifier เฉพาะของ Audit Log Entry นี้
`organizationId`	string	ใช่	องค์กรที่ Event นี้เป็นของ
`actorId`	string	ใช่	User ID ของผู้ดำเนินการ
`actorEmail`	string	ใช่	อีเมลของผู้ดำเนินการ ณ เวลาที่เกิดการกระทำ
`action`	string	ใช่	การกระทำที่เกิดขึ้น (เช่น `project.created`)
`entityType`	string	ใช่	ประเภทของทรัพยากรที่ได้รับผลกระทบ (`organization`, `project`, `template`, `member`, `api_token`, `webhook`)
`entityId`	string	ไม่	ID ของทรัพยากรที่ได้รับผลกระทบ
`entityName`	string	ไม่	ชื่อที่อ่านได้ของทรัพยากรที่ได้รับผลกระทบ
`metadata`	object	ไม่	ฟิลด์ Request Body ที่ผ่านการกรองแล้ว (Keys ที่มีความอ่อนไหว เช่น `password`, `token`, `secret` และ `key` จะถูกลบออกอัตโนมัติ)
`ipAddress`	string	ไม่	IP Address ที่ส่ง Request มา
`userAgent`	string	ไม่	Browser หรือ Client User-Agent String
`statusCode`	number	ไม่	HTTP Response Status Code ของ Request (เช่น `200`, `201`)
`createdAt`	timestamp	ใช่	เวลาที่บันทึก Event (ISO 8601)
`updatedAt`	timestamp	ใช่	เวลาที่ Record ถูกอัปเดตล่าสุด (ISO 8601)

NOTE

Audit Log ถูกบันทึกแบบ Asynchronous หลังจากส่ง API Response ออกไปแล้ว ในกรณีที่ไม่น่าจะเกิดขึ้นซึ่งการบันทึก Log ล้มเหลว Request เดิมจะไม่ได้รับผลกระทบ — มีเพียง Log Entry เท่านั้นที่จะถูกข้ามไป ความล้มเหลวดังกล่าวจะถูกบันทึกใน Error Log ฝั่ง Server

การดู Audit Log

เข้าถึง Audit Trail ขององค์กรผ่าน Dashboard:

เปิดเมนู Organization จาก Navigation Bar ด้านบน
เลือก Audit Trail จาก Sidebar
ตาราง Log จะแสดง Entry เรียงตามลำดับเวลาย้อนหลัง (ล่าสุดก่อน)

แต่ละแถวในตารางแสดง:

Actor — อีเมลของสมาชิกที่ดำเนินการ
Action — Event ที่เกิดขึ้น (เช่น template.updated)
Entity — ชื่อของทรัพยากรที่ได้รับผลกระทบ
IP Address — IP ต้นทางของ Request
Date & Time — เวลาที่บันทึก Event

คลิกที่แถวใดก็ได้เพื่อขยายดูรายละเอียดเต็มของ Entry รวมถึง Object metadata และ String userAgent แบบ Raw

TIP

Audit Trail เป็นแบบอ่านอย่างเดียว Log Entry ไม่สามารถแก้ไขหรือลบได้จาก Dashboard หรือ API ทั้งนี้เป็นการออกแบบโดยตั้งใจ — ความไม่เปลี่ยนแปลงของ Audit Record คือสิ่งที่ทำให้บันทึกเหล่านี้น่าเชื่อถือในฐานะหลักฐาน

การกรองและค้นหา

ใช้ตัวควบคุมตัวกรองด้านบนตาราง Log เพื่อจำกัดผลลัพธ์:

ตัวกรอง	คำอธิบาย
Action	กรองตามประเภทการกระทำที่ต้องการ (เช่น `api_token.regenerated`)
Entity Type	กรองตามประเภทของทรัพยากร (`organization`, `project`, `template`, `member`, `api_token`, `webhook`)
Actor	กรองตาม User ID ของผู้ดำเนินการ
Date Range	จำกัดผลลัพธ์ในช่วงเวลาที่ต้องการโดยใช้วันเริ่มต้นและวันสิ้นสุด

สามารถใช้ตัวกรองหลายตัวร่วมกันได้ ตัวอย่างเช่น คุณสามารถแสดงการกระทำทั้งหมดเกี่ยวกับ template ที่ผู้ใช้คนใดคนหนึ่งดำเนินการภายใน 30 วันที่ผ่านมา

ขนาดหน้าเริ่มต้นคือ 20 Entry ต่อหน้า สูงสุด 100 Entry ต่อ Request

การเข้าถึงผ่าน API

Audit Log พร้อมใช้งานผ่าน REST API สำหรับการเข้าถึงแบบ Programmatic, Pipeline การ Export และการผสานรวมกับ SIEM

Endpoints

Method	Path	คำอธิบาย
`GET`	`/audit-trail/organizations/:organizationId`	ดึงรายการ Audit Log แบบ Paginated ขององค์กร
`GET`	`/audit-trail/:id`	ดึง Audit Log Entry เดียวตาม ID

ทุก Endpoint ต้องใช้ JWT Access Token หรือ API Token ที่ถูกต้องใน Header Authorization

Query Parameters

Parameter	ประเภท	ค่าเริ่มต้น	สูงสุด	คำอธิบาย
`page`	number	`1`	—	หมายเลขหน้า (เริ่มที่ 1)
`limit`	number	`20`	`100`	จำนวน Entry ต่อหน้า
`action`	string	—	—	กรองตาม Action (เช่น `project.deleted`)
`entityType`	string	—	—	กรองตาม Entity Type
`actorId`	string	—	—	กรองตาม User ID ของผู้ดำเนินการ
`startDate`	string	—	—	ISO 8601 Date String (ขอบเขตล่างแบบ Inclusive)
`endDate`	string	—	—	ISO 8601 Date String (ขอบเขตบนแบบ Inclusive)

ตัวอย่าง: ดึงรายการ Audit Log

# ดึงหน้าแรกของ Audit Log สำหรับองค์กร
curl -X GET \
  "https://api.ocriva.com/audit-trail/organizations/ORG_ID?page=1&limit=20" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

Response:

{
  "logs": [
    {
      "id": "664f1a2b3c4d5e6f7a8b9c0d",
      "organizationId": "663a0b1c2d3e4f5a6b7c8d9e",
      "actorId": "661b2c3d4e5f6a7b8c9d0e1f",
      "actorEmail": "alice@example.com",
      "action": "template.updated",
      "entityType": "template",
      "entityId": "662c3d4e5f6a7b8c9d0e1f2a",
      "entityName": "Invoice Extraction",
      "metadata": {
        "name": "Invoice Extraction",
        "fields": ["invoice_number", "total_amount", "due_date"]
      },
      "ipAddress": "203.0.113.42",
      "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)",
      "statusCode": 200,
      "createdAt": "2026-04-04T09:15:00.000Z",
      "updatedAt": "2026-04-04T09:15:00.000Z"
    }
  ],
  "total": 142,
  "page": 1,
  "totalPages": 8
}

ตัวอย่าง: กรองตาม Action และช่วงวันที่

# แสดงการลบ API Token ทั้งหมดในเดือนมีนาคม 2026
curl -X GET \
  "https://api.ocriva.com/audit-trail/organizations/ORG_ID?action=api_token.deleted&startDate=2026-03-01T00:00:00Z&endDate=2026-03-31T23:59:59Z" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

ตัวอย่าง: ดึง Entry เดียว

# ดึง Audit Log Entry เฉพาะตาม ID
curl -X GET \
  "https://api.ocriva.com/audit-trail/664f1a2b3c4d5e6f7a8b9c0d" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

WARNING

Audit Trail API ส่งคืนข้อมูลเฉพาะองค์กรของผู้ใช้ที่ผ่านการยืนยันตัวตนเท่านั้น การพยายามดึง Log ขององค์กรที่คุณไม่ได้เป็นสมาชิกจะได้รับ Response 401 Unauthorized

กรณีการใช้งาน

การตรวจสอบด้าน Compliance

กรอบงานด้านกฎระเบียบ เช่น PDPA (ประเทศไทย), ISO 27001 และ SOC 2 กำหนดให้มีหลักฐานว่าการเข้าถึงข้อมูลสำคัญและการเปลี่ยนแปลงการตั้งค่าถูกติดตาม Audit Trail ของ Ocriva มอบบันทึกพร้อมใช้ที่คุณสามารถนำเสนอแก่ผู้ตรวจสอบได้:

Export Log ที่ครอบคลุมช่วงเวลา Audit ผ่าน API
กรองตาม Entity Type เพื่อแสดงการเปลี่ยนแปลงการตั้งค่าทั้งหมด (Template, Webhook, API Token)
เปรียบเทียบ actorEmail กับข้อมูล HR ขององค์กรเพื่อยืนยันว่าการเปลี่ยนแปลงดำเนินการโดยบุคลากรที่มีอำนาจ

การสืบสวนด้านความปลอดภัย

เมื่อคุณสงสัยว่ามีการเข้าถึงโดยไม่ได้รับอนุญาตหรือมีการเปลี่ยนแปลงที่ไม่คาดคิด Audit Trail ช่วยให้คุณตอบคำถามสำคัญได้:

ใคร เป็นผู้เปลี่ยนแปลง — actorEmail และ actorId
อะไร ที่ถูกเปลี่ยนแปลง — action, entityName และ metadata
เมื่อไหร่ ที่เกิดขึ้น — createdAt
ที่ไหน ที่ส่ง Request มา — ipAddress และ userAgent

กรองตาม actorId เพื่อดูการกระทำทั้งหมดของผู้ใช้คนใดคนหนึ่ง หรือกรองตาม entityType เพื่อดูทุกการเปลี่ยนแปลงในประเภทของทรัพยากรนั้น

การแก้ปัญหาการตั้งค่า

หาก Project หยุดทำงานหลังจากมีการเปลี่ยนแปลงล่าสุด ให้ค้นหาเหตุการณ์ project.updated หรือ template.updated ใน Audit Trail ในช่วงเวลาที่เกี่ยวข้อง ฟิลด์ metadata จัดเก็บ Request Body ที่ผ่านการกรองแล้ว ทำให้คุณเห็นได้ชัดเจนว่าฟิลด์ใดถูกเปลี่ยนแปลง

ความรับผิดชอบของทีม

ในองค์กรที่มี Admin หลายคน Audit Trail มอบบันทึกที่เป็นกลางของการดำเนินการด้านการดูแลระบบทั้งหมด ไม่ว่าจะเป็นการเชิญสมาชิก การเปลี่ยนบทบาท การลบ Project และการสร้าง API Token สิ่งนี้ช่วยขจัดความคลุมเครือในการสืบหาที่มาของการตัดสินใจด้านการตั้งค่า

แนวปฏิบัติที่ดี

ตรวจสอบกิจกรรม API Token สม่ำเสมอ — ค้นหาเหตุการณ์ api_token.created และ api_token.regenerated ทุกเดือน Token ที่สร้างโดยผู้ดำเนินการที่ไม่รู้จักควรถือว่าถูกบุกรุกและควรยกเลิกทันที
ตั้งค่า SIEM Export — ใช้ Paginated API เพื่อส่ง Audit Log ไปยังระบบ Security Information and Event Management (SIEM) เช่น Datadog, Splunk หรือ Elastic กำหนดตารางการดึงข้อมูลโดยใช้ startDate และ endDate เพื่อดึงเฉพาะ Entry ใหม่
ตั้งค่าการแจ้งเตือนสำหรับการกระทำวิกฤต — สร้างการแจ้งเตือนสำหรับ Event ที่มีความเสี่ยงสูง เช่น organization.deleted, member.role_updated และ api_token.regenerated การแจ้งเตือนอัตโนมัติช่วยลดเวลาระหว่างเหตุการณ์และการตรวจพบ
เปรียบเทียบกับ IP Whitelist — นำค่า ipAddress ใน Audit Log มาเปรียบเทียบกับ IP ของ Server ที่รู้จัก Request จาก IP Address ที่ไม่คาดคิดอาจบ่งชี้ว่า Credential ถูกบุกรุก
เก็บ Log ไว้นอกแพลตฟอร์ม — Export Audit Log ไปยัง Storage ของคุณเองสำหรับการเก็บรักษาระยะยาว ประวัติ Log ในตัวของ Ocriva ออกแบบมาเพื่อการใช้งานเชิงปฏิบัติ สำหรับ Archive ด้าน Compliance หลายปีควรเก็บสำเนาของคุณเอง
ตรวจสอบอีเมลของผู้ดำเนินการ — ฟิลด์ actorEmail บันทึกอีเมล ณ เวลาที่ดำเนินการ หากสมาชิกเปลี่ยนอีเมล Log ในอดีตยังคงสะท้อนอีเมลที่ใช้ในขณะนั้น ควรอ้างอิง actorId เสมอเพื่อระบุตัวตนอย่างต่อเนื่อง

TIP

เมื่อ Export Log เพื่อวัตถุประสงค์ด้าน Compliance ให้ใช้ตัวกรอง startDate และ endDate เพื่อดึงข้อมูลทีละเดือน วิธีนี้ทำให้ API Response แต่ละครั้งมีขนาดเล็กและหลีกเลี่ยงการถึงขีดจำกัด 100 Entry ต่อหน้า

Documents

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