เอกสารข้อมูลการเข้ารหัส

อัปเดตล่าสุดเมื่อ: 21 ตุลาคม 2019

บทแนะนำ

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

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

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

การเข้ารหัสคืออะไร

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

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

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

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

เหตุผลที่เราเข้ารหัสข้อมูล

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

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

เราหมายความว่าอย่างไรเมื่อกล่าวถึง 'ข้อมูล'

มีข้อมูลสองประเภทที่เราจัดการ

  1. ข้อมูลลูกค้า - ข้อมูลที่คุณจัดเก็บไว้กับเราผ่านบริการของ Zoho โดยหลักแล้ว ข้อมูลชนิดนี้จะจัดการโดยบริการของ Zoho ผ่านบัญชีของลูกค้า ซึ่งสามารถระบุตัวตนได้ในฐานข้อมูล IAM (Identity and Access Management) ของเรา

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

  2. ข้อมูลที่รวบรวม - ข้อมูลซึ่งคุณไม่ได้เป็นผู้มอบให้โดยตรง แต่รวบรวมมาจากข้อมูลอื่นๆ ของคุณ ตัวอย่างเช่น โทเค็น auth, ID เฉพาะตัว, URL และรายงาน ฯลฯ... จะถูกจัดเก็บไว้กับเรา

    ข้อมูลที่รวบรวมบางส่วนจะถูกเข้ารหัส ในขณะที่บางส่วนไม่ถูกเข้ารหัส ขึ้นอยู่กับระดับความอ่อนไหวของข้อมูล

ในส่วนต่างๆ ต่อจากนี้ไป คำว่า 'ข้อมูล' จะหมายถึงข้อมูลที่ถูกเข้ารหัส

การเข้ารหัสในขณะส่ง

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

มีสถานการณ์สองแบบที่ข้อมูลของคุณจะถูกเข้ารหัส:

  • เมื่อข้อมูลเดินทางจากเบราว์เซอร์ของคุณมายังเซิร์ฟเวอร์ของเรา
  • เมื่อข้อมูลเดินทางจากเซิร์ฟเวอร์ของเราไปยังเซิร์ฟเวอร์ที่ไม่ใช่ของ Zoho (บุคคลที่สาม)

ระหว่างคุณกับ Zoho

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

เรายึดมั่นในโปรโตคอล TLS เวอร์ชัน 1.2/1.3 ล่าสุด และใช้ใบรับรองที่ออกให้โดย SHA 256 และรหัสลับ (คีย์สำหรับการเข้ารหัส 256 บิต/128 บิต AES_CBC/AES_GCM, SHA2 สำหรับการตรวจรับรองความถูกต้องข้อความ และ ECDHE_RSA ในฐานะกลไกการแลกเปลี่ยนคีย์) นอกจากนี้เรายังใช้ระบบ Perfect Forward Secrecy และบังคับใช้ HTTPS Strict Transport Security (HSTS) ในไซต์ทั้งหมด

ระหว่าง Zoho กับบุคคลที่สาม

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

สำหรับวิธีนี้ เราจะสร้างคีย์สาธารณะและคีย์ส่วนตัวขึ้นมาคู่หนึ่งใน KMS (Key Management Service) ของเรา ซึ่งจะสร้าง จัดเก็บ และจัดการคีย์ในบริการทั้งหมด เราเข้ารหัสคู่ของคีย์เหล่านี้โดยใช้คีย์ต้นแบบ และคู่ของคีย์ที่เข้ารหัสแล้วจะถูกจัดเก็บไว้ในตัว KMS เอง คีย์ต้นแบบจะถูกจัดเก็บในเซิร์ฟเวอร์แยกต่างหาก

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

การเข้ารหัสเมื่อไม่มีการใช้งาน

การเข้ารหัสแบ่งออกเป็นสองระดับหลักๆ

  1. การเข้ารหัสระดับแอปพลิเคชัน
  2. การเข้ารหัสทั้งดิสก์โดยยึดฮาร์ดแวร์

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

  • ฐานข้อมูล (Database - DB) - จัดเก็บเป็นตาราง
  • ระบบไฟล์แบบกระจาย (Distributed File System - DFS) - จัดเก็บเป็นไฟล์
  • การเข้ารหัส URL
  • ข้อมูลสำรอง
  • บันทึก (Log)
  • แคช

รูปภาพด้านล่างแสดงให้เห็นภาพรวมกว้างๆ ของกลยุทธ์การเข้ารหัสของเรา:

กลยุทธ์การเข้ารหัส

