การเข้ารหัส

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

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

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

HTTPS

การย้ายครั้งแรกคือการให้บริการเว็บของคุณผ่าน HTTPS ก็มีโอกาสมากที่คุณจะเคยทำแล้ว แต่หากไม่เป็นเช่นนั้น นี่ถือเป็นขั้นตอนสำคัญ HTTPS คือ HTTP ซึ่งเป็นโปรโตคอลที่เบราว์เซอร์ใช้เพื่อขอหน้าเว็บจากเซิร์ฟเวอร์ แต่เข้ารหัสโดยใช้ SSL ซึ่งหมายความว่าผู้โจมตีภายนอกจะไม่สามารถอ่านหรือแทรกแซงคำขอ HTTPS ระหว่างผู้ส่ง (ผู้ใช้ของคุณ) และผู้รับ (คุณ) ได้เนื่องจากมีการเข้ารหัสเข้ารหัส ทำให้อ่านหรือเปลี่ยนแปลงไม่ได้ การเข้ารหัสขณะรับส่ง กล่าวคือ เมื่อมีการย้ายข้อมูลจากผู้ใช้มายังคุณ หรือจากคุณไปยังผู้ใช้ การเข้ารหัส HTTPS ระหว่างการส่งยังป้องกันไม่ให้ ISP ของผู้ใช้หรือผู้ให้บริการ Wi-Fi ที่ใช้อยู่ อ่านข้อมูลที่ส่งให้คุณในฐานะส่วนหนึ่งของความสัมพันธ์กับบริการของคุณได้ด้วย อาจส่งผลต่อฟีเจอร์ของบริการเช่นกัน การใช้งาน JavaScript API ที่มีอยู่หลายรายการกำหนดให้เว็บไซต์ต้องแสดงผลผ่าน HTTPS MDN มีรายการที่ครอบคลุมมากกว่า แต่ API ที่เกิดขึ้นเบื้องหลังบริบทที่ปลอดภัย ได้แก่ โปรแกรมทำงานของบริการ, ข้อความ Push, การแชร์เว็บ, เว็บคริปโต และ API ของอุปกรณ์บางอย่าง

ในการแสดงเว็บไซต์ผ่าน HTTPS คุณจะต้องมีใบรับรอง SSL เครื่องมือเหล่านี้สร้างขึ้นได้ฟรีผ่าน Let's Encrypt หรือมักจะให้บริการโดยบริการโฮสติ้งของคุณหากคุณใช้บริการอยู่ คุณยังสามารถใช้บริการของบุคคลที่สามซึ่ง "พร็อกซี" บริการเว็บของคุณให้บริการ HTTPS รวมถึงบริการแคชและ CDN ได้ ตัวอย่างบริการดังกล่าวมีอยู่เป็นจำนวนมาก เช่น Cloudflare และ Fastly ตัวอย่างการใช้งานจะขึ้นอยู่กับโครงสร้างพื้นฐานปัจจุบันของคุณ ที่ผ่านมา HTTPS อาจมีภาระหรือค่าใช้จ่ายสูงในการใช้งาน จึงเป็นเหตุผลที่มักจะใช้บนหน้าการชำระเงินหรือต้นทางที่ปลอดภัยเป็นพิเศษเท่านั้น แต่ใบรับรองที่ใช้งานได้ฟรี การปรับปรุงมาตรฐาน และการเพิ่มขึ้นของเบราว์เซอร์ที่เพิ่มมากขึ้นได้ขจัดอุปสรรคเหล่านั้นออกไปทั้งหมด

ควรทำ

• เปิดใช้ HTTPS บนเซิร์ฟเวอร์สำหรับทุกอย่าง (ขึ้นอยู่กับวิธีที่คุณเลือก)
• ลองใช้พร็อกซีด้านหน้าเซิร์ฟเวอร์ เช่น Cloudflare (httpsiseasy.com/ อธิบายกระบวนการนี้)
• Let's Encrypt จะอธิบายขั้นตอนการสร้างใบรับรอง SSL ของคุณเอง
• หรือใช้ OpenSSL โดยตรงเพื่อสร้างใบรับรองของคุณเองและลงนามโดยผู้ออกใบรับรอง (CA) ที่คุณเลือก (เปิดใช้ HTTPS จะอธิบายวิธีดำเนินการโดยละเอียด)

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

