สิ่งที่คุณคงไม่อยากรู้เกี่ยวกับ S3

 (blog.plerion.com)
2 คะแนน โดย GN⁺ 2024-06-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

การเข้ารหัสบัคเก็ต AWS S3 ไม่ได้ง่ายอย่างที่คิด

ตัวเลือกการเข้ารหัสของ S3

  • การเข้ารหัสฝั่งเซิร์ฟเวอร์ (SSE-S3): ใช้คีย์ที่ AWS จัดการเพื่อเข้ารหัสข้อมูล
  • การเข้ารหัสฝั่งเซิร์ฟเวอร์ (SSE-KMS): ใช้ AWS Key Management Service (KMS) เพื่อเข้ารหัสข้อมูล
  • การเข้ารหัสฝั่งเซิร์ฟเวอร์ (SSE-C): ใช้คีย์ที่ผู้ใช้จัดเตรียมเองเพื่อเข้ารหัสข้อมูล
  • การเข้ารหัสฝั่งไคลเอนต์: ผู้ใช้เข้ารหัสข้อมูลด้วยตนเองก่อนอัปโหลด

ความแตกต่างระหว่างการเข้ารหัสกับการควบคุมการเข้าถึง

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

ทำไมเรื่องนี้จึงสำคัญ

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

ความเห็นของ GN⁺

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-06-02
ความคิดเห็นจาก Hacker News
  • ไม่เห็นด้วยกับการบ่นว่า file system แยกตัวพิมพ์เล็ก-ใหญ่เป็นปัญหา เพราะมันเป็นเรื่องปกติอยู่แล้ว และสิ่งที่น่ารำคาญคือ macOS ไม่รองรับสิ่งนี้
  • พาธของ S3 เป็นเพียงการจำลอง ไม่ใช่ไดเรกทอรีจริง ตัวอย่างเช่น /builds/1/installer.exe ที่จริงแล้วคือไฟล์ที่มี / อยู่ในชื่อ
  • การใช้ S3 หรือบริการอื่นของ AWS มีความซับซ้อนและเอกสารมีจำนวนมากจนทำให้เผลอเปิดเผยข้อมูลได้ จึงชอบบริการที่เรียบง่ายกว่าอย่าง Hetzner Storage Boxes หรือ DigitalOcean Spaces
  • การลบอ็อบเจ็กต์หลายพันล้านรายการอาจมีค่าใช้จ่ายสูง แต่ถ้าตั้งค่า wildcard หรือกำหนดเวลาให้วัตถุทั้งบักเก็ตหมดอายุ ก็สามารถหยุดค่าบริการจัดเก็บได้ทันทีโดยไม่เสียค่าใช้จ่าย
  • multipart upload ที่ล้มเหลวอาจค้างอยู่แบบมองไม่เห็นและก่อให้เกิดค่าใช้จ่ายด้าน storage ได้ ทำให้ชื่อ "Simple" ของ S3 ดูไม่ตรงนัก
  • multipart upload ไม่สามารถทำข้ามหลายเครื่องได้ และคำขอ LIST ก็ช้าและมีค่าใช้จ่ายสูง การสร้างบักเก็ตอาจไม่มีความสม่ำเสมอ
  • S3 แยกตัวพิมพ์เล็ก-ใหญ่ ซึ่งอาจเป็นปัญหาเมื่อแปลงไปเป็นโครงสร้าง file system
  • การตั้งค่า S3 ส่วนใหญ่อนุญาตคำขอ GET แต่ไม่อนุญาต HEAD ทำให้โฟลว์ที่อาศัย cache อาจใช้งานไม่ได้
  • หากใช้ pre-signed URL จำนวนมาก สามารถปรับให้การสร้าง URL เร็วขึ้นได้ตั้งแต่ 10 ถึง 40 เท่า
  • ต้องจ่ายค่าจัดเก็บสำหรับ multipart upload ที่ยังไม่เสร็จ จึงควรเปิดการตั้งค่าลบอัตโนมัติ
  • การถกเถียงเรื่องการแยกตัวพิมพ์เล็ก-ใหญ่มีมุมมองที่ยึดภาษาอังกฤษเป็นศูนย์กลางมากเกินไป
  • S3 จะเพิกเฉยต่อทุกคำขอแบบเงียบ ๆ หลังจากการเชื่อมต่อ TCP เดียวส่ง HTTP request ไปแล้ว 100 รายการ
  • เว็บไซต์ที่ตั้งค่าผิดอาจอัปโหลดเนื้อหาของผู้ใช้ไปยัง Amazon Glacier และค่อยนำมาให้บริการภายหลัง
  • S3 ไม่เหมาะกับการเสิร์ฟเว็บเพราะมี latency สูง โดย latency ที่สม่ำเสมอของอ็อบเจ็กต์ขนาดเล็กอยู่ที่ 100-200 มิลลิวินาที