ระดับแอปพลิเคชัน

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

ส่วนนี้จะเกี่ยวข้องกับการเข้ารหัสเมื่อไม่มีการใช้งานที่ระดับแอปพลิเคชัน

การเข้ารหัส DB

เมื่อคุณใช้บริการต่างๆ เช่น Zoho Creator หรือ Zoho Forms ข้อมูลที่คุณป้อนลงในแอปพลิเคชัน หรือที่เรียกว่าข้อมูลบริการ จะถูกจัดเก็บในฐานข้อมูลของเราเป็นตาราง

ข้อมูลในตารางเหล่านี้จะถูกเข้ารหัสโดยอิงตามมาตรฐาน AES 256 พร้อมด้วยโหมดการเพิ่มข้อมูล AES/CBC/PKCS5P อย่างไรก็ตาม ขึ้นอยู่กับความอ่อนไหวหรือฟิลด์ข้อมูลและตัวเลือกและข้อกำหนดของลูกค้า ระดับของการเข้ารหัสจะแตกต่างกันไป

การเข้ารหัส DB แบ่งออกเป็นสองระดับ

  1. ขึ้นอยู่กับความอ่อนไหวของข้อมูล
  2. ขึ้นอยู่กับฟังก์ชันการค้นหา

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

ขึ้นอยู่กับความอ่อนไหวของข้อมูล

ระดับที่ 1- นี่คือระดับเริ่มต้นของการเข้ารหัสที่เราดำเนินการกับข้อมูลจากองค์กรทั้งหมด ในระดับนี้ KMS ของเราจะจัดสรรคีย์ให้กับแต่ละองค์กร ข้อมูลที่สัมพันธ์กับองค์กรนั้นๆ จะถูกเข้ารหัสโดยใช้คีย์นี้ คีย์จะถูกเข้ารหัสโดยใช้คีย์ต้นแบบและคีย์ที่เข้ารหัสจะถูกจัดเก็บในเซิร์ฟเวอร์แยกต่างหาก

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

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

ขึ้นอยู่กับฟังก์ชันการค้นหา

เวคเตอร์เริ่มต้นการทำงาน (Initialisation Vector - IV) เป็นค่าจากการสุ่มที่จะเริ่มต้นกระบวนการเข้ารหัส ค่าจากการสุ่มนี้ช่วยให้มั่นใจว่าแต่ละบล็อค/หน่วยของข้อมูลจะมีการเข้ารหัสโดยแตกต่างกัน ซึ่งยังหมายความว่าการเข้ารหัสข้อมูลเดียวกันสองครั้งจะให้ผลลัพธ์เป็น Ciphertext ที่แตกต่างกัน

เหตุใด IV จึงมีความสำคัญ

หากคุณไม่มี IV และใช้โหมด Cipher Block Chaining (CBC) โดยมีเพียงคีย์ของคุณเท่านั้น ข้อมูลสองชุดที่ขึ้นต้นด้วยข้อมูลที่เหมือนกันจะสร้างบล็อคแรกๆ ที่เหมือนกัน IV ทำให้การเข้ารหัสข้อมูลที่แตกต่างกันสองข้อมูลมีแนวโน้มที่จะไม่สร้างคู่อินพุต/เอาท์พุตที่เหมือนกัน (ที่ระดับ Cipher ของบล็อค และใช้คีย์เดียวกัน) แม้ในกรณีที่ข้อมูลหนึ่งมีความสัมพันธ์บางส่วนกับอีกข้อมูลหนึ่ง (รวมถึงแต่ไม่จำกัดเพียง: การขึ้นต้นด้วยบล็อคแรกที่เหมือนกัน)

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

การเข้ารหัสแบบเก็บรักษาในระดับเดียวกัน (Equality Preserving): นี่คือระดับเริ่มต้นของการเข้ารหัสสำหรับตารางทั้งหมด ในระดับนี้ ตารางข้อมูลทั้งตารางจะได้รับหนึ่ง IV ซึ่งหมายความว่า Ciphertext ทั้งบล็อคจะสามารถใช้ในการค้นหาภายในตารางได้ เนื่องจาก IV นั้นเหมือนกันสำหรับตารางทั้งหมดภายในตาราง การค้นหาจึงจะดึงข้อมูลให้กับคุณ

