Keamanan cloud dan infrastruktur: siapa mengurus apa?

Apakah memakai cloud berarti keamanan sudah diurus penyedia?

Sebagian pekerjaan diurus penyedia, sebagian tetap perlu dikerjakan pelanggan. Batasnya bergantung pada layanan dan kontrak. Jangan menyamakan sewa server virtual, platform aplikasi terkelola, dan aplikasi SaaS yang langsung dipakai.

Istilah shared responsibility berarti pembagian tanggung jawab tersebut. Pernyataan “cloud sudah bersertifikat” belum menjelaskan siapa yang mengatur akun, membuka akses penyimpanan, membuat cadangan, atau merespons insiden pada aplikasi Anda.

Gambaran umum tiga jenis layanan. Pastikan batas sebenarnya dalam layanan dan kontrak yang Anda gunakan.

Server sewaan · IaaS

Penyedia

Mengelola infrastruktur fisik.

Pelanggan

Mengelola sistem operasi, aplikasi, dan akses datanya, kecuali disepakati lain.

Platform aplikasi · PaaS

Penyedia

Mengelola platform tempat aplikasi berjalan.

Pelanggan

Mengelola kode aplikasi, izin pengguna, dan konfigurasi yang tersedia.

Aplikasi siap pakai · SaaS

Penyedia

Mengoperasikan aplikasi beserta platformnya.

Pelanggan

Mengatur pengguna, penggunaan data, dan integrasi yang diaktifkan.

Label layanan bukan bukti bahwa tugas sudah dikerjakan. Tuliskan penanggung jawab serta bukti untuk akses, pembaruan, backup, dan insiden pada matriks di bawah.

Rujukan: OWASP Secure Cloud Architecture, Shared Responsibility Model.

Buat matriks untuk layanan yang benar-benar dipakai

Contoh fiktif: tim menyewa server aplikasi, database terkelola, dan penyimpanan berkas. Tabel berikut adalah pertanyaan serah terima, bukan pembagian baku untuk semua penyedia.

Pekerjaan	Pertanyaan dan bukti yang disimpan
Pembaruan sistem operasi	Server mana diurus tim atau penyedia? Simpan batas layanan, jadwal, dan catatan pembaruan.
Izin database	Siapa membuat akun aplikasi dan mencabut akses admin? Simpan daftar peran dan hasil pemeriksaan akses.
Penyimpanan berkas	Berkas mana memang publik dan mana terbatas? Simpan keputusan pemilik data dan hasil pemeriksaan akses.
Cadangan	Siapa membuat, menjaga, dan menguji pemulihan? Simpan kebijakan layanan dan hasil restore tim.
Log dan insiden	Siapa menerima peringatan dan boleh membatasi layanan? Simpan kontak, prosedur eskalasi, dan catatan latihan.
Akhir kontrak	Bagaimana data diekspor, akses dicabut, dan salinan ditangani? Simpan rencana keluar dan tanggung jawab setiap pihak.

Isi nama penanggung jawab, bukan hanya “tim IT” atau “vendor”. Bagian yang belum dijawab adalah pekerjaan terbuka sebelum layanan dipakai untuk data penting.

Apa yang diperiksa pada storage dan database?

Object storage menyimpan berkas sebagai objek. Bedakan berkas yang memang boleh dibuka umum dari dokumen pelanggan. Periksa izin pada akun, layanan, objek, dan jalur unduhan yang dipakai aplikasi.

Untuk database, tanyakan siapa yang bisa terhubung, dari lingkungan mana, dan dengan hak apa. Hindari akses yang dibuka luas hanya agar pemasangan awal lebih cepat. Gunakan data fiktif untuk membuktikan akses yang diizinkan serta yang seharusnya ditolak.

Enkripsi dan jaringan privat membantu menjawab risiko yang berbeda. Keduanya tidak menggantikan pemeriksaan hak pengguna pada aplikasi. Lihat enkripsi, kunci, dan salinan data.

Apa yang dimaksud hardening server?

