Praktik terbaik untuk mengontrol akses jaringan SSH

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

Untuk terhubung ke instance VM menggunakan SSH, pengguna memerlukan akses jaringan ke VM dan kredensial SSH yang valid. Secara default, Compute Engine menggunakan aturan firewall yang tidak membatasi akses jaringan SSH, tetapi mengizinkan siapa pun di internet untuk hubungkan ke port 22 instance VM. Meskipun nyaman bagi developer untuk mendapatkan dimulai dengan cepat tanpa mempertimbangkan kontrol jaringan atau keamanan, yang memungkinkan pengguna untuk terhubung dari perangkat, jaringan, dan lokasi apa pun dapat menimbulkan risiko:

  • Pengguna mungkin terhubung dari perangkat atau jaringan yang tidak dipercaya.
  • Pihak tidak bertanggung jawab mungkin meluncurkan serangan {i>brute force<i} dan mencoba untuk menyusupi ke semua instance VM Anda.
  • Pihak tidak bertanggung jawab yang memiliki akses ke kredensial SSH yang bocor atau tidak dicabut dapat menggunakan kredensial tersebut untuk mengakses dan login ke VM dari jaringan mana pun.

Bagian berikut menjelaskan bagaimana Anda dapat mengurangi risiko dengan membatasi jaringan, lokasi, atau perangkat tempat pengguna dapat membuat koneksi SSH ke VM Anda:

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.

Mengurangi eksposur jaringan

Memungkinkan pengguna untuk membuat koneksi SSH dari mana saja berarti Anda sepenuhnya bergantung pada mekanisme otentikasi dan otorisasi SSH untuk melindungi VM Anda. Anda dapat mengurangi risiko dan membuat lapisan perlindungan tambahan dengan mengurangi eksposur jaringan VM.

Ada beberapa pendekatan untuk mengurangi eksposur jaringan VM Anda. Untuk mengidentifikasi pendekatan yang paling sesuai dengan lingkungan Anda, Anda harus mempertimbangkan sejumlah faktor seperti yang diilustrasikan oleh diagram alir berikut:

Mengurangi paparan jaringan

  • Akses eksternal: Faktor pertama yang harus dipertimbangkan adalah apakah VM hanya memerlukan agar dapat diakses dalam jaringan VPC, atau apakah Anda memerlukan VM juga dapat diakses secara eksternal.

    Jika akses internal VPC sudah memadai, Anda tidak perlu menetapkan ke VM, tetapi Anda tetap harus memutuskan cara mengelola akses.

  • Ukuran jaringan internal: Jika akses internal VPC sudah memadai, faktor kedua yang perlu dipertimbangkan adalah ukuran jaringan internal Anda.

    Dalam jaringan yang lebih kecil, mungkin cukup untuk menggunakan aturan {i>firewall<i} yang memungkinkan traffic masuk ke port 22 dari alamat internal untuk membantu melindungi VM Anda. Di beberapa jaringan yang lebih besar, mengandalkan aturan {i>firewall<i} saja mungkin terlalu membatasi: Dalam kasus semacam ini, Anda dapat memperoleh manfaat dari penggunaan penerusan TCP-Aware Proxy untuk menerapkan akses kontekstual ke VM.

  • Desain perimeter Kontrol Layanan VPC: Faktor berikutnya yang perlu dipertimbangkan adalah apakah Instance VM adalah bagian dari perimeter Kontrol Layanan VPC.

    Jika VM merupakan bagian dari perimeter layanan, berarti setiap akses API yang dari VM dianggap berasal dari dalam perimeter. Jika Anda memberi pengguna yang terletak di luar perimeter akses SSH ke VM di dalam perimeter, mereka berpotensi menyalin data dari perimeter lokal, atau sebaliknya. Hal ini dapat menjaga kerahasiaan dan integritas data perimeter Anda yang terancam.

    Kapan pun Anda perlu memberikan akses SSH ke instance VM yang merupakan bagian dari Perimeter Kontrol Layanan VPC, gunakan IAP TCP-forwarding. IAP mendeteksi apakah workstation pengguna merupakan bagian dari perimeter Kontrol Layanan VPC yang sama dan memblokir upaya akses dari luar perimeter layanan secara default. Untuk mengizinkan akses eksternal, gunakan aturan masuk dan mengonfigurasi mereka untuk menerapkan akses kontekstual.

  • Pengelolaan perangkat klien: Faktor terakhir yang perlu dipertimbangkan adalah bagaimana perangkat klien dikelola, karena hal itu menentukan cara di mana Anda dapat mengontrol akses kontekstual.

    Akses kontekstual berfungsi paling efektif saat Pengelola Akses Konteks memiliki akses ke beragam sinyal tentang pengguna, perangkat, dan sehingga dapat digunakan bersama Chrome Enterprise Premium: Jika Anda menggunakan Chrome Enterprise Premium untuk mengelola perangkat Anda, lalu Anda dapat menyiapkannya tingkat akses yang mengontrol akses berdasarkan postur perangkat. Anda kemudian dapat menerapkan tingkat akses ini ke akses SSH dengan menggunakan penerusan TCP di IAP yang dikombinasikan dengan binding akses atau kondisi IAM.

    Jika Anda tidak mengontrol konfigurasi perangkat klien, Anda harus mempertimbangkan data tersebut tidak dikelola dan berpotensi tidak tepercaya.

    Untuk mengizinkan akses dari perangkat yang tidak dikelola, Anda juga dapat menggunakan IAP penerusan TCP, tetapi Anda hanya dapat mengelola akses berdasarkan alamat IP perangkat. Karena Access Context Manager tidak memiliki akses ke sinyal perangkat, Anda tidak akan dapat membatasi akses berdasarkan postur perangkat.

