เหตุการณ์ความปลอดภัยเดือนนี้ 2,493 รายการ
| ระดับ | จำนวน | สัดส่วน | การจัดการ | เวลาตอบสนองเฉลี่ย |
|---|---|---|---|---|
| ข้อมูลเพื่อการบันทึก | 1,842 | 73.9% | บันทึกอัตโนมัติ ไม่ต้องดำเนินการ | — |
| ต่ำ | 486 | 19.5% | จัดการอัตโนมัติตามกฎที่ตั้งไว้ | ทันที |
| ปานกลาง | 124 | 5.0% | แจ้งทีมความปลอดภัย | 24 นาที |
| สูง | 38 | 1.5% | แจ้งทันทีและต้องมีคนตอบรับ | 12 นาที |
| สูงสุด | 3 | 0.1% | ล็อกอัตโนมัติและแจ้งผู้บริหาร | 4 นาที |
| รวม | 2,493 | 100.0% |
1,842 + 486 + 124 + 38 + 3 = 2,493 ✓ · 73.9 + 19.5 + 5.0 + 1.5 + 0.1 = 100.0% ✓
เหตุการณ์ที่ยังไม่ปิด 3 รายการ · เรียงตามความรุนแรง
รายการแรกในต้นแบบหน้าศูนย์บัญชาการถูกจัดไว้เป็นเพียงคำเตือน และยังแสดงชื่อบัญชีเต็มบนหน้าจอ · การเข้าสู่ระบบผิดปกติของบัญชีที่มองเห็นข้อมูลของทุกองค์กรได้ คือเหตุการณ์ที่ต้องล็อกบัญชีทันทีโดยไม่รอคนมาอ่าน เพราะระหว่างที่รอ ผู้ที่ยึดบัญชีได้ก็ทำงานต่อไปเรื่อย ๆ · การล็อกอัตโนมัติมีต้นทุนคือผู้ดูแลตัวจริงอาจถูกล็อกออกด้วย ซึ่งเป็นราคาที่ยอมจ่ายได้เมื่อเทียบกับผลของการถูกยึดบัญชีสิทธิ์สูงสุด ระบบจึงมีขั้นตอนปลดล็อกที่ทำได้เร็วโดยผู้ดูแลอีกคน
การแยกข้อมูลระหว่างองค์กร จุดที่ระบบหลายผู้เช่าเสียหายที่สุด
| ชั้นการป้องกัน | วิธีที่ใช้ | สถานะ | ครั้งที่ล้มเหลว |
|---|---|---|---|
| ระดับฐานข้อมูล | แยกฐานข้อมูลต่อองค์กร | เปิดใช้งาน | 0 |
| ระดับแถวข้อมูล | นโยบายกรองที่ระดับฐานข้อมูล | เปิดใช้งาน | 0 |
| ระดับโปรแกรม | ตรวจขอบเขตทุกคำขอ | เปิดใช้งาน | 0 |
| ระดับกุญแจเข้ารหัส | กุญแจแยกต่อองค์กร | เปิดใช้งาน | 0 |
| การทดสอบอัตโนมัติ | ทดสอบการรั่วข้ามองค์กรทุกครั้งที่ปล่อยระบบ | เปิดใช้งาน | 0 |
การรั่วไหลข้ามองค์กรเป็นเหตุการณ์ที่กระทบลูกค้าทุกรายพร้อมกัน — ในระบบที่ให้บริการหลายองค์กร ถ้าลูกค้ารายหนึ่งเห็นข้อมูลของอีกรายได้ ผู้เสียหายไม่ใช่แค่สองราย แต่คือความเชื่อมั่นของลูกค้าทั้งหมดที่ฝากข้อมูลไว้ · การพึ่งเงื่อนไขกรองในโค้ดอย่างเดียวไม่เพียงพอ เพราะการลืมใส่เงื่อนไขในคำสั่งเดียวก็ทำให้ข้อมูลข้ามได้ ระบบจึงต้องมีการป้องกันหลายชั้นที่ทำงานอิสระจากกัน และต้องมีการทดสอบอัตโนมัติที่พยายามทำให้รั่วทุกครั้งที่ปล่อยระบบ · ผู้ให้บริการอยู่ในฐานะผู้ประมวลผลข้อมูลแทนองค์กรลูกค้า การรั่วไหลจึงมีทั้งความรับผิดตามสัญญาและตามกฎหมายคุ้มครองข้อมูลส่วนบุคคล
การเข้าถึงข้อมูลลูกค้าโดยผู้ให้บริการ ทุกครั้งต้องมีเหตุผลและวันหมดอายุ
| ผู้เข้าถึง | องค์กรที่เข้าดู | เหตุผล | วันหมดอายุสิทธิ์ | แจ้งลูกค้าแล้ว |
|---|---|---|---|---|
| SA-002 | ORG-014 | แก้ไขปัญหาที่ลูกค้าแจ้ง | 2 มิ.ย. 2569 | ✓ |
| SA-005 | ORG-031 | ตรวจสอบข้อมูลผิดพลาดตามที่ร้องขอ | 1 มิ.ย. 2569 | ✓ |
| SA-001 | ORG-008 | ย้ายข้อมูลตามสัญญาบริการ | 5 มิ.ย. 2569 | ✓ |
ต้นแบบไม่มีหน้าจอนี้เลย — ในระบบที่ให้บริการหลายองค์กร คำถามที่ลูกค้าองค์กรถามก่อนเซ็นสัญญาคือ “พนักงานของผู้ให้บริการเปิดดูข้อมูลของเราได้ไหม และเราจะรู้ได้อย่างไร” · ระบบนี้ตอบด้วยการบังคับให้ทุกการเข้าถึงต้องระบุเหตุผล มีวันหมดอายุสิทธิ์ และแจ้งองค์กรนั้นทราบ พร้อมให้ลูกค้าดูรายการย้อนหลังได้เอง · สิทธิ์ที่ไม่มีวันหมดอายุคือสิทธิ์ที่ไม่มีใครถอน ระบบจึงตั้งให้หมดอายุอัตโนมัติเสมอ ต้องขอใหม่ถ้ายังจำเป็น
ต้นแบบ — ข้อมูลตัวอย่าง · ข้อมูลจัดชั้น C5 — Super Admin เข้าถึงข้อมูลของทุกองค์กรได้ ทุกการกระทำถูกบันทึกและตรวจสอบย้อนหลังได้เสมอ · ในระบบที่ให้บริการหลายองค์กร การรั่วไหลข้ามองค์กรครั้งเดียวกระทบลูกค้าทุกรายพร้อมกัน จึงเป็นเหตุการณ์ที่ระบบนี้จัดเป็นระดับสูงสุดเสมอ ไม่ว่าจะเป็นข้อมูลจำนวนมากหรือน้อย · หน้านี้ยกระดับการเข้าสู่ระบบผิดปกติของบัญชีผู้ดูแลจากคำเตือนเป็นเหตุการณ์วิกฤตที่ล็อกบัญชีอัตโนมัติ ซึ่งต้นแบบหน้าศูนย์บัญชาการจัดไว้เป็นเพียงคำเตือน · ข้อมูลของแต่ละองค์กรต้องแยกขาดกันในระดับฐานข้อมูล การพึ่งเงื่อนไขกรองในโค้ดอย่างเดียวไม่เพียงพอ เพราะพลาดครั้งเดียวข้อมูลก็ข้ามได้