VPN üzərindən Cassandra: müştərilərə və qovşaqlara ayrı giriş verin

Cassandra quraşdırmasının vahid bir verilənlər bazası şəbəkəsi yoxdur. Tətbiqlər müştəri xidməti ilə danışır, klaster üzvləri bir-biri ilə danışır, operatorlar isə inzibati interfeyslərdən istifadə edir və bu üç auditoriya bir-birinin əlçatanlığını miras almamalıdır. VPN kimi xüsusi bir yol yaxşı başlanğıc nöqtəsidir, lakin o, verilənlər bazasının istifadəçi şəxsiyyəti deyil və onun şifrələmə siyasəti də deyil. Bağlantı qərarını və avtorizasiya qərarını iki ayrı baxış kimi qiymətləndirin.

Üç auditoriyanın hər biri öz cavabını alır və aşağıdakı bölmələr onları məruz qalma sırası ilə ele alır.

Üç auditoriya, üç qərar

Hər qrupun həqiqətən nəyə ehtiyacı olduğunu hər hansı qaydaya toxunmazdan əvvəl müəyyən edin. Müştərilərə müştəri dinləyicisi və onlara verilə biləcək hər qovşağa çatmaq üçün kifayət qədər məlumat lazımdır, qovşaq həmkarlarına qovşaqlararası portda bir-biri lazımdır, operatorlara isə runbook-un həqiqətən tələb etdiyi şey üçün idarəetmə interfeysi lazımdır. Üç siyahı, üç auditoriya, üç etimad səviyyəsi.

Ümumi səhv tək düz xüsusi seqment qurmaq və VPN sərhədinin qalanını etdiyini güman etməkdir. Onun içində müştəri portuna çata bilən tətbiq adətən qovşaqlararası porta da çata bilir və operatorun inzibati alətləri çox vaxt tətbiqlə eyni keçid hostunda oturur. Bunları birlikdə düzləşdirmək o deməkdir ki, kompromisə uğramış tətbiq şəxsiyyəti artıq öz sorğularından daha geniş çıxışa malikdir. Üç auditoriyanı dizayn sənədində üç sətir kimi çəkin, hər birinin yanında ona icazə verən qayda olsun və boşluqlar heç kim onları qurmadan görünəcək.

Müştərilərə nə lazımdır və başqa heç nə

Yerləşdirilmiş versiya üçün nəzərdə tutulan tətbiq mənbələrinə müştəri son nöqtələrinə icazə verin və əlaqəsiz klaster və idarəetmə xidmətlərini bu çıxışdan kənarda saxlayın. Sonra sürücünün qovşaqları necə kəşf etdiyini yoxlayın. Əlçatan ilkin əlaqə nöqtəsi sürücünün sonra seçdiyi hər qovşaq ünvanının həmin müştəri kontekstindən əlçatan olmasını təsdiqləmir, çünki sürücü klasterdən həmkarları soruşur və sonra klasterin elan etdiyi ünvanlara qoşulur.

Buna görə bir xüsusi ünvan uyğunsuzluğu tanış nümunə yaradır: uğurlu ilk bağlantı və ardınca fasilələr. Elan olunan ünvanları və müştəri marşrutlaşdırmasını qəsdən konfiqurasiya edin; bir uyğunsuzluğu düzəltmək üçün bütün klasteri internetə yayımlamaq marşrutlaşdırma xətasını geri qaytara bilməyəcəyiniz bir məruz qalma ilə dəyişir.

Tətbiqin verilənlər bazası autentifikasiyasını və rol icazələrini də yerində saxlayın. Paylaşılan tərcümə olunmuş VPN ünvanı bir çox istifadəçi və ya xidməti təmsil edə bilər, buna görə o, heç vaxt fərqli verilənlər bazası şəxsiyyətlərini əvəz etmir.

Müştəri-qovşaq və qovşaqlararası şifrələməni ayrı-ayrı edin

Apache-nin təhlükəsizlik sənədləri müştəri-qovşaq və qovşaqlararası şifrələməni ayrı konfiqurasiyalar kimi ele alır və birinin aktivləşdirilməsi digərini aktivləşdirmir. Bu fərq VPN-in içində də qüvvədədir, çünki tunel öz seqmentini qoruyur və tətbiq prosesindən verilənlər bazası prosesinə və ya klaster üzvlərinin hər cütü arasında avtomatik uzanmır.

Hər ikisini şablon standartını miras almaq əvəzinə açıq şəkildə yandıran konfiqurasiya təxminən belə görünür:

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

İstəyə bağlı müştəri şifrələməsinə icazə verən server konfiqurasiyalarında TLS-in qəbul edilməsi şifrələnməmiş bağlantıların qəbulu ilə birgə mövcud ola bilər, buna görə niyyəti deyil, faktiki siyasəti oxuyun. Sertifikat adlarını, etimad paylanmasını və yenilənməsini hər müştərinin həqiqətən əlaqə saxladığı son nöqtələr üçün planlaşdırın; host adını IP ünvanı ilə əvəz etmək müştərinin şəxsiyyət yoxlamasını, təkcə marşrutunu deyil, dəyişir.

İdarəetməni öz yolunda saxlayın

Qovşaqlararası trafikə icazə verilmiş həmkar dəsti və öz müdafiə siyasəti lazımdır. İnzibati girişə, o cümlədən istifadə olunduğu yerdə JMX-ə, ayrı auditoriya və öz autentifikasiyası lazımdır. Adi sorğular verməyə icazə verilmiş tətbiq bununla bütün idarəetmə imkanlarına ehtiyac duymur və əksi daha pisdir: tətbiq seqmentinə açılmış inzibati yol xətadan yenidən qurmaya ən qısa yoldur. Bu iki auditoriyanı ayrı-ayrı yazın və sahiblərini adlandırın, çünki onlar adətən qaydaları təsadüfən birləşdirilmiş fərqli komandalardır.

Faktiki bulud qaydalarını, host qaydalarını və dinləyici konfiqurasiyasını uyğun saxlayın. Xüsusi dinləyici yenə də təsadüfi tərcümə və ya proksi vasitəsilə açıla bilər və geniş ictimai qayda kimsə hər ikisini birdən yoxlamayana qədər dar VPN qaydasının yanında səssizcə dura bilər.

Operatorların həqiqətən idarəetmə yoluna ehtiyacı olduğu yerdə ona adlı sahib və tətbiqinkindən daha qısa etimad məlumatı ömrü verin. Bu, növbəti şəxs klasteri miras aldıqda nümayəndəliyi görünən saxlayır.

Dizayn nə vəd edir

Üç vədin hamısını yalnız bağlantı testləri ilə deyil, real rollarla yoxlayın. Təsdiqlənmiş tətbiq icazə verilmiş işini tamamlamalı və başqa heç nə etməməlidir, kənarda qalan mənbə müştəri girişində uğursuz olmalıdır və tətbiq şəxsiyyəti ayrılmış idarəetmə yollarında rədd edilməlidir. Müştəri yenidən qoşulmasını və qovşaq seçimini eyni yayımlama testinə əlavə edin, çünki kəşf səhvləri məhz orada üzə çıxır.

Dizayn sənədini üç cümlə ilə bitirin: hansı müştərilər sorğu verə bilər, hansı qovşaqlar əlaqə saxlaya bilər və hansı operatorlar idarə edə bilər. VPN-in arxasında olmaq faydalı topologiya məlumatıdır, lakin bu üç sualın heç birinə cavab deyil.