Pertanyaan yang sering diajukan
- Apakah semua pengguna SaaS harus memakai SSO dan MFA?
- Idealnya ya, terutama untuk admin, tim internal, dan akun yang mengakses data sensitif. Namun, kebijakan bisa memberi pengecualian terbatas untuk kasus tertentu dengan persetujuan dan kontrol tambahan.
- Apakah MFA saja sudah cukup tanpa SSO?
- MFA sangat penting, tetapi tanpa SSO pengelolaan identitas tetap terfragmentasi. SSO membantu sentralisasi akses, sedangkan MFA menambah lapisan verifikasi saat login.
- Apakah kebijakan SSO dan MFA menjamin kepatuhan ISO?
- Tidak. Kebijakan ini membantu mendukung kontrol keamanan dan audit, tetapi kepatuhan atau sertifikasi ISO tetap membutuhkan penerapan kontrol lain, bukti, dan audit profesional.
- Apa faktor MFA yang paling aman untuk SaaS?
- Faktor yang berbasis aplikasi autentikator, passkey, atau security key umumnya lebih kuat daripada SMS. Pilihan terbaik bergantung pada risiko, perangkat yang dipakai, dan kebutuhan pengguna.
- Kapan perusahaan perlu meninjau ulang kebijakan ini?
- Saat ada perubahan penyedia identitas, insiden keamanan, ekspansi ke pasar baru, perubahan regulasi, atau saat audit internal menemukan celah pada proses akses.
Informasi waktu: Artikel ini dibuat otomatis pada 20 Juni 2026 pukul 14.29 (Asia/Jakarta, 2026-06-20T07:29:28.856Z).
Mengapa kebijakan SSO dan MFA penting untuk SaaS?
Untuk SaaS, kebijakan SSO dan MFA bukan sekadar fitur keamanan, melainkan aturan operasional yang mengatur cara orang masuk ke sistem, siapa yang boleh mengakses apa, dan bagaimana risiko akses dikelola. Di Indonesia, banyak perusahaan tumbuh cepat, memakai berbagai aplikasi cloud, dan bekerja dengan tim hybrid atau remote. Tanpa kebijakan yang jelas, akun mudah tersebar, password dipakai ulang, dan proses offboarding sering terlambat.
SSO membantu menyatukan identitas pengguna ke satu sumber tepercaya, misalnya Google Workspace, Microsoft Entra ID, atau IdP lain yang dipilih perusahaan. MFA menambahkan lapisan verifikasi kedua agar akun tidak mudah diambil alih hanya karena password bocor. Kombinasi keduanya sangat relevan untuk startup yang sedang scale up maupun enterprise yang butuh kontrol akses lebih rapi.
Apa isi minimum kebijakan SSO dan MFA?
Kebijakan yang baik tidak harus panjang, tetapi harus tegas. Setidaknya, dokumen ini menjawab lima hal: siapa yang wajib memakai SSO, siapa yang wajib MFA, metode MFA apa yang disetujui, bagaimana pengecualian diberikan, dan bagaimana logging serta review akses dilakukan.
Beberapa elemen minimum yang sebaiknya ada:
- Ruang lingkup: aplikasi, tim, dan jenis akun yang tercakup.
- Kewajiban SSO: akun internal, admin, dan akses ke sistem produksi.
- Kewajiban MFA: semua akun dengan akses sensitif, termasuk vendor dan kontraktor.
- Metode MFA yang diizinkan: authenticator app, passkey, atau security key.
- Metode yang dibatasi: SMS OTP untuk kasus tertentu saja, jika memang masih digunakan.
- Proses pengecualian: siapa yang menyetujui, berapa lama berlaku, dan kontrol kompensasinya.
- Prosedur pemulihan akun: verifikasi identitas, eskalasi helpdesk, dan pencatatan audit.
- Review berkala: misalnya tiap kuartal atau setelah insiden.
Untuk perusahaan di Jakarta dan kota besar lain di Indonesia, kebijakan ini juga membantu saat bekerja dengan banyak pihak eksternal. Vendor, agensi, dan konsultan sering perlu akses sementara; tanpa aturan yang jelas, akun tamu bisa bertahan terlalu lama.
Bagaimana menyusun kebijakan yang realistis untuk tim Indonesia?
Kebijakan yang bagus harus aman sekaligus bisa dijalankan. Jangan mulai dari aturan paling ketat jika kesiapan organisasi belum ada. Mulailah dari klasifikasi risiko.
Contoh pendekatan praktis:
- Wajibkan SSO untuk semua akun karyawan tetap dan kontraktor.
- Wajibkan MFA untuk seluruh akun admin, finance, engineering, dan customer support.
- Terapkan MFA wajib untuk semua akses ke data pelanggan, data pribadi, dan environment produksi.
- Izinkan metode MFA yang paling kuat terlebih dahulu, lalu sediakan opsi cadangan untuk kondisi lapangan.
- Buat alur onboarding dan offboarding yang otomatis atau setidaknya terdokumentasi.
Di Indonesia, tantangan yang sering muncul adalah variasi perangkat pengguna, koneksi internet, dan kebiasaan memakai nomor telepon pribadi untuk OTP. Karena itu, kebijakan sebaiknya mendorong metode yang tidak terlalu bergantung pada SMS. Authenticator app atau passkey biasanya lebih stabil untuk kerja jarak jauh dan lebih tahan terhadap SIM swap.
Apa hubungan SSO dan MFA dengan audit dan compliance?
SSO dan MFA sering menjadi kontrol dasar dalam audit keamanan, termasuk saat perusahaan menyiapkan diri untuk standar seperti ISO 27001 atau kebutuhan kontrol internal lain. Namun, penting untuk dipahami bahwa kebijakan ini tidak otomatis membuat perusahaan patuh atau tersertifikasi. Ia hanya bagian dari sistem kontrol yang lebih luas.
Saat auditor atau tim internal menilai akses, mereka biasanya mencari bukti bahwa:
- akses dikelola secara terpusat,
- akun sensitif memakai MFA,
- hak akses ditinjau secara berkala,
- akun yang keluar dari perusahaan segera dicabut,
- dan ada catatan perubahan akses yang bisa ditelusuri.
Itulah mengapa kebijakan harus disertai bukti operasional: log login, daftar pengguna, hasil review akses, tiket pengecualian, dan catatan insiden. Untuk organisasi yang sedang membangun kesiapan compliance, layanan seperti Patuh.ai dari APLINDO dapat membantu menyusun kontrol multi-ISO dan dokumentasi yang lebih terstruktur. Meski begitu, hasil audit tetap bergantung pada implementasi nyata dan penilaian profesional.
Key takeaways
- SSO memusatkan identitas, MFA menambah lapisan verifikasi; keduanya saling melengkapi.
- Kebijakan yang baik harus mencakup ruang lingkup, metode MFA, pengecualian, dan review berkala.
- Untuk konteks Indonesia, prioritaskan metode MFA yang kuat dan tidak terlalu bergantung pada SMS.
- Audit dan compliance membutuhkan bukti operasional, bukan hanya kebijakan tertulis.
- Mulailah dari akun berisiko tinggi: admin, produksi, finance, dan data pelanggan.
Contoh struktur kebijakan yang bisa dipakai
Anda bisa menyusun kebijakan dalam format singkat seperti ini:
Tujuan: melindungi akses ke sistem SaaS dan data perusahaan.
Kebijakan: semua pengguna internal harus mengakses aplikasi melalui SSO. MFA wajib untuk akun dengan akses sensitif. Pengecualian hanya boleh diberikan oleh pihak berwenang dan harus memiliki masa berlaku.
Standar teknis: metode MFA utama adalah authenticator app, passkey, atau security key. SMS OTP hanya sebagai fallback jika tidak ada opsi lain.
Kontrol operasional: akses ditinjau minimal setiap kuartal, akun nonaktif dicabut dalam waktu yang ditetapkan, dan seluruh perubahan akses dicatat.
Penanganan insiden: jika ada indikasi kompromi akun, reset akses, cabut sesi aktif, dan lakukan investigasi sesuai prosedur keamanan.
Struktur seperti ini cukup ringkas untuk dipahami tim engineering, security, HR, dan operations. Di banyak perusahaan Indonesia, kebijakan yang terlalu panjang sering tidak dibaca. Karena itu, lebih baik jelas, singkat, dan bisa dieksekusi.
Kapan perusahaan perlu mulai menerapkannya?
Jawaban singkatnya: sejak SaaS mulai memegang data pelanggan, data internal, atau akses ke environment produksi. Semakin cepat kebijakan dibuat, semakin kecil risiko Anda harus merapikan akses yang sudah terlanjur acak. Ini berlaku untuk startup yang baru mendapat pendanaan maupun perusahaan mapan yang sedang modernisasi sistem identitasnya.
Jika organisasi Anda sedang membangun arsitektur akses, APLINDO dapat membantu dari sisi SaaS engineering, applied AI, Fractional CTO, hingga konsultasi ISO dan compliance. Untuk kebutuhan produk, SealRoute, Patuh.ai, RTPintar, dan BlastifyX dapat menjadi bagian dari ekosistem operasional yang lebih aman dan terukur, tergantung konteks bisnis Anda.
FAQ
Apakah kebijakan SSO dan MFA harus dibuat terpisah?
Tidak harus. Banyak perusahaan menggabungkannya dalam satu kebijakan identity and access management agar lebih sederhana dikelola.
Apakah SMS OTP boleh dipakai sebagai MFA?
Boleh sebagai opsi terbatas, tetapi sebaiknya bukan metode utama untuk akun sensitif karena risikonya lebih tinggi dibanding authenticator app atau passkey.
Siapa yang sebaiknya menyetujui pengecualian MFA?
Biasanya security lead, IT lead, atau manajemen yang ditunjuk. Persetujuan harus terdokumentasi dan memiliki masa berlaku.
Bagaimana jika perusahaan belum punya IdP yang matang?
Mulailah dari aplikasi paling kritis dan pilih IdP yang mendukung SSO, MFA, logging, dan lifecycle management. Implementasi bertahap lebih baik daripada menunggu sempurna.
Apakah kebijakan ini relevan untuk perusahaan kecil?
Sangat relevan. Bahkan tim kecil sering lebih rentan karena akses masih informal dan belum ada pemisahan peran yang jelas.