Panduan Praktis Keamanan Bucket Amazon Simple Storage Service

Banyak organisasi mulai memindahkan penyimpanan berkas aplikasi dari server lokal ke layanan objek di awan karena skalabilitas, durabilitas, dan integrasi ekosistem yang kuat. Salah satu layanan yang paling populer adalah Amazon Simple Storage Service yang biasa disebut Amazon S tiga.
Dalam skenario ini, aplikasi masih berjalan di pusat data atau server on premise, tetapi media penyimpanannya berada di awan. Pola ini membuka banyak manfaat namun juga menambah permukaan serangan jika desain dan konfigurasinya tidak hati hati.

Artikel ini menyajikan panduan praktis dan terstruktur untuk menyiapkan bucket Amazon Simple Storage Service yang aman sebagai media penyimpanan aplikasi on premise. Fokus utama adalah aspek keamanan: desain arsitektur, pengaturan identitas dan hak akses, enkripsi, konektivitas, hingga logging dan pemantauan.
Tujuannya adalah memberikan kerangka pikir yang dapat dijadikan standar internal sebelum tim mengizinkan aplikasi on premise berkomunikasi dengan bucket di awan.

Konsep dasar penggunaan Amazon Simple Storage Service untuk aplikasi on premise

Pada dasarnya, bucket adalah ruang logis untuk menyimpan objek seperti berkas gambar, dokumen, lampiran aplikasi, maupun arsip log. Untuk aplikasi yang berjalan di lingkungan on premise, komunikasi ke bucket dilakukan melalui internet publik atau konektivitas privat seperti kanal privat dan gateway khusus.
Karena rata rata bucket dapat diakses dari internet jika tidak diatur dengan benar, desain keamanan harus mengasumsikan bahwa lalu lintas dari pusat data ke awan berada di jaringan tidak tepercaya.

Beberapa karakteristik penting yang perlu dipahami sebelum mulai membuat bucket:

Bucket bersifat regional, sehingga pemilihan wilayah akan mempengaruhi latensi koneksi dari pusat data dan juga regulasi data.
Secara default, akses diatur menggunakan identitas dan kebijakan pada layanan identitas dan manajemen akses. Bucket tidak memerlukan credential terpisah.
Semua permintaan harus menggunakan saluran terenkripsi melalui protokol aman. Hal ini wajib bagi akses dari on premise.
Fitur seperti versi objek, enkripsi di sisi server, logging dan replikasi dapat diaktifkan per bucket untuk memenuhi kebutuhan ketahanan dan kepatuhan.

Dengan memahami karakteristik ini, tim dapat merancang struktur bucket dan pola penamaan objek yang konsisten dengan modul aplikasi, lingkungan pengembangan, dan domain bisnis yang dilayani.

Prinsip desain keamanan untuk media penyimpanan awan

Sebelum masuk ke langkah teknis, penting untuk menyepakati prinsip desain keamanan yang akan menjadi panduan setiap keputusan konfigurasi. Prinsip prinsip berikut sebaiknya dijadikan kebijakan internal:

Privat secara default: seluruh bucket hanya dapat diakses oleh identitas yang terdefinisi, tidak ada akses publik kecuali ada kebutuhan bisnis yang sangat jelas dan terkontrol.
Hak akses minimum: identitas aplikasi hanya mendapatkan hak yang benar benar diperlukan, misalnya hanya menulis atau membaca pada jalur prefiks tertentu.
Enkripsi menyeluruh: data dienkripsi selama transit dan saat tersimpan di bucket, dengan pengelolaan kunci yang tertib.
Teknologi bukan satu satunya kontrol: kebijakan organisasi, prosedur operasional, dan audit berkala sama pentingnya dengan konfigurasi teknis.
Pemisahan lingkungan: bucket untuk pengembangan, pengujian, dan produksi dipisah, baik dari nama maupun hak aksesnya.

Prinsip ini tampak sederhana, tetapi sering dilanggar demi kepraktisan. Kebiasaan menambahkan akses luas sementara yang kemudian lupa dicabut merupakan pola yang kerap menjadi sumber insiden keamanan.
Oleh karena itu, pipeline otomatis dan template infrastruktur sebagai kode sangat dianjurkan agar konfigurasi keamanan dapat direview, diuji, dan diulang secara konsisten.

