Praktik terbaik untuk melindungi kredensial SSH

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 kunci pribadi yang bocor:

Dokumen ini berfokus pada praktik yang spesifik untuk Google Cloud atau sangat relevan saat menggunakan SSH di Google Cloud. Dokumen ini tidak membahas praktik terbaik untuk implementasi klien atau server SSH tertentu.

Memperlakukan kunci pribadi SSH seperti kunci akun layanan

Beberapa instance VM Anda mungkin memiliki akun layanan terlampir. Melampirkan akun layanan ke VM memungkinkan workload yang berjalan di VM ini meminta token akses berjangka pendek dari server metadata sehingga dapat mengakses Google Cloud API dan resource.

Saat terhubung ke VM dengan akun layanan terlampir menggunakan SSH, Anda juga dapat meminta token akses berjangka pendek dari server metadata. Oleh karena itu, memberikan akses SSH kepada pengguna ke VM sama dengan memberikan izin kepada pengguna 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 memberikan akses kepada pihak tidak bertanggung jawab ke Google Cloud resource.

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 berjangka panjang, izinkan workload tersebut menggunakan kunci SSH sementara yang baru setiap kali dijalankan.

Untuk menggunakan kunci SSH sementara, izinkan pipeline deployment atau proses otomatisasi Anda melakukan langkah-langkah berikut:

  1. Autentikasi sebagai akun layanan dengan cara yang tidak melibatkan kunci atau secret, misalnya dengan menggunakan akun layanan terlampir atau workload identity federation.
  2. Buat pasangan kunci SSH sementara menggunakan alat seperti ssh-keygen.

  3. Publikasikan kunci publik ke Google Cloud, dengan menentukan tanggal habis masa berlaku yang tidak terlalu lama (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.

  4. Gunakan kunci pribadi untuk membuat koneksi SSH ke instance VM.

  5. Secara opsional, 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 masih dapat bocor, kunci tersebut hanya dapat digunakan dalam waktu 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 independen dari kredensial Google: Jika kunci SSH pribadi pengguna bocor, pihak tidak bertanggung jawab dapat menggunakan kunci tersebut untuk terhubung dan melakukan autentikasi ke instance VM mana pun yang diizinkan untuk diakses oleh kunci tersebut. Pihak tidak bertanggung jawab tidak perlu mengetahui nama pengguna atau sandi pengguna, atau bahkan memiliki kredensial Google apa pun.

Kontrol keamanan seperti verifikasi dua langkah dan membatasi durasi sesi untuk Google Cloud layanan dapat menjadi cara yang efektif untuk mengurangi risiko pencurian kredensial, tetapi kontrol ini hanya berlaku untuk resource yang memerlukan kredensial Google.

Untuk memastikan bahwa kunci SSH tidak dapat digunakan tanpa kredensial Google yang valid, gunakan IAP untuk mengatur akses SSH dan gunakan kebijakan firewall untuk memastikan bahwa semua akses SSH dilakukan melalui IAP.

IAP bertindak sebagai proxy terbalik dan hanya mengizinkan pengguna membuat koneksi SSH ke instance VM jika mereka berhasil melakukan autentikasi menggunakan kredensial Google mereka. Selain itu, IAP memungkinkan Anda membatasi VM yang dapat terhubung dengan pengguna, dan menerapkan akses berbasis konteks.

Menggunakan autentikasi multi-faktor

Menggunakan IAP untuk mengatur akses SSH akan mempersulit pihak tidak bertanggung jawab mengakses instance VM menggunakan kredensial yang bocor, tetapi tidak membuatnya mustahil: Misalnya, pihak tidak bertanggung jawab dapat membobol workstation dan menemukan kunci SSH pribadi dan kredensial gcloud CLI yang di-cache – cukup untuk lulus pemeriksaan autentikasi dan otorisasi IAP, serta terhubung ke instance VM pengguna.

Anda dapat mengurangi kemungkinan dampak 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 hal berikut untuk menerapkan MFA:

  1. Konfigurasi Cloud Identity atau Google Workspace untuk mewajibkan verifikasi 2 langkah.
  2. Batasi durasi sesi untuk Google Cloud layanan sehingga kredensial yang di-cache otomatis tidak valid dan pengguna harus melakukan autentikasi ulang secara berkala dan melakukan MFA.

Jika Anda menggunakan single sign-on dengan IdP eksternal, lakukan hal berikut:

  1. Konfigurasi Cloud Identity atau Google Workspace untuk membatasi durasi sesi untuk Google Cloud layanan sehingga kredensial yang di-cache otomatis tidak valid dan pengguna harus melakukan autentikasi ulang secara berkala menggunakan IdP eksternal.
  2. Konfigurasi IdP eksternal Anda untuk mewajibkan MFA, dan batasi durasi sesinya sehingga pengguna harus melakukan MFA setiap kali sesi Google Cloud mereka berakhir.

Untuk memastikan MFA juga berlaku untuk akses SSH, Anda juga harus melakukan setidaknya salah satu hal berikut:

  1. Gunakan IAP untuk mengontrol akses jaringan sehingga pengguna harus melakukan MFA secara berkala untuk memperbarui kredensial Google mereka.
  2. Aktifkan Login OS 2FA untuk instance VM individual atau seluruh project sehingga pengguna harus melakukan MFA setiap kali membuat koneksi SSH.

Pengguna yang memiliki Admin Instance Compute atau peran yang setara untuk instance VM atau project dapat menonaktifkan Login OS 2FA dengan mengubah metadata instance. Oleh karena itu, efektivitas Login OS 2FA terbatas jika Anda tidak juga menerapkan MFA di Cloud Identity atau IdP eksternal Anda.

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 beranda Anda. Sistem operasi Anda mungkin melindungi file Anda agar tidak dapat 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 ke 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: Versi modern OpenSSH 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 apa pun di sistem file komputer Anda.
  • Menggunakan fasilitas penyimpanan kunci sistem operasi Anda: Misalnya, IAP Desktop menghindari penggunaan kunci berbasis file dan menggunakan Windows CNG untuk melindungi kunci SSH Anda.

Jika penggunaan kunci yang didukung hardware atau dikelola sistem operasi bukan merupakan opsi, Anda dapat menggunakan frasa sandi untuk melindungi kunci pribadi SSH Anda: Untuk menggunakan kunci SSH yang dilindungi frasa sandi, pihak tidak bertanggung jawab tidak hanya memerlukan salinan kunci pribadi, tetapi juga perlu mengetahui frasa sandi kunci.

Menggunakan kunci host untuk mengautentikasi host

Saat membuat koneksi SSH ke instance VM, Anda mengidentifikasi instance VM berdasarkan 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. Pihak tidak bertanggung jawab dapat dengan sengaja menetapkan ulang atau menggunakan kembali nama atau alamat IP untuk memalsukan instance VM dan memikat pengguna agar terhubung ke VM yang dibobol.

Klien SSH dapat mendeteksi situasi saat instance VM yang sebelumnya tepercaya diganti dengan instance VM lain menggunakan kunci host SSH: Kunci host SSH VM dibuat saat booting pertama dan digunakan untuk mengidentifikasi instance. Klien SSH biasanya meminta dan menyimpan kunci host VM pada koneksi pertama dan memverifikasi bahwa kunci host VM tidak berubah pada koneksi berikutnya.

Kunci host SSH berfungsi berdasarkan skema kepercayaan saat pertama kali digunakan. Efektivitas kunci host SSH dapat dirusak jika pihak tidak bertanggung jawab menggunakan serangan man-in-the-middle (MITM) untuk memungkinkan klien terhubung dan mempercayai 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 belakang dengan mengaktifkan atribut tamu di project Anda. gcloud CLI kemudian membaca kunci host VM sebelum Anda terhubung ke VM untuk pertama kalinya, dan menyimpannya di komputer lokal Anda.

Tidak menyimpan kredensial pribadi di VM

Saat Anda mengotorisasi gcloud CLI, alat ini akan mendapatkan token refresh OAuth dan menyimpannya di direktori beranda lokal Anda. Saat Anda menjalankan perintah gcloud CLI berikutnya, gcloud CLI akan menggunakan token refresh untuk mengautentikasi Anda secara otomatis.

Komputer lokal Anda mungkin tidak dapat diakses oleh pengguna lain, tetapi di instance VM, direktori beranda Anda juga dapat diakses oleh pengguna lain yang memiliki hak istimewa sudo di VM.

Jika pihak tidak bertanggung jawab berhasil mendapatkan hak istimewa sudo di VM, mereka dapat memindai token refresh dan kredensial lainnya di direktori beranda pengguna lain, dan menggunakan kredensial ini untuk meningkatkan hak istimewa mereka atau memperluas akses mereka ke resource lain (pergerakan lateral).

Saat Anda terhubung ke instance VM melalui SSH, hindari mengotorisasi gcloud CLI atau Kredensial Default Aplikasi (ADC) dengan kredensial pribadi Anda, dan izinkan gcloud CLI menggunakan akun layanan terlampir VM. Demikian pula, hindari menjalankan alat lain yang mungkin menyimpan kredensial pribadi di direktori beranda Anda.

Anda dapat mengurangi risiko lebih lanjut dengan membatasi durasi sesi untuk Google Cloud layanan sehingga token refresh OAuth yang disimpan otomatis berakhir setelah jangka waktu tertentu.

Tidak mengirimkan 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 terlampirnya), kunci pribadi SSH yang digunakan oleh alat tersebut dapat menjadi 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