Hardening adalah pengurangan bagian dan akses yang tidak diperlukan, disertai konfigurasi pengamanan yang sesuai. Dalam catatan kerja, ubah istilah umum ini menjadi tugas nyata: layanan yang digunakan, akun admin, pembaruan, koneksi yang diizinkan, log, dan cara pemulihan.

Minta tim membandingkan konfigurasi yang disetujui dengan keadaan yang berjalan. Simpan alasan pengecualian dan penanggung jawabnya. Panduan ini tidak memberikan perintah konfigurasi universal; perubahan perlu diuji terhadap sistem operasi dan beban kerja yang dipakai.

Bagaimana dengan container dan Kubernetes?

Container mengemas aplikasi beserta kebutuhan menjalankannya. Kubernetes mengatur beban kerja container. Teknologi ini tidak menghapus pekerjaan pengamanan aplikasi atau host.

Dokumentasi proyek Kubernetes mengarahkan pemeriksaan pada akses API, jaringan, hak beban kerja, secret, serta asal dan pembaruan image. Tentukan siapa mengurus setiap lapisan, termasuk ketika control plane dikelola penyedia. Jangan menganggap nama lingkungan atau namespace saja sudah membuktikan pemisahan.

Untuk rapat kesiapan, minta daftar image yang dirilis, penanggung jawab pembaruan, hak akun layanan, batas koneksi, serta bukti bahwa aplikasi uji tidak dapat mengakses data produksi tanpa izin. Konfigurasi rinci perlu mengikuti versi dan arsitektur yang digunakan.

Latihan: siapa yang perlu mengerjakan ini?

Dalam contoh fiktif ini, bisnis memakai server sewaan dan aplikasi dokumen SaaS. Gunakan kontrak layanan Anda untuk menentukan pembagian yang sebenarnya.

Sistem operasi server sewaan perlu diperbarui. Siapa yang mengerjakannya?

Periksa apakah paketnya mencakup pengelolaan sistem operasi. Pada server yang dikelola sendiri, tim pelanggan perlu mengurusnya. Jika pekerjaan diserahkan kepada vendor, catat nama petugas, batas layanan, dan bukti pembaruan; jangan hanya mengandalkan sebutan “cloud”.

Pegawai keluar dari perusahaan. Apakah penyedia aplikasi otomatis mencabut aksesnya?

Jangan menganggap demikian. Tim perlu menjalankan proses pencabutan akses dan memeriksa hasilnya, termasuk akun serta integrasi terkait. Bila ada otomatisasi dari sistem HR atau akun kantor, pastikan layanan tersebut benar-benar tercakup.

Penyedia menyebut backup tersedia. Apakah bisnis sudah siap menghadapi kehilangan data?

Belum terbukti. Tanyakan data yang dicadangkan, masa simpan, cara meminta pemulihan, biaya, dan siapa yang menguji hasilnya. Cocokkan dengan kebutuhan bisnis; layanan backup penyedia belum tentu mencakup semua konfigurasi atau data aplikasi Anda.

Apa yang diperiksa sebelum serah terima?

Tinjau akses manusia dan otomatis, perbedaan lingkungan, cadangan, pemulihan, serta biaya dan batas layanan. Pastikan tim dapat menjalankan langkah yang menjadi tanggung jawabnya, termasuk saat kontak utama tidak tersedia.

Lokasi cloud juga tidak menjawab seluruh persoalan pemindahan data. Jika ada penyimpanan atau akses dari luar Indonesia, gunakan panduan transfer data pribadi untuk penilaian terpisah. Untuk kelangsungan layanan, hubungkan matriks ini dengan BCP dan DRP.

Pahami risiko di balik pemeriksaan

Baca Security Misconfiguration untuk memahami konsep dan contoh kegagalannya. Gunakan langkah di halaman ini untuk pekerjaan penerapan.

Langkah penerapan berikutnya

Lanjutkan pemeriksaan per komponen: izin object storage, koneksi dan akun database, container serta image, dan perubahan infrastructure as code. Gunakan komponen yang memang ada dalam arsitektur Anda; tidak setiap layanan memerlukan semuanya.