จัดลำดับ C-I-A ให้ตรงกับธุรกิจ จุดเริ่มต้นของการออกแบบการควบคุมภายในด้านไอที

C-I-A คืออะไร และทำไมการจัดลำดับสำคัญกว่าการท่องนิยาม

C-I-A คือเป้าหมายสามข้อของการรักษาความมั่นคงปลอดภัยของสารสนเทศ ซึ่งเป็นนิยามที่ใช้ร่วมกันทั้งใน ISO/IEC 27001 และกรอบงานด้านความมั่นคงปลอดภัยอื่น ๆ ประกอบด้วย

1. Confidentiality (การรักษาความลับ) ข้อมูลถูกเข้าถึงได้เฉพาะผู้ที่ได้รับอนุญาต ความเสียหายคือข้อมูลรั่วไหลไปถึงคนที่ไม่ควรเห็น
2. Integrity (ความถูกต้องครบถ้วน) ข้อมูลถูกต้อง ครบถ้วน และไม่ถูกแก้ไขโดยไม่ได้รับอนุญาต ความเสียหายคือตัวเลขผิดโดยที่ไม่มีใครรู้
3. Availability (ความพร้อมใช้งาน) ระบบและข้อมูลพร้อมให้ใช้เมื่อจำเป็น ความเสียหายคือระบบล่มแล้วทำงานต่อไม่ได้

จุดที่หลายองค์กรพลาดไม่ใช่การจำนิยามไม่ได้ แต่คือ การปฏิบัติกับทั้งสามข้อเท่ากันหมด เพราะในความเป็นจริงไม่มีองค์กรใดมีทรัพยากรพอจะควบคุมทุกด้านให้แน่นเท่ากัน เมื่อถึงเวลาต้องเลือกว่าจะใช้งบไปกับการเข้ารหัสข้อมูล การสอบยันความถูกต้องของรายการ หรือระบบสำรองและกู้คืน คำถามที่ต้องตอบให้ได้ก่อนคือ ถ้าเสียข้อใดไปหนึ่งข้อ ธุรกิจนี้เจ็บที่สุดจากข้อไหน

หลักการจัดลำดับนี้ไม่ใช่เรื่องใหม่ในเชิงกรอบงาน ตัวอย่างคือ FIPS 199 ของสถาบันมาตรฐานและเทคโนโลยีแห่งชาติสหรัฐอเมริกา (NIST) ซึ่งเป็นมาตรฐานจัดประเภทความมั่นคงปลอดภัยสำหรับสารสนเทศและระบบสารสนเทศของรัฐบาลกลางสหรัฐฯ มาตรฐานนี้กำหนดให้ประเมินผลกระทบแยกทีละด้าน ระดับ C, I และ A ของระบบเดียวกันจึงต่างกันได้ เท่ากับยอมรับโดยปริยายว่าน้ำหนักของสามข้อนี้ไม่จำเป็นต้องเท่ากันทุกบริบท

ลำดับ C-I-A เปลี่ยนไปตามประเภทธุรกิจอย่างไร

วิธีที่ใช้ได้ผลคือถามว่าความเสียหายรูปแบบใดเกิดเร็วที่สุดและกู้คืนยากที่สุดสำหรับธุรกิจนั้น ตัวอย่างที่พบบ่อย

1. เว็บขายของออนไลน์ ลำดับมักเป็น A > I > C เพราะระบบล่มหมายถึงขายไม่ได้ทันทีและวัดเป็นตัวเงินได้ในหน่วยนาที ส่วนข้อมูลที่เก็บส่วนใหญ่เป็นข้อมูลคำสั่งซื้อที่อ่อนไหวน้อยกว่าข้อมูลประเภทอื่น
2. ธนาคารและระบบบัญชี ลำดับมักเป็น I > C > A เพราะตัวเลขที่ผิดเพียงรายการเดียวสร้างความเสียหายหนักและตามแก้ยาก ระบบที่ล่มไปชั่วคราวยังพอมีกระบวนการสำรองรองรับ แต่ยอดคงเหลือที่เพี้ยนโดยไม่มีใครจับได้จะไหลต่อไปถึงงบการเงิน
3. ข้อมูลสุขภาพหรือข้อมูลด้านความมั่นคง ลำดับมักเป็น C > I > A เพราะข้อมูลที่รั่วออกไปแล้วเรียกคืนไม่ได้ ความเสียหายเป็นแบบถาวรและกระทบบุคคลโดยตรง
4. ระบบควบคุมในโรงงานหรือระบบที่เกี่ยวกับชีวิตคน ต้องพิจารณาความปลอดภัยเป็นเงื่อนไขนำ แล้วจึงเรียง A > I > C ตามมา ซึ่งเป็นการกลับลำดับจากระบบสารสนเทศทั่วไป

