Sepakati jendela serah terima dan pemiliknya
Konfirmasi siapa yang berwenang menyetujui transfer dan mencabut akses. Sebutkan pemilik akun klien, kontraktor yang keluar, operator pengganti dan orang yang dapat membantu jika akses bermasalah. Sepakati batas waktu, perubahan yang diizinkan selama masa tumpang tindih dan bukti yang diperlukan sebelum penyelesaian.
Miliki inventaris proyek terkini, lingkup kerja yang disepakati dan akses ke sistem kredensial aman klien. Tetapkan cara pemulihan akun sebelum menghapus operator yang keluar. Jika serah terima menyusul dugaan kompromi, pemilik respons insiden harus menentukan waktu pembatasan; urutan tumpang tindih normal mungkin tidak sesuai.
Inventarisasi kepemilikan secara terpisah dari akses login
Daftarkan pemilik akun setiap layanan, operator saat ini, identitas otomatisasi, pemilik pemulihan dan tindakan transfer yang diperlukan. Login administrator tidak menentukan siapa yang mengendalikan penagihan atau pemulihan. Catat hanya referensi kredensial atau sidik jari kunci publik; jangan pernah memasukkan kata sandi, token, kunci privat atau kode pemulihan ke dalam register ini.
Gulir secara horizontal untuk semua kolom tabel.
| Aset proyek | Pertanyaan kepemilikan | Bukti penyelesaian |
|---|---|---|
| Domain dan DNS | Siapa yang mengendalikan registrar, perpanjangan dan kontak pemulihan? | Pemilik mengonfirmasi akses dan catatan terkini. |
| Hosting dan server | Siapa yang mengendalikan akun, konsol dan pengguna dengan hak istimewa? | Pengganti memverifikasi akses yang diperlukan secara independen. |
| Repositori dan deployment | Siapa yang memiliki repositori, otomatisasi dan kredensial deploy? | Rilis yang disetujui diterapkan ke target terisolasi. |
| Aplikasi dan integrasi | Siapa yang mengelola CMS, email, API dan tugas terjadwal? | Pemeriksaan peran dan integrasi tercatat. |
| Pencadangan dan pemulihan | Siapa yang mengendalikan penyimpanan cadangan dan materi dekripsi yang diperlukan? | Pengganti menyelesaikan latihan pemulihan terisolasi. |
Alihkan kepemilikan dan pengetahuan operasional
Gunakan mekanisme transfer atau undangan yang didukung layanan, lalu minta pemilik penerima memverifikasi kendali dari akunnya sendiri. Hindari mengadopsi identitas pribadi kontraktor sebagai login bersama. Terbitkan ulang kredensial proyek melalui sistem aman yang disetujui jika akun pribadi sebelumnya menyediakannya.
Untuk repositori GitHub, transfer mempertahankan secret terkait, kunci deploy dan webhook, dan kolaborator yang ada dapat tetap ada. Tinjau ini secara eksplisit setelah transfer. Tanda terima transfer menetapkan perubahan kepemilikan, bukan penyelesaian penghapusan akses.
Berikan referensi rilis, versi runtime, lokasi konfigurasi, tugas terjadwal, dependensi eksternal, cakupan pencadangan dan prosedur pemulihan. Tambahkan kegagalan yang diketahui dan tugas pemeliharaan berikutnya. Jelaskan di mana kredensial diambil secara aman tanpa menyalin nilainya ke dalam dokumentasi.
Biarkan pengganti melakukan pekerjaannya
Minta pengganti mengikuti prosedur tertulis tanpa meminjam sesi kontraktor. Mereka harus memperoleh sumber yang disetujui, menerapkan ke target uji terisolasi, menemukan log yang berguna dan menunjukkan tugas administrasi aplikasi yang diizinkan. Catat setiap langkah yang hilang, lalu perbarui instruksi dan ulangi pemeriksaan yang terdampak.
Minta mereka memulihkan cadangan yang disepakati ke tujuan uji terpisah dengan integrasi keluar dinonaktifkan atau dialihkan. Periksa catatan, unggahan dan perilaku aplikasi yang representatif. Catat pengenal cadangan, target, waktu berlalu dan kesenjangan yang belum terselesaikan. Jangan menimpa produksi untuk mendemonstrasikan pemulihan, dan jangan menafsirkan tugas pencadangan yang berhasil sebagai uji pemulihan yang selesai.
Hapus akses pihak yang keluar di setiap jalur
Setelah penggantian akses dan pemulihan diverifikasi, hapus kontraktor dari tim, repositori, akun hosting, dan peran aplikasi yang relevan. Tinjau sesi aktif dan cabut token proyek, integrasi, serta kredensial yang masih mereka pegang. Jika suatu kredensial digunakan bersama, terbitkan penggantinya, perbarui layanan yang bergantung padanya, dan uji sebelum menonaktifkan nilai lama. Ulangi tugas pengganti setelah pencabutan untuk menangkap ketergantungan tersembunyi pada kredensial lama.
Kunci deploy GitHub tetap aktif ketika pembuatnya dihapus dari repositori. Periksa secara terpisah, termasuk izin tulis dan mesin yang menggunakan setiap kunci. Untuk aplikasi OAuth yang diotorisasi, pemilik akun harus meninjau daftar aplikasi dan mencabut otorisasi yang sudah usang menggunakan kontrol GitHub.
Untuk akses SSH, identifikasi konfigurasi otorisasi kunci publik yang sebenarnya. OpenSSH mendokumentasikan bahwa AuthorizedKeysFile memilih file yang digunakan untuk autentikasi kunci publik; jangan berasumsi setiap server menggunakan satu file default. Pertahankan jalur pemulihan yang terverifikasi dan uji koneksi baru pengganti serta hak istimewa yang diperlukan sebelum menutup sesi pemeliharaan.
Contoh: repositori dipindahkan, tetapi deployment tidak
Dalam skenario fiktif ini, Cedar Workshop mengganti kontraktor situs webnya. Repositori mencapai organisasi klien, tetapi pekerjaan deployment masih menggunakan kredensial milik kontraktor yang akan pergi. Pengganti dapat mengedit kode namun tidak dapat mempublikasikan build yang disetujui. Serah terima tetap belum selesai.
Pemilik mengatur kredensial deployment yang dikendalikan proyek dengan izin yang diperlukan untuk pekerjaan tersebut. Pengganti memverifikasi deployment dan pemulihan pada target uji. Tim kemudian menonaktifkan kredensial lama, meninjau kunci deploy yang tersisa, dan menjalankan ulang pemeriksaan yang diizinkan. Catatan penutupan menautkan ke hasil ini tanpa memuat nilai kredensial.
Tutup dengan bukti dan kepemilikan yang terjadwal
Catat pemilik yang menerima serah terima, setiap referensi akses yang dicabut, waktu penyelesaian, hasil uji pengganti, dan pengecualian yang masih ada. Konfirmasi siapa yang akan bertindak pada kegagalan pekerjaan terjadwal berikutnya, perpanjangan domain, dan tugas pemeliharaan. Sepakati bagaimana data uji sementara dan salinan proyek yang dipegang kontraktor ditangani berdasarkan perjanjian yang ada.
Penghapusan akses tidak dapat membuktikan bahwa salinan historis tidak pernah disimpan. Latihan pemulihan membuktikan skenario yang diuji, bukan setiap mode kegagalan. Pertahankan batas-batas tersebut tetap terlihat dan bawa pekerjaan yang belum selesai ke dalam catatan tanggung jawab operasional dengan pemilik dan tenggat waktu yang disebutkan.
Sumber & tinjauan
Referensi teknis diperiksa pada September 12, 2026. Contoh adalah latihan perencanaan; dokumentasi perangkat lunak yang direferensikan tidak menetapkan kemampuan layanan PrivateHostLab.