Praktik terbaik untuk mengontrol akses login SSH

Dokumen ini menjelaskan praktik terbaik untuk mengontrol akses login SSH ke instance virtual machine (VM) Linux.

Untuk mengelola akses SSH ke instance VM secara efektif, Anda harus mengizinkan akses pengguna ketika mereka membutuhkannya, dan mencabut akses itu ketika mereka tidak membutuhkannya lagi. Jika proses Anda untuk mencabut akses tidak dapat diandalkan atau tidak mencakup semua sumber daya, maka pihak tidak bertanggung jawab mungkin dapat mempertahankan akses bahkan setelah mereka seharusnya sudah dicabut.

Bagian berikut berisi praktik terbaik yang membantu Anda memastikan akses yang efektif pencabutan dan melindungi dari ancaman persistensi:

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.

Menggunakan Login OS untuk memastikan evaluasi akses berkelanjutan terhadap kebijakan IAM

Image Linux publik Compute Engine dikonfigurasi untuk mengizinkan otentikasi kunci publik SSH. Untuk mengotorisasi kunci publik pengguna dan memberikan izin akses untuk membuat sesi SSH, Anda dapat menggunakan salah satu dua mekanisme:

  • Otorisasi kunci berbasis metadata: Sebagai administrator, Anda mengupload kunci publik pengguna ke metadata project atau VM atau Anda membiarkan pengguna melakukan upload dengan memberi mereka izin untuk memodifikasi {i>metadata.<i}

    Kunci publik yang diupload ke metadata satu VM memberikan hak istimewa root pengguna ke VM saja; kunci yang diunggah ke metadata proyek memberikan akses pengguna ke semua VM dalam project.

  • Otorisasi kunci Login OS: Sebagai pengguna, Anda mengunggah satu atau beberapa kunci publik ke profil {i> Login<i} OS Anda, yang merupakan bagian dari akun pengguna Google Anda.

    Sebagai administrator, Anda dapat memutuskan apakah akan memberikan hak istimewa root pengguna atau hak istimewa pengguna reguler di VM dengan memberikan Peran IAM OS Login Admin User atau OS Login User Peran IAM.

    gcloud CLI, Konsol Google Cloud dalam browser Klien SSH, dan IAP Desktop otomatis mendeteksi mekanisme mana yang Anda gunakan dan dapat mengunggah kunci yang sesuai.

Perbedaan utama antara kedua mekanisme itu adalah ketika akses dievaluasi terhadap Kebijakan IAM:

  • Dengan kunci metadata, akses hanya dievaluasi sekali, pada saat upload kunci.

    Kunci pengguna terkait dengan siklus proses VM atau project, dan tetap valid hingga Anda menghapus kunci atau menghapus VM atau project. Menangguhkan atau menghapus akun pengguna tidak mempengaruhi validitas kunci mereka.

  • Dengan Login OS, akses dievaluasi setiap kali pengguna mencoba membangun melakukan sesi SSH.

    Kunci pengguna terkait dengan siklus proses akun pengguna mereka. Jika Anda menangguhkan atau menghapus pengguna di Cloud Identity atau Google Workspace, kunci mereka tidak dapat lagi digunakan untuk memberikan akses SSH.

Menggunakan kunci berbasis metadata dapat menimbulkan ancaman persistensi: Pengguna mungkin mempertahankan akses SSH lebih lama dari yang diperlukan jika kunci publiknya tidak dihapus dari {i>metadata<i} secara tepat waktu, dan mereka bahkan mungkin mempertahankan akses setelah meninggalkan organisasi. Meskipun Anda dapat mengurangi risiko ini dengan menelusuri {i>metadata<i} secara teratur, melakukannya bisa menjadi sulit di lingkungan yang lebih besar, dan mungkin tidak cukup karena kunci berbasis metadata memberikan hak istimewa root kepada pengguna.

Untuk membantu melindungi dari ancaman persistensi tersebut, jangan izinkan pengguna menggunakan kunci berbasis metadata. Sebagai gantinya, konfigurasikan project Anda untuk menerapkan penggunaan Login OS.

Gunakan kebijakan organisasi untuk menerapkan penggunaan Login OS yang konsisten

Login OS dikontrol oleh kunci metadata enable-oslogin: Menyetel enable-oslogin ke TRUE dalam metadata project atau instance akan mengaktifkan Login OS, menyetelnya ke FALSE akan menonaktifkan Login OS.