Berdasarkan faktor-faktor tersebut dan dengan menggunakan diagram alir, Anda dapat mengidentifikasi pendekatan mana untuk mengurangi dari eksposur jaringan yang paling sesuai dengan lingkungan Anda. Bagian berikut menjelaskan pendekatan ini secara lebih rinci.

Akses SSH berbasis IAP

Ide pendekatan ini adalah untuk hanya mengizinkan akses SSH melalui IAP TCP-forwarding, dan memungkinkan IAP mengontrol akses berdasarkan identitas pengguna.

Kami merekomendasikan pendekatan ini untuk instance VM yang menerapkan hal berikut:

  • Instance VM harus dapat diakses secara eksternal atau dari jaringan internal yang besar.
  • VM bukan bagian dari perimeter Kontrol Layanan VPC.

Secara default, instance VM dengan alamat IP eksternal memungkinkan akses SSH {i>firewall<i} {i>default<i} mengizinkan koneksi dari internet publik ke porta 22, tetapi ini bukanlah pendekatan yang disarankan. Pendekatan ini dapat meningkatkan secara signifikan risiko bahwa VM bisa terkena serangan seperti berikut:

  • Penggunaan kredensial yang tidak dicabut: Mantan karyawan yang aksesnya belum dicabut sepenuhnya dapat terus mengakses VM.
  • Penyalahgunaan kredensial yang valid: Pihak tidak bertanggung jawab yang memiliki barang curian atau bocor kredensial apa pun yang digunakan untuk login.
  • Denial of service: Pihak tidak bertanggung jawab mungkin mencoba menghabiskan resource VM dengan membanjirinya dengan permintaan.

Cara yang lebih aman untuk mengaktifkan akses SSH eksternal ke instance VM adalah dengan menggunakan Penerusan TCP IAP. Mirip dengan {i>bastion host<i} atau {i>reverse proxy<i}, IAP TCP-forwarding bertindak sebagai perantara antara klien perangkat dan VM.

Penerusan TCP IAP melakukan empat fungsi berikut ketika pengguna mencoba untuk membuat koneksi SSH:

  • Autentikasi: IAP memverifikasi bahwa pengguna memiliki kredensial Google yang valid.
  • Otorisasi: IAP memeriksa kebijakan IAM untuk memverifikasi bahwa pengguna telah diberi izin untuk terhubung ke VM melalui IAP.
  • Akses kontekstual: Opsional, IAP dapat memverifikasi bahwa pengguna, perangkat, dan lokasi mereka memenuhi tingkat akses tertentu.
  • Audit: Saat log akses data diaktifkan, log IAP setiap upaya yang berhasil dan gagal untuk terhubung ke instance VM.

Dengan bertindak sebagai perantara dan melakukan fungsi-fungsi ini, IAP menghilangkan kebutuhan untuk menetapkan alamat IP eksternal ke VM, dan lapisan keamanan tambahan.

Akses SSH kontekstual berbasis IAP