Langkah membuat bucket yang aman

Bagian ini membahas urutan langkah yang direkomendasikan ketika membuat bucket baru untuk aplikasi on premise. Contoh bersifat umum sehingga dapat disesuaikan dengan kebijakan internal dan regulasi lokal.

Perencanaan bucket dan skema penamaan

Sebelum membuat bucket, tentukan lebih dulu struktur dan batasannya:

Pilih wilayah pusat data awan yang paling dekat dengan pusat data on premise guna mengurangi latensi.
Bagi bucket per sistem dan per lingkungan, misalnya pemisahan antara pengembangan, pengujian, dan produksi.
Rancang prefiks untuk memisahkan jenis data, misalnya lampiran pengguna, berkas konfigurasi, dan log.
Tentukan kebutuhan retensi dan kebijakan arsip untuk setiap jenis data, karena akan berpengaruh pada konfigurasi masa simpan dan kelas penyimpanan.

Pembuatan bucket dengan konfigurasi dasar

Pembuatan dapat dilakukan melalui konsol, antarmuka baris perintah, atau infrastruktur sebagai kode. Contoh berikut hanya ilustrasi dan tidak boleh dijalankan tanpa penyesuaian penuh terhadap kebijakan organisasi.

Catatan risiko: selalu gunakan akun non produksi dan wilayah uji ketika mencoba perintah berikut. Jangan menggunakan contoh nama bucket dan profil tanpa penyesuaian. Pastikan kredensial tidak tertulis di skrip.

aws s3api create-bucket \
  --bucket contoh-bucket-aplikasi-prod \
  --region ap-southeast-1 \
  --create-bucket-configuration LocationConstraint=ap-southeast-1

Mengaktifkan blokir akses publik

Setelah bucket dibuat, pastikan semua opsi blokir akses publik diaktifkan. Ini menjadi benteng pertama agar tidak ada kebijakan yang secara tidak sengaja mengizinkan akses publik.

aws s3api put-public-access-block \
  --bucket contoh-bucket-aplikasi-prod \
  --public-access-block-configuration \
    "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

Kebijakan internal dapat menetapkan bahwa setiap bucket yang tidak mengaktifkan blokir akses publik dianggap tidak patuh dan harus diperbaiki sebelum dipakai aplikasi.

Mengaktifkan enkripsi di sisi server

Enkripsi di sisi server adalah kontrol wajib. Secara umum terdapat dua pendekatan utama:

Enkripsi menggunakan kunci yang dikelola layanan penyimpanan. Lebih sederhana, beban operasional lebih rendah.
Enkripsi menggunakan kunci yang dikelola layanan manajemen kunci. Memberi kontrol lebih besar, tetapi memerlukan pengelolaan kunci yang baik.

Contoh berikut mengatur enkripsi default menggunakan kunci yang dikelola oleh layanan manajemen kunci. Gantilah nilai kunci dengan pengenal kunci milik organisasi.

aws s3api put-bucket-encryption \
  --bucket contoh-bucket-aplikasi-prod \
  --server-side-encryption-configuration '{
    "Rules": [
      {
        "ApplyServerSideEncryptionByDefault": {
          "SSEAlgorithm": "aws:kms",
          "KMSMasterKeyID": "arn:aws:kms:ap-southeast-1:ID_AKUN:kms-key-id-anda"
        }
      }
    ]
  }'

Mengaktifkan versioning dan logging

Versioning membantu pemulihan jika terjadi penghapusan atau penimpaan objek secara tidak sengaja, sementara logging akses membantu investigasi insiden.
Keduanya sangat direkomendasikan untuk bucket produksi yang melayani aplikasi penting.

aws s3api put-bucket-versioning \
  --bucket contoh-bucket-aplikasi-prod \
  --versioning-configuration Status=Enabled

Untuk logging, umumnya digunakan bucket terpisah yang didedikasikan sebagai tujuan log, dengan hak akses lebih ketat dan masa simpan lebih panjang.

Menetapkan kebijakan masa simpan dan kelas penyimpanan

