ผู้พิทักษ์ของการปฏิบัติตามกฎหมาย: วิเคราะห์การระบุตัวตนภายใต้ SOC 2 และ GDPR
เรียนรู้ว่า SOC 2 และ GDPR กำหนดให้มีการยืนยันตัวตน MFA การควบคุมการเข้าถึง และบันทึกการตรวจสอบ โดยมีการอ้างอิงโดยตรงไปยังมาตรฐานทางการอย่างเป็นทางการ
เรียนรู้ว่า SOC 2 และ GDPR กำหนดให้มีการยืนยันตัวตน MFA การควบคุมการเข้าถึง และบันทึกการตรวจสอบ โดยมีการอ้างอิงโดยตรงไปยังมาตรฐานทางการอย่างเป็นทางการ
ในภูมิทัศน์ข้อบังคับสมัยใหม่ การจัดการตัวตนและการเข้าถึง (IAM) ไม่ใช่แค่ภารกิจเชิงปฏิบัติการด้าน IT อีกต่อไป แต่เป็นข้อกำหนดทางกฎหมายและการปฏิบัติตามกฎระเบียบ กรอบงานที่สำคัญที่สุดสองกรอบที่ควบคุมด้านนี้คือ SOC 2 (System and Organization Controls 2) และ GDPR (General Data Protection Regulation)
แม้ว่า SOC 2 จะเน้นเรื่องความน่าเชื่อถือในการให้บริการ และ GDPR เน้นสิทธิความเป็นส่วนตัวของแต่ละบุคคล แต่ทั้งสองต่างบรรจบกันที่ข้อเท็จจริงประการเดียว: คุณไม่สามารถรักษาความปลอดภัยของข้อมูลได้หากไม่สามารถระบุตัวตนของผู้ที่เข้าถึงข้อมูลนั้นได้
ต่อไปนี้คือการวิเคราะห์อย่างเข้มงวดในข้อกำหนดและเกณฑ์เฉพาะทั้งสองกรอบงาน ซึ่งกำหนดให้ต้องมีการพิสูจน์ตัวตนที่รัดกุม รวมถึงลิงก์โดยตรงไปยังมาตรฐานทางการ
SOC 2 ตรวจสอบโดยอ้างอิงจาก 2017 Trust Services Criteria (TSC) ของ AICPA สำหรับการพิสูจน์ตัวตน จะอ้างอิง Common Criteria (CC) 6.0 Series (Logical and Physical Access Controls) เป็นหลักฐานสูงสุด
เกณฑ์:
"องค์กรต้องใช้ซอฟต์แวร์โครงสร้างพื้นฐานและสถาปัตยกรรมควบคุมการเข้าถึงเชิงตรรกะกับสินทรัพย์ข้อมูลที่ได้รับการปกป้องเพื่อป้องกันเหตุการณ์ด้านความปลอดภัยให้ผ่านเป้าหมายขององค์กร"
การวิเคราะห์:
นี่คือข้อกำหนดกว้างสำหรับระบบ IAM เพื่อให้ผ่าน CC6.1 องค์กรต้องพิสูจน์ว่ามีระบบรวมศูนย์ (เช่น Identity Provider - IdP) เพื่อจัดการตัวตน การใช้บัญชีร่วมกันหรือไม่เป็นระบบมักจะไม่ผ่านข้อกำหนดนี้เพราะทำให้ไม่สามารถตรวจสอบ "logical access security" ได้
เกณฑ์:
"ก่อนมอบสิทธิ์เข้าระบบและให้การเข้าถึง องค์กรจะต้องลงทะเบียนและอนุมัติผู้ใช้ภายในและภายนอกใหม่ที่ดูแลการเข้าถึงโดยองค์กรเอง"
การวิเคราะห์:
ต้องมีขั้นตอน Joiner/Mover/Leaver (JML) ที่เข้มงวด
เกณฑ์:
"องค์กรอนุญาต แก้ไข หรือถอนการเข้าถึงข้อมูล ซอฟต์แวร์ ฟังก์ชัน และสินทรัพย์ข้อมูลอื่น ๆ ที่ได้รับความคุ้มครองโดยพิจารณาตามบทบาท ความรับผิดชอบ หรือการออกแบบของระบบ..."
การวิเคราะห์:
แม้ข้อความจะระบุถึง "บทบาท" (RBAC) แต่ "Points of Focus" ของ AICPA สำหรับ CC6.3 เน้นว่าต้องมี Multi-Factor Authentication (MFA)
เกณฑ์:
"องค์กรจำกัดการเข้าถึงสถานที่และสินทรัพย์ข้อมูลที่ได้รับการปกป้องให้เฉพาะบุคคลที่ได้รับอนุญาตเท่านั้น ตามเป้าหมายขององค์กร"
การวิเคราะห์:
ประเด็นนี้เมื่อปรับใช้กับการเข้าถึงแบบ logical คือ User Access Reviews (UAR) คุณไม่สามารถพิสูจน์ตัวตนผู้ใช้เพียงครั้งเดียว แต่ต้องตรวจสอบซ้ำเป็นระยะ (ส่วนมากรายไตรมาส) ว่าตัวตนนั้นยังถูกต้องและมีสิทธิที่เหมาะสม
ต่างจาก SOC 2, GDPR เป็นกฎหมายของสหภาพยุโรป มันไม่ได้ระบุเทคโนโลยีเฉพาะ (เช่น "ใช้งาน OTP app") แต่กำหนดผลลัพธ์ที่ทำให้จำเป็นต้องมีการยืนยันตนที่เข้มแข็ง
ข้อบัญญัติ: ข้อ 5(1)(f)
"ข้อมูลส่วนบุคคลต้องถูกประมวลผลในลักษณะที่รับประกันความปลอดภัยของข้อมูลอย่างเหมาะสม รวมถึงการป้องกันการประมวลผลที่ไม่ได้รับอนุญาตหรือไม่ชอบด้วยกฎหมาย..."
การวิเคราะห์:
"การประมวลผลที่ไม่ได้รับอนุญาต" คือประเด็นสำคัญ หากผู้ร้ายเดารหัสผ่านที่อ่อนแอและเข้าถึงข้อมูลได้ องค์กรถือว่าล้มเหลวต่อข้อ 5
ข้อบัญญัติ: ข้อ 32(1)
"โดยคำนึงถึงเทคโนโลยีที่เป็นสากล ต้นทุนในการดำเนินการ และลักษณะ ขอบเขต บริบท วัตถุประสงค์ของการประมวลผล... ผู้ควบคุมและผู้ประมวลผลต้องดำเนินมาตรการทางเทคนิคและองค์กรที่เหมาะสม..."
การวิเคราะห์:
นี่คือ "State of the Art" clause
ข้อบัญญัติ: ข้อ 25(2)
"ผู้ควบคุมต้องดำเนินมาตรการทางเทคนิคและองค์กรที่เหมาะสมเพื่อให้แน่ใจว่าโดยค่าเริ่มต้นข้อมูลส่วนบุคคลที่ถูกประมวลผลนั้นเฉพาะเท่าที่จำเป็นเท่านั้น"
การวิเคราะห์:
ข้อนี้กำหนดหลัก least privilege
ตารางต่อไปนี้สรุปว่าวิธีปฏิบัติตามทั้งสองมาตรฐานพร้อมกันต้องทำอย่างไร:
| คุณสมบัติ | ข้อกำหนด SOC 2 (เกณฑ์) | ข้อกำหนด GDPR (ข้อบัญญัติ) | มาตรฐานการดำเนินการแบบเข้มงวด |
|---|---|---|---|
| ความปลอดภัยของการเข้าสู่ระบบ | CC6.3 (Access Control) | Art. 32 (Security of Processing) | MFA เป็นสิ่งจำเป็น สำหรับพนักงานทุกคนที่เข้าถึงข้อมูลลูกค้าหรือ environment production |
| ขอบเขตการเข้าถึง | CC6.2 (Authorization) | Art. 25 (Privacy by Design) | RBAC (Role-Based Access Control). Default deny; อนุญาตเฉพาะที่อนุญาตตามหน้าที่งาน |
| การออกจากระบบ | CC6.2 (Removal) | Art. 5 (Integrity) | Automated de-provisioning. การเข้าถึงต้องถูกยกเลิกทันทีเมื่อสิ้นสุดสัญญา |
| การตรวจสอบ | CC6.1 (Security Architecture) | Art. 30 (Records of Processing) | Centralized Logging. ใครบันทึกเข้าสู่ระบบ เมื่อไร จากที่ไหน (IP address)? |
เพื่อให้ผ่านการวิเคราะห์อย่างเข้มงวดของทั้งสองมาตรฐาน:
การปฏิบัติตาม SOC 2 และ GDPR ต้องก้าวข้ามการจัดการรหัสผ่านแบบพื้นฐาน องค์กรต้องสร้างระบบ Identity Provider แบบรวมศูนย์ที่บังคับใช้ Multi-Factor Authentication (MFA), RBAC (Role-Based Access Control) อย่างเข้มงวด และบันทึกการจัดการบัญชีโดยอัตโนมัติ หากไม่ทำจะส่งผลให้ SOC 2 audit ไม่ผ่าน (พบข้อยกเว้นใน CC6.x) และมีโอกาสถูกปรับจาก GDPR ข้อหาไม่ดำเนิน "มาตรการทางเทคนิคที่เหมาะสม" ตาม Article 32.