Akun layanan dan identitas workload: izin untuk proses otomatis

Apa itu service account dan identitas workload?

Akun layanan atau service account adalah identitas yang digunakan aplikasi atau proses otomatis. Workload adalah pekerjaan yang dijalankan sistem, misalnya tugas ekspor terjadwal atau proses deployment. Identitas workload memungkinkan pekerjaan tersebut membuktikan asalnya dan memperoleh izin sesuai tugas.

API key, token, atau sertifikat merupakan cara membawa atau membuktikan akses sesuai mekanisme layanan. Memindahkan kunci ke penyimpanan secret belum menjawab apakah izinnya terlalu luas atau siapa yang boleh mengambilnya.

Contoh: tugas pengiriman faktur

Contoh fiktif: proses malam hari membaca faktur yang sudah disetujui dan mengirimkannya ke layanan pengiriman. Awalnya proses memakai akun pribadi pengembang dengan akses admin.

Tim membuat identitas khusus untuk pekerjaan ini. Haknya dibatasi pada data dan tindakan yang diperlukan; ia tidak boleh menghapus pelanggan atau mengubah admin. Lingkungan uji memakai identitas berbeda agar pengujian tidak memperoleh akses produksi.

Pemilik layanan memeriksa satu pengiriman sah dan beberapa tindakan yang harus ditolak. Nama akun yang terdengar terbatas bukan bukti; hasil permintaan pada sistem tujuan yang menunjukkan batas akses.

Inventaris yang membantu tim menjaga akses

Informasi	Yang dicatat tanpa nilai rahasia
Pemilik	Tim penanggung jawab dan pengganti yang berwenang
Kegunaan	Pekerjaan, aplikasi, dan lingkungan yang memakai identitas
Izin	Data serta tindakan yang diperlukan dan yang harus ditolak
Kredensial	Lokasi pengelolaan, pengenal aman, masa berlaku, dan cara penggantian
Ketergantungan	Proses yang akan berhenti bila akses dicabut
Penghentian	Cara menonaktifkan identitas dan memeriksa akses tersisa

Kurangi rahasia yang disalin manual

Bila tersedia, gunakan identitas terkelola atau pertukaran identitas untuk memperoleh kredensial berumur pendek. Periksa siapa yang dipercaya, dari lingkungan mana, dan untuk layanan tujuan apa. Menggunakan token singkat tetap berbahaya bila semua pekerjaan dapat meminta peran admin.

Jika kunci statis masih diperlukan, simpan pada pengelola secret dengan izin terbatas. Jangan masukkan nilainya ke repositori, image, log, atau tiket. Catat pengambilan dan penggunaan yang relevan tanpa merekam rahasianya. Hindari memakai satu identitas bersama untuk pekerjaan yang berbeda kebutuhan.

Uji penggantian dan penghentian

Untuk rotasi terencana, petakan pengguna kredensial, pasang pengganti, uji pekerjaan, lalu buktikan kunci lama ditolak. Siapkan penanganan ketika pengelola secret tidak tersedia. Jangan menyamakan prosedur transisi dengan penanganan kunci yang sudah bocor; kredensial yang terpapar perlu segera ditangani sesuai risiko.

Saat integrasi dihentikan, cabut izin dan kredensial, hentikan jadwal, serta periksa apakah ada salinan akses pada lingkungan lain. Jika pegawai pembuatnya keluar, pastikan pemilik operasional telah ditetapkan; proses otomatis tidak seharusnya bergantung pada akun pribadi tersebut.

Lanjutkan ke keamanan CI/CD untuk izin pipeline, atau pengelolaan akses admin bila pekerjaan otomatis memerlukan kewenangan tinggi.