การเข้ารหัสมาตรฐาน: ในระดับนี้ แต่ละรายการข้อมูลจะมี IV ที่ไม่ซ้ำกัน แม้ว่าคุณจะเข้ารหัสตารางทั้งตารางด้วยคีย์เดียว รายการข้อมูลที่เข้ารหัสแต่ละรายการจะสร้าง Ciphertext ที่ไม่ซ้ำกัน นอกจากนี้ เนื่องจาก IV เป็นแบบสุ่มและไม่ซ้ำกันสำหรับข้อมูลแต่ละรายการ คำค้นหาจึงจะไม่ดึงข้อมูลให้กับคุณ ตัวเลือกนี้มีความปลอดภัยมากกว่ารูปแบบ "เก็บรักษาในระดับเดียวกัน"

รูปแบบเหล่านี้จะใช้กับสถานการณ์ใดบ้าง

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

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

การเข้ารหัสไฟล์หรือ DFS

เมื่อคุณใช้บริการต่างๆ เช่น Zoho Docs คุณจะสร้างไฟล์ที่จะถูกจัดเก็บไว้ในระบบไฟล์แบบกระจาย (DFS) ของเรา

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

เช่นเดียวกับในการเข้ารหัสแบบ DB การเข้ารหัสไฟล์ก็มีสองระดับเช่นเดียวกัน:

ระดับที่ 1 - ในระดับนี้ แต่ละองค์กรจะได้รับคีย์ แต่ละไฟล์จากองค์กรนั้นๆ จะถูกเข้ารหัสโดยใช้คีย์นี้ แต่จะมี IV แบบสุ่มที่ไม่ซ้ำกัน ซึ่งถูกจัดเก็บไว้พร้อมกับตัวไฟล์เอง เช่นเคย คีย์นี้จะถูกเข้ารหัสโดยใช้คีย์ต้นแบบและจัดเก็บใน KMS

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

การเข้ารหัส URL

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

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

การเข้ารหัสข้อมูลสำรอง

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

การเข้ารหัสบันทึก

Zoho Logs ใช้ระบบไฟล์แบบกระจาย Hadoop (Hadoop Distributed File System - HDFS) เพื่อจัดเก็บและจัดการบันทึก เราใช้เทคโนโลยีการเข้ารหัสของ Hadoop Inc เพื่อเข้ารหัสข้อมูล ในขณะที่การจัดการคีย์เป็นหน้าที่ของ KMS ของเรา

การเข้ารหัสแคช

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

การจัดการคีย์

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

คีย์ที่ใช้ในระยะต่างๆ ของการเก็บข้อมูลแบ่งออกเป็นหลากหลายประเภท:

คีย์สำหรับเข้ารหัสข้อมูล (Data Encryption Key - DEK): คีย์ที่ใช้เพื่อแปลงข้อมูลจากข้อความธรรมดาเป็นข้อความ Cipher หรือคีย์ที่ใช้เพื่อเข้ารหัสข้อมูล

คีย์สำหรับเข้ารหัสคีย์ (Key Encryption Key - KEK): คีย์ที่ใช้เพื่อเข้ารหัส DEK และมีความเฉพาะเจาะจงต่อบริการ คีย์ชนิดนี้มอบเลเยอร์การรักษาความปลอดภัยเพิ่มเติม

คีย์ต้นแบบ: คีย์ที่ใช้เพื่อเข้ารหัส KEK คีย์นี้จะจัดเก็บไว้ในเซิร์ฟเวอร์แยกต่างหากเพื่อความปลอดภัย

KMS ทำงานอย่างไร

การเข้ารหัสทุกประเภทสอดคล้องตามอัลกอริธึม AES 256 เมื่อยึดตามอัลกอริธึมนี้ ข้อมูลจะถูกจัดการในฐานะ 'บล็อค' ซึ่งต้องถูกเข้ารหัส ไม่ว่าบล็อคนั้นจะเป็นฟิลด์ในฐานข้อมูลหรือไฟล์ใน DFS การเข้ารหัสจะเริ่มต้นเมื่อบล็อคของข้อมูลถูกเข้ารหัสโดยใช้ DEK

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

  • ข้อมูลที่เข้ารหัส
  • DEK
  • DEK ที่เข้ารหัส
  • KEK
  • KEK ที่เข้ารหัส
  • คีย์ต้นแบบ

KMS จะจัดการองค์ประกอบเหล่านี้ในลักษณะดังต่อไปนี้:

kms1

1
เริ่มต้นคำขอ

ผู้ใช้ที่ตรวจรับรองความถูกต้องกับบริการของ Zoho และส่งคำขอข้อมูล

2
การเข้ารหัสในขณะส่ง

การเข้ารหัสตาม TLS

