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

Dokumen ini berfokus pada praktik yang spesifik untuk Trusted Cloud by S3NS atau sangat relevan saat menggunakan SSH di Trusted Cloud. Dokumen ini tidak mencakup praktik terbaik untuk penerapan klien atau server SSH tertentu.

Perlakukan kunci pribadi SSH seperti kunci akun layanan

Beberapa instance VM Anda mungkin memiliki akun layanan yang terlampir. Dengan memasang akun layanan ke VM, beban kerja yang berjalan di VM tersebut dapat meminta token akses yang berlaku singkat dari server metadata sehingga dapat mengakses API dan resource. Trusted 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 serupa dengan memberi pengguna izin untuk bertindak sebagai akun layanan yang terlampir. Karena kemiripan tersebut, perlakukan kunci pribadi SSH, terutama jika tidak dilindungi dengan frasa sandi, seperti kunci akun layanan: Kedua jenis kunci tersebut, jika bocor, dapat memberikan akses ke resource Trusted Cloud kepada pihak tidak bertanggung jawab.

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 membiarkan beban kerja ini menggunakan pasangan kunci SSH yang aktif dalam jangka waktu lama, biarkan beban kerja tersebut menggunakan kunci SSH sementara yang baru setiap kali dijalankan.

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

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

  3. Publikasikan kunci publik ke Trusted Cloud, dengan menentukan tanggal habis masa berlaku yang akan segera tiba (seperti 1 jam ke depan).

    Login OS memungkinkan Anda menentukan tanggal habis masa berlaku kunci saat Anda 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. 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 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 untuk 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 berwenang 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 layanan Trusted Cloud dapat menjadi cara 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 diautentikasi menggunakan kredensial Google mereka. Selain itu, IAP memungkinkan Anda membatasi VM yang dapat dihubungkan oleh pengguna, dan menerapkan akses kontekstual.

Menggunakan autentikasi multi-faktor

Menggunakan IAP untuk mengatur akses SSH membuat pihak tidak bertanggung jawab lebih sulit mengakses instance VM menggunakan kredensial yang bocor, tetapi tidak membuatnya mustahil: Misalnya, pihak tidak bertanggung jawab dapat membahayakan workstation dan menemukan kunci SSH pribadi dan kredensial gcloud CLI yang di-cache – cukup untuk melewati pemeriksaan otentikasi 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 menerapkan verifikasi 2 langkah.
  2. Batasi durasi sesi untuk layanan Trusted Cloud agar kredensial yang di-cache otomatis dibatalkan dan pengguna harus melakukan autentikasi ulang dan MFA secara berkala.

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

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

Untuk memastikan bahwa 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 2FA Login OS untuk setiap instance VM atau seluruh project sehingga pengguna harus melakukan MFA setiap kali mereka membuat koneksi SSH.

Pengguna yang memiliki peran 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 2FA Login OS 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 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: OpenSSH versi modern memungkinkan Anda menggunakan kunci keamanan FIDO2 untuk autentikasi, dan Anda dapat mengonfigurasi Login OS agar 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 menggunakan 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, pelaku jahat tidak hanya memerlukan salinan kunci pribadi, tetapi juga perlu mengetahui frasa sandi kunci tersebut.

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 memancing pengguna agar terhubung ke VM yang telah disusupi.

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 terganggu jika pelaku kejahatan menggunakan serangan man in the middle (MITM) untuk memungkinkan 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 belakang dengan mengaktifkan atribut tamu di project Anda. Kemudian, gcloud CLI akan membaca kunci host VM sebelum Anda terhubung ke VM untuk pertama kalinya, dan menyimpannya di komputer lokal Anda.

Jangan menyimpan kredensial pribadi di VM

Saat Anda mengizinkan gcloud CLI, alat ini akan mendapatkan token refresh OAuth dan menyimpannya di direktori beranda lokal Anda. Saat Anda menjalankan perintah gcloud CLI selanjutnya, 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 pelaku kejahatan 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 mengeskalasikan 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 biarkan gcloud CLI menggunakan akun layanan yang terlampir di VM. Demikian pula, hindari menjalankan alat lain yang dapat menyimpan kredensial pribadi di direktori beranda Anda.

Anda dapat mengurangi risiko lebih lanjut dengan membatasi durasi sesi untuk Trusted Cloud layanan sehingga token refresh OAuth yang disimpan akan otomatis berakhir 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 menjadi sangat sensitif.

Jika Anda mengirimkan kunci pribadi SSH ke repositori kode sumber, ada peningkatan risiko bahwa kunci tersebut 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