การเข้ารหัสข้อมูล: คำศัพท์เฉพาะที่นักพัฒนาต้องรู้

ในขณะที่โลกขับเคลื่อนด้วยข้อมูลมากขึ้นเรื่อยๆ การจัดการข้อมูลผู้ใช้อย่างปลอดภัยจึงมีความสำคัญมากกว่าที่เคย

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

ความปลอดภัยของข้อมูลเหมือนการส่งเงิน

สิ่งที่ทำให้การรักษาความปลอดภัยยากขึ้นคือมีหลายชั้นและกลายเป็นความรับผิดชอบของทุกคน ในทีมระบบคลาวด์ที่ทันสมัย ​​หลายทีมควบคุมการเข้า/ออกของข้อมูลโดยตรง: นักพัฒนา ผู้ดูแลระบบฐานข้อมูล ผู้ดูแลระบบ (คน DevOps ถ้าคุณต้องการ) ผู้ใช้ back-office ที่มีสิทธิพิเศษ และอื่นๆ บทบาท/ทีมเหล่านี้สามารถหลับตาได้อย่างรวดเร็วและคิดว่าการรักษาความปลอดภัยของข้อมูลเป็นปัญหาของผู้อื่น อย่างไรก็ตาม ความจริงก็คือพวกเขามีโลกของตัวเองที่ต้องดูแล เนื่องจากผู้ดูแลระบบฐานข้อมูลไม่สามารถควบคุมความปลอดภัยด้านแอปได้ คน DevOps ไม่สามารถทำอะไรได้เลยเกี่ยวกับการเข้าถึงแบ็คออฟฟิศ และอื่นๆ

นักพัฒนาและความปลอดภัยของข้อมูล

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

ในตอนนี้ การรักษาความปลอดภัยของข้อมูลเป็นช่องโหว่ที่ไม่มีจุดสิ้นสุด และไม่มีทางที่ฉันจะขีดข่วนพื้นผิวในโพสต์เดียวได้ อย่างไรก็ตาม ฉันต้องการครอบคลุมคำศัพท์ที่จำเป็นที่นักพัฒนาซอฟต์แวร์ต้องรู้เพื่อให้แอปของตนปลอดภัย คิดว่าเป็น App Data Security 101

มาเริ่มกันเลย!

แฮชชิ่ง

หากคุณต้องการคำจำกัดความที่เข้มงวดมาก มี Wikipedia อยู่เสมอ แต่ในแง่ง่ายๆ การแฮชคือกระบวนการแปลงข้อมูลเป็นรูปแบบอื่น ซึ่งข้อมูลนั้นไม่สามารถอ่านได้ ตัวอย่างเช่น การใช้กระบวนการเข้ารหัส Base64 ที่เป็นที่รู้จัก (และไม่ปลอดภัยมาก) สตริง “ความลับของฉันปลอดภัยกับคุณหรือไม่” สามารถแปลง (“แฮช”) เป็น “SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/” ได้ ตัวอย่างเช่น หากคุณเริ่มเขียนไดอารี่ส่วนตัวในรูปแบบ Base64 ไม่มีทางที่ครอบครัวของคุณจะสามารถอ่านความลับของคุณได้ (เว้นแต่พวกเขาจะรู้วิธีถอดรหัสจาก Base64)!

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

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

ในขณะที่เราอยู่ในหัวข้อของแฮช นี่คือสิ่งที่น่าสนใจ หากคุณเคยดาวน์โหลดซอฟต์แวร์หรือไฟล์จากอินเทอร์เน็ต คุณอาจได้รับแจ้งให้ตรวจสอบไฟล์ก่อนใช้งาน ตัวอย่างเช่น หากคุณต้องการดาวน์โหลด Ubuntu Linux ISO หน้าดาวน์โหลดจะแสดงตัวเลือกให้คุณตรวจสอบยืนยันการดาวน์โหลดของคุณ หากคุณคลิก ป๊อปอัปจะเปิดขึ้น:

ป๊อปอัปบอกให้คุณเรียกใช้คำสั่งซึ่งโดยพื้นฐานแล้วจะแฮชไฟล์ทั้งหมดที่คุณเพิ่งดาวน์โหลดและเปรียบเทียบผลลัพธ์กับสตริงแฮชที่คุณเห็นในหน้าดาวน์โหลด: 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5 การแปลงนี้ดำเนินการโดยใช้อัลกอริทึม SHA256 ซึ่งคุณสามารถเห็นได้ในส่วนสุดท้ายของคำสั่ง: shasum -a 256 --check

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

ชื่อที่คุ้นเคยบางชื่อที่คุณจะได้ยินในโดเมนของการแฮชรหัสผ่านคือ MD5 (ไม่ปลอดภัยและตอนนี้หมดอายุแล้ว), SHA-1 และ SHA-2 (ตระกูลของอัลกอริทึม ซึ่ง SHA-256 เป็นสมาชิก เช่นเดียวกับ SHA-512) SCRYPT, BCRYPT ฯลฯ

เกลือ

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

จึงมีการพัฒนาเทคนิคการทำเกลือ ทั้งหมดหมายความว่าการคำนวณแฮชของรหัสผ่าน (หรือข้อมูลใดๆ) จะทำโดยใช้สองสิ่งร่วมกัน: ข้อมูลเอง เช่นเดียวกับสตริงสุ่มใหม่ที่ผู้โจมตีไม่สามารถคาดเดาได้ ดังนั้น ด้วยการใช้ salting หากเราต้องการแฮชรหัสผ่าน superman009 ก่อนอื่นเราจะเลือกสตริงสุ่มเป็น "เกลือ" เช่น bCQC6Z2LlbAsqj77 จากนั้นทำการคำนวณแฮชใน superman009-bCQC6Z2LlbAsqj77 แฮชที่ได้จะเบี่ยงเบนไปจากโครงสร้างปกติที่สร้างโดยอัลกอริทึม ซึ่งลดขอบเขตสำหรับวิศวกรรมย้อนกลับอัจฉริยะหรือการคาดเดาลงอย่างมาก

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

กุญแจ

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

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

แป้นหมุน

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

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

ตัวอย่างเช่น AWS มีบริการเฉพาะสำหรับบริการนี้ที่เรียกว่า AWS Key Management Service (KMS) บริการอัตโนมัติช่วยให้คุณไม่ต้องยุ่งยากในการเปลี่ยนและแจกจ่ายคีย์ระหว่างเซิร์ฟเวอร์ทั้งหมด และในปัจจุบันนี้ไม่ใช่เรื่องง่ายสำหรับการปรับใช้ขนาดใหญ่

การเข้ารหัสคีย์สาธารณะ

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

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

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

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

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

ความปลอดภัยของชั้นการขนส่ง (TLS)

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

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

คุณอาจเจอคำว่า Secure Socket Layer (SSL) ในบางกรณี เป็นแนวคิดเดียวกันกับ TLS ยกเว้นว่า SSL มีต้นกำเนิดมามากก่อนหน้านี้และตอนนี้เลิกใช้ TLS แทน

การเข้ารหัสดิสก์แบบเต็ม

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

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

การเข้ารหัสตั้งแต่ต้นทางถึงปลายทาง

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

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

ด้วยเหตุนี้ บริษัทเหล่านี้จึงได้เริ่มการเข้ารหัสแบบ end-to-end ซึ่งหมายความว่าข้อมูลจะได้รับการเข้ารหัสเมื่อมีการสร้าง จัดเก็บ หรือโอนโดยแอป กล่าวอีกนัยหนึ่ง แม้ว่าข้อมูลจะไปถึงผู้รับ ข้อมูลจะได้รับการเข้ารหัสอย่างสมบูรณ์และสามารถเข้าถึงได้โดยโทรศัพท์ของผู้รับเท่านั้น

โปรดทราบว่าการเข้ารหัสแบบ End-to-End (E2E) ไม่มีการรับประกันทางคณิตศาสตร์ใด ๆ เช่นเดียวกับการเข้ารหัสคีย์สาธารณะ มันเป็นเพียงการเข้ารหัสมาตรฐานที่จัดเก็บคีย์ไว้กับธุรกิจ และข้อความของคุณก็ปลอดภัยตามที่ธุรกิจตัดสินใจ

บทสรุป

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