Agar biaya terkendali, gunakan fitur kebijakan masa simpan. Misalnya, objek log dipindahkan ke kelas penyimpanan arsip setelah beberapa bulan dan dihapus setelah masa retensi berakhir.
Kebijakan ini harus disejajarkan dengan kebijakan retensi data internal dan regulasi eksternal.

Pola akses aman dari aplikasi on premise

Setelah bucket siap, tantangan berikutnya adalah bagaimana aplikasi di pusat data mengakses bucket secara aman. Pada prinsipnya, terdapat dua pendekatan besar:
menggunakan internet publik dengan pengamanan ketat atau menggunakan konektivitas privat.

Akses melalui internet dengan pengamanan berlapis

Banyak organisasi memulai dengan akses melalui internet publik yang diamankan. Untuk pola ini, beberapa hal yang wajib diperhatikan:

Gunakan hanya protokol aman dan pastikan semua klien memverifikasi sertifikat.
Batasi koneksi keluar dari pusat data ke daftar tujuan tertentu, misalnya nama domain atau alamat tujuan resmi.
Keelola kredensial di sisi server menggunakan mekanisme variabel lingkungan, manajer rahasia, atau layanan serupa, bukan menuliskannya dalam berkas kode.

Pada banyak kasus, pola ini cukup aman jika dikombinasikan dengan kebijakan identitas dan manajemen akses yang ketat serta pemantauan berkelanjutan atas pola akses.

Konektivitas privat melalui kanal khusus

Untuk sistem dengan kebutuhan keamanan dan kepatuhan yang lebih tinggi, konektivitas privat menjadi pilihan. Dengan kanal privat, lalu lintas antara pusat data dan awan tidak lagi melewati internet publik, sehingga risiko tertentu dapat dikurangi.
Namun, perlu diingat bahwa penguatan pada lapisan jaringan tidak menggantikan kebutuhan akan pengamanan pada lapisan identitas dan aplikasi.

Pola presigned url untuk klien eksternal

Jika pengguna akhir mengunggah atau mengunduh berkas secara langsung dari perangkat masing masing, memaksa semua lalu lintas melewati aplikasi on premise bisa menjadi sempitnya jalur.
Salah satu pola yang umum adalah menggunakan tautan bertanda tangan yang masa berlakunya terbatas. Aplikasi akan meminta layanan awan untuk menghasilkan tautan khusus dan mengirimkannya ke klien.
Dengan demikian, klien dapat berkomunikasi langsung dengan bucket tanpa menyimpan kredensial apa pun di sisi klien.

Pengelolaan identitas dan kredensial bagi aplikasi

Salah satu sumber risiko terbesar dalam integrasi on premise dengan layanan awan adalah pencurian atau kebocoran kredensial. Oleh karena itu, desain identitas dan kebijakan akses perlu menjadi prioritas.

Gunakan peran identitas khusus aplikasi, terpisah untuk setiap lingkungan seperti pengembangan, pengujian, dan produksi.
Batasi akses hanya pada bucket dan prefiks yang benar benar diperlukan.
Gunakan metode rotasi kunci secara berkala dan otomatis apabila memungkinkan.
Simpan kunci dan rahasia pada manajer rahasia, bukan pada variabel lingkungan statik yang tertulis dalam skrip.

Untuk aplikasi yang berjalan pada mesin virtual atau kontainer di awan, dianjurkan menggunakan mekanisme kredensial turunan peran sehingga tidak ada kunci jangka panjang yang disimpan.
Pada beban kerja murni on premise, biasanya masih dibutuhkan sepasang kunci akses, sehingga perlakuan terhadap berkas konfigurasi dan pipeline harus mengikuti standar keamanan tinggi.

Peringatan keamanan kode: jangan pernah menuliskan pengenal akses dan rahasia asli di dalam kode sumber, repositori, artikel, atau bahan pelatihan. Selalu gunakan placeholder generik seperti contoh berikut.

[default]
aws_access_key_id=YOUR_AWS_ACCESS_KEY_ID
aws_secret_access_key=YOUR_AWS_SECRET_ACCESS_KEY
region=ap-southeast-1

