คำศัพท์สำคัญที่นักพัฒนาซอฟต์แวร์ต้องรู้

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

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

ความปลอดภัยของข้อมูลเป็นเพียงแค่การส่งต่อ

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

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

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

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

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

แฮชชิ่ง

หากคุณต้องการคำจำกัดความที่เคร่งครัดมาก ก็มีเสมอ วิกิพีเดียแต่พูดง่ายๆ การแฮชคือกระบวนการแปลงข้อมูลเป็นรูปแบบอื่น โดยที่ข้อมูลไม่สามารถอ่านได้ ตัวอย่างเช่น การใช้กระบวนการที่รู้จักกันดี (และไม่ปลอดภัยมาก) ของ การเข้ารหัส 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 เป็นต้น

เกลือ

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

“นาย. Rumpelstiltskin ฉันเข้าใจ?!”

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

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

กุญแจ

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

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

แป้นหมุน

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

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

เครดิตรูปภาพ: AWS

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

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

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

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

เครดิตรูปภาพ: มูลนิธิพรมแดนอิเล็กทรอนิกส์

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

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

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

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

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

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

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

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

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

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

การเข้ารหัสแบบครบวงจร

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

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

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

เครดิตรูปภาพ: Google

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

บทสรุป 👩‍🏫

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