การปฏิบัติตามข้อกำหนดและการจับคู่การควบคุม
หน้านี้จับคู่การควบคุมความปลอดภัยและการดำเนินงานของแพลตฟอร์มกับเฟรมเวิร์กยอดนิยมที่ทีมควบคุมการปฏิบัติตามข้อกำหนดและผู้ตรวจสอบบัญชีมักจะสอบถาม ได้แก่ SOC 2, ISO 27001, NIST SP 800-53, CIS Kubernetes Benchmark, GDPR และ PDPA (ประเทศไทย)
เอกสารนี้เหมาะสำหรับใคร
เจ้าหน้าที่ดูแลการปฏิบัติตามข้อกำหนด ผู้ตรวจสอบภายใน และสถาปนิกความปลอดภัยที่กำลังเตรียมเอกสารหลักฐานสำหรับการรับรอง การตรวจสอบ หรือการประเมินความเสี่ยง โดยควรอ่านควบคู่ไปกับตาราง ความรับผิดชอบร่วมกันและระดับความพร้อมในการใช้งาน (Shared responsibility & maturity) เนื่องจากทุกรายการที่เป็นส่วนของ "ลูกค้า" (Customer) ในตารางดังกล่าวคือสิ่งที่คุณต้องดำเนินการเพิ่มเติมเองเพื่อให้สอดคล้องกับข้อกำหนด
นี่คือแนวทางการจับคู่การควบคุม ไม่ใช่การรับรองอย่างเป็นทางการ
Opsta AI Gateway ไม่ได้รับการรับรองภายใต้เฟรมเวิร์กเหล่านี้โดยตรง การจับคู่นี้ระบุเพียงว่า ฟีเจอร์ใดบ้างของผลิตภัณฑ์ที่ช่วยตอบโจทย์การควบคุม และ การควบคุมใดบ้างที่ยังคงเป็นหน้าที่รับผิดชอบของคุณ ในฐานะผู้ควบคุมระบบ ผู้ตรวจสอบบัญชีของคุณจะเป็นผู้ประเมินความเพียงพอในการควบคุม โดยเอกสารฉบับนี้จะเป็นจุดเริ่มต้นสำหรับพวกเขา
วิธีการอ่านหน้านี้
แต่ละแถวในตารางระบุการจับคู่ระหว่างข้อกำหนดและการควบคุมดังนี้
- การควบคุมโดยผลิตภัณฑ์ (Product control) หมายถึงสิ่งที่แพลตฟอร์มมีให้ใช้งานได้ทันที
- แหล่งค้นหาหลักฐาน (Where to find evidence) หมายถึงหน้าเว็บ บันทึกการทำงาน หรือเอกสารที่แสดงถึงการควบคุมดังกล่าว
- การดำเนินการโดยผู้ควบคุมระบบ (Operator action) หมายถึงสิ่งที่คุณต้องดำเนินการเพิ่มเติมเพื่อตอบโจทย์การควบคุมในระบบของคุณ
ระดับความพร้อมในการใช้งานจะเป็นไปตามสัญลักษณ์ใน ตารางความรับผิดชอบร่วมกัน ได้แก่ Shipped · Shipped (toggle) · Opt-in · Roadmap · Customer
SOC 2 Type II
มาตรฐาน SOC 2 จะประเมินการควบคุมตามหลักเกณฑ์บริการที่น่าเชื่อถือ (Trust Services Criteria) ทั้ง 5 ด้าน โดย Opsta AI Gateway มักจะถูกรวมอยู่ในการตรวจสอบความปลอดภัยของระบบภายใต้หัวข้อ ความปลอดภัย (Security หรือ CC) และ ความพร้อมใช้งาน (Availability หรือ A)
ความปลอดภัย (Security หรือ CC)
| รหัส CC | ข้อกำหนด | การควบคุมโดยผลิตภัณฑ์ | ระดับความพร้อม | หลักฐาน | การดำเนินการโดยผู้ควบคุมระบบ |
|---|---|---|---|---|---|
| CC6.1 | การจำกัดสิทธิ์เข้าถึงระบบเฉพาะผู้ได้รับอนุญาต | ปลั๊กอิน Key-auth และระบบ RBAC ที่มี 3 บทบาท | Shipped | บันทึกการตรวจสอบและโมเดล RBAC | กำหนดค่ากลุ่มใน Keycloak และอีเมลผู้ดูแลระบบแพลตฟอร์ม (platform-admin) |
| CC6.2 | การยกเลิกสิทธิ์เข้าถึงเมื่อมีการเปลี่ยนบทบาทหน้าที่ | การเพิกถอน API key และการปิดใช้งานผู้ใช้ใน Keycloak | Shipped | รายการบันทึกการตรวจสอบสำหรับ key.revoke และ member.remove | จัดทำคู่มือปฏิบัติการยกเลิกสิทธิ์สำหรับพนักงานที่ออกจากงาน ทั้งนี้ ระบบการนำผู้ใช้ออกจากระบบอัตโนมัติด้วย SCIM อยู่ในแผนพัฒนาการทำงาน |
| CC6.3 | การให้สิทธิ์เท่าที่จำเป็น (Least privilege) | ผู้ดูแลระบบระดับองค์กร (org_admin) และสมาชิกทั่วไปที่อ่านได้อย่างเดียว (member) | Shipped | โมเดล RBAC | ตรวจสอบสมาชิกภาพของกลุ่มทุกไตรมาส |
| CC6.6 | การเข้ารหัสข้อมูลระหว่างรับส่ง | การใช้ TLS ที่ระดับ ingress และการเชื่อมต่อแบบ TLS จาก control plane ไปยัง PostgreSQL | Shipped | ใบรับรองจาก cert-manager และตัวแปร PGSSLMODE=require | บังคับใช้งาน CNI ที่รองรับการแยกส่วนเครือข่ายภายใน |
| CC6.7 | การเข้ารหัสข้อมูลขณะจัดเก็บ (Data at rest) | การเข้ารหัสข้อมูลที่เก็บใน PVC และ etcd | Customer (G3) | การกำหนดค่า StorageClass และไฟล์ระบุการเข้ารหัส etcd | เปิดใช้งานการเข้ารหัส etcd หรือใช้งาน Sealed Secrets และ External Secrets Operator |
| CC6.8 | การป้องกันมัลแวร์และการเปลี่ยนแปลงระบบโดยไม่ได้รับอนุญาต | การตรวจสอบความปลอดภัยผ่าน Trivy และ gosec ใน CI รวมถึงระบบไฟล์คอนเทนเนอร์แบบอ่านได้อย่างเดียว | Shipped | ผลลัพธ์ของ CI workflow และการตั้งค่า readOnlyRootFilesystem: true | ระบุ OCI digest สำหรับ Helm chart และสแกนอิมเมจเมื่อดึงมาใช้งาน |
| CC7.1 | การตรวจหาช่องโหว่ | การสแกน Trivy SCA และสแกน IaC พร้อมกับ gosec | Shipped | ผลลัพธ์การสแกนของ CI และข้อตกลงระดับบริการในการแก้ไขช่องโหว่ lifecycle | ติดตามข่าวสารประกาศด้านความปลอดภัยและอัปเดตแพตช์ตามกำหนดเวลา |
| CC7.2 | การเฝ้าระวังเหตุการณ์ด้านความปลอดภัย | การแจ้งเตือนผ่าน Grafana และการบันทึกข้อมูลการบล็อกของ guardrail | Shipped (toggle) | กฎการแจ้งเตือน และข้อมูล guardrail_blocks | เชื่อมต่อการแจ้งเตือนไปยังระบบแจ้งเหตุฉุกเฉิน และกำหนดขั้นตอนการตอบสนองต่อเหตุการณ์ด้านความปลอดภัย |
| CC9.1 | การบริหารความเสี่ยงจากผู้ให้บริการภายนอก | การทำงานในระบบของตนเองทั้งหมด และไม่มีระบบคลาวด์ของ Opsta อยู่ในเส้นทางการรับส่งข้อมูล | Shipped | อธิปไตยของข้อมูล | ประเมินสัญญาการใช้งานของผู้ให้บริการ LLM เช่น ข้อตกลงที่จะไม่นำข้อมูลไปเทรนโมเดล หรือนโยบายการเก็บรักษาข้อมูลเป็นศูนย์ (Zero Data Retention) |
ความพร้อมใช้งาน (Availability หรือ A)
| รหัส A | ข้อกำหนด | การควบคุมโดยผลิตภัณฑ์ | ระดับความพร้อม | หลักฐาน | การดำเนินการโดยผู้ควบคุมระบบ |
|---|---|---|---|---|---|
| A1.1 | การวางแผนความจุระบบ | คำแนะนำด้านขนาดการใช้งาน โดยกำลังจัดทำเอกสารสำหรับสถาปัตยกรรมอ้างอิง | Shipped (doc pending RA.1) | ข้อกำหนดของระบบ | เฝ้าระวังการแจ้งเตือนระบบทำงานหนัก และวางแผนสำหรับช่วงที่มีผู้ใช้งานสูงสุด |
| A1.2 | การป้องกันสภาพแวดล้อมระบบทำงาน | โครงสร้างแบบพร้อมใช้งานสูงที่รองรับ Pod Disruption Budget และการไม่รันร่วมกันบนโหนดเดียวกัน (anti-affinity) | Shipped (toggle) | การตั้งค่า global.highAvailability: true และไฟล์กำหนดค่า PDB | ใช้งานคลัสเตอร์ที่มีตั้งแต่ 3 โหนดขึ้นไป และบังคับใช้กฎ anti-affinity |
| A1.3 | การสำรองข้อมูลและการกู้คืน | การสำรองข้อมูล CloudNativePG และการทำคืนระบบผ่านการระบุค่าโครงสร้างพื้นฐานด้วยโค้ด (IaC) | Opt-in (G1) | การตั้งค่า postgres.backup.enabled และเอกสาร การสำรองข้อมูลและการกู้คืน | เปิดใช้งานการสำรองข้อมูล ฝึกซ้อมการกู้คืน และบันทึกเวลาที่ใช้ในการกู้คืนกับข้อมูลที่อาจสูญหายได้ (RTO/RPO) |
ISO 27001:2022
ระบบเกตเวย์จะจับคู่ได้โดยตรงกับมาตรการควบคุมของภาคผนวก A (Annex A) ในหมวด การควบคุมการเข้าถึง (A.5-A.9), วิทยาการเข้ารหัสลับ (A.10), การดำเนินงาน (A.12), การสื่อสาร (A.13) และ การจัดการเหตุการณ์ความมั่นคงปลอดภัย (A.16)
| การควบคุม ISO 27001 | ข้อกำหนด | การควบคุมโดยผลิตภัณฑ์ | ระดับความพร้อม | การดำเนินการโดยผู้ควบคุมระบบ |
|---|---|---|---|---|
| A.5.15 | นโยบายการควบคุมการเข้าถึง | การยืนยันตัวตนด้วย Key-auth ระบบ RBAC และกลุ่มผู้ใช้ใน Keycloak | Shipped | จัดทำนโยบายการควบคุมการเข้าถึงเป็นเอกสาร และตรวจสอบทบทวนทุกไตรมาส |
| A.5.16 | การจัดการเอกลักษณ์บุคคล | ระบบเชื่อมต่อของ Keycloak ที่รองรับฐานข้อมูลภายใน คลังข้อมูล LDAP ระบบ OIDC และระบบ SAML รวมถึงการจองสิทธิ์เข้าใช้งานแบบทันเวลา (Just-In-Time) | Shipped | ดูแลรักษาขอบเขตผู้ใช้งานใน Keycloak และจัดทำคู่มือสำหรับการนำผู้ใช้ออกเมื่อพ้นสภาพการทำงาน ทั้งนี้ ระบบ de-provisioning ผ่านโปรโตคอล SCIM อยู่ในแผนพัฒนาการทำงาน |
| A.5.17 | ข้อมูลที่ใช้ในการยืนยันตัวตน | คีย์ API ที่แปลงค่าด้วยฟังก์ชันแฮช HMAC และโทเค็น OIDC โดยไม่มีการบันทึกคีย์ตัวจริงในรูปแบบข้อความธรรมดาลงฐานข้อมูล | Shipped | จัดทำขั้นตอนการหมุนเวียนคีย์การทำงาน และหมุนเวียนความลับสำหรับเซสชันการทำงานเป็นระยะ |
| A.5.28 | การจัดเก็บหลักฐาน | บันทึกการตรวจสอบการทำงานที่บันทึกการเปลี่ยนแปลงสิทธิ์ทั้งหมดรวมถึงการพยายามกระทำที่ถูกปฏิเสธ | Shipped | กำหนดค่า audit.retentionDays เป็นอย่างน้อย 365 วัน และเพิ่มความปลอดภัยให้กับข้อมูลบันทึกที่ส่งออก |
| A.8.7 | การป้องกันมัลแวร์ | ระบบไฟล์แบบอ่านได้อย่างเดียว การสแกนช่องโหว่ใน CI และการไม่มีเชลล์ให้เรียกใช้งานภายในคอนเทนเนอร์ | Shipped | ระบุอิมเมจแบบระบุ digest และสแกนอิมเมจเมื่อดึงมาใช้งาน |
| A.8.9 | การจัดการโครงสร้างพื้นฐานของระบบ | การกำหนดค่าในรูปแบบโครงสร้างพื้นฐานด้วยโค้ด (IaC) เท่านั้นผ่าน helmfile โดยไม่มีการปรับแต่งระบบเองแบบแมนนวล | Shipped | ใช้งานระบบการทำงานแบบ GitOps และใช้ Taskfile เป็นทางเข้าหลักทางเดียวสำหรับรันคำสั่ง |
| A.8.24 | การใช้วิทยาการเข้ารหัสลับ | การเปิดใช้งาน TLS ที่ระดับ ingress และการเชื่อมต่อแบบ TLS จาก control plane ไปยัง PostgreSQL แต่ไม่มีการเข้ารหัสข้อมูลขณะจัดเก็บในเครื่องโดยตรง | Shipped / Customer | เปิดใช้งานการเข้ารหัส etcd และการเข้ารหัสข้อมูลระดับ StorageClass |
| A.8.25 | การพัฒนาซอฟต์แวร์อย่างปลอดภัย | การตรวจสอบความปลอดภัยซอร์สโค้ดแบบคงที่ด้วย gosec (SAST) การสแกนองค์ประกอบซอฟต์แวร์ด้วย Trivy การตรวจสอบใบอนุญาตใช้งาน และการใช้ pre-commit hook ตรวจสอบข้อมูลก่อน commit | Shipped | ตรวจสอบผลการทำงานใน CI และอัปเดตแพตช์ระบบตามกำหนดข้อตกลงระดับบริการในการแก้ไขช่องโหว่ lifecycle |
| A.8.32 | การจัดการการเปลี่ยนแปลง | การออกรุ่นตามรูปแบบ SemVer การบันทึกรายการเปลี่ยนแปลง รวมถึงการตรวจสอบผ่านระบบ pre-commit และการทดสอบใน CI | Shipped | จัดทำเอกสารกระบวนการอนุมัติการเปลี่ยนแปลงและใช้วิธีการออกรุ่นตามขั้นตอนมาตรฐาน |
| A.5.26 | การตอบสนองต่อเหตุการณ์ด้านความปลอดภัยของข้อมูล | การบล็อกคำสั่งของ guardrail กฎการแจ้งเตือน และบันทึกการตรวจสอบ | Shipped (toggle) | กำหนดขั้นตอนการตอบสนองต่อเหตุการณ์ และตั้งค่าให้ส่งการแจ้งเตือนไปยังระบบแจ้งเหตุของทีม |
| A.8.15 | การบันทึกเหตุการณ์การทำงาน | การส่งบันทึกการทำงานของเกตเวย์ไปยัง Loki และบันทึกการตรวจสอบไปยัง PostgreSQL | Shipped | กำหนดระยะเวลาการเก็บรักษาบันทึกข้อมูล และกำหนดสิทธิ์การป้องกันระบบจัดเก็บข้อมูลของ Loki |
NIST SP 800-53 Rev 5
หมวดหมู่การควบคุมหลักที่เกี่ยวข้องกับการใช้งานระบบเกตเวย์ AI มีดังนี้
| หมวดหมู่ | รหัสการควบคุม | การควบคุมโดยผลิตภัณฑ์ | ระดับความพร้อม | หมายเหตุ |
|---|---|---|---|---|
| AC — การควบคุมการเข้าถึง | AC-2 (การจัดการบัญชีผู้ใช้), AC-3 (การบังคับใช้นโยบาย), AC-6 (สิทธิ์การเข้าถึงขั้นต่ำ), AC-17 (การเชื่อมต่อระยะไกล) | ระบบ RBAC ระบบ Key-auth และ Keycloak | Shipped | รหัส AC-2 หมายถึงต้องดูแลรักษาวงจรชีวิตผู้ใช้งาน และรหัส AC-17 หมายถึงบังคับใช้โปรโตคอล TLS เสมอ |
| AU — การตรวจสอบและความรับผิดชอบ | AU-2 (เหตุการณ์ตรวจสอบ), AU-3 (เนื้อหาบันทึก), AU-9 (การป้องกันข้อมูล), AU-11 (การเก็บรักษาข้อมูล) | บันทึกการตรวจสอบการทำงาน | Shipped | รหัส AU-9 หมายถึงต้องป้องกันข้อมูลบันทึกที่ถูกส่งออก และรหัส AU-11 หมายถึงต้องกำหนดค่า retentionDays |
| IA — การระบุตัวตนและการยืนยันตัวตน | IA-2 (การยืนยันตัวตนผู้ใช้), IA-3 (การยืนยันตัวตนอุปกรณ์), IA-5 (การจัดการข้อมูลยืนยันตัวตน) | ระบบ Key-auth และ OIDC ของ Keycloak | Shipped | รหัส IA-3 หมายถึงการใช้คีย์ API ทำหน้าที่ระบุและยืนยันตัวตนของอุปกรณ์ |
| SC — ระบบและการสื่อสาร | SC-8 (การเก็บรักษาความลับระหว่างส่ง), SC-28 (การปกป้องข้อมูลจัดเก็บ) | การเข้ารหัส TLS ที่ระดับ ingress และช่องทางระหว่าง control plane ไปยัง PostgreSQL รวมถึงการเข้ารหัส PVC | Shipped / Customer | รหัส SC-28 หมายถึงต้องเปิดใช้งานระดับ StorageClass และการเข้ารหัส etcd |
| SI — ความสมบูรณ์ของระบบ | SI-2 (การแก้ไขข้อบกพร่อง), SI-3 (การป้องกันมัลแวร์), SI-7 (ความถูกต้องของซอฟต์แวร์) | ข้อตกลงระดับบริการสำหรับการอัปเดตแพตช์พร้อมระบบสแกน Trivy และ gosec | Shipped | รหัส SI-7 หมายถึงใช้การระบุอิมเมจแบบ digest ไปก่อนในตอนนี้ ส่วนการตรวจสอบลายเซ็นดิจิทัลอยู่ในแผนพัฒนาการทำงาน |
| CP — การวางแผนฉุกเฉิน | CP-9 (การสำรองข้อมูล), CP-10 (การกู้คืนระบบ) | การสำรองข้อมูล CloudNativePG และการทำคืนระบบผ่านการระบุค่าโครงสร้างพื้นฐานด้วยโค้ด (IaC) | Opt-in (G1) | ต้องเปิดใช้งานการสำรองข้อมูล ทดสอบการกู้คืน และบันทึกค่า RTO/RPO |
| RA — การประเมินความเสี่ยง | RA-5 (การสแกนหาช่องโหว่), RA-7 (การตอบสนองต่อความเสี่ยง) | ระบบตรวจสอบของ Trivy และ gosec ในขั้นตอน CI | Shipped | รหัส RA-7 หมายถึงต้องติดตั้งแพตช์ตามข้อกำหนดใน lifecycle |
| SA — การจัดหาระบบ | SA-12 (ห่วงโซ่อุปทาน), SA-15 (กระบวนการพัฒนาซอฟต์แวร์) | ตารางกำหนดรุ่นซอฟต์แวร์ที่แน่นอน การตรวจเช็คในขั้นตอน CI และการตรวจสอบสิทธิ์การใช้งาน | Shipped (G8 partial) | รหัส SA-12 หมายถึงการระบุอิมเมจแบบ digest ส่วนการลงนามรหัสและเอกสารคลังส่วนประกอบซอฟต์แวร์ (SBOM) อยู่ในแผนพัฒนาการทำงาน |
CIS Kubernetes Benchmark
การทำงานของแพลตฟอร์มนี้พัฒนาขึ้นโดยมีเป้าหมายให้ผ่านการทดสอบ CIS K8s Benchmark เวอร์ชัน 1.9 (ระดับ 1) สำหรับกระบวนการทำงานที่ระบบควบคุมได้โดยตรง ส่วนชุดคำสั่งย่อยที่เป็นระบบภายนอกอื่นๆ เช่น Higress, Keycloak หรือ LGTM จะมีการกำหนดแนวทางสร้างความปลอดภัยตามแนวทางต้นทางของตนเอง ซึ่งจำเป็นต้องตรวจสอบแยกต่างหาก
| หมวดของ CIS | ข้อกำหนด | สถานะการรองรับ | หมายเหตุ |
|---|---|---|---|
| 5.1 — RBAC | การกำหนดสิทธิ์แบบขั้นต่ำและไม่มีการใช้บัญชีบริการแบบ cluster-admin | Met | อิมเมจของ Opsta จะทำงานด้วยบัญชีบริการที่จำกัดขอบเขตในเนมสเปซของตัวเองและได้รับสิทธิ์ขั้นต่ำสำหรับการทำงานเท่านั้น |
| 5.2 — PSA | การไม่ใช้สิทธิ์ root การไม่ใช้โหมดมีสิทธิ์สูง และการจำกัดสิทธิ์ระดับระบบ (seccomp) | Met | มีการกำหนดตั้งค่าให้รันแบบไม่ใช่ผู้ใช้งานระดับสูงสุด runAsNonRoot การตัดสิทธิ์พิเศษออกทั้งหมด drop ALL และการใช้โปรไฟล์ความปลอดภัยระดับระบบเริ่มต้น seccompProfile: RuntimeDefault ในทุก pod ที่พัฒนาโดย Opsta |
| 5.3 — NetworkPolicy | การปฏิเสธการเชื่อมต่อเริ่มต้นและอนุญาตเฉพาะรายการที่จำเป็น | Met (toggle) | เปิดตั้งค่าด้วย controlPlane.networkPolicy.enabled: true โดยจำเป็นต้องใช้คู่กับ CNI ที่รองรับการแยกส่วนเครือข่าย |
| 5.4 — Secrets | การไม่เก็บความลับในรูปแบบข้อความธรรมดาในตัวแปรสภาพแวดล้อม และไม่มีการใส่ความลับในอิมเมจ | Met | ความลับจะถูกนำมาใช้งานในลักษณะของไฟล์ที่ถูก mount หรือดึงค่าผ่าน SecretKeyRef เท่านั้น โดยไม่มีการใส่ลงไปในอิมเมจของแอปพลิเคชัน |
| 5.5 — แหล่งที่มาของอิมเมจ | การระบุแท็กของอิมเมจแบบเจาะจงโดยไม่ใช้แท็ก latest | Met | อิมเมจอิมเมจทั้งหมดจะถูกล็อกเวอร์ชันไว้ในไฟล์ version.yaml และแนะนำให้กำหนดแบบใช้รหัสระบุตัวตนเฉพาะ (digest) ร่วมด้วย |
| 5.7 — เนมสเปซ | การแยกเนมสเปซการทำงานออกจากกันตามลักษณะหน้าที่ของระบบ | Met | มีการแยกเป็นเนมสเปซ ได้แก่ higress-system, opsta-ai-gateway, opsta-keycloak และ opsta-observability |
| 4.2 — การตรวจสอบ API server | การเปิดใช้งานบันทึกการตรวจสอบความปลอดภัยของ API server | Customer | ผู้ใช้ต้องดำเนินการเปิดการบันทึกการทำงานของ API server ในการกำหนดค่าระบบของคลัสเตอร์เอง |
พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล (PDPA) และกฎหมาย GDPR
เกตเวย์นี้จะมีการประมวลผลข้อมูลส่วนบุคคลบางรายการ เช่น อีเมลของผู้ใช้ในตาราง members อีเมลของผู้ดำเนินการในระบบบันทึกการตรวจสอบความปลอดภัย และฟิลด์ข้อมูล user_email ในบันทึกการบล็อกของ guardrail ตารางจับคู่นี้สามารถอ้างอิงได้สำหรับทั้งกฎหมาย PDPA ของประเทศไทย (พ.ศ. 2562) และกฎหมาย GDPR ของสหภาพยุโรป (EU 2016/679)
| ข้อกำหนด | การรองรับโดยผลิตภัณฑ์ | ระดับความพร้อม | การดำเนินการโดยผู้ควบคุมระบบ |
|---|---|---|---|
| ฐานการประมวลผลโดยชอบด้วยกฎหมายและการจำกัดวัตถุประสงค์ (Lawful basis / purpose limitation) | ระบบจัดเก็บข้อมูลเฉพาะที่จำเป็นเพื่อทำหน้าที่ควบคุมสิทธิ์ บันทึกปริมาณการใช้งาน และรักษาความปลอดภัยของระบบเท่านั้น | Shipped | จัดทำเอกสารอธิบายฐานความชอบด้วยกฎหมายในการประมวลผลอีเมลของสมาชิกและข้อมูลการตรวจสอบระบบ |
| การเก็บข้อมูลส่วนบุคคลให้น้อยที่สุด (Data minimisation) | ระบบบันทึกข้อความจากของ guardrail ไว้เพียงส่วนสั้นๆ ไม่เกิน 280 ตัวอักษร และไม่มีการจัดเก็บเนื้อหาคำสั่งเต็มรูปแบบลงในระบบ | Shipped | ทบทวนการตั้งค่าการเก็บรักษาข้อมูล retentionDays และประเมินการปิดฟิลด์เก็บข้อความตัวอย่าง ซึ่งอยู่ในแผนพัฒนาการทำงานสำหรับระยะที่สี่ (G4) |
| การจัดเก็บและการลบทำลายข้อมูล (Retention and erasure) | สามารถกำหนดช่วงเวลาเก็บรักษา audit.retentionDays ได้ตามความต้องการ และมี API สำหรับใช้คำสั่งลบข้อมูลองค์กรหรือสมาชิกออกจากฐานข้อมูลโดยตรง | Shipped | กำหนดช่วงเวลาเก็บข้อมูลระยะสั้น เช่น 90 วัน เพื่อความปลอดภัยตามหลัก PDPA และ GDPR รวมถึงระบุขั้นตอนกระบวนการขอลบข้อมูลให้ชัดเจน |
| สิทธิ์ในการเข้าถึงและโอนย้ายข้อมูล (Right to access / portability) | ผู้ดูแลระบบสามารถค้นหาข้อมูลประวัติการตรวจสอบและประวัติสมาชิกได้ผ่านทางระบบ API หรือเครื่องมือ psql | Shipped | จัดทำคู่มือหรือขั้นตอนการรับคำร้องเรียนจากเจ้าของข้อมูลส่วนบุคคล (Data Subject Request หรือ DSR) สำหรับองค์กรของคุณ |
| สิทธิ์ในการขอให้ลบทำลายข้อมูล (Right to erasure) | การลบข้อมูลสมาชิกพร้อมกับคีย์และประวัติการใช้งานที่เกี่ยวข้องทั้งหมดออกจากระบบ | Shipped (manual) | เขียนขั้นตอนการลบข้อมูลเป็นเอกสารพร้อมทั้งทำการทดสอบขั้นตอนดังกล่าว |
| ความมั่นคงปลอดภัยในการประมวลผลข้อมูล (Security of processing) | มีระบบการป้องกันผ่านกระบวนการเข้ารหัส TLS ระบบ RBAC การบันทึกการตรวจสอบความปลอดภัย และการแยกส่วนเครือข่าย | Shipped | เปิดใช้งานการเข้ารหัสข้อมูลใน etcd และการสำรองข้อมูล รวมถึงการเปิดการแจ้งเตือนกรณีระบบมีความผิดปกติ |
| การโอนย้ายข้อมูลออกนอกประเทศ | คำสั่งใช้งานจะถูกส่งไปยังผู้ให้บริการโมเดลที่คุณระบุไว้เท่านั้น | Customer | ประเมินนโยบายการโอนย้ายข้อมูลของผู้ให้บริการโมเดลที่คุณใช้งาน โดยเลือกใช้ผู้ให้บริการภายในพื้นที่ที่กำหนด หรือเลือกใช้วิธีรันโมเดลในเซิร์ฟเวอร์ตัวเองผ่าน Ollama |
| การแจ้งเตือนเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (DPO) | ไม่มีระบบแจ้งข้อมูลไปยังเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคลโดยอัตโนมัติ | Customer | ดำเนินการสร้างขั้นตอนและกระบวนการทำงานเพื่อแจ้งเตือนเมื่อเกิดเหตุข้อมูลรั่วไหลหรือผิดปกติด้วยตนเอง |
| การยินยอมเพื่อนำข้อมูลไปเทรนโมเดล | ผลิตภัณฑ์ไม่มีระบบจัดการการยินยอมในตัวเอง | Customer | เลือกใช้บริการโมเดลจากภายนอกที่มีนโยบายว่าจะไม่นำข้อมูลลูกค้าไปเทรนโมเดล หรือเลือกใช้งานระบบรันโมเดลภายในองค์กรเอง |
หน้าเว็บที่เกี่ยวข้อง
- ตารางความรับผิดชอบร่วมกันและระดับความพร้อมในการใช้งาน (Shared responsibility & maturity)
- รายการตรวจสอบความพร้อมสำหรับใช้งานจริง (Production-readiness checklist)
- การจัดการข้อมูล (Data handling)
- ภาพรวมความปลอดภัย (Security overview)
- การเพิ่มความปลอดภัยให้ระบบ (Hardening)
- วงจรชีวิตและการสนับสนุน (Software lifecycle & support)
- การตรวจสอบระบบและการปฏิบัติตามข้อกำหนด (Audit & compliance)