Ide pendekatan ini adalah untuk hanya mengizinkan akses SSH melalui IAP, penerusan TCP, dan untuk memungkinkan IAP mengendalikan akses berdasarkan alamat identitas dan faktor tambahan.

Kami merekomendasikan pendekatan ini untuk instance VM yang menerapkan hal berikut:

  • Instance VM harus dapat diakses dari luar VPC dan jaringan yang yang terhubung ke VPC.
  • VM bukan bagian dari perimeter Kontrol Layanan VPC.
  • VM hanya perlu dapat diakses dari perangkat, jaringan, atau lokasi tertentu.

Saat Anda memberi pengguna akses SSH ke instance VM, baik secara langsung maupun melalui IAP – secara default, mereka dapat mengakses instance VM dari perangkat, jaringan, dan lokasi. Meskipun nyaman bagi pengguna, tingkat akses ini meningkatkan risiko karena pengguna mungkin terhubung dari perangkat yang disusupi atau jaringan yang tidak dapat dipercaya.

Untuk mengurangi risiko, konfigurasikan penerusan TCP dalam IAP sehingga pengguna dapat hanya mengakses instance VM dari perangkat atau lokasi tertentu. Anda dapat mengonfigurasi akses kontekstual tersebut dengan dua cara:

  • Binding akses: Anda dapat membuat tingkat akses dan menetapkannya ke grup dengan menggunakan binding akses. Binding akses adalah kebijakan berbasis formulir atau identitas dan berlaku untuk semua yang coba diakses oleh pengguna – ini termasuk IAP, tetapi juga API lain dan konsol Google Cloud.

    Penggunaan binding akses berfungsi paling baik jika Anda ingin memastikan bahwa akses kontekstual diterapkan secara seragam di seluruh resource.

  • Kondisi IAM: Anda dapat membuat tingkat akses dan menetapkan ke tiap binding peran IAM menggunakan Kondisi IAM.

    Menggunakan binding peran IAM adalah bentuk kebijakan berbasis resource dan pendekatan ini berfungsi paling baik jika Anda ingin menerapkan kebijakan yang berbeda untuk set VM yang berbeda.

Tingkat akses dasar memungkinkan Anda membatasi akses menurut jaringan atau lokasi geografis. Sebagai seorang Pelanggan Chrome Enterprise Premium, Anda juga dapat membatasi akses berdasarkan seperti kekuatan kredensial, konfigurasi browser yang digunakan untuk otentikasi, atau postur perangkat.

Akses SSH berbasis Kontrol Layanan VPC

Ide pendekatan ini adalah untuk hanya mengizinkan akses SSH melalui IAP, penerusan TCP, dan untuk mengonfigurasi perimeter layanan untuk mengizinkan IAP traffic masuk untuk identitas tertentu, yang merupakan sumber informasi yang kita miliki.

Kami merekomendasikan pendekatan ini untuk instance VM yang merupakan bagian dari perimeter Kontrol Layanan VPC.

Memberi pengguna akses SSH eksternal ke VM yang merupakan bagian dari perimeter layanan dapat berisiko karena memungkinkan pengguna merusak Kontrol Layanan VPC Anda perimeter dengan memindahkan data secara tidak sah melalui SSH.

Dengan hanya mengizinkan akses SSH melalui penerusan TCP di IAP, Anda dapat mengurangi risiko ini dan memastikan bahwa semua akses SSH tunduk pada konfigurasi perimeter Kontrol Layanan VPC Anda:

  • Jika pengguna mencoba untuk terhubung dari luar perimeter layanan (seperti yang digambarkan dalam contoh sebelumnya), IAP TCP-forwarding tidak hanya memeriksa apakah pengguna diberi akses IAM ke VM, tetapi juga memeriksa apakah permintaan tersebut memenuhi aturan traffic masuk perimeter.

  • Jika pengguna mencoba untuk terhubung dari dalam perimeter layanan, IAP Penerusan TCP juga memeriksa apakah pengguna diberi akses IAM atau tidak ke VM, tetapi mengabaikan aturan masuknya Kontrol Layanan VPC.

    IAP menganggap koneksi berasal dari dalam perimeter layanan jika salah satu hal berikut terjadi:

    • IP sumber adalah alamat IP eksternal VM yang merupakan bagian dari perimeter layanan.
    • Koneksi dilakukan melalui Akses Google Pribadi dari VM yang sebagai bagian dari perimeter layanan.
    • Koneksi dilakukan melalui endpoint akses Private Service Connect yang merupakan bagian dari perimeter layanan.