3
ฟรอนต์เอนด์ของแอปพลิเคชัน

ปริมาณข้อมูลโดยตรงที่ส่งไปยังเซิร์ฟเวอร์แอปพลิเคชัน

4
เซิร์ฟเวอร์แอปพลิเคชัน

เริ่มต้นกระบวนการเข้ารหัส

5
บริการการจัดการคีย์

สร้าง/รับคีย์การเข้ารหัสข้อมูล (DEK)

6
เซิร์ฟเวอร์ต้นแบบ

สร้าง/รับการเข้ารหัสคีย์ (KEK)

7
ฐานข้อมูล KMS

จัดเก็บ DEK ที่เข้ารหัส

8
บริการการจัดการคีย์

ส่งกลับ DEK สำหรับการเข้ารหัส

9
เอเจนต์การเข้ารหัส

เข้ารหัสข้อมูลโดยใช้ DEK

10
พื้นที่จัดเก็บ

จัดเก็บข้อมูลที่เข้ารหัส

คีย์ถูกสร้างขึ้นอย่างไร

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

KMS จะสร้างคีย์และ IV เหล่านี้โดยใช้ไลบรารีที่ปลอดภัยของ Java และเครื่องมือสร้างตัวเลขแบบสุ่มที่ปลอดภัย 

คีย์จะถูกจัดเก็บไว้ที่ไหน

DEK ที่สร้างขึ้นใน KMS จะถูกเข้ารหัสโดยใช้ KEK วิธีนี้จะมอบเลเยอร์การรักษาความปลอดภัยเพิ่มเติม DEK ที่เข้ารหัสจะถูกจัดเก็บไว้ในฐานข้อมูล KMS

layers-security

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

สำหรับ Zoho Docs เราจะมอบเลเยอร์การรักษาความปลอดภัยเพิ่มเติมสำหรับเอกสารที่จัดเก็บไว้ขณะไม่มีการใช้งาน

layers-security1

ผู้โจมตีจะไม่สามารถสร้างอันตรายต่อข้อมูลได้ด้วยการมุ่งเป้าหมายไปที่ KMS เพียงอย่างเดียว

คีย์จะได้รับความปลอดภัยแค่ไหน

การแยกในทางกายภาพ - ดังที่ได้อธิบายไปก่อนหน้านี้ คีย์ต้นแบบจะยังคงอยู่ในเซิร์ฟเวอร์ที่แยกจากกันในทางกายภาพและปลอดภัย วิธีนี้จะทำให้ผู้โจมตีสร้างอันตรายต่อทั้ง DEK และ KEK ได้ยาก

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

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

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

มีข้อกำหนดในการทริกเกอร์การหมุนเวียนคีย์ด้วยตนเองสำหรับรับมือกับสถานการณ์วิกฤติที่อาจเกิดขึ้น

ความพร้อมให้บริการของคีย์ - หากการจัดเก็บดิสก์หลักในศูนย์ข้อมูล (DC) หนึ่งๆ ล้มเหลว ยังมีดิสก์ลูกและดิสก์ลูกสำรองไว้อีกด้วย ซึ่งจัดเก็บข้อมูลเช่นเดียวกับ DC ต้นแบบ ทั้งดิสก์ลูกและดิสก์ลูกลำดับที่สองมีการเข้ารหัส DEK เอาไว้ เช่นเดียวกับดิสก์ต้นแบบ

เราเข้ารหัสข้อมูลใดบ้างในบริการของเรา

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

คอลัมน์ตารางต่อไปนี้อธิบายถึงข้อมูลที่เข้ารหัสโดยบริการต่างๆ ของ Zoho:

