ข้อมูลส่วนบุคคลในภาพหน้าจอในฐานความรู้ภายใน
ฐานความรู้ภายใน — Confluence, Notion, SharePoint, GitBook — มีปัญหาข้อมูลส่วนบุคคลเฉพาะประเภทที่เครื่องมือการปฏิบัติตามกฎระเบียบทั่วไปพลาด: ข้อมูลส่วนบุคคลของลูกค้าที่ฝังอยู่ในภาพหน้าจอที่ใช้สำหรับเอกสารกระบวนการ
รูปแบบนี้เล่นซ้ำในทีมสนับสนุนและปฏิบัติการหลายพันทีม
เจ้าหน้าที่ฝ่ายสนับสนุนพบการตั้งค่าบัญชีที่ผิดปกติ ถ่ายภาพหน้าจอของหน้าบัญชีลูกค้าเพื่อบันทึกปัญหา ภาพหน้าจอแสดงชื่อลูกค้าในส่วนหัว UI อีเมลในการตั้งค่าบัญชี และรายละเอียดแผน
บทความออนไลน์ในฐานความรู้ภายใน เจ้าหน้าที่ฝ่ายสนับสนุน 150 คนสามารถดูได้ ผู้รับเหมาภายนอก 12 คนในฝ่ายช่วยเหลือสามารถดูได้เช่นกัน บทความมีประโยชน์ แสดงวิธีจัดการกรณีขอบนั้น
สามปีต่อมา ฐานความรู้มีบทความดังกล่าว 847 ฉบับ แต่ละฉบับมีภาพหน้าจอของบัญชีลูกค้า ลูกค้าที่แสดงไม่ได้ยินยอมต่อการใช้งานรองนี้ ส่วนใหญ่ไม่รู้ว่าข้อมูลของตนถูกจัดเก็บที่นั่น
นี่ไม่ใช่ปัญหาเล็กน้อย มันเติบโตขึ้นทุกบทความใหม่
การเปิดเผย GDPR: ทำไมสิ่งนี้จึงสำคัญ
การวิเคราะห์ GDPR สำหรับภาพหน้าจอฐานความรู้ตรงไปตรงมา
การลดข้อมูล (Article 5(1)(c)): ข้อมูลส่วนบุคคลต้อง "เพียงพอ เกี่ยวข้อง และจำกัดเฉพาะสิ่งที่จำเป็น" บทความฐานความรู้เกี่ยวกับการตั้งค่าบัญชีไม่จำเป็นต้องมีชื่อและอีเมลจริงของลูกค้า ภาพหน้าจอที่เบลอก็ใช้งานได้เช่นเดียวกัน
การจำกัดวัตถุประสงค์ (Article 5(1)(b)): ข้อมูลที่รวบรวมเพื่อวัตถุประสงค์หนึ่ง — บริการลูกค้า — ไม่สามารถนำมาใช้ใหม่เพื่อวัตถุประสงค์อื่น — เอกสารกระบวนการภายใน — โดยไม่มีฐานทางกฎหมาย บันทึกบัญชีถูกรวบรวมเพื่อการให้บริการ ไม่ใช่สำหรับเอกสารภายใน
การควบคุมการเข้าถึง (Article 5(1)(f) และ Article 32): มาตรการทางเทคนิคที่เหมาะสมต้องปกป้องข้อมูลส่วนบุคคล ภาพหน้าจอบัญชีลูกค้าในเครื่องมือที่เปิดให้เจ้าหน้าที่ 150 คนและผู้รับเหมา — รวมถึงผู้ที่ไม่มีสิทธิ์เข้าถึงระบบบัญชีพื้นฐาน — สร้างการเข้าถึงที่กว้างเกินไป
สิทธิ์ในการลบข้อมูล (Article 17): เจ้าของข้อมูลที่ขอลบข้อมูลมีสิทธิ์ให้บันทึกของตนถูกลบ "โดยไม่ล่าช้าเกินควร" หากข้อมูลของพวกเขาปรากฏใน 23 บทความฐานความรู้เป็นภาพหน้าจอที่ฝังไว้ คำขอต้องค้นหาและอัปเดตบทความทั้ง 23 ฉบับ ซึ่งยากโดยไม่มีระบบ
การหลีกเลี่ยงการควบคุมการเข้าถึง
ปัญหาการปฏิบัติตามกฎระเบียบที่ร้ายแรงที่สุดกับภาพหน้าจอ Confluence คือการหลีกเลี่ยงการควบคุมการเข้าถึงที่สร้างขึ้น
ทีมสนับสนุนใช้การควบคุมการเข้าถึงตามบทบาท (RBAC) เพื่อจำกัดว่าใครสามารถดูระบบบัญชีลูกค้าได้ เจ้าหน้าที่ Tier 1 เห็นรายละเอียดบัญชีพื้นฐาน เจ้าหน้าที่ Tier 2 เห็นบันทึกการเรียกเก็บเงินและเทคนิค ผู้จัดการเห็นโปรไฟล์บัญชีเต็ม
เมื่อเจ้าหน้าที่ Tier 2 สร้างบทความฐานความรู้พร้อมภาพหน้าจอของบัญชีลูกค้าเต็ม ภาพหน้าจอนั้นจะมองเห็นได้สำหรับผู้ใช้เครื่องมือทุกคน เจ้าหน้าที่ Tier 1 ที่ไม่ควรเห็นบันทึกการเรียกเก็บเงินตอนนี้สามารถดูได้ ผู้รับเหมาที่ไม่มีสิทธิ์เข้าถึงระบบสามารถดูได้
ภาพหน้าจอหลีกเลี่ยงการควบคุม RBAC บนระบบบัญชีลูกค้า ข้อมูลส่วนบุคคลที่ RBAC สร้างขึ้นเพื่อปกป้องตอนนี้เปิดเผยต่อทุกคนที่มีสิทธิ์เข้าถึงฐานความรู้
นี่ไม่ใช่ความเสี่ยงเชิงทฤษฎี แต่เป็นผลลัพธ์ปกติของขั้นตอนการทำงานเอกสาร
ขั้นตอนการแก้ไขในทางปฏิบัติ
สำหรับทีมที่พบปัญหานี้ในระหว่างการตรวจสอบ GDPR:
การแก้ไขย้อนหลัง:
- ระบุหน้าฐานความรู้ทั้งหมดที่มีไฟล์แนบรูปภาพ
- รันการตรวจหาข้อมูลส่วนบุคคลรูปภาพบนไฟล์แนบทุกรายการ
- ตรวจสอบรูปภาพที่ถูกระบุ: รายการที่มีความเชื่อมั่นสูงไปยังคิวตรวจสอบ
- สำหรับแต่ละรูปภาพที่ถูกระบุ: แทนที่ด้วยเวอร์ชันที่ผ่านการทำความสะอาดหรือจำกัดการเข้าถึงหน้า
- บันทึกการดำเนินการแก้ไขสำหรับบันทึก GDPR
การควบคุมเชิงรุก:
- ฝึกอบรมเจ้าหน้าที่ฝ่ายสนับสนุนทั้งหมดให้ทำความสะอาดภาพหน้าจอก่อนเผยแพร่ในฐานความรู้
- จัดให้มีเครื่องมือ: เครื่องมือใส่คำอธิบายภาพหน้าจอที่เบลอชื่อลูกค้าก่อนวาง
- เพิ่มขั้นตอนตรวจสอบ: ผู้ตรวจสอบที่กำหนดตรวจบทความก่อนเผยแพร่ มองหาข้อมูลส่วนบุคคลของลูกค้าในรูปภาพโดยเฉพาะ
- รันการสแกนรูปภาพแบตช์รายไตรมาสบนไฟล์แนบ Confluence ทั้งหมด
การควบคุมขั้นต่ำที่ทำได้: รายการตรวจสอบการเผยแพร่: "ลบหรือเบลอชื่อลูกค้า อีเมล และ ID บัญชีทั้งหมดจากภาพหน้าจอก่อนเผยแพร่" เทคโนโลยีต่ำ ไม่อัตโนมัติ แต่สร้างการควบคุมที่บันทึกไว้
ดู ภาพรวมการปฏิบัติตาม GDPR ของเราสำหรับกรอบกฎหมายที่กว้างขึ้น
ทำไมปัญหาจึงเติบโตตามเวลา
โดยไม่มีการควบคุมอย่างเป็นระบบ การเปิดเผยข้อมูลส่วนบุคคลในฐานความรู้จะทบทวี
ปริมาณ: แต่ละบทความใหม่ที่มีภาพหน้าจอลูกค้าเพิ่มการเปิดเผยทั้งหมด เมื่อทีมสนับสนุนเติบโตและฐานความรู้ขยาย ข้อมูลส่วนบุคคลที่สะสมก็เติบโตด้วย
บทความที่ถูกลืม: บทความเกี่ยวกับกรณีขอบเก่าที่ไม่เกิดขึ้นอีกยังคงเข้าถึงได้ มีข้อมูลส่วนบุคคลจากลูกค้าที่ยื่นคำขอลบข้อมูลแล้ว ไม่มีใครตรวจสอบบทความที่อัปเดตล่าสุดในปี 2022
การแพร่กระจายข้ามทีม: ฐานความรู้มักข้ามหน้าที่ บทความสนับสนุนที่มีภาพหน้าจอลูกค้าอาจถูกแชร์กับทีมผลิตภัณฑ์ ทีมวิศวกรรม หรือผู้รับเหมาภายนอก
งานค้างการลบข้อมูล: เมื่อบันทึกลูกค้าสะสมในฐานความรู้มากขึ้น การตอบสนองคำขอลบข้อมูลก็ซับซ้อนมากขึ้น
ข้อมูลส่วนบุคคลในฐานความรู้ง่ายกว่าที่จะป้องกันมากกว่าแก้ไข การควบคุมที่นำมาใช้ตอนนี้หลีกเลี่ยงปัญหาการแก้ไขที่ทบทวีได้ ทุกบทความที่เผยแพร่โดยไม่มีภาพหน้าจอที่เบลอคือภารกิจการแก้ไขที่เลื่อนไปในอนาคต