การสร้างใบรับรองและลงชื่อโดย CA คือกระบวนการที่ใช้ในการดำเนินการ SSL แต่การใช้ Let's Encrypt จะง่ายขึ้นหากผู้ให้บริการสนับสนุนหรือหากทีมเซิร์ฟเวอร์ของคุณมีความเชี่ยวชาญทางเทคนิคเพียงพอและให้บริการฟรี นอกจากนี้ ยังเป็นเรื่องปกติที่ผู้ให้บริการของคุณจะเสนอ SSL เป็นบริการหากคุณใช้บริการระดับสูงกว่าโฮสติ้งระบบคลาวด์ ดังนั้นเราขอแนะนำให้คุณตรวจสอบ

ทำไมจึงควร

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

วิธีที่เบราว์เซอร์แสดงหน้า HTTP (ไม่ปลอดภัย)

เปลี่ยนเส้นทางไปยัง HTTPS

หากเว็บไซต์ของคุณสามารถใช้ได้ทั้งใน URL แบบ http: และ https: คุณควรเปลี่ยนเส้นทางการเข้าถึง URL แบบ http ทั้งหมดไปยัง https ด้วยเหตุผลข้างต้นและยังช่วยให้มั่นใจว่าเว็บไซต์ของคุณจะไม่ปรากฏใน whynohttps.com หากได้รับความนิยม วิธีการนี้ขึ้นอยู่กับโครงสร้างพื้นฐานของคุณอย่างมาก หากคุณโฮสต์บน AWS จะใช้ตัวจัดสรรภาระงานคลาสสิกหรือแอปพลิเคชันได้ ส่วน Google Cloud ก็มีความคล้ายคลึงกัน ใน Azure คุณสร้าง Front Door, ใน Node with Express check for request.secure ใน Nginx ให้ตรวจจับพอร์ต 80 ทั้งหมดและแสดงผล 301 และใน Apache ให้ใช้ ใช้ RewriteRule หากคุณกำลังใช้บริการโฮสติ้ง มีแนวโน้มว่าผู้ให้บริการดังกล่าวจะจัดการการเปลี่ยนเส้นทางไปยัง URL แบบ HTTPS ให้คุณโดยอัตโนมัติ เช่น Netlify, Firebase และ GitHub Pages เป็นต้น

HSTS

HSTS เป็นชื่อย่อของ "HTTP Strict-Transport-Security" และเป็นวิธีล็อกเบราว์เซอร์ให้ใช้ HTTPS กับบริการของคุณตลอดไป เมื่อพอใจกับการย้ายข้อมูลไปยัง HTTPS แล้วหรือหากดำเนินการแล้ว คุณจะเพิ่มส่วนหัวการตอบกลับ HTTP Strict-Transport-Security ลงในการตอบกลับขาออกได้ เบราว์เซอร์ที่เคยเข้าถึงเว็บไซต์ของคุณมาก่อนจะบันทึกว่าตนเห็นส่วนหัวนี้ จากนั้นจะเข้าถึงเว็บไซต์นี้เป็น HTTPS โดยอัตโนมัติแม้ว่าคุณจะขอ HTTP ก็ตาม การดำเนินการนี้จะหลีกเลี่ยงการเปลี่ยนเส้นทางของคุณในลักษณะข้างต้น ทำให้เหมือนกับว่าเบราว์เซอร์จะ "อัปเกรด" คำขอทั้งหมดที่ส่งไปยังบริการของคุณเพื่อใช้ HTTPS แบบเงียบ

