TLS asli, penerusan SSH, atau VPN untuk satu layanan cloud

Pertanyaannya jarang apakah harus mengenkripsi sesuatu antara dua mesin cloud; pertanyaannya adalah antarmuka mana yang Anda enkripsi dan siapa yang memeriksa identitas siapa. Saya memulai percakapan ini dari layanan, bukan dari diagram jaringan, karena layanan sudah tahu apa yang dibutuhkannya. Tiga batas mencakup sebagian besar kasus: TLS milik aplikasi, satu port TCP yang diteruskan melalui SSH, dan overlay terutekan yang memberi setiap peserta alamat. Ketiganya tidak diperingkat menurut kekuatan, melainkan menurut seberapa banyak masalah yang dicakupnya.

Mulai dari layanan, bukan dari jaringan

Bergeraklah keluar dari proses. Protokol apa yang dipakainya, nama apa yang akan diverifikasi klien, dan siapa yang boleh membuka koneksi? Ketiga jawaban itu menyisihkan opsi lebih cepat daripada tabel perbandingan mana pun, dan konfigurasi layanan sendiri biasanya menjawabnya dalam beberapa menit.

Ambil API internal kecil yang sudah menyajikan HTTPS pada port 8443 dengan sertifikat untuk api.internal.example. ss -ltnp di host menunjukkan ke apa ia terikat, dan openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example menunjukkan apakah sertifikat itu valid untuk nama yang benar-benar akan dipakai klien. Jika keduanya sehat, layanan dapat melindungi alirannya sendiri dan tinggal keterjangkauan. Itu masalah yang jauh lebih kecil daripada membangun jaringan.

Langkah 1: apakah layanan melindungi dirinya sendiri?

Ini opsi yang diambil bila cocok, dan cocok lebih sering daripada yang tim duga. Enkripsi layanan mencakup seluruh jalur antara klien dan server, termasuk setiap lompatan di antaranya, yang tidak diperbaiki oleh terowongan mana pun di sekitar tengah. Atur nama yang diharapkan dan kepercayaan secara eksplisit alih-alih mengandalkan apa yang kebetulan ada di penyimpanan bawaan klien.

Enkripsi dan keterjangkauan tetap menjadi kendali terpisah, dan menggabungkannya adalah tempat opsi ini salah. Layanan TLS pada pendengar publik tanpa batas tetap menerima upaya koneksi dari siapa pun, jadi pendengar dan aturan jaringan harus dibatasi secara independen dari fakta bahwa muatan terlindungi. Lalu periksa dependensinya, karena API di atas TLS tidak mengatakan apa pun tentang titik penemuan, port admin, atau kanal transfer massal di sebelahnya. Masing-masing perlu jawabannya sendiri, dan satu saudara tanpa perlindungan cukup untuk membuat seluruh batas menjadi fiksi.

Langkah 2: apakah satu port TCP seluruh persyaratannya?

Bila persyaratannya memang satu port TCP, penerusan adalah hal terkecil yang berfungsi. Penerusan lokal SSH membawa port itu melalui koneksi terautentikasi yang sudah ada.

Bentuknya ssh -N -L 8443:127.0.0.1:8443 [email protected], dan detail yang penting adalah alamat tujuan: 127.0.0.1 diselesaikan di sisi jauh, jadi koneksi ke layanan dibuka dari bastion, bukan dari laptop Anda. Ikat pendengar lokal secara sempit sebagai -L 127.0.0.1:8443:... agar Anda tidak tanpa sengaja memublikasikan layanan ke jaringan lokal Anda sendiri. Di sisi server, batasi apa yang boleh diteruskan akun alih-alih memercayai perilaku baik klien. PermitOpen, AllowTcpForwarding local, dan bawaan GatewayPorts no adalah tiga pengaturan yang mengubah relai serbaguna menjadi kanal tertentu.

Kontraknya sempit di kedua arah. SSH melindungi kanalnya sendiri, dan lompatan lanjutan dari bastion ke aplikasi lain memerlukan perlindungannya sendiri. Layanan yang hanya mendengarkan di loopback bastion memiliki paparan yang sangat berbeda dari yang dicapai melalui jaringan lain, dan penerusan tidak mengubahnya. Pertahankan autentikasi dan pemeriksaan TLS aplikasi alih-alih memperlakukan terowongan sebagai penggantinya.

Ini bekerja baik untuk satu koneksi dengan satu pemilik. Pada skala besar ini menjadi sistem: konflik port lokal, pengawasan, rotasi kunci, dan pertanyaan siapa yang menyalakan ulang penerusan setelah reboot.

Langkah 3: apakah perutean persyaratan sebenarnya?

Daftar itu adalah biaya jujur dari opsi terkecil, dan itulah sebabnya tim akhirnya mengganti beberapa perintah latar yang terlupakan dengan sesuatu yang terkelola. Penggantinya tidak otomatis VPN. Jika persyaratannya masih satu port TCP, penerusan terawasi dengan pemilik terdokumentasi lebih murah dijalankan daripada overlay dan gagal dengan cara yang bisa Anda lihat. Ukur kepemilikan operasional sebelum mengukur keanggunan.

Perutean menjadi jawaban yang tepat ketika perutean adalah persyaratannya. Beberapa aplikasi yang memerlukan konektivitas IP biasa, protokol yang tidak dapat dibawa penerusan TCP, atau layanan yang berpindah antarhost semuanya menunjuk ke arah yang sama.

Overlay memberi peserta alamat dan rute, lalu pekerjaan sebenarnya dimulai: rentang yang tidak tumpang tindih, kepemilikan rute, DNS, pendaftaran, pencabutan, dan apa yang terjadi ketika rekan hilang. Tidak satu pun dari itu datang bersama alamat. Rekan yang diterima ke overlay juga tidak otomatis diotorisasi untuk setiap operasi di tujuan, jadi autentikasi tingkat layanan tetap ada.

Apa yang Anda miliki sesudahnya

Dua hal termasuk dalam catatan yang Anda tinggalkan. Yang pertama adalah identitas yang diharapkan diverifikasi klien, karena setiap batas ini menurun diam-diam begitu pemeriksaan nama dilonggarkan agar sesuatu berfungsi. Yang kedua adalah langkah penghapusan: kunci, aturan, atau rute mana yang hilang saat akses berakhir, dan siapa yang melakukannya.

Penelusuran berakhir di tempat ia dimulai, pada layanan. Pilih batas yang mencakup lalu lintas sebenarnya dan memverifikasi rekan yang ingin Anda verifikasi, lalu tuliskan bagaimana akses diperbarui, dipantau, dan dihapus. Referensi OpenSSH adalah tempat untuk mengonfirmasi opsi penerusan sebelum menjanjikan kontrak yang sempit. Jika Anda tidak dapat menjelaskan langkah penghapusan dalam satu kalimat, batasnya lebih besar daripada masalahnya.