Akses SSH internal yang dikontrol firewall

Ide pendekatan ini adalah untuk melarang semua akses eksternal dan hanya mengizinkan Akses SSH internal VPC.

Anda dapat menggunakan pendekatan ini untuk instance VM yang menerapkan hal berikut:

  • Instance VM tidak harus dapat diakses secara eksternal.
  • VM terhubung ke jaringan internal berukuran kecil hingga menengah.
  • VM bukan bagian dari perimeter Kontrol Layanan VPC.

Untuk melarang semua akses eksternal, Anda dapat melakukan salah satu langkah berikut:

Nonaktifkan akses konsol serial

Untuk memecahkan masalah instance VM yang gagal berfungsi, Compute Engine memungkinkan Anda menghubungkan ke konsol port serial instance melalui gateway SSH, ssh-serialport.googleapis.com. Gateway ini dapat diakses secara publik melalui internet.

Gateway SSH mengakses VM melalui hypervisor yang mendasarinya, bukan melalui Jaringan VPC. Oleh karena itu, akses ke konsol serial dikontrol oleh Kebijakan IAM dan bukan oleh aturan firewall.

Mengizinkan pengguna untuk mengakses konsol seri VM dapat meninggalkan VM secara tidak sengaja pencahayaan yang berlebihan. Untuk mencegah eksposur berlebihan ini, gunakan compute.disableSerialPortAccess batasan kebijakan organisasi untuk menonaktifkan akses konsol serial, dan mencabut batasan untuk sementara saat Anda memerlukan akses darurat ke port serial VM.

Gunakan bastion VM jika Anda memerlukan rekaman sesi

Dengan bertindak sebagai perantara antara perangkat klien dan VM, IAP Penerusan TCP melakukan fungsi yang umumnya dilakukan oleh {i>bastion host<i} atau server jump. Fungsi ini mencakup:

  • Menegakkan kebijakan akses secara terpusat
  • Mengaudit akses

Tidak seperti beberapa {i>bastion host<i}, penerusan TCP di IAP tidak Koneksi SSH: Saat Anda membuat koneksi SSH ke VM melalui IAP Penerusan TCP, koneksi SSH dienkripsi end-to-end antara klien Anda dan VM. Berkat enkripsi {i>end-to-end<i} ini, IAP Penerusan TCP tidak dapat memeriksa isi sesi SSH, dan tidak menyediakan kemampuan perekaman sesi. Log audit IAP berisi metadata koneksi, tetapi tidak mengungkapkan informasi apa pun tentang konten sesi.

Jika Anda membutuhkan perekaman sesi, gunakan bastion VM:

  • Mengonfigurasi bastion VM agar dapat menghentikan koneksi dan kumpulan data SSH isinya. Pastikan untuk membatasi penggunaan penerusan port SSH seperti yang mungkin mengurangi efektivitas perekaman sesi.
  • Menyiapkan aturan firewall VM target agar koneksi SSH hanya diizinkan dari bastion VM.
  • Mengizinkan akses ke bastion VM hanya melalui penerusan TCP di IAP

Menggunakan kebijakan firewall untuk membatasi eksposur SSH

Setelah Anda menentukan cara untuk membatasi eksposur SSH bekerja paling baik untuk lingkungan Anda, Anda harus memastikan bahwa semua VM dan project dikonfigurasi dengan sesuai. Secara khusus, Anda harus memastikan bahwa semua proyek menggunakan serangkaian aturan {i>firewall<i} yang konsisten yang menentukan bagaimana SSH dapat digunakan.

Untuk menerapkan sekumpulan aturan firewall di beberapa project, gunakan kebijakan firewall hierarkis dan terapkan ke folder di hierarki resource Anda.

Misalnya, untuk membantu memastikan bahwa semua akses SSH dilakukan melalui Penerusan TCP IAP, menerapkan kebijakan firewall yang menyertakan dua aturan khusus berikut (sesuai urutan prioritas):

  1. Izinkan traffic masuk dari 35.235.240.0/20 ke port 22 VM yang dipilih. 35.235.240.0/20 adalah rentang IP yang digunakan oleh penerusan TCP IAP.
  2. Tolak traffic masuk dari 0.0.0.0/0 ke port 22 di semua VM.

Langkah selanjutnya