ในทำนองเดียวกัน คุณอาจแสดงส่วนหัว Upgrade-Insecure-Requests กับหน้าเว็บได้ การดำเนินการนี้มีลักษณะที่ต่างจากเดิม แต่เกี่ยวข้องกับ Strict-Transport-Security หากคุณเพิ่ม Upgrade-Insecure-Requests: 1 ระบบจะส่งคำขอจากหน้านี้ไปยังทรัพยากรอื่นๆ (รูปภาพ สคริปต์) เป็น https แม้ว่าลิงก์จะเป็น http ก็ตาม แต่เบราว์เซอร์จะไม่ขอหน้าเว็บอีกครั้งเป็น https และเบราว์เซอร์จะจำไม่ได้ในครั้งต่อไป ในทางปฏิบัติ คำขออัปเกรดที่ไม่ปลอดภัยจะมีประโยชน์ในกรณีที่คุณแปลงเว็บไซต์ที่มีอยู่ซึ่งมีลิงก์จำนวนมากเป็น HTTPS และการแปลง URL ของลิงก์ในเนื้อหาเป็นเรื่องที่ทำได้ยาก แต่การเปลี่ยนแปลงเนื้อหาเมื่อเป็นไปได้จะดีกว่า

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

ควรทำ

เพิ่มส่วนหัว HSTS ในการตอบกลับขาออกของคุณ:

Strict-Transport-Security: max-age=300; includeSubDomains

พารามิเตอร์ max-age เป็นตัวกำหนดระยะเวลาเป็นวินาทีที่เบราว์เซอร์ควรจดจำและบังคับใช้การอัปเกรด HTTPS (เราตั้งค่าเป็น 300 วินาที นั่นคือ 5 นาที) ในท้ายที่สุดแล้วคุณต้องการให้ URL นี้เท่ากับ 6,3072,000 ซึ่งคิดเป็น 2 ปีและเป็นตัวเลขที่ hstspreload.org แนะนำ แต่การจะกู้คืนค่อนข้างยากหากมีปัญหา ดังนั้น ขอแนะนำให้คุณตั้งค่านี้โดยใช้ตัวเลขต่ำในตอนแรก (300) ทดสอบเพื่อยืนยันว่าไม่มีอะไรผิดพลาด จากนั้นเพิ่มจำนวนเป็นระยะ

เพิ่มส่วนหัว Upgrade-Insecure-Requests ในคำตอบขาออก ดังนี้

Upgrade-Insecure-Requests: 1 Content-Security-Policy: upgrade-insecure-requests

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

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

ลักษณะการจัดกิจกรรม

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

ตัวอย่าง: Excalidraw

Excalidraw ทำเช่นนี้และอธิบายวิธีในบล็อกโพสต์ นี่เป็นแอปวาดเวกเตอร์ ที่เก็บภาพวาดบนเซิร์ฟเวอร์ ซึ่งถูกเข้ารหัสด้วยคีย์ที่เลือกมาแบบสุ่ม สาเหตุส่วนหนึ่งที่ Excalidraw สามารถใช้การเข้ารหัสจากต้นทางถึงปลายทางได้ด้วยโค้ดเพียงเล็กน้อยก็คือตอนนี้ไลบรารีการเข้ารหัสลับมีอยู่ในเบราว์เซอร์ด้วย window.crypto ซึ่งเป็นชุด JavaScript API ที่รองรับในเบราว์เซอร์สมัยใหม่ทั้งหมด วิทยาการเข้ารหัสนั้นไม่ใช่เรื่องง่าย และการใช้อัลกอริทึม ก็มาพร้อมขอบข่ายเรื่องต่างๆ มากมาย การที่เบราว์เซอร์ทำหน้าที่นี้ทำให้นักพัฒนาเว็บเข้าถึงการเข้ารหัสได้ง่ายขึ้น ดังนั้นจึงทำให้การนำความเป็นส่วนตัวไปใช้ผ่านข้อมูลที่เข้ารหัสทำได้ง่ายขึ้น ตามที่ Excalidraw อธิบายไว้ในการเขียน คีย์การเข้ารหัสยังคงอยู่ในฝั่งไคลเอ็นต์เนื่องจากเป็นส่วนหนึ่งของส่วนย่อย URL เมื่อเบราว์เซอร์ไปที่ URL https://example.com/path?param=1#fraghere เส้นทางของ URL (/path) และพารามิเตอร์ (param=1) จะส่งไปยังเซิร์ฟเวอร์ (example.com) แต่ส่วน (fraghere) จะไม่ปรากฏ เซิร์ฟเวอร์จึงไม่เคยเห็นส่วนดังกล่าว ซึ่งหมายความว่าแม้ว่าข้อมูลที่เข้ารหัสไว้จะส่งผ่านเซิร์ฟเวอร์ แต่คีย์การเข้ารหัสจะไม่ได้รับการปกป้อง และจะมีการรักษาความเป็นส่วนตัวเนื่องจากข้อมูลได้รับการเข้ารหัสจากต้นทางถึงปลายทาง

