Mengelola Token

Token dibuat sekali, tetapi hidupnya panjang — dan selama hidup itu, kualitas pengelolaan yang menentukan apakah token menjadi pintu terkontrol atau lubang yang dilupakan. Personal Access Token membahas cara membuat dan memakainya; chapter ini membahas cara merawatnya: memberi nama yang jujur, membatasi cakupan sejak lahir, menjadwalkan rotasi, mencabutnya saat mencurigakan, dan — yang paling sering terabaikan — menolak tempat-tempat yang kelihatannya praktis untuk menyimpan token tapi sebenarnya adalah kebocoran yang menunggu waktu.

Satu Token, Satu Peruntukan #

Daftar token di halaman pengaturan platform hanya menampilkan nama dan metadatanya — nilai token hanya sekali terlihat saat pembuatan. Nama yang kabur (token1, baru) membuat daftar itu tidak bisa dipakai untuk keputusan apa pun; nama yang jujur membuatnya menjadi papan kendali:

Prinsip di balik tabelnya: satu token per perangkat atau per tujuan. Saat satu titik bocor — laptop dicuri, skrip terunggah, token CI bocor di log — hanya token milik titik itu yang perlu dicabut; seluruh alur kerja lain berjalan tanpa gangguan.

Scope Minimal: Prinsip Least Privilege #

Scope token menentukan apa yang bisa dilakukan siapa pun yang memegang nilainya. Pemilihan scope adalah momen paling murah untuk mempersempit kerusakan masa depan — setelah token dipakai, memperkecil scope berarti membuat token baru:

Aturan praktisnya satu kalimat: beri token izin minimum yang membuat tugasnya selesai, tidak satu poin lebih. Prinsip least privilege ini berlaku jauh melampaui token — pembahasan utuhnya menunggu di Least Privilege .

Umur Pendek dan Rotasi Terjadwal #

Token tanpa kedaluwarsa adalah hutang keamanan tanpa jatuh tempo. Saat membuat token, platform menawarkan masa berlaku — pilih yang terpendek yang masih nyaman untuk peruntukannya: 30 hari untuk kebutuhan aktif, 90 untuk yang jarang disentuh, dan jangan pernah memilih no expiration untuk token dengan scope tulis. Kedaluwarsa otomatis menjamin satu hal: token yang dilupakan mati sendiri.

Rotasi mengisi celah di antara kedaluwarsa: kalender pengingat bulanan untuk menekan tombol regenerate — nilai token diganti, izin dan nama tetap — lalu memperbarui secret di satu-satunya tempat token itu tinggal. Fitur ini ada di halaman pengaturan token di tiap platform: GitHub menyediakannya di Settings → Developer settings → Personal access tokens, GitLab di Preferences → Access Tokens, Bitbucket di setelan API tokens per ruang kerja. Halaman-halaman itu juga tempat tombol revoke bersemayam.

Pencabutan dan Audit #

Dua kejadian meminta pencabutan segera, bukan esok: perangkat pemegang token hilang, dan perilaku aneh di repository — commit yang tidak dikenal, branch asing, pengaturan berubah. Pencabutan satu token memutus aksesnya seketika tanpa menyentuh kredensial lain.

Setelah memutus, telusuri jejaknya. Platform mencatat aktivitas akun: GitHub menyediakan security log di Settings → Security → Security log yang mencatat peristiwa autentikasi dan penggunaan token, termasuk kapan token terakhir dipakai — panduan membacanya tersedia di dokumentasi GitHub tentang security log . Daftar token di halaman pengaturan juga menampilkan indikasi pemakaian terakhir per token; token yang “terakhir dipakai” pada waktu kita tidak sedang bekerja adalah alarm, bukan kebetulan.

Tempat yang Dilarang untuk Token #

Tempat penyimpanan menentukan siapa yang bisa membaca. Lima tempat ini tampak praktis dan semuanya bocor:

Alternatif Lebih Aman #

Dua alternatif menyempitkan permukaan lebih jauh dari token akun. Deploy key adalah pasangan kunci SSH yang terdaftar pada satu repository — bukan pada akun — sehingga bisa dibuat read-only untuk kebutuhan mesin deploy; pendaftarannya berjalan lewat jalur SSH keys seperti di Membuat dan Menggunakan SSH Key , dan pembatasan per repository terdokumentasi di panduan deploy keys GitHub . SSH pribadi untuk pekerjaan harian menggeser kredensial dari token yang harus dirotasi menjadi kunci ber-passphrase yang dipegang ssh-agent — tanpa nilai rahasia yang pernah diketik ke prompt.

Skrip Aman: Token dari Variabel Lingkungan #

Sisa satu pertanyaan praktis: bagaimana skrip memakai token tanpa menyimpannya? Jawabannya variabel lingkungan — token di-set di luar repository, skrip membacanya saat runtime. Git sendiri menyediakan pintu resmi untuk ini: variabel GIT_ASKPASS berisi program yang dipanggil Git untuk mengisi prompt kredensial, sebagaimana dirinci di gitcredentials(7) . Skrip askpass latihan di sandbox:

#!/bin/sh
# Skrip askpass tidak memuat kredensial apa pun —
# nilai dibaca dari variabel lingkungan saat runtime.
case "$1" in
  *Username*) echo "budi" ;;
  *Password*) echo "$TOKEN_LATIHAN" ;;
esac

Ketiga baris intinya adalah pemetaan: prompt berisi kata Username dijawab nama pengguna tetap, prompt Password dijawab nilai TOKEN_LATIHAN. Token diujikan lewat plumbing git credential fill:

TOKEN_LATIHAN=YOUR_GITHUB_TOKEN bash -c \
  "printf 'protocol=https\nhost=example.com\n' | \
   GIT_ASKPASS=./askpass-latihan.sh git credential fill"

Output yang Dihasilkan:

protocol=https
host=example.com
username=budi
password=YOUR_GITHUB_TOKEN

Git mendapat kredensial lengkap tanpa satu nilai rahasia yang tertulis di skrip atau berkas repository. Uji kebalikannya membuktikan sumber nilai memang variabel lingkungan — tanpa TOKEN_LATIHAN, password kosong:

protocol=https
host=example.com
username=budi
password=

Di mesin sungguhan, TOKEN_LATIHAN di-set dari secret manager CI atau berkas lingkungan yang masuk .gitignore, lalu git push berjalan dengan GIT_ASKPASS terpasang. Konfigurasi repository tetap bersih — git config --local --list hanya memuat identitas dan pengaturan, tidak pernah token.

Token yang diberi nama jujur, scope kecil, umur pendek, dan tempat tinggal yang benar adalah kredensial yang bisa tidur nyenyak. Namun satu kesalahan klasik masih menunggu di ujung jalan: token yang terlanjur masuk ke pesan commit atau berkas .env yang ter-commit. Menghapus berkas itu dari HEAD tidak menutup apa-apa — pembuktianya menunggu di chapter berikutnya.