Dokumen ini menjelaskan praktik terbaik untuk melindungi kredensial SSH.
Secara default, Compute Engine menggunakan autentikasi SSH berbasis kunci publik: Pengguna diautentikasi oleh sesuatu yang mereka miliki, yaitu kunci pribadi SSH. Jika kunci pribadi pengguna tidak diamankan dengan benar, kunci tersebut dapat jatuh ke tangan pihak tidak bertanggung jawab yang mungkin menggunakan kunci ini untuk mengakses instance VM Anda.
Bagian berikut berisi praktik terbaik yang dapat membantu Anda menghindari kebocoran kunci dan mengurangi potensi dampak kebocoran kunci pribadi:
- Memperlakukan kunci pribadi SSH mirip dengan kunci akun layanan
- Menggunakan kunci SSH sementara untuk pengguna mesin
- Menggunakan IAP untuk melengkapi autentikasi kunci publik SSH
- Menggunakan autentikasi multi-faktor
- Menggunakan kunci pribadi yang tidak dapat diekspor atau dilindungi frasa sandi
- Menggunakan kunci host untuk mengautentikasi host
- Jangan tinggalkan kredensial pribadi di VM
- Jangan kirimkan kunci pribadi SSH ke repositori kode sumber
Dokumen ini berfokus pada praktik yang spesifik untuk Google Cloud atau sangat relevan saat menggunakan SSH di Google Cloud. Dokumen ini tidak mencakup praktik terbaik untuk implementasi server atau klien SSH tertentu.
Memperlakukan kunci pribadi SSH mirip dengan kunci akun layanan
Beberapa instance VM Anda mungkin memiliki akun layanan yang disertakan. Dengan memasang akun layanan ke VM, beban kerja yang berjalan di VM ini dapat meminta token akses berumur pendek dari server metadata sehingga dapat mengakses API dan resource. Google Cloud
Saat terhubung ke VM dengan akun layanan terpasang menggunakan SSH, Anda juga dapat meminta token akses berumur pendek dari server metadata. Oleh karena itu, memberi pengguna akses SSH ke VM mirip dengan memberi pengguna izin untuk bertindak sebagai akun layanan terlampir. Karena kesamaan tersebut, perlakukan kunci pribadi SSH, terutama jika tidak dilindungi frasa sandi, seperti kunci akun layanan: Kedua jenis kunci tersebut, jika bocor, dapat memberi pihak tidak bertanggung jawab akses ke resource Google Cloud.
Menggunakan kunci SSH sementara untuk pengguna mesin
Pipeline deployment atau proses otomatisasi mungkin memerlukan akses SSH ke instance VM untuk melakukan deployment atau menerapkan perubahan konfigurasi. Daripada mengizinkan workload ini menggunakan pasangan kunci SSH yang berumur panjang, izinkan workload tersebut menggunakan kunci SSH baru yang bersifat sementara setiap kali dijalankan.
Untuk menggunakan kunci SSH sementara, izinkan pipeline deployment atau proses otomatisasi Anda melakukan langkah-langkah berikut:
- Lakukan autentikasi sebagai akun layanan dengan cara yang tidak melibatkan kunci atau secret, misalnya dengan menggunakan akun layanan terlampir atau gabungan Workload Identity.
- Buat pasangan kunci SSH sementara menggunakan alat seperti
ssh-keygen
. Publikasikan kunci publik ke Google Cloud, dengan menentukan tanggal habis masa berlaku dalam waktu dekat (seperti 1 jam ke depan).
Login OS memungkinkan Anda menentukan tanggal habis masa berlaku kunci saat memublikasikan kunci. Demikian pula, Anda dapat menentukan tanggal habis masa berlaku saat memublikasikan kunci publik SSH ke metadata project atau VM.
Gunakan kunci pribadi untuk membuat koneksi SSH ke instance VM.
Jika perlu, batalkan publikasi kunci publik dan hapus kunci pribadi.
Contoh:
# Generate RSA key pair without passphrase
ssh-keygen -t rsa -f ephemeral_key -q -N "" -V 30m
# Publish key to the service account's OS Login profile, with 30 min expiry
gcloud compute os-login ssh-keys add --key-file ephemeral_key.pub --ttl 30m
# Look up the service account's UNIX username
USERNAME=$(gcloud compute os-login describe-profile --format "value(posixAccounts[0].username)")
# Authenticate using the service account's UNIX user and public key
ssh $USERNAME@VM whoami
# Remove key
gcloud compute os-login ssh-keys remove --key-file ephemeral_key.pub
Meskipun kunci pribadi SSH sementara mungkin masih bocor, kunci tersebut hanya dapat digunakan untuk waktu yang singkat. Oleh karena itu, penggunaan kunci SSH sementara dapat mengurangi risiko kebocoran kredensial, dan memungkinkan Anda menggunakan Cloud IAM sebagai cara utama autentikasi dan otorisasi.
Menggunakan IAP untuk melengkapi autentikasi kunci publik SSH
Secara default, kunci pribadi SSH dapat digunakan secara terpisah dari kredensial Google: Jika kunci SSH pribadi pengguna bocor, pihak tidak bertanggung jawab dapat menggunakan kunci tersebut untuk terhubung dan mengautentikasi ke instance VM mana pun yang diizinkan untuk diakses oleh kunci tersebut. Pelaku kejahatan tidak perlu mengetahui nama pengguna atau sandi pengguna, atau bahkan memiliki kredensial Google apa pun.
Kontrol keamanan seperti verifikasi 2 langkah dan membatasi durasi sesi untuk Google Cloud layanan dapat menjadi cara efektif untuk mengurangi risiko pencurian kredensial, tetapi kontrol ini hanya berlaku untuk resource yang memerlukan kredensial Google.
Untuk memastikan kunci SSH tidak dapat digunakan tanpa kredensial Google yang valid, gunakan IAP untuk mengatur akses SSH dan gunakan kebijakan firewall untuk mewajibkan semua akses SSH dilakukan melalui IAP.
IAP bertindak sebagai reverse proxy dan hanya mengizinkan pengguna untuk membuat koneksi SSH ke instance VM jika mereka berhasil diautentikasi menggunakan kredensial Google mereka. Selain itu, IAP memungkinkan Anda membatasi VM yang dapat dihubungkan pengguna, dan menerapkan akses kontekstual.
Menggunakan autentikasi multi-faktor
Menggunakan IAP untuk mengatur akses SSH akan mempersulit pelaku kejahatan untuk mengakses instance VM menggunakan kredensial yang bocor, tetapi tidak membuatnya tidak mungkin: Misalnya, pelaku kejahatan dapat membahayakan workstation dan menemukan kunci SSH pribadi dan kredensial gcloud CLI yang di-cache, yang cukup untuk lulus pemeriksaan otentikasi dan otorisasi IAP, serta terhubung ke instance VM pengguna.
Anda dapat mengurangi kemungkinan dampak dari serangan pencurian kredensial tersebut dengan mengonfigurasi Cloud Identity atau Google Workspace untuk mewajibkan autentikasi multi-faktor (MFA).
Jika Cloud Identity atau Google Workspace adalah penyedia identitas utama Anda, lakukan penerapan MFA berikut:
- Konfigurasikan Cloud Identity atau Google Workspace untuk menerapkan verifikasi 2 langkah.
- Batasi durasi sesi untuk Google Cloud layanan sehingga kredensial yang di-cache otomatis menjadi tidak valid dan pengguna harus melakukan autentikasi ulang dan MFA secara berkala.
Jika Anda menggunakan single sign-on dengan IdP eksternal, lakukan tindakan berikut:
- Konfigurasikan Cloud Identity atau Google Workspace untuk membatasi durasi sesi untuk Google Cloud layanan sehingga kredensial yang di-cache otomatis menjadi tidak valid dan pengguna harus melakukan autentikasi ulang secara berkala menggunakan IdP eksternal.
- Konfigurasikan IdP eksternal Anda untuk mewajibkan MFA, dan batasi durasi sesi sehingga pengguna harus melakukan MFA setiap kali Google Cloud sesi mereka berakhir.
Untuk memastikan bahwa MFA juga berlaku untuk akses SSH, Anda juga harus melakukan setidaknya salah satu hal berikut:
- Gunakan IAP untuk mengontrol akses jaringan sehingga pengguna harus melakukan MFA secara berkala untuk memperbarui kredensial Google mereka.
- Aktifkan 2FA Login OS untuk setiap instance VM atau seluruh project sehingga pengguna harus melakukan MFA setiap kali mereka membuat koneksi SSH.
Pengguna yang memiliki Compute Instance Admin atau peran yang setara untuk instance VM atau project dapat menonaktifkan 2FA Login OS dengan mengubah metadata instance. Oleh karena itu, efektivitas OS Login 2FA terbatas jika Anda juga tidak menerapkan MFA di Cloud Identity atau IdP eksternal.
Menggunakan kunci pribadi yang tidak dapat diekspor atau dilindungi frasa sandi
Banyak klien SSH secara default menyimpan kunci pribadi SSH sebagai file di disk. Misalnya,
gcloud compute ssh
membuat pasangan kunci SSH saat pertama kali digunakan, dan menyimpannya di
direktori utama Anda. Sistem operasi Anda mungkin melindungi file agar tidak diakses
oleh pengguna lain, tetapi jika pihak tidak bertanggung jawab dapat mengatasi izin sistem file (misalnya, dengan menyalin dan memasang disk di komputer lain), mereka dapat menyalin
kunci di tempat lain, dan menggunakannya tanpa sepengetahuan Anda.
Beberapa klien SSH memungkinkan Anda menghindari penggunaan kunci berbasis file dan menawarkan opsi alternatif untuk mengelola kunci pribadi SSH, seperti:
- Menggunakan kunci yang didukung hardware: OpenSSH versi modern memungkinkan Anda menggunakan kunci keamanan FIDO2 untuk autentikasi, dan Anda dapat mengonfigurasi Login OS sehingga hanya mengizinkan kunci keamanan yang terdaftar di Cloud Identity atau Google Workspace. Menggunakan kunci yang didukung hardware membantu Anda menghindari penyimpanan materi kunci pribadi di sistem file komputer.
- Menggunakan fasilitas penyimpanan kunci sistem operasi Anda: Misalnya, IAP Desktop menghindari penggunaan kunci berbasis file dan sebagai gantinya menggunakan Windows CNG untuk melindungi kunci SSH Anda.
Jika menggunakan kunci yang didukung hardware atau dikelola sistem operasi bukan merupakan opsi, Anda dapat menggunakan frasa sandi untuk melindungi kunci pribadi SSH: Untuk menggunakan kunci SSH yang dilindungi frasa sandi, pelaku kejahatan tidak hanya memerlukan salinan kunci pribadi, tetapi juga harus mengetahui frasa sandi kunci.
Menggunakan kunci host untuk mengautentikasi host
Saat membuat koneksi SSH ke instance VM, Anda mengidentifikasi instance VM dengan nama atau alamat IP-nya. Nama dan alamat IP dapat ditetapkan ulang dan digunakan kembali, dan nama yang merujuk ke instance VM tertentu kemarin mungkin tidak merujuk ke instance VM yang sama hari ini. Pelaku kejahatan mungkin sengaja menetapkan ulang atau menggunakan kembali nama atau alamat IP untuk menipu instance VM dan memancing pengguna agar terhubung ke VM yang disusupi.
Klien SSH dapat mendeteksi situasi saat instance VM yang sebelumnya tepercaya diganti dengan instance VM yang berbeda menggunakan kunci host SSH: Kunci host SSH VM dibuat saat pertama kali di-booting dan digunakan untuk mengidentifikasi instance. Klien SSH biasanya meminta dan menyimpan kunci host VM pada koneksi pertama dan memverifikasi bahwa kunci host VM belum berubah pada koneksi berikutnya.
Kunci host SSH berfungsi berdasarkan skema kepercayaan pada penggunaan pertama. Efektivitas kunci host SSH dapat dirusak jika pelaku kejahatan menggunakan serangan man in the middle (MITM) untuk mengizinkan klien terhubung ke dan memercayai VM yang salah saat pertama kali digunakan. Cara yang lebih baik untuk mendapatkan kunci host adalah dengan mendapatkannya melalui saluran samping tepercaya sebelum terhubung ke VM untuk pertama kalinya.
Anda dapat mengizinkan gcloud CLI mendapatkan kunci host melalui saluran balik dengan mengaktifkan atribut tamu di project Anda. gcloud CLI kemudian membaca kunci host VM sebelum Anda terhubung ke VM tersebut terlebih dahulu, dan menyimpannya di komputer lokal.
Jangan tinggalkan kredensial pribadi di VM
Saat Anda memberi otorisasi gcloud CLI, alat ini akan mendapatkan token refresh OAuth dan menyimpannya di direktori beranda lokal Anda. Saat Anda kemudian menjalankan perintah gcloud CLI, gcloud CLI akan menggunakan token refresh untuk mengautentikasi Anda secara otomatis.
Komputer lokal Anda mungkin tidak dapat diakses oleh pengguna lain, tetapi pada instance VM, direktori rumah Anda juga dapat diakses oleh pengguna lain yang memiliki hak istimewa sudo di VM.
Jika pelaku kejahatan berhasil mendapatkan hak istimewa sudo di VM, mereka dapat memindai token refresh dan kredensial lainnya di direktori utama pengguna lain, dan menggunakan kredensial ini untuk mengeskalasikan hak istimewa atau memperluas akses mereka ke resource lain (gerakan lateral).
Saat Anda terhubung ke instance VM melalui SSH, hindari memberikan otorisasi ke gcloud CLI atau Kredensial Default Aplikasi (ADC) dengan kredensial pribadi Anda, dan izinkan gcloud CLI menggunakan akun layanan yang terpasang di VM. Demikian pula, hindari menjalankan alat lain yang mungkin menyimpan kredensial pribadi di direktori utama Anda.
Anda dapat lebih mengurangi risiko dengan membatasi durasi sesi untuk Google Cloud layanan sehingga token refresh OAuth yang disimpan akan otomatis berakhir masa berlakunya setelah jangka waktu tertentu.
Jangan kirimkan kunci pribadi SSH ke repositori kode sumber
Beberapa alat otomatisasi seperti Ansible menggunakan SSH untuk mengakses dan mengelola instance VM. Karena alat tersebut mungkin memiliki akses ke banyak instance VM (dan akun layanan yang terlampir), kunci pribadi SSH yang digunakan oleh alat tersebut dapat sangat sensitif.
Jika Anda mengirimkan kunci pribadi SSH ke repositori kode sumber, ada peningkatan risiko bahwa kunci menjadi dapat diakses oleh pengguna yang tidak sah dan pihak tidak bertanggung jawab:
- Pihak tidak bertanggung jawab dapat memindai kode sumber repositori sumber publik untuk menemukan kunci yang bocor.
- Di masa mendatang, Anda dapat memutuskan untuk mengubah repositori sumber pribadi menjadi repositori publik, tanpa memeriksanya untuk kunci terlebih dahulu.
- Anggota tim lain mungkin menyimpan salinan kode sumber di workstation mereka.
Untuk mengurangi risiko ini, simpan kunci pribadi SSH di lokasi aman yang terpisah dari kode sumber dan gunakan kunci SSH sementara jika memungkinkan.
Langkah berikutnya
- Lanjutkan membaca tentang praktik terbaik untuk mengaudit akses SSH