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 diotentikasi oleh sesuatu yang mereka miliki, yang merupakan kunci pribadi SSH. Jika pengguna kunci pribadi tidak diamankan dengan baik, kunci itu bisa jatuh ke tangan pihak tidak bertanggung jawab. yang dapat 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:

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

Memperlakukan kunci pribadi SSH mirip dengan kunci akun layanan

Beberapa instance VM Anda mungkin memiliki terlampir akun layanan. Memasang akun layanan ke VM memungkinkan workload berjalan VM ini meminta token akses berumur pendek dari server metadata agar mereka dapat mengakses API dan resource Google Cloud.

Saat terhubung ke VM dengan akun layanan yang terpasang menggunakan SSH, Anda dapat juga meminta token akses berumur pendek dari metadata server. Oleh karena itu, memberikan akses SSH kepada pengguna ke VM mirip dengan memberi pengguna izin untuk bertindak sebagai akun layanan yang terlampir. Karena kesamaan itu, perlakukan kunci pribadi SSH, terutama jika tidak dilindungi frasa sandi, seperti kunci akun layanan: Kedua jenis kunci, jika bocor, dapat memberikan akses ke Google Cloud kepada pihak tidak bertanggung jawab Google Cloud Platform.

Menggunakan kunci SSH efemeral untuk pengguna mesin

Pipeline deployment atau proses otomatisasi mungkin memerlukan akses SSH ke instance VM untuk melakukan deployment atau menerapkan perubahan konfigurasi. Alih-alih membiarkan menggunakan pasangan kunci SSH yang berumur panjang, memungkinkan mereka menggunakan kunci SSH efemeral baru setiap kali dijalankan.

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

  1. Melakukan otentikasi sebagai akun layanan dengan cara yang tidak melibatkan kunci atau rahasia, misalnya, menggunakan akun layanan terlampir atau federasi identitas workload.
  2. Buat pasangan kunci SSH sementara menggunakan alat seperti ssh-keygen.

  3. Memublikasikan kunci publik ke Google Cloud, dengan menentukan rencana jangka panjang tanggal habis masa berlaku (misalnya 1 jam pada masa mendatang).

    Login OS memungkinkan Anda menentukan tanggal habis masa berlaku kunci saat Anda memublikasikan kunci. Demikian pula, Anda dapat menentukan tanggal habis masa berlaku saat Anda memublikasikan kunci publik SSH ke metadata project atau VM.

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

  5. 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 efemeral masih bocor, kunci itu hanya dapat digunakan untuk waktu yang singkat. Oleh karena itu, menggunakan kunci SSH {i>ephemeral<i} dapat mengurangi risiko Anda kebocoran kredensial, dan memungkinkan Anda menggunakan Cloud IAM sebagai cara otentikasi 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 itu untuk terhubung dan mengautentikasi ke instance VM apa pun yang dapat diakses oleh kunci tersebut. Penting penjahat tidak perlu mengetahui nama pengguna atau {i>password<i} pengguna, atau bahkan memiliki kredensial Google.

Kontrol keamanan seperti verifikasi dua langkah dan membatasi durasi sesi untuk layanan Google Cloud 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 menggunakan kebijakan firewall untuk menegakkan bahwa semua akses SSH dilakukan melalui IAP.

IAP bertindak sebagai {i>reverse proxy<i} dan hanya mengizinkan pengguna untuk membuat koneksi SSH ke terhadap instance VM jika berhasil diautentikasi menggunakan kredensial Google mereka. Selain itu, IAP memungkinkan Anda membatasi VM mana yang dapat terhubung oleh pengguna, dan menerapkan akses kontekstual.

Menggunakan autentikasi multi-faktor

Menggunakan IAP untuk mengatur akses SSH akan mempersulit pihak tidak bertanggung jawab untuk mengakses instance VM menggunakan kredensial yang bocor, tetapi tidak membuatnya tidak mungkin dilakukan: Misalnya, pihak tidak bertanggung jawab dapat menyusupi sebuah {i>workstation<i} dan menemukan kunci SSH pribadi dan kredensial gcloud CLI yang di-cache – cukup untuk lulus pemeriksaan otentikasi dan otorisasi IAP, dan menghubungkan ke instance VM pengguna.

Anda dapat mengurangi kemungkinan dampak serangan pencurian kredensial dengan mengonfigurasi Cloud Identity atau Google Workspace yang memerlukan multi-faktor autentikasi (MFA).

Jika Cloud Identity atau Google Workspace adalah penyedia identitas utama Anda, lakukan hal berikut untuk menerapkan MFA:

  1. Mengonfigurasi Cloud Identity atau Google Workspace untuk menerapkan verifikasi 2 langkah.
  2. Membatasi durasi sesi untuk layanan Google Cloud sehingga kredensial yang di-cache secara otomatis menjadi tidak valid dan pengguna harus melakukan otentikasi ulang dan melakukan MFA secara berkala.

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

  1. Mengonfigurasi Cloud Identity atau Google Workspace untuk membatasi durasi sesi untuk layanan Google Cloud sehingga kredensial yang di-cache secara otomatis menjadi 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 bahwa pengguna harus melakukan MFA setiap kali sesi Google Cloud mereka berakhir.

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

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