Contoh bucket policy dan kebijakan minimal

Bagian ini memberikan contoh kebijakan yang dapat dijadikan titik awal. Semua contoh harus ditinjau oleh tim keamanan dan kepatuhan sebelum digunakan di lingkungan nyata.

Contoh bucket policy yang hanya mengizinkan peran tertentu

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSpecificRoleAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ID_AKUN:role/PeranAplikasiProd"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::contoh-bucket-aplikasi-prod/prefix-aplikasi/*"
    }
  ]
}

Contoh kebijakan identitas minimal untuk aplikasi

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowListBucketOnPrefix",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::contoh-bucket-aplikasi-prod",
      "Condition": {
        "StringLike": {
          "s3:prefix": "prefix-aplikasi/*"
        }
      }
    },
    {
      "Sid": "AllowReadWriteOnPrefix",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::contoh-bucket-aplikasi-prod/prefix-aplikasi/*"
    }
  ]
}

Dengan pola ini, aplikasi hanya dapat bekerja di jalur yang memang disediakan untuknya. Pola lain dapat menambahkan kondisi berdasarkan sumber permintaan atau parameter lain sesuai kebutuhan.

Checklist keamanan sebelum produksi

Sebelum bucket dihubungkan ke aplikasi on premise di lingkungan produksi, gunakan checklist sederhana namun tegas berikut untuk menilai kesiapan:

Blokir akses publik telah aktif sepenuhnya untuk bucket yang bersangkutan.
Enkripsi di sisi server telah diaktifkan dan kebijakan pengelolaan kunci sudah disepakati antar tim.
Kebijakan identitas dan bucket sudah menerapkan hak minimum, tidak ada tindakan dengan cakupan terlalu luas tanpa alasan kuat.
Versioning dan logging diaktifkan atau diputuskan secara sadar dengan alasan terdokumentasi.
Pola koneksi dari pusat data sudah melewati perangkat keamanan jaringan dan pemantauan yang disetujui.
Kredensial aplikasi dikelola dengan mekanisme yang sesuai standar keamanan internal dan tidak disimpan di repositori kode.
Proses insiden dan audit akses terhadap bucket terdokumentasi dan telah disosialisasikan ke tim operasi.

Checklist dapat dikembangkan menjadi kontrol dalam sistem manajemen keamanan informasi yang lebih luas, sehingga setiap bucket baru dievaluasi dengan cara yang konsisten.

Kesimpulan

Menggunakan bucket layanan penyimpanan objek sebagai media penyimpanan untuk aplikasi on premise adalah langkah strategis yang dapat meningkatkan skalabilitas dan ketahanan data. Namun, tanpa desain dan konfigurasi keamanan yang matang, integrasi ini justru berpotensi menambah risiko baru.
Kunci suksesnya terletak pada penerapan prinsip privat secara default, hak akses minimum, enkripsi menyeluruh, serta pemisahan yang jelas antar lingkungan.

Panduan ini menekankan pentingnya dimulai dari perencanaan yang rapi, dilanjutkan dengan pembuatan bucket yang mengikuti standar keamanan, diikuti pengelolaan identitas dan kredensial yang disiplin.
Dengan memanfaatkan fitur seperti blokir akses publik, enkripsi, versioning, logging, kebijakan masa simpan, serta pola koneksi yang aman dari pusat data, organisasi dapat memperoleh manfaat penuh dari layanan penyimpanan objek tanpa mengorbankan kontrol dan kepatuhan.

Pada akhirnya, keamanan bukan hanya tugas tim infrastruktur atau keamanan informasi. Desainer aplikasi, pengembang, dan manajemen harus memandang bucket di awan sebagai bagian dari arsitektur sistem secara keseluruhan.
Ketika semua pihak memahami prinsip dasar dan checklist yang sama, keputusan sehari hari yang diambil tim akan lebih konsisten dengan tujuan keamanan jangka panjang organisasi.

Sumber dan referensi

https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html
https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-overview.html
https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html
https://docs.aws.amazon.com/wellarchitected/latest/storage-lens-lens/well-architected-storage-lens.html
https://aws.amazon.com/architecture/security-identity-compliance/