จะเก็บกุญแจส่วนตัวได้ที่ไหน


22

กล่าวว่าฉันต้องการเข้ารหัสบางส่วนของซอฟต์แวร์ ตัวอย่างเช่นข้อมูลประจำตัวสำหรับฐานข้อมูล ฯลฯ ฉันต้องเก็บค่าเหล่านั้นไว้ที่อื่น แต่การทำเช่นนี้ใน cleartext จะทำให้ผู้โจมตีสามารถเข้าถึงได้โดยไม่ได้รับอนุญาต

อย่างไรก็ตามหากฉันเข้ารหัสข้อความธรรมดาบางส่วนฉันจะเก็บกุญแจไว้ที่ไหน สิ่งใดก็ตามที่ซอฟต์แวร์สามารถเข้าถึงผู้โจมตีที่ถูกกำหนดจะสามารถเข้าถึงได้ไม่ว่าระดับของการทำให้งงงวย:

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

วิทยาการเข้ารหัสลับมีความแรงพอ ๆ กับจุดอ่อนที่สุดในห่วงโซ่การเชื่อมโยงและดูเหมือนจะหลวมไปหน่อย! สมมติว่าเป็นเครื่องมือที่เหมาะสมสำหรับงาน (humour me) แล้วจะมีวิธีรักษาความปลอดภัยข้อมูลดังกล่าวได้อย่างไร


เกี่ยวกับเครื่องมือที่เหมาะสมสำหรับงาน: อาจเป็นในกรณีของการเข้าถึงบริการ (DBs, เซิร์ฟเวอร์การตรวจสอบความถูกต้อง ฯลฯ ) คุณจะ จำกัด การเข้าถึงที่ระดับนี้ด้วยบัญชีบริการอาจมีระดับบริการบางอย่าง การตรวจสอบและอื่น ๆ การมีข้อมูลประจำตัวใน cleartext นั้นไม่ต้องกังวล

อย่างไรก็ตามสำหรับฉันที่ยังดูเหมือนไม่เพียงพอ: ฉันไม่ต้องการให้ใครก็ตามที่ไม่ควรไปไหนมาไหน!


6
คุณอาจพบโพสต์ต่างๆที่ Security.SEเป็นที่สนใจ ฉันจะทราบว่ากรอบและภาษาบางอย่างให้การสนับสนุนเป็นพิเศษสำหรับเรื่องนี้ (เช่นส่วนการกำหนดค่าที่เข้ารหัสใน. net)
Brian

9
น่าเสียดายที่คุณไม่สามารถทำอะไรกับ "superusers ที่เป็นอันตราย" ได้มากนัก เนื่องจากซอฟต์แวร์ของคุณต้องการการเข้าถึงคีย์ดังนั้น superuser ใด ๆ จะมีความสามารถในการแก้ไข / บายพาส ACL ใด ๆ ที่คุณอาจใช้แทน
DXM

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

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

3
วิธีที่ดีที่สุดที่คุณสามารถทำได้เกี่ยวกับไคลเอนต์ที่เป็นอันตรายคือการ จำกัด ให้บริการ API ที่กำหนดไว้อย่างดีไม่ให้พวกเขาเข้าถึงฐานข้อมูลโดยตรง คุณไม่สามารถทำอะไรได้มากกว่านั้นเนื่องจากคุณไม่สามารถซ่อนความลับในไคลเอนต์ได้
CodesInChaos

คำตอบ:


25

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

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

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

คำถามชัดเจนดังนั้นก่อนอื่นฉันจะพยายามที่จะอยู่ในแต่ละประเด็นของคุณ:

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

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

หรือกุญแจถูกเข้ารหัสในซอฟท์แวร์ไบนารี แต่มันสามารถถอดรหัสได้เสมอและสิ่งที่เกี่ยวกับซอฟต์แวร์โอเพนซอร์ซหรือการตีความรหัส?

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

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

ใช่แล้วขั้นตอนวิธีจะกลายเป็นข้อมูลไพรเวตคีย์สำหรับการสร้างไพรเวตคีย์ ดังนั้นตอนนี้จะต้องได้รับการปกป้อง

ดังนั้นผมคิดว่าคุณได้ระบุเป็นปัญหาหลักที่มีนโยบายการรักษาความปลอดภัยใด ๆการจัดการที่สำคัญ การมีนโยบายการจัดการที่สำคัญคือศูนย์กลางของการให้ระบบที่ปลอดภัย และมันเป็นหัวข้อกว้างสวย

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

ตอนนี้ถ้าคุณเต็มใจที่จะจ่ายมีบางคนออกไปที่นั่นเพื่อแก้ปัญหานี้ เราสิ้นสุดการใช้HSM (อุปกรณ์รักษาความปลอดภัย Module) มันเป็นเซิร์ฟเวอร์ป้องกันการงัดแงะที่มีรหัสในฮาร์ดแวร์ คีย์นี้สามารถใช้เพื่อสร้างคีย์อื่น ๆ ที่ใช้สำหรับการเข้ารหัส แนวคิดในที่นี้คือ (หากกำหนดค่าไว้ถูกต้อง) กุญแจจะไม่ทิ้ง HSM HSMs เสียค่าใช้จ่ายมาก แต่ในบางธุรกิจ (ปกป้องข้อมูลบัตรเครดิตให้พูด) ค่าใช้จ่ายในการฝ่าฝืนจะสูงขึ้นมาก ดังนั้นจึงมีความสมดุล

