VPN üzerinden Cassandra: istemciler ve düğümler için ayrı erişim

Bir Cassandra kurulumunun tek bir evrensel veritabanı ağı yoktur. Uygulamalar istemci hizmetiyle konuşur, küme üyeleri birbirleriyle konuşur ve operatörler yönetim arayüzlerini kullanır ve bu üç kitle birbirinin erişilebilirliğini miras almamalıdır. VPN gibi özel bir yol iyi bir başlangıç noktasıdır, ancak veritabanının kullanıcı kimliği değildir ve şifreleme politikası da değildir. Bağlantı kararını ve yetkilendirme kararını iki ayrı inceleme olarak ele alın.

Üç kitlenin her biri kendi yanıtını alır ve aşağıdaki bölümler onları maruz kalma sırasına göre ele alır.

Üç kitle, üç karar

Bir kurala dokunmadan önce her grubun gerçekte neye ihtiyacı olduğunu belirleyin. İstemcilerin istemci dinleyicisine ve kendilerine verilebilecek her düğüme ulaşmak için yeterli bilgiye ihtiyacı vardır, eş düğümlerin internode bağlantı noktasında birbirine ihtiyacı vardır ve operatörlerin runbook'un gerçekten istediği şey için yönetim arayüzüne ihtiyacı vardır. Üç liste, üç kitle, üç güven düzeyi.

Yaygın hata, tek bir düz özel segment kurup VPN sınırının gerisini halledeceğini varsaymaktır. İçinde, istemci bağlantı noktasına ulaşan bir uygulama genellikle internode bağlantı noktasına da ulaşır ve bir operatörün yönetim araçları çoğu zaman uygulamayla aynı atlama ana bilgisayarında oturur. Bunları birlikte düzleştirmek, ele geçirilmiş bir uygulama kimliğinin kendi sorgularından daha fazla erişime zaten sahip olduğu anlamına gelir. Üç kitleyi tasarım belgesinde üç satır olarak çizin, her biri kendisine izin veren kuralla birlikte, ve boşluklar kimse onları inşa etmeden önce görünür hale gelir.

İstemcilerin neye ihtiyacı var, fazlası değil

Dağıtılan sürüm için amaçlanan uygulama kaynaklarına istemci uç noktalarına izin verin ve ilgisiz küme ile yönetim hizmetlerini bu erişimin dışında tutun. Sonra sürücünün düğümleri nasıl keşfettiğini kontrol edin. Ulaşılabilir bir ilk temas noktası, sürücünün sonradan seçtiği her düğüm adresinin o istemci bağlamından ulaşılabilir olduğunu kanıtlamaz, çünkü sürücü kümeden eşleri ister ve sonra kümenin duyurduğu adreslere bağlanır.

Bu yüzden tek bir özel adres uyuşmazlığı tanıdık deseni üretir: başarılı bir ilk bağlantı ve ardından zaman aşımları. Duyurulan adresleri ve istemci yönlendirmesini bilerek yapılandırın; tek bir uyuşmazlığı onarmak için tüm kümeyi internete yayımlamak, bir yönlendirme hatasını geri alamayacağınız bir maruziyetle değiştirir.

Uygulamanın veritabanı kimlik doğrulamasını ve rol izinlerini de yerinde tutun. Paylaşılan çevrilmiş bir VPN adresi birçok kullanıcıyı veya hizmeti temsil edebilir, bu yüzden ayrı veritabanı kimliklerinin yerini asla tutmaz.

İstemciden düğüme ve internode bağlantısını ayrı ayrı şifreleyin

Apache güvenlik belgeleri istemciden düğüme ve internode şifrelemesini ayrı yapılandırmalar olarak ele alır ve birini etkinleştirmek diğerini etkinleştirmez. Bu ayrım VPN içinde hâlâ geçerlidir, çünkü tünel kendi segmentini korur ve uygulama sürecinden veritabanı sürecine veya küme üyelerinin her çifti arasında otomatik olarak yayılmaz.

Her ikisini de şablon varsayılanını miras almak yerine açıkça açan bir yapılandırma yaklaşık olarak şöyle görünür:

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

İsteğe bağlı istemci şifrelemesine izin veren sunucu yapılandırmalarında, TLS kabulü şifrelenmemiş bağlantıların kabulüyle bir arada bulunabilir, bu yüzden niyeti değil yürürlükteki politikayı okuyun. Her istemcinin gerçekte iletişim kurduğu uç noktalar için sertifika adlarını, güven dağıtımını ve yenilemeyi planlayın; bir ana bilgisayar adını IP adresiyle değiştirmek istemcinin kimlik denetimini değiştirir, yalnızca rotasını değil.

Yönetimi kendi yolunda tutun

Internode trafiği izin verilen eş kümesine ve kendi koruma politikasına ihtiyaç duyar. Yönetim erişimi, kullanıldığı yerde JMX dahil, ayrı bir kitleye ve kendi kimlik doğrulamasına ihtiyaç duyar. Sıradan sorgular göndermesine izin verilen bir uygulama bu nedenle her yönetim yeteneğine ihtiyaç duymaz ve tersi daha kötüdür: uygulama segmentine açılan bir yönetim yolu, bir hatadan yeniden inşaya giden en kısa yoldur. Bu iki kitleyi ayrı ayrı yazın ve sahiplerini adlandırın, çünkü genellikle kuralları kazara birleştirilmiş farklı ekiplerdir.

Yürürlükteki bulut kurallarını, ana bilgisayar kurallarını ve dinleyici yapılandırmasını hizada tutun. Özel bir dinleyici yine de istenmeyen bir çeviri veya vekil üzerinden açığa çıkabilir ve geniş bir genel kural, biri her ikisini birden denetleyene kadar dar bir VPN kuralının yanında sessizce durabilir.

Operatörlerin gerçekten bir yönetim yoluna ihtiyaç duyduğu yerlerde, ona adlandırılmış bir sahip ve uygulamadan daha kısa kimlik bilgisi ömrü verin. Bu, küme bir sonraki kişiye geçtiğinde yetkilendirmeyi görünür tutar.

Tasarım ne vaat ediyor

Üç vaadin hepsini yalnızca bağlantı testleriyle değil, gerçek rollerle doğrulayın. Onaylanmış bir uygulama izin verilen işini tamamlamalı ve fazlasını yapmamalı, hariç tutulan bir kaynak istemci girişinde başarısız olmalı ve bir uygulama kimliği ayrılmış yönetim yollarında reddedilmelidir. İstemci yeniden bağlanmasını ve düğüm seçimini aynı kullanıma alma testine ekleyin, çünkü keşif hataları tam orada ortaya çıkar.

Tasarım belgesinde üç cümleyle bitirin: hangi istemciler sorgu yapabilir, hangi düğümler iletişim kurabilir ve hangi operatörler yönetebilir. Bir VPN'in arkasında olmak yararlı topoloji bilgisidir, ancak bu üç sorunun hiçbirinin yanıtı değildir.