Mulai dengan persyaratan operasional
Sebelum membandingkan konfigurasi, kumpulkan stack aplikasi, database, unggahan, tugas terjadwal, integrasi, dan perubahan yang diharapkan dari setiap proyek. Identifikasi siapa yang memerlukan akses konten, akses deployment, dan administrasi host. Ini adalah pekerjaan yang berbeda. Klien yang mengedit halaman mungkin hanya memerlukan akun aplikasi; kontraktor yang memelihara sistem operasi memerlukan otoritas yang jauh lebih luas.
Catat juga jendela pemeliharaan yang dapat diterima, siapa yang menyetujui downtime, di mana salinan pemulihan disimpan, dan siapa yang membayar pekerjaan operasional. Catat persyaratan klien untuk server atau akun terpisah sebagai batasan keputusan. Spreadsheet sumber daya tidak dapat menyelesaikan persyaratan kepemilikan atau akses.
- Sebutkan operator utama dan pengganti untuk setiap proyek.
- Cantumkan dependensi bersama: akses DNS, kredensial deployment, layanan database, dan tujuan cadangan.
- Tandai persyaratan yang belum diketahui untuk keputusan klien sebelum menyetujui pengaturan tersebut.
Pilih batas akses sebelum ukuran server
OWASP merekomendasikan pemberian hanya izin yang diperlukan untuk pekerjaan seseorang dan memvalidasi bahwa pembatasan yang dimaksudkan tetap berlaku. Terapkan prinsip itu pada paket hosting: gunakan identitas individual, kredensial aplikasi khusus proyek, dan jalur deployment yang didokumentasikan. Direktori yang dinamai berdasarkan klien adalah alat bantu organisasi, bukan kebijakan akses.
Jika menggunakan Docker, perlakukan akses ke daemon-nya sebagai tanggung jawab tingkat host. Dokumentasi keamanan Docker menjelaskan bahwa operator daemon yang tepercaya dapat me-mount dan memodifikasi file host. Memberikan kontrol Docker tanpa batas kepada kontraktor eksternal karena itu tidak cocok untuk host yang berisi data klien lain yang tidak terkait.
Instans VPS terpisah memungkinkan administrasi sistem operasi dan keputusan rilis yang terpisah. Mereka tetap memerlukan izin yang hati-hati di dalam setiap proyek. Kredensial agensi bersama atau akun deployment bersama dapat menyatukan kembali risiko yang ingin Anda pisahkan.
Kerjakan dua brief klien fiktif
Klien di bawah ini adalah contoh fiktif, bukan riwayat pelanggan. Agensi mengoperasikan kedua proyek saat ini, tetapi persyaratan akses dan waktu mereka berbeda.
Menggabungkan kedua proyek ini akan menjadikan akses kontraktor dan jadwal peluncuran Morrow sebagai bagian dari risiko operasional Aster. Keputusan server terpisah mengikuti batasan tersebut; ini tidak mengklaim bahwa Morrow membutuhkan jumlah CPU tertentu atau bahwa Aster bebas risiko.
Gulir secara horizontal untuk semua kolom tabel.
| Faktor keputusan | Aster Furniture: situs brosur | Morrow Workshops: situs pendaftaran |
|---|---|---|
| Beban kerja | Halaman publik dan pembaruan konten sesekali | Formulir, basis data, dan ekspor pendaftaran terjadwal |
| Akses | Klien mengedit konten; agensi melakukan deployment | Pengembang eksternal memerlukan administrasi host |
| Pemeliharaan | Jendela malam yang disepakati | Tidak ada perubahan yang direncanakan selama peluncuran pemesanan |
| Dampak insiden | Gangguan halaman sementara dapat didiskusikan | Kiriman yang hilang atau terduplikasi memerlukan investigasi |
| Persyaratan keluar | Ekspor konten dan pindahkan aplikasi | Transfer lingkungan yang dioperasikan secara independen |
| Keputusan sementara | Pertimbangkan berbagi dengan situs yang dijalankan agensi yang kompatibel | Gunakan VPS terpisah dan kredensial proyek terpisah |
Bandingkan biaya penuh dari kedua pengaturan
Buat dua versi anggaran menggunakan konfigurator saat ini: satu konfigurasi bersama dan satu konfigurasi per proyek. Untuk masing-masing, cantumkan total hosting untuk periode yang dipilih, opsi berulang, layanan eksternal, dan waktu pemeliharaan agensi secara terpisah. Hindari menyalin harga lama ke dalam brief klien. Catat kapan konfigurasi disiapkan dan siapa yang menyetujui alokasi tersebut.
Untuk host bersama, sepakati bagaimana klien membagi biaya tetap dan apa yang terjadi ketika salah satu keluar atau memerlukan peningkatan. Pembagian yang sama itu sederhana tetapi mungkin tidak cocok ketika satu proyek menyebabkan sebagian besar pertumbuhan penyimpanan atau pekerjaan operasional. Server terpisah membuat atribusi lebih jelas sekaligus menambah tugas patching, pemantauan, dan pemulihan yang terpisah.
Sisakan ruang sumber daya untuk rilis, cadangan, dan pekerjaan sementara. Kontainer Docker tidak memiliki batasan CPU atau memori secara default; konfigurasikan batas yang sesuai dan nilai beban kerja gabungan. Daftar kontainer saja tidak menunjukkan anggaran sumber daya yang layak.
Buat pemeliharaan dan pemulihan khusus proyek
Pada host bersama, restart sistem operasi memengaruhi setiap proyek yang berada di sana. Letakkan pemeliharaan host pada kalender bersama dan identifikasi siapa yang menghubungi setiap klien. Pisahkan rilis aplikasi jika memungkinkan, dan hindari menjadwalkan ekspor data satu proyek selama peluncuran penting proyek lain.
Catatan pemulihan harus mengidentifikasi basis data, file, konfigurasi, dan kredensial yang diperlukan suatu proyek tanpa menyalin rahasia ke dalam catatan. Rencanakan pemulihan ke tujuan pengujian terpisah. Memulihkan seluruh host bersama sebagai respons pertama dapat menggantikan perubahan sehat milik klien lain.
Dengan instans VPS terpisah, catat layanan bersama yang tetap ada. Akun DNS bersama, tujuan cadangan, atau operator dapat tetap memengaruhi kedua proyek. Pemisahan server bukan bukti infrastruktur fisik independen atau ketersediaan yang terjamin.
Validasi pengaturan dan tetapkan pemicu tinjauan
Sebelum menerima pengaturan tersebut, minta operator kedua memeriksa bahwa identitas proyek dapat melakukan pekerjaan yang ditugaskan dan tidak dapat membaca file, cadangan, atau rahasia proyek lain. Tinjau izin basis data dan kredensial yang di-deploy serta layar aplikasi. Gunakan data uji yang tidak berbahaya di lingkungan yang disepakati; jangan menyelidiki data produksi klien lain.
Catat hasilnya sebagai diterima, ditolak, atau menunggu koreksi yang disebutkan. Jika isolasi tidak dapat ditunjukkan, persempit akses atau pindahkan proyek sebelum memberikan izin yang lebih luas. Respons beranda yang berhasil bukan pemeriksaan akses atau pemulihan.
- Simpan catatan keputusan dengan tata letak yang dipilih, alokasi biaya yang disetujui, pemilik, dan item yang belum terselesaikan.
- Tinjau pilihan tersebut ketika administrator luar bergabung, jendela peluncuran berubah, penyimpanan bertambah, atau klien bersiap untuk keluar.
- Gunakan panduan tanggung jawab untuk mengubah pilihan teknis menjadi perjanjian operasional.
Sumber & tinjauan
Referensi teknis diperiksa pada September 12, 2026. Contoh adalah latihan perencanaan; dokumentasi perangkat lunak yang direferensikan tidak menetapkan kemampuan layanan PrivateHostLab.