ข้อสำคัญคือลำดับเหล่านี้เป็นผลของการวิเคราะห์ ไม่ใช่กฎตายตัวที่ท่องจำแล้วใช้ได้ทุกกรณี องค์กรเดียวกันอาจมีลำดับต่างกันคนละระบบ เช่น บริษัทที่ขายของออนไลน์ย่อมให้ความพร้อมใช้งานมาก่อนในระบบหน้าร้าน แต่ในระบบบัญชีแยกประเภทของบริษัทเดียวกันนั้น ความถูกต้องครบถ้วนต้องมาก่อนเสมอ การตอบว่า บริษัทเราเรียง A มาก่อน แบบเหมารวมทั้งองค์กรจึงเป็นสัญญาณว่ายังไม่ได้วิเคราะห์จริง

ความปลอดภัยของชีวิต ปัจจัยหลักที่ห้ามมองข้าม

เราควรแยกให้ชัด

Safety หรือความปลอดภัยของชีวิตและร่างกาย ไม่ได้เป็นหนึ่งในสามองค์ประกอบของ C-I-A ตั้งแต่ต้น เพราะ C-I-A เป็นกรอบสำหรับสารสนเทศ ไม่ใช่สำหรับกระบวนการทางกายภาพ แต่ในระบบเทคโนโลยีเชิงปฏิบัติการ เช่น ระบบควบคุมในโรงงาน ระบบสาธารณูปโภค หรือเครื่องมือแพทย์ ความปลอดภัยเป็นวัตถุประสงค์ที่อยู่เหนือทั้งสามข้อ เพราะความเสียหายไม่ใช่ข้อมูลแต่เป็นชีวิตคน

ในทางปฏิบัติจึงมักอธิบายว่า ระบบสารสนเทศทั่วไปเรียง C-I-A ส่วนระบบเทคโนโลยีเชิงปฏิบัติการเรียงกลับด้านเป็น A-I-C โดยมีความปลอดภัยเป็นเงื่อนไขครอบอีกชั้นหนึ่ง

แปลงลำดับที่ได้ไปเป็นการควบคุมภายในด้านไอที

เมื่อจัดลำดับได้แล้ว ขั้นต่อไปคือแปลงเป็นการควบคุมที่มีหลักฐานให้ตรวจสอบได้ บทความนี้แบ่งการควบคุมทั่วไปด้านเทคโนโลยีสารสนเทศ (ITGC) เป็นสี่กลุ่มเช่นเดียวกับบทความ ITGC ของเรา ส่วนมาตรฐานการสอบบัญชี รหัส 315 (ปรับปรุง 2564) ภาคผนวก 6 จัดตัวอย่างเป็นสามกระบวนการ โดยรวมการพัฒนาหรือซื้อระบบไว้กับการจัดการการเปลี่ยนแปลง ทั้งสี่กลุ่มให้น้ำหนักกับเป้าหมายแต่ละข้อไม่เท่ากัน

1. การเข้าถึงโปรแกรมและข้อมูล (Access to Programs and Data) รองรับทั้ง C และ I ในงานบัญชีจะเน้น I เพราะการเข้าถึงโดยไม่ได้รับอนุญาตอาจทำให้มีการบันทึกรายการที่ไม่มีอยู่จริงหรือแก้ข้อมูลโดยไม่เหมาะสม กลุ่มนี้ครอบคลุมการให้สิทธิตามหน้าที่ การทบทวนสิทธิตามรอบ การถอนสิทธิเมื่อพ้นสภาพ และการควบคุมบัญชีผู้ใช้สิทธิสูง
2. การบริหารการเปลี่ยนแปลงโปรแกรม (Program Change) รองรับ I เป็นหลัก ครอบคลุมการอนุมัติก่อนเปลี่ยน การทดสอบ การแยกสภาพแวดล้อมพัฒนาออกจากใช้งานจริง และการแยกหน้าที่ระหว่างผู้พัฒนากับผู้นำขึ้นระบบ
3. การพัฒนาและการนำระบบใหม่มาใช้ (Program Development) รองรับ I เป็นหลัก ครอบคลุมการทดสอบก่อนใช้งานจริง การอนุมัติรับมอบระบบ และการกระทบยอดข้อมูลที่ย้ายจากระบบเดิม
4. การปฏิบัติงานคอมพิวเตอร์ (Computer Operations) รองรับ A เป็นหลัก ครอบคลุมการสำรองข้อมูล การทดสอบกู้คืน การเฝ้าระวังงานประมวลผล และแผนความต่อเนื่องทางธุรกิจ

