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 saat mereka membutuhkannya, dan mencabut akses tersebut saat mereka tidak membutuhkannya lagi. Jika proses pencabutan akses Anda tidak dapat diandalkan atau tidak mencakup semua resource, maka pelaku jahat mungkin dapat mempertahankan akses meskipun akses mereka seharusnya telah dicabut.

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

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.

Menggunakan Login OS untuk memastikan evaluasi akses berkelanjutan terhadap kebijakan IAM

Image Linux publik Compute Engine dikonfigurasi untuk mengizinkan autentikasi kunci publik SSH. Untuk mengizinkan kunci publik pengguna dan memberi mereka 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 memberikan hak istimewa root kepada pengguna hanya untuk VM tersebut; kunci yang diupload ke metadata project memberikan akses kepada pengguna ke semua VM dalam project.

  • Otorisasi kunci Login OS: Sebagai pengguna, Anda mengupload satu atau beberapa kunci publik ke profil Login OS Anda, yang merupakan bagian dari akun pengguna Google Anda.

    Sebagai administrator, Anda dapat memutuskan apakah akan memberikan hak istimewa root atau hak istimewa pengguna biasa kepada pengguna di VM dengan memberikan peran IAM Pengguna Admin Login OS atau peran IAM Pengguna Login OS.

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

Perbedaan utama antara kedua mekanisme tersebut adalah kapan akses dievaluasi terhadap 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 pengguna tersebut tidak dapat lagi digunakan untuk memberikan akses SSH.

Penggunaan kunci berbasis metadata dapat membuat Anda rentan terhadap ancaman persisten: Pengguna dapat mempertahankan akses SSH lebih lama dari yang diperlukan jika kunci publik mereka tidak dihapus dari metadata secara tepat waktu, dan mereka bahkan dapat mempertahankan akses setelah keluar dari organisasi. Meskipun Anda dapat mengurangi risiko ini dengan memindai metadata secara rutin, melakukannya bisa jadi sulit di lingkungan yang lebih besar, dan mungkin tidak cukup karena kunci berbasis metadata memberi pengguna hak istimewa root.

Untuk membantu melindungi dari ancaman persistensi semacam itu, jangan izinkan pengguna menggunakan kunci berbasis metadata. Sebagai gantinya, konfigurasi project Anda untuk mewajibkan 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, dan 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, untuk mengubah metadata level instance, Anda memerlukan izin compute.instances.setMetadata pada instance VM terkait.

Metadata level instance memiliki prioritas lebih tinggi daripada metadata level project. Oleh karena itu, menyetel enable-oslogin ke TRUE di metadata project tidak cukup untuk menerapkan penggunaan Login OS di seluruh project: Pengguna dengan akses Admin Instance Compute atau 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 penetapan 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 istimewa secara sementara atau per-VM

Jika memiliki instance VM yang menjalankan workload berbeda dan dikelola oleh tim yang berbeda, Anda dapat menyederhanakan pengelolaan akses dengan men-deploy VM ini di projectTrusted Cloud yang berbeda, dan mengizinkan project menggunakan jaringan bersama. Namun, penggunaan project terpisah tidak selalu memungkinkan dan beberapa project 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 pemberian peran secara permanen kepada pengguna seperti Admin Instance Compute di tingkat project. Sebagai gantinya, bedakan antara akses hanya lihat dan akses istimewa:

  • Berikan peran Compute Viewer atau peran hanya baca yang setara kepada pengguna di tingkat project. Peran ini memungkinkan pengguna menjelajahi VM menggunakan konsol Trusted Cloud , tetapi tidak memungkinkan mereka memublikasikan kunci SSH atau mengakses VM.
  • Berikan peran istimewa Compute OS Login, Compute Instance Admin, atau peran istimewa lainnya kepada pengguna hanya untuk VM tertentu, 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, penangguhan atau penghapusan akun pengguna juga 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 mencabut kemampuannya 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 untuk mengautentikasi dan membuat koneksi SSH.

Untuk mencabut akses SSH secara andal saat pengguna keluar dari organisasi, pastikan untuk menangguhkan atau menghapus akun pengguna Cloud Identity atau Google Workspace miliknya. Jika Anda menggunakan IdP eksternal, konfigurasikan IdP tersebut untuk menyebarkan peristiwa penangguhan pengguna agar 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 terlampir, aplikasi yang berjalan di VM dapat meminta kredensial berumur pendek dari server metadata VM dan menggunakan kredensial ini untuk bertindak sebagai akun layanan.

Memiliki akses SSH ke VM memberi Anda hak istimewa 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 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 penyalahgunaan akses SSH untuk eskalasi hak istimewa.

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

  • Jangan melampirkan akun layanan ke VM kecuali jika workload memerlukan akses ke Trusted Cloud resource.
  • Gunakan akun layanan tujuan tunggal dan hanya berikan akses ke resource yang diperlukan beban kerja tersebut.
  • Mewajibkan 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 peran Pengguna Login OS (roles/compute.osLogin) kepada pengguna, Anda menetapkan hak istimewa pengguna terbatas di VM. Sebaliknya, jika Anda memberikan peran Pengguna Admin Login OS (roles/compute.osAdminLogin) kepada pengguna, menggunakan otorisasi kunci berbasis metadata, bukan Login OS, atau mengizinkan pengguna untuk mengubah metadata VM, Anda secara implisit memberikan hak istimewa root kepada pengguna di VM.

Memberi pengguna hak istimewa root di VM dapat membuat Anda terpapar risiko persistensi: Pengguna dapat menyalahgunakan hak istimewa ini untuk membuat akun pengguna baru atau menginstal pintu belakang 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 menyimpan database pengguna (/etc/passwd) dan grup (/etc/groups) lokal. Saat Anda pertama kali terhubung ke VM Linux menggunakan SSH, lingkungan tamu akan otomatis membuat akun pengguna Linux untuk Anda, dan menetapkan UID untuk akun tersebut.

Jika Anda menggunakan kunci berbasis metadata, lingkungan tamu tidak akan menautkan pengguna Linux ke akun pengguna Google Anda dan dapat menetapkan UID yang berbeda untuk setiap VM yang Anda hubungkan. 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 aktor jahat, dengan 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 oleh 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 OS Login: Saat Anda pertama kali login ke VM Linux menggunakan OS Login, 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 untuk semua pengguna di akun Cloud Identity atau Google Workspace yang sama
  • UID dan GID yang unik di semua project Trusted Cloud
  • jalur direktori beranda
  • konfigurasi tambahan, seperti shell login

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

Nama pengguna dan UID yang dialokasikan oleh Login OS bersifat unik dalam lingkungan Trusted Cloud Anda, tetapi mungkin tumpang-tindih atau tidak konsisten dengan nama pengguna dan UID yang Anda gunakan di luar Trusted 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 OS Login terlebih dahulu dan menetapkan nama pengguna, UID, dan GID kustom.

Langkah berikutnya