ไม่มีฐานข้อมูลกลาง

ฉันมีลูกค้าที่ต้องการเว็บไซต์ / แอพมือถือ / แอพเดสก์ท็อปที่สร้างขึ้นเพื่อจัดการกับข้อมูลที่มีความอ่อนไหวมาก (ละเอียดอ่อนกว่ารายละเอียดธนาคาร / บัตร) เนื่องจากลักษณะที่ละเอียดอ่อนของข้อมูลพวกเขาไม่ต้องการบันทึกลงในฐานข้อมูลกลาง แต่พวกเขายังต้องการให้แอพของพวกเขาซิงโครไนซ์ (สมมติว่าฉันเพิ่มข้อมูลลงในแอพมือถือของฉันแล้วฉันต้องการไปที่ แอปเดสก์ท็อปและดูข้อมูลเดียวกัน)

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

ทางออกหนึ่งที่ฉันคิดคือการมีฐานข้อมูลฝั่งไคลเอ็นต์ในแต่ละแอพที่จะซิงค์ระหว่างแอพฉันเห็นว่ามันไม่น่าเชื่อถือและยุ่งเหยิง

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

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

คุณจำเป็นต้องมีการสำรองข้อมูลขั้นตอนที่สองและในการให้คำปรึกษากับลูกค้าของคุณทำงานออกมาเป็นรูปแบบของภัยคุกคาม (ใช่นั่นคือลิงค์ไปยังหนังสือ 600 หน้าใช่ฉันแนะนำให้คุณอ่านทุกอย่างอย่างจริงจัง)

รูปแบบการคุกคามเริ่มต้นด้วยการถามคำถามเช่น

• ทำไมแอพจำเป็นต้องจัดเก็บข้อมูลที่ละเอียดอ่อนนี้ตั้งแต่แรก?
  • คุณสามารถหลีกเลี่ยงการเก็บมันได้ทั้งหมดหรือไม่?
  • มันจะถูกโยนทิ้งไปในเวลาอันสั้นหรือไม่?
  • จำเป็นต้องเข้าถึงอุปกรณ์มากกว่าหนึ่งเครื่องอย่างแท้จริงหรือไม่?
  • หากต้องสามารถเข้าถึงได้ในอุปกรณ์มากกว่าหนึ่งเครื่องจำเป็นต้องจัดเก็บในอุปกรณ์มากกว่าหนึ่งเครื่องหรือไม่
• ใครคือผู้ที่ได้รับอนุญาตให้ดูข้อมูลที่ละเอียดอ่อนของผู้ใช้แต่ละคน
  • รายการนี้สามารถทำให้สั้นลงได้หรือไม่?
• ใครคือผู้ที่อาจได้รับข้อมูลที่ละเอียดอ่อนของผู้ใช้แต่ละคนขณะที่พยายามทำงาน แต่ไม่จำเป็นต้องรู้
  • สามารถนี้รายการจะทำให้สั้นลง?
  • ข้อมูลนี้ไม่สามารถเข้าถึงได้โดยไม่กระทบต่อความสามารถในการทำงานของพวกเขาหรือไม่?
  • หากไม่สามารถเข้าถึงไม่ได้อย่างน้อยจะเข้าใจไม่ได้หรือไม่ (นี่คือสิ่งที่การเข้ารหัสทำในนามธรรม: ทำให้ข้อมูลไม่สามารถเข้าใจได้)
• ใครคือคนที่ต้องการดูข้อมูลที่ละเอียดอ่อน แต่ไม่ได้รับอนุญาต
  • พวกเขามีโอกาสใดบ้างที่จะได้รับข้อมูล
  • พวกเขาต้องการทำอะไรกับข้อมูลเมื่อมีข้อมูล
  • พวกเขาจะโกรธแค่ไหนถ้าพวกเขาไม่ได้สิ่งที่ต้องการ?
  • พวกเขายินดีที่จะใช้เงินเงินเวลารอบการทำงานของ CPU และความพยายามของมนุษย์เท่าใด
  • พวกเขาสนใจหรือไม่ถ้ามีคนรู้ว่าพวกเขาเห็นข้อมูลหรือไม่
  • พวกเขาต้องการเข้าถึงข้อมูลที่ละเอียดอ่อนของผู้ใช้โดยเฉพาะหรือไม่
  • พวกเขารู้อะไรอยู่แล้ว
  • พวกเขาสามารถเข้าถึงอะไรได้บ้าง

เมื่อคุณรู้คำตอบของคำถามเหล่านี้แล้วคุณจะอยู่ในตำแหน่งที่ดีกว่ามากในการหาว่าต้องทำอะไร

โปรดทราบว่าอาจมีคำตอบมากกว่าหนึ่งคำถามสำหรับแต่ละชุดคำถามโดยเฉพาะคำถามที่เกี่ยวข้องกับผู้โจมตี (ผู้ที่ต้องการข้อมูลที่ละเอียดอ่อน แต่ไม่ได้รับอนุญาต) หากคุณไม่สามารถนึกถึงผู้โจมตีตามแบบฉบับที่แตกต่างกันอย่างน้อยครึ่งโหลโดยมีแรงจูงใจเป้าหมายและทรัพยากรที่แตกต่างกันคุณอาจพลาดบางสิ่งไป

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

ตัวเลือกหนึ่งในการทำข้อมูลให้ตรงกันคือทำแบบ peer-to-peer สิ่งนี้จะยังคงต้องใช้เซิร์ฟเวอร์กลาง แต่เซิร์ฟเวอร์นั้นจะไม่จัดการกับข้อมูลใด ๆ

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

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

ทำให้เป็นปัญหาของคนอื่น

เก็บข้อมูลไว้ในเครื่องในแต่ละแอพจากนั้นให้ผู้ใช้มีตัวเลือกในการเปิดใช้งานการซิงโครไนซ์โดยใช้บัญชีของตนเองกับบริการของบุคคลที่สาม (Dropbox, Google Drive, ฯลฯ ) และคิดเกี่ยวกับการเข้ารหัสข้อมูลใด ๆ ที่อัปโหลดไปยังบริการบุคคลที่สาม (มีข้อดีและข้อเสียในการทำเช่นนั้น)

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

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

หากลูกค้าของคุณไม่ต้องการให้จัดเก็บข้อมูลใด ๆ พวกเขาต้องการให้ผู้ใช้ป้อนมือของฉันทุกครั้งหรือไม่