ส่วนการควบคุมระดับรายการในระบบงาน เช่น การตรวจสอบความถูกต้องของข้อมูลนำเข้า การสอบยันยอดรวม และการควบคุมลำดับเลขที่เอกสาร เรียกว่าการควบคุมระดับแอปพลิเคชัน (Application Controls หรือ ITAC) ซึ่งเป็นคนละชั้นกับ ITGC ไม่ใช่กลุ่มย่อยของ ITGC การควบคุมกลุ่มนี้รองรับ I โดยตรงที่สุด แต่การจะเชื่อได้ว่าทำงานต่อเนื่องตลอดงวดอาจขึ้นอยู่กับ ITGC ที่รองรับระบบนั้น เพราะหากใครก็แก้โปรแกรมหรือแก้ข้อมูลในฐานข้อมูลได้โดยไม่ผ่านการอนุมัติ การควบคุมที่ฝังอยู่ในหน้าจอก็ไม่มีความหมาย

ความเชื่อมโยงนี้ทำให้การจัดลำดับมีผลต่อการตัดสินใจจริง องค์กรที่วางลำดับว่า I มาก่อน ควรลงแรงกับการแยกหน้าที่ การควบคุมการเปลี่ยนแปลงโปรแกรม และการควบคุมระดับรายการให้แน่นก่อน ส่วนองค์กรที่วางลำดับว่า A มาก่อน ควรลงแรงกับการทดสอบกู้คืนและแผนความต่อเนื่องให้เห็นผลก่อน แทนที่จะไล่ทำทุกหัวข้อในเช็กลิสต์ให้ครบแบบผิวเผินเท่ากันหมด

ในเชิงกรอบการควบคุมภายใน แนวคิดนี้สอดคล้องกับ COSO Internal Control: Integrated Framework หลักการที่ 11 ซึ่งว่าด้วยการคัดเลือกและพัฒนากิจกรรมการควบคุมทั่วไปด้านเทคโนโลยีเพื่อสนับสนุนการบรรลุวัตถุประสงค์ โดยคำสำคัญคือ เพื่อสนับสนุนวัตถุประสงค์ ไม่ใช่เพื่อให้มีครบทุกหัวข้อ

ผู้ตรวจสอบภายในใช้ลำดับนี้ทำอะไรได้บ้าง

สำหรับงานตรวจสอบภายใน ลำดับ C-I-A ใช้ประโยชน์ได้อย่างน้อยสามจุด

จุดแรก คือ การวางแผนตรวจสอบ เมื่อจัดทำ audit universe แล้วต้องจัดลำดับความเสี่ยง การระบุว่าแต่ละระบบให้น้ำหนัก C, I หรือ A มากที่สุด ช่วยอธิบายต่อคณะกรรมการตรวจสอบได้ว่าทำไมจึงเลือกตรวจระบบหนึ่งก่อนอีกระบบหนึ่ง ซึ่งหนักแน่นกว่าการบอกว่าระบบนี้ใหญ่กว่า

จุดที่สอง คือ การกำหนดขอบเขตและวิธีการตรวจ ระบบที่ให้น้ำหนัก I สูงควรใช้เวลาไปกับการทดสอบการแยกหน้าที่และการทดสอบความถูกต้องของรายการ ส่วนระบบที่ให้น้ำหนัก A สูงควรตรวจหลักฐานการทดสอบกู้คืนจริง ไม่ใช่แค่ดูว่ามีนโยบายสำรองข้อมูลเป็นลายลักษณ์อักษร

จุดที่สาม คือ การจัดระดับความเสี่ยงของประเด็นที่ตรวจพบ ข้อบกพร่องเรื่องเดียวกันอาจมีระดับต่างกันคนละระบบ เช่น การไม่ทบทวนสิทธิผู้ใช้ตามรอบ ถือเป็นประเด็นระดับสูงในระบบที่เก็บข้อมูลส่วนบุคคลอ่อนไหว แต่อาจเป็นระดับปานกลางในระบบที่เก็บข้อมูลทั่วไป การอ้างลำดับ C-I-A ของระบบนั้นทำให้การให้ระดับความเสี่ยงมีเหตุผลรองรับ ไม่ใช่ความรู้สึกของผู้ตรวจ