Untuk mengubah metadata level project, Anda memerlukan compute.projects.setCommonInstanceMetadata izin akses pada project. Izin ini adalah bagian dari Admin Instance Compute (roles/compute.instanceAdmin.v1) dan Compute Admin (roles/compute.admin). Demikian pula, memodifikasi level instance metadata memerlukan izin compute.instances.setMetadata pada masing-masing di seluruh instance VM.

Metadata level instance lebih diutamakan daripada metadata level project. Oleh karena itu, menyetel enable-oslogin ke TRUE dalam metadata project tidak cukup untuk menerapkan penggunaan Login OS di seluruh project: Pengguna dengan Admin Instance Compute akses instance yang setara ke instance VM dalam project dapat mengganti setelan Anda dengan menambahkan enable-oslogin=FALSE ke metadata instance VM.

Untuk menerapkan penggunaan Login OS yang konsisten, jangan mengandalkan setelan enable-oslogin ke TRUE dalam metadata project. Sebagai gantinya, terapkan metode Mengaktifkan Login OS untuk organisasi menggunakan kebijakan organisasi sehingga setiap upaya untuk menetapkan enable-oslogin ke false dalam instance atau project metadata ditolak.

Memberikan peran hak istimewa berbasis sementara atau per VM

Jika Anda memiliki instance VM yang menjalankan workload berbeda dan dikelola oleh Anda dapat menyederhanakan pengelolaan akses dengan men-deploy VM ini di berbagai Project Google Cloud, dan mengizinkan project tersebut menggunakan jaringan bersama. Tetapi menggunakan proyek terpisah tidak selalu layak dan beberapa proyek Anda mungkin berisi kombinasi instance VM, di mana instance VM yang berbeda hanya dapat diakses oleh pengguna yang berbeda.

Setiap kali project berisi kombinasi instance VM yang berbeda, hindari memberikan peran kepada pengguna secara permanen, seperti Admin Instance Compute di level project. Sebagai gantinya, bedakan antara akses hanya lihat dan akses istimewa:

  • Beri pengguna Compute Viewer atau peran hanya lihat yang setara pada project level organisasi. Peran ini memungkinkan pengguna menjelajahi VM menggunakan Konsol Google Cloud, tetapi tidak mengizinkan mereka memublikasikan kunci SSH atau mengakses VM.
  • Beri pengguna Login OS, Admin Instance Compute, atau hak istimewa lainnya kepada pengguna peran hanya untuk VM individu, atau hanya berdasarkan waktu.

Menangguhkan akun pengguna saat pengguna keluar dari organisasi

Menangguhkan atau menghapus akun pengguna di Cloud Identity atau Google Workspace secara otomatis akan mencabut izin IAM pengguna. Karena {i>Login OS<i} memeriksa izin akses IAM pengguna sebelum mengizinkan mereka untuk menetapkan sesi SSH, menangguhkan atau menghapus akun pengguna juga akan mencabut akses pengguna ke VM yang menggunakan Login OS.

Jika Anda telah mengonfigurasi Cloud Identity atau Google Workspace untuk digunakan IdP eksternal untuk Single Sign-On, maka karyawan akan memiliki akun pengguna IdP eksternal dan di Cloud Identity atau Google Workspace. Menonaktifkan atau menghapus akun pengguna karyawan di IdP eksternal mencabut kemampuan mereka dalam membuat sesi browser baru untuk mengakses layanan Google, tetapi tidak berdampak langsung pada Login OS: Selama akun Cloud Identity karyawan atau akun pengguna Google Workspace tetap aktif, Login OS akan terus memungkinkan pengguna untuk mengotentikasi dan membuat koneksi SSH.

Untuk mencabut akses SSH secara andal ketika pengguna keluar dari organisasi, pastikan untuk menangguhkan atau menghapus Cloud Identity atau Google Workspace mereka menggunakan akun layanan. Jika Anda menggunakan IdP eksternal, konfigurasikan untuk menerapkan peristiwa penangguhan pengguna sehingga {i>login<i} OS dapat mencabut akses.

Menghindari memberikan akses SSH ke VM yang memiliki akun layanan dengan hak istimewa

Jika instance VM memiliki terlampir akun layanan, maka aplikasi yang berjalan pada VM dapat meminta berumur pendek kredensial dari server metadata VM dan menggunakan kredensial ini untuk bertindak sebagai akun layanan.

Memiliki akses SSH ke VM memberi Anda hak istimewa yang serupa: Seperti aplikasi, Anda dapat meminta kredensial berumur pendek dari server metadata VM dan bertindak sebagai akun layanan yang terpasang.

