ระบบ Certificate Transparency (CT) logs ซึ่งช่วยรักษาความปลอดภัยของเว็บโดยการติดตามใบรับรอง SSL ทั้งหมดที่ออกโดยหน่วยงานรับรอง ได้กลายเป็นระบบที่มีค่าใช้จ่ายและความยุ่งยากในการดำเนินงานลดลงอย่างมาก เทคโนโลยีใหม่ที่เรียกว่า Static CT API ได้ลดค่าใช้จ่ายในการดำเนินงานจากกว่า 100,000 ดอลลาร์สหรัฐฯ ต่อปี เหลือประมาณ 10,000 ดอลลาร์สหรัฐฯ ต่อปี ทำให้เกิดการอภิปรายในชุมชนว่าองค์กรต่างๆ ควรจะเข้ามาดำเนินการบริการสำคัญเหล่านี้มากขึ้นหรือไม่
การเปรียบเทียบต้นทุน
- การดำเนินงาน CT Log แบบดั้งเดิม: มากกว่า 100,000 ดอลลาร์สหรัฐต่อปี
- Static CT API ใหม่: ประมาณ 10,000 ดอลลาร์สหรัฐต่อปี (รวมฮาร์ดแวร์ การจัดหาสถานที่ และค่าแบนด์วิธ)
- ประมาณการค่าแบนด์วิธ CDN: มากกว่า 60,000 ดอลลาร์สหรัฐต่อปีสำหรับผู้ให้บริการรายใหญ่
 |
