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 pengguna mengakses VM saat mereka membutuhkannya, dan mencabut akses tersebut saat mereka tidak membutuhkannya lagi. Jika proses Anda untuk mencabut akses tidak dapat diandalkan atau tidak mencakup semua resource, pihak tidak bertanggung jawab mungkin dapat mempertahankan akses meskipun akses mereka telah dicabut.

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

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.

Menggunakan Login OS untuk memastikan evaluasi akses berkelanjutan terhadap kebijakan IAM

Image Linux publik Compute Engine dikonfigurasi untuk mengizinkan autentikasi kunci publik SSH. Untuk memberikan otorisasi pada kunci publik pengguna dan memberinya izin untuk membuat sesi SSH, Anda dapat menggunakan salah satu dari dua mekanisme berikut:

  • Otorisasi kunci berbasis metadata: Sebagai administrator, Anda mengupload kunci publik pengguna ke metadata VM atau project atau Anda mengizinkan pengguna melakukan upload sendiri dengan memberi mereka izin untuk mengubah metadata.

    Kunci publik yang diupload ke metadata satu VM akan memberikan hak istimewa root kepada pengguna hanya untuk VM; kunci yang diupload ke metadata project akan memberikan akses kepada pengguna ke semua VM dalam project.

  • Otorisasi kunci Login OS: Sebagai pengguna, Anda mengunggah satu atau beberapa kunci publik ke profil Login OS, 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 Pengguna Admin Login OS atau peran IAM Pengguna Login OS.

    gcloud CLI, klien SSH dalam browser Konsol Google Cloud, dan IAP Desktop otomatis mendeteksi mekanisme yang Anda gunakan dan dapat mengupload kunci pengguna yang sesuai.

Perbedaan utama antara kedua mekanisme ini adalah saat akses dievaluasi berdasarkan kebijakan IAM:

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

    Kunci pengguna terikat dengan siklus proses VM atau project dan tetap valid hingga Anda menghapus kunci atau menghapus VM atau project. Menangguhkan atau menghapus akun pengguna tidak akan memengaruhi validitas kuncinya.

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

    Kunci pengguna terikat dengan siklus proses akun penggunanya. 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 mengekspos Anda ke ancaman persistensi: Pengguna mungkin mempertahankan akses SSH lebih lama dari yang diperlukan jika kunci publik mereka tidak dihapus dari metadata secara tepat waktu, dan mereka bahkan mungkin mempertahankan akses setelah keluar dari organisasi. Meskipun Anda dapat mengurangi risiko ini dengan memeriksa metadata secara rutin, tindakan tersebut dapat sulit dilakukan di lingkungan yang lebih besar, dan mungkin tidak memadai karena kunci berbasis metadata memberi pengguna hak istimewa root.

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

Menggunakan kebijakan organisasi untuk menerapkan penggunaan Login OS yang konsisten

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

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

Metadata level instance lebih diprioritaskan daripada metadata level project. Oleh karena itu, menetapkan enable-oslogin ke TRUE dalam metadata project tidak memadai untuk menerapkan penggunaan Login OS di seluruh project: Pengguna dengan Compute Instance Admin atau akses 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 Mengaktifkan Login OS untuk organisasi menggunakan kebijakan organisasi sehingga setiap upaya untuk menetapkan enable-oslogin ke false dalam metadata instance atau project ditolak.

Memberikan peran dengan hak istimewa secara sementara atau per VM

Jika memiliki instance VM yang menjalankan workload yang berbeda dan dikelola oleh tim yang berbeda, Anda dapat menyederhanakan pengelolaan akses dengan men-deploy VM ini di projectGoogle Cloud yang berbeda, dan mengizinkan project tersebut menggunakan jaringan bersama. Namun, menggunakan project terpisah tidak selalu memungkinkan dan beberapa project Anda mungkin berisi kombinasi instance VM, dengan 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 Compute Instance Admin di tingkat project. Sebagai gantinya, bedakan antara akses hanya lihat dan akses dengan hak istimewa:

  • Berikan peran Compute Viewer atau peran hanya lihat yang setara kepada pengguna di tingkat project. Peran ini memungkinkan pengguna menjelajahi VM menggunakan konsol Google Cloud, tetapi tidak mengizinkan mereka memublikasikan kunci SSH atau mengakses VM.
  • Berikan pengguna Compute Login OS, Compute Instance Admin, atau peran dengan hak istimewa lainnya hanya untuk setiap VM, atau hanya berdasarkan just-in-time.

Menangguhkan akun pengguna saat pengguna keluar dari organisasi

Menangguhkan atau menghapus akun pengguna di Cloud Identity atau Google Workspace akan otomatis mencabut izin IAM pengguna. Karena Login OS memeriksa izin IAM pengguna sebelum mengizinkannya membuat 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 menggunakan IdP eksternal untuk single sign-on, karyawan akan memiliki akun pengguna di IdP eksternal dan di Cloud Identity atau Google Workspace. Menonaktifkan atau menghapus akun pengguna karyawan di IdP eksternal Anda akan mencabut kemampuan mereka untuk membuat sesi browser baru guna mengakses layanan Google, tetapi tidak berdampak langsung pada Login OS: Selama akun pengguna Cloud Identity atau Google Workspace karyawan tetap aktif, Login OS akan terus mengizinkan pengguna mengautentikasi dan membuat koneksi SSH.

Untuk mencabut akses SSH dengan andal saat pengguna keluar dari organisasi, pastikan untuk menangguhkan atau menghapus akun pengguna Cloud Identity atau Google Workspace mereka. Jika Anda menggunakan IdP eksternal, konfigurasikan untuk menyebarkan peristiwa penangguhan pengguna sehingga Login OS dapat mencabut akses.

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

Jika instance VM memiliki akun layanan yang disertakan, aplikasi yang berjalan di VM dapat meminta kredensial berumur singkat 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 terlampir memungkinkan Anda bertindak sebagai akun layanan, Login OS mengharuskan Anda memiliki izin iam.serviceAccounts.actAs di akun layanan, dan memeriksa izin ini setiap kali Anda terhubung ke instance VM. Dengan begitu, Login OS membantu menjaga keamanan akun layanan dan mencegah akses SSH disalahgunakan untuk eskalasi akses.

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

  • Jangan lampirkan akun layanan ke VM kecuali jika beban kerja memerlukan akses ke resource Google Cloud .
  • Gunakan akun layanan tujuan tunggal dan hanya berikan akses ke resource yang diperlukan beban kerja.
  • Wajibkan pengguna untuk meminta akses tepat waktu, bukan memberi mereka akses ke VM dan akun layanan secara permanen.

Membatasi penggunaan hak istimewa root

Saat menggunakan Login OS dan memberi pengguna peran Pengguna Login OS (roles/compute.osLogin), Anda menetapkan hak istimewa pengguna terbatas kepada pengguna di VM. Sebaliknya, saat Anda memberikan peran OS Login Admin User (roles/compute.osAdminLogin) kepada pengguna, gunakan otorisasi kunci berbasis metadata, bukan Login OS, atau izinkan pengguna mengubah metadata VM, Anda secara implisit memberikan hak istimewa root kepada pengguna di VM.

Memberi pengguna hak istimewa root di VM dapat mengekspos Anda pada risiko persistensi: Pengguna dapat menyalahgunakan hak istimewa ini untuk membuat akun pengguna baru atau menginstal backdoor untuk mempertahankan akses persisten ke VM.

Untuk membantu mengurangi risiko persistensi ini, batasi penggunaan hak istimewa root dan hanya berikan peran Pengguna Login OS (roles/compute.osLogin) jika hak istimewa root tidak diperlukan.

Membuat 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 Anda pertama kali terhubung ke VM Linux menggunakan SSH, lingkungan tamu akan otomatis membuat akun pengguna Linux untuk Anda, dan menetapkan UID-nya.

Saat Anda menggunakan kunci berbasis metadata, lingkungan tamu tidak menautkan pengguna Linux ke akun pengguna Google Anda dan mungkin menetapkan UID yang berbeda di setiap VM yang terhubung. Jika Anda menggunakan protokol seperti NFS yang mengasumsikan UID yang konsisten di lingkungan yang tidak menerapkan UID yang konsisten di seluruh mesin, pengguna mungkin – secara tidak sengaja atau, dalam kasus pelaku jahat, sengaja – dapat melakukan akses jarak jauh sebagai pengguna lain.

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

Anda dapat mencegah ambiguitas UID dan nama pengguna tersebut dengan menggunakan Login OS: Saat Anda pertama kali login ke VM Linux menggunakan Login OS, lingkungan tamu akan membuat pengguna Linux 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 akun Cloud Identity atau Google Workspace yang sama
  • UID dan GID yang unik di semua Google Cloud project
  • jalur direktori beranda
  • konfigurasi tambahan, seperti shell login

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

Nama pengguna dan UID yang dialokasikan oleh Login OS bersifat unik dalam lingkungan Google Cloud, tetapi mungkin tumpang-tindih atau tidak konsisten dengan nama pengguna dan UID 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 otomatis. Sebagai gantinya, gunakan Directory API untuk membuat profil POSIX Login OS terlebih dahulu dan menetapkan nama pengguna, UID, dan GID kustom.

Langkah berikutnya