ช่องว่างระหว่างคำกล่าวอ้างและสถาปัตยกรรม
ผู้ให้บริการคลาวด์ทุกรายที่จัดการข้อมูลละเอียดอ่อนอ้างบางส่วนของคำกล่าวอ้างเดียวกัน: "เราเข้ารหัสข้อมูลของคุณ" คำกล่าวอ้างนั้นแทบจะถูกต้องเสมอ และแทบจะไม่เพียงพอเสมอ
การละเมิด LastPass ปี 2022 คือกรณีศึกษาที่ชัดเจนที่สุด LastPass เข้ารหัส vault รหัสผ่านของผู้ใช้ พวกเขาใช้การเข้ารหัส คำกล่าวอ้างถูกต้อง และยังคง ผู้ใช้ 25 ล้านคน มี vault ของตนถูกดึงข้อมูลออกไป และ 438 ล้านดอลลาร์ ถูกขโมยจากผู้ใช้ LastPass ในการปล้นสกุลเงินดิจิทัลต่อเนื่องจนถึงปี 2025 ตามการวิจัยของ Coinbase Institutional
สำนักงานคณะกรรมาธิการข้อมูลแห่งสหราชอาณาจักรปรับหน่วยงาน UK ของ LastPass 1.2 ล้านปอนด์ ในเดือนธันวาคม 2025 สำหรับ "ความล้มเหลวในการดำเนินมาตรการรักษาความปลอดภัยทางเทคนิคและองค์กรที่เหมาะสม" การเข้ารหัสมีอยู่ มาตรการรักษาความปลอดภัยไม่เป็นไปตามมาตรฐานที่กำหนด
สำหรับองค์กรที่ประเมินเครื่องมือความเป็นส่วนตัวบนคลาวด์ รวมถึงแพลตฟอร์ม anonymization PII บรรทัดฐาน LastPass เปลี่ยนคำถามการจัดซื้อ คำถามไม่ใช่ "พวกเขาเข้ารหัสข้อมูลของเรา?" แต่เป็น "พวกเขาสามารถถอดรหัสข้อมูลของเรา?"
สี่คำถาม Zero-Knowledge ที่สำคัญจริงๆ
เมื่อประเมินคำกล่าวอ้าง zero-knowledge ของผู้ให้บริการ สี่คำถามกำหนดว่าสถาปัตยกรรมเป็นของแท้:
1. การสร้างกุญแจเกิดขึ้นที่ไหน?
ในสถาปัตยกรรม zero-knowledge ที่แท้จริง การสร้างกุญแจการเข้ารหัสเกิดขึ้นฝั่ง client ในเบราว์เซอร์หรือแอปพลิเคชันเดสก์ท็อป ก่อนที่ข้อมูลใดจะถูกส่ง กุญแจที่ได้ใช้เข้ารหัสข้อมูลในเครื่อง มีเพียงข้อความที่เข้ารหัสแล้วเท่านั้นที่เดินทางไปยังเซิร์ฟเวอร์ของผู้ให้บริการ
หากผู้ให้บริการสร้างกุญแจการเข้ารหัสบนเซิร์ฟเวอร์ของตน พวกเขาถือกุญแจ หากพวกเขาถือกุญแจ พวกเขาสามารถถอดรหัสได้ คำกล่าวอ้างถูกต้องทางเทคนิค ("เราเข้ารหัส") แต่ทำให้เข้าใจผิดในนัย
2. ผู้ให้บริการเคยเข้าถึง plaintext หรือไม่?
เครื่องมือบางอย่างเข้ารหัสข้อมูลที่หยุดนิ่ง แต่ถอดรหัสเพื่อการประมวลผล เช่น การรันโมเดล AI, การวิเคราะห์, การจัดทำดัชนีการค้นหา หรือการสร้างบันทึกการตรวจสอบ ในช่วงหน้าต่างการประมวลผล plaintext สามารถเข้าถึงได้บนโครงสร้างพื้นฐานของผู้ให้บริการ การละเมิดในช่วงนั้นเปิดเผยข้อมูลในรูปแบบที่ไม่ได้เข้ารหัส
3. เกิดอะไรขึ้นภายใต้กระบวนการทางกฎหมาย?
หากหน่วยงานรัฐบาลส่งคำสั่งให้กับผู้ให้บริการ ข้อมูลใดที่พวกเขาสามารถผลิตได้? ผู้ให้บริการที่มีกุญแจฝั่งเซิร์ฟเวอร์สามารถถูกบังคับให้ผลิตเนื้อหาที่ถอดรหัสแล้ว ผู้ให้บริการที่มีสถาปัตยกรรม zero-knowledge สามารถผลิตเพียง ciphertext ที่เข้ารหัส แม้แต่ภายใต้การบังคับทางกฎหมาย พวกเขาไม่มีสิ่งที่มีประโยชน์ให้ส่งมอบ
4. การโจมตีเซิร์ฟเวอร์อย่างสมบูรณ์เปิดเผยอะไร?
ใน zero-knowledge implementation ที่แท้จริง การโจมตีโครงสร้างพื้นฐานของผู้ให้บริการอย่างสมบูรณ์ให้เพียง encrypted blob ผู้โจมตีได้รับ ciphertext โดยไม่มีกุญแจถอดรหัส ใน implementation ที่มีกุญแจที่ผู้ให้บริการควบคุม การโจมตีเซิร์ฟเวอร์เปิดเผยทั้งกุญแจและข้อมูล
ความล้มเหลวของ Implementation ของ LastPass
การละเมิด LastPass เผยให้เห็นช่องว่าง implementation เฉพาะ: บัญชีเก่าใช้ PBKDF2 พร้อมเพียง 1 iteration สำหรับการสร้างกุญแจ แทนที่จะเป็น 600,000 iterations ที่แนะนำ การสร้างกุญแจที่อ่อนแอกว่าทำให้การโจมตี brute-force บน vault ที่ถูกดึงข้อมูลออกไปสามารถทำได้ในเชิงคอมพิวเตอร์
นี่แสดงให้เห็นว่าเหตุใดการประเมินคำกล่าวอ้าง zero-knowledge จึงต้องตรวจสอบรายละเอียด implementation ไม่ใช่เพียงคำอธิบายสถาปัตยกรรม ผู้ให้บริการสามารถใช้การออกแบบ zero-knowledge ขณะ implement อย่างอ่อนแอได้ คำถามที่ถูกต้องครอบคลุมทั้งสถาปัตยกรรม (ตำแหน่งการสร้างกุญแจ) และความแข็งแกร่งของ implementation (อัลกอริทึมและจำนวน iteration)
การละเมิด Okta: รูปแบบความล้มเหลวที่แตกต่าง
ในเดือนตุลาคม 2023 Okta เปิดเผยว่าบันทึกการสนับสนุนลูกค้ากว่า 600,000 รายการรั่วไหลในการละเมิด Okta เป็นแพลตฟอร์ม identity ซึ่งเป็นบริษัทที่องค์กรหลายแห่งใช้เพื่อรักษาความปลอดภัยการเข้าถึงเครื่องมือคลาวด์อื่นๆ การละเมิด Okta เป็นรูปแบบความล้มเหลวที่แตกต่างจาก LastPass: ไม่ใช่ความอ่อนแอใน zero-knowledge implementation แต่เป็นการโจมตีโครงสร้างพื้นฐานการสนับสนุนที่มีข้อมูลลูกค้าอยู่
การพุ่งสูง 300% ของการละเมิด SaaS ในปี 2024 (AppOmni/CSA) สะท้อนทั้งรูปแบบความล้มเหลว: ความอ่อนแอเชิงสถาปัตยกรรมเช่น LastPass และการโจมตีโครงสร้างพื้นฐานเช่น Okta สถาปัตยกรรม zero-knowledge แก้ไขรูปแบบความล้มเหลวเชิงสถาปัตยกรรม ไม่ได้ขจัดความเสี่ยงการละเมิดทั้งหมด แต่ทำให้แน่ใจว่าแม้แต่การโจมตีโครงสร้างพื้นฐานอย่างสมบูรณ์ก็ไม่เปิดเผยข้อมูลลูกค้าที่ถอดรหัสได้
การประเมินที่แท้จริงมีหน้าตาอย่างไร
สำหรับทีมจัดซื้อที่ประเมินคำกล่าวอ้าง zero-knowledge รายการตรวจสอบการประเมิน:
การตรวจสอบสถาปัตยกรรม:
- ขอเอกสารแสดงให้เห็นว่าการสร้างกุญแจเกิดขึ้นที่ไหน (ฝั่ง client vs. ฝั่งเซิร์ฟเวอร์)
- ขอ algorithm การเข้ารหัส ความยาวกุญแจ และจำนวน iteration
- ขอการยืนยันว่า plaintext ไม่มีวันถูกส่งไปยังเซิร์ฟเวอร์ของผู้ให้บริการ
การทดสอบสถานการณ์การละเมิด:
- ถามผู้ให้บริการว่าการโจมตีเซิร์ฟเวอร์อย่างสมบูรณ์จะเปิดเผยอะไร
- หากคำตอบรวมสิ่งใดนอกเหนือจาก "encrypted ciphertext ที่เราไม่สามารถถอดรหัส" คำกล่าวอ้างไม่ใช่ zero-knowledge ที่แท้จริง
การตรวจสอบกระบวนการทางกฎหมาย:
- ถามว่าผู้ให้บริการสามารถปฏิบัติตามคำสั่งที่ต้องการ plaintext ของลูกค้าได้หรือไม่
- ผู้ให้บริการ zero-knowledge ที่แท้จริงไม่สามารถผลิตสิ่งที่พวกเขาไม่มีได้
เอกสารการปฏิบัติตามกฎระเบียบ:
- ขอเอกสารการปฏิบัติตาม GDPR มาตรา 32 ของผู้ให้บริการ
- การรับรอง ISO 27001 โดยเฉพาะ Annex A cryptographic controls ให้การตรวจสอบภายนอกของแนวปฏิบัติการจัดการกุญแจ
ค่าปรับ ICO 1.2 ล้านปอนด์ของ LastPass กำหนดว่าผู้ให้บริการที่อ้างการเข้ารหัสอยู่ภายใต้การประเมินด้านกฎระเบียบว่าคำกล่าวอ้างเหล่านั้นเป็นไปตามมาตรฐานที่กำหนดหรือไม่ กรอบการประเมินเดียวกันที่หน่วยงานกำกับดูแลใช้มีให้สำหรับทีมจัดซื้อก่อนที่จะเกิดการละเมิด
แหล่งที่มา: