Untuk rollout korporasi dan pemerintah, onboarding SIP Shield ditangani oleh tim kami sebagai standar, apa pun OS yang digunakan. Ini menjaga deployment konsisten di Linux, Windows Server, dan cloud, mengurangi risiko konfigurasi salah, serta mempercepat waktu menuju proteksi. Jika tim IT Anda lebih memilih self-install, kami dapat mendukungnya setelah deployment pertama stabil.
OS server dan versinya, mail stack (Exim / Postfix / Exchange / lainnya), control panel (Webuzo / cPanel / Plesk / none), metode akses admin (SSH / VPN / Bastion), akses root atau sudo untuk instalasi (akses sementara boleh), maintenance window, dan scope rollout. Jika mau, Anda dapat membuat username SSH sementara memakai Client ID SIP Shield agar proses handoff lebih rapi.
Instal dan konfigurasi aplikasi server SIP Shield, discovery mailbox dan konfirmasi daftar yang dilindungi, aktifkan karantina dan alur review, validasi notifikasi email yang ditahan serta aksi release/delete, lalu siapkan jalur upgrade dan runbook dasar untuk tim IT.
Onboarding terkelola biasanya 60–180 menit tergantung mail stack dan environment. Self-install oleh klien biasanya 2–6 jam (sering lebih lama karena perbedaan environment dan troubleshooting).
Kami menjaga akses sesingkat dan seminimal mungkin sambil memastikan instalasi berjalan benar.
Aplikasi server dipasang sebagai system service dan terintegrasi dengan mail stack, sehingga akses root atau sudo dibutuhkan saat instalasi. Akses sementara diperbolehkan dan direkomendasikan. Kami menyarankan menggunakan Client ID SIP Shield sebagai username sementara (contoh: SS-00ABC1234) agar referensi akses mudah dilacak.
Kami hanya mempertahankan akses selama setup dan validasi awal. Setelah itu, akses bisa langsung dicabut.
Kami tidak meminta password mailbox end-user, dan tidak mengambil alih DNS, MX record, atau routing email eksternal tanpa persetujuan eksplisit.
Footprint kami kecil dan bisa dibalik agar tim Anda tahu apa saja yang disentuh SIP Shield.
SIP Shield dipasang sebagai service terpisah dengan konfigurasi sendiri dan tidak mengganti mail server Anda.
Kami menambahkan hook filter mail yang terkontrol agar email bisa dievaluasi sebelum delivery. Jika hook dinonaktifkan, alur mail normal kembali.
Logging dan visibilitas karantina diaktifkan agar tim Anda dapat melihat apa yang ditahan dan alasannya.
Kami lebih memilih scope kecil dulu, lalu diperluas setelah uji coba bersih.
Kami biasanya mulai dari subset mailbox kecil untuk memastikan mail flow, karantina, dan notifikasi berjalan sebelum cakupan diperluas.
Maintenance window 60–180 menit biasanya cukup untuk instalasi dan validasi. Kami jadwalkan di jam trafik email rendah.
Jika ada hal tak terduga, kami dapat menonaktifkan hook SIP Shield dan mengembalikan alur mail default segera.
SIP Shield tidak menggantikan mail server Anda dan tidak menghapus email asli tanpa review eksplisit. Aplikasi dipasang sebagai service dan memakai hook mail stack standar.
Kami tidak mengambil backup penuh server secara default karena berat dan memakan waktu. Jika kebijakan Anda mewajibkan, kami bisa koordinasi snapshot sebelum perubahan. Instalasi juga bisa dijalankan pada scope kecil terlebih dahulu.
SIP Shield dirancang berisiko rendah, tetapi integrasi mail stack tetap punya risiko operasional. Risiko utama adalah gangguan alur email jika hook salah konfigurasi. Kami mitigasi dengan testing mailbox kecil terlebih dahulu.
Kerusakan sistem besar tidak diharapkan. SIP Shield tidak memodifikasi paket sistem di luar jalur instalasinya. Risiko realistis adalah gangguan sementara alur email jika detail environment salah, itulah sebabnya onboarding terkelola menjadi standar.
Kami ingin tim internal Anda memiliki kejelasan setelah deployment pertama selesai.
Kami memberikan jalur upgrade yang jelas dan runbook singkat agar tim IT dapat menerapkan update tanpa mengulang rollout.
Email yang ditahan memicu notifikasi ke pengguna mailbox yang terdampak, dengan email akun pelanggan tetap disalin untuk visibilitas.
Portal menampilkan jumlah mailbox, status karantina, dan model deployment aktif agar tim Anda dapat melacak rollout.
Kami transparan agar klien memahami tradeoff-nya.
Lebih cepat menuju proteksi, risiko konfigurasi salah lebih rendah, catatan deployment lebih rapi, dan beban tim IT lebih ringan.
Perlu akses admin sementara, perlu maintenance window, dan beberapa organisasi lebih suka kontrol internal penuh.
Self-install memberi kontrol penuh tetapi lebih lambat dan berisiko salah konfigurasi. Kami sarankan self-install hanya setelah deployment pertama stabil.