การจัดการข้อมูล
เอกสารนี้รวบรวมรายการข้อมูลที่ทีมรักษาความปลอดภัย ทีมปฏิบัติตามข้อกำหนด และทีมคุ้มครองข้อมูลส่วนบุคคลจำเป็นต้องตรวจสอบก่อนที่จะทำการติดตั้ง Opsta AI Gateway เพื่อให้ข้อมูลตอบคำถามเกี่ยวกับการจัดเก็บข้อมูล ได้แก่ จัดเก็บข้อมูลใดบ้าง เก็บไว้ที่ไหน จัดอยู่ในระดับชั้นความลับใด เก็บไว้นานเท่าใด และมีมาตรการควบคุมความปลอดภัยอย่างไร นอกจากนี้ยังระบุข้อจำกัดของระบบในปัจจุบันอย่างตรงไปตรงมา โดยสามารถดูรายละเอียดระดับความพร้อมในการใช้งานได้ที่ ตารางความรับผิดชอบร่วมกัน (Shared responsibility matrix)
เอกสารนี้เหมาะสำหรับใคร
เจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล สถาปนิกความปลอดภัย และทีมกำกับดูแลการทำงาน โดยควรอ่านควบคู่กับเอกสาร อธิปไตยของข้อมูล ที่เกี่ยวกับพื้นที่จัดเก็บข้อมูลและการใช้งานระบบปิด และเอกสาร การตรวจสอบระบบและการปฏิบัติตามข้อกำหนด ที่ระบุรายละเอียดของบันทึกการตรวจสอบ
รายการข้อมูล (Data inventory)
PostgreSQL แหล่งข้อมูลอ้างอิงหลัก (Source of truth)
จัดการโดย CloudNativePG ทำหน้าที่เก็บข้อมูลทุกอย่างที่เป็นของระบบ control plane
| ตาราง หรือ ข้อมูล | ระดับชั้นความลับ | ข้อมูลที่จัดเก็บ | ระยะเวลาจัดเก็บ |
|---|---|---|---|
orgs, projects, members | Confidential | ชื่อองค์กร ชื่อโครงการ และอีเมลของสมาชิก | จนกว่าจะถูกลบ |
providers | Confidential | ชื่อผู้ให้บริการ ลิงก์เชื่อมต่อ และรายการโมเดล โดยไม่มีการจัดเก็บข้อมูลคีย์ความลับ เนื่องจากคีย์ความลับจะถูกเก็บไว้ใน Kubernetes Secrets | จนกว่าจะถูกลบ |
api_keys | Confidential | ค่าแฮช HMAC ของคีย์และข้อมูลกำกับ ได้แก่ โครงการ ผู้ใช้งาน ป้ายชื่อ งบประมาณ โดยไม่มีการจัดเก็บข้อมูลคีย์ตัวจริงแต่อย่างใด | จนกว่าจะยกเลิกการใช้งาน |
budgets, usage_ledger | Internal | งบประมาณในหน่วยดอลลาร์สหรัฐ ตัวนับจำนวนโทเค็นแยกตามคีย์ และรายการบันทึกการใช้งานระบบสำหรับเรียกเก็บเงิน | จนกว่าจะถูกลบหรือเริ่มใหม่ |
audit_log | Confidential | บันทึกการทำงานของผู้ดูแลระบบที่แสดงรายละเอียดว่าผู้ใดแก้ไขข้อมูลใดและเกิดขึ้นเมื่อใด เช่น การเปลี่ยนแปลงข้อมูลองค์กร โครงการ ผู้ให้บริการ หรือคีย์การใช้งาน | สามารถตั้งค่าได้ผ่าน audit.retentionDays โดยมีค่าเริ่มต้นที่ 365 วัน และจะมีการลบข้อมูลเก่าออกทุกวัน |
guardrail_blocks | Sensitive | บันทึกรายละเอียดการบล็อกแต่ละครั้ง ได้แก่ ตัวตนของผู้ใช้งาน ชื่อองค์กรหรือโครงการ เวลาที่เกิดเหตุ การบล็อกโดยส่วนควบคุมใด กฎที่ตรงกัน และเนื้อความตัวอย่างคำสั่งที่ทำผิดกฎความยาวไม่เกิน 280 ตัวอักษร | สามารถตั้งค่าได้ผ่าน audit.retentionDays โดยใช้ค่าเดียวกันและมีค่าเริ่มต้นที่ 365 วัน และจะมีการลบข้อมูลเก่าออกทุกวัน |
guardrail_rules | Confidential | รูปแบบกฎการทำงานของ guardrail ที่ตั้งค่าโดยผู้ดูแลระบบระดับองค์กร (org_admin) | จนกว่าจะถูกลบ |
routing_rules, provider_keys, canary_rules, mcp_servers, prompt_templates | Confidential | ข้อมูลสำหรับกำหนดค่าการทำงานของระบบต่างๆ | จนกว่าจะถูกลบ |
รายการข้อความตัวอย่างที่ถูกบล็อกโดย guardrail (G4)
ในคอลัมน์ guardrail_blocks.snippet จะมีการจัดเก็บข้อความตัวอย่างความยาวไม่เกิน 280 ตัวอักษรจากคำสั่งที่ถูกบล็อกโดย guardrail ซึ่งข้อความดังกล่าวอาจมีข้อมูลที่มีความสำคัญสูงที่ guardrail ออกแบบมาเพื่อตรวจจับ เช่น ข้อมูลระบุตัวตนบุคคล การพยายามทำ prompt injection หรือความลับขององค์กร ดังนั้นขอแนะนำให้ปฏิบัติกับตาราง guardrail_blocks เสมือนเป็นตารางข้อมูลที่ต้องเฝ้าระวังความปลอดภัยเป็นพิเศษ พร้อมทั้งกำหนดสิทธิ์เข้าใช้งาน เข้ารหัสข้อมูลสำรอง และกำหนดระยะเวลาการจัดเก็บข้อมูลอย่างเข้มงวด
แนวทางปฏิบัติมีดังนี้
- ลดระยะเวลาการเก็บรักษาข้อมูล โดยกำหนดค่า
audit.retentionDaysให้สั้นลง เช่น 90 วัน หากคุณไม่จำเป็นต้องตรวจสอบประวัติคำสั่งที่ถูกบล็อกในระยะยาว - จำกัดสิทธิ์การเข้าใช้งาน เนื่องจากตารางดังกล่าวอยู่ในฐานข้อมูลร่วมกับโครงสร้างข้อมูลส่วนควบคุมระบบหลักและไม่ได้เปิดเผยข้อมูลสู่ภายนอกโดยตรง ทว่าการเข้าถึงในระดับฐานข้อมูล เช่น การใช้
psqlด้วยบทบาทผู้ใช้opstaจะสามารถอ่านตารางนี้ได้ จึงควรกำหนดสิทธิ์เข้าใช้งานระดับฐานข้อมูลให้แคบที่สุดเท่าที่เป็นไปได้ - ปิดการใช้งานบันทึกตัวอย่างข้อความ ทั้งนี้ ระบบยังไม่มีปุ่มปิดการเก็บข้อความตัวอย่างนี้โดยตรงในเวอร์ชันปัจจุบัน เนื่องจากฟีเจอร์นี้อยู่ในแผนพัฒนาการทำงาน แต่คุณสามารถใช้วิธีสร้าง SQL trigger หลังจากการทำ database migration หรือเขียนคำสั่งใน CNPG hook เพื่อล้างข้อมูลในคอลัมน์นี้เป็นศูนย์ทันทีเมื่อมีการบันทึกได้ หากนโยบายของคุณต้องการความปลอดภัยระดับสูงสุด โปรดติดต่อฝ่ายสนับสนุนของ Opsta เพื่อขอรับคำแนะนำ
Kubernetes Secrets
สร้างขึ้นโดย Helm chart และตัวจัดการระบบ (operator) โดยเป็นค่า Kubernetes Secrets มาตรฐานที่ถูกแปลงข้อมูลในรูปแบบ base64 และไม่มีการเข้ารหัสในตัวเก็บข้อมูล เว้นแต่คุณจะเปิดใช้งานการเข้ารหัส etcd หรือเชื่อมต่อกับระบบ KMS หรือเครื่องมือภายนอก
| ข้อมูลความลับ (Secret) | สิ่งที่จัดเก็บอยู่ภายใน | ถูกเรียกใช้งานโดย |
|---|---|---|
provider-keys-<org> | คีย์ API ของผู้ให้บริการโมเดลสำหรับแต่ละองค์กร | เกตเวย์ Higress ผ่านทางปลั๊กอิน Wasm |
idp-secrets-<org> | ข้อมูลความลับ OIDC หรือ SAML client สำหรับการเชื่อมโยงระบบระบุตัวตนของแต่ละองค์กร | Keycloak ผ่านทาง control plane |
mcp-* | ข้อมูลยืนยันตัวตนสำหรับ MCP server | เกตเวย์ Higress |
opsta-pg-app | ข้อความเชื่อมต่อฐานข้อมูล PostgreSQL ที่มีชื่อโฮสต์ ผู้ใช้ รหัสผ่าน และชื่อฐานข้อมูล | Control plane |
keycloak-pg-app | ข้อความเชื่อมต่อฐานข้อมูล PostgreSQL ของ Keycloak | Keycloak |
| Session / CSRF secrets | คีย์สำหรับลงนามข้อมูลเซสชันการเข้าใช้งาน console | ส่วนของหน้าเว็บ console |
| TLS cert + key | ใบรับรองและคีย์ส่วนตัว Wildcard TLS (*.<baseDomain>) | cert-manager หรือ Higress |
การเข้ารหัสข้อมูลความลับขณะจัดเก็บ (G3)
ค่า Kubernetes Secrets จะถูกจัดเก็บในรูปของ รหัส base64 โดยไม่ได้มีการเข้ารหัสจริง เว้นแต่คลัสเตอร์ของคุณจะเปิดใช้งานการเข้ารหัส etcd หรือใช้เครื่องมือภายนอก เช่น Sealed Secrets หรือ External Secrets ส่งผลให้ผู้ใช้ที่มีสิทธิ์ระดับบริหารระบบคลัสเตอร์ (cluster-admin) หรือเข้าถึงข้อมูลดิบของ etcd ได้จะสามารถถอดรหัสออกมาเป็นตัวอักษรปกติและเห็นคีย์ API หรือข้อมูลความลับได้ทันที
สิ่งที่ผู้ใช้งานจำเป็นต้องดำเนินการสำหรับสภาพแวดล้อมใช้งานจริงมีดังนี้
- เปิดใช้งาน การเข้ารหัส etcd ขณะจัดเก็บ (etcd encryption at rest) ซึ่งระบบของ RKE2 และ EKS รองรับการตั้งค่านี้ได้จากตัวผู้ให้บริการโดยตรง
- ติดตั้งระบบ Bitnami Sealed Secrets และเข้ารหัสไฟล์ secrets-values.yaml ก่อนนำมาใช้งานจริงในระบบ หรือ
- ติดตั้งระบบ External Secrets Operator เพื่อเชื่อมต่อดึงข้อมูลความลับจากระบบ KMS ของคุณ เช่น AWS Secrets Manager, HashiCorp Vault, Azure Key Vault หรือ Google Secret Manager
การเชื่อมต่อกับ ESO และ Vault ในตัวซอฟต์แวร์โดยตรงอยู่ในแผนพัฒนาการทำงานของผลิตภัณฑ์ ในระหว่างนี้ มาตรการความปลอดภัยใดๆ ข้างต้นที่ผู้ใช้งานเลือกนำมาปรับใช้จะถือว่าเพียงพอต่อการรักษาความปลอดภัยระบบ
Redis ข้อมูลโควตาชั่วคราวและสถานะแคช (Redis — ephemeral quota and cache state)
จัดการดูแลโดย Opstree Redis operator ทำหน้าที่เก็บเฉพาะข้อมูลชั่วคราวเท่านั้น โดย ไม่มีข้อมูลสำคัญใดๆ จัดเก็บอยู่ใน Redis เป็นแหล่งอ้างอิงหลัก ค่าตัวนับทั้งหมดสามารถคำนวณใหม่ได้จากรายการใช้งานที่จัดเก็บในระบบ จึงสามารถคำนวณขึ้นมาใหม่ได้หากเกิดกรณีข้อมูลเสียหาย
| พื้นที่จัดเก็บคีย์ | ข้อมูลที่เก็บอยู่ภายใน | ความคงทนของข้อมูล |
|---|---|---|
| Quota / rate-limit counters | ตัวนับปริมาณโทเค็นต่อนาทีและตัวนับงบประมาณการเงินแยกตามคีย์ใช้งาน | ข้อมูลชั่วคราว โดยระบบจะล้างค่าและคำนวณใหม่โดยใช้ข้อมูลอ้างอิงหลักจาก PostgreSQL เมื่อมีการปรับปรุงสิทธิ์ (reconcile) ในรอบถัดไป |
| แคชด้านความหมาย (Semantic-cache entries) | ข้อมูลเวกเตอร์คำขอคู่กับคำตอบที่ได้จากโมเดล ในกรณีเลือกเปิดใช้งานฟีเจอร์นี้ | มีการกำหนดอายุใช้งาน (TTL) หากไม่พบข้อมูลในแคช ระบบจะเปลี่ยนไปดึงข้อมูลจากผู้ให้บริการโดยตรงโดยไม่ทำให้เกิดข้อผิดพลาดในการทำงาน |
ค่าความสูญเสียของข้อมูลที่ยอมรับได้ (RPO) สำหรับ Redis นั้นไม่มีความจำเป็นต้องกำหนด เนื่องจากหากเกิดกรณีข้อมูลใน Redis สูญหายจะส่งผลกระทบเพียงชั่วคราวต่อช่วงเวลาควบคุมการจำกัดปริมาณงาน โดยสามารถดูรายละเอียดเพิ่มเติมเกี่ยวกับผลกระทบได้จากส่วนของ FMEA ในหน้า สถาปัตยกรรมอ้างอิง (Reference architecture) และไม่ส่งผลให้ข้อมูลจริงสูญหายแต่อย่างใด
ระบบจัดเก็บออบเจกต์ (Object store สำหรับโครงสร้างแบบพร้อมใช้งานสูงเท่านั้น)
ใช้งานโดยระบบตรวจสอบการทำงานของ LGTM และระบบจัดเก็บไฟล์บันทึกการทำงานของฐานข้อมูล Postgres (WAL archiving) ในกรณีเปิดใช้งาน โดยเป็นระบบจัดเก็บข้อมูลแบบที่เข้ากันได้กับโปรโตคอล S3 ซึ่งคุณเป็นผู้จัดหาและดูแลถังเก็บข้อมูลนี้เอง
| ชนิดข้อมูล | พื้นที่จัดเก็บ | การควบคุมระยะเวลาเก็บรักษาข้อมูล |
|---|---|---|
| Mimir metrics blocks | ถังเก็บข้อมูล S3 ของคุณ | ตั้งค่าผ่าน mimir.storage.retention โดยสามารถกำหนดค่าได้ตามต้องการ |
| Loki log chunks | ถังเก็บข้อมูล S3 ของคุณ | ตั้งค่าผ่าน loki.storage.retention โดยสามารถกำหนดค่าได้ตามต้องการ |
| Tempo trace blocks | ถังเก็บข้อมูล S3 ของคุณ | ตั้งค่าผ่าน tempo.storage.retention โดยสามารถกำหนดค่าได้ตามต้องการ |
| PostgreSQL base backups (when enabled) | ถังเก็บข้อมูล S3 ของคุณ | กำหนดผ่านตารางเวลาการสำรองข้อมูลของ CNPG และนโยบายการเก็บรักษาข้อมูล |
ระบบจัดเก็บข้อมูลออบเจกต์นี้จะดำเนินงานและดูแลโดยคุณเองทั้งหมด โดยที่บริษัท Opsta จะไม่มีความสามารถในการเข้าถึงข้อมูลต่างๆ เหล่านี้ได้เลย
สรุปการจัดประเภทระดับชั้นข้อมูล (Data classification summary)
| ระดับชั้นข้อมูล | ตัวอย่างข้อมูล | มาตรการควบคุมที่จำเป็น |
|---|---|---|
| Critical | คีย์ API ของผู้ให้บริการ ข้อมูลความลับของ IdP คีย์ส่วนตัวสำหรับ TLS | การเข้ารหัสข้อมูล etcd หรือใช้ Sealed Secrets หรือระบบความลับภายนอก การกำหนดสิทธิ์แบบ RBAC อย่างเข้มงวด และมีตารางเวลาหมุนเวียนคีย์ |
| Sensitive | ตัวอย่างคำสั่งที่ทำผิดกฎความยาวไม่เกิน 280 ตัวอักษรที่บันทึกโดย guardrail | มีช่วงเวลาจัดเก็บข้อมูลที่สั้น จำกัดสิทธิ์เข้าถึงในระดับฐานข้อมูล และมีการเข้ารหัสข้อมูลขณะจัดเก็บ |
| Confidential | อีเมลของสมาชิก ชื่อองค์กรหรือโครงการ บันทึกการตรวจสอบความปลอดภัย บันทึกการใช้งานเพื่อเรียกเก็บเงิน | เข้ารหัสข้อมูลสำรอง บังคับใช้ TLS ระหว่างส่งข้อมูล และจำกัดสิทธิ์เข้าถึงเฉพาะบทบาทผู้ดูแลระบบ |
| Internal | ข้อมูลการตั้งค่างบประมาณ กฎการจัดส่งข้อมูล รูปแบบกฎของ guardrail | มาตรการควบคุมการเข้าถึงมาตรฐานทั่วไป |
| Ephemeral | ตัวนับประวัติการทำงานใน Redis ข้อมูลแคชด้านความหมาย | ไม่จำเป็นต้องสำรองข้อมูล หากเกิดกรณีข้อมูลสูญหายจะส่งผลเพียงทำให้การทำงานบางส่วนตอบสนองช้าลงชั่วคราวและไม่ถือว่าข้อมูลหลักสูญหาย |
การควบคุมระยะเวลาเก็บรักษาข้อมูล (Retention controls)
บันทึกการตรวจสอบและข้อมูลการบล็อกของ guardrail
ตาราง audit_log และตาราง guardrail_blocks จะใช้การตั้งค่าระยะเวลาเก็บรักษาข้อมูลร่วมกัน และจะมีการเคลียร์ข้อมูลเก่าเป็นประจำทุกวันดังนี้
# charts/opsta-ai-gateway/values.yaml
audit:
retentionDays: 365 # ค่าเริ่มต้น — สามารถปรับลดลงเพื่อความเป็นส่วนตัวของข้อมูลการบล็อก guardrailให้ปรับเปลี่ยนค่า audit.retentionDays ตามข้อกำหนดนโยบายความมั่นคงปลอดภัยขององค์กรคุณ เช่น 90 วัน เพื่อให้สอดคล้องกับข้อกำหนด GDPR หรือเลือกใช้ 730 วันหากคุณมีหน้าที่ต้องเก็บรักษาข้อมูลการตรวจสอบความปลอดภัยในระยะยาวตามกฎหมาย
การเก็บรักษาข้อมูลระบบตรวจสอบการทำงาน
สามารถตั้งค่าแยกตามประเภทของข้อมูลได้ในส่วนของ LGTM chart values ดังนี้
loki:
storage:
retention: 90d # ระยะเวลาเก็บรักษาไฟล์ log chunk
mimir:
# ดูรายละเอียดการตั้งค่าการรวบรวมข้อมูลในระบบ Mimir
tempo:
storage:
trace:
backend: s3
block_retention: 720h # 30 วันระบุหน่วยเป็นชั่วโมงตามรูปแบบ Go durationดูรายละเอียดการตั้งค่าทั้งหมดได้ที่หน้า ระบบตรวจสอบการทำงานของแพลตฟอร์ม (Platform observability)
การปกปิดข้อมูลระบุตัวตนบุคคล (PII masking สำหรับการเปิดใช้งานเป็นกรณีพิเศษ)
ระบบปกปิดข้อมูลระบุตัวตน (PII masking) ผ่านการระบุตั้งค่า guardrails.masking.enabled จะถูกปิดการใช้งานไว้เป็นค่าเริ่มต้นตั้งแต่รุ่น v1.8.1 เนื่องจากปลั๊กอินต้นทางมีข้อจำกัดในการตัดคำตอบของโมเดลกรณีใช้งานการดึงข้อมูลภายนอกแบบสตรีมมิ่ง (ซึ่งเป็นข้อผิดพลาดที่พบจากภายนอกในการทำงานของ Wasm plugin ด้านการทำบัฟเฟอร์ข้อมูลการเรียกใช้เครื่องมือภายนอกแบบสตรีมมิ่ง) การเปิดฟีเจอร์นี้ขณะที่แอปพลิเคชันของคุณใช้งานการเรียกใช้เครื่องมือภายนอกแบบสตรีมมิ่ง อาจส่งผลให้ข้อมูลฟิลด์ tool_calls ตกหล่นสูญหายได้
ช่วงเวลาที่ควรเปิดใช้งาน ควรเปิดใช้งานการปกปิดข้อมูลหากแอปพลิเคชันของคุณไม่มีการเรียกใช้เครื่องมือภายนอกแบบสตรีมมิ่ง หรือหากคุณมีความจำเป็นทางกฎหมายที่ต้องการปกปิดข้อมูลส่วนบุคคลและยอมรับข้อจำกัดด้านสตรีมมิ่งดังกล่าวได้
ช่วงเวลาที่ไม่ควรเปิดใช้งาน หากแอปพลิเคชันของคุณมีการใช้งานระบบเอเจนต์หรือการเรียกใช้เครื่องมือภายนอก (tool use) แบบที่ส่งข้อมูลกลับมาแบบสตรีมมิ่ง ขอแนะนำให้ปิดการตั้งค่านี้ไว้ก่อนจนกว่าข้อผิดพลาดข้างต้นจะได้รับการแก้ไขและอัปเดตเข้ามา ซึ่งได้รับการบันทึกไว้ในแผนพัฒนาของ Opsta เรียบร้อยแล้ว
วิธีการเปิดใช้งาน
# charts/opsta-ai-gateway/values.yaml (หรือส่วนการตั้งค่า overlay ของคุณ)
guardrails:
masking:
enabled: true
rules:
- type: replace
regex: "\\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\\.[A-Z]{2,}\\b"
placeholder: "[EMAIL]"
restore: false
# เพิ่มเติมกฎตามความต้องการของคุณได้ที่นี่การรับส่งข้อมูลไปยังผู้ให้บริการภายนอก (Provider data-in-flight)
คำสั่งและคำตอบจากโมเดลจะถูกส่งออกจากคลัสเตอร์ของคุณไปยังผู้ให้บริการ LLM ที่คุณระบุไว้ผ่านทางโปรโตคอล HTTPS โดยเกตเวย์จะทำหน้าที่เป็นเพียงตัวกลางในการส่งข้อมูลเท่านั้นและไม่มีการเก็บเนื้อความของคำสั่งหรือคำตอบเก็บไว้ในฐานข้อมูล ยกเว้นแต่ข้อมูลตัวอย่างความยาวสั้นกรณีคำสั่งถูกบล็อกโดย guardrail ตามที่ระบุไว้ในตอนต้น
การพัฒนาและฝึกสอนโมเดลพร้อมทั้งการไม่บันทึกข้อมูลของระบบปลายทาง
นโยบายของผู้ให้บริการเกี่ยวกับการนำข้อมูลคำสั่งไปพัฒนาหรือฝึกสอนโมเดลเพิ่มเติม หรือข้อตกลงเกี่ยวกับการไม่บันทึกข้อมูลของผู้ใช้เลย (Zero Data Retention) จะเป็นไปตามเงื่อนไขและข้อตกลงในการใช้บริการระหว่างคุณกับผู้ให้บริการนั้นๆ โดยทาง Opsta ไม่สามารถเข้าไปควบคุมหรือตรวจสอบมาตรการด้านข้อมูลของผู้ให้บริการเหล่านั้นแทนคุณได้ ผู้ใช้งานต้องเลือกผู้ให้บริการที่มีนโยบายตรงตามความปลอดภัยขององค์กรเอง
สำหรับงานที่มีนโยบายห้ามส่งข้อมูลออกนอกพื้นที่เซิร์ฟเวอร์เด็ดขาด โปรดเลือกตั้งค่าใช้งานโมเดลภายในองค์กร (on-premises model) ผ่านทาง Ollama และกำหนดเส้นทางข้อมูลให้ส่งไปยังโมเดลดังกล่าวเท่านั้น โดยสามารถดูรายละเอียดเพิ่มเติมได้ที่หน้า ผู้ให้บริการโมเดลที่รองรับ (Supported providers)
ปลายทางข้อมูลออกนอกระบบ (Egress endpoints)
ระหว่างการทำงาน เกตเวย์จะมีการเชื่อมต่อ HTTPS ขาออกไปยังปลายทางดังนี้
- ผู้ให้บริการ LLM ที่กำหนดค่าไว้ เช่น ลิงก์ที่คุณตั้งค่าแยกตามผู้ให้บริการ อาทิ
api.openai.comหรือapi.anthropic.comซึ่งคุณเป็นผู้ควบคุมรายการทั้งหมดเอง - เซิร์ฟเวอร์ MCP ที่ตั้งค่าไว้ ตามลิงก์ที่ระบุไว้ในข้อมูลของแต่ละเซิร์ฟเวอร์ MCP
- ระบบ ACME API ของ Let's Encrypt ปลายทาง
acme-v02.api.letsencrypt.orgเฉพาะกรณีเลือกใช้โหมดtls.mode: letsencryptเท่านั้น - ไม่มีการเชื่อมต่อภายนอกอื่นๆ ไม่มีการส่งข้อมูลสถิติกลับมาที่ Opsta ไม่มีการวิเคราะห์ข้อมูลการใช้งาน หรือการเชื่อมต่อกลับมาเพื่อตรวจสอบใดๆ ทั้งสิ้น
สำหรับคลัสเตอร์ที่ติดตั้งในระบบปิด ให้เลือกตั้งค่าใช้งาน CA ภายในองค์กร เช่น tls.mode: provided หรือ selfsigned และทำสำเนาอิมเมจทั้งหมดเข้าสู่ระบบ ซึ่งจะทำให้ไม่จำเป็นต้องมีการเชื่อมต่อเครือข่ายขาออกสู่ภายนอกเลยหลังจากติดตั้งเสร็จสิ้น โดยสามารถดูรายละเอียดเพิ่มเติมได้ที่หน้า การติดตั้งในระบบปิด (Air-gapped install)
การโอนย้ายข้อมูลข้ามประเทศและพื้นที่จัดเก็บข้อมูล (Cross-border and residency)
เนื่องจากระบบจัดเก็บข้อมูลทั้งหมดทำงานอยู่ภายในคลัสเตอร์ของคุณเอง พื้นที่จัดเก็บข้อมูลจริงจึงเป็นไปตามพื้นที่ที่คลัสเตอร์ติดตั้งอยู่ โดยคุณสามารถเลือกติดตั้งระบบในพื้นที่หรือศูนย์ข้อมูลตามที่กฎหมายและมาตรการปฏิบัติตามข้อกำหนดระบุไว้ได้ทันที
การโอนย้ายข้อมูลออกนอกประเทศจะเกิดขึ้นเฉพาะกรณีที่มีการส่งข้อมูลคำสั่งไปยังผู้ให้บริการ LLM เท่านั้น ซึ่งคุณเป็นผู้ควบคุมทั้งหมดด้วยตนเองโดยการเลือกใช้ลิงก์ปลายทางของผู้ให้บริการในพื้นที่ที่กำหนด หรือเลือกใช้งานโมเดลที่รันอยู่ในเครื่องตัวเองแทน
ไม่มีการส่งข้อมูลสถิติการใช้งานออกภายนอก (No external telemetry)
ระบบไม่มีการส่งข้อมูลประเภทใดๆ ต่อไปนี้กลับมายังบริษัท Opsta หรือผู้ให้บริการรายอื่นภายนอกทั้งสิ้น
- ข้อมูลการวัดระดับการใช้งาน เช่น ปริมาณโทเค็น หรือความถี่ของคำสั่งใช้งาน
- เนื้อหาคำสั่งหรือคำตอบที่ได้รับกลับมา
- ข้อมูลระบุตัวตนของผู้ใช้หรือข้อมูลองค์กร
- นโยบายความปลอดภัยและข้อมูลการตั้งค่าระบบ
- บันทึกข้อผิดพลาดในการทำงานของระบบ
ข้อมูลการตรวจสอบและการเฝ้าระวังทั้งหมดจะถูกเก็บรักษาไว้ภายในชุดระบบ LGTM ที่คุณดูแลและรันอยู่บนเซิร์ฟเวอร์ตนเองเท่านั้น
หน้าเว็บที่เกี่ยวข้อง
- ตารางความรับผิดชอบร่วมกันและระดับความพร้อมในการใช้งาน (Shared responsibility & maturity)
- อธิปไตยของข้อมูล (Data sovereignty)
- การตรวจสอบระบบและการปฏิบัติตามข้อกำหนด (Audit & compliance)
- การสำรองข้อมูลและการกู้คืน (Backup & DR)
- การเพิ่มความปลอดภัยให้ระบบ (Hardening)
- สถาปัตยกรรมอ้างอิง (Reference architecture)