ความรับผิดชอบร่วมกันและระดับความพร้อมในการใช้งาน
หน้านี้เป็นข้อมูลที่สำคัญที่สุดสำหรับคณะกรรมการตรวจสอบสถาปัตยกรรมหรือคณะกรรมการความปลอดภัยของระบบ โดยจะระบุรายละเอียดของแต่ละฟีเจอร์อย่างชัดเจนในสองประเด็นคือ ใครเป็นผู้รับผิดชอบดูแล ระหว่าง Opsta หรือตัวคุณเอง และ ระดับความพร้อมในการใช้งานในปัจจุบัน เพื่อให้คุณสามารถประเมินขอบข่ายงานและความเสี่ยงได้ก่อนการลงนามรับรองระบบจริง ทั้งนี้ เราประสงค์จะแจ้งข้อมูลตรงตามจริงหากการควบคุมความปลอดภัยส่วนใดเป็นทางเลือกให้เปิดใช้งานเองหรืออยู่ระหว่างแผนพัฒนา แทนการอ้างอิงคุณสมบัติความปลอดภัยที่ระบบในรุ่นปัจจุบันยังไม่รองรับจริง
เอกสารนี้เหมาะสำหรับใคร
ทีมงานสถาปัตยกรรม ความปลอดภัย และผู้ดูแลระบบที่ต้องการประเมินการนำ Opsta AI Gateway ไปใช้งานจริง โดยควรอ่านข้อมูลควบคู่ไปกับหน้า รายการตรวจสอบความพร้อมสำหรับใช้งานจริง (Production-readiness checklist) เนื่องจากทุกหัวข้อที่เป็นสิทธิ์การจัดการของ "ลูกค้า" (you provide) จะมีหัวข้อการตรวจสอบที่ตรงกันอยู่ในหน้านั้น
วิธีการอ่านคอลัมน์ระดับความพร้อมในการใช้งาน
| ระดับความพร้อม | ความหมาย |
|---|---|
| Shipped | เปิดใช้งานเป็นค่าเริ่มต้นและทำงานปกติ |
| Shipped (toggle) | ถูกพัฒนาและรองรับโดยสมบูรณ์ โดยคุณเป็นผู้เปิดใช้งานตามสถาปัตยกรรมที่เลือก เช่น ระบบ HA |
| Opt-in | พัฒนาเสร็จสิ้นแต่ปิดใช้งานไว้เป็นค่าเริ่มต้น โดยคุณต้องเปิดระบบด้วยตัวเองและยอมรับข้อจำกัดที่ระบุไว้ |
| Roadmap | ยังไม่ได้พัฒนาในเวอร์ชันปัจจุบัน โดยอาจมีคู่มือการตั้งค่าเพื่อเลี่ยงชั่วคราวให้ในตอนนี้ และจะพัฒนาเป็นฟีเจอร์ภายในตัวในอนาคต |
| You provide | ความสามารถที่ผลิตภัณฑ์จำเป็นต้องพึ่งพาระบบโครงสร้างพื้นฐานของคุณ เช่น ตัวคลัสเตอร์ ระบบจัดเก็บข้อมูล ระบบ KMS ระบบ IdP หรือระบบแจ้งเตือนหลัก |
ตัวซอฟต์แวร์ระบบจะถูกส่งมอบในลักษณะอุปกรณ์สำเร็จรูป (Appliance) โดยระบบส่วนประกอบทั้งหมดอันได้แก่ Higress, PostgreSQL (CloudNativePG), Redis, Keycloak, ชุดระบบตรวจสอบการทำงาน LGTM, cert-manager และ control plane พร้อม Console จะได้รับการติดตั้งรวมกันเป็นหน่วยเดียวที่มีการตรวจสอบรุ่นอย่างชัดเจน ส่วนข้อมูลคลัสเตอร์ Kubernetes ที่ได้มาตรฐาน ระบบจัดเก็บข้อมูล ระบบ DNS รวมถึงระบบ IdP ภายนอกและถังเก็บข้อมูลออบเจกต์จะถูกจัดเตรียมโดยคุณเอง
ตารางเปรียบเทียบระดับความรับผิดชอบและระดับความพร้อม
| ความสามารถของระบบ | ระดับความพร้อม | สิ่งที่ Opsta จัดเตรียมให้ | สิ่งที่คุณต้องจัดเตรียมเอง |
|---|---|---|---|
| การจัดเส้นทางโมเดล งบประมาณการใช้งานแยกตามองค์กรและโครงการ ระบบ guardrails บันทึกประวัติการตรวจสอบความปลอดภัย และระบบควบคุมสิทธิ์ RBAC | Shipped | ซอฟต์แวร์และฟังก์ชันในระบบ | การกำหนดค่าการตั้งค่าและนโยบายการทำงาน |
| การแยกส่วนข้อมูลตัววัดและบันทึกการทำงานของระบบตรวจสอบแยกตามองค์กร | Shipped | ชุดระบบ LGTM แยกตาม tenant และ proxy ควบคุมการเข้าถึง | — |
| ความพร้อมใช้งานสูง ทั้งการทำซ้ำส่วนประกอบ กฎ PodDisruptionBudget กฎ anti-affinity และฐานข้อมูลหรือ Redis แบบคลัสเตอร์ | Shipped (toggle) | การตั้งค่าใน Helm chart ผ่าน global.highAvailability: true | คลัสเตอร์ที่มีจำนวนตั้งแต่ 3 โหนดขึ้นไป |
| การเข้ารหัส TLS ที่ ingress ด้วย Let's Encrypt หรือใบรับรอง wildcard ขององค์กรคุณ | Shipped (toggle) | ระบบ cert-manager และตัวควบคุมการขอใบรับรอง | ระบบ DNS และเส้นทางการเชื่อมต่อ ACME หรือใบรับรองพร้อมคีย์ความลับส่วนตัว |
| การสำรองข้อมูลและการกู้คืนข้อมูลระบบฐานข้อมูล | Opt-in | ระบบสำรองข้อมูล CloudNativePG และเอกสารคู่มือขั้นตอนการทำงาน | ถังเก็บข้อมูลออบเจกต์พร้อมการเปิดใช้ค่าระบบ และการทดสอบฝึกซ้อมการกู้คืนจริง |
| การกู้คืนข้อมูลแบบระบุจุดเวลา (Point-in-time recovery ผ่านการจัดเก็บไฟล์ WAL ต่อเนื่อง) | Roadmap | คู่มือสำหรับตั้งค่าบันทึกไฟล์ WAL ของ CNPG เพื่อเลี่ยงชั่วคราว | — |
| การเข้ารหัสข้อมูลความลับขณะจัดเก็บ (Secrets encrypted at rest) | You provide | ข้อมูลความลับจะถูกแยกออกจาก git และฐานข้อมูลโดยบันทึกอยู่ในรูปแบบ Kubernetes Secrets มาตรฐาน | การเปิดระบบเข้ารหัส etcd การติดตั้ง Sealed Secrets หรือใช้ External Secrets เพื่อดึงคีย์จาก KMS |
| การปกปิดข้อมูลส่วนบุคคลในคำสั่งและคำตอบ (PII masking) | Opt-in | ปลั๊กอินสำหรับการปกปิดข้อมูล | เปิดใช้งานการตั้งค่าและยอมรับข้อจำกัดเกี่ยวกับระบบสตรีมมิ่งที่ระบุด้านล่าง |
| การเก็บรักษาเนื้อหาข้อมูลคำสั่งที่ติดกฎของ guardrail | Opt-in | การระงับการทำงานตามกฎ guardrail | ตัดสินใจระยะเวลาและแนวทางการปกปิดข้อความตัวอย่างที่ถูกบันทึกไว้ในระบบ |
| การทำ DR failover ข้ามสาขาหรือข้ามภูมิภาค | Roadmap | ระบบกู้คืนจากข้อมูลสำรองในสาขาเดียว | การติดตั้งศูนย์กู้คืนภัยพิบัติระบบภายนอกยังไม่อยู่ในขอบข่ายของรุ่นปัจจุบัน |
| การเซ็นกำกับความถูกต้องอิมเมจ เอกสารคลังส่วนประกอบ (SBOM) และการรับรองแหล่งที่มา | Roadmap | การระบุใช้อิมเมจแบบล็อกรหัสเฉพาะเจาะจง (digest) เพื่อเลี่ยงชั่วคราว | ตั้งค่าสแกนอิมเมจเมื่อดึงมาใช้งานและตรวจสอบความปลอดภัยในไปป์ไลน์ของคุณ |
| การนำผู้ใช้ออกจากระบบยืนยันตัวตนอัตโนมัติ (SCIM) | Roadmap | การสร้างผู้ใช้แบบทันทีและการลบผู้ใช้งานแบบแมนนวลใน Keycloak | คู่มือขั้นตอนการลบสิทธิ์พนักงานออกเมื่อพ้นสภาพ |
| ระบบแจ้งเตือนเมื่อเกิดความผิดปกติในสัญญาณหลัก | You provide | ระบบ Grafana พร้อมเอกสารคำแนะนำตั้งค่ากฎการแจ้งเตือน | เชื่อมต่อข้อมูลแจ้งเตือนไปยังระบบของทีมงาน เช่น PagerDuty หรือ Opsgenie |
| ระบบคลัสเตอร์ Kubernetes ประเภทพื้นที่จัดเก็บข้อมูล และ CNI สำหรับเครือข่าย | You provide | การทดสอบกับตารางดิสทริบิวชันมาตรฐานที่ผ่านการรับรอง | คลัสเตอร์ที่ได้มาตรฐานพร้อมพื้นที่จัดเก็บแบบ RWO และระบบจัดเก็บข้อมูลออบเจกต์สำหรับระบบ HA |
หมายเหตุชี้แจงความโปร่งใสเกี่ยวกับการทำงานจริง
รายละเอียดเหล่านี้เป็นหัวข้อที่คณะกรรมการตรวจสอบมักตั้งคำถาม โดยจะระบุรายละเอียดของระบบ เหตุผล และแนวทางแก้ไขที่คุณสามารถปฏิบัติได้จริง
ระบบสำรองข้อมูลปิดทำงานไว้เป็นค่าเริ่มต้น
ระบบสำรองข้อมูลระบบฐานข้อมูล (postgres.backup.enabled) จะถูกปิดการทำงานไว้ เพื่อช่วยให้กระบวนการติดตั้งซอฟต์แวร์เริ่มต้นทำงานได้โดยไม่ต้องบังคับให้สร้างถังเก็บข้อมูลออบเจกต์ตั้งแต่แรก อย่างไรก็ตามสำหรับการใช้งานจริงในองค์กร คุณจำเป็นต้องเปิดตั้งค่านี้ ชี้ข้อมูลไปยังถังเก็บข้อมูลที่เข้ากันได้กับโปรโตคอล S3 และทำการทดสอบฝึกซ้อมการกู้คืนจริง โดยศึกษาคู่มือได้ที่หน้า การสำรองข้อมูลและการกู้คืน (Backup & DR) ซึ่งรายการตรวจสอบความพร้อมก่อนเริ่มใช้งานจริงจะมีขั้นตอนบังคับในหัวข้อนี้ด้วย ในส่วนของโปรไฟล์ HA ในอนาคตจะมีการตั้งค่าให้เปิดระบบสำรองข้อมูลไว้เลย แต่อย่างไรคุณก็ยังจำเป็นต้องระบุปลายทางของถังเก็บข้อมูลด้วยตนเอง
ระบบ Point-in-time recovery ยังไม่ได้เชื่อมโยงในระบบ
กระบวนการสำรองข้อมูลในปัจจุบันจะอยู่ในลักษณะบันทึกภาพรวมตามช่วงเวลาที่กำหนด ไม่ใช่การจัดเก็บไฟล์บันทึกรายการแบบต่อเนื่อง (continuous WAL archiving) ส่งผลให้จุดเวลาที่ข้อมูลจะกู้คืนได้จะขึ้นกับช่วงเวลาสำรองข้อมูลและไม่ได้ลงลึกระดับวินาที การทำ PITR อย่างต่อเนื่องแบบในตัวอยู่ในแผนพัฒนาการทำงานของระบบ ในตอนนี้ผู้ดูแลระบบสามารถเลือกตั้งค่าการส่งไฟล์ WAL ของ CNPG เพื่อลดระดับความเสียหายข้อมูลที่ยอมรับได้ (RPO) ให้แคบลงแทนได้
ข้อมูลความลับจัดเก็บในลักษณะ Kubernetes Secrets
คีย์ API ของผู้ให้บริการโมเดลภายนอกและข้อมูลความลับของระบบ IdP หรือ MCP จะไม่มีการเก็บไว้ในฐานข้อมูลหรือในประวัติ git โดยจะอยู่ในส่วนของ Kubernetes Secrets เท่านั้น ข้อมูลดังกล่าวจัดเก็บด้วยการเข้ารหัสแปลงรหัสในรูปแบบ base64 และยังไม่ได้เข้ารหัสเพื่อป้องกันการโจรกรรมไฟล์ เว้นแต่ระบบคลัสเตอร์ของคุณจะเปิดระบบป้องกันนี้ไว้ ดังนั้นผู้ใช้งานจำเป็นต้องเปิดใช้งานการเข้ารหัสข้อมูลขณะจัดเก็บด้วยตัวเอง เช่น ตั้งค่าเข้ารหัส etcd ติดตั้ง Sealed Secrets หรือใช้ External Secrets เพื่อทำงานร่วมกับระบบ KMS และระบบการดึงข้อมูลความลับร่วมกับ Vault แบบในตัวอยู่ในแผนพัฒนาการทำงาน
การปกปิดข้อมูลส่วนบุคคลเป็นระบบที่ต้องเลือกเปิดใช้งานเอง
ปลั๊กอินปกปิดข้อมูล PII ถูกปิดการใช้งานไว้เป็นค่าเริ่มต้น เนื่องจากระบบปลั๊กอินต้นทางในปัจจุบันอาจส่งผลให้ข้อมูลฟิลด์การเรียกใช้เครื่องมือภายนอกแบบสตรีมมิ่งถูกตัดทอนได้ คุณสามารถเลือกเปิดฟีเจอร์นี้ได้หากนโยบายการดูแลข้อมูลขององค์กรมีความเข้มงวดและยอมรับเงื่อนไขข้อจำกัดเกี่ยวกับระบบสตรีมมิ่งได้ โดยศึกษารายละเอียดเพิ่มเติมได้ที่หน้า อธิปไตยของข้อมูล
ข้อมูลการบล็อกคำสั่งของ guardrail จะจัดเก็บข้อความตัวอย่างสั้นๆ
เมื่อระบบ guardrail ทำการบล็อกการทำงาน คำสั่งบางส่วนที่เป็นข้อความตัวอย่างที่ทำผิดกฎจะถูกเก็บเข้าระบบบันทึกตรวจสอบความปลอดภัย ซึ่งข้อความดังกล่าวอาจมีข้อมูลระบุตัวตนหรือคีย์ความลับที่หลุดเข้ามาจริงๆ ดังนั้นจึงขอให้ระมัดระวังและดูแลข้อมูลในส่วนนี้อย่างเข้มงวดเสมือนข้อมูลที่มีความสำคัญสูง โดยคุณสามารถตั้งค่าระยะเวลาจัดเก็บข้อมูลและเลือกที่จะไม่บันทึกหรือทำลายข้อมูลข้อความตัวอย่างเหล่านี้ได้
ระบบกู้คืนภัยพิบัติทำงานในลักษณะกู้คืนข้อมูลภายในสาขาเดียว
การเปิดตั้งค่าความพร้อมใช้งานสูงด้วย global.highAvailability จะทำหน้าที่ช่วยระบบสำรองความปลอดภัยภายในคลัสเตอร์เดียวกันเพื่อป้องกันโหนดใช้งานเสียหาย และไม่รองรับกรณีเซิร์ฟเวอร์หลักพังทั้งระบบ (site loss) โดยระบบยังไม่มีระบบการเตรียมเครื่องพร้อมรันในสาขาสำรองหรือสลับข้ามภูมิภาคโดยอัตโนมัติ ซึ่งหากเกิดความเสียหายในระดับคลัสเตอร์หลักทั้งคลัสเตอร์ จะต้องใช้วิธีนำข้อมูลสำรองไปสร้างใหม่ทั้งหมดบนระบบโครงสร้างพื้นฐานใหม่เท่านั้น และการทำ DR ในระบบคลัสเตอร์คู่ยังไมู่อยู่ในขอบข่ายการทำงานขณะนี้
การรับรองซอฟต์แวร์ห่วงโซ่อุปทานยังไม่ได้ลงนาม
อิมเมจระบบถูกพัฒนาและยกสถานะรุ่นผ่านทางวิธีการเปลี่ยนแท็กจากระบบ uat ไปยังรุ่นรุ่น vX.Y.Z โดยระบบในปัจจุบันยังไม่มีการลงลายเซ็นความถูกต้องด้วย cosign ไม่มีรายงาน SBOM หรือข้อมูลประวัติซอฟต์แวร์ SLSA มาตรการควบคุมเพื่อป้องกันชั่วคราวคือการระบุใช้อิมเมจแบบล็อกรหัส digest ร่วมกับการทำกระบวนการสแกนอิมเมจในฝั่งของคุณเมื่อดึงอิมเมจลงมาทำงาน โดยระบบการเซ็นชื่อความถูกต้องและเอกสาร SBOM อยู่ในแผนพัฒนาการทำงาน
ระบบผู้ใช้ทำงานแบบ JIT และการลบผู้ใช้ทำแบบแมนนวล
บัญชีผู้ใช้จะถูกสร้างขึ้นทันทีเมื่อเข้าระบบเป็นครั้งแรกผ่านทาง SSO โดยในตอนนี้ยังไม่มีความสามารถลบผู้ใช้ออกจากระบบอัตโนมัติ (SCIM) เมื่อมีพนักงานพ้นสภาพการทำงาน ทำให้ผู้ควบคุมระบบจำเป็นต้องมาลบข้อมูลบัญชีของพนักงานออกแบบแมนนวลใน Keycloak โดยตรง ขอแนะนำให้จัดเตรียมคู่มือสำหรับการลบสิทธิ์พนักงานออกให้ชัดเจน ส่วนระบบ SCIM อยู่ในแผนพัฒนาการทำงาน
ความสามารถในการย้อนกลับซอฟต์แวร์เมื่อทำการอัปเกรด
กระบวนการปรับปรุงข้อมูลฐานข้อมูลของ control plane ในระหว่างรันจะเป็นลักษณะปรับเปลี่ยนไปข้างหน้าเท่านั้น แม้จะมีคู่มือการย้อนโครงสร้างข้อมูลแยกต่างหากเพื่อความปลอดภัย แต่จะไม่มีขั้นตอนการทำย้อนกลับโครงสร้างข้อมูลโดยอัตนัติ ส่งผลให้การสลับรุ่นอิมเมจของ control plane ย้อนกลับภายหลังการอัปเกรดฐานข้อมูลไม่สามารถทำได้ทันที ผู้ดูแลระบบต้องทำการสำรองข้อมูลฐานข้อมูลล่วงหน้าเสมอก่อนเริ่มทำการอัปเกรด โดยศึกษาขั้นตอนการย้อนกลับได้ที่หน้า การอัปเกรดระบบ (Upgrades)