Pengguna yang memiliki Admin Instance Compute atau peran yang setara untuk instance VM atau project dapat menonaktifkan OS Login 2FA dengan mengubah metadata instance. Tujuan Efektivitas Login OS 2FA dibatasi jika Anda 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 pada penggunaan pertama, dan menyimpannya dalam {i>home<i} Anda. Sistem operasi Anda dapat melindungi file Anda agar tidak dapat diakses oleh pengguna lain, tetapi jika pihak tidak bertanggung jawab dapat mengatasi izin akses sistem file (untuk dengan menyalin dan memasang {i>disk <i}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: Versi modern OpenSSH memungkinkan Anda menggunakan FIDO2 kunci keamanan 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 perangkat keras membantu Anda menghindari penyimpanan materi kunci pribadi apa pun di sistem file komputer Anda.
  • Menggunakan fasilitas penyimpanan kunci sistem operasi Anda: Misalnya, Desktop IAP menghindari penggunaan kunci berbasis file dan Windows CNG untuk melindungi kunci SSH Anda.

Jika menggunakan kunci yang didukung perangkat keras atau yang dikelola sistem operasi tidak tersedia, Anda dapat menggunakan frasa sandi untuk melindungi kunci pribadi SSH Anda: Untuk menggunakan kunci SSH, penjahat tidak hanya membutuhkan salinan kunci pribadi, tetapi juga perlu mengetahui frase sandi kunci.

Menggunakan kunci host untuk mengautentikasi host

Saat Anda membuat koneksi SSH ke instance VM, Anda mengidentifikasi instance VM menurut 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 instance VM yang sama saat ini. Pihak tidak bertanggung jawab dapat dengan sengaja menetapkan kembali atau menggunakan kembali nama atau alamat IP untuk melakukan spoofing terhadap instance VM dan memikat pengguna agar terhubung ke VM yang disusupi.

Klien SSH dapat mendeteksi situasi ketika instance VM yang dipercaya sebelumnya diganti dengan instance VM lain dengan menggunakan kunci host SSH: Host SSH VM dibuat saat {i>booting<i} pertama dan digunakan untuk mengidentifikasi {i>instance<i}. Klien SSH biasanya meminta dan menyimpan kunci host VM pada koneksi pertama dan kunci host VM tidak berubah pada koneksi berikutnya.

Kunci host SSH berfungsi berdasarkan kepercayaan pada penggunaan pertama skema baru. Efektivitas kunci {i>host<i} SSH dapat berkurang jika pihak tidak bertanggung jawab menggunakan serangan {i>man in the middle<i} (MITM) untuk memungkinkan klien terhubung dan mempercayai orang yang salah VM pada penggunaan pertama. Cara yang lebih baik untuk mendapatkan kunci host adalah dengan mendapatkannya melalui jaringan saluran samping sebelum terhubung ke VM untuk pertama kalinya.

Anda dapat mengizinkan gcloud CLI mendapatkan kunci host melalui saluran belakang dengan mengaktifkan atribut tamu dalam proyek Anda. gcloud CLI kemudian membaca kunci host VM sebelum Anda terhubung ke sana terlebih dahulu, dan menyimpannya di komputer lokal Anda.

Jangan tinggalkan kredensial pribadi di VM

Saat Anda mengotorisasi gcloud CLI, alat ini mendapatkan token refresh OAuth dan menyimpannya di direktori {i>home<i} lokal Anda. Ketika kemudian menjalankan gcloud CLI gcloud CLI menggunakan token refresh untuk mengautentikasi Anda secara otomatis.

Komputer lokal Anda mungkin tidak dapat diakses oleh pengguna lain, tetapi pada {i>instance<i} VM, direktori {i>home<i} Anda juga dapat diakses oleh pengguna lain yang memiliki {i>sudo<i} mendapatkan hak istimewa di VM.

Jika pihak tidak bertanggung jawab berhasil mendapatkan hak istimewa {i>sudo<i} di VM, mereka mungkin memindai token refresh dan kredensial lainnya di akun pengguna lain direktori {i>home<i}, 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, jangan mengizinkan gcloud CLI atau {i>Application Default Credentials <i}(ADC) dengan kredensial pribadi Anda, dan biarkan gcloud CLI menggunakan akun layanan VM yang terpasang. Demikian pula, hindari menjalankan alat lain yang mungkin menyimpan kredensial pribadi di direktori {i>home<i} Anda.

Anda dapat mengurangi risiko lebih lanjut dengan membatasi durasi sesi untuk layanan Google Cloud sehingga token penyegaran OAuth yang disimpan 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 instance akun layanan), kunci pribadi SSH yang digunakan oleh alat tersebut bisa sangat sensitif.

Jika Anda mengirim kunci pribadi SSH ke repositori kode sumber, terdapat peningkatan risiko bahwa kunci tersebut dapat diakses oleh pengguna yang tidak sah dan aktor:

  • Pihak tidak bertanggung jawab dapat memindai kode sumber repositori sumber publik untuk menemukan kunci yang bocor.
  • Di masa mendatang, Anda mungkin memutuskan untuk mengubah repositori sumber pribadi menjadi repositori data, 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 menggunakan kunci SSH {i>ephemeral<i} jika memungkinkan.

Langkah selanjutnya