Cassandra melalui VPN: akses terpisah untuk klien dan node

Penerapan Cassandra tidak memiliki satu jaringan basis data universal. Aplikasi berbicara dengan layanan klien, anggota klaster berbicara satu sama lain, dan operator menggunakan antarmuka administratif, dan ketiga kelompok itu tidak seharusnya mewarisi jangkauan satu sama lain. Jalur privat seperti VPN adalah titik awal yang baik, tetapi itu bukan identitas pengguna basis data dan bukan kebijakan enkripsinya. Perlakukan keputusan konektivitas dan keputusan otorisasi sebagai dua tinjauan terpisah.

Masing-masing dari ketiga kelompok mendapat jawabannya sendiri, dan bagian di bawah ini membahasnya sesuai urutan paparan.

Tiga kelompok, tiga keputusan

Identifikasi apa yang sebenarnya dibutuhkan setiap kelompok sebelum Anda menyentuh sebuah aturan. Klien membutuhkan pendengar klien dan cukup informasi untuk menjangkau setiap node yang mungkin diberikan kepada mereka, node rekan membutuhkan satu sama lain pada port antar-node, dan operator membutuhkan antarmuka manajemen untuk apa yang benar-benar diminta runbook. Tiga daftar, tiga kelompok, tiga tingkat kepercayaan.

Kesalahan umum adalah membangun satu segmen privat datar dan menganggap batas VPN mengerjakan sisanya. Di dalamnya, aplikasi yang dapat menjangkau port klien biasanya juga dapat menjangkau port antar-node, dan alat administratif operator sering berada di host lompat yang sama dengan aplikasi. Meratakan semuanya bersama berarti identitas aplikasi yang disusupi sudah memiliki jangkauan lebih besar daripada kuerinya sendiri. Gambarkan ketiga kelompok sebagai tiga baris dalam dokumen desain, masing-masing dengan aturan yang mengizinkannya, dan celahnya menjadi terlihat sebelum siapa pun membangunnya.

Apa yang dibutuhkan klien, dan tidak lebih

Izinkan sumber aplikasi yang dimaksud menjangkau titik akhir klien untuk versi yang dipasang, dan jauhkan layanan klaster dan manajemen yang tidak terkait dari jangkauan itu. Lalu periksa bagaimana driver menemukan node. Titik kontak awal yang dapat dijangkau tidak membuktikan bahwa setiap alamat node yang dipilih driver setelahnya dapat dijangkau dari konteks klien itu, karena driver meminta rekan ke klaster lalu terhubung ke alamat apa pun yang diiklankan klaster.

Itulah sebabnya satu ketidakcocokan alamat privat menghasilkan pola yang familier: koneksi pertama yang berhasil diikuti waktu tunggu habis. Konfigurasikan alamat yang diiklankan dan perutean klien secara sengaja; menerbitkan seluruh klaster ke internet untuk memperbaiki satu ketidakcocokan menukar bug perutean dengan paparan yang tidak dapat Anda tarik kembali.

Pertahankan juga autentikasi basis data aplikasi dan izin perannya. Alamat VPN bersama yang diterjemahkan dapat mewakili banyak pengguna atau layanan, jadi itu tidak pernah menjadi pengganti identitas basis data yang berbeda.

Enkripsikan klien-ke-node dan antar-node secara terpisah

Dokumentasi keamanan Apache memperlakukan enkripsi klien-ke-node dan antar-node sebagai konfigurasi terpisah, dan mengaktifkan yang satu tidak mengaktifkan yang lain. Perbedaan itu tetap berlaku di dalam VPN, karena terowongan melindungi segmennya sendiri dan tidak secara otomatis meluas dari proses aplikasi ke proses basis data atau di antara setiap pasangan anggota klaster.

Konfigurasi yang menyalakan keduanya secara eksplisit, alih-alih mewarisi default templat, kira-kira terlihat seperti ini:

client_encryption_options:
  enabled: true
  optional: false
server_encryption_options:
  internode_encryption: all

Pada konfigurasi server yang mengizinkan enkripsi klien opsional, menerima TLS dapat hidup berdampingan dengan menerima koneksi tanpa enkripsi, jadi bacalah kebijakan yang berlaku, bukan niatnya. Rencanakan nama sertifikat, distribusi kepercayaan, dan pembaruan untuk titik akhir yang benar-benar dihubungi setiap klien; mengganti nama host dengan alamat IP mengubah pemeriksaan identitas klien, bukan hanya rutenya.

Pertahankan administrasi pada jalurnya sendiri

Lalu lintas antar-node membutuhkan kumpulan rekan yang diizinkan dan kebijakan perlindungannya sendiri. Akses administratif, termasuk JMX di tempat yang digunakan, membutuhkan kelompok terpisah dan autentikasinya sendiri. Aplikasi yang diizinkan mengeluarkan kueri biasa tidak dengan demikian membutuhkan setiap kemampuan manajemen, dan sebaliknya lebih buruk: jalur administratif yang terbuka ke segmen aplikasi adalah rute terpendek dari bug ke pembangunan ulang. Tuliskan kedua kelompok itu secara terpisah, dan sebutkan pemiliknya, karena biasanya itu tim berbeda yang aturannya tergabung secara tidak sengaja.

Pertahankan aturan cloud yang berlaku, aturan host, dan konfigurasi pendengar tetap selaras. Pendengar privat masih dapat terbuka melalui terjemahan atau proksi yang tidak disengaja, dan aturan publik yang luas dapat diam-diam berada di samping aturan VPN yang sempit sampai seseorang mengaudit keduanya sekaligus.

Di mana operator benar-benar membutuhkan jalur manajemen, berikan pemilik bernama dan masa hidup kredensial yang lebih pendek daripada aplikasi. Itu menjaga pendelegasian tetap terlihat ketika orang berikutnya mewarisi klaster.

Apa yang dijanjikan desain

Validasi ketiga janji dengan peran nyata, bukan hanya dengan uji konektivitas. Aplikasi yang disetujui harus menyelesaikan pekerjaan yang diizinkan dan tidak lebih, sumber yang dikecualikan harus gagal di pintu masuk klien, dan identitas aplikasi harus ditolak pada jalur administrasi yang dicadangkan. Tambahkan penyambungan ulang klien dan pemilihan node ke uji peluncuran yang sama, karena di situlah kesalahan penemuan muncul.

Akhiri dengan tiga kalimat dalam dokumen desain: klien mana yang dapat membuat kueri, node mana yang dapat berkomunikasi, dan operator mana yang dapat mengelola. Berada di belakang VPN adalah informasi topologi yang berguna, tetapi itu bukan jawaban atas salah satu dari tiga pertanyaan tersebut.