การควบคุมการเข้าถึงและ audit log

สามมุมมอง

1. ใครเข้าถึงได้ (มนุษย์ / service account)
2. อะไรที่เข้าถึงได้ (ข้อมูล / ฟังก์ชัน / environment)
3. บันทึกว่าใครทำอะไรเมื่อไหร่ (audit log)

หลักสิทธิ์ขั้นต่ำ

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

RBAC (การควบคุมการเข้าถึงตามบทบาท)

การให้สิทธิ์แก่บทบาทแทนที่จะให้แก่ตัวบุคคล แล้วจึงมอบบทบาทให้แต่ละบุคคล เป็นวิธีที่จัดการได้ง่ายกว่า

ตัวอย่างบทบาท：
・Admin       … ทุกสิทธิ์ (จำนวนน้อยมาก)
・Operator    … อ่านเขียนผ่านเครื่องมือ production
・Support     … อ่านข้อมูลลูกค้าได้อย่างเดียว
・Developer   … development และ staging เท่านั้น
・Auditor     … อ่าน audit log ได้อย่างเดียว

การเข้าถึง secret และโทเคน

• client secret ของ ReceiptRoller → เฉพาะ service account ของ production เท่านั้น
• access token ของลูกค้า → เฉพาะผู้ใช้ที่แอปทำงาน ซ่อนจากมนุษย์
• Webhook secret → เฉพาะเซิร์ฟเวอร์ผู้รับเท่านั้น

Audit log

การบันทึกว่าใครทำอะไรเป็นสิ่งจำเป็นสำหรับการตรวจจับการทุจริต การสอบสวนอุบัติเหตุ และการปฏิบัติตามข้อกำหนดด้าน compliance

event ที่ควรบันทึก

• การล็อกอิน / ล็อกเอาต์เข้า environment production
• การดึง secret และโทเคน
• การเข้าดูข้อมูลลูกค้า (โดยเฉพาะการดึงจำนวนมาก)
• การลบข้อมูลและการ export
• การเปลี่ยนแปลงการตั้งค่าแอป
• การมอบและเพิกถอนสิทธิ์

รายการที่ควรมีในแต่ละ record

• timestamp (UTC)
• ผู้กระทำ (user_id / service_account_id)
• action (read, write, delete เป็นต้น)
• เป้าหมาย (resource_type + resource_id)
• ผลลัพธ์ (success / failure)
• client IP และ User-Agent
• request ID ที่เกี่ยวข้อง

การจัดเก็บ

• storage เฉพาะสำหรับ audit log (เขียนได้อย่างเดียว แก้ไขไม่ได้)
• อย่างน้อย 1 ปี (บางอุตสาหกรรมอาจ 3–7 ปี)
• เก็บแยกต่างหากจาก log ของแอป

รีวิวตามระยะ

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

การยืนยันตัวตนแบบหลายปัจจัย (MFA)

ผู้ใช้ทุกรายที่เข้าถึง environment production ได้ควรบังคับใช้ MFA เราแนะนำ TOTP (Google Authenticator เป็นต้น) หรือ FIDO2 มากกว่า SMS

คู่มือที่เกี่ยวข้อง

• แนวคิดเรื่องการปกป้องข้อมูล
• แนวปฏิบัติที่ดีในการใช้งาน production
• การหมุนเวียน secret
• กลับไปที่ Developer Help Top