Karena memiliki akses SSH ke VM dengan akun layanan yang terpasang, Anda dapat bertindak sebagai akun layanan, Login OS mengharuskan Anda memiliki iam.serviceAccounts.actAs izin pada akun layanan, dan memeriksa izin ini setiap kali Anda untuk terhubung ke instance VM. Dengan begitu, {i>login<i} OS membantu menjaga keamanan akun layanan dan mencegah penyalahgunaan akses SSH untuk eskalasi akses.

Untuk lebih mengurangi risiko yang terkait dengan VM yang memiliki layanan dengan hak istimewa Google, pertimbangkan alternatif berikut:

  • Jangan memasang akun layanan ke VM kecuali jika workload memerlukan akses ke resource Google Cloud.
  • Menggunakan akun layanan dengan satu tujuan dan hanya memberinya akses ke sumber daya yang dibutuhkan oleh beban kerja.
  • Wajibkan pengguna untuk meminta akses tepat waktu daripada memberi mereka akses ke VM dan akun layanan secara permanen.

Membatasi penggunaan hak istimewa root

Saat Anda menggunakan Login OS dan memberikan Pengguna Login OS (roles/compute.osLogin) kepada pengguna peran Anda, Anda menetapkan hak istimewa pengguna terbatas pada VM. Sebaliknya, saat Anda memberi pengguna OS Login Admin User (roles/compute.osAdminLogin) peran, menggunakan otorisasi kunci berbasis metadata alih-alih Login OS, atau mengizinkan pengguna memodifikasi metadata VM, Anda secara implisit memberikan hak istimewa {i>root<i} pengguna pada VM.

Memberikan hak istimewa root kepada pengguna di VM dapat menimbulkan risiko persistensi: Pengguna dapat menyalahgunakan hak istimewa ini untuk membuat akun pengguna baru atau menginstal pintu belakang, {i>backdoor<i} untuk mempertahankan akses yang persisten ke VM.

Untuk membantu mengurangi risiko persistensi ini, batasi penggunaan hak istimewa {i>root<i} dan hanya memberikan peran OS Login User (roles/compute.osLogin) saat hak istimewa root tidak diperlukan.

Buat profil POSIX terlebih dahulu untuk memastikan nama pengguna dan UID yang konsisten

Setiap VM Linux mengelola database lokal pengguna (/etc/passwd) dan grup (/etc/groups). Saat pertama kali terhubung ke VM Linux menggunakan SSH, lingkungan tamu secara otomatis membuat akun pengguna Linux untuk Anda, dan menetapkan UID.

Saat Anda menggunakan kunci berbasis metadata, lingkungan tamu tidak menautkan pengguna Linux ke akun pengguna Google Anda dan mungkin menetapkan UID yang berbeda pada setiap VM hubungkan. Jika Anda menggunakan protokol seperti NFS dengan UID yang konsisten di lingkungan yang tidak menerapkan UID yang konsisten di seluruh komputer, mungkin – secara tidak sengaja atau, dalam kasus pihak tidak bertanggung jawab, dengan sengaja - dapat melakukan akses jarak jauh sebagai pengguna yang berbeda.

Saat Anda menggunakan kunci berbasis metadata, lingkungan tamu juga memungkinkan Anda memilih nama pengguna yang ingin Anda gunakan. Jika Anda memilih nama pengguna yang sebelumnya digunakan oleh rekan kerja, Anda masuk dengan akun yang awalnya dibuat untuk rekan kerja Anda.

Anda dapat mencegah ambiguitas UID dan nama pengguna dengan menggunakan Login OS: Saat pertama kali login ke VM Linux menggunakan Login OS, lingkungan tamu membuat berdasarkan profil POSIX akun pengguna Google Anda. Profil POSIX berfungsi sebagai template untuk pengguna Linux dan menentukan hal berikut:

  • nama pengguna Linux yang unik di semua pengguna Cloud Identity yang sama atau akun Google Workspace
  • UID dan GID yang unik di semua project Google Cloud
  • jalur direktori {i>home<i}
  • konfigurasi tambahan, seperti login shell

Jika Akun Google Anda tidak memiliki profil POSIX saat pertama kali login, Login OS akan membuat akun secara otomatis untuk Anda.

Nama pengguna dan UID yang dialokasikan oleh Login OS bersifat unik dalam Google Cloud Anda tetapi mungkin tumpang tindih atau tidak konsisten dengan nama pengguna dan UID yang yang Anda gunakan di luar Google Cloud. Jika Anda memerlukan nama pengguna dan UID Login OS agar konsisten di seluruh lingkungan lain, sebaiknya jangan mengandalkan pembuatan profil. Sebagai gantinya, gunakan Directory API untuk membuat profil POSIX Login OS dan menetapkan nama pengguna, UID, dan GID kustom.

Langkah selanjutnya