ข้อจำกัด

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

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

การเข้ารหัสเมื่อไม่มีการเคลื่อนไหว

นอกจากการเข้ารหัสข้อมูลของผู้ใช้ในระหว่างการส่งแล้ว ก็ยังควรพิจารณาการเข้ารหัสข้อมูลที่คุณจัดเก็บไว้ในเซิร์ฟเวอร์ด้วย การดำเนินการเช่นนี้จะช่วยป้องกันการละเมิดข้อมูล เนื่องจากผู้ใดก็ตามที่มีสิทธิ์เข้าถึงข้อมูลที่จัดเก็บไว้โดยไม่ได้รับอนุญาต จะมีข้อมูลที่มีการเข้ารหัส ซึ่งอาจไม่มีคีย์สำหรับถอดรหัส วิธีการเข้ารหัสข้อมูลที่ไม่มีการเคลื่อนไหวมี 2 วิธีที่แตกต่างกันและเป็นส่วนเสริม ได้แก่ การเข้ารหัสที่คุณเพิ่ม และการเข้ารหัสที่ผู้ให้บริการพื้นที่เก็บข้อมูลระบบคลาวด์เพิ่ม (หากคุณใช้ผู้ให้บริการพื้นที่เก็บข้อมูลระบบคลาวด์) การเข้ารหัสของผู้ให้บริการพื้นที่เก็บข้อมูลไม่ได้ให้การป้องกันการละเมิดข้อมูลผ่านซอฟต์แวร์มากนัก (เนื่องจากโดยปกติแล้วการเข้ารหัสของผู้ให้บริการพื้นที่เก็บข้อมูลจะมีความโปร่งใสกับคุณในฐานะผู้ใช้บริการ) แต่ก็ช่วยป้องกันการละเมิดที่เกิดขึ้นในโครงสร้างพื้นฐานของผู้ให้บริการได้ การเปิดใช้ก็เป็นเรื่องง่าย จึงควรพิจารณา ช่องนี้มีการเปลี่ยนแปลงอย่างรวดเร็ว ทีมรักษาความปลอดภัยของคุณ (หรือวิศวกรที่เชี่ยวชาญด้านความปลอดภัยในทีม) ควรให้คำแนะนำแก่บริการนี้ แต่ผู้ให้บริการพื้นที่เก็บข้อมูลระบบคลาวด์ทุกรายจะเสนอการเข้ารหัสเมื่อไม่มีการเคลื่อนไหวสำหรับ พื้นที่เก็บข้อมูลแบบบล็อก Amazon S3 โดยการตั้งค่า, Azure Storage และ Google Cloud Storage โดยค่าเริ่มต้น และสำหรับการจัดเก็บข้อมูลฐานข้อมูล AWS RDS, Azure SQL และ SQL อื่นๆ ลองใช้ข้อมูลนี้กับผู้ให้บริการพื้นที่เก็บข้อมูลระบบคลาวด์ หากคุณใช้บัญชี การจัดการการเข้ารหัสข้อมูลที่ไม่มีการเคลื่อนไหวด้วยตนเองเพื่อช่วยปกป้องข้อมูลผู้ใช้จากการละเมิดข้อมูลทำได้ยากขึ้น เนื่องจากการจัดการคีย์การเข้ารหัสอย่างปลอดภัยและการทำให้คีย์เหล่านี้พร้อมใช้งานกับผู้โจมตีได้นั้นเป็นเรื่องยาก นี่ไม่ใช่วิธีที่ดีที่สุดที่จะให้คำปรึกษาเกี่ยวกับปัญหาด้านความปลอดภัยในระดับนั้น ปรึกษาวิศวกรที่เชี่ยวชาญด้านความปลอดภัยหรือทีมเฉพาะทางเกี่ยวกับเรื่องนี้ หรือหน่วยงานด้านความปลอดภัยภายนอก