Akses kontraktor ke repositori: pintu publik atau jalur VPN?

Kontraktor memerlukan satu repositori privat untuk proyek terbatas, dan permintaan datang sebagai «jadikan repo publik» atau «beri mereka akses VPN». Kedua jawaban melewati pertanyaan sebenarnya. Otorisasi repositori dan pintu jaringan adalah lapisan terpisah, dan izin yang penting adalah izin yang memungkinkan orang itu membaca atau push ke satu repositori tersebut. Segala hal lain dalam paket mana pun adalah risiko tambahan. Rancang dulu lapisan otorisasi, lalu putuskan seberapa sedikit jalur jaringan yang dibutuhkannya.

Sebuah keterlibatan ilustratif membuatnya konkret: satu pengembang eksternal, satu repositori, tanpa host produksi, tanpa antarmuka administrasi. Pertahankan cakupan itu tetap saat Anda membandingkan pintu masuk.

Dua pintu, dua batas berbeda

Layanan repositori yang dapat dijangkau publik tetap memberlakukan autentikasi HTTPS atau SSH dan otorisasi aplikasi. Keterjangkauan publik bukan berarti keterbacaan anonim. Biayanya adalah listener yang harus Anda rawat, pantau, dan tambal.

Pintu VPN dapat menjauhkan listener itu dari jalur publik, tetapi akun VPN yang luas dapat mengekspos layanan yang tidak terkait. Nama host publik yang tertinggal, listener SSH, atau keluarga alamat yang Anda lupakan dapat menggagalkan batas khusus VPN yang Anda kira Anda miliki. Itulah sebabnya desain khusus VPN memerlukan inventaris listener, bukan hanya aturan firewall.

Bandingkan jalur yang diizinkan, bukan label. Bagaimanapun, pertahankan autentikasi aplikasi dan validasi identitas server yang normal.

Peran repositori adalah unit izin

Beri kontraktor identitas individu dengan peran terkecil yang menyelesaikan tugas. Melihat, push, memelihara, dan mengelola adalah peran berbeda, dan grup yang memberikan setiap proyek internal tidak sama dengan akses ke satu repositori. Periksa nama peran yang sebenarnya di platform Anda alih-alih mengasumsikan nama grup memetakan ke satu peran.

Daftar setiap operasi yang benar-benar dibutuhkan keterlibatan. Akses peramban dan transport Git dapat memakai kredensial atau listener berbeda. Build otomatis, unduhan paket, dan webhook dapat berjalan sebagai identitas terpisah dengan jalur pengiriman sendiri, dan VPN di laptop tidak menghubungkannya.

Melindungi isi repositori adalah pekerjaan terpisah. Mengubah jalur masuk tidak menghapus rahasia yang sudah ada di riwayat, membatasi klon yang diotorisasi, atau mengamankan stasiun kerja kontributor.

Kredensial yang hidup lebih lama dari orangnya

Offboarding adalah titik ketika akses repositori dan akses jaringan kembali menyimpang. Hapus otorisasi repositori dan hak VPN melalui pemilik masing-masing, lalu periksa token pribadi, kunci SSH, kredensial otomasi, dan sesi aktif. Kunci deploy adalah penyintas klasik: kunci itu dapat mempertahankan akses baca atau tulis yang dikonfigurasi setelah orang tersebut meninggalkan organisasi. Menghapus dari daftar anggota bukan offboarding lengkap.

Inventarisasi kredensial mesin menurut pemilik dan tujuan sebelum keterlibatan berakhir, bukan sesudahnya. Token yang dibuat untuk build seminggu dapat hidup setahun lebih lama dari proyek jika tak ada yang menuliskan mengapa token itu ada.

Verifikasi operasi, penolakan, dan offboarding

Sebelum serah terima, uji tiga hal: operasi repositori yang diizinkan berhasil, repositori yang tidak terkait ditolak, dan identitas yang dipensiunkan gagal. Jika desainnya khusus VPN, pastikan jalur publik langsung yang lama tidak lagi dapat melakukan operasi itu.

Simpan kode dan catatan tinjauan, tetapi jangan biarkan akses yang terlupakan menjadi rencana pemulihan. Daftar tertulis identitas, peran, dan tanggal kedaluwarsa adalah yang membuat permintaan kontraktor berikutnya menjadi proses yang dapat diulang.