|---|
| ดวงอาทิตย์เป็นสัญลักษณ์ของความก้าวหน้าที่ให้ความกระจ่างใน Certificate Transparency logs ทำให้ความปลอดภัยทางเว็บเข้าถึงได้ง่ายขึ้น |
ความต้องการ Bandwidth ก่อให้เกิดการถกเถียง
ชุมชนกำลังอภิปรายกันอย่างกระตือรือร้นว่าความต้องการ bandwidth ขาออก 2-3 Gbps ที่ระบุไว้นั้นสมจริงสำหรับผู้ดำเนินการรายเล็กหรือไม่ ผู้ใช้หลายคนตั้งคำถามกับตัวเลขนี้ โดยมีคนหนึ่งคำนวณว่าแม้จะมีการออกใบรับรองทุกวัน ปริมาณการใช้งานควรจะต่ำกว่านี้มาก ผู้เขียนได้ชี้แจงว่า bandwidth นี้ส่วนใหญ่ใช้สำหรับการอ่านข้อมูลจากบริการตรวจสอบ ไม่ใช่การส่งใบรับรองใหม่ ดังที่ผู้แสดงความเห็นคนหนึ่งกล่าวไว้ว่า ความต้องการนี้ทำให้บริการค่อนข้างเข้าไม่ถึงเว้นแต่จะโอนภาระส่วนใหญ่นี้ไปยัง CloudFront/CloudFlare ซึ่งอาจส่งผลให้เกิดค่าใช้จ่ายรายเดือน 60,000 ดอลลาร์สหรัฐฯ หรือมากกว่าสำหรับ bandwidth เพียงอย่างเดียว
การอภิปรายเรื่อง bandwidth เผยให้เห็นความท้าทายสำคัญ: แม้ว่าเทคโนโลยีใหม่จะลดความซับซ้อนและความต้องการเซิร์ฟเวอร์ลงอย่างมาก แต่ค่าใช้จ่ายเครือข่ายยังคงเป็นอุปสรรคสำคัญสำหรับผู้ดำเนินการรายบุคคลหรือองค์กรเล็กๆ ที่ต้องการมีส่วนร่วมในโครงสร้างพื้นฐานความปลอดภัยของเว็บ
ข้อกำหนดทางเทคนิคสำหรับการรัน CT Log
- เซิร์ฟเวอร์: เซิร์ฟเวอร์อย่างน้อย 1 เครื่อง (ใช้งานได้ 99% ในช่วง 3 เดือน)
- CPU/หน่วยความจำ: 4 cores, RAM 2GB (ต้องใช้หน่วยความจำ ECC)
- แบนด์วิดท์: 2-3 Gbps ขาออก
- ตัวเลือกพื้นที่จัดเก็บข้อมูล:
- พื้นที่ระบบไฟล์ SSD แบบสำรอง 3-5 TB หรือ
- พื้นที่จัดเก็บข้อมูลแบบ S3-compatible object storage 3-5 TB + SSD cache 200GB
- บุคลากร: ต้องมีผู้ติดต่ออย่างน้อย 2 คน
สถาปัตยกรรมการจัดเก็บข้อมูลสร้างความสนใจด้านเทคนิค
สมาชิกชุมชนตื่นเต้นเป็นพิเศษกับแนวทางการจัดเก็บข้อมูลใหม่ที่ทำให้ CT logs ทำงานกับไฟล์แบบคงที่ได้ การออกแบบนี้ช่วยให้ผู้ดำเนินการสามารถให้บริการ logs โดยตรงจาก object storage เช่น Amazon S3 หรือผ่าน content delivery networks แทนที่จะต้องใช้ระบบฐานข้อมูลที่ซับซ้อน การเปลี่ยนแปลงนี้แก้ไขข้อร้องเรียนก่อนหน้านี้เกี่ยวกับการใช้งาน CT แบบดั้งเดิมที่ซับซ้อนเกินไปเนื่องจากความปรารถนาที่ผิดที่ในการมี write availability สูง
การอภิปรายด้านเทคนิคยังสำรวจโมเดลการจัดเก็บข้อมูลทางเลือกอื่นๆ โดยบางคนแนะนำว่า Certificate Authorities เองควรจัดการความรับผิดชอบในการจัดเก็บข้อมูลมากขึ้น แทนที่จะพึ่งพาผู้ดำเนินการ log บุคคลที่สาม อย่างไรก็ตาม คนอื่นๆ ชี้ให้เห็นว่าการจัดเก็บข้อมูลแบบอิสระเป็นสิ่งจำเป็นสำหรับโมเดลความปลอดภัย เนื่องจากจุดประสงค์ทั้งหมดคือการป้องกันไม่ให้ฝ่ายใดฝ่ายหนึ่งสามารถลบหรือแก้ไขบันทึกใบรับรองได้
ความกังวลของชุมชนเกี่ยวกับการรวมศูนย์
แม้จะยินดีกับการลดลงของค่าใช้จ่าย แต่สมาชิกชุมชนบางคนกังวลเกี่ยวกับผลกระทบในทางปฏิบัติของความต้องการ bandwidth ความต้องการเครือข่ายสูงหมายความว่าในทางปฏิบัติ มีเพียงองค์กรที่มีโครงสร้างพื้นฐาน bandwidth สูงอยู่แล้วหรือผู้ที่เต็มใจจ่ายค่าโฮสติ้งคลาวด์จำนวนมากเท่านั้นที่สามารถเข้าร่วมได้ สิ่งนี้อาจจำกัดความหลากหลายของผู้ดำเนินการ log ที่ระบบต้องการอย่างยิ่ง
การอภิปรายยังได้สัมผัสคำถามที่กว้างขึ้นเกี่ยวกับโครงสร้างพื้นฐานความปลอดภัยของเว็บ โดยบางคนสนับสนุนแนวทางทางเลือกเช่น DANE (DNS-based Authentication of Named Entities) ที่สามารถลดการพึ่งพา Certificate Authorities แบบรวมศูนย์ได้โดยสิ้นเชิง อย่างไรก็ตาม คนอื่นๆ สังเกตว่าทางเลือกดังกล่าวเผชิญกับความท้าทายในการนำไปใช้ของตัวเอง
Static CT API ใหม่แสดงถึงก้าวสำคัญไปข้างหน้าในการทำให้โครงสร้างพื้นฐานความปลอดภัยของเว็บที่สำคัญเข้าถึงได้มากขึ้น แม้ว่าอุปสรรคในทางปฏิบัติเช่นค่าใช้จ่าย bandwidth จะยังคงจำกัดว่าใครสามารถมีส่วนร่วมในการปกป้องระบบนิเวศอินเทอร์เน็ตที่กว้างขึ้น