บริการฟิลด์ที่ถูกเข้ารหัส
CRMฟิลด์ที่กำหนดเองซึ่งมีข้อมูลส่วนตัว, ไฟล์ทั้งหมด
Docsไฟล์ทั้งหมด
Creatorฟิลด์แบบกำหนดเอง
Campaignsฟิลด์ที่มีข้อมูลส่วนตัว, ไฟล์ที่ผู้ใช้อัปโหลด
CliqChatTranscript และข้อมูลส่วนตัว
Peopleฟิลด์ที่กำหนดเอง, ไฟล์ทั้งหมด
Connectชื่อ, URL และเนื้อหาของ - ฟีด, โพสต์ในฟอรั่ม, บทความ, ทาวน์ฮอลล์, กลุ่ม, คำแถลง, งานและความคิดเห็นของงาน, ไฟล์วิดีโอ และไฟล์แนบ
Deskเนื้อหาของเธรดในทิกเก็ต, ไฟล์แนบ และโทเคน
การเงินรายละเอียดบัญชีธนาคาร, ฟิลด์ที่กำหนดเองที่มีข้อมูลส่วนตัว, รายละเอียดพนักงานที่มีข้อมูลส่วนตัว, เอกสารการเดินทาง, ใบแจ้งยอดธนาคาร, ไฟล์แนบ
Projectsไฟล์แนบ, ฟิลด์ที่มีข้อมูลส่วนตัว, โทเคน
Notebookการ์ดบันทึกย่อและไฟล์แนบ
Signเอกสาร, ภาพลายเซ็น และโทเคน
รายงานฟิลด์ที่กำหนดเอง, ไฟล์ที่อัปโหลดโดยผู้ใช้, คำค้นหาที่กำหนดเอง
Mailเนื้อหาเมลทั้งหมด, ไฟล์แนบ และฟิลด์ที่มีข้อมูลส่วนตัว
Recruitฟิลด์ที่กำหนดเอง, เอกสารที่ผู้ใช้นำเข้า
โซเชียลโทเคน, ฟิลด์ที่มีข้อมูลส่วนตัว

การเข้ารหัสทั้งดิสก์

เราใช้ดิสก์ที่เข้ารหัสด้วยตนเอง (Self-Encrypting Drive - SED) เพื่อสนับสนุนการเข้ารหัสทั้งดิสก์โดยยึดฮาร์ดแวร์

SED เป็นไดรฟ์แบบฮาร์ดดิสก์ (Hard Disk Drive - HDD) หรือไดรฟ์แบบโซลิดสเตท (Solid State Drive - SSD) โดยมีวงจรการเข้ารหัสในตัวไดรฟ์ การเข้ารหัสด้วยตนเองมีความหมายอย่างง่ายคือ ข้อมูลทั้งหมดที่เขียนลงในสื่อจัดเก็บจะถูกเข้ารหัสโดยดิสก์ไดรฟ์ ก่อนที่จะถูกเขียนและถอดรหัสโดยดิสก์ไดรฟ์เมื่อมีการอ่านข้อมูล

ไดรฟ์ SED เป็นไดรฟ์ที่สอดคล้องตาม FIPS 140-2 หรือการร้องเรียน TCG อัลกอริธึมการเข้ารหัสที่กำหนดค่าสำหรับ SED คืออัลกอริธึม AES คีย์ที่ใช้สำหรับการเข้ารหัสและถอดรหัสมีความยาว 256

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

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

คีย์สำหรับตรวจรับรองความถูกต้อง - คีย์นี้จะเข้ารหัส DEK และใช้สำหรับการล็อคและปลดล็อคไดรฟ์ คีย์สำหรับการตรวจรับรองความถูกต้องจะถูกสร้างขึ้นด้วยนโยบายที่เคร่งครัด และจะจัดเก็บไว้ในระบบการจัดการคีย์ของเรา คีย์เดียวกันนี้จะถูกส่งไปยังแต่ละเซิร์ฟเวอร์ด้วยวิธีการที่ปลอดภัยเมื่อเราเปิดใช้การเข้ารหัสในเซิร์ฟเวอร์เหล่านั้น เราใช้ระบบจัดการคีย์ภายใน (Local Key Management - LKM ) เพื่อจัดการคีย์การตรวจรับรองความถูกต้อง

หมายเหตุ: ขณะนี้ การเข้ารหัสทั้งดิสก์โดยยึดฮาร์ดแวร์มีผลกับศูนย์ข้อมูลในอินเดีย (IN) เท่านั้น

บทสรุป

เราจะเข้ารหัสข้อมูลลูกค้าที่อ่อนไหวเมื่อข้อมูลดังกล่าวถูกส่งผ่านอินเทอร์เน็ต และในขณะที่ข้อมูลดังกล่าวเดินทางระหว่าง DC ต่างๆ ของเรา อย่างไรก็ตาม การเข้ารหัสเป็นเพียงส่วนหนึ่งของกลยุทธ์การรักษาความปลอดภัยของเรา เราสรรค์สร้างและมุ่งมั่นที่จะเพิ่มประสิทธิภาพการปกป้องข้อมูลอย่างต่อเนื่องด้วยการใช้โปรโตคอลและเทคโนโลยีล่าสุด หากต้องการเรียนรู้เกี่ยวกับกลยุทธ์การรักษาความปลอดภัยทั้งหมดของเรา โปรดเข้าชม https://www.zoho.com/security.html