# Mengamankan akun kerja: MFA, passkey, SSO, dan pencabutan akses

Sumber diperiksa. Metode: https://kompli.id/metodologi/.

Pengamanan akun mencakup cara masuk, hak yang diberikan, pemulihan saat perangkat hilang, dan pencabutan akses. MFA membantu, tetapi proses pemulihan dan akun lama juga perlu diperiksa.

URL kanonis: https://kompli.id/panduan/keamanan/mengamankan-akun-dan-akses/
Sumber diakses: 2026-09-29
Diperbarui: 2026-09-30
Penulis: Kompli
Sumber diperiksa: 2026-09-30


## Dari akun mana sebaiknya mulai?

**Dahulukan akun yang bisa mengubah layanan, membaca banyak data, atau mengambil alih akun lain.** Contohnya admin email, registrar domain, hosting, penyimpanan cadangan, dan sistem pengelola akses. Catat pemilik serta pengganti yang berwenang untuk masing-masing akun.

Pisahkan identitas pengguna agar tindakan dapat ditelusuri. Berikan hak sesuai tugas, bukan semua orang menjadi admin karena lebih mudah saat proyek dimulai. NIST SP 1300 menjadi rujukan praktik; panduan ini tidak menetapkan kewajiban MFA yang seragam untuk seluruh bisnis Indonesia.

## Apa beda MFA, passkey, dan SSO?

MFA memakai lebih dari satu faktor autentikasi, misalnya sesuatu yang diketahui dan sesuatu yang dimiliki. Dua kata sandi bukan dua jenis faktor.

Passkey menggunakan pasangan kunci kriptografi. Dalam penerapan yang sesuai, pengikatan ke nama layanan membantu melawan phishing. Namun, keamanan perangkat, akun sinkronisasi, dan pemulihannya tetap penting. NIST membedakan autentikasi tahan phishing dari kode sekali pakai yang diketik manual; kode tersebut masih dapat ditipu agar diberikan ke pihak lain.

SSO (*single sign-on*) memungkinkan satu identitas dipakai masuk ke beberapa layanan. Ini memudahkan pengelolaan, tetapi tim harus memeriksa aplikasi yang belum terhubung, akun lokal cadangan, dan akses yang tetap aktif setelah identitas pusat dinonaktifkan.

## Contoh pemeriksaan saat pegawai pindah peran

Contoh fiktif: Dina pindah dari operasional ke pemasaran. Ia masih memerlukan email, tetapi tidak lagi bertugas mengekspor data pesanan.

| Langkah tim | Bukti selesai |
| --- | --- |
| Atasan mengonfirmasi tugas baru | Daftar aplikasi dan hak yang masih dibutuhkan |
| Pengelola akses mencabut hak ekspor | Catatan perubahan pada aplikasi, bukan hanya tiket permintaan |
| Tim memeriksa grup dan akun lokal | Akses lama tidak muncul lewat keanggotaan grup lain |
| Dina dan pengelola melakukan pemeriksaan terbatas | Tugas baru berjalan; fungsi ekspor lama ditolak |
| Pemilik aplikasi menutup permintaan | Nama pemeriksa, tanggal efektif, dan pengecualian yang masih terbuka |

Gunakan pola yang sama saat pegawai masuk atau keluar. Saat keluar, periksa sesi aktif, token pribadi, akses perangkat, dan tugas otomatis yang mungkin bergantung pada akun tersebut. Alihkan kepemilikan pekerjaan sebelum menutup akun sesuai prosedur organisasi.

## Contoh serah terima saat pegawai keluar

Contoh fiktif: petugas operasional berhenti pada akhir bulan, tetapi akunnya masih menjadi pemilik folder pesanan dan tugas ekspor otomatis. Sebelum waktu penutupan, atasan menunjuk pemilik baru. IT mengalihkan pekerjaan yang masih diperlukan, lalu menonaktifkan akses pegawai sesuai waktu yang disetujui dan memeriksa sesi serta token terkait.

Pemilik aplikasi memeriksa layanan yang tidak memakai SSO, termasuk akun ekspedisi. Tiket belum ditutup bila satu akses masih belum jelas. Gunakan [checklist akses pegawai](/template/checklist-akses-pegawai/) untuk mencatat petugas, waktu, bukti, dan pekerjaan tersisa. Menutup akses tidak berarti langsung menghapus semua arsip kerja atau data kepegawaian.

## Bagaimana jika perangkat MFA hilang?

Siapkan jalur pemulihan sebelum kejadian. Tentukan cara membuktikan pemilik akun, pihak yang menyetujui reset, cara memberi tahu pengguna, serta pencabutan metode lama. Simpan kode pemulihan secara terbatas; jangan menaruhnya di tempat yang dapat dibuka dengan akun yang sedang dipulihkan.

Latih skenario kehilangan perangkat dengan akun uji. Catat apakah pemilik yang sah berhasil kembali masuk dan apakah pihak lain dapat meminta reset hanya dengan informasi yang mudah diketahui. Ini latihan internal, bukan alasan untuk melemahkan pemeriksaan identitas saat ada permintaan mendesak.

## Bagaimana mengatur akun darurat dan akses vendor?

Akun darurat diperlukan hanya bila desain operasional membutuhkannya. Tentukan penjaga, alasan penggunaan, pemberitahuan saat dipakai, dan pemeriksaan setelahnya. Akun cadangan tanpa pemilik atau tanpa pemantauan bisa menjadi jalan masuk yang terlupakan.

Untuk vendor, tulis layanan yang diakses, tugas, pemberi izin, masa akses, dan cara penghentian. Hindari berbagi akun admin tetap. Setelah pekerjaan selesai, periksa pencabutan pada sistem yang sebenarnya dan alihkan kredensial atau kepemilikan yang relevan.

## Kapan akses diperiksa ulang?

Tentukan jadwal berdasarkan risiko dan kontrak, serta pemeriksaan ketika peran berubah, kerja sama selesai, atau ada insiden. Tidak ada jadwal bulanan atau tahunan universal yang ditetapkan artikel ini. Gunakan [checklist keamanan](/template/checklist-keamanan-website-aplikasi/) untuk mencatat bukti dan tindak lanjutnya.

Untuk menentukan kebutuhan dokumen saat pendaftaran, baca [verifikasi identitas pengguna](/panduan/operasional-digital/verifikasi-identitas-pengguna/).

## Latihan: pilih tindakan untuk akun kerja

Contoh berikut fiktif. Tentukan jawaban Anda, lalu buka pembahasannya.

### 1. Memilih pengamanan akun admin

Layanan email kantor mendukung passkey, tetapi tim baru memakai kata sandi. Apa yang perlu disiapkan sebelum beralih?

<details class="learning-answer">
<summary>Lihat pembahasan pilihan pengamanan</summary>
<p>Periksa dukungan perangkat dan cara pemulihannya, lalu uji dengan akun yang diizinkan. Passkey dapat membantu menghadapi phishing, tetapi pemulihan yang lemah tetap perlu diperbaiki. Jangan menyimpan satu-satunya cara pemulihan di dalam akun yang mungkin terkunci. Catat siapa yang dapat membantu dan cara memverifikasi pemilik akun.</p>
</details>

### 2. Kode masuk diminta lewat chat

Seseorang mengaku petugas IT meminta OTP agar dapat “mengaktifkan MFA”. Apakah kode boleh diberikan karena tujuannya pengamanan?

<details class="learning-answer">
<summary>Lihat pembahasan kode masuk</summary>
<p>Jangan menyerahkan kode login kepada pengirim pesan. Konfirmasikan pekerjaan melalui jalur dukungan IT yang biasa dipakai. Kode sekali pakai tetap dapat dicuri melalui permintaan palsu; nama MFA tidak membuat semua proses masuk tahan phishing.</p>
</details>

### 3. Perangkat hilang saat ada pekerjaan mendesak

Ponsel yang dipakai masuk akun hilang. Rekan menawarkan akunnya agar pekerjaan segera selesai. Apakah ini cara pemulihan yang tepat?

<details class="learning-answer">
<summary>Lihat pembahasan pemulihan akun</summary>
<p>Gunakan prosedur pemulihan dan pemeriksaan identitas yang telah disiapkan. Minta petugas menilai pencabutan metode masuk serta sesi pada perangkat hilang. Meminjam akun rekan bukan pemulihan akun Anda dan membuat pencatatan tindakan sulit dibedakan.</p>
</details>

Setelah latihan, cek satu akun kerja yang menjadi tanggung jawab Anda: apakah metode masuk, kontak bantuan, dan cara pemulihannya sudah diketahui? Catat kekurangan tanpa menyalin kata sandi atau kode rahasia ke lembar latihan.

Jika masalahnya adalah dugaan pengambilalihan akun, lanjutkan ke [langkah menangani akun admin](/panduan/keamanan/akun-admin-diambil-alih/), termasuk pemeriksaan akses tambahan dan keputusan mengembalikan kewenangan.

## Contoh least privilege saat pegawai pindah tugas

Contoh fiktif: petugas dukungan pindah ke tim penagihan. Berikan akses tagihan yang diperlukan, lalu cabut hak mengunduh seluruh percakapan dukungan yang tidak lagi menjadi tugasnya. Pemilik masing-masing sistem memeriksa hasilnya, termasuk sesi dan token yang masih aktif. Menambah peran baru tanpa meninjau peran lama membuat izin terus menumpuk.

*Least privilege* berarti memberi akses sebatas kebutuhan yang sah. Bedakan [autentikasi dan otorisasi](/panduan/keamanan/autentikasi-dan-otorisasi/); login yang aman belum menjawab izin yang terlalu luas. [Zero Trust](/panduan/keamanan/zero-trust/) membantu memahami mengapa jaringan kantor saja tidak cukup menjadi dasar kepercayaan.

## Pahami risiko di balik pemeriksaan

Baca [Authentication Failures](/panduan/owasp/authentication-failures/) untuk memahami konsep dan contoh kegagalannya. Gunakan langkah di halaman ini untuk pekerjaan penerapan.

## Panduan penerapan terkait

Untuk pemeriksaan lebih rinci, pilih [pemulihan akun dan MFA](/panduan/keamanan/pemulihan-akun-dan-mfa/), [akses admin dan PAM](/panduan/keamanan/akses-admin-dan-pam/), atau [akun layanan untuk proses otomatis](/panduan/keamanan/akun-layanan-dan-identitas-workload/). Masing-masing menyertakan contoh kerja dan bukti yang perlu diperiksa.
## Sumber rujukan

- [NIST SP 800-63B-4 — Authentication and Authenticator Management](https://pages.nist.gov/800-63-4/sp800-63b.html) — Bagian 3.2.5 dan 4; phishing resistance serta pengelolaan dan pemulihan autentikator
- [NIST SP 1300 — Cybersecurity Framework 2.0: Small Business Quick-Start Guide](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1300.pdf) — Protect; akses, autentikasi, dan prinsip hak minimum

## Jalur belajar: Keamanan sehari-hari

Materi berikutnya: [Periksa pesan dan permintaan palsu](https://kompli.id/panduan/keamanan/mengenali-phishing-di-tempat-kerja/)

[Lihat urutan belajar](https://kompli.id/belajar/#keamanan-sehari-hari)


## Perlu membahas kebutuhan tim Anda?

Ceritakan sistem yang dikelola dan kebutuhan pengamanan tim Anda.

[Konsultasikan kebutuhan Anda](https://kompli.id/konsultasi/?topik=keamanan)

## Bacaan terkait

- [Keamanan API: akses pengguna, tenant, token, dan batas penggunaan](https://kompli.id/panduan/keamanan/keamanan-api-akses-data/)
- [Checklist keamanan website dan aplikasi](https://kompli.id/template/checklist-keamanan-website-aplikasi/)
- [Memeriksa vendor pengolah data pribadi sebelum kerja sama](https://kompli.id/panduan/pdp/pemeriksaan-vendor-pengolah-data/)
- [Checklist akses pegawai masuk, pindah peran, dan keluar](https://kompli.id/template/checklist-akses-pegawai/)

