Consentrix แยก customer identity, internal user access และ system-to-system authentication ออกจากกันอย่างชัดเจน เพื่อให้ audit และ organization scope ไม่ปะปนกัน เรื่องนี้สำคัญมากสำหรับ consent platform เพราะเส้นแบ่งของ identity และหลัก data minimization ส่งผลโดยตรงต่อ privacy และ compliance posture
Identity Types
| Identity | Used for | Example |
|---|
| customer_id | customer reference จากระบบภายนอกขององค์กรคุณ | cust_12345 |
| Subject | internal record ของ Consentrix ที่เชื่อมกับ customer_id หนึ่งค่า | 550e8400-e29b-41d4-a716-446655440000 |
| User | human operator ใน Backoffice | ops@company.com |
| Role & Permission | กฎการเข้าถึงสำหรับ Backoffice users | users:view, consent_templates:approve |
| System / API Key | การยืนยันตัวตนแบบ machine-to-machine | checkout-service |
| Alias | organization identifier ภายใน platform | acme-corp |
Subject vs customer_id
สองสิ่งนี้เกี่ยวข้องกัน แต่ไม่ใช่สิ่งเดียวกัน:
| Item | Owned by | Purpose | Where it appears |
|---|
customer_id | องค์กรของคุณ | customer reference ที่คงที่จากระบบของคุณเอง | public API paths, search, backoffice lookups |
| Subject | Consentrix | internal record ที่ใช้เชื่อม decisions, products และ controls | internal records, admin responses, audit-related joins |
- application ของคุณส่ง
customer_id มากับการเรียก API
- Consentrix จะ resolve ค่านั้นไปยัง Subject ภายในระบบ
- Subject จะถูกสร้างขึ้นเมื่อมีการใช้งานครั้งแรก และช่วยให้ platform เก็บประวัติ consent และ controls ที่เกี่ยวข้องได้อย่างสม่ำเสมอ
How They Connect
customer_id คือ customer reference ที่มาจากระบบของคุณเอง- Subject คือ internal record ที่ Consentrix สร้างต่อจาก
customer_id
- User คือ internal operator
- Roles และ permissions เป็นตัวกำหนดว่า users ทำอะไรได้
- System และ API key ใช้กับ applications
- Alias ใช้ระบุ organization ของคุณภายใน platform
Privacy and Data Minimization
Consentrix ถูกออกแบบมาเพื่อให้เชื่อม consent records เข้าหากันได้ โดยไม่กลายเป็น customer profile store
| Principle | What Consentrix does |
|---|
| Store the minimum needed to link consent | เก็บ customer_id จากภายนอกและ technical identifiers ภายใน เช่น Subject record เท่าที่จำเป็น |
| Avoid storing unnecessary PII | ไม่ถือว่า names, email addresses, phone numbers หรือ profile fields อื่นเป็นส่วนหนึ่งของ core consent identity model |
| Keep rich profile data in your own systems | ใช้ระบบของคุณหรือ profile APIs ภายนอกเมื่อจำเป็นต้องแสดงรายละเอียด customer เพิ่มเติม |
ในทางปฏิบัติ Consentrix จะเก็บ customer_id เป็น business identifier หลักของ consent records ส่วนข้อมูลโปรไฟล์ที่ละเอียดกว่าจะยังคงอยู่ในระบบของคุณเอง นี่เป็นคุณสมบัติสำคัญของ consent management platform เพราะระบบควรเก็บประวัติ consent ที่ตรวจสอบย้อนกลับได้ โดยไม่กลายเป็นแหล่งเก็บ customer PII หลัก
Practical Rules
| Rule | Why it matters |
|---|
อย่ามองว่า customer_id, Subject และ User คือสิ่งเดียวกัน | เพราะแต่ละอย่างมีหน้าที่ต่างกันทั้งด้าน privacy และ access |
ส่ง customer_id ที่คงที่จากระบบของคุณเอง | consent records จะอิงความสม่ำเสมอของค่านี้ |
| ใช้ roles แทน shared accounts | ช่วยให้งาน audit และ least-privilege control ชัดเจนขึ้น |
| แยก systems ตาม applications | ปลอดภัยกว่าสำหรับ key rotation และ incident response |
| เก็บ PII ไว้ในระบบของคุณเอง เว้นแต่มีเหตุผลทางธุรกิจที่ชัดเจน | เพื่อรักษาหลัก data minimization |
| ตั้ง alias ให้ตรงกับ organization ที่ถูกต้อง | เพราะมีผลต่อ routing และ authentication context |
Common Scenarios
| Scenario | What to use |
|---|
| business user ต้องเข้าใช้งาน portal | สร้าง User และ assign roles |
| service หนึ่งต้องเรียก API | สร้าง System และ generate API key |
| ต้องการค้นหาความยินยอมของ customer | เริ่มจาก customer_id ของ customer แล้ว Consentrix จะ resolve Subject ภายใน |
| ต้องวิเคราะห์พฤติกรรมที่ขึ้นกับ organization | ตรวจ Alias และ access scope ของ organization นั้น |