ความปลอดภัยใน cloud QMS ขึ้นอยู่กับสองคำถาม ใครย้ายเอกสารระหว่างสถานะวงจรชีวิตได้ และใครอ่านบันทึกสิ่งที่เกิดขึ้นหลังจากนั้นได้ ทุกอย่างอื่น การเข้ารหัส การโฮสต์ อัปไทม์ เป็นมาตรฐานพื้นฐานที่แพลตฟอร์ม cloud ที่สมเหตุสมผลไหนก็มีอยู่แล้ว ส่วนที่เฉพาะเจาะจงกับการควบคุมเอกสาร ISO คือการควบคุมสิทธิ์การเข้าถึงที่แมปกับจุดตัดสินใจจริงของคุณ และ audit trail ที่ไม่มีใครแอบแก้ไขได้
เรื่องนี้มักถูกข้ามไปในบทสนทนาเรื่องความปลอดภัย QMS ส่วนใหญ่ ที่มักตกไปใช้ภาษาเช็คลิสต์ทั่วไปเรื่อง "ความปลอดภัยระดับองค์กร" โดยไม่บอกว่ามันหมายความว่าอย่างไรสำหรับเอกสารที่ปล่อยใช้งานได้โดยคนสองคนที่ระบุไว้เฉพาะเจาะจงเท่านั้น ถ้าระบบตอบไม่ได้ว่า "ใครมีสิทธิ์อนุมัติสิ่งนี้ และฉันพิสูจน์ได้ไหมว่ามีแค่พวกเขาที่ทำ" มาตรฐานการเข้ารหัสที่อยู่เบื้องหลังก็ไม่ใช่ประเด็นสำคัญแล้ว
การควบคุมสิทธิ์การเข้าถึง คือสิทธิ์ที่แมปกับจุดตัดสินใจ ไม่ใช่บทบาททั่วไป
การควบคุมสิทธิ์การเข้าถึงของซอฟต์แวร์ส่วนใหญ่สร้างขึ้นรอบบทบาททั่วไป ผู้ดูแลระบบ ผู้แก้ไข ผู้ดู ที่ไม่ตรงกับวิธีที่การควบคุมเอกสาร ISO 9001 ทำงานจริงเลย สิทธิ์การเข้าถึงการควบคุมเอกสารไม่ใช่แค่เรื่องใคร "แก้ไข" เอกสารได้ แต่เป็นเรื่องใครทริกเกอร์แต่ละจุดตัดสินใจที่ SOP ของคุณกำหนดไว้แล้วได้ และใครทำได้แค่สังเกตการณ์
cloud QMS ที่สร้างขึ้นรอบวงจรชีวิตเอกสารจริงของคุณ ควรให้คุณกำหนดสิทธิ์ด้วยคำศัพท์ที่ SOP ของคุณใช้อยู่แล้ว ไม่ใช่บทบาทแอปทั่วไป
- ใครส่งคำขอเปลี่ยนแปลงได้ (มักกว้าง ใครก็เสนอได้)
- ใครเป็นผู้ทบทวนที่จุดแรกได้ (มักเป็นบทบาทที่กำหนดไว้ ไม่ใช่ทุกคน)
- ใครเป็นผู้อนุมัติที่จุดความเหมาะสมของเนื้อหาได้ (มักแคบกว่านั้นอีก)
- ใครดำเนินการลงนามอนุมัติสุดท้ายที่รวมทุกฝ่ายเพื่อปล่อยเอกสารหลักได้
- ใครอ่านทะเบียนและบันทึกกิจกรรมได้เท่านั้น โดยไม่มีสิทธิ์เขียนเลย
สิ่งนี้แมปตรงกับสี่จุดตัดสินใจที่ automation ที่สร้างอย่างถูกต้องรักษาไว้เสมอ การลงนามของผู้ทบทวน การตรวจสอบของผู้อนุมัติ และจุดรวมสุดท้ายที่ครอบคลุมเอกสารหลักและเอกสารภายนอก/สนับสนุน โครงสร้างสิทธิ์ไม่ใช่ชั้นความปลอดภัยแยกต่างหากที่เพิ่มเข้าไปใน workflow แต่เป็นโครงสร้างเดียวกับที่ workflow บังคับใช้อยู่แล้ว นำมาใช้กำหนดว่าใครมีสิทธิ์ทริกเกอร์ขั้นตอนไหน
โฟลเดอร์คือขอบเขตสิทธิ์การเข้าถึง ไม่ใช่แค่ตัวทริกเกอร์ workflow
ในระบบที่สถานะวงจรชีวิตเอกสารสะท้อนผ่านโฟลเดอร์จริง ฉบับร่าง อยู่ระหว่างทบทวน อนุมัติแล้ว ยกเลิกแล้ว และอื่น ๆ ตามวงจรชีวิตที่กำหนดไว้ สิทธิ์โฟลเดอร์และสิทธิ์ workflow ควรเป็นสิ่งเดียวกัน ไม่ใช่สองระบบที่เบี่ยงเบนไม่ตรงกันได้ ถ้ามีคนมีสิทธิ์เขียนในโฟลเดอร์ แต่ไม่ใช่ผู้อนุมัติที่กำหนดไว้ใน workflow นั่นคือช่องโหว่ความปลอดภัยที่ปลอมตัวเป็นความสะดวก
นี่ก็เป็นจุดที่ "ใครย้ายโฟลเดอร์" กลายเป็นคำถามด้านความปลอดภัย ไม่ใช่แค่คำถามด้านกระบวนการ การย้ายเอกสารเข้าโฟลเดอร์สถานะอนุมัติแล้ว คือการตัดสินใจของคนที่ทริกเกอร์ทุกอย่างที่ตามมา การเขียนทะเบียน การอัปเดตการแจกจ่าย นาฬิกาเก็บรักษา การจำกัดว่าใครทำการย้ายนั้นได้ เท่ากับการจำกัดว่าใครอนุมัติเอกสารได้ในทางปฏิบัติ ซึ่งหมายความว่าสิทธิ์ระดับโฟลเดอร์สมควรได้รับการตรวจสอบละเอียดเท่ากับบทบาทการอนุมัติใด ๆ ไม่ใช่ตรวจสอบหลวมกว่าเพราะมัน "แค่" ย้ายไฟล์
ทำไมความปลอดภัย cloud QMS เริ่มที่ใครเป็นเจ้าของสภาพแวดล้อม
คำถามความปลอดภัยที่ผู้ขาย QMS ส่วนใหญ่ไม่อยากให้ถูกถาม คือระบบนี้รันอยู่ในสภาพแวดล้อมของใครจริง ๆ ระบบที่สร้างให้ลูกค้าเป็นเจ้าของ ติดตั้งใน Google Workspace และ automation instance ของคุณเอง ไม่ใช่แพลตฟอร์ม SaaS แบบ multi-tenant ที่ใช้ร่วมกันซึ่งผู้ขายรัน หมายความว่าข้อมูลเอกสาร log การเข้าถึง และโครงสร้างสิทธิ์ของคุณ อยู่ในโครงสร้างพื้นฐานที่คุณควบคุมและตรวจสอบเองได้อยู่แล้ว ไม่มีการผูกติดกับผู้ขาย ก็หมายความว่าไม่ต้องพึ่งการมีอยู่ ราคา หรือท่าทีความปลอดภัยของผู้ขายต่อไป เพื่อให้บันทึกของคุณเองยังเข้าถึงได้
นี่คือโมเดลความปลอดภัยที่ต่างจาก SaaS QMS ทั่วไปจริง ๆ ที่ข้อมูลควบคุมเอกสารของคุณอยู่บนโครงสร้างพื้นฐานที่ใช้ร่วมกันของผู้ขาย และการเข้าถึง audit trail ของคุณเองขึ้นอยู่กับสัญญาที่คุณมีกับพวกเขายังใช้งานได้อยู่หรือไม่ การติดตั้งที่ลูกค้าเป็นเจ้าของไม่ได้แทนที่แนวปฏิบัติการควบคุมสิทธิ์ที่ดี มันแค่หมายความว่าขอบเขตของสิ่งที่คุณกำลังรักษาความปลอดภัยเป็นของคุณทั้งหมด ไม่ได้ใช้ร่วมกับลูกค้ารายอื่นของผู้ขาย
บันทึกกิจกรรมในฐานะการควบคุมความปลอดภัย ไม่ใช่แค่หลักฐาน compliance
ทุกการเขียนอัตโนมัติ ช่องข้อมูลแปดช่องที่เจ้าหน้าที่ควบคุมเอกสารเคยพิมพ์ซ้ำด้วยมือ ควรถูกบันทึก log แยกกันในบันทึกกิจกรรม ประทับเวลา และผูกกับเหตุการณ์ของคนที่เป็นต้นเหตุ บันทึกนั้นทำหน้าที่สองอย่างพร้อมกัน เป็นหลักฐานการตรวจประเมินที่ ISO 9001 ต้องการ และเป็นการควบคุมความปลอดภัย เพราะทำให้การเปลี่ยนแปลงที่ไม่ได้รับอนุญาตหรือนอกกระบวนการมองเห็นได้ แทนที่จะเงียบหายไป
บันทึกกิจกรรมที่สร้างมาดีควรเป็นแบบนี้
| คุณสมบัติ | เหตุผลที่สำคัญต่อความปลอดภัย |
|---|---|
| เพิ่มได้อย่างเดียว แก้ไม่ได้ | รายการที่ถูกแก้หรือลบตรวจจับได้ในตัวเอง |
| ผูกกับเหตุการณ์ของคนที่เป็นต้นเหตุ | ทุกการเขียนย้อนกลับไปถึงการตัดสินใจที่มีชื่อระบุ ไม่ใช่การกระทำของระบบแบบไม่ระบุตัวตน |
| อ่านได้โดยคนมากกว่าที่เขียนได้ | การกำกับดูแล (QMR ผู้ตรวจประเมิน) ไม่ควรต้องมีสิทธิ์เขียน |
| แยกจากทะเบียนที่มันบันทึก | ทะเบียนที่ถูกโจมตี ไม่ลบประวัติของตัวเองไปด้วย |
นี่ก็เป็นเหตุผลที่ idempotency สำคัญต่อความปลอดภัยด้วย ไม่ใช่แค่ความสมบูรณ์ของข้อมูล workflow ที่ถูกออกแบบด้วย idempotency key หมายความว่าการเล่นซ้ำเหตุการณ์อนุมัติเดียวกัน โดยตั้งใจหรือไม่ก็ตาม ไม่สร้างรายการซ้ำในทะเบียน สิ่งนี้ปิดช่องทางการปั่นแต่งข้อมูลเฉพาะทาง ไม่มีใครขยายหรือทำให้ทะเบียนเสียหายได้ด้วยการส่งการอนุมัติเดียวกันซ้ำหลายครั้ง
สิ่งที่ automation ไม่ควรถูกอนุญาตให้แตะต้องเด็ดขาด
ไม่ว่าการควบคุมสิทธิ์จะระดับไหน กฎพื้นฐานไม่เปลี่ยน automation ไม่ควรมีระดับสิทธิ์ที่ให้มันอนุมัติเนื้อหาได้ ไม่มีบทบาทผู้ดูแลระบบ ไม่มีการ override ไม่มีการตั้งค่าข้ามขั้นฉุกเฉินใด ที่ควรให้ระบบทำเครื่องหมายว่าเอกสารเหมาะสมได้เอง ทุกโครงสร้างสิทธิ์ใน QMS อัตโนมัติที่สร้างขึ้นอย่างถูกต้อง มีไว้ควบคุมว่าคนคนไหนทริกเกอร์จุดไหนได้ ไม่ใช่สร้างช่องทางให้ระบบทำหน้าที่แทนคนเลย
คำถามที่พบบ่อย
ผู้ดูแลระบบ override จุดอนุมัติใน QMS อัตโนมัติได้หรือไม่
โดยทั่วไปผู้ดูแลระบบจัดการว่าใครถือบทบาทไหนได้ แต่ไม่ควรอนุมัติเอกสารแทนระบบได้ หรืออนุมัติเนื้อหาโดยไม่ผ่านจุดเดียวกับที่ผู้ทบทวนหรือผู้อนุมัติที่กำหนดไว้ใช้ ถ้าระบบมี "admin override" ที่ข้ามจุดตัดสินใจได้ นั่นคือข้อบกพร่องในการออกแบบ ไม่ใช่ฟีเจอร์
ใครควรอ่านบันทึกกิจกรรมได้
กว้างกว่าคนที่เขียนได้ โดยทั่วไปคือ QMR ผู้ตรวจประเมินภายใน และการควบคุมเอกสาร แม้ว่าจะมีคนกลุ่มเล็กกว่านั้นเท่านั้นที่ทริกเกอร์เหตุการณ์ที่ถูกบันทึกได้ สิทธิ์อ่าน audit trail คือการกำกับดูแล สิทธิ์เขียนคือการดำเนินการ
cloud QMS หมายความว่าข้อมูลของเราอยู่บนเซิร์ฟเวอร์ของคนอื่นหรือไม่
ไม่จำเป็น การติดตั้งที่ลูกค้าเป็นเจ้าของ รันอยู่ในโครงสร้างพื้นฐานที่คุณดำเนินการอยู่แล้ว Google Workspace และ automation instance ของคุณเอง คำว่า "cloud" อธิบายว่าซอฟต์แวร์รันที่ไหน ไม่ใช่ใครควบคุมข้อมูล
idempotency เกี่ยวข้องกับความปลอดภัยอย่างไร ไม่ใช่แค่คุณภาพข้อมูล
มันปิดช่องทางการปั่นแต่งข้อมูล ถ้าไม่มี การส่งหรือเล่นซ้ำเหตุการณ์อนุมัติอาจสร้างรายการซ้ำในทะเบียนได้ ไม่ว่าจะโดยบังเอิญหรือมีคนพยายามทดสอบขอบเขตของระบบ workflow ที่ถูกออกแบบด้วย idempotency key ทำให้ความพยายามเล่นซ้ำไม่มีผลอะไรเลย
สิทธิ์โฟลเดอร์กับสิทธิ์ workflow ในระบบแบบนี้ต่างกันอย่างไร
ในระบบที่สร้างมาดี ไม่ควรมีความต่างเลย การย้ายเอกสารระหว่างโฟลเดอร์สถานะวงจรชีวิตคือตัวทริกเกอร์ workflow ดังนั้นสิทธิ์เขียนโฟลเดอร์และสิทธิ์ทริกเกอร์ workflow ต้องเป็นสิทธิ์เดียวกัน ตรวจสอบด้วยวิธีเดียวกัน
หากอยากเห็นว่าการควบคุมสิทธิ์ที่แมปกับจุดตัดสินใจ จะแมปกับรายชื่อผู้ทบทวนและผู้อนุมัติจริงของคุณอย่างไร นี่คือบทสนทนาที่ควรมี โดยมีบทบาทจริงของคุณอยู่ตรงหน้า นัดปรึกษาฟรีกับ 1% EVO นำรายชื่อผู้ลงนามปัจจุบันของคุณมาด้วย เราจะเปิดระบบจริงให้ดูสด และไล่เรียงไปพร้อมกัน