ข้อควรระวัง จากประสบการณ์ที่พบเจอ

นโยบายความมั่นคงปลอดภัยสารสนเทศของหลายองค์กรระบุ C-I-A ไว้ครบสามข้อ แต่ไม่เคยระบุลำดับ ผลคือ เมื่อถึงเวลาตัดงบประมาณ ฝ่ายไอทีเลือกตัดตามความสะดวก ไม่ใช่ตามความเสี่ยง ข้อเสนอแนะที่ใช้ได้ผลคือให้ระบุลำดับไว้ในเอกสารจัดประเภทระบบงานรายระบบ ไม่ใช่เขียนรวมไว้ที่นโยบายระดับองค์กรเพียงจุดเดียว

องค์กรจำนวนมากให้น้ำหนัก C มากเกินจริงเพราะเป็นด้านที่เป็นข่าว ขณะที่ความเสียหายที่พบจริงในงานตรวจสอบมักมาจาก I มากกว่า เช่น รายการซ้ำจากการนำเข้าไฟล์สองรอบ ยอดยกมาไม่ตรงหลังเปลี่ยนระบบ หรือสูตรในไฟล์คำนวณที่ถูกแก้โดยไม่มีใครอนุมัติ ปัญหากลุ่มนี้ไม่เป็นข่าวแต่ไปโผล่ที่งบการเงินโดยตรง

เมื่อองค์กรย้ายระบบขึ้นคลาวด์ คำตอบเรื่องความพร้อมใช้งานมักเปลี่ยนไปอยู่ที่ผู้ให้บริการ แต่ความรับผิดชอบตามแบบจำลองความรับผิดชอบร่วมยังอยู่ที่องค์กรในส่วนของการตั้งค่า การให้สิทธิ และการสำรองข้อมูลระดับแอปพลิเคชัน ควรตรวจว่าองค์กรเข้าใจเส้นแบ่งนี้จริง และอย่าถือว่าการมีรายงานมาตรฐานจากผู้ให้บริการเท่ากับตรวจสอบแล้ว เพราะต้องอ่านว่าครอบคลุมช่วงเวลาใด ขอบเขตใด และมีข้อยกเว้นอะไรบ้าง

สำหรับบริษัทที่เตรียม IPO การจัดลำดับ C-I-A รายระบบเป็นเอกสารที่ช่วยได้มากตอนตอบแบบประเมินความเพียงพอของระบบควบคุมภายใน เพราะทำให้อธิบายได้ว่าการควบคุมที่มีอยู่ออกแบบมาเพื่อรองรับความเสี่ยงใด แทนที่จะตอบเพียงว่ามีหรือไม่มี

ระวังการนำลำดับจากตัวอย่างในตำราหรือข้อสอบมาใช้กับองค์กรจริงโดยไม่ปรับ ตัวอย่างเหล่านั้นออกแบบมาเพื่อให้เห็นหลักคิดในกรณีที่ชัดเจนที่สุด แต่ธุรกิจจริงมักคาบเกี่ยวหลายประเภท เช่น ผู้ให้บริการแพลตฟอร์มสุขภาพออนไลน์ที่ต้องแบกทั้ง C จากข้อมูลผู้ป่วยและ A จากการที่ระบบต้องพร้อมใช้ตลอดเวลา กรณีแบบนี้ต้องจัดลำดับแยกรายระบบย่อย ไม่ใช่รายบริษัท

บทความนี้เรียบเรียงจากแนวคิดความมั่นคงปลอดภัยของสารสนเทศตาม ISO/IEC 27001 แนวทางจัดประเภทระบบสารสนเทศของ NIST และกรอบ COSO ร่วมกับมาตรฐานที่เกี่ยวข้อง ณ ปี 2569 ลำดับ C-I-A ตามประเภทธุรกิจในบทความเป็นตัวอย่างประกอบ ไม่ใช่ข้อกำหนดของมาตรฐานใด องค์กรควรวิเคราะห์ตามลักษณะธุรกิจ ระบบงาน และข้อกำหนดของหน่วยงานกำกับดูแลที่เกี่ยวข้องก่อนนำไปใช้