HSMs จำนวนมากใช้คีย์การ์ดจากการบำรุงรักษาและการดูแลระบบของคุณสมบัติ โควรัมคีย์การ์ด (5 จาก 9 สมมติว่า) ต้องใส่ลงในเซิร์ฟเวอร์เพื่อเปลี่ยนคีย์ ดังนั้นสิ่งนี้ยกระดับค่อนข้างสูงโดยอนุญาตให้มีการฝ่าฝืนหากองค์ประชุมของผู้ใช้ขั้นสูงสมรู้ร่วมคิด

อาจมีโซลูชันซอฟต์แวร์ที่มีคุณสมบัติคล้ายกับ HSM แต่ฉันไม่ทราบว่ามันคืออะไร

ฉันรู้ว่านี่เป็นเพียงวิธีการในการตอบคำถามเท่านั้น แต่ฉันหวังว่านี่จะช่วยได้


2
"ดีฉันเดาว่าระบบที่ปลอดภัยอย่างสมบูรณ์จะเป็นระบบที่เซิร์ฟเวอร์ทั้งหมดถูกปิด" และไม่มีวิธีที่จะเปิดใช้งานได้
StingyJack

2

สิ่งที่คุณต้องการไม่สามารถทำได้

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

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

ดังนั้นอย่าทำงานกับฐานข้อมูลรับรอง แต่เป็นกลไกการตรวจสอบสิทธิ์อื่น ๆ แต่ไม่ว่าอะไรจะเกิดขึ้นใครบางคนต้องการเข้าถึงข้อมูลและบางคนอาจเป็นอันตรายได้


2

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

ปรัชญาแรกคือ "ไม่ไว้วางใจลูกค้า" และสิ่งที่เกี่ยวข้องอย่างใกล้ชิด "ถ้าคุณต้องการเก็บความลับอย่าบอกใครเลย!"

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

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

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

หากคุณเป็นหนึ่งในกรณีการใช้งานแคบ ๆ มันเป็นเรื่องของความงงงวยซึ่งเป็นเรื่องของการสร้างสรรค์ มันคล้ายกับ Code Golf จริงๆ - ยกเว้นคุณเป็นผู้สร้างปริศนา นั่นคือทั้งหมดที่มันเป็น - ปริศนา และผู้คนชอบไขปริศนาดังนั้นจะดีกว่าเมื่อมีคนคิดออก

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

ในบริบทการเข้ารหัส / การรักษาความปลอดภัย "การจัดการคีย์" ที่แท้จริงคำตอบของ "ตำแหน่งที่จะจัดเก็บคีย์ส่วนตัว" คือ "ที่อื่น!" การเข้ารหัสเป็นการป้องกันแบบจุดต่อจุดและการเข้ารหัสคีย์สาธารณะถูกออกแบบมาเพื่อปกป้องข้อมูลในการขนส่งผ่านเวลาและพื้นที่ ไพรเวตคีย์นั้นมีความเสี่ยงโดยเนื้อแท้และการปกป้องมันไม่ได้เป็นปัญหาของการเข้ารหัสที่ทับซ้อนกัน - มันคือการรักษาความปลอดภัยจากการเข้าถึงโดยสิ้นเชิง และหากระบบต้องเข้าถึงระบบก็จะต้องมีการรักษาความปลอดภัย - และคุณไม่สามารถทำได้บนเครื่องของลูกค้า พวกเขาสามารถเรียกใช้ VM, ถ่ายโอนข้อมูล RAM, ดมกลิ่นการรับส่งข้อมูลเครือข่ายของพวกเขาติดตั้งพร็อกซีหรือ NIC เสมือน decompile executables ... ไม่สมัครใจเข้าร่วมในการต่อสู้ที่สูญเสียไป

ตอนนี้ถ้าคุณต้องการที่จะทำสิ่งที่ชอบ DRM ที่ความต้องการของคุณจะเก็บเป็นความลับเป็นไปตามจริงในการควบคุมการใช้ซอฟต์แวร์ของตัวเองนั่นคือสถานการณ์อื่นทั้งหมด


TLDR: อย่าเก็บความลับจากผู้ใช้เก็บความลับกับผู้ใช้


1

หนึ่งในระบบที่ฉันใช้ในปัจจุบันทำงานด้วยวิธีนี้

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

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

โดยทั่วไปถ้าคุณมี superuser มุ่งร้ายการเดิมพันทั้งหมดจะปิด และคุณควรถือว่ามี superuser ที่เป็นอันตรายในโมเดลภัยคุกคามของคุณ

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

หากบริการที่ได้รับการปกป้องของคุณนั้นไม่สำคัญเท่ากับที่จะสามารถใช้มาตรการดังกล่าวได้ให้ไปที่ที่เก็บคีย์ที่เข้ารหัสไว้ซึ่งระบบปฏิบัติการให้คุณ: ทั้ง Windows, Linux และ OSX มีการใช้งานพวงกุญแจ


-1

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

อีกวิธีหนึ่งอาจจะมีระบบรักษาความปลอดภัยเป็นบัญชีฐานข้อมูลด้วยตนเอง ไม่สามารถปรับขนาดได้มาก ...

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.