Hal-hal tentang S3 yang Semoga Tak Perlu Anda Ketahui

 (blog.plerion.com)
2 poin oleh GN⁺ 2024-06-02 | 1 komentar | Bagikan ke WhatsApp

Enkripsi bucket AWS S3 tidak sesederhana yang dibayangkan

Opsi enkripsi S3

  • Enkripsi sisi server (SSE-S3): Mengenkripsi data menggunakan kunci yang dikelola AWS.
  • Enkripsi sisi server (SSE-KMS): Mengenkripsi data menggunakan AWS Key Management Service (KMS).
  • Enkripsi sisi server (SSE-C): Mengenkripsi data menggunakan kunci yang disediakan pengguna.
  • Enkripsi sisi klien: Pengguna mengenkripsi data sendiri sebelum mengunggahnya.

Perbedaan antara enkripsi dan kontrol akses

  • Enkripsi: Proses mengubah data untuk melindunginya.
  • Kontrol akses: Kebijakan yang menentukan siapa yang dapat mengakses data.
  • Enkripsi S3 pada praktiknya lebih dekat ke kontrol akses, dan lebih berfokus pada pengelolaan izin akses daripada perlindungan data.

Mengapa ini penting

  • Keamanan: Enkripsi dapat melindungi data bahkan saat terjadi kebocoran data.
  • Kepatuhan: Enkripsi mungkin diperlukan untuk memenuhi regulasi industri tertentu atau persyaratan hukum.
  • Integritas data: Enkripsi memastikan bahwa data tidak diubah secara semena-mena.

Opini GN⁺

  • Kebingungan antara enkripsi dan kontrol akses: Banyak orang mencampuradukkan enkripsi dan kontrol akses. Artikel ini menjelaskan perbedaannya dengan jelas.
  • Tingkat keamanan yang sebenarnya: Diperlukan sudut pandang yang kritis terhadap seberapa aman sebenarnya opsi enkripsi S3.
  • Teknologi alternatif: Selain S3, layanan penyimpanan cloud lain seperti Google Cloud Storage atau Azure Blob Storage juga layak dipertimbangkan.
  • Edukasi pengguna: Penting untuk membuat engineer pemula memahami dengan jelas perbedaan antara enkripsi dan kontrol akses.
  • Hal yang perlu dipertimbangkan saat mengadopsi teknologi: Saat mengadopsi teknologi enkripsi, faktor seperti penurunan performa dan kenaikan biaya perlu dipertimbangkan.

Bacaan terkait

1 komentar

 
GN⁺ 2024-06-02
Komentar Hacker News
  • Tidak setuju dengan keluhan tentang sistem file yang peka huruf besar/kecil. Itu hal yang wajar, dan justru macOS yang tidak mendukungnya terasa merepotkan.
  • Path S3 adalah simulasi, bukan direktori sungguhan. Misalnya, /builds/1/installer.exe sebenarnya adalah file dengan nama yang mengandung /.
  • Menggunakan S3 atau layanan AWS lain itu rumit dan dokumentasinya sangat banyak, sehingga data bisa terekspos karena kesalahan. Lebih menyukai layanan yang lebih sederhana seperti Hetzner Storage Boxes atau DigitalOcean Spaces.
  • Menghapus puluhan miliar objek bisa sangat mahal. Namun, dengan wildcard atau mengatur waktu kedaluwarsa objek untuk seluruh bucket, biaya penyimpanan bisa dihentikan secara gratis dan segera.
  • Upload multipart yang gagal bisa tertinggal tanpa terlihat dan tetap menimbulkan biaya penyimpanan. Nama 'Simple' di S3 jadi terasa tidak cocok.
  • Upload multipart tidak bisa dilakukan dari beberapa mesin, dan permintaan LIST lambat serta mahal. Pembuatan bucket juga bisa tidak konsisten.
  • S3 peka huruf besar/kecil, dan ini bisa menimbulkan masalah saat diubah menjadi struktur sistem file.
  • Sebagian besar konfigurasi S3 mengizinkan permintaan GET, tetapi tidak mengizinkan permintaan HEAD. Alur yang memanfaatkan cache bisa jadi tidak berjalan.
  • Jika sering menggunakan URL pra-tanda tangan, kecepatan pembuatan URL bisa ditingkatkan 10 hingga 40 kali lipat.
  • Biaya penyimpanan tetap dikenakan untuk upload multipart yang belum selesai. Pengaturan penghapusan otomatis perlu diaktifkan.
  • Pembahasan soal peka huruf besar/kecil terlalu berpusat pada bahasa Inggris.
  • S3 akan diam-diam mengabaikan semua permintaan setelah satu koneksi TCP tunggal mengirim 100 permintaan HTTP.
  • Situs web yang salah konfigurasi bisa mengunggah konten pengguna ke Amazon Glacier lalu menyajikannya nanti.
  • S3 tidak cocok untuk web serving karena latensinya tinggi. Latensi yang konsisten untuk objek kecil